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