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

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

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

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

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

Offline, Nearline, and Online Computation

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

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

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

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

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

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

Offline Jobs

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

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

信號(hào)和模型

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

Event & Data Distribution

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

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

推薦結(jié)果

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

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

結(jié)論

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