Netflix的推薦和個性化功能向來精準，3月27日他們公布了自己在這方面的系統架構。其公布的系統架構圖中包含了多種機器學習算法，通過将作業分為離線、近線上和線上三種方式來對抗延時。
Netflix的推薦和個性化功能向來精準，前不久，他們公布了自己在這方面的系統架構。
3月27日，Netflix的工程師 Xavier Amatrain和 Justin Basilico在官方部落格 釋出文章，介紹了自己的個性化和推薦系統架構。文章開頭，他們指出：
要開發出這樣的一個軟體架構，能夠處理海量現有資料、響應使用者互動，還要易于嘗試新的推薦方法，這可不一點都不容易。
接下來，文章貼出了他們的系統架構圖，其中的主要元件包括多種機器學習算法。
他們這樣解釋其中的元件和處理過程：
對于資料，最簡單的方法是存下來，留作後續離線處理，這就是我們用來管理離線作業（Offline jobs）的部分架構。計算可以以離線、接近線上或是線上方式完成。線上計算（Online computation）能更快地響應最近的事件和使用者互動，但必須實時完成。這會限制使用算法的複雜性和處理的資料量。離線計算（Offline computation）對于資料數量和算法複雜度限制更少，因為它以批量方式完成，沒有很強的時間要求。不過，由于沒有及時加入最新的資料，是以很容易過時。個性化架構的關鍵問題，就是如何以無縫方式結合、管理線上和離線計算過程。接近線上計算（Nearline computation）介于兩種方法之間，可以執行類似于線上計算的方法，但又不必以實時方式完成。模型訓練（Model training）是另一種計算，使用現有資料來産生模型，便于以後在對實際結果計算中使用。另一塊架構是如何使用事件和資料分發系統（Event and Data Distribution）處理不同類型的資料和事件。與之相關的問題，是如何組合在離線、接近線上和線上之間跨越的不同的信号和模型（Signals and Models）。最後，需要找出如何組合推薦結果（Recommendation Results），讓其對使用者有意義。
接下來，文章分析了線上、接近線上和離線計算。
對于線上計算，相關元件需要滿足SLA對可用性和響應時間的要求，而且純粹的線上計算在某型情形下可能無法滿足SLA，是以，快速的備用方案就很重要，比如傳回預先計算好的結果等。線上計算還需要不同的資料源確定線上可用，這需要額外的基礎設施。
離線計算在算法上可相對靈活，工程方面的需求也簡單。用戶端的SLA響應時間要求也不高。在部署新算法到生産環境時，對于性能調優的需求也不高。Netflix利用這種靈活性來完成快速實驗：如果某個新的實驗算法執行較慢，他們會部署更多Amazon EC2執行個體來達成吞吐處理目标，而不是花費寶貴的工程師時間去優化性能，因為業務價值可能不是很高。
接近線上計算與線上計算執行方式相同，但計算結果不是馬上提供，而是暫時存儲起來，使其具備異步性。接近線上計算的完成是為了響應使用者事件，這樣系統在請求之間響應速度更快。這樣一來，針對每個事件就有可能完成更複雜的處理。增量學習算法很适合應用在接近線上計算中。
不管什麼情況，選擇線上、接近線上、還是離線處理，這都不是非此即彼的決策。所有的方式都可以、而且應該結合使用。 …… 即使是模組化部分也可以用線上和離線的混合方式完成。這可能不适合傳統的監督分類法（supervised classification）應用，因為分類器必須從有标記的資料中批量教育訓練，而且隻能以線上方式使用，對新輸入分類。不過，諸如矩陣因子分解這樣的方法更适合混合離線和線上模組化方法：有些因子可以預先以離線方式計算，有些因子可以實時更新，建立更新的結果。其他諸如叢集處理這樣的非監督方法，也可以對叢集中心進行離線計算，對叢集節點進行線上作業。這些例子說明：模型訓練可以分解為大規模和複雜的全局模型訓練，以及輕量級的使用者指定模型訓練或更新階段，以線上方式完成。
對于離線作業（Offline jobs），主要用來運作個性化機器學習算法。這些作業會定期執行，而且不必與結果的請求和展示同步。主要有兩種任務這樣處理：模型訓練和中間與最終結果批量計算（batch computation of intermediate or final results）。不過，他們也有一些學習算法是以線上增量方式完成的。
這兩種任務都需要改善資料，通常是由資料庫查詢完成。由于這些查詢要操作大量資料，以分布式方式完成更友善，是以通過Hadoop或是Hive、Pig作業就是自然而然的事情。一旦查詢完成，就需要某種機制釋出産生的資料。對于這樣的機制，Netflix有如下需求：
- 可以通知訂閱者查詢完成。
- 支援不同存儲方式（不隻是HDFS，還有S3或是Cassandra等等）
- 應該透明處理錯誤，允許監控和報警。
Netflix使用内部的工具Hermes完成這些功能，它将資料以接近實時的方式傳遞給訂閱者，在某些方面接近 Apache Kafka，但它不是消息/事件隊列系統。
無論是離線還是線上計算，都需要處理三種輸入：模型、資料和信号。模型是以離線方式訓練完成的參數檔案，資料是已完成處理的資訊，存在某種資料庫中。在Netflix，信号是指輸入到算法中的新鮮資訊。這些資料來自實時服務，可用其産生使用者相關資料。
對于事件和資料分發，Netflix會從多種裝置和應用中收集盡可能多的使用者事件，并将其集中起來為算法提供基礎資料。他們區分了資料和事件。事件是對時間敏感的資訊，需要盡快處理。事件會路由、觸發後續行動或流程。而資料需要處理和存儲，便于以後使用，延遲不是重要，重要的是資訊品質和數量。有些使用者事件也會被作為資料處理。
Netflix使用内部架構Manhattan處理接近實時的事件流。該分布式計算系統是推薦算法架構的中心。它類似Twitter的Storm，但是用處不同，而且響應不同的内部需求。資料流主要通過 Chukwa，輸入到Hadoop，進行處理的初步階段。此後使用Hermes作為釋出-訂閱機制。
Netflix使用Cassandra、EVCache和MySQL存儲離線和中間結果。它們各有利弊。MySQL存儲結構化關系資料，但會面臨分布式環境中的擴充性問題。當需要大量寫操作時，他們使用EVCache更合适。關鍵問題在于，如何滿足查詢複雜度、讀寫延遲、事務一緻性等彼此沖突的需求，要對于各種情況到達某個最優點。
在總結中，他們指出：
我們需要具備使用複雜機器學習算法的能力，這些算法要可以适應高度複雜性，可以處理大量資料。我們還要能夠提供靈活、靈活創新的架構，新的方法可以很容易在其基礎上開發和插入。而且，我們需要我們的推薦結果足夠新，能快速響應新的資料和使用者行為。找到這些要求之間恰當的平衡并不容易，需要深思熟慮的需求分析，細心的技術選擇，戰略性的推薦算法分解，最終才能為客戶達成最佳的結果。
原文連結： Netflix公布個性化和推薦系統架構