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更合適。關鍵問題在於，如何滿足查詢複雜度、讀寫延遲、事務一致性等彼此衝突的需求，要對於各種情況到達某個最優點。

在總結中，他們指出：

我們需要具備使用複雜機器學習演算法的能力，這些演算法要可以適應高度複雜性，可以處理大量資料。我們還要能夠提供靈活、敏捷創新的架構，新的方法可以很容易在其基礎上開發和插入。而且，我們需要我們的推薦結果足夠新，能快速響應新的資料和使用者行為。找到這些要求之間恰當的平衡並不容易，需要深思熟慮的需求分析，細心的技術選擇，戰略性的推薦演算法分解，最終才能為客戶達成最佳的結果。