知識分享|超詳細：完整的推薦系統(tǒng)架構設計
發(fā)布時間：2023-09-15 15:12:00
架構設計概述
架構設計是一個很大的話題，這里只討論和推薦系統(tǒng)相關的部分。更具體地說，我們主要關注的是算法以及其他相關邏輯在時間和空間上的關系——這樣一種邏輯上的架構關系。
在前面的章節(jié)中我們講到了很多種算法，每種算法都是用來解決整個推薦系統(tǒng)流程中的某個問題的。我們的最終目標是將這些算法以合理的方式組合起來，形成一整套系統(tǒng)。在這個過程中，可用的組合方式有很多，每種方式都有舍有得，但每種組合方式都可被看作一種架構。這里要介紹的就是一些經過實踐檢驗的架構層面的最佳實踐，以及對這些最佳實踐在不同應用場景下的分析。除此之外，還希望能夠通過把各種推薦算法放在架構的視角和場景下重新審視，讓讀者對算法間的關系有更深入的理解，從全局的角度看待推薦系統(tǒng)，而不是只看到一個個孤立的算法。
架構設計的本質之一是平衡和妥協(xié)。一個推薦系統(tǒng)在不同的時期、不同的數據環(huán)境、不同的應用場景下會選擇不同的架構，在選擇時本質上是在平衡一些重要的點。下面介紹幾個常用的平衡點。
1. 個性化 vs 復雜度
個性化是推薦系統(tǒng)作為一個智能信息過濾系統(tǒng)的安身立命之本，從最早的熱榜，到后來的公式規(guī)則，再到著名的協(xié)同過濾算法，最后到今天的大量使用機器學習算法，其主線之一就是為用戶提供個性化程度越來越高的體驗，讓每個人看到的東西都盡量差異化，并且符合個人的喜好。為了達到這一目的，系統(tǒng)的整體復雜度越來越高，具體表現(xiàn)為使用的算法越來越多、算法使用的數據量和數據維度越來越多、機器學習模型使用的特征越來越多，等等。同時，為了更好地支持這些高復雜度算法的開發(fā)、迭代和調試，又衍生出了一系列對應的配套系統(tǒng)，進一步增加了整個系統(tǒng)的復雜度?？梢哉f整個推薦邏輯鏈條上的每一步都被不斷地細化分析和優(yōu)化，這些不同維度的優(yōu)化橫縱交織，構造出了一個整體復雜度非常高的系統(tǒng)。從機器學習理論的角度來類比，如果把推薦系統(tǒng)整體看作一個巨大的以區(qū)分用戶為目標的機器學習模型，則可以認為復雜度的增加對應著模型中特征維度的增加，這使得模型的 VC 維不斷升高，對應著可分的用戶數不斷增加，進而提高了整個空間中用戶的個性化程度。這條通過不斷提高系統(tǒng)復雜度來提升用戶個性化體驗的路線，也是近年來推薦系統(tǒng)發(fā)展的主線之一。
2. 時效性 vs 計算量
推薦系統(tǒng)中的時效性概念體現(xiàn)在實時服務的響應速度、實時數據的處理速度以及離線作業(yè)的運行速度等幾個方面。這幾個速度從時效性角度影響著推薦系統(tǒng)的效果，整體上講，運行速度越快，耗時越少，得到的效果越好。這是因為響應速度越快，意味著對用戶行為、物品信息變化的感知越快，感知后的處理速度越快，處理后結果的反饋就越快，最終體現(xiàn)到用戶體驗上，就是系統(tǒng)更懂用戶，更快地對用戶行為做出了反應，從而產生了更好的用戶體驗。但這些時效性的優(yōu)化，帶來的是更大的計算量，計算量又對應著復雜的實現(xiàn)邏輯和更多的計算資源。在設計得當的前提下，這樣的付出通常是值得的。如同前面章節(jié)中介紹過的，時效性優(yōu)化是推薦系統(tǒng)中非常重要的一類優(yōu)化方法和優(yōu)化思路，但由此帶來的計算壓力和系統(tǒng)設計的復雜度也是必須要面對的。
3. 時間 vs 空間
時間和空間之間的平衡關系可以說是計算機系統(tǒng)中最為本質的關系之一，在推薦系統(tǒng)中也不例外。時間和空間這一對矛盾關系在推薦系統(tǒng)中的典型表現(xiàn)，主要體現(xiàn)在對緩存的使用上。緩存通常用來存儲一些計算代價較高以及相對靜態(tài)變化較少的數據，例如用戶的一些畫像標簽以及離線計算的相關性結果等。但是隨著越來越多的實時計算的引入，緩存的使用也越來越廣泛，常常在生產者和消費者之間起到緩沖的作用，使得二者可以解耦，各自異步進行。例如實時用戶興趣計算這一邏輯，如果沒有將之前計算的興趣緩存起來，那么在每次需要用戶興趣時都要實時計算一次，并要求在較短的時間內返回結果，這對計算性能提出了較高的要求。但如果中間有一層緩存作為緩沖，則需求方可以直接從緩存中取來結果使用。這在結果的實時性和新鮮度上雖然做了一定的妥協(xié)，但卻能給性能提升帶來極大的幫助。這樣就將生產和消費隔離開來，生產者可以根據具體情況選擇生產的方式和速度。當然，仍然可以努力提高生產速度，生產速度越快，緩存給時效性帶來的損失就越小，消費者不做任何改動就可以享受到這一提升效果。所以說，這種利用緩存來解耦系統(tǒng)，帶來性能上的提升以及開發(fā)的便利，也是在推薦系統(tǒng)架構設計中需要掌握的一種通用的思路。
上面介紹的一些基本性原則貫穿著推薦系統(tǒng)架構設計的方方面面，是一些具有較高通用性的思路，掌握這些思路，可以產生出很多具體的設計和方法；反過來，每一種設計技巧或方法，也都可以映射到一個或幾個這樣的高層次抽象原則上來。這種自頂向下的思維學習方法對于推薦系統(tǒng)的架構設計是非常重要的，并且可以推廣到很多其他系統(tǒng)的設計中。
系統(tǒng)邊界和外部依賴
架構設計的第一步是確定系統(tǒng)的邊界。所謂邊界，就是區(qū)分什么是這個系統(tǒng)要負責的，也就是邊界內的部分，以及什么是這個模型要依賴的，也就是邊界外的部分。劃分清楚邊界，意味著確定了功能的邊界以及團隊的邊界，能夠讓后期的工作都專注于核心功能的設計和實現(xiàn)。反之，如果系統(tǒng)邊界沒有清晰的定義，可能會在開發(fā)過程中無意識地侵入其他系統(tǒng)中，形成冗余甚至矛盾，或者默認某些功能別人會開發(fā)而將其忽略掉。無論哪種情況，都會影響系統(tǒng)的開發(fā)乃至最終的運轉。
系統(tǒng)邊界的確定，簡單來說，就是在輸入方面確定需要別人給我提供什么，而在輸出方面確定我要給別人提供什么。在輸入方面，就是判斷什么輸入是需要別人提供給我的，要把握的主要原則包括：
這個數據或服務是否與我的業(yè)務強相關。在推薦業(yè)務中用到的每個東西，并不是都與推薦業(yè)務強相關，例如電商推薦系統(tǒng)中的商品信息，只有與推薦業(yè)務強相關的服務才應該被納入推薦系統(tǒng)的邊界中。
這個數據或服務除了我的業(yè)務在使用，是否還有其他業(yè)務也在使用。例如上面說到的商品信息服務，除了推薦系統(tǒng)在使用，其他子系統(tǒng)也在廣泛使用，那么顯然它應該是一個外部依賴。也有例外情況，例如推薦系統(tǒng)要用到一些其他系統(tǒng)都用不到的商品信息，這時候，雖然理論上應該升級商品信息服務來支持推薦系統(tǒng)，但由于其他地方都用不到這些信息，因此很多時候可能需要推薦系統(tǒng)的負責團隊來實現(xiàn)這樣一個定制化服務。
依照此原則，圖 11-1 展示了推薦系統(tǒng)的主要外部依賴。
圖 11-1 推薦系統(tǒng)的主要外部依賴
1. 數據依賴
推薦系統(tǒng)作為一個典型的數據算法系統(tǒng)，數據是其最重要的依賴。這里面主要包括用戶行為數據和物品數據兩大類，前面介紹的各種算法幾乎都是以這兩種數據作為輸入進行計算的。這些數據除了為推薦系統(tǒng)所用，它們也是搜索、展示等其他重要系統(tǒng)的輸入數據，所以作為通用的公共數據和服務，顯然不應該在推薦系統(tǒng)的邊界內部，而應該是外部依賴。需要特別指出的是，雖然有專門的團隊負責行為數據的收集，但是收集到的數據是否符合推薦系統(tǒng)的期望卻不是一件可以想當然的事情。例如，對于結果展示的定義，數據收集團隊認為前端請求到了結果就是展示，但對于推薦系統(tǒng)來說，只有用戶真正看見了才是真實的展示。其中的原因在于數據收集團隊并不直接使用數據，那么他們就無法保證數據的正確性，這時就需要具體使用數據的業(yè)務方，在這里是推薦團隊，來和他們一起確認數據收集的邏輯是正確的。如果數據收集的邏輯不正確，后面的算法邏輯就是在做無用功。花在確保數據正確上的精力和資源，幾乎總是有收益的。
2. 平臺工具依賴
推薦系統(tǒng)是一個計算密集型的系統(tǒng)，需要對各種形態(tài)的數據做各種計算處理，在此過程中，需要一整套計算平臺工具的支持，典型的如機器學習平臺、實時計算平臺、離線計算平臺、其他平臺工具等。在一個較為理想的環(huán)境中，這些平臺工具都是由專門的團隊來構建和維護的。而在一些場景下，推薦系統(tǒng)可能是整個組織中最早使用這些技術的系統(tǒng)，推薦業(yè)務也還沒有重要和龐大到需要老板專門配備一個平臺團隊為之服務的程度，在這種情況下，其中的一些平臺工具就需要推薦系統(tǒng)的團隊自己負責來構建和維護了。為了簡化邏輯，下面我們假設這些平臺工具都是獨立于推薦系統(tǒng)存在的，屬于推薦系統(tǒng)的外部依賴。
在對外輸出方面，系統(tǒng)邊界的劃定會根據公司組織的不同有所差異。例如，在一些公司中，推薦團隊負責的是與推薦相關的整個系統(tǒng)，在輸出方面的體現(xiàn)就是從算法邏輯到結果展示，這時候系統(tǒng)的邊界就要延伸到最終的結果展示。而在另外一些公司中，前端展示是由一個大團隊統(tǒng)一負責的，這時候推薦系統(tǒng)只需要給出要展示的物品 ID 和相關展示信息即可，前端團隊會負責統(tǒng)一展示這些物品信息。這兩種模式沒有絕對的好壞之分，重要的是要與整個技術團隊的規(guī)劃和架構相統(tǒng)一。在本書中，為了敘述簡便，我們不討論前端展示涉及的內容，只專注于推薦結果的生產邏輯。
推薦系統(tǒng)的效果和性能在一定程度上取決于這些依賴系統(tǒng)，所以在尋求推薦系統(tǒng)的優(yōu)化目標時，目光不能只看到推薦系統(tǒng)本身，很多時候這些依賴系統(tǒng)也是重要的效果提升來源。例如，物品信息的變更如果能被更快地通知到推薦系統(tǒng)，那么推薦系統(tǒng)的時效性就會更好，給到用戶的結果也就會更好；再如，用戶行為數據收集的準確性能有所提高的話，對應的相關性算法的準確性也會隨之提高。在有些情況下，外部系統(tǒng)升級會比優(yōu)化算法有更大的效果提升。當然，推薦系統(tǒng)的問題也可能來自這些外部的依賴系統(tǒng)。例如，前端渲染展示速度的延遲會導致用戶點擊率的顯著下降，因為這會讓用戶失去耐心。所以，當推薦系統(tǒng)指標出現(xiàn)下降時，不光要從內部找問題，也要把思路拓展到系統(tǒng)外部，從全局的角度去找問題。綜合來講，外部依賴的存在啟發(fā)我們要從全鏈條、全系統(tǒng)的角度來看問題，找問題，以及設計優(yōu)化方法。
離線層、在線層和近線層架構
架構設計有很多不同的切入方式，最簡單也是最常用的一種方式就是先決定某個模塊或邏輯是運行在離線層、在線層還是近線層。這三層的對比如表 11-1 所示。
任何使用非實時數據、提供非實時服務的邏輯模塊，都可以被定義為離線模塊。其典型代表是離線的協(xié)同過濾算法，以及一些離線的標簽挖掘類算法。離線層通常用來進行大數據量的計算，由于計算是離線進行的，因此用到的數據也都是非實時數據，最終會產出一份非實時的離線數據，供下游進一步處理使用。與離線層相對的是在線層，也常被稱為服務層，這一層的核心功能是對外提供服務，實時處理調用方的請求。這一層的典型代表是推薦系統(tǒng)的對外服務接口，接受實時調用并返回結果。在線層提供的服務是實時的，但用到的數據卻不一定局限于實時數據，也可以使用離線計算好的各種數據，例如相關性數據或標簽數據等，但前提是這些數據已經以對實時友好的形態(tài)被存儲起來。
近線層則處于離線層和在線層的中間位置，是一個比較奇妙的層。這一層的典型特點就是：使用實時數據（也會使用非實時數據），但不提供實時服務，而是提供一種近實時的服務。所謂近實時指的是越快越好，但并不強求像在線層一樣在幾十毫秒內給出結果，因為通常在近線層計算的結果會寫入緩存系統(tǒng)，供在線層讀取，做了一層隔離，因此對時效性無強要求。其典型代表是我們前面講過的實時協(xié)同過濾算法，該算法通過用戶的實時行為計算最新的相關性結果，但這些計算結果并不是實時提供給用戶的，而是要等到用戶發(fā)起請求時才會把最新的結果提供給他使用。
下面詳細介紹每一層的特點、案例和具體分析。
離線層架構
離線層是推薦系統(tǒng)中承擔最大計算量的一個部分，很大一部分的相關性計算、標簽挖掘以及用戶畫像挖掘工作都是在這一層進行的。這一層的任務具有的普遍特點是使用大量數據以及較為復雜的算法進行計算和挖掘。所謂大量數據，通常指的是可以使用較長時間段的用戶行為數據和全量的物品數據；而在算法方面，可以使用較為復雜的模型或算法，對性能的壓力相對較小。對應地，離線層的任務也有缺點，就是在時間上存在滯后性。由于離線任務通常是按天級別運行的，用戶行為或物品信息的變更也要等一天甚至更久才能夠被反映到計算結果中。在離線層雖然進行的是離線作業(yè)，但其生產出來的數據通常是被實時使用的，因此離線數據在生產出來之后還需要同步到方便在線層讀取的地方，例如數據庫、在線緩存等。
在具體實踐中，經常放在離線層執(zhí)行的任務主要包括：協(xié)同過濾等行為類相關性算法計算、用戶標簽挖掘、物品標簽挖掘、用戶長期興趣挖掘、機器學習模型排序等。仔細分析這些任務，會發(fā)現(xiàn)它們都符合上面提到的特點。這些任務的具體流程各不相同，但大體上都遵循一個共同的邏輯流程，如圖 11-2 所示。
圖 11-2 離線層邏輯架構圖
在這個邏輯架構圖中，離線算法的數據來源主要有兩大類：一類是 HDFS/Hive 這樣的分布式文件系統(tǒng)，通常用來存儲收集到的用戶行為日志以及其他服務器日志；另一類是 RDBMS 這樣的關系數據庫，通常用來存儲商品等物品信息。離線算法會從輸入數據源獲取原始數據并進行預處理，例如，協(xié)同過濾算法會先把數據處理成兩個倒排表，LDA 算法會先對物品文本做分詞處理，等等，我們將預處理后的數據統(tǒng)一稱為訓練數據（雖然有些離線算法并不是機器學習算法）。預處理這一步值得單獨拿出來講，這是因為很多算法用到的預處理是高度類似的，例如，文本標簽類算法需要先對原始文本進行分詞或詞性標注，行為類相關性算法需要先將行為數據按用戶聚合，點擊率模型需要先將數據按照點擊/展示進行聚合整理，等等。所以在設計離線挖掘的整體架構時，有必要有針對性地將數據預處理流程單獨提煉出來，以方便后面的流程使用，做到更好的可擴展性和可復用性。下一步是各種推薦算法或機器學習模型基于各自的訓練數據進行挖掘計算，得到挖掘結果。離線計算用到的工具通常包括 Hadoop、Spark 等，結果可能是一份協(xié)同過濾相關性數據，可能是物品的文本主題特征，也可能是結果排序模型。接下來，為了讓挖掘結果能夠被后面的流程所使用，需要將挖掘結果同步到不同的存儲系統(tǒng)中。一般來說，如果挖掘結果要被用作下游離線流程的輸入，是一份中間結果，那么通常它會被再次同步到 Hive 或 HDFS 這樣的分布式文件系統(tǒng)中；如果挖掘結果要被最終的推薦服務在線實時使用，那么它就需要被同步到 Redis 或 RDBMS 這樣對實時訪問更為友好的存儲系統(tǒng)中。至此，一個完整的離線挖掘流程就完成了。
上面講到離線任務通常以天為單位來執(zhí)行，但是在很多情況下，提高作業(yè)的運行頻率以及對應的數據同步頻率，例如從一天一次提升到一天多次，都會對推薦系統(tǒng)的效果有提升作用，因為這些都可以被理解為在做時效性方面的優(yōu)化。一種極限的思想是，當我們把作業(yè)的運行頻率提高到極致時，例如每分鐘甚至每幾秒鐘運行一次作業(yè)，離線任務就變成了近線任務。當然，在這種情況下就需要對離線算法做相應的修改以適應近線計算的要求，例如前面介紹過的實時協(xié)同過濾算法就是對原始協(xié)同過濾算法的修改，以及將機器學習的模型訓練過程從離線改為在線。
所以，雖然我們會把某些任務放到離線層來執(zhí)行，但并不代表這些任務就只能是離線任務。我們要深入理解為什么將這些任務放在離線層來執(zhí)行，在什么情況下可以提高其運行頻率，甚至變?yōu)榻€任務，以及這樣做的好處和代價是什么。只有做到這一點，才能夠做到融會貫通，不被當前的表象迷住眼睛。一種典型的情況是，當實時計算或流計算平臺資源不足，或者開發(fā)人力資源不足時，我們傾向于把更多的任務放到離線層來執(zhí)行，因為離線計算對時效性要求較低，出錯之后影響也較小。綜合來說，就是容錯度較高，適合在整體資源受限的情況下優(yōu)先選擇。而隨著平臺的不斷完善，以及人力資源的不斷補充，就可以把一些對時效敏感的任務放到近線層來執(zhí)行，以獲得更好的收益。
近線層架構
有了上面的鋪墊，近線層的存在理由和價值就比較明確了，從生產力發(fā)展的角度來看，可以認為它是實時計算平臺工具發(fā)展到一定程度對離線計算的自然改造；而從推薦系統(tǒng)需求的角度來看，它是各種推薦算法追求實時化效果提升的一種自然選擇。
近線層和離線層最大的差異在于，它可以獲取到實時數據，并有能力對實時數據進行實時或近實時的計算。也正是由于這個特點，近線層適合用來執(zhí)行對時效比較敏感的計算任務，例如實時的數據統(tǒng)計等，以及實時執(zhí)行能夠獲得較大效果提升的任務，例如一些實時的相關性算法計算或標簽提取算法計算。近線層在計算時可使用實時數據，也可使用離線生成的數據，在提供服務時，由于無須直接響應用戶請求，因此也不用提供實時服務，而是通常會將數據寫入對實時服務友好的在線緩存中，方便實時服務讀取，同時也會同步到離線端做備份使用。
通常放在近線層執(zhí)行的任務包括實時指標統(tǒng)計、用戶的實時興趣計算、實時相關性算法計算、物品的實時標簽挖掘、推薦結果的去重、機器學習模型統(tǒng)計類特征的實時更新、機器學習模型的在線更新等，這些任務通常會以如下兩種方式進行計算。
個體實時：所謂個體實時，指的是每個實時數據點到來時都會觸發(fā)一次計算，做到真正意義上的實時。典型的工具代表是 Storm 和 Flink。
批量實時：很多時候并不需要到來一個實時數據點就計算一次，因為這會帶來大量的計算和 I/O，而是可以將一定的時間窗口或一定數量的數據收集起來，以小批次為單位進行計算，這可以有效減少 I/O 量。這種妥協(xié)對于很多應用來說，只要時間窗口不太大，就不會帶來效果的顯著下降。典型的工具代表是 Spark Streaming。
圖 11-3 展示了典型的近線層計算架構圖。
圖 11-3 典型的近線層計算架構圖
從數據源接入的角度來看，近線層主要使用實時數據進行計算，這就引出了近線層和離線層的一個主要區(qū)別：近線層的計算通常是事件觸發(fā)的，而離線層的計算通常是時間觸發(fā)的。事件觸發(fā)意味著對計算擁有更多的主動權和選擇權，但時間觸發(fā)則無法主動做出選擇。事件觸發(fā)意味著每個事件發(fā)生之后都會得到通知，但是否要計算以及計算什么是可以自己選擇的。例如，可以選擇只捕捉滿足某種條件的事件，或者等事件累積到一定程度時再計算，等等。所以，當某個任務的觸發(fā)條件是某個事件發(fā)生之后進行計算，那么這個任務就很適合放在近線層來執(zhí)行。例如推薦結果的去重，需要在用戶瀏覽過該物品之后將其加入一個去重集合中，這就是一個典型的事件觸發(fā)的計算任務。此外，近線層的計算是可以使用離線數據的，但前提是需要提前將這些數據同步到對實時計算友好的存儲系統(tǒng)中。
在近線層中執(zhí)行的典型任務包括但不限于：
特征的實時更新。例如，根據用戶的實時點擊行為實時更新各維度的點擊率特征。
用戶實時興趣的計算。根據用戶實時的喜歡和不喜歡行為計算其當下實時興趣的變化。
物品實時標簽的計算。例如，在第 6 章用戶畫像系統(tǒng)中介紹過的實時提取標簽的流程。
算法模型的在線更新。通過實時消息隊列接收和拼接實時樣本，采用 FTRL 等在線更新算法來更新模型，并將更新后的模型推送到線上。
推薦結果的去重。用戶兩次請求之間是有時間間隔的，所以無須在處理實時請求時進行去重，而是可以將這個信息通過消息隊列發(fā)送給一個專門的服務，在近線層中處理。
實時相關性算法計算。典型的如實時協(xié)同過濾算法，按照其原理，也可以把隨機游走等行為類算法改寫為實時計算，放到近線層中執(zhí)行。
總結起來，凡是可以和實時請求解耦，但需要實時或近實時計算結果的任務，都可以放到近線層中執(zhí)行。
近線層的實時計算雖然沒有響應時間的要求，但卻存在數據堆積的壓力。具體來說，近線層計算用到的數據大部分是通過 Kafka 這樣的消息隊列實時發(fā)送過來的，在接收到每一個消息或消息窗口之后，如果對消息或消息窗口的計算速度不夠快，就會導致后面的消息堆積。這就像大家都在排隊辦理業(yè)務，如果一個業(yè)務辦理得太慢，那么排的隊就會越來越長，長到一定程度就會出問題。所以，近線層的計算邏輯不宜過于復雜，而且近線層讀取的外部數據，例如離線同步好的 Redis 中的數據，也不宜過多，還有 I/O 次數不宜過多。這就要求近線層的計算邏輯和用到的數據結構都要經過精心的設計，共同保證近線層的計算效率，以免造成數據堆積。
除了純數據統(tǒng)計類型的任務，以及結果去重這樣的無數據產出的任務，近線層的大多數任務在離線層都有對應的部分，二者有著明顯的優(yōu)勢和劣勢，因此應該結合起來使用。典型的如實時協(xié)同過濾算法，由于引入了實時性，使得它在一些新物品和新用戶上的效果比原始的協(xié)同過濾算法的效果好；但由于它只使用實時數據，所以在稀疏性和不穩(wěn)定性方面的問題也是比較大的，要使用離線版本的協(xié)同過濾算法作為補充，才能形成更全面的覆蓋。再比如在近線層執(zhí)行的用戶實時興趣預測，能夠捕捉到用戶最新鮮的興趣，準確率會比較高；但由于短期興趣易受展示等各種因素影響發(fā)生較大的波動，如果完全根據短期興趣來進行推薦的話，則很有可能會陷入局部的信息繭房，產生高度同質的結果，影響用戶的整體體驗。而如果將離線計算的長期興趣和短期興趣相結合，就可以有效避免這個問題，既能利用實時數據取得高相關性，又能利用長期數據取得穩(wěn)定性和多樣性。從這些例子可以看出，離線層和近線層之間并沒有不可逾越的鴻溝，二者更多的是在效率、效果、穩(wěn)定性、稀疏性等多個因素之間進行權衡得到的不同選擇，一個優(yōu)秀的工程師應該做到“碼中有層，心中無層”，才算是對算法和架構做到了融會貫通。
上面講到離線層的任務在一定條件下可以放到近線層來執(zhí)行，那么類似地，近線層的任務是否可以放到在線層來執(zhí)行呢？這個問題其實涉及離線層、近線層這兩層作為整體和在線層的關系。如果把推薦系統(tǒng)比作一支打仗的軍隊，那么在線層就是在前方沖鋒陷陣的士兵，直接面對敵人的攻擊，而離線層和近線層就是提供支持的支援部門，離線層就像是生產糧食和軍火的大后方，近線層就像是搭橋修路的前方支援部門，二者的本質都是讓前線士兵能夠最高效、最猛烈地打擊敵人，但其業(yè)務本質導致它們無法到前線去殺敵。離線層和近線層是推薦系統(tǒng)的生產者，在線層是推薦系統(tǒng)的消費者（也會承擔一定的生產責任），它們有著截然不同的分工和定位，是無法互換的。
在線層架構
在線層與離線層、近線層最大的差異在于，它是直接面對用戶的，所有的用戶請求都會發(fā)送到在線層，而在線層需要快速給出結果。如果抽離掉其他所有細節(jié)，這就是在線層最本質的東西。在線層最本質的東西并不是在線計算部分，因為在極端情況下，在接收到用戶請求之后，在線層可以直接從緩存或數據庫中取出結果，返回給用戶，而不做任何額外計算。而事實上，早年還沒有引入機器學習等復雜的算法技術時，絕大多數計算都是在離線層進行的，在線層就起到一個數據傳遞的作用，很多推薦系統(tǒng)基本都是這么做的，甚至時至今日，這種做法仍然是一種極端情況下的降級方案。
推薦系統(tǒng)發(fā)展到現(xiàn)在，尤其是各種機器學習算法的引入，使得我們可以使用的信息越來越多，可用的算法也越來越復雜，給用戶的推薦結果通常是融合了多種召回策略，并且又加了重排序之后的結果，而融合和重排序現(xiàn)在通常是在在線層做的。那么問題來了：這些復雜計算一定要放到在線層做嗎？為了回答這個問題，不妨假設：如果將所有計算都放在離線層做，在線層只負責按照用戶 ID 查詢返回結果，是否可行？如果將所有計算都放在離線層做，由于不知道明天會有哪些用戶來訪問系統(tǒng)，所以就需要為每個用戶都計算出推薦結果，這要求我們計算出全平臺所有用戶的推薦結果，而對于那些明天沒有來訪問系統(tǒng)的用戶，今天的計算就浪費掉了。但這仍然不夠，因為明天還會有新來的用戶，這些用戶的信息在當前計算時是拿不到的，所以，即使今天離線計算出了所有當前用戶的推薦結果，明天也還會有大量覆蓋不到的用戶。這就是將上面提到的復雜計算一定要放在在線層做的第一個主要原因：只有按需實時計算才能覆蓋到所有用戶，并且不會產生計算的浪費。從另一個角度來看，如果今天就把用戶的推薦結果完全計算出來，若用戶明天的實時行為表達出來的興趣和今天的不相符，或者機器學習模型中一些關鍵特征的取值發(fā)生了變化，那么推薦結果就會不準確，并且無法及時調整。例如，用戶昨天看的是手機，今天打算買衣服，但我們昨天計算出的推薦結果是以手機為主的，那么用戶今天的需求是無法滿足的。這就是需要在在線層做復雜計算的第二個主要原因：只有在線實時計算，才能夠充分利用用戶的實時信息，包括實時興趣、實時特征以及其他近線層計算的結果等。除此以外，還有其他原因，比如實時處理可以快速應對實時發(fā)生的業(yè)務請求等。以上這些原因共同決定了在線層存在的意義。
