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