本文我們將探索如何創(chuàng)建一個能夠交付并支持快速創(chuàng)新的軟件架構(gòu)。提出一種能夠處理大量現(xiàn)有數(shù)據(jù)、響應(yīng)用戶交互并易于試驗新的推薦方法的軟件體系結(jié)構(gòu)并非易事。在這篇文章中，我們將描述我們?nèi)绾谓鉀QNetflix面臨的一些挑戰(zhàn)。

首先，我們在下圖中展示了推薦系統(tǒng)的總體系統(tǒng)圖。該體系結(jié)構(gòu)的主要組件包含一個或多個機器學(xué)習算法。

對于數(shù)據(jù)，我們能做的最簡單的事情就是將其存儲起來，以便稍后進行脫機處理，這就引出了管理脫機作業(yè)的部分體系結(jié)構(gòu)。然而，計算可以離線、近線或在線進行。在線計算可以更好地響應(yīng)最近的事件和用戶交互，但必須實時響應(yīng)請求。這可以限制所使用算法的計算復(fù)雜度以及可處理的數(shù)據(jù)量。離線計算對數(shù)據(jù)量和算法的計算復(fù)雜度的限制較小，因為它以批處理方式運行，對時間的要求比較寬松。但是，由于沒有包含最新的數(shù)據(jù)，在更新的過程中很容易變得陳舊。

個性化體系結(jié)構(gòu)中的一個關(guān)鍵問題是如何以無縫的方式組合和管理在線和離線計算。近線計算是這兩種模式之間的一種折衷，在這種模式下，我們可以執(zhí)行類似于在線的計算，但不要求它們是實時的。模型訓(xùn)練是使用現(xiàn)有數(shù)據(jù)生成模型的另一種計算形式，該模型稍后將在實際計算結(jié)果時使用。體系結(jié)構(gòu)的另一部分描述了事件和數(shù)據(jù)分發(fā)系統(tǒng)需要如何處理不同類型的事件和數(shù)據(jù)。一個相關(guān)的問題是如何組合不同的信號和模型，這些信號和模型是離線、近線和在線系統(tǒng)所需要的。最后，我們還需要找出如何以一種對用戶有意義的方式組合中間推薦結(jié)果。

本文的其余部分將詳細介紹此體系結(jié)構(gòu)的這些組件及其交互。為了做到這一點，我們將把一般的圖分解成不同的子系統(tǒng)，并且我們將詳細討論每一個子系統(tǒng)。當您繼續(xù)閱讀本文時，值得記住的是，我們的整個基礎(chǔ)設(shè)施都運行在公共Amazon Web Services云上。

Offline, Nearline, and Online Computation

如上所述，我們的算法結(jié)果既可以在線實時計算，也可以離線批量計算，或者在兩者之間的近線計算。每種方法都有其優(yōu)點和缺點，需要考慮到每種用例。

在線計算可以快速響應(yīng)事件并使用最新的數(shù)據(jù)。例如，使用當前上下文為成員組裝一個動作電影庫。在線組件受可用性和響應(yīng)時間服務(wù)級別協(xié)議(SLA)的約束，SLA指定了在我們的成員等待建議出現(xiàn)時響應(yīng)客戶端應(yīng)用程序請求的流程的最大延遲。這使得用這種方法來擬合復(fù)雜且計算量大的算法變得更加困難。此外，在某些情況下，純在線計算可能無法滿足其SLA，因此考慮快速回退機制(如恢復(fù)到預(yù)計算結(jié)果)總是很重要的。在線計算還意味著所涉及的各種數(shù)據(jù)源也需要在線可用，這可能需要額外的基礎(chǔ)設(shè)施。

另一方面，離線計算允許在算法方法上有更多的選擇，比如復(fù)雜的算法，并且對使用的數(shù)據(jù)量有更少的限制。一個簡單的例子可能是定期聚合來自數(shù)百萬電影播放事件的統(tǒng)計數(shù)據(jù)，以編譯推薦的基準流行度指標。離線系統(tǒng)也有更簡單的工程需求。例如，可以很容易地滿足客戶機施加的寬松響應(yīng)時間sla。可以在生產(chǎn)環(huán)境中部署新的算法，而不需要在性能調(diào)優(yōu)方面投入太多精力。這種靈活性支持敏捷創(chuàng)新。在Netflix,我們利用這個來支持快速實驗:如果一個新的實驗算法執(zhí)行慢,我們可以選擇簡單的部署更多的Amazon EC2實例來達到所需的吞吐量運行實驗,而不是花費寶貴的工程時間算法的優(yōu)化性能,可能小的業(yè)務(wù)價值。然而，由于離線處理沒有很強的延遲需求，它不會對上下文或新數(shù)據(jù)中的更改做出快速反應(yīng)。最終，這可能導(dǎo)致過時，降低成員的體驗。離線計算還需要存儲、計算和訪問大量預(yù)計算結(jié)果集的基礎(chǔ)設(shè)施。

近線計算可以看作是前兩種模式的折衷。在本例中，計算的執(zhí)行與在線情況完全相同。但是，我們刪除了在計算結(jié)果時立即提供結(jié)果的需求，并可以存儲它們，從而允許它是異步的。近線計算是根據(jù)用戶事件進行的，因此系統(tǒng)可以在請求之間做出更快速的響應(yīng)。這為每個事件可能進行的更復(fù)雜的處理打開了大門。例如，更新建議，以反映在成員開始觀看電影之后，電影已經(jīng)立即被觀看。結(jié)果可以存儲在中間緩存或后端存儲中。近線計算也是應(yīng)用增量學(xué)習算法的一種自然設(shè)置。

在任何情況下，選擇聯(lián)機/近線/脫機處理都不是一個非此即非的問題。所有的方法都可以而且應(yīng)該結(jié)合起來。組合它們的方法有很多。我們已經(jīng)提到了使用離線計算作為備份的想法。另一種選擇是使用離線進程預(yù)先計算結(jié)果的一部分，而將算法中成本較低或上下文敏感的部分留給在線計算。

甚至建模部分也可以以離線/在線混合方式完成。在傳統(tǒng)的監(jiān)督分類應(yīng)用中，分類器必須從標記數(shù)據(jù)批量訓(xùn)練，并且只能在線應(yīng)用于對新輸入進行分類，這并不自然適合。然而，矩陣分解等方法更自然地適合于混合的在線/離線建模:一些因素可以離線預(yù)先計算，而另一些可以實時更新，以創(chuàng)建更新鮮的結(jié)果。其他非監(jiān)督方法，如集群，也允許離線計算集群中心和在線分配集群。這些例子表明，一方面可以將我們的模型培訓(xùn)劃分為大規(guī)模的、潛在復(fù)雜的全局模型培訓(xùn)，另一方面可以在線執(zhí)行更輕松的特定于用戶的模型培訓(xùn)或更新階段。

Offline Jobs

當運行個性化機器學(xué)習算法時，我們需要做的大部分計算都可以離線完成。這意味著可以將作業(yè)計劃為定期執(zhí)行，并且它們的執(zhí)行不需要與結(jié)果的請求或表示同步。這類任務(wù)主要有兩類:模型訓(xùn)練和中間結(jié)果或最終結(jié)果的批處理計算。在模型訓(xùn)練工作中，我們收集相關(guān)的現(xiàn)有數(shù)據(jù)，應(yīng)用機器學(xué)習算法生成一組模型參數(shù)(我們將其稱為模型)。這個模型通常會被編碼并存儲在一個文件中供以后使用。雖然大多數(shù)模型都是離線批處理模式培訓(xùn)的，但我們也有一些在線學(xué)習技術(shù)，其中增量培訓(xùn)確實是在線執(zhí)行的。批量計算結(jié)果是上面定義的離線計算過程，我們使用現(xiàn)有的模型和相應(yīng)的輸入數(shù)據(jù)來計算結(jié)果，這些結(jié)果將在稍后用于后續(xù)的在線處理或直接呈現(xiàn)給用戶。

這兩個任務(wù)都需要處理精制的數(shù)據(jù)，而這些數(shù)據(jù)通常是通過運行數(shù)據(jù)庫查詢生成的。由于這些查詢運行在大量數(shù)據(jù)上，因此以分布式方式運行它們是有益的，這使得它們非常適合通過Hive或Pig作業(yè)在Hadoop上運行。一旦查詢完成，我們就需要一種發(fā)布結(jié)果數(shù)據(jù)的機制。我們對該機制有幾個要求:首先，當查詢結(jié)果準備好時，它應(yīng)該通知訂閱者。其次，它應(yīng)該支持不同的存儲庫(例如，不僅支持HDFS，還支持S3或Cassandra)。最后，它應(yīng)該透明地處理錯誤，允許監(jiān)視和警報。在Netflix，我們使用一個名為Hermes的內(nèi)部工具，它提供所有這些功能，并將它們集成到一個一致的發(fā)布-訂閱框架中。它允許向訂閱者提供近乎實時的數(shù)據(jù)。在某種意義上，它涵蓋了與Apache Kafka相同的一些用例，但它不是消息/事件隊列系統(tǒng)。

信號和模型

無論我們是在線計算還是離線計算，我們都需要考慮算法將如何處理三種輸入:模型、數(shù)據(jù)和信號。模型通常是之前離線訓(xùn)練的參數(shù)的小文件。數(shù)據(jù)是預(yù)先處理的信息，這些信息已經(jīng)存儲在某種數(shù)據(jù)庫中，比如電影元數(shù)據(jù)或流行度。我們使用"信號"這個術(shù)語來指代我們輸入到算法中的新信息。這些數(shù)據(jù)來自live services，可以由用戶相關(guān)的信息(如成員最近觀看了什么)或上下文數(shù)據(jù)(如會話、設(shè)備、日期或時間)組成。

Event & Data Distribution

我們的目標是將成員交互數(shù)據(jù)轉(zhuǎn)換為可用于改進成員體驗的洞察力。因此，我們希望Netflix的各種用戶界面應(yīng)用程序(智能電視、平板電腦、游戲機等)不僅能提供令人愉快的用戶體驗，還能收集盡可能多的用戶事件。這些操作可以與任何時候的單擊、瀏覽、查看，甚至是視圖的內(nèi)容相關(guān)。然后可以聚合事件，為我們的算法提供基本數(shù)據(jù)。在這里，我們試圖在數(shù)據(jù)和事件之間做出區(qū)分，盡管邊界肯定是模糊的。我們認為事件是時間敏感信息的小單元，需要以盡可能少的延遲處理。這些事件被路由來觸發(fā)后續(xù)的操作或過程，例如更新近線結(jié)果集。另一方面，我們認為數(shù)據(jù)是更密集的信息單元，可能需要處理和存儲以便稍后使用。在這里，延遲并不像信息的質(zhì)量和數(shù)量那么重要。當然，有些用戶事件可以同時作為事件和數(shù)據(jù)處理，因此可以發(fā)送到兩個流。

在Netflix，我們近乎實時的活動流程是通過一個名為Manhattan的內(nèi)部框架來管理的。曼哈頓是一個分布式計算系統(tǒng)，它是我們推薦算法體系結(jié)構(gòu)的核心。這有點類似于Twitter的Storm，但它解決了不同的問題，并響應(yīng)了不同的一組內(nèi)部需求。數(shù)據(jù)流主要通過從Chukwa到Hadoop的日志記錄來管理，以完成流程的初始步驟。稍后，我們使用Hermes作為發(fā)布-訂閱機制。

推薦結(jié)果

我們機器學(xué)習方法的目標是提出個性化的建議。這些推薦結(jié)果可以直接從我們之前計算過的列表中得到，也可以通過在線算法動態(tài)生成。當然，我們可以考慮同時使用這兩種方法，離線計算推薦的大部分內(nèi)容，并使用使用實時信號的在線算法對列表進行后處理，從而增加一些新鮮度。

在Netflix，我們將離線和中間結(jié)果存儲在各種存儲庫中，以便稍后在請求時使用:我們使用的主要數(shù)據(jù)存儲庫是Cassandra、EVCache和MySQL。每種解決方案都有其優(yōu)缺點。MySQL允許存儲結(jié)構(gòu)化關(guān)系數(shù)據(jù)，這些數(shù)據(jù)將來可能需要通過通用查詢進行處理。然而，這種通用性是以分布式環(huán)境中的可伸縮性問題為代價的。Cassandra和EVCache都提供了鍵值存儲的優(yōu)點。當需要分布式和可伸縮的無sql存儲時，Cassandra是一個著名的標準解決方案。Cassandra在某些情況下工作得很好，但是在我們需要密集且持續(xù)的寫操作的情況下，我們發(fā)現(xiàn)EVCache更適合。然而，關(guān)鍵問題不在于將它們存儲在哪里，而在于如何以一種相互沖突的目標(如查詢復(fù)雜性、讀寫延遲和事務(wù)一致性)在每個用例的最優(yōu)點上滿足的方式處理需求。

結(jié)論

在以前的文章中，我們強調(diào)了數(shù)據(jù)、模型和用戶界面對于創(chuàng)建世界級推薦系統(tǒng)的重要性。在構(gòu)建這樣一個系統(tǒng)時，還必須考慮將在其中部署該系統(tǒng)的軟件體系結(jié)構(gòu)。我們希望能夠使用復(fù)雜的機器學(xué)習算法，可以增長到任意的復(fù)雜性，并能夠處理大量的數(shù)據(jù)。我們還需要一個允許靈活和敏捷創(chuàng)新的體系結(jié)構(gòu)，在這個體系結(jié)構(gòu)中可以輕松地開發(fā)和插入新方法。此外，我們希望我們的推薦結(jié)果是新鮮的，并快速響應(yīng)新的數(shù)據(jù)和用戶操作。在這些需求之間找到最佳平衡點并非易事:它需要對需求進行深思熟慮的分析，仔細選擇技術(shù)，并對推薦算法進行戰(zhàn)略性分解，從而為我們的成員實現(xiàn)最佳結(jié)果。