推薦系統(tǒng)是移動互聯(lián)網(wǎng)時代非常成功的人工智能技術(shù)落地場景之一。

本文我們將從架構(gòu)設(shè)計的角度回顧和討論推薦系統(tǒng)的一些核心算法模塊，重點從離線層、近線層和在線層三個架構(gòu)層面討論這些算法。

本文不會講解一些具體推薦模塊的架構(gòu)設(shè)計，但無論什么推薦模塊，其邏輯經(jīng)過拆解后都可以映射到本文的架構(gòu)體系中，做到觸類旁通，舉一反三。

-----

本文選自《從零開始構(gòu)建企業(yè)級推薦系統(tǒng)》一書，在龐雜的領(lǐng)域知識網(wǎng)格中點亮關(guān)鍵節(jié)點，為你的商業(yè)化落地開辟泛化通道。

架構(gòu)設(shè)計是一個很大的話題，本文這里只討論和推薦系統(tǒng)相關(guān)的部分。更具體地說，我們主要關(guān)注的是算法以及其他相關(guān)邏輯在時間和空間上的關(guān)系——這樣一種邏輯上的架構(gòu)關(guān)系。

下面介紹的是一些經(jīng)過實踐檢驗的架構(gòu)層面的最佳實踐，以及對這些最佳實踐在不同應(yīng)用場景下的分析。除此之外，還希望能夠通過把各種推薦算法放在架構(gòu)的視角和場景下重新審視，讓讀者大家對算法間的關(guān)系有更深入的理解，從全局的角度看待推薦系統(tǒng)，而不是只看到一個個孤立的算法。

架構(gòu)設(shè)計的本質(zhì)之一是平衡和妥協(xié)。一個推薦系統(tǒng)在不同的時期、不同的數(shù)據(jù)環(huán)境、不同的應(yīng)用場景下會選擇不同的架構(gòu)，在選擇時本質(zhì)上是在平衡一些重要的點。下面介紹幾個常用的平衡點。

▊ 個性化 vs 復(fù)雜度

個性化是推薦系統(tǒng)作為一個智能信息過濾系統(tǒng)的安身立命之本，從最早的熱榜，到后來的公式規(guī)則，再到著名的協(xié)同過濾算法，最后到今天的大量使用機(jī)器學(xué)習(xí)算法，其主線之一就是為用戶提供個性化程度越來越高的體驗，讓每個人看到的東西都盡量差異化，并且符合個人的喜好。為了達(dá)到這一目的，系統(tǒng)的整體復(fù)雜度越來越高，具體表現(xiàn)為使用的算法越來越多、算法使用的數(shù)據(jù)量和數(shù)據(jù)維度越來越多、機(jī)器學(xué)習(xí)模型使用的特征越來越多，等等。同時，為了更好地支持這些高復(fù)雜度算法的開發(fā)、迭代和調(diào)試，又衍生出了一系列對應(yīng)的配套系統(tǒng)，進(jìn)一步增加了整個系統(tǒng)的復(fù)雜度。可以說整個推薦邏輯鏈條上的每一步都被不斷地細(xì)化分析和優(yōu)化，這些不同維度的優(yōu)化橫縱交織，構(gòu)造出了一個整體復(fù)雜度非常高的系統(tǒng)。從機(jī)器學(xué)習(xí)理論的角度來類比，如果把推薦系統(tǒng)整體看作一個巨大的以區(qū)分用戶為目標(biāo)的機(jī)器學(xué)習(xí)模型，則可以認(rèn)為復(fù)雜度的增加對應(yīng)著模型中特征維度的增加，這使得模型的VC維不斷升高，對應(yīng)著可分的用戶數(shù)不斷增加，進(jìn)而提高了整個空間中用戶的個性化程度。這條通過不斷提高系統(tǒng)復(fù)雜度來提升用戶個性化體驗的路線，也是近年來推薦系統(tǒng)發(fā)展的主線之一。

▊ 時效性 vs 計算量

推薦系統(tǒng)中的時效性概念體現(xiàn)在實時服務(wù)的響應(yīng)速度、實時數(shù)據(jù)的處理速度以及離線作業(yè)的運行速度等幾個方面。這幾個速度從時效性角度影響著推薦系統(tǒng)的效果，整體上講，運行速度越快，耗時越少，得到的效果越好。這是因為響應(yīng)速度越快，意味著對用戶行為、物品信息變化的感知越快，感知后的處理速度越快，處理后結(jié)果的反饋就越快，最終體現(xiàn)到用戶體驗上，就是系統(tǒng)更懂用戶，更快地對用戶行為做出了反應(yīng)，從而產(chǎn)生了更好的用戶體驗。但這些時效性的優(yōu)化，帶來的是更大的計算量，計算量又對應(yīng)著復(fù)雜的實現(xiàn)邏輯和更多的計算資源。在設(shè)計得當(dāng)?shù)那疤嵯拢@樣的付出通常是值得的。

時效性優(yōu)化是推薦系統(tǒng)中非常重要的一類優(yōu)化方法和優(yōu)化思路，但由此帶來的計算壓力和系統(tǒng)設(shè)計的復(fù)雜度也是必須要面對的。

▊ 時間 vs 空間

時間和空間之間的平衡關(guān)系可以說是計算機(jī)系統(tǒng)中最為本質(zhì)的關(guān)系之一，在推薦系統(tǒng)中也不例外。時間和空間這一對矛盾關(guān)系在推薦系統(tǒng)中的典型表現(xiàn)，主要體現(xiàn)在對緩存的使用上。緩存通常用來存儲一些計算代價較高以及相對靜態(tài)變化較少的數(shù)據(jù)，例如用戶的一些畫像標(biāo)簽以及離線計算的相關(guān)性結(jié)果等。但是隨著越來越多的實時計算的引入，緩存的使用也越來越廣泛，常常在生產(chǎn)者和消費者之間起到緩沖的作用，使得二者可以解耦，各自異步進(jìn)行。例如實時用戶興趣計算這一邏輯，如果沒有將之前計算的興趣緩存起來，那么在每次需要用戶興趣時都要實時計算一次，并要求在較短的時間內(nèi)返回結(jié)果，這對計算性能提出了較高的要求。但如果中間有一層緩存作為緩沖，則需求方可以直接從緩存中取來結(jié)果使用。這在結(jié)果的實時性和新鮮度上雖然做了一定的妥協(xié)，但卻能給性能提升帶來極大的幫助。這樣就將生產(chǎn)和消費隔離開來，生產(chǎn)者可以根據(jù)具體情況選擇生產(chǎn)的方式和速度。當(dāng)然，仍然可以努力提高生產(chǎn)速度，生產(chǎn)速度越快，緩存給時效性帶來的損失就越小，消費者不做任何改動就可以享受到這一提升效果。所以說，這種利用緩存來解耦系統(tǒng)，帶來性能上的提升以及開發(fā)的便利，也是在推薦系統(tǒng)架構(gòu)設(shè)計中需要掌握的一種通用的思路。

上面介紹的一些基本性原則貫穿著推薦系統(tǒng)架構(gòu)設(shè)計的方方面面，是一些具有較高通用性的思路，掌握這些思路，可以產(chǎn)生出很多具體的設(shè)計和方法；反過來，每一種設(shè)計技巧或方法，也都可以映射到一個或幾個這樣的高層次抽象原則上來。這種自頂向下的思維學(xué)習(xí)方法對于推薦系統(tǒng)的架構(gòu)設(shè)計是非常重要的，并且可以推廣到很多其他系統(tǒng)的設(shè)計中。

架構(gòu)設(shè)計的第一步是確定系統(tǒng)的邊界。

所謂邊界，就是區(qū)分什么是這個系統(tǒng)要負(fù)責(zé)的，也就是邊界內(nèi)的部分，以及什么是這個模型要依賴的，也就是邊界外的部分。劃分清楚邊界，意味著確定了功能的邊界以及團(tuán)隊的邊界，能夠讓后期的工作都專注于核心功能的設(shè)計和實現(xiàn)。反之，如果系統(tǒng)邊界沒有清晰的定義，可能會在開發(fā)過程中無意識地侵入其他系統(tǒng)中，形成冗余甚至矛盾，或者默認(rèn)某些功能別人會開發(fā)而將其忽略掉。無論哪種情況，都會影響系統(tǒng)的開發(fā)乃至最終的運轉(zhuǎn)。

系統(tǒng)邊界的確定，簡單來說，就是在輸入方面確定需要別人給我提供什么，而在輸出方面確定我要給別人提供什么。

在輸入方面，就是判斷什么輸入是需要別人提供給我的，要把握的主要原則包括：

• 這個數(shù)據(jù)或服務(wù)是否與我的業(yè)務(wù)強(qiáng)相關(guān)

• 這個數(shù)據(jù)或服務(wù)除了我的業(yè)務(wù)在使用，是否還有其他業(yè)務(wù)也在使用

依照此原則，下圖展示了推薦系統(tǒng)的主要外部依賴。

▊ 1、 數(shù)據(jù)依賴

推薦系統(tǒng)作為一個典型的數(shù)據(jù)算法系統(tǒng)，數(shù)據(jù)是其最重要的依賴。這里面主要包括用戶行為數(shù)據(jù)和物品數(shù)據(jù)兩大類，前面介紹的各種算法幾乎都是以這兩種數(shù)據(jù)作為輸入進(jìn)行計算的。這些數(shù)據(jù)除了為推薦系統(tǒng)所用，它們也是搜索、展示等其他重要系統(tǒng)的輸入數(shù)據(jù)，所以作為通用的公共數(shù)據(jù)和服務(wù)，顯然不應(yīng)該在推薦系統(tǒng)的邊界內(nèi)部，而應(yīng)該是外部依賴。需要特別指出的是，雖然有專門的團(tuán)隊負(fù)責(zé)行為數(shù)據(jù)的收集，但是收集到的數(shù)據(jù)是否符合推薦系統(tǒng)的期望卻不是一件可以想當(dāng)然的事情。例如，對于結(jié)果展示的定義，數(shù)據(jù)收集團(tuán)隊認(rèn)為前端請求到了結(jié)果就是展示，但對于推薦系統(tǒng)來說，只有用戶真正看見了才是真實的展示。其中的原因在于數(shù)據(jù)收集團(tuán)隊并不直接使用數(shù)據(jù)，那么他們就無法保證數(shù)據(jù)的正確性，這時就需要具體使用數(shù)據(jù)的業(yè)務(wù)方，在這里是推薦團(tuán)隊，來和他們一起確認(rèn)數(shù)據(jù)收集的邏輯是正確的。如果數(shù)據(jù)收集的邏輯不正確，后面的算法邏輯就是在做無用功。花在確保數(shù)據(jù)正確上的精力和資源，幾乎總是有收益的。

▊ 2、平臺工具依賴

推薦系統(tǒng)是一個計算密集型的系統(tǒng)，需要對各種形態(tài)的數(shù)據(jù)做各種計算處理，在此過程中，需要一整套計算平臺工具的支持，典型的如機(jī)器學(xué)習(xí)平臺、實時計算平臺、離線計算平臺、其他平臺工具等。在一個較為理想的環(huán)境中，這些平臺工具都是由專門的團(tuán)隊來構(gòu)建和維護(hù)的。而在一些場景下，推薦系統(tǒng)可能是整個組織中最早使用這些技術(shù)的系統(tǒng)，推薦業(yè)務(wù)也還沒有重要和龐大到需要老板專門配備一個平臺團(tuán)隊為之服務(wù)的程度，在這種情況下，其中的一些平臺工具就需要推薦系統(tǒng)的團(tuán)隊自己負(fù)責(zé)來構(gòu)建和維護(hù)了。為了簡化邏輯，下面我們假設(shè)這些平臺工具都是獨立于推薦系統(tǒng)存在的，屬于推薦系統(tǒng)的外部依賴。

在對外輸出方面，系統(tǒng)邊界的劃定會根據(jù)公司組織的不同有所差異。例如，在一些公司中，推薦團(tuán)隊負(fù)責(zé)的是與推薦相關(guān)的整個系統(tǒng)，在輸出方面的體現(xiàn)就是從算法邏輯到結(jié)果展示，這時候系統(tǒng)的邊界就要延伸到最終的結(jié)果展示。而在另外一些公司中，前端展示是由一個大團(tuán)隊統(tǒng)一負(fù)責(zé)的，這時候推薦系統(tǒng)只需要給出要展示的物品ID和相關(guān)展示信息即可，前端團(tuán)隊會負(fù)責(zé)統(tǒng)一展示這些物品信息。這兩種模式?jīng)]有絕對的好壞之分，重要的是要與整個技術(shù)團(tuán)隊的規(guī)劃和架構(gòu)相統(tǒng)一。在本書中，為了敘述簡便，我們不討論前端展示涉及的內(nèi)容，只專注于推薦結(jié)果的生產(chǎn)邏輯。

推薦系統(tǒng)的效果和性能在一定程度上取決于這些依賴系統(tǒng)，所以在尋求推薦系統(tǒng)的優(yōu)化目標(biāo)時，目光不能只看到推薦系統(tǒng)本身，很多時候這些依賴系統(tǒng)也是重要的效果提升來源。例如，物品信息的變更如果能被更快地通知到推薦系統(tǒng)，那么推薦系統(tǒng)的時效性就會更好，給到用戶的結(jié)果也就會更好；再如，用戶行為數(shù)據(jù)收集的準(zhǔn)確性能有所提高的話，對應(yīng)的相關(guān)性算法的準(zhǔn)確性也會隨之提高。在有些情況下，外部系統(tǒng)升級會比優(yōu)化算法有更大的效果提升。當(dāng)然，推薦系統(tǒng)的問題也可能來自這些外部的依賴系統(tǒng)。例如，前端渲染展示速度的延遲會導(dǎo)致用戶點擊率的顯著下降，因為這會讓用戶失去耐心。所以，當(dāng)推薦系統(tǒng)指標(biāo)出現(xiàn)下降時，不光要從內(nèi)部找問題，也要把思路拓展到系統(tǒng)外部，從全局的角度去找問題。綜合來講，外部依賴的存在啟發(fā)我們要從全鏈條、全系統(tǒng)的角度來看問題，找問題，以及設(shè)計優(yōu)化方法。

架構(gòu)設(shè)計有很多不同的切入方式，最簡單也是最常用的一種方式就是先決定某個模塊或邏輯是運行在離線層、在線層還是近線層。這三層的對比如下。

近線層則處于離線層和在線層的中間位置，是一個比較奇妙的層。這一層的典型特點就是：使用實時數(shù)據(jù)（也會使用非實時數(shù)據(jù)），但不提供實時服務(wù)，而是提供一種近實時的服務(wù)。所謂近實時指的是越快越好，但并不強(qiáng)求像在線層一樣在幾十毫秒內(nèi)給出結(jié)果，因為通常在近線層計算的結(jié)果會寫入緩存系統(tǒng)，供在線層讀取，做了一層隔離，因此對時效性無強(qiáng)要求。其典型代表是我們前面講過的實時協(xié)同過濾算法，該算法通過用戶的實時行為計算最新的相關(guān)性結(jié)果，但這些計算結(jié)果并不是實時提供給用戶的，而是要等到用戶發(fā)起請求時才會把最新的結(jié)果提供給他使用。

下面詳細(xì)介紹每一層的特點、案例和具體分析。

離線層是推薦系統(tǒng)中承擔(dān)最大計算量的一個部分，很大一部分的相關(guān)性計算、標(biāo)簽挖掘以及用戶畫像挖掘工作都是在這一層進(jìn)行的。這一層的任務(wù)具有的普遍特點是使用大量數(shù)據(jù)以及較為復(fù)雜的算法進(jìn)行計算和挖掘。所謂大量數(shù)據(jù)，通常指的是可以使用較長時間段的用戶行為數(shù)據(jù)和全量的物品數(shù)據(jù)；而在算法方面，可以使用較為復(fù)雜的模型或算法，對性能的壓力相對較小。對應(yīng)地，離線層的任務(wù)也有缺點，就是在時間上存在滯后性。由于離線任務(wù)通常是按天級別運行的，用戶行為或物品信息的變更也要等一天甚至更久才能夠被反映到計算結(jié)果中。在離線層雖然進(jìn)行的是離線作業(yè)，但其生產(chǎn)出來的數(shù)據(jù)通常是被實時使用的，因此離線數(shù)據(jù)在生產(chǎn)出來之后還需要同步到方便在線層讀取的地方，例如數(shù)據(jù)庫、在線緩存等。

在具體實踐中，經(jīng)常放在離線層執(zhí)行的任務(wù)主要包括：協(xié)同過濾等行為類相關(guān)性算法計算、用戶標(biāo)簽挖掘、物品標(biāo)簽挖掘、用戶長期興趣挖掘、機(jī)器學(xué)習(xí)模型排序等。仔細(xì)分析這些任務(wù)，會發(fā)現(xiàn)它們都符合上面提到的特點。這些任務(wù)的具體流程各不相同，但大體上都遵循一個共同的邏輯流程。

離線層邏輯架構(gòu)圖

在這個邏輯架構(gòu)圖中，離線算法的數(shù)據(jù)來源主要有兩大類：一類是HDFS/Hive這樣的分布式文件系統(tǒng)，通常用來存儲收集到的用戶行為日志以及其他服務(wù)器日志；另一類是RDBMS這樣的關(guān)系數(shù)據(jù)庫，通常用來存儲商品等物品信息。離線算法會從輸入數(shù)據(jù)源獲取原始數(shù)據(jù)并進(jìn)行預(yù)處理，例如，協(xié)同過濾算法會先把數(shù)據(jù)處理成兩個倒排表，LDA算法會先對物品文本做分詞處理，等等，我們將預(yù)處理后的數(shù)據(jù)統(tǒng)一稱為訓(xùn)練數(shù)據(jù)（雖然有些離線算法并不是機(jī)器學(xué)習(xí)算法）。預(yù)處理這一步值得單獨拿出來講，這是因為很多算法用到的預(yù)處理是高度類似的，例如，文本標(biāo)簽類算法需要先對原始文本進(jìn)行分詞或詞性標(biāo)注，行為類相關(guān)性算法需要先將行為數(shù)據(jù)按用戶聚合，點擊率模型需要先將數(shù)據(jù)按照點擊/展示進(jìn)行聚合整理，等等。所以在設(shè)計離線挖掘的整體架構(gòu)時，有必要有針對性地將數(shù)據(jù)預(yù)處理流程單獨提煉出來，以方便后面的流程使用，做到更好的可擴(kuò)展性和可復(fù)用性。下一步是各種推薦算法或機(jī)器學(xué)習(xí)模型基于各自的訓(xùn)練數(shù)據(jù)進(jìn)行挖掘計算，得到挖掘結(jié)果。離線計算用到的工具通常包括Hadoop、Spark等，結(jié)果可能是一份協(xié)同過濾相關(guān)性數(shù)據(jù)，可能是物品的文本主題特征，也可能是結(jié)果排序模型。接下來，為了讓挖掘結(jié)果能夠被后面的流程所使用，需要將挖掘結(jié)果同步到不同的存儲系統(tǒng)中。一般來說，如果挖掘結(jié)果要被用作下游離線流程的輸入，是一份中間結(jié)果，那么通常它會被再次同步到Hive或HDFS這樣的分布式文件系統(tǒng)中；如果挖掘結(jié)果要被最終的推薦服務(wù)在線實時使用，那么它就需要被同步到Redis或RDBMS這樣對實時訪問更為友好的存儲系統(tǒng)中。至此，一個完整的離線挖掘流程就完成了。

上面講到離線任務(wù)通常以天為單位來執(zhí)行，但是在很多情況下，提高作業(yè)的運行頻率以及對應(yīng)的數(shù)據(jù)同步頻率，例如從一天一次提升到一天多次，都會對推薦系統(tǒng)的效果有提升作用，因為這些都可以被理解為在做時效性方面的優(yōu)化。一種極限的思想是，當(dāng)我們把作業(yè)的運行頻率提高到極致時，例如每分鐘甚至每幾秒鐘運行一次作業(yè)，離線任務(wù)就變成了近線任務(wù)。當(dāng)然，在這種情況下就需要對離線算法做相應(yīng)的修改以適應(yīng)近線計算的要求，例如前面介紹過的實時協(xié)同過濾算法就是對原始協(xié)同過濾算法的修改，以及將機(jī)器學(xué)習(xí)的模型訓(xùn)練過程從離線改為在線。

所以，雖然我們會把某些任務(wù)放到離線層來執(zhí)行，但并不代表這些任務(wù)就只能是離線任務(wù)。我們要深入理解為什么將這些任務(wù)放在離線層來執(zhí)行，在什么情況下可以提高其運行頻率，甚至變?yōu)榻€任務(wù)，以及這樣做的好處和代價是什么。只有做到這一點，才能夠做到融會貫通，不被當(dāng)前的表象迷住眼睛。一種典型的情況是，當(dāng)實時計算或流計算平臺資源不足，或者開發(fā)人力資源不足時，我們傾向于把更多的任務(wù)放到離線層來執(zhí)行，因為離線計算對時效性要求較低，出錯之后影響也較小。綜合來說，就是容錯度較高，適合在整體資源受限的情況下優(yōu)先選擇。而隨著平臺的不斷完善，以及人力資源的不斷補(bǔ)充，就可以把一些對時效敏感的任務(wù)放到近線層來執(zhí)行，以獲得更好的收益。

有了上面的鋪墊，近線層的存在理由和價值就比較明確了，從生產(chǎn)力發(fā)展的角度來看，可以認(rèn)為它是實時計算平臺工具發(fā)展到一定程度對離線計算的自然改造；而從推薦系統(tǒng)需求的角度來看，它是各種推薦算法追求實時化效果提升的一種自然選擇。

近線層和離線層最大的差異在于，它可以獲取到實時數(shù)據(jù)，并有能力對實時數(shù)據(jù)進(jìn)行實時或近實時的計算。也正是由于這個特點，近線層適合用來執(zhí)行對時效比較敏感的計算任務(wù)，例如實時的數(shù)據(jù)統(tǒng)計等，以及實時執(zhí)行能夠獲得較大效果提升的任務(wù)，例如一些實時的相關(guān)性算法計算或標(biāo)簽提取算法計算。近線層在計算時可使用實時數(shù)據(jù)，也可使用離線生成的數(shù)據(jù)，在提供服務(wù)時，由于無須直接響應(yīng)用戶請求，因此也不用提供實時服務(wù)，而是通常會將數(shù)據(jù)寫入對實時服務(wù)友好的在線緩存中，方便實時服務(wù)讀取，同時也會同步到離線端做備份使用。

通常放在近線層執(zhí)行的任務(wù)包括實時指標(biāo)統(tǒng)計、用戶的實時興趣計算、實時相關(guān)性算法計算、物品的實時標(biāo)簽挖掘、推薦結(jié)果的去重、機(jī)器學(xué)習(xí)模型統(tǒng)計類特征的實時更新、機(jī)器學(xué)習(xí)模型的在線更新等，這些任務(wù)通常會以如下兩種方式進(jìn)行計算。

個體實時：所謂個體實時，指的是每個實時數(shù)據(jù)點到來時都會觸發(fā)一次計算，做到真正意義上的實時。典型的工具代表是Storm和Flink。

批量實時：很多時候并不需要到來一個實時數(shù)據(jù)點就計算一次，因為這會帶來大量的計算和I/O，而是可以將一定的時間窗口或一定數(shù)量的數(shù)據(jù)收集起來，以小批次為單位進(jìn)行計算，這可以有效減少I/O量。這種妥協(xié)對于很多應(yīng)用來說，只要時間窗口不太大，就不會帶來效果的顯著下降。典型的工具代表是Spark Streaming。

下面展示了典型的近線層計算架構(gòu)圖。

從數(shù)據(jù)源接入的角度來看，近線層主要使用實時數(shù)據(jù)進(jìn)行計算，這就引出了近線層和離線層的一個主要區(qū)別：近線層的計算通常是事件觸發(fā)的，而離線層的計算通常是時間觸發(fā)的。事件觸發(fā)意味著對計算擁有更多的主動權(quán)和選擇權(quán)，但時間觸發(fā)則無法主動做出選擇。事件觸發(fā)意味著每個事件發(fā)生之后都會得到通知，但是否要計算以及計算什么是可以自己選擇的。例如，可以選擇只捕捉滿足某種條件的事件，或者等事件累積到一定程度時再計算，等等。所以，當(dāng)某個任務(wù)的觸發(fā)條件是某個事件發(fā)生之后進(jìn)行計算，那么這個任務(wù)就很適合放在近線層來執(zhí)行。例如推薦結(jié)果的去重，需要在用戶瀏覽過該物品之后將其加入一個去重集合中，這就是一個典型的事件觸發(fā)的計算任務(wù)。此外，近線層的計算是可以使用離線數(shù)據(jù)的，但前提是需要提前將這些數(shù)據(jù)同步到對實時計算友好的存儲系統(tǒng)中。

在近線層中執(zhí)行的典型任務(wù)包括但不限于：

• 特征的實時更新。例如，根據(jù)用戶的實時點擊行為實時更新各維度的點擊率特征。
• 用戶實時興趣的計算。根據(jù)用戶實時的喜歡和不喜歡行為計算其當(dāng)下實時興趣的變化。
• 物品實時標(biāo)簽的計算。例如，在第6章用戶畫像系統(tǒng)中介紹過的實時提取標(biāo)簽的流程。
• 算法模型的在線更新。通過實時消息隊列接收和拼接實時樣本，采用FTRL等在線更新算法來更新模型，并將更新后的模型推送到線上。
• 推薦結(jié)果的去重。用戶兩次請求之間是有時間間隔的，所以無須在處理實時請求時進(jìn)行去重，而是可以將這個信息通過消息隊列發(fā)送給一個專門的服務(wù)，在近線層中處理。

• 實時相關(guān)性算法計算。典型的如實時協(xié)同過濾算法，按照其原理，也可以把隨機(jī)游走等行為類算法改寫為實時計算，放到近線層中執(zhí)行。

總結(jié)起來，凡是可以和實時請求解耦，但需要實時或近實時計算結(jié)果的任務(wù)，都可以放到近線層中執(zhí)行。

近線層的實時計算雖然沒有響應(yīng)時間的要求，但卻存在數(shù)據(jù)堆積的壓力。具體來說，近線層計算用到的數(shù)據(jù)大部分是通過Kafka這樣的消息隊列實時發(fā)送過來的，在接收到每一個消息或消息窗口之后，如果對消息或消息窗口的計算速度不夠快，就會導(dǎo)致后面的消息堆積。這就像大家都在排隊辦理業(yè)務(wù)，如果一個業(yè)務(wù)辦理得太慢，那么排的隊就會越來越長，長到一定程度就會出問題。所以，近線層的計算邏輯不宜過于復(fù)雜，而且近線層讀取的外部數(shù)據(jù)，例如離線同步好的Redis中的數(shù)據(jù)，也不宜過多，還有I/O次數(shù)不宜過多。這就要求近線層的計算邏輯和用到的數(shù)據(jù)結(jié)構(gòu)都要經(jīng)過精心的設(shè)計，共同保證近線層的計算效率，以免造成數(shù)據(jù)堆積。

除了純數(shù)據(jù)統(tǒng)計類型的任務(wù)，以及結(jié)果去重這樣的無數(shù)據(jù)產(chǎn)出的任務(wù)，近線層的大多數(shù)任務(wù)在離線層都有對應(yīng)的部分，二者有著明顯的優(yōu)勢和劣勢，因此應(yīng)該結(jié)合起來使用。典型的如實時協(xié)同過濾算法，由于引入了實時性，使得它在一些新物品和新用戶上的效果比原始的協(xié)同過濾算法的效果好；但由于它只使用實時數(shù)據(jù)，所以在稀疏性和不穩(wěn)定性方面的問題也是比較大的，要使用離線版本的協(xié)同過濾算法作為補(bǔ)充，才能形成更全面的覆蓋。再比如在近線層執(zhí)行的用戶實時興趣預(yù)測，能夠捕捉到用戶最新鮮的興趣，準(zhǔn)確率會比較高；但由于短期興趣易受展示等各種因素影響發(fā)生較大的波動，如果完全根據(jù)短期興趣來進(jìn)行推薦的話，則很有可能會陷入局部的信息繭房，產(chǎn)生高度同質(zhì)的結(jié)果，影響用戶的整體體驗。而如果將離線計算的長期興趣和短期興趣相結(jié)合，就可以有效避免這個問題，既能利用實時數(shù)據(jù)取得高相關(guān)性，又能利用長期數(shù)據(jù)取得穩(wěn)定性和多樣性。從這些例子可以看出，離線層和近線層之間并沒有不可逾越的鴻溝，二者更多的是在效率、效果、穩(wěn)定性、稀疏性等多個因素之間進(jìn)行權(quán)衡得到的不同選擇，一個優(yōu)秀的工程師應(yīng)該做到“碼中有層，心中無層”，才算是對算法和架構(gòu)做到了融會貫通。

上面講到離線層的任務(wù)在一定條件下可以放到近線層來執(zhí)行，那么類似地，近線層的任務(wù)是否可以放到在線層來執(zhí)行呢？這個問題其實涉及離線層、近線層這兩層作為整體和在線層的關(guān)系。如果把推薦系統(tǒng)比作一支打仗的軍隊，那么在線層就是在前方?jīng)_鋒陷陣的士兵，直接面對敵人的攻擊，而離線層和近線層就是提供支持的支援部門，離線層就像是生產(chǎn)糧食和軍火的大后方，近線層就像是搭橋修路的前方支援部門，二者的本質(zhì)都是讓前線士兵能夠最高效、最猛烈地打擊敵人，但其業(yè)務(wù)本質(zhì)導(dǎo)致它們無法到前線去殺敵。離線層和近線層是推薦系統(tǒng)的生產(chǎn)者，在線層是推薦系統(tǒng)的消費者（也會承擔(dān)一定的生產(chǎn)責(zé)任），它們有著截然不同的分工和定位，是無法互換的。

在線層與離線層、近線層最大的差異在于，它是直接面對用戶的，所有的用戶請求都會發(fā)送到在線層，而在線層需要快速給出結(jié)果。如果抽離掉其他所有細(xì)節(jié)，這就是在線層最本質(zhì)的東西。在線層最本質(zhì)的東西并不是在線計算部分，因為在極端情況下，在接收到用戶請求之后，在線層可以直接從緩存或數(shù)據(jù)庫中取出結(jié)果，返回給用戶，而不做任何額外計算。而事實上，早年還沒有引入機(jī)器學(xué)習(xí)等復(fù)雜的算法技術(shù)時，絕大多數(shù)計算都是在離線層進(jìn)行的，在線層就起到一個數(shù)據(jù)傳遞的作用，很多推薦系統(tǒng)基本都是這么做的，甚至?xí)r至今日，這種做法仍然是一種極端情況下的降級方案。

推薦系統(tǒng)發(fā)展到現(xiàn)在，尤其是各種機(jī)器學(xué)習(xí)算法的引入，使得我們可以使用的信息越來越多，可用的算法也越來越復(fù)雜，給用戶的推薦結(jié)果通常是融合了多種召回策略，并且又加了重排序之后的結(jié)果，而融合和重排序現(xiàn)在通常是在在線層做的。那么問題來了：這些復(fù)雜計算一定要放到在線層做嗎？為了回答這個問題，不妨假設(shè)：如果將所有計算都放在離線層做，在線層只負(fù)責(zé)按照用戶ID查詢返回結(jié)果，是否可行？如果將所有計算都放在離線層做，由于不知道明天會有哪些用戶來訪問系統(tǒng)，所以就需要為每個用戶都計算出推薦結(jié)果，這要求我們計算出全平臺所有用戶的推薦結(jié)果，而對于那些明天沒有來訪問系統(tǒng)的用戶，今天的計算就浪費掉了。但這仍然不夠，因為明天還會有新來的用戶，這些用戶的信息在當(dāng)前計算時是拿不到的，所以，即使今天離線計算出了所有當(dāng)前用戶的推薦結(jié)果，明天也還會有大量覆蓋不到的用戶。這就是將上面提到的復(fù)雜計算一定要放在在線層做的第一個主要原因：只有按需實時計算才能覆蓋到所有用戶，并且不會產(chǎn)生計算的浪費。從另一個角度來看，如果今天就把用戶的推薦結(jié)果完全計算出來，若用戶明天的實時行為表達(dá)出來的興趣和今天的不相符，或者機(jī)器學(xué)習(xí)模型中一些關(guān)鍵特征的取值發(fā)生了變化，那么推薦結(jié)果就會不準(zhǔn)確，并且無法及時調(diào)整。例如，用戶昨天看的是手機(jī)，今天打算買衣服，但我們昨天計算出的推薦結(jié)果是以手機(jī)為主的，那么用戶今天的需求是無法滿足的。這就是需要在在線層做復(fù)雜計算的第二個主要原因：只有在線實時計算，才能夠充分利用用戶的實時信息，包括實時興趣、實時特征以及其他近線層計算的結(jié)果等。除此以外，還有其他原因，比如實時處理可以快速應(yīng)對實時發(fā)生的業(yè)務(wù)請求等。以上這些原因共同決定了在線層存在的意義。

從目前的趨勢來看，在線層承擔(dān)的工作越來越多，因為大家希望利用的信息越來越多地來自實時計算結(jié)果。如果說離線層和近線層是廚房里的小工，負(fù)責(zé)一切食材和配料的前期準(zhǔn)備工作，那么在線層就是最后掌勺的大廚，它需要將大家準(zhǔn)備好的材料進(jìn)行組合裝配，最終形成一盤菜。

在線層的典型形態(tài)是一個RESTful API，對外提供服務(wù)。調(diào)用方傳入的參數(shù)在不同公司的設(shè)計中差異較大，但基本都會包含訪問用戶的ID標(biāo)識和推薦場景這兩個核心信息，其他信息推薦系統(tǒng)都可以通過這兩個信息從其他地方獲取到。在線層接收到請求后會啟動一套流程，將離線層和近線層生成的數(shù)據(jù)進(jìn)行串聯(lián)，在毫秒級響應(yīng)時間內(nèi)返回給調(diào)用方。這套流程的典型步驟包括：

• AB實驗分流

根據(jù)用戶ID或請求ID，決定當(dāng)前用戶要執(zhí)行的策略版本。

• 獲取用戶畫像

根據(jù)傳入的用戶ID信息和場景信息，從Redis等緩存中獲取用戶的畫像信息，用在后面的流程中。

• 相關(guān)性候選集召回

包括行為相關(guān)性、內(nèi)容相關(guān)性、上下文相關(guān)性、冷啟動物品等多維度候選集的召回。

• 候選集融合排序

將上面流程得到的候選集進(jìn)行融合，再進(jìn)一步進(jìn)行機(jī)器學(xué)習(xí)模型排序，最后得到在算法上效果最優(yōu)的結(jié)果列表。在當(dāng)今推薦系統(tǒng)大量使用機(jī)器學(xué)習(xí)算法的背景下，這一部分的邏輯通常會比較復(fù)雜。而為了將機(jī)器學(xué)習(xí)模型預(yù)測這一越來越通用的邏輯和推薦主邏輯相剝離，通常也會為機(jī)器學(xué)習(xí)專門搭建一套在線系統(tǒng)，用來提供預(yù)測功能，包括對推薦結(jié)果的點擊、轉(zhuǎn)化預(yù)測。這樣做的好處是機(jī)器學(xué)習(xí)模型的升級改造不會干擾到推薦系統(tǒng)本身，有利于模塊化維護(hù)。

• 業(yè)務(wù)邏輯干預(yù)

在完成算法邏輯之前或之后，還需要加入一些業(yè)務(wù)邏輯，例如去除或減少某些類別的物品，或者出于業(yè)務(wù)考慮插入一些在算法上非最優(yōu)的結(jié)果，等等。

• 拼接展示信息

在一些推薦系統(tǒng)中，推薦服務(wù)要負(fù)責(zé)將展示所需的所有信息集成到一起，這樣調(diào)用方拿到結(jié)果后就可以直接展示了，而不需要再去獲取其他內(nèi)容。這看起來是一個負(fù)擔(dān)，但從某些角度來看也是好事，因為我們可以做一些展示層面的個性化，典型的如根據(jù)不同的用戶展示不同的圖片或標(biāo)題，要知道展示層對于用戶是否對物品感興趣是起著非常重要的作用的，畢竟這是一個處處看臉的時代。Netflix就做過劇集封面?zhèn)€性化的嘗試，相比給所有人展示同樣的封面，個性化封面使得在用戶點擊方面獲得了顯著的提升。

在這套流程中，本書前面介紹過的相關(guān)性算法的結(jié)果、用戶畫像的結(jié)果、用戶興趣模型的結(jié)果等都會被串聯(lián)起來。

這套流程對應(yīng)的在線層服務(wù)架構(gòu)圖如下。

在上圖中不僅呈現(xiàn)了在線服務(wù)層的流程架構(gòu)，而且還把它所依賴的數(shù)據(jù)和服務(wù)也一并呈現(xiàn)出來，這樣可以最直接地體現(xiàn)在線層“主廚”的串聯(lián)作用。最上面一層在線服務(wù)層的流程體現(xiàn)了上面介紹的在線層的典型計算流程。下面所依賴的數(shù)據(jù)平臺，包含了推薦服務(wù)用到的所有數(shù)據(jù)，如相關(guān)性數(shù)據(jù)、用戶畫像數(shù)據(jù)、用戶興趣數(shù)據(jù)，以及與機(jī)器學(xué)習(xí)相關(guān)的模型和特征數(shù)據(jù)等。這些數(shù)據(jù)又是通過下面的計算平臺這一層生成的，包括離線層的計算平臺和近線層的計算平臺。這些計算平臺所使用的數(shù)據(jù)構(gòu)成了整個推薦系統(tǒng)的數(shù)據(jù)源，主要包括：物品數(shù)據(jù)源、行為數(shù)據(jù)源和外部數(shù)據(jù)源。

這個架構(gòu)圖從數(shù)據(jù)和計算的角度對推薦系統(tǒng)做了分割，跟之前講的離線層和近線層的分割方法是兩種不同的視角，相互正交。經(jīng)常從不同的視角去抽象、剝離一個系統(tǒng)，有助于我們更全面、更深刻地認(rèn)識系統(tǒng)。在復(fù)雜系統(tǒng)面前，我們的認(rèn)識過程就像盲人摸象，需要不斷地從新的視角去看待理解它，才能得到更全面的認(rèn)識。

在介紹完離線層、近線層和在線層的架構(gòu)之后，我們通過下表對它們進(jìn)行更全面的對比。

上表基本上列出了推薦系統(tǒng)的所有主要模塊在架構(gòu)中的位置，建議讀者從架構(gòu)的視角對其算法進(jìn)行回顧，以加深對它們的理解。

-------

希望工程師在設(shè)計和實現(xiàn)算法時，腦子里除了有算法和數(shù)據(jù)，還應(yīng)多一個架構(gòu)的維度，能夠從架構(gòu)工程的角度來考慮算法，做到心中有系統(tǒng)，而不只是一些零散推薦算法的實現(xiàn)，這樣才能構(gòu)建好一個推薦系統(tǒng)。

（完）

《從零開始構(gòu)建企業(yè)級推薦系統(tǒng)》是一本面向?qū)嵺`的企業(yè)級推薦系統(tǒng)開發(fā)指南，可以幫助開發(fā)者逐步構(gòu)建一個完整的推薦系統(tǒng)，并提供了持續(xù)優(yōu)化的系統(tǒng)性思路。

《從零開始構(gòu)建企業(yè)級推薦系統(tǒng)》

張相於 著

• 舉一綱而萬目張，解一卷而眾篇明

本書旨在與龐雜的領(lǐng)域知識網(wǎng)格中點亮關(guān)鍵節(jié)點，為讀者的商業(yè)化落地開辟泛化通道。

• 注重零啟動、全流程、成系統(tǒng)、通用化

用整體、全局思維將商業(yè)級推薦系統(tǒng)涉及的算法、模塊、架構(gòu)與相關(guān)性鏈條全線貫通。

• 國內(nèi)首批實踐商業(yè)化推薦的老江湖

從當(dāng)當(dāng)、轉(zhuǎn)轉(zhuǎn)到阿里，十年知名電商企業(yè)主導(dǎo)推薦系統(tǒng)研發(fā)和帶領(lǐng)相關(guān)算法團(tuán)隊經(jīng)驗。

• 產(chǎn)品邏輯、數(shù)據(jù)、算法、架構(gòu)四大體系

用真實案例覆蓋電商、新聞、短視頻等主流場景和技術(shù)生態(tài)，面向工程師與產(chǎn)品經(jīng)理。