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
Signals & Models & Event & Data
無論我們是在進行線上還是離線計算，我們都需要考慮演算法如何處理三種輸入：model，data和signal。 Model通常是先前已離線培訓的引數的小檔案。 Data是先前處理的資訊，已儲存在某種資料庫中，例如電影後設資料或流行度。 我們使用術語“signal”來指代我們輸入演算法的新資訊。 該資料從實時服務獲得，並且可以由使用者相關資訊（例如，成員最近觀看的內容）或諸如會話，裝置，日期或時間的上下文資料構成。
Netflix嘗試區別event和data。他們將事件視為時間敏感資訊的小單位，需要以儘可能少的延遲進行處理，以觸發後續操作或過程，例如更新nearline結果集。另一方面，他們將資料視為可能需要處理和儲存以供以後使用的更密集的資訊單元。這裡的延遲並不像資訊質量和數量那麼重要。當然，有些使用者事件可以被視為事件和資料，因此被髮送到兩個流。
Recommendation Results
MySQL允許儲存結構化關係資料，這些資料可能是通過通用查詢進行的某些未來過程所必需的。但是，這種通用性是以犧牲分散式環境中的scalability為代價的。 Cassandra和EVCache都提供了鍵值儲存的優勢。當需要分散式和可擴充套件的無SQL儲存時，Cassandra是一個眾所周知的標準解決方案。 Cassandra在某些情況下執行良好，但EVCache更適合密集和持續的寫操作。