Netflix推薦系統(Part two)-系統架構

Netflix在2013年公佈了本身推薦系統的架構，本文主要總結和翻譯自System Architectures for Personalization and Recommendation，但這並非一篇完整的翻譯文章。

Overview

首先，咱們在下圖中提供推薦系統的總體系統圖。 該體系結構的主要組件包含一個或多個機器學習算法。

計算能夠被online，nearline或者offline完成。 online計算能夠更好地響應最近的事件和用戶交互，但必須實時響應請求。這會限制所採用的算法的計算複雜性以及能夠處理的數據量。offline計算對數據量和算法的計算複雜性的限制較少，由於它以批量方式運行且具備寬鬆的時序要求。個性化架構中的關鍵問題之一是如何以無縫方式組合和管理在線和離線計算。近線計算是這兩種模式之間的中間折衷，咱們能夠在其中執行相似在線的計算，但不要求它們實時提供。模型訓練是另外一種計算形式，它使用現有數據生成模型，該模型稍後將在實際計算結果期間使用。該體系結構的另外一部分描述了事件和數據分發系統如何處理不一樣類型的事件和數據。相關問題是如何組合離線，近線和在線制度所需的不一樣信號和模型。最後，咱們還須要弄清楚如何以對用戶有意義的方式組合中間推薦結果。本文的其他部分將詳細介紹此體系結構的這些組件及其交互。Netflix的整個基礎架構都在Amazon Web Services雲上運行。

Computation

Online計算能夠快速響應事件並使用最新數據。 一個示例是使用當前context爲action movie gallery排序。 聯機組件受可用性和響應時間服務級別協議（SLA）的約束，該協議指定響應來自客戶端應用程序的請求的進程的最大延遲。 這使得在複雜且計算成本高的算法難以在online service中使用。 此外，純粹的在線計算在某些狀況下可能沒法知足其SLA，所以考慮快速回退機制（例如恢復到預先計算的結果）很重要。 online計算還意味着所涉及的各類數據源也須要在線提供，這可能須要額外的基礎設施。

Offline計算容許使用更復雜的算法和更多的數據一個簡單的例子多是按期彙總數百萬電影播放事件的統計數據，以計算baseline的流行度指標。離線系統也有更簡單的工程要求。例如，能夠輕鬆知足客戶施加的寬鬆響應時間SLA。能夠在生產中部署新算法，而無需在性能調優上投入太多精力。這種靈活性支持敏捷創新。Netflix利用這一點來支持快速實驗：若是新的實驗算法執行速度較慢，咱們能夠選擇簡單地部署更多Amazon EC2實例來實現運行實驗所需的吞吐量，而不是花費寶貴的工程時間來優化性能對於可能被證實具備很小商業價值的算法。可是，因爲脫機處理沒有強大的延遲要求，所以它不會對上下文或新數據的更改作出快速反應。這可能會下降用戶體驗。離線計算還須要具備用於存儲，計算和訪問大量預先計算結果的基礎結構。

Nearline計算能夠看做是前兩種模式之間的折衷。Nearline計算是響應於用戶事件而完成的。

在任何狀況下，online/nearline/offline均可以並且應該結合起來。有不少方法能夠將它們組合在一塊兒。咱們已經提到了使用離線計算做爲後備的想法。另外一種選擇是使用離線過程預先計算部分結果，並留下算法中成本較低的部分或者上下文敏感的部分用於online計算。 甚至建模部分也能夠以混合離線/在線方式完成。傳統的監督分類應用必須從標記數據批量訓練分類器，而且在線進行預測。可是，矩陣分解等方法更適合混合在線/離線建模：某些因素能夠離線預先計算，而其餘因素能夠實時更新以建立更新鮮的結果。其餘無監督方法（例如cluster）還容許cluster center的離線計算和cluster的在線分配。

Offline Jobs

offline jobs的主要內容是數據統計和模型的離線訓練，這些內容一般以batch爲單位完成。 這兩個任務都須要處理數據，這一般是經過運行數據庫查詢生成的。因爲這些查詢會運行大量數據，它們適合以分佈式方式經過Hive或Pig做業在Hadoop上運行。查詢完成後，咱們須要一種機制來發布結果數據。咱們對該機制有幾個要求：首先，它應該在查詢結果準備好時通知訂閱者。其次，它應該支持不一樣的存儲庫（不只是HDFS，還有S3或Cassandra）。最後，它應該透明地處理錯誤，容許監視和警報。Netflix使用一個名爲Hermes的內部工具，從某種意義上說，它涵蓋了與Apache Kafka相同的一些用例，但它不是消息/事件隊列系統。

Signals & Models & Event & Data

不管咱們是在進行在線仍是離線計算，咱們都須要考慮算法如何處理三種輸入：model，data和signal。 Model一般是先前已離線培訓的參數的小文件。 Data是先前處理的信息，已存儲在某種數據庫中，例如電影元數據或流行度。 咱們使用術語「signal」來指代咱們輸入算法的新信息。 該數據從實時服務得到，而且能夠由用戶相關信息（例如，成員最近觀看的內容）或諸如會話，設備，日期或時間的上下文數據構成。

Netflix嘗試區別event和data。他們將事件視爲時間敏感信息的小單位，須要以儘量少的延遲進行處理，以觸發後續操做或過程，例如更新nearline結果集。另外一方面，他們將數據視爲可能須要處理和存儲以供之後使用的更密集的信息單元。這裏的延遲並不像信息質量和數量那麼重要。固然，有些用戶事件能夠被視爲事件和數據，所以被髮送到兩個流。

Recommendation Results

Netflix將offline和intermediate結果存儲在各類存儲庫中，以便稍後在請求時使用：他們使用的主要數據存儲是Cassandra，EVCache和MySQL。每種解決方案都有其優勢和缺點。

MySQL容許存儲結構化關係數據，這些數據多是經過通用查詢進行的某些將來過程所必需的。可是，這種通用性是以犧牲分佈式環境中的scalability爲代價的。 Cassandra和EVCache都提供了鍵值存儲的優點。當須要分佈式和可擴展的無SQL存儲時，Cassandra是一個衆所周知的標準解決方案。 Cassandra在某些狀況下運行良好，但EVCache更適合密集和持續的寫操做。