導讀： 在數字化革命和AI賦能的大背景下，推薦場景邏輯越來越複雜，推薦細分場景越來越豐富，對業務迭代和效果優化的效率有了更高的要求。推薦系統業務和技術在傳統架構支撐下自然堆砌，變得越來越臃腫，開發維護困難，推薦系統在應用架構上正面臨新的挑戰。本文就第四範式在智能推薦系統架構方面的探索實踐，聊一聊在應用架構治理方面提升推薦服務開發維護效率，增強系統靈活性和擴展性的新探索。重點探討在開發推薦系統乃至智能系統領域時遇到的問題，解決方法及未來的發展趨勢。
主要內容包括：
- 推薦系統業務現狀、趨勢及挑戰
- "治理"的指導思想
- Flowengine架構
- 應用Flowengine後推薦的架構
- 實例演示
01 推薦系統業務現狀，趨勢及挑戰
1. 推薦系統業務現狀
從圖中我們可以看出，推薦系統大體可以分爲三個階段，最初的探索階段，早在2010年左右，已經有了千人千面的說法，現在我們在學習推薦系統時，看一些文檔或者資料，大都會拿亞馬遜基於協同過濾的推薦、豆瓣基於標籤的推薦系統做介紹，它們都是早期推薦系統應用在工業界的代表。到了第二階段 ( 普及深入階段 )，淘寶、京東以及一些垂直行業開始大範圍嘗試個性化推薦，此時，工程架構，算法策略層面都有了一些新的發展，比如一些大型推薦系統已經開始向實時特徵，實時模型方向進行探索，以提升時效性，從而達到更好的推薦效果。到了第三個階段 ( 規模化精細化階段 )，進入移動互聯網時代，推薦已經不僅限於PC端的單一場景推薦，出現了移動端及多場景的推薦需求。現今，從拼多多、快手、抖音的推薦，再到百度、頭條的信息流推薦，推薦系統已經成爲一個網站的靈魂，驅動着各種各樣的業務場景，在這一階段，智能化，工程化，標準化，注重開發效率和成本已成了技術探索的新方向。總體看來，推薦系統的發展趨勢是一個從無到有，從有到精的過程，不管是工程，算法或者場景業務都有了深入的發展。
2. 業務趨勢
推薦系統從業務方面來說，呈現四個趨勢：
① 場景更豐富： 早期做推薦的時候，推薦的開發門檻和成本很高，一個網站集中精力維護好一個場景，那時最經典的場景可能就是主頁下方的"猜你喜歡"。到了現在，多端，多個資源位，更多的細分場景都會有推薦需求。舉個例子，從進入頁面的"猜你喜歡"，導航九宮格的推薦，再到列表頁或下單頁的"看了又看"，“買了又買”，乃至在一個資源位上多個時段都有個性化的需求。在技術層面上，過去一個系統支撐一個場景或者一種模式，或者爲了簡單，一個架構，一個數據流，一個模型勉強應付多個場景，已無法滿足業務精細化運作的需要。現在，一個推薦系統需要支持很多的場景，不同的場景也需要有不同的數據流，業務邏輯，模型來深入刻畫；另一方面，早期做推薦系統是一個門檻很高的事情，對工程、算法的要求比較高，且業務邏輯高度定製，很難標準化、低門檻的開發，而現在隨着場景越來越豐富，推薦需求的旺盛增加，原來的工作模式已不能滿足需要，推薦場景開發需要向靈活化，標準化，規模化發展。
② 運營更精細： 從簡單規則 ( 比如像置頂，置底，黑白名單過濾 ) 向複雜規則轉變，通用規則向個性化規則轉變；技術主導變爲技術+業務聯營。推薦系統的效果好壞不再全是技術主導，業務也利用內容物料，規則玩法等運營手段發揮重要的作用。
③ 服務更實時： 早期推薦模型都是基於歷史數據採用離線批量的方式構建，離線的特徵，離線的模型，導致系統時效性差，用戶實時或近實時行爲的影響無法體現在推薦的結果中，用戶體驗不好。讓用戶能夠更快感受到變化，批量非實時向流式實時閉環推薦發展是推薦效果提升的必然趨勢。
④ 未來的重要趨勢：系統更智能，更知心。 早期的一些簡單算法或者規則，被更豐富，更復雜的AI算法所替代。推薦系統與AI結合的越來越緊密。推薦系統已經成爲AI賦能的重要場景之一，如何構建一套對AI友好的推薦系統，在技術上也是一個很大挑戰。
3. 帶來的技術挑戰
① 當前推薦系統的基本架構
在前面所講的業務大趨勢下，推薦系統技術層面正面臨一些挑戰。我們先了解一下當前推薦系統的基本架構，一般分爲五個板塊：
- 數據流：推薦系統的特點就是高度和數據流相關，那麼技術層面要解決數據怎麼來，數據怎麼用，數據怎麼加工處理，正確性和時效性如何保證等問題。
- 離線板塊：系統內涉及到一些數據加工，任務處理，模型生產，指標報表等離線任務，怎麼協調這些任務有序高效進行，並獲得正確有效的結果。
- 在線板塊：推薦系統對外提供實時推薦的能力，涉及到諸多的在線處理過程和規則。如何在適應業務快速變化的同時保證可用性和性能是至關重要的。
- AI：當下推薦系統的重要組成部分，其包含整個AI模型生成到服務的全生命週期。如何從系統層面支撐AI全生命週期以及如何有機集成進系統是一個挑戰。
- 基礎設施：推薦系統是一個多領域交叉的綜合應用，需要有衆多的中間件、基礎組件做支撐，如何管理和運維，減少依賴，有效利用是一個重要的命題。
上面說的五大板塊，對照起來實際上就是這張示意圖。虛線框是數據流，藍色框是離線部分，黃色框是在線部分，綠色的是基礎組件。相較於簡化的示意圖，在實際系統中，會變得更加複雜。比如就日誌或數據收集這一部分，日誌就可能因爲來源，收集方式多樣，導致開發，維護和管理的複雜度激增。各家公司的推薦系統涉及到大量的應用服務和中間件，它們的技術選型，實現方式，部署方式並不完全一致，但是整體邏輯結構卻是可以映射到剛纔提到的五個板塊內。但是這樣的架構存在什麼問題呢？我們可以結合四個趨勢來看，如果只針對性的支撐一個場景，這樣是可以的，但是當場景變得更多，更精細，問題便出現了。比如"猜你喜歡"，“看了又看”，召回物料可能不一樣，召回的算法邏輯可能不一樣，精排模型可能不同，甚至整個處理流程也可能不一樣，而它們卻在一個代碼模塊中，各場景的邏輯必然會形成耦合，互相影響，繼而影響系統穩定性。另一方面，因爲板塊割裂，很多領域邏輯分散在服務或中間件中，比如數據處理一般採用Azkaban/Airflow一類的中間件系統去調度處理任務，這就不可避免的將業務邏輯用大量的膠水代碼封裝在中間件系統中，如果一個開發者想要了解一個推薦系統的業務流程，就會變得非常困難。隨着業務的不斷髮展，這一現象會加劇，大量的場景規則，服務，運營策略，算法模型越來越多，最終導致系統難以維護，變成誰都不敢動的“老古董”。
② 當前推薦系統面臨的技術挑戰
我簡單的總結了一下，主要有四方面的挑戰。
a. 開發運維部署遷移困難，曲線陡峭，效率低下。 因爲推薦系統等智能系統，都涉及到大量的基礎組件和服務，各有特點，缺乏一體化的管理運維手段，如何把完整系統搭起來並管理，期間中間件或者服務出問題，都可能會導致系統不可用。這對於沒有豐富的組件維護經驗或者人力不足的團隊來講，是一個巨大挑戰。
b. 這實際上是一個應用治理的問題，服務，流程，規則，策略，數據，產物繁多，組織管理困難。 圖中任何一個框是一種服務，也可能是若干個服務，這些服務之間的依賴不直觀，很難管理。數據流邏輯繁瑣複雜，系統有很多的離線數據流，在線的數據流，還會產生大量數據產物，缺乏標準化的管理，極易出錯。不同場景的差異化難以組織，不同的服務，策略間相互影響，其中一個可能表現就是在一個服務模塊代碼中因爲要處理不同場景的邏輯而產生大量if分支邏輯。從架構上講，一個好的場景服務應該是縱向切分的，不同的場景是不同的系統，場景間互相隔離，但這又會導致系統資源浪費，管理上面也很麻煩。因此，需要採取更加系統化的方法去治理它。
c. 系統涉及到數據/在線/離線/AI各個領域，技術棧割裂，整個推薦流程需要大量的膠水代碼來整合集成。 而膠水代碼的一個特點就是難以複用，不同人之間也難以維護。這樣的割裂突出表現在以下三點：
- 衆多領域技術，彼此割裂，難以集成
- 數據質量難以保證，效果也無法保證
- 定製性膠水代碼驅動，無法複用，遷移
d. 大量重複程序化工作難以避免。 在面臨支持多個場景的情況下，表現很突出。落地一個新的場景，可能需要各個系統配合開發，部署，而且這個過程是高度重複和繁瑣的，最終導致成本很高。這也是現在大一點的公司，爲了效率和標準化，開始推動推薦系統中臺化建設的一個原因，其目的是能夠在一個平臺上低成本的完成場景的快速開發和應用。
上述這些問題的表現都可以用一個字來總結，那就是"亂"。
4. 如何戡"亂"
那麼我來講一講如何戡亂，首先我們深入分析一下亂的原因。
① "亂"的原因：
a. 智能系統特有的複雜性，涉及到龐大的服務依賴，數據依賴，知識依賴。 推薦系統涉及到的服務模塊很多，而一個服務又涉及多個依賴，整個服務的依賴關係就會很複雜，從而管理上就需要很大的成本。數據依賴層面，系統涉及到大量的原始攝取數據，中間加工數據，以及最終的結果服務數據，數據的質量對最終的推薦效果影響是至關重要的，而這種依賴又非常的隱含，極易出錯還難以排查。最後，特別提出"知識依賴"這一概念，推薦系統一直以來在應用系統中以其技術複雜性著稱，其在工程上，策略上，數據處理上，算法模型上，有很多模式經驗及潛在技能門檻。但這些知識在系統中是隱性的，存在於架構師、專家的腦袋裏面，並沒有固化和沉澱到系統內。強依賴架構師憑藉自己的認知和經驗去構建，驅動整個系統流程。而正是因爲是人來主導，那自然會隨着人的水平的高低以及偏好，產生實現上的差異，難以沉澱和繼承，後期持續演化也會很脆弱。
b. 領域架構缺失 現有的框架都在解決局部問題，需要抽象出一層專門解決推薦場景應用開發領域自身的問題。 比如Airflow是做離線任務調度領域的平臺工具，Flink是做數據處理領域相關的框架，這兩者都是各自領域很優秀的框架或平臺，但是要解決推薦領域的問題，他們都只能解決其中部分子領域問題，缺失一個面向推薦領域的一體化平臺或框架，其結果就是從業務問題直接穿透到子領域層，在實現上，缺乏抽象和隔離，使用膠水代碼將下層服務拼接在一起完成邏輯實現。雖然子領域框架能夠解決了一些局部問題，但它們之間如何協同，管理，以及在其之上更有序的解決推薦領域層面的業務問題成爲了如何讓架構更好服務場景業務的關鍵。所謂戡亂，就是需要形成一箇中間推薦場景開發的領域層，承接服務依賴，數據依賴，知識依賴，並協調子領域服務更有效工作。
② 這一層應當如何做？
a. 統一的場景開發和管理接口。 對於上層來講，開發一個"看了又看"，"買了又買"等不同的場景，開發過程和接口應該是相似的，只需要面向這一層開發，無需關注下層細節。
b. 統一的底層架構和集成標準。 下層非常複雜，涉及到衆多子領域，作爲開發者，常常在選型和集成上犯難，也無法將它們協調起來，那麼我們需要這一層能夠把複雜度給屏蔽掉，開發者面對的是統一的數據結構和接口規範，而無需關注具體的執行層選型和實現。
c. 領域內要素治理：
- 合適粒度的領域實體抽象及實現。在推薦服務中，有大大小小的服務，規則，策略及數據，我們稱之爲領域資源要素，它們需要有合適的領域抽象和粒度，粒度不能太大，也不能太小。是一個規則那麼我們就用規則去承載，如果是一個服務，那麼我們就應該用一個服務來承載。這樣能夠在提供靈活性的同時，控制整體複雜性
- 統一靈活的管理方式。我們需要針對領域要素有統一靈活的管理方式，領域的業務邏輯通過統一的編排管理方式來構建。
- 成熟可複用的單元。資源要素的載體是成熟可複用的單元，組件、策略等避免重新開發，產生重複的成本，應該通過複用讓使用者更低成本使用。
有幾個指導思想，來指導我們具體應該如何將這一層做好。
02 推薦系統"治理"的指導思想
1. "治理"的指導思想
① 聲明式 ( Declarative )： 解決複雜系統，複雜流程管理的靈丹妙藥。早期在沒有k8s的時候，微服務運維管理是一個複雜的過程，需要人工編寫很多的腳本完成應用的部署更新擴縮容等工作，使用者必須明確描述其所有操作細節。因爲相對於聲明式，這種過程命令式的運維腳本，需要使用的人要能夠掌控過程執行所有細節，這對於大型複雜系統來講是一個很大挑戰。聲明式編程的思想流行會使這樣的工作大大簡化，服務負責內部自身複雜運行邏輯，上層使用者只需要聲明出自己的目標即可，系統自動幫你完成，無需關注其達成目標的具體過程。就像SQL一樣，之所以大家用着覺得簡單，其很大原因是SQL就是一個聲明式的編程語言。這一思想已經逐步成爲架構師解決複雜系統管理的推薦思路。比如，當下很熱門的運維部署框架Ansible，運維人員只需要按要求編寫安裝部署劇本，系統就會自動安裝和部署相應的服務。
② 框架平臺： 在目標定位上，是開發一款工具，還是開發一個框架平臺，會直接影響到我們的系統設計決策。工具的特點是被集成，可以爲使用者提供更靈活有效的手段解決具體問題，但對於使用者本身有比較高的要求，最終結果如何，高度依賴使用的方式。而對於框架來講，將實現過程讓渡給框架，開發者無需瞭解全過程，只需要按照框架提供的規範進行開發即可，這一定程度約束了開發者的行爲，也降低了上手門檻，這實際上是依賴反轉思想的體現。我們提到的知識依賴，就可以通過框架或平臺把它們沉澱下來。而使用者自然會在框架的幫助下，使其開發的系統是相對可靠的。比如web開發框架Spring，亦或是持續集成平臺Jenkins，它們的作用就是提供一個領域業務模式或流程，能夠使得初學者只需要掌握平臺或框架的使用便能在其領域達到一個比較高的水平，獲得方法論指引，避免前人的錯誤。
③ 組件化： 其特點是標準化，複用性和靈活性。框架和它是依存關係，是它的契約，組件是按照契約去實現及被集成。
④ 低代碼 ( LowCode )： 特點是簡單，快速。當下比較熱門的概念，一個框架或者平臺，不需要寫代碼或者少寫代碼就能夠完成開發，是基於框架開發基礎上的更進一步，能夠將業務過程，核心邏輯封裝成一些低代碼的模塊，這對於簡單化業務過程，降低使用門檻有很大的幫助。
2. Flow Engine
基於上述的挑戰及解決思路，第四範式研發了這樣一個聲明式的、低代碼的、組件化的智能場景開發和管理的框架平臺。在這個框架基礎上可以快速開發和管理推薦等智能場景。
03 Flowengine架構
接下來簡單介紹一下Flowengine架構，它位於場景業務服務和子領域執行層之間。它的出現其目的便是將我們缺失的領域層補充上。
1. 表現
Flowengine提供了一套聲明式API，可用來創建，管理智能場景 ( 推薦 )，表現爲以下方面：
- 場景沉澱，遷移，快速構建。在框架無狀態的前提下，將應用邏輯，業務規則和服務依賴保存成一個方案文件，從而做到可以在不同的Flowengine平臺下無痛遷移分享。
- 領域要素 ( 組件，JOB，FUNC等 ) 的管理，集成，更新。提供要素的開發，發佈，集成，運行等全生命週期管理，使得其能夠在明確的標準下被集成和管理。
- 業務邏輯編排 ( 批/流/在線pipeline )。場景業務邏輯是對領域要素的邏輯編排，這就使得其天然具備敏捷性，業務上也能做到垂直切分隔離，卻共用相同的執行底層。在業務隔離和資源共享層面達成了統一。
- 預置核心組件及標準流程方案。簡單的業務可以通過已有方案自動的生成推薦服務，達到開箱即用的目的。如果存在場景差異也可以在此基礎上進行修改和完善，但修改過程僅僅發生在方案場景層面，從而有效的控制了修改風險蔓延，做到了框架與方案的分離，從而在易用性，規範性與靈活性，差異性上達成了統一，這個在傳統架構上是一個不可調和的矛盾。
- 標準化的底層集成方式，上層簡單，下層開放。標準化的底層集成方式，均採用業務組件或技術組件的方式集成，對上層呈現爲可被pipeline編排的資源要素，使用者無需關注執行層差異。這樣就保證了上層是接口簡單，下層是開放的。
2. 構成與基本實現
簡單說一下它的構成：
- Flowengine-Hub：用於存放方案，組件，FUNC/JOB等資源要素的倉庫。
- EngineManager：用來管理和監控引擎並作爲適配層屏蔽下層複雜度。
- EngineKernel：單個引擎的核心，用於管理當前引擎領域實體，業務流程，並提供運行環境及通信支持。
- Flowengine-Data：一個AI/BI爲一體的數據服務，用於管理引擎數據、元數據及對外提供統一的數據流服務。
基本實現：
- 基於k8s微服務管理。從大的架構上看，Flowengine是一個CloudNative架構，通過利用k8s的能力，實現了引擎內微服務的管理及動態化。一個引擎是由一個或者多個微服務共同組成，運行組件的標準格式是在docker鏡像基礎上再封裝而來，天然容器化友好。另外，在Docker和k8s的支撐下，框架對於基礎環境的複雜性有了很好的適應能力。
- 在計算引擎層面，集成了Spark，Flink以及自研的模型訓練 ( GDBT ) 等框架，通過進一步的集成優化，使得開發者無需關注這些框架的使用細節，通過統一的編程接口便能夠完成開發。
- 批流一體的數據流管理及元數據管理，引入數據攝取，加工，服務三個過程，抽象出一，二，三級表的抽象表概念，開發者無需關注數據的存儲和計算細節，採用統一的方式完成數據流開發，從而降低開發的複雜度及分散性。
- 業務編排框架。提供批，流，在線三大可視化業務編排能力，使得業務邏輯開發變成了無代碼的拖拉拽操作。另一方面，通過集中的編排管理及任務分發，解決了場景業務邏輯散落在各個執行組件中的問題。在引擎層便能夠管理業務全過程，這對於後期開發維護都大有幫助。
接下來我們介紹一下應用Flowengine之後的架構是什麼樣子的。
04 應用Flowengine後推薦的架構
1. 業務分解與技術映射
業務分解： 如圖，業務上一個推薦的場景大體是這樣的，它包含在線的業務流程，這一個流程大體可以分爲召回，過濾，粗排，精排等幾個部分，這裏通常會因爲業務過程的變化而變化。另一塊是數據處理及離線處理，這裏會有數據怎麼獲取，加工，以及提供給在線服務使用的邏輯。它也會隨着業務變化而變化。最後一部分，對於智能推薦，人工智能的作用舉足輕重，它包含數據接入處理，特徵工程，模型訓練，模型服務等多個過程，這其中也包含了離線和在線等諸多服務模塊。
技術映射： 那麼，對於上述分解出的三大業務部分，在Flowengine框架上如何映射呢？轉化到Flowengine上面，我們用引擎的概念來映射，一個推薦場景就是一個引擎，如圖，這個引擎我們可以起名叫reco-engine，這個引擎裏存在一個在線編排的pipeline叫reco-func-pipeline，而它就具備把推薦服務流程通過編排表達出來形成在線服務能力。Flowengine-Data支持數據的接入，它提供數據的攝取和服務的能力，比如說是kafka數據引入，ES或者Mysql的服務輸出，並提供數據表之間的處理能力，開發者只需要關注數據流本身的處理邏輯，而無需關注數據的存取和調度。而對於AI模型服務來講，它也是一個引擎，在引擎內部便能完成AI模型從開發到部署的全流程。場景引擎reco-engine只需要在需要模型服務時調用該AI引擎的服務即可。這樣我們一個推薦的場景就變成了一個主場景引擎及若干AI模型引擎構成，而它們的底層資源管理和調度都無需場景開發者關心。和我們之前講的傳統架構比，結構上清晰了許多，而這一切都歸功於必要的領域層抽象。
2. 帶來的價值
接下來我們總結一下應用了Flowengine之後帶來的價值：
- 面向Flowengine聲明業務過程，簡單，統一。聲明元數據，聲明編排過程。我們不需要管理執行層的具體細節，使得複雜度大大降低，業務過程也變得更加標準化。
- 服務及中間件數量減少，資源消耗減少，維護方便。推薦系統因爲業務上的發展，會增生很多小服務，這些服務管理麻煩，還佔用資源。比如說推薦系統一般會一個兜底的服務，定期生成靜態的推薦結果，用來在正常推薦響應失敗時降級出推薦結果。在Flowengine的支持下，可以通過創建一個離線的pipeline解決這類需求，那麼這樣的小服務就可以避免。
- 邏輯分層，合適的拆分粒度。服務，策略，腳本，配置都能夠合理安排，體現最小知識原則，其靈活性，複用性更強。
- 減少大量膠水代碼和重複代碼，串聯流程基於編排框架，無需再自己管理流程，聲明配置即可，低代碼，效率高，好管理。開發方案和使用方案分離，分工會更加清晰，也便於經驗及方法論傳遞。
- 場景縱向隔離，便於業務差異化發展，業務不能綁架技術，技術更不能綁架業務。在引擎層面做到相互隔離，一個引擎就是一個場景，開發，升級，變更都能夠互不影響。
- 服務運維，環境遷移部署更便利，CloudNative架構，無狀態設計，方案可導入導出。從解決思路上講，Docker解決了單一服務的遷移問題，而Flowengine解決場景的遷移問題。
最後給大家做一些實例的展示。
05 實例演示
Flowengine支持頁面、SDK和CLI多種操作方式。左側是引擎Web管理界面和CLI截圖。右側是一個應用方案包結構，包含了應用的定義meta_info.yaml以及依賴組件的定義。
下圖是Flowengine-data 的管理界面，可以管理數據表及數據攝取，加工，服務的處理過程。
最後是業務編排的操作界面。它包含離線編排，在線編排，流式編排。
06 總結
隨着智能場景越來越多，原來項目式，單點式的場景開發維護，必然導致整體研發成本的爆炸性增加。正如十來年前，web應用的大發展，催生了大量優秀的web開發框架一樣，智能場景應用的大發展也將會重演這樣的歷史。Flowengine正是我們在這一領域的探索，以我們對智能應用的架構理解，構建一套加速開發和運維過程的框架平臺，跟進未來的發展趨勢。
今天的分享就到這裏，謝謝大家。
作者介紹：
李瀚，第四範式平臺架構師
李瀚，第四範式先知平臺架構師，十餘年大型互聯網推薦，搜索系統架構設計開發經驗。負責業務產品的整體架構設計工作。目前重點聚焦在自研AI場景領域系統開發框架 ( FLowEngine ) 的設計研發及推薦，搜索等智能系統應用架構設計及落地。
本文來自 DataFunTalk
原文鏈接：