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更適合密集和持續的寫操作。