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