摘要：本文由 Netflix 高級軟件工程師徐振中分享，內容包含有趣的案例、分佈式系統基礎方面的各種挑戰以及解決方案，此外還討論了其在開發運維過程中的收穫，對開放式自助式實時數據平臺的一些新願景，以及對 Realtime ETL 基礎平臺的一些新思考。文章內容主要分爲以下三部分：
產品背景
產品功能
挑戰&解決方案
Tips：點擊「閱讀原文」可下載作者分享PPT及觀看現場分享視頻～
Netflix 致力於會員的喜悅。我們不懈地專注於提高產品體驗和高質量內容。近年來，我們一直在技術驅動的 Studio 和內容製作方面進行大量投資。在這個過程中，我們發現在實時數據平臺的領域裏中出現了許多獨特並有意思的挑戰。例如，在微服務架構中，領域對象分佈在不同的 App 及其有狀態存儲中，這使得低延遲高一致性的實時報告和實體搜索發現特別具有挑戰性。
產品背景
Netflix 的長久願景是把歡樂和微笑帶給整個世界，通過在全球各地拍攝一些高質量、多元化的內容產品放在平臺上，分享給平臺超過一個億級別的用戶。更遠大的目標爲了給用戶帶來愉悅的體驗，Netflix 的努力方向分爲兩個：
一方面是通過數據整合知識來反饋並用於提高用戶的產品體驗中去；
另一方面通過建立一個技術驅動的 Studio 去幫助產出內容質量更高的產品。
而作爲一個數據平臺團隊，需要關注的是怎麼幫助公司中不同的開發人員、數據分析人員等實現其在公司中的價值，最終爲解決上述兩方面問題做出自己的貢獻。
簡單地介紹一下 Netflix 數據平臺團隊及相應的產品，Keystone。它的主要功能是幫助公司在所有的微服務中埋點、建立 Agent、發佈事件、收集事件信息，然後放到不同的數據倉庫中進行存儲，比如 Hive 或 ElasticSearch，最後幫助用戶在數據實時存儲的情況下實現計算和分析。
從用戶的角度來講，Keystone 是一個完整的自容（Self-contained）的平臺,支持多用戶，用戶可以通過所提供的 UI 很方便地聲明並創建自己想要的 pipeline。
從平臺角度來說，Keystone 提供底層所有分佈式系統中實現比較困難的解決方案，如容器編排（Container Orchestration）、工作流管理（Workflow Management）等等，這些對於用戶是不可見的。
從產品的角度來說，主要有兩個功能，一個是幫助用戶將數據從邊緣設備移到數倉，另一個是幫助用戶實時計算的功能。
從數字的角度來說，Keystone 在 Netflix 的使用是非常有必要的，只要跟數據打交道的開發者，一定會用到，因此 Keystone 在整個公司中有幾千個用戶，並有一百個 Kafka 的集羣支持每天 10PB 數量級左右的數據。
Keystone 的整個架構分爲兩層，底層是 Kafka 和 Flink 作爲底層引擎，底層對所有分佈式系統中比較困難的技術方案進行抽象，對用戶不可見，在上層構建整個應用；服務層會提供抽象的服務，UI 對於用戶來講比較簡單，不需要關心底層實現。
下面介紹一下 Keystone 產品在過去四五年的發展歷程。最初的動機是收集所有設備的數據並將其存儲到數據倉庫中，當時使用的是 Kafka 技術，因爲數據移動比較好解決，本質上來講僅是一個多併發的問題。
在此之後，用戶給出了新的需求，即在數據移動的過程中對數據進行一些簡單的處理操作，比如篩選（Filter），還有一個很通用的功能 —— projection，爲此 Keystone 推出了針對該需求推出了相應的功能特性。
經過一段時間後，用戶表示想做更加複雜的 ETL，比如 Streaming Join 等，因此產品決定將底層的 API 提供給用戶，並將底層的關於所有分佈式系統的解決方案抽象化，讓其更好地關注上層的內容。
產品功能
產品功能介紹將圍繞 Netflix 中的兩個“超級英雄” Elliot 和 Charlie 來展開。Elliot 是來自數據科學工程組織的一個數據科學家，他的需求是在非常大的數據中尋找響應的 pattern，以幫助提高用戶體驗；Charlie 是一個來自 Studio 組織的應用開發者，其目標是通過開發一系列的應用來幫助周邊的其他開發者產出更高質量的產品。
這兩個人的工作對於產品來講都非常重要，Elliot 的數據分析結果可以幫助給出更好的推薦和個性化定製,最終提高用戶體驗；而 Charlie 的工作可以幫助周邊的開發者提高效率。
Recommendation & Personalization
Elliot 作爲一個數據科學家，需要的是一個簡單易用的實時 ETL 操作平臺，他不希望寫非常複雜的編碼，同時需要保證整個 pipeline 的低延時。他所從事的工作和相關需求主要有以下幾個：
推薦和個性化定製。該工作中可以根據個人特點的不同將同樣的視頻通過不同的形式推送給相應的用戶，視頻可以分爲多個 row，每一個 row 可以是不同的分類，根據個人的喜好可以對不同的 row 進行更改。此外，每一個視頻的題目都會有一個 artwork，不同國家、不同地域的不同用戶對 artwork 的喜好也可能不同，也會通過算法進行計算並定製適合用戶的 artwork。
A/B Testing。Netflix 提供給非會員用戶 28 天免費的視頻觀看機會，同時也相信給用戶看到了適合自己的視頻，用戶更有可能會購買 Netflix 的服務，而在進行A/B Testing 的時候，就需要 28 天才能做完。對於 Elliot 來講，進行 A/B Testing 的時候可能會犯錯誤，他所關心的是怎麼樣才能在不用等到 28 天結束的時候就可以提前發現問題。
當在設備上觀看 Netflix 的時候，會以請求的形式和網關進行交互，然後網關會將這些請求分發給後端的微服務，比如說用戶在設備上點擊播放、暫停、快進、快退等操作，這些會有不同的微服務進行處理，因此需要將相應的數據收集起來，進一步處理。
對於 Keystone 平臺團隊來講，需要收集不同的微服務中產生的數據並進行存儲。Elliot 需要將不同的數據整合起來，以解決他關注的問題。
至於爲什麼要使用流處理，主要有四方面的考量，即實時報告、實時告警、機器學習模型的快速訓練以及資源效率。相比於前兩點，機器學習模型的快速訓練以及資源效率對 Elliot 的工作更加重要。尤其需要強調的是資源效率，針對前面的 28 天的 A/B Testing，目前的做法是每天將數據與前 27 天做 Batch Processing，這個過程中涉及了很多重複處理，使用流處理可以很好地幫助提高整體的效率。
Keystone 會提供命令行的工具給用戶，用戶只需要在命令行中輸入相應的命令來進行操作，工具最開始會詢問用戶一些簡單的問題，如需要使用什麼 repository 等，用戶給出相應的回答後，會最終產生一個模板，用戶便可以開始使用工具進行開發工作；產品還提供一系列簡單的 SDK，目前支持的是Hive、Iceberg、Kafka 和 ElasticSearch 等。
需要強調的是 Iceberg，它是在 Netflix 主導的一個 Table Format，未來計劃取代 Hive。其提供了很多特色功能來幫助用戶做優化；Keystone 向用戶提供了簡單的 API，可以幫助其直接生成 Source 和 Sink。
Elliot 在完成一系列的工作之後，可以選擇將自己的代碼提交到 repository 中，後臺會自動啓動一個 CI/CD pipeline，將所有的源代碼和製品等包裝在 Docker 鏡像中，保證所有的版本一致性。Elliot 在 UI 處只需要選擇想要部署哪一個版本，然後點擊部署按鈕可以將 jar 部署到生產環境中。
產品會在後臺幫助其解決底層分佈式系統比較困難的問題，比如怎麼做容器編排等，目前是基於資源的編排，未來計劃向 K8S 方向發展。部署 Job（作業）包的過程中會部署一個 JobManager 的集羣和一個 TaskManager 的集羣，因此每一個 Job 對於用戶來說是完全獨立的。
產品提供默認的配置選項，同時也支持用戶在平臺 UI 上修改並覆蓋配置信息，直接選擇部署即可生效，而不需重寫代碼。Elliot 之前有一個需求是在 Stream Processing 的過程中，比如從不同的 Topic 中去讀取數據，出現問題的情況下可能需要在 Kafka 中操作，也可能需要在數據倉庫中操作，面對該問題，其需求是在不改動代碼的情況下切換不同的 Source，而目前平臺提供的UI很方便地完成該需求。此外平臺還可以幫助用戶在部署的時候選擇需要多少資源來運行作業。
很多用戶從 Batch Processing 轉到 Stream Processing 的過程中，已經有了很多需要的製品，比如 Schema 等，因此平臺還幫助其簡單地實現這些製品的集成。
平臺擁有很多需要在其之上寫 ETL 工程的用戶，當用戶越來越多的時候，平臺的可伸縮性顯得尤爲重要。爲此，平臺採用了一系列的 pattern 來解決該問題。具體來講，主要有三個 pattern 正在使用，即 Extractor Pattern、Join Pattern 和 Enrichment Pattern。
Content Production
先簡要介紹一下什麼是 Content Production。包括預測在視頻製作方面的花費、制定 program、達成 deal、製作視頻、視頻後期處理、發佈視頻以及金融報告。
Charlie 所在的是 Studio 部門主要負責開發一系列的應用來幫助支持 Content Production。每一個應用都是基於微服務架構來開發部署的，每一個微服務應用會有自己的職責。舉個最簡單的例子，會有專門管理電影標題的微服務應用，也會有專門管理 deals 和 contracts 的微服務應用等等。
面對如此多的微服務應用，Charlie 面臨的挑戰問題是當其在進行實時搜索的過程中，比如搜索某一個電影的演員，需要將數據從不同的地方 join 起來；另外數據每天都在增加，保證實時更新的數據的一致性比較困難，這本質上是分佈式微服務系統的特點導致，不同的微服務選擇使用的數據庫可能不同，這給數據一致性的保證又增加了一定的複雜度。針對該問題，常用的解決方案有以下三個：
Dual writes: 當開發者知道數據需要放到主要的數據庫中的時候，同時也要放到另一個數據庫中，可以很簡單地選擇分兩次寫入到數據庫中，但是這種操作是不容錯的，一旦發生錯誤，很有可能會導致數據的不一致；
Change Data Table: 需要數據庫支持事務的概念，不管對數據庫做什麼操作，相應的變更會加到事務變更的 statement 中並存入單獨的表中，之後可以查詢該 change 表並獲取相應的變更情況並同步到其他數據表；
Distributed Transaction：指的是分佈式事務，在多數據環境中實現起來比較複雜。
Charlie 的一個需求是將所有的電影從 Movie Datastore 複製到一個以 Elasticsearch 來支持的 movie search index 中，主要通過一個 Polling System 來做數據拉取和複製，數據一致性的保證採用的是上述的 Change data table 的方法。
該方案的弊端是隻支持定期數據拉取，另外 Polling System 和數據源直接緊密結合，一旦 Movie Search Datastore 的 Schema 改變，Polling System 就需要修改。爲此，該架構在後來做了一次改進，引入了事件驅動的機制，讀取數據庫中所有實現的事務，通過 stream processing 的方式傳遞到下一個 job 進行處理。爲了普適化該解決方案，在 source 端實現了不同數據庫的 CDC（Change Data Capture）支持，包括 MySQL、PostgreSQL 和 Cassandra 等在 Netflix 中比較常用的數據庫，通過 Keystone 的 pipeline 進行處理。
挑戰及解決方案
下面分享一下上述方案存在的挑戰和相應的解決方案：
Ordering Semantics
在變更數據事件中，必須要保證 Event ordering，比如一個事件包含 create、update 和 delete 是三個操作，需要返回給消費者側一個嚴格遵守該順序的操作事件。一個解決方案是通過 Kafka 來控制；另一個解決方案是在分佈式系統中保證捕獲的事件與實際從數據庫中讀取數據的順序是一致的，該方案中當所有的變更事件捕獲出來後，會存在重複和亂序的情況，會通過 Flink 進行去重和重新排序。
Processing Contracts
在寫 stream processing 的時候，很多情況下不知道 Schema 的具體信息，因此需要在消息上定義一個契約 contract，包括 Wire Format 以及在不同的層級上定義與Schema 相關的信息，如基礎設施（Infrastructure）、平臺（Platform）等。Processor Contract 的目的是幫助用戶將不同的 processor metadata 組合起來，儘量減少其寫重複代碼的可能。
舉一個具體的案例，比如 Charlie 希望有新的 deal 的時候被及時通知，平臺通過將相關的不同組件組合起來，DB Connector、Filter 等，通過用戶定義契約的方式幫助其實現一個開放的可組合的流數據平臺。
以往所看到的 ETL 工程大多數適用於數據工程師或數據科學家。但從經驗上來講，ETL 的整個過程，即 Extract、Transform 和 Load，其實是有被更廣泛應用的可能。最早的 Keystone 簡單易用，但靈活性不高，之後的發展過程中雖然提高了靈活性，但複雜性也相應地增大了。因此未來團隊計劃在目前的基礎上進一步優化，推出開放的、合作的、可組合的、可配置的 ETL 工程平臺，幫助用戶在極短的時間解決問題。
作者簡介：
徐振中，Netflix 軟件工程師，在 Netflix 從事高度可擴展和彈性的流媒體數據平臺的基礎設施工作，熱衷於研究分享與實時數據系統、分佈式系統基本原理相關的任何有趣的事情！
點擊「閱讀原文」可查看作者現場分享視頻～
關注 Flink 中文社區，獲取更多技術乾貨
你也「在看」嗎？????