作者丨George Anadiotis
編譯丨布加迪
審校丨孫淑娟、梁策
Netflix 是怎么成功的?Investopedia 網(wǎng)站給出了三個(gè)答案:引人入勝的原創(chuàng)節(jié)目制作,針對(duì)訂閱服務(wù)而開展的用戶數(shù)據(jù)分析,以及允許用戶以自己喜愛的方式進(jìn)行內(nèi)容消費(fèi)。
可能這三點(diǎn)大多數(shù)人都同意。不過(guò),Netflix 通過(guò)用戶數(shù)據(jù)和運(yùn)營(yíng)數(shù)據(jù)分析來(lái)提高訂閱用戶服務(wù)水平,這方面背后的故事卻可能鮮為人知。Zhenzhong Xu 表示,在 Netflix 全球高速發(fā)展時(shí)期,業(yè)務(wù)和運(yùn)營(yíng)決策比任何時(shí)候都依賴更快速的日志數(shù)據(jù)。
Xu 在 2015 年加入 Netflix,擔(dān)任實(shí)時(shí)數(shù)據(jù)基礎(chǔ)架構(gòu)團(tuán)隊(duì)的創(chuàng)始工程師,后來(lái)領(lǐng)導(dǎo)流處理引擎團(tuán)隊(duì)。他在 2010 年代初對(duì)實(shí)時(shí)數(shù)據(jù)產(chǎn)生興趣,從那時(shí)起就認(rèn)為這個(gè)領(lǐng)域大有可為。
Xu 于近期離開了 Netflix,開始在實(shí)時(shí)機(jī)器學(xué)習(xí)領(lǐng)域謀求發(fā)展。對(duì)于 Netflix 實(shí)時(shí)數(shù)據(jù)基礎(chǔ)架構(gòu)的開發(fā)之旅,Xu 認(rèn)為從 2015 到 2021 年是一段迭代過(guò)程。他將這段旅程分為四個(gè)階段:
第一階段:從失敗的批處理管道中拯救 Netflix 日志(2015 年)
第一階段涉及從失敗的批處理管道中拯救 Netflix 日志。在這個(gè)階段,Xu 的團(tuán)隊(duì)從頭開始構(gòu)建了一個(gè)流優(yōu)先平臺(tái),以取代失敗的管道。
Xu 及其團(tuán)隊(duì)負(fù)責(zé)集中管理底層基礎(chǔ)架構(gòu),以提供賦能機(jī)制,從而使產(chǎn)品團(tuán)隊(duì)能夠?qū)W⒂跇I(yè)務(wù)邏輯。
2015 年,Netflix 已經(jīng)擁有約 6000 萬(wàn)訂閱用戶,并積極拓展全球影響力。平臺(tái)團(tuán)隊(duì)知道,迅速擴(kuò)大平臺(tái)影響力將是保持訂閱用戶迅猛增長(zhǎng)的關(guān)鍵。
其中一個(gè)緊迫任務(wù)是 Xu 的團(tuán)隊(duì)必須弄清楚如何幫助 Netflix 擴(kuò)展日志實(shí)踐。當(dāng)時(shí),Netflix 擁有 500 多個(gè)微服務(wù),每天生成的數(shù)據(jù)量超過(guò) 10PB。
通過(guò)收集這些海量數(shù)據(jù),Netflix 獲得了兩種認(rèn)知。首先,這有助于了解業(yè)務(wù)分析(比如用戶保留、平均會(huì)話長(zhǎng)度和趨勢(shì)等)。其次,這有助于了解運(yùn)營(yíng)層面(比如測(cè)量每秒流媒體播放量,以快速輕松地了解 Netflix 系統(tǒng)的健康狀況),從而讓開發(fā)人員可以發(fā)出警報(bào)或執(zhí)行緩解措施。
Xu 表示,數(shù)據(jù)必須從生成數(shù)據(jù)的邊緣轉(zhuǎn)移到某個(gè)分析存儲(chǔ)區(qū)。所有數(shù)據(jù)人員都知道這么做的原因:微服務(wù)是為滿足運(yùn)營(yíng)需求而建的,并使用聯(lián)機(jī)事務(wù)處理(OLTP)存儲(chǔ)。分析工具則需要聯(lián)機(jī)分析處理(OLAP)。
使用 OLTP 存儲(chǔ)來(lái)分析效果欠佳,還會(huì)降低那些服務(wù)的性能。因此,需要以低延遲的方式可靠地移動(dòng)日志。到 2015 年,Netflix 的日志量已從 2011 年 450 億個(gè)事件 / 每天增加到 5000 億個(gè)事件 / 每天(數(shù)據(jù)攝取量達(dá) 1PB)。
現(xiàn)有的日志基礎(chǔ)架構(gòu)是一個(gè)簡(jiǎn)單的批處理管道平臺(tái),它用 Chukwa、Hadoop 和 Hive 構(gòu)建,面對(duì)每周訂閱用戶數(shù)量增加的現(xiàn)狀,很快就難以招架。Xu 的團(tuán)隊(duì)只有六個(gè)月左右的時(shí)間來(lái)開發(fā)流優(yōu)先解決方案,更為糟糕的是,他們只有六名團(tuán)隊(duì)成員來(lái)完成任務(wù)。
此外,Xu 特別指出了當(dāng)時(shí)流數(shù)據(jù)生態(tài)系統(tǒng)還不成熟的情況。很少有科技公司能在 Netflix 需要的那種規(guī)模下成功地部署流優(yōu)先解決方案,因此團(tuán)隊(duì)必須評(píng)估技術(shù)選項(xiàng)和試驗(yàn)方案,并決定構(gòu)建什么系統(tǒng)、看好哪些新興工具。
正是在那幾年,他們?yōu)?Netflix 的一些自主開發(fā)的產(chǎn)品(比如 Keystone 和 Mantis)打下了基礎(chǔ)。這些產(chǎn)品后來(lái)自立門戶,其中 Mantis 后來(lái)還開源了。
第二階段:擴(kuò)展到數(shù)百個(gè)數(shù)據(jù)移動(dòng)用例(2016 年)
早期做出的一個(gè)關(guān)鍵決策是,分離問(wèn)題而不是忽視問(wèn)題。Xu 的團(tuán)隊(duì)通過(guò)單獨(dú)完善 Mantis(以運(yùn)營(yíng)為重點(diǎn))和 Keystone(以分析為重點(diǎn)),將運(yùn)營(yíng)用例和分析用例方面的問(wèn)題分開來(lái),但又為這兩個(gè)系統(tǒng)的對(duì)接留有余地。
他們還將內(nèi)容生產(chǎn)者和消費(fèi)者方面的問(wèn)題分開來(lái)。為此,他們引入了生產(chǎn)者 / 消費(fèi)者客戶軟件,配備標(biāo)準(zhǔn)化有線協(xié)議和簡(jiǎn)單模式管理,幫助分離生產(chǎn)者和消費(fèi)者的開發(fā)工作流程。后來(lái)證明這是數(shù)據(jù)治理和數(shù)據(jù)質(zhì)量控制的一個(gè)重要方面。
團(tuán)隊(duì)從面向微服務(wù)的單一職責(zé)原則入手,將整套基礎(chǔ)架構(gòu)分為消息傳遞(流傳輸)、處理(流處理)和控制平面。分離組件職責(zé)讓該團(tuán)隊(duì)能夠盡早確保界面一致,同時(shí)又通過(guò)關(guān)注不同的部分來(lái)釋放生產(chǎn)力。
除了資源限制和不成熟的生態(tài)系統(tǒng)外,團(tuán)隊(duì)最初還不得不面對(duì)這個(gè)事實(shí):分析問(wèn)題和運(yùn)營(yíng)問(wèn)題不一樣。分析型流處理專注于正確性和可預(yù)測(cè)性,運(yùn)營(yíng)型流處理更專注于成本效益、延遲和可用性。
此外,對(duì)有狀態(tài)數(shù)據(jù)的平臺(tái)來(lái)說(shuō),云原生彈性問(wèn)題有些棘手。在第一階段開始時(shí),Netflix 已經(jīng)在 AWS 云上運(yùn)行了幾年。但是,它是首家將有狀態(tài)數(shù)據(jù)平臺(tái)搬到容器化云基礎(chǔ)架構(gòu)上的公司,這帶來(lái)了巨大的技術(shù)挑戰(zhàn)。
在交付最初的 Keystone 最簡(jiǎn)可行產(chǎn)品(MVP)并遷移幾個(gè)內(nèi)部客戶之后,Xu 的團(tuán)隊(duì)逐漸獲得了信任,也得到其他工程團(tuán)隊(duì)認(rèn)可。因?yàn)楹苋菀滓苿?dòng)日志用于分析處理、根據(jù)需要獲得運(yùn)營(yíng)洞察力,流媒體在 Netflix 受到追捧?,F(xiàn)在是時(shí)候?yàn)槠胀蛻魯U(kuò)展規(guī)模了,而這帶來(lái)了一系列新的挑戰(zhàn)。
第一個(gè)挑戰(zhàn)是運(yùn)營(yíng)負(fù)擔(dān)加重。最初他們?yōu)樾掠脩籼峁┘?xì)致入微的協(xié)助,但是隨著需求激增,這很快難以為繼。MVP 不得不與時(shí)俱進(jìn),只支持十幾個(gè)客戶是不夠的。
第二個(gè)挑戰(zhàn)是出現(xiàn)了多樣化需求,出現(xiàn)了兩大客戶群。一群更喜歡易于使用的完全托管服務(wù),另一群更愛靈活一些,需要復(fù)雜的計(jì)算能力來(lái)解決更高級(jí)的業(yè)務(wù)問(wèn)題。Xu 指出,這兩大客戶群的需求很難同時(shí)兼顧。
第三個(gè)挑戰(zhàn)是,由于規(guī)模龐大,團(tuán)隊(duì)幾乎一度中斷了所有依賴的服務(wù):從亞馬遜的 S3 到 Apache Kafka 和 Apache Flink,不一而足。不過(guò),之前做出的戰(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ū)成果的同時(shí),按需求為開源軟件做貢獻(xiàn)。該團(tuán)隊(duì)在應(yīng)對(duì)與容器化云基礎(chǔ)架構(gòu)相關(guān)的挑戰(zhàn)方面與 Titus 團(tuán)隊(duì)進(jìn)行了合作。
Xu 還詳述了早期做出的更多關(guān)鍵決策,比如構(gòu)建專注幾個(gè)早期客戶的 MVP 產(chǎn)品。在探索最初的產(chǎn)品市場(chǎng)契合時(shí),一不留神就會(huì)分心。然而,他們決定幫助幾個(gè)高優(yōu)先級(jí)、數(shù)據(jù)需求量大的內(nèi)部客戶,以后再考慮擴(kuò)大客戶群。
第三階段:支持定制需求,擴(kuò)展海量用例(2017 年 – 2019 年)
在整個(gè)第二階段,Xu 的團(tuán)隊(duì)再度做出了一些關(guān)鍵決策,這對(duì)他們大有助益。
他們選擇先專注于簡(jiǎn)單性,而不是將基礎(chǔ)架構(gòu)的復(fù)雜性暴露在用戶面前,因?yàn)檫@讓團(tuán)隊(duì)能夠支持大多數(shù)數(shù)據(jù)移動(dòng)和簡(jiǎn)單的流式 ETL 用例,同時(shí)使用戶能夠?qū)W⒂跇I(yè)務(wù)邏輯。
他們決定投入完全托管的多租戶自助服務(wù),而不是繼續(xù)提供細(xì)致入微的人工支持。在第一階段,他們選擇投入于構(gòu)建一個(gè)預(yù)料故障,并監(jiān)測(cè)所有運(yùn)營(yíng)的系統(tǒng),而不是延遲投入。在第二階段,他們繼續(xù)投入于 DevOps,旨在根據(jù)需要每天多次發(fā)布平臺(tái)變更。2017 年左右,團(tuán)隊(duì)認(rèn)為已建立了穩(wěn)固的運(yùn)營(yíng)基礎(chǔ):客戶很少在他們待命期間收到通知,所有基礎(chǔ)架構(gòu)問(wèn)題都由平臺(tái)團(tuán)隊(duì)密切監(jiān)控和處理。強(qiáng)大的交付平臺(tái)已實(shí)施到位,在幾分鐘內(nèi)就能幫助客戶將變更引入生產(chǎn)環(huán)境。
Xu 特別指出,他們推出的 Keystone 產(chǎn)品在實(shí)現(xiàn)最初設(shè)想上非常出色:已成為一個(gè)易于使用、幾乎可以無(wú)限擴(kuò)展的流數(shù)據(jù)路由平臺(tái)。不過(guò),很明顯流處理的潛力遠(yuǎn)未全部發(fā)揮出來(lái)。Xu 的團(tuán)隊(duì)不斷碰到新需求,需要對(duì)復(fù)雜的處理能力擁有更精細(xì)化的控制。Xu 寫道,Netflix 有獨(dú)特的自由和責(zé)任文化,每個(gè)團(tuán)隊(duì)有權(quán)做出自己的技術(shù)決策。該團(tuán)隊(duì)決定擴(kuò)大平臺(tái)的范圍,同時(shí)在此過(guò)程中遇到了一些新的挑戰(zhàn)。
第一個(gè)挑戰(zhàn)是自定義用例需要不同的開發(fā)者和運(yùn)營(yíng)體驗(yàn)。比如說(shuō),Netflix 推薦的對(duì)象可以包括接下來(lái)要觀看的內(nèi)容、個(gè)性化的藝術(shù)作品,以及最佳展示區(qū)域等一系列內(nèi)容。
這些用例需要更高級(jí)的流處理功能,比如復(fù)雜的事件 / 處理時(shí)間和窗口語(yǔ)義、允許的延遲和大狀態(tài)檢查點(diǎn)管理。它們還需要更多的運(yùn)營(yíng)支持、更靈活的編程接口以及能夠管理 TB 數(shù)據(jù)中本地狀態(tài)的基礎(chǔ)架構(gòu)。
第二個(gè)挑戰(zhàn)是兼顧靈活性和簡(jiǎn)單性。針對(duì)所有新的自定義用例,團(tuán)隊(duì)必須對(duì)暴露水平進(jìn)行合理控制。此外,支持自定義用例要求增加平臺(tái)的自由度,而這也是第三個(gè)挑戰(zhàn):運(yùn)營(yíng)復(fù)雜性增加。
最后,團(tuán)隊(duì)的職責(zé)是提供一個(gè)集中式流處理平臺(tái)。但由于之前的策略專注于簡(jiǎn)單性,一些團(tuán)隊(duì)已使用不受支持的技術(shù)投入到了他們的本地流處理平臺(tái)——用 Netflix 的話來(lái)說(shuō),就是“舍近求遠(yuǎn)”。Xu 的團(tuán)隊(duì)不得不說(shuō)服他們搬回到托管平臺(tái)。這也是第四個(gè)挑戰(zhàn):集中平臺(tái)與本地平臺(tái)之爭(zhēng)。
在第三階段,F(xiàn)link 被引入進(jìn)來(lái),由 Xu 的團(tuán)隊(duì)管理。他們決定構(gòu)建一個(gè)新的產(chǎn)品入口點(diǎn),這是對(duì)現(xiàn)有架構(gòu)的重構(gòu),而不是孤立地構(gòu)建新產(chǎn)品。Flink 充當(dāng)這個(gè)入口點(diǎn),重構(gòu)有助于盡量減少冗余問(wèn)題。
另一個(gè)關(guān)鍵決策是先從流式 ETL 和可觀察性用例入手,而不是一次性處理所有自定義用例。由于這些用例難度大、規(guī)模大,極具挑戰(zhàn)性,Xu 認(rèn)為先處理最困難的用例并從中汲取經(jīng)驗(yàn)是明智之舉。
這時(shí)候做出的最后一個(gè)關(guān)鍵決策是,一開始與客戶分擔(dān)運(yùn)營(yíng)責(zé)任,然后隨著時(shí)間的推移,逐漸共謀創(chuàng)新,以減輕負(fù)擔(dān)。早期采用者自給自足,細(xì)致入微的支持幫助了那些無(wú)法做到的人。久而久之,自動(dòng)擴(kuò)展和托管部署等運(yùn)營(yíng)投入也相繼到位。
第四階段:擴(kuò)大流處理方面的職責(zé)(2020 年至今)
隨著流處理用例擴(kuò)展到 Netflix 的所有部門,人們發(fā)現(xiàn)了全新模式,團(tuán)隊(duì)也獲得了早期的成功。但隨著 Netflix 繼續(xù)探索新領(lǐng)域,并大力投入于內(nèi)容制作和游戲上,一系列新的挑戰(zhàn)隨之而來(lái)。
第一個(gè)挑戰(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ù)可供選擇,人們自然會(huì)將技術(shù)分門別類,而有分類的存在就會(huì)阻礙組織往前推進(jìn)。第二個(gè)挑戰(zhàn)是學(xué)習(xí)難度更大。由于可用的數(shù)據(jù)工具越來(lái)越多,專業(yè)化程度不斷加深,用戶學(xué)習(xí)和決定什么技術(shù)適合特定的用例顯得困難重重。
Xu 特別指出,第三個(gè)挑戰(zhàn)是機(jī)器學(xué)習(xí)實(shí)踐沒有充分發(fā)揮數(shù)據(jù)平臺(tái)的力量。所有上述的挑戰(zhàn)都會(huì)對(duì)機(jī)器學(xué)習(xí)實(shí)踐造成影響。數(shù)據(jù)科學(xué)家的反饋環(huán)路很長(zhǎng),數(shù)據(jù)工程師的生產(chǎn)力受到影響,產(chǎn)品工程師在共享有價(jià)值的數(shù)據(jù)方面遇到了挑戰(zhàn)。最終,許多企業(yè)失去了抓住市場(chǎng)瞬息變化的大好機(jī)會(huì)。
第四個(gè)挑戰(zhàn)是中央平臺(tái)模型的規(guī)模限制。Xu 特別指出,由于中央數(shù)據(jù)平臺(tái)以超線性的速度擴(kuò)展用例,使用單一聯(lián)系點(diǎn)來(lái)支持是無(wú)以為繼的。應(yīng)評(píng)估注重支持構(gòu)建在中央平臺(tái)上的本地平臺(tái)的模式,現(xiàn)在正是最佳時(shí)機(jī)。
Xu 在此過(guò)程中汲取了寶貴的經(jīng)驗(yàn),一些經(jīng)驗(yàn)可能產(chǎn)品負(fù)責(zé)人也很熟悉,并適用于流數(shù)據(jù)之外的領(lǐng)域。比如營(yíng)造失敗也沒有關(guān)系的氛圍、決定不開發(fā)什么內(nèi)容、鼓勵(lì)用戶成為平臺(tái)忠粉,以及在壓力下保持鎮(zhèn)靜。有興趣的讀者可以參閱(https://zhenzhongxu.com/the-four-innovation-phases-of-netflixs-trillions-scale-real-time-data-infrastructure-2370938d7f01)。
在第四階段及之外,Xu 也看到了實(shí)時(shí)數(shù)據(jù)處理的特殊機(jī)會(huì)。數(shù)據(jù)流可以連接世界,并可以通過(guò)結(jié)合簡(jiǎn)單性和靈活性來(lái)提高抽象性,更好地滿足機(jī)器學(xué)習(xí)的需求。