作者： 徐赢、高立
摘要：如何基于 Flink 搭建大規模準實時資料分析平台？在 Flink Forward Asia 2019 上，來自 Lyft 公司實時資料平台的徐赢博士和計算資料平台的高立博士分享了 Lyft 基于 Apache Flink 的大規模準實時資料分析平台。
檢視FFA大會視訊。
本次分享主要分為四個方面：
- Lyft 的流資料與場景
- 準實時資料分析平台和架構
- 平台性能及容錯深入分析
- 總結與未來展望
重要：文末「閱讀原文」可檢視 Flink Forward Asia 大會視訊。
一、Lyft 的流資料與場景
關于 Lyft
Lyft 是位于北美的一個共享交通平台，和大家所熟知的 Uber 和國内的滴滴類似，Lyft 也為群眾提供共享出行的服務。Lyft 的宗旨是提供世界最好的交通方案來改善人們的生活。
Lyft 的流資料場景
Lyft 的流資料可以大緻分為三類，秒級别、分鐘級别和不高于 5 分鐘級别。分鐘級别流資料中，自适應定價系統、欺詐和異常檢測系統是最常用的，此外還有 Lyft 最新研發的機器學習特征工程。不高于 5 分鐘級别的場景則包括準實時資料互動查詢相關的系統。
Lyft 資料分析平台架構
如下圖所示的是 Lyft 之前的資料分析平台架構。Lyft 的大部分流資料都是來自于事件，而事件産生的來源主要有兩種，分别是手機 APP 和後端服務，比如乘客、司機、支付以及保險等服務都會産生各種各樣的事件，而這些事件都需要實時響應。
在分析平台這部分，事件會流向 AWS 的 Kinesis 上面，這裡的 Kinesis 與 Apache Kafka 非常類似，是一種 AWS 上專有的 PubSub 服務，而這些資料流都會量化成檔案，這些檔案則都會存儲在 AWS 的 S3 上面，并且很多批處理任務都會彈出一些資料子集。在分析系統方面，Lyft 使用的是開源社群中比較活躍的 presto 查詢引擎。Lyft 資料分析平台的使用者主要有四種，即資料工程師、資料分析師以及機器學習專家和深度學習專家，他們往往都是通過分析引擎實作與資料的互動。
既往平台的問題
Lyft 之是以要基于 Apache Flink 實作大規模準實時資料分析平台，是因為以往的平台存在一些問題。比如較高的延遲，導入資料無法滿足準實時查詢的要求；并且基于 Kinesis Client Library 的流式資料導入性能不足；導入資料存在太多小檔案導緻下遊操作性能不足；資料 ETL 大多是高延遲多日多步的架構；此外，以往的平台對于嵌套資料提供的支援也不足。
二、準實時資料分析平台和架構
準實時平台架構
在新的準實時平台架構中，Lyft 采用 Flink 實作流資料持久化。Lyft 使用雲端存儲，而使用 Flink 直接向雲端寫一種叫做 Parquet 的資料格式，Parquet 是一種列資料存儲格式，能夠有效地支援互動式資料查詢。Lyft 在 Parquet 原始資料上架構實時數倉，實時數倉的結構被存儲在 Hive 的 Table 裡面，Hive Table 的 metadata 存儲在 Hive metastore 裡面。
平台會對于原始資料做多級的非阻塞 ETL 加工，每一級都是非阻塞的(nonblocking)，主要是壓縮和去重的操作，進而得到更高品質的資料。平台主要使用 Apache Airflow 對于 ETL 操作進行排程。所有的 Parquet 格式的原始資料都可以被 presto 查詢，互動式查詢的結果将能夠以 BI 模型的方式顯示給使用者。
平台設計
Lyft 基于 Apache Flink 實作的大規模準實時資料分析平台具有幾個特點：
- 首先，平台借助 Flink 實作高速有效的流資料接入，使得雲上叢集規模縮減為原來的十分之一，是以大大降低了運維成本。
- 其次，Parquet 格式的資料支援互動式查詢，當使用者僅對于某幾個列資料感興趣時可以通過分區和選擇列的方式過濾不必要的資料，進而提升查詢的性能。
- 再次，基于 AWS 的雲端存儲，平台的資料無需特殊存儲形式。
- 之後，多級 ETL 程序能夠確定更好的性能和資料品質。
- 最後，還能夠兼顧性能容錯及可演進性。
平台特征及應用
Lyft 準實時資料分析平台需要每天處理千億級事件，能夠做到資料延遲小于 5 分鐘，而鍊路中使用的元件確定了資料完整性，同時基于 ETL 去備援操作實作了資料單一性保證。
資料科學家和資料工程師在模組化時會需要進行自發的互動式查詢，此外，平台也會提供實時機器學習模型正确性預警，以及實時資料面闆來監控供需市場健康狀況。
基于 Flink 的準實時資料導入
下圖可以看到當事件到達 Kinesis 之後就會被存儲成為 EventBatch。通過 Flink-Kinesis 連接配接器可以将事件提取出來并送到 FlatMap 和 Record Counter 上面，FlatMap 将事件打撒并送到下遊的 Global Record Aggregator 和 Tagging Partitioning 上面，每當做 CheckPoint 時會關閉檔案并做一個持久化操作，針對于 StreamingFileSink 的特征，平台設定了每三分鐘做一次 CheckPoint 操作，這樣可以保證當事件進入 Kinesis 連接配接器之後在三分鐘之内就能夠持久化。
以上的方式會造成太多數量的小檔案問題，因為資料鍊路支援成千上萬種檔案，是以使用了 Subtasks 記錄本地事件權重，并通過全局記錄聚合器來計算事件全局權重并廣播到下遊去。而 Operator 接收到事件權重之後将會将事件配置設定給 Sink。
ETL 多級壓縮和去重
上述的資料鍊路也會做 ETL 多級壓縮和去重工作，主要是 Parquet 原始資料會經過每小時的智能壓縮去重的 ETL 工作，産生更大的 Parquet File。同理，對于小時級别壓縮去重不夠的檔案，每天還會再進行一次壓縮去重。對于新産生的資料會有一個原子性的分區交換，也就是說當産生新的資料之後，ETL Job 會讓 Hive metastore 裡的表分區指向新的資料和分區。這裡的過程使用了啟發性算法來分析哪些事件必須要經過壓縮和去重以及壓縮去重的時間間隔級别。此外，為了滿足隐私和合規的要求，一些 ETL 資料會被儲存數以年計的時間。
三、平台性能及容錯深入分析
事件時間驅動的分區感測
Flink 和 ETL 是通過事件時間驅動的分區感測實作同步的。S3 采用的是比較常見的分區格式，最後的分區是由時間戳決定的，時間戳則是基于 EventTime 的，這樣的好處在于能夠帶來 Flink 和 ETL 共同的時間源，這樣有助于同步操作。此外，基于事件時間能夠使得一些回填操作和主操作實作類似的結果。Flink 處理完每個小時的事件後會向事件分區寫入一個 Success 檔案，這代表該小時的事件已經處理完畢，ETL 可以對于該小時的檔案進行操作了。
Flink 本身的水印并不能直接用到 Lyft 的應用場景當中，主要是因為當 Flink 處理完時間戳并不意味着它已經被持久化到存儲當中，此時就需要引入分區水印的概念，這樣一來每個 Sink Source 就能夠知道目前寫入的分區，并且維護一個分區 ID，并且通過 Global State Aggregator 聚合每個分區的資訊。每個 Subtasks 能夠知道全局的資訊，并将水印定義為分區時間戳中最小的一個。
ETL 主要有兩個特點，分别是及時性和去重，而 ETL 的主要功能在于去重和壓縮，最重要的是在非阻塞的情況下就進行去重。前面也提到 Smart ETL，所謂 Smart 就是智能感覺，需要兩個相應的資訊來引導 Global State Aggregator，分别是分區完整性辨別 SuccessFile，在每個分區還有幾個相應的 States 統計資訊能夠告訴下遊的 ETL 怎樣去重和壓縮以及操作的頻率和範圍。
Schema 演進的挑戰
ETL 除了去重和壓縮的挑戰之外，還經常會遇到 Schema 的演化挑戰。Schema 演化的挑戰分為三個方面，即不同引擎的資料類型、嵌套結構的演變、資料類型演變對去重邏輯的影響。
S3 深入分析
Lyft 的資料存儲系統其實可以認為是資料湖，對于 S3 而言，Lyft 也有一些性能的優化考量。S3 本身内部也是有分區的，為了使其具有并行的讀寫性能，添加了 S3 的熵數字首，在分區裡面也增加了标記檔案，這兩種做法能夠極大地降低 S3 的 IO 性能的影響。辨別符對于能否觸發 ETL 操作會産生影響，與此同時也是對于 presto 的內建，能夠讓 presto 決定什麼情況下能夠掃描多少個檔案。
Parquet 優化方案
Lyft 的準實時資料分析平台在 Parquet 方面做了很多優化，比如檔案資料值大小範圍統計資訊、檔案系統統計資訊、基于主鍵資料值的排序加快 presto 的查詢速度以及二級索引的生成。
基于資料回填的平台容錯機制
如下兩個圖所示的是 Lyft 準實時資料分析平台的基于資料回填的平台容錯機制。對于 Flink 而言，因為平台的要求是達到準實時，而 Flink 的 Job 出現失效的時候可能會超過一定的時間，當 Job 重新開始之後就會形成兩個資料流，主資料流總是從最新的資料開始往下執行，附加資料流則可以回溯到之前中斷的位置進行執行直到中斷結束的位置。這樣的好處是既能保證主資料流的準實時特性，同時通過回填資料流保證資料的完整性。
對于 ETL 而言，基于資料回填的平台容錯機制則表現在 Airflow 的幂等排程系統、原子壓縮和 HMS 交換操作、分區自建自修複體系和 Schema 整合。
四、總結與未來展望
體驗與經驗教訓
利用 Flink 能夠準實時注入 Parquet 資料，使得互動式查詢體驗為可能。同時，Flink 在 Lyft 中的應用很多地方也需要提高，雖然 Flink 在大多數情況的延時都能夠得到保證，但是重新開機和部署的時候仍然可能造成分鐘級别的延時，這會對于 SLO 産生一定影響。
此外，Lyft 目前做的一件事情就是改善部署系統使其能夠支援 Kubernetes，并且使得其能夠接近 0 當機時間的效果。因為 Lyft 準實時資料分析平台在雲端運作，是以在将資料上傳到 S3 的時候會産生一些随機的網絡情況，造成 Sink Subtasks 的停滞，進而造成整個 Flink Job 的停滞。而通過引入一些 Time Out 機制來檢測 Sink Subtasks 的停滞，使得整個 Flink Job 能夠順利運作下去。
ETL 分區感應能夠降低成本和延遲，成功檔案則能夠表示什麼時候處理完成。此外，S3 檔案布局對性能提升的影響還是非常大的，目前而言引入熵數還屬于經驗總結，後續 Lyft 也會對于這些進行總結分析并且公開。因為使用 Parquet 資料，是以對于 Schema 的相容性要求就非常高，如果引入了不相容事件則會使得下遊的 ETL 癱瘓，是以 Lyft 已經做到的就是在資料鍊路上遊對于 Schema 的相容性進行檢查，檢測并拒絕使用者送出不相容的 Schema。
未來展望
Lyft 對于準實時資料分析平台也有一些設想。
- 首先，Lyft 希望将 Flink 部署在 Kubernetes 叢集環境下運作，使得 Kubernetes 能夠管理這些 Flink Job，同時也能夠充分利用 Kubernetes 叢集的高可擴充性。
- 其次，Lyft 也希望實作通用的流資料導入架構，準實時資料分析平台不僅僅支援事件，也能夠支援資料庫以及服務日志等資料。
- 再次，Lyft 希望平台能夠實作 ETL 智能壓縮以及事件驅動 ETL，使得回填等事件能夠自動觸發相應的 ETL 過程，實作和以前的資料的合并，同時将延時資料導入來對于 ETL 過程進行更新。
- 最後，Lyft 還希望準實時資料分析平台能夠實作存儲過程的改進以及查詢優化，借助 Parquet 的統計資料來改善 presto 的查詢性能，借助表格管理相關的開源軟體對存儲管理進行性能改善，同時實作更多的功能。
作者簡介：
- 徐赢博士是 Lyft 資料平台流媒體平台的技術上司（Technical Lead），目前主導準實時資料分析平台的架構開發。在 Lyft 之前，他曾在領英(Linkedin)以及 IBM 擔任技術上司職位，主導領英跨資料中心資料庫複制的上線，以及 IBM 高速資料傳輸技術的研發。
- 高立博士在 Lyft 的資料平台團隊中工作，目前上司 Lyft 資料平台内的多個資料基礎架構項目，包括實時資料倉庫，自服務機器學習平台項目等。 曾在 Salesforce，Fitbit，Groupon 和其他初創公司擔任關鍵技術上司職務。