作者丨George Anadiotis

編譯丨布加迪

審校丨孫淑娟、梁策

Netflix 是怎么成功的?Investopedia 網(wǎng)站給出了三個答案：引人入勝的原創(chuàng)節(jié)目制作，針對訂閱服務(wù)而開展的用戶數(shù)據(jù)分析，以及允許用戶以自己喜愛的方式進(jìn)行內(nèi)容消費(fèi)。

可能這三點(diǎn)大多數(shù)人都同意。不過，Netflix 通過用戶數(shù)據(jù)和運(yùn)營數(shù)據(jù)分析來提高訂閱用戶服務(wù)水平，這方面背后的故事卻可能鮮為人知。Zhenzhong Xu 表示，在 Netflix 全球高速發(fā)展時期，業(yè)務(wù)和運(yùn)營決策比任何時候都依賴更快速的日志數(shù)據(jù)。

Xu 在 2015 年加入 Netflix，擔(dān)任實(shí)時數(shù)據(jù)基礎(chǔ)架構(gòu)團(tuán)隊(duì)的創(chuàng)始工程師，后來領(lǐng)導(dǎo)流處理引擎團(tuán)隊(duì)。他在 2010 年代初對實(shí)時數(shù)據(jù)產(chǎn)生興趣，從那時起就認(rèn)為這個領(lǐng)域大有可為。

Xu 于近期離開了 Netflix，開始在實(shí)時機(jī)器學(xué)習(xí)領(lǐng)域謀求發(fā)展。對于 Netflix 實(shí)時數(shù)據(jù)基礎(chǔ)架構(gòu)的開發(fā)之旅，Xu 認(rèn)為從 2015 到 2021 年是一段迭代過程。他將這段旅程分為四個階段：

第一階段：從失敗的批處理管道中拯救 Netflix 日志(2015 年)

第一階段涉及從失敗的批處理管道中拯救 Netflix 日志。在這個階段，Xu 的團(tuán)隊(duì)從頭開始構(gòu)建了一個流優(yōu)先平臺，以取代失敗的管道。

Xu 及其團(tuán)隊(duì)負(fù)責(zé)集中管理底層基礎(chǔ)架構(gòu)，以提供賦能機(jī)制，從而使產(chǎn)品團(tuán)隊(duì)能夠?qū)Ｗ⒂跇I(yè)務(wù)邏輯。

2015 年，Netflix 已經(jīng)擁有約 6000 萬訂閱用戶，并積極拓展全球影響力。平臺團(tuán)隊(duì)知道，迅速擴(kuò)大平臺影響力將是保持訂閱用戶迅猛增長的關(guān)鍵。

其中一個緊迫任務(wù)是 Xu 的團(tuán)隊(duì)必須弄清楚如何幫助 Netflix 擴(kuò)展日志實(shí)踐。當(dāng)時，Netflix 擁有 500 多個微服務(wù)，每天生成的數(shù)據(jù)量超過 10PB。

通過收集這些海量數(shù)據(jù)，Netflix 獲得了兩種認(rèn)知。首先，這有助于了解業(yè)務(wù)分析(比如用戶保留、平均會話長度和趨勢等)。其次，這有助于了解運(yùn)營層面(比如測量每秒流媒體播放量，以快速輕松地了解 Netflix 系統(tǒng)的健康狀況)，從而讓開發(fā)人員可以發(fā)出警報(bào)或執(zhí)行緩解措施。

Xu 表示，數(shù)據(jù)必須從生成數(shù)據(jù)的邊緣轉(zhuǎn)移到某個分析存儲區(qū)。所有數(shù)據(jù)人員都知道這么做的原因：微服務(wù)是為滿足運(yùn)營需求而建的，并使用聯(lián)機(jī)事務(wù)處理(OLTP)存儲。分析工具則需要聯(lián)機(jī)分析處理(OLAP)。

使用 OLTP 存儲來分析效果欠佳，還會降低那些服務(wù)的性能。因此，需要以低延遲的方式可靠地移動日志。到 2015 年，Netflix 的日志量已從 2011 年 450 億個事件 / 每天增加到 5000 億個事件 / 每天(數(shù)據(jù)攝取量達(dá) 1PB)。

現(xiàn)有的日志基礎(chǔ)架構(gòu)是一個簡單的批處理管道平臺，它用 Chukwa、Hadoop 和 Hive 構(gòu)建，面對每周訂閱用戶數(shù)量增加的現(xiàn)狀，很快就難以招架。Xu 的團(tuán)隊(duì)只有六個月左右的時間來開發(fā)流優(yōu)先解決方案，更為糟糕的是，他們只有六名團(tuán)隊(duì)成員來完成任務(wù)。

此外，Xu 特別指出了當(dāng)時流數(shù)據(jù)生態(tài)系統(tǒng)還不成熟的情況。很少有科技公司能在 Netflix 需要的那種規(guī)模下成功地部署流優(yōu)先解決方案，因此團(tuán)隊(duì)必須評估技術(shù)選項(xiàng)和試驗(yàn)方案，并決定構(gòu)建什么系統(tǒng)、看好哪些新興工具。

正是在那幾年，他們?yōu)?Netflix 的一些自主開發(fā)的產(chǎn)品(比如 Keystone 和 Mantis)打下了基礎(chǔ)。這些產(chǎn)品后來自立門戶，其中 Mantis 后來還開源了。

第二階段：擴(kuò)展到數(shù)百個數(shù)據(jù)移動用例(2016 年)

早期做出的一個關(guān)鍵決策是，分離問題而不是忽視問題。Xu 的團(tuán)隊(duì)通過單獨(dú)完善 Mantis(以運(yùn)營為重點(diǎn))和 Keystone(以分析為重點(diǎn))，將運(yùn)營用例和分析用例方面的問題分開來，但又為這兩個系統(tǒng)的對接留有余地。

他們還將內(nèi)容生產(chǎn)者和消費(fèi)者方面的問題分開來。為此，他們引入了生產(chǎn)者 / 消費(fèi)者客戶軟件，配備標(biāo)準(zhǔn)化有線協(xié)議和簡單模式管理，幫助分離生產(chǎn)者和消費(fèi)者的開發(fā)工作流程。后來證明這是數(shù)據(jù)治理和數(shù)據(jù)質(zhì)量控制的一個重要方面。

團(tuán)隊(duì)從面向微服務(wù)的單一職責(zé)原則入手，將整套基礎(chǔ)架構(gòu)分為消息傳遞(流傳輸)、處理(流處理)和控制平面。分離組件職責(zé)讓該團(tuán)隊(duì)能夠盡早確保界面一致，同時又通過關(guān)注不同的部分來釋放生產(chǎn)力。

除了資源限制和不成熟的生態(tài)系統(tǒng)外，團(tuán)隊(duì)最初還不得不面對這個事實(shí)：分析問題和運(yùn)營問題不一樣。分析型流處理專注于正確性和可預(yù)測性，運(yùn)營型流處理更專注于成本效益、延遲和可用性。

此外，對有狀態(tài)數(shù)據(jù)的平臺來說，云原生彈性問題有些棘手。在第一階段開始時，Netflix 已經(jīng)在 AWS 云上運(yùn)行了幾年。但是，它是首家將有狀態(tài)數(shù)據(jù)平臺搬到容器化云基礎(chǔ)架構(gòu)上的公司，這帶來了巨大的技術(shù)挑戰(zhàn)。

在交付最初的 Keystone 最簡可行產(chǎn)品(MVP)并遷移幾個內(nèi)部客戶之后，Xu 的團(tuán)隊(duì)逐漸獲得了信任，也得到其他工程團(tuán)隊(duì)認(rèn)可。因?yàn)楹苋菀滓苿尤罩居糜诜治鎏幚?、根?jù)需要獲得運(yùn)營洞察力，流媒體在 Netflix 受到追捧。現(xiàn)在是時候?yàn)槠胀蛻魯U(kuò)展規(guī)模了，而這帶來了一系列新的挑戰(zhàn)。

第一個挑戰(zhàn)是運(yùn)營負(fù)擔(dān)加重。最初他們?yōu)樾掠脩籼峁┘?xì)致入微的協(xié)助，但是隨著需求激增，這很快難以為繼。MVP 不得不與時俱進(jìn)，只支持十幾個客戶是不夠的。

第二個挑戰(zhàn)是出現(xiàn)了多樣化需求，出現(xiàn)了兩大客戶群。一群更喜歡易于使用的完全托管服務(wù)，另一群更愛靈活一些，需要復(fù)雜的計(jì)算能力來解決更高級的業(yè)務(wù)問題。Xu 指出，這兩大客戶群的需求很難同時兼顧。

第三個挑戰(zhàn)是，由于規(guī)模龐大，團(tuán)隊(duì)幾乎一度中斷了所有依賴的服務(wù)：從亞馬遜的 S3 到 Apache Kafka 和 Apache Flink，不一而足。不過，之前做出的戰(zhàn)略性選擇之一是，要與技術(shù)合作伙伴共同發(fā)展，即使?fàn)顟B(tài)并不理想成熟。

這些伙伴包括業(yè)內(nèi)許多領(lǐng)導(dǎo)流處理工作的品牌，比如領(lǐng)英，Apache Kafka 和 Samza 兩大項(xiàng)目正是誕生于此，Kafka 也由他們商業(yè)化;此外還有更名為 Ververica 的 Data Artisans，他們將 Apache Flink 商業(yè)化。

選擇合作途徑使團(tuán)隊(duì)能夠在利用社區(qū)成果的同時，按需求為開源軟件做貢獻(xiàn)。該團(tuán)隊(duì)在應(yīng)對與容器化云基礎(chǔ)架構(gòu)相關(guān)的挑戰(zhàn)方面與 Titus 團(tuán)隊(duì)進(jìn)行了合作。

Xu 還詳述了早期做出的更多關(guān)鍵決策，比如構(gòu)建專注幾個早期客戶的 MVP 產(chǎn)品。在探索最初的產(chǎn)品市場契合時，一不留神就會分心。然而，他們決定幫助幾個高優(yōu)先級、數(shù)據(jù)需求量大的內(nèi)部客戶，以后再考慮擴(kuò)大客戶群。

第三階段：支持定制需求，擴(kuò)展海量用例(2017 年 – 2019 年)

在整個第二階段，Xu 的團(tuán)隊(duì)再度做出了一些關(guān)鍵決策，這對他們大有助益。

他們選擇先專注于簡單性，而不是將基礎(chǔ)架構(gòu)的復(fù)雜性暴露在用戶面前，因?yàn)檫@讓團(tuán)隊(duì)能夠支持大多數(shù)數(shù)據(jù)移動和簡單的流式 ETL 用例，同時使用戶能夠?qū)Ｗ⒂跇I(yè)務(wù)邏輯。

他們決定投入完全托管的多租戶自助服務(wù)，而不是繼續(xù)提供細(xì)致入微的人工支持。在第一階段，他們選擇投入于構(gòu)建一個預(yù)料故障，并監(jiān)測所有運(yùn)營的系統(tǒng)，而不是延遲投入。在第二階段，他們繼續(xù)投入于 DevOps，旨在根據(jù)需要每天多次發(fā)布平臺變更。2017 年左右，團(tuán)隊(duì)認(rèn)為已建立了穩(wěn)固的運(yùn)營基礎(chǔ)：客戶很少在他們待命期間收到通知，所有基礎(chǔ)架構(gòu)問題都由平臺團(tuán)隊(duì)密切監(jiān)控和處理。強(qiáng)大的交付平臺已實(shí)施到位，在幾分鐘內(nèi)就能幫助客戶將變更引入生產(chǎn)環(huán)境。

Xu 特別指出，他們推出的 Keystone 產(chǎn)品在實(shí)現(xiàn)最初設(shè)想上非常出色：已成為一個易于使用、幾乎可以無限擴(kuò)展的流數(shù)據(jù)路由平臺。不過，很明顯流處理的潛力遠(yuǎn)未全部發(fā)揮出來。Xu 的團(tuán)隊(duì)不斷碰到新需求，需要對復(fù)雜的處理能力擁有更精細(xì)化的控制。Xu 寫道，Netflix 有獨(dú)特的自由和責(zé)任文化，每個團(tuán)隊(duì)有權(quán)做出自己的技術(shù)決策。該團(tuán)隊(duì)決定擴(kuò)大平臺的范圍，同時在此過程中遇到了一些新的挑戰(zhàn)。

第一個挑戰(zhàn)是自定義用例需要不同的開發(fā)者和運(yùn)營體驗(yàn)。比如說，Netflix 推薦的對象可以包括接下來要觀看的內(nèi)容、個性化的藝術(shù)作品，以及最佳展示區(qū)域等一系列內(nèi)容。

這些用例需要更高級的流處理功能，比如復(fù)雜的事件 / 處理時間和窗口語義、允許的延遲和大狀態(tài)檢查點(diǎn)管理。它們還需要更多的運(yùn)營支持、更靈活的編程接口以及能夠管理 TB 數(shù)據(jù)中本地狀態(tài)的基礎(chǔ)架構(gòu)。

第二個挑戰(zhàn)是兼顧靈活性和簡單性。針對所有新的自定義用例，團(tuán)隊(duì)必須對暴露水平進(jìn)行合理控制。此外，支持自定義用例要求增加平臺的自由度，而這也是第三個挑戰(zhàn)：運(yùn)營復(fù)雜性增加。

最后，團(tuán)隊(duì)的職責(zé)是提供一個集中式流處理平臺。但由于之前的策略專注于簡單性，一些團(tuán)隊(duì)已使用不受支持的技術(shù)投入到了他們的本地流處理平臺——用 Netflix 的話來說，就是“舍近求遠(yuǎn)”。Xu 的團(tuán)隊(duì)不得不說服他們搬回到托管平臺。這也是第四個挑戰(zhàn)：集中平臺與本地平臺之爭。

在第三階段，F(xiàn)link 被引入進(jìn)來，由 Xu 的團(tuán)隊(duì)管理。他們決定構(gòu)建一個新的產(chǎn)品入口點(diǎn)，這是對現(xiàn)有架構(gòu)的重構(gòu)，而不是孤立地構(gòu)建新產(chǎn)品。Flink 充當(dāng)這個入口點(diǎn)，重構(gòu)有助于盡量減少冗余問題。

另一個關(guān)鍵決策是先從流式 ETL 和可觀察性用例入手，而不是一次性處理所有自定義用例。由于這些用例難度大、規(guī)模大，極具挑戰(zhàn)性，Xu 認(rèn)為先處理最困難的用例并從中汲取經(jīng)驗(yàn)是明智之舉。

這時候做出的最后一個關(guān)鍵決策是，一開始與客戶分擔(dān)運(yùn)營責(zé)任，然后隨著時間的推移，逐漸共謀創(chuàng)新，以減輕負(fù)擔(dān)。早期采用者自給自足，細(xì)致入微的支持幫助了那些無法做到的人。久而久之，自動擴(kuò)展和托管部署等運(yùn)營投入也相繼到位。

第四階段：擴(kuò)大流處理方面的職責(zé)(2020 年至今)

隨著流處理用例擴(kuò)展到 Netflix 的所有部門，人們發(fā)現(xiàn)了全新模式，團(tuán)隊(duì)也獲得了早期的成功。但隨著 Netflix 繼續(xù)探索新領(lǐng)域，并大力投入于內(nèi)容制作和游戲上，一系列新的挑戰(zhàn)隨之而來。

第一個挑戰(zhàn)是團(tuán)隊(duì)自治的弊端。由于團(tuán)隊(duì)有權(quán)做出自己的決定，因此 Netflix 許多團(tuán)隊(duì)使用的數(shù)據(jù)技術(shù)各種各樣，迥異的數(shù)據(jù)技術(shù)使協(xié)調(diào)變得困難。Xu 寫道，有許多技術(shù)可供選擇，人們自然會將技術(shù)分門別類，而有分類的存在就會阻礙組織往前推進(jìn)。第二個挑戰(zhàn)是學(xué)習(xí)難度更大。由于可用的數(shù)據(jù)工具越來越多，專業(yè)化程度不斷加深，用戶學(xué)習(xí)和決定什么技術(shù)適合特定的用例顯得困難重重。

Xu 特別指出，第三個挑戰(zhàn)是機(jī)器學(xué)習(xí)實(shí)踐沒有充分發(fā)揮數(shù)據(jù)平臺的力量。所有上述的挑戰(zhàn)都會對機(jī)器學(xué)習(xí)實(shí)踐造成影響。數(shù)據(jù)科學(xué)家的反饋環(huán)路很長，數(shù)據(jù)工程師的生產(chǎn)力受到影響，產(chǎn)品工程師在共享有價值的數(shù)據(jù)方面遇到了挑戰(zhàn)。最終，許多企業(yè)失去了抓住市場瞬息變化的大好機(jī)會。

第四個挑戰(zhàn)是中央平臺模型的規(guī)模限制。Xu 特別指出，由于中央數(shù)據(jù)平臺以超線性的速度擴(kuò)展用例，使用單一聯(lián)系點(diǎn)來支持是無以為繼的。應(yīng)評估注重支持構(gòu)建在中央平臺上的本地平臺的模式，現(xiàn)在正是最佳時機(jī)。

Xu 在此過程中汲取了寶貴的經(jīng)驗(yàn)，一些經(jīng)驗(yàn)可能產(chǎn)品負(fù)責(zé)人也很熟悉，并適用于流數(shù)據(jù)之外的領(lǐng)域。比如營造失敗也沒有關(guān)系的氛圍、決定不開發(fā)什么內(nèi)容、鼓勵用戶成為平臺忠粉，以及在壓力下保持鎮(zhèn)靜。有興趣的讀者可以參閱(https://zhenzhongxu.com/the-four-innovation-phases-of-netflixs-trillions-scale-real-time-data-infrastructure-2370938d7f01)。

在第四階段及之外，Xu 也看到了實(shí)時數(shù)據(jù)處理的特殊機(jī)會。數(shù)據(jù)流可以連接世界，并可以通過結(jié)合簡單性和靈活性來提高抽象性，更好地滿足機(jī)器學(xué)習(xí)的需求。