Categories
程式開發

Lyft基於Flink的大規模準實時數據分析平台實踐


如何基於 Flink 搭建大規模準實時數據分析平台?在 Flink Forward Asia 2019 上,來自 Lyft 公司實時數據平台的徐贏博士和計算數據平台的高立博士分享了 Lyft 基於 Apache Flink 的大規模準實時數據分析平台的建設實踐。

本次分享主要分為四個方面:

  1. Lyft 的流數據與場景
  2. 準實時數據分析平台和架構
  3. 平台性能及容錯深入分析
  4. 總結與未來展望

一、Lyft 的流數據與場景

關於 Lyft

Lyft 是位於北美的一個共享交通平台,和大家所熟知的 Uber 和國內的滴滴類似,Lyft 也為民眾提供共享出行的服務。 Lyft 的宗旨是提供世界最好的交通方案來改善人們的生活。

Lyft基於Flink的大規模準實時數據分析平台實踐 1

Lyft 的流數據場景

Lyft 的流數據可以大致分為三類,秒級別、分鐘級別和不高於 5 分鐘級別。分鐘級別流數據中,自適應定價系統、欺詐和異常檢測系統是最常用的,此外還有 Lyft 最新研發的機器學習特徵工程。不高於 5 分鐘級別的場景則包括準實時數據交互查詢相關的系統。

Lyft基於Flink的大規模準實時數據分析平台實踐 2

Lyft 數據分析平台架構

如下圖所示的是 Lyft 之前的數據分析平台架構。 Lyft 的大部分流數據都是來自於事件,而事件產生的來源主要有兩種,分別是手機APP 和後端服務,比如乘客、司機、支付以及保險等服務都會產生各種各樣的事件,而這些事件都需要實時響應。

Lyft基於Flink的大規模準實時數據分析平台實踐 3

在分析平台這部分,事件會流向AWS 的Kinesis 上面,這裡的Kinesis 與Apache Kafka 非常類似,是一種AWS 上專有的PubSub 服務,而這些數據流都會量化成文件,這些文件則都會存儲在AWS的S3 上面,並且很多批處理任務都會彈出一些數據子集。在分析系統方面,Lyft 使用的是開源社區中比較活躍的 presto 查詢引擎。 Lyft 數據分析平台的用戶主要有四種,即數據工程師、數據分析師以及機器學習專家和深度學習專家,他們往往都是通過分析引擎實現與數據的交互。

既往平台的問題

Lyft 之所以要基於 Apache Flink 實現大規模準實時數據分析平台,是因為以往的平台存在一些問題。比如較高的延遲,導入數據無法滿足準實時查詢的要求;並且基於Kinesis Client Library 的流式數據導入性能不足;導入數據存在太多小文件導致下游操作性能不足;數據ETL 大多是高延遲多日多步的架構;此外,以往的平台對於嵌套數據提供的支持也不足。

Lyft基於Flink的大規模準實時數據分析平台實踐 4

二、準實時數據分析平台和架構

準實時平台架構

在新的準實時平台架構中,Lyft 採用 Flink 實現流數據持久化。 Lyft 使用雲端存儲,而使用 Flink 直接向雲端寫一種叫做 Parquet 的數據格式,Parquet 是一種列數據存儲格式,能夠有效地支持交互式數據查詢。 Lyft 在 Parquet 原始數據上架構實時數倉,實時數倉的結構被存儲在 Hive 的 Table 裡面,Hive Table 的 metadata 存儲在 Hive metastore 裡面。

平台會對於原始數據做多級的非阻塞 ETL 加工,每一級都是非阻塞的(nonblocking),主要是壓縮和去重的操作,從而得到更高質量的數據。平台主要使用 Apache Airflow 對於 ETL 操作進行調度。所有的 Parquet 格式的原始數據都可以被 presto 查詢,交互式查詢的結果將能夠以 BI 模型的方式顯示給用戶。

Lyft基於Flink的大規模準實時數據分析平台實踐 5

平台設計

Lyft 基於 Apache Flink 實現的大規模準實時數據分析平台具有幾個特點:

  • 首先,平台借助 Flink 實現高速有效的流數據接入,使得云上集群規模縮減為原來的十分之一,因此大大降低了運維成本。
  • 其次,Parquet 格式的數據支持交互式查詢,當用戶僅對於某幾個列數據感興趣時可以通過分區和選擇列的方式過濾不必要的數據,從而提升查詢的性能。
  • 再次,基於 AWS 的雲端存儲,平台的數據無需特殊存儲形式。
  • 之後,多級 ETL 進程能夠確保更好的性能和數據質量。
  • 最後,還能夠兼顧性能容錯及可演進性。

Lyft基於Flink的大規模準實時數據分析平台實踐 6

平台特徵及應用

Lyft 準實時數據分析平台需要每天處理千億級事件,能夠做到數據延遲小於 5 分鐘,而鏈路中使用的組件確保了數據完整性,同時基於 ETL 去冗餘操作實現了數據單一性保證。

Lyft基於Flink的大規模準實時數據分析平台實踐 7

數據科學家和數據工程師在建模時會需要進行自發的交互式查詢,此外,平台也會提供實時機器學習模型正確性預警,以及實時數據面板來監控供需市場健康狀況。

基於 Flink 的準實時數據導入

下圖可以看到當事件到達 Kinesis 之後就會被存儲成為 EventBatch。通過Flink-Kinesis 連接器可以將事件提取出來並送到FlatMap 和Record Counter 上面,FlatMap 將事件打撒並送到下游的Global Record Aggregator 和Tagging Partitioning 上面,每當做CheckPoint 時會關閉文件並做一個持久化操作,針對於StreamingFileSink 的特徵,平台設置了每三分鐘做一次CheckPoint 操作,這樣可以保證當事件進入Kinesis 連接器之後在三分鐘之內就能夠持久化。

Lyft基於Flink的大規模準實時數據分析平台實踐 8

以上的方式會造成太多數量的小文件問題,因為數據鏈路支持成千上萬種文件,因此使用了Subtasks 記錄本地事件權重,並通過全局記錄聚合器來計算事件全局權重並廣播到下游去。而 Operator 接收到事件權重之後將會將事件分配給 Sink。

ETL 多級壓縮和去重

上述的數據鏈路也會做 ETL 多級壓縮和去重工作,主要是 Parquet 原始數據會經過每小時的智能壓縮去重的 ETL 工作,產生更大的 Parquet File。同理,對於小時級別壓縮去重不夠的文件,每天還會再進行一次壓縮去重。對於新產生的數據會有一個原子性的分區交換,也就是說當產生新的數據之後,ETL Job 會讓 Hive metastore 裡的表分區指向新的數據和分區。這裡的過程使用了啟發性算法來分析哪些事件必須要經過壓縮和去重以及壓縮去重的時間間隔級別。此外,為了滿足隱私和合規的要求,一些 ETL 數據會被保存數以年計的時間。

Lyft基於Flink的大規模準實時數據分析平台實踐 9

三、平台性能及容錯深入分析

事件時間驅動的分區感測

Flink 和 ETL 是通過事件時間驅動的分區感測實現同步的。 S3 採用的是比較常見的分區格式,最後的分區是由時間戳決定的,時間戳則是基於 EventTime 的,這樣的好處在於能夠帶來 Flink 和 ETL 共同的時間源,這樣有助於同步操作。此外,基於事件時間能夠使得一些回填操作和主操作實現類似的結果。 Flink 處理完每個小時的事件後會向事件分區寫入一個 Success 文件,這代表該小時的事件已經處理完畢,ETL 可以對於該小時的文件進行操作了。

Lyft基於Flink的大規模準實時數據分析平台實踐 10

Flink 本身的水印並不能直接用到Lyft 的應用場景當中,主要是因為當Flink 處理完時間戳並不意味著它已經被持久化到存儲當中,此時就需要引入分區水印的概念,這樣一來每個Sink Source 就能夠知道當前寫入的分區,並且維護一個分區ID,並且通過Global State Aggregator 聚合每個分區的信息。每個 Subtasks 能夠知道全局的信息,並將水印定義為分區時間戳中最小的一個。

Lyft基於Flink的大規模準實時數據分析平台實踐 11

ETL 主要有兩個特點,分別是及時性和去重,而 ETL 的主要功能在於去重和壓縮,最重要的是在非阻塞的情況下就進行去重。前面也提到Smart ETL,所謂Smart 就是智能感知,需要兩個相應的信息來引導Global State Aggregator,分別是分區完整性標識SuccessFile,在每個分區還有幾個相應的States 統計信息能夠告訴下游的ETL 怎樣去重和壓縮以及操作的頻率和範圍。

Lyft基於Flink的大規模準實時數據分析平台實踐 12

Schema 演進的挑戰

ETL 除了去重和壓縮的挑戰之外,還經常會遇到 Schema 的演化挑戰。 Schema 演化的挑戰分為三個方面,即不同引擎的數據類型、嵌套結構的演變、數據類型演變對去重邏輯的影響。

Lyft基於Flink的大規模準實時數據分析平台實踐 13

S3 深入分析

Lyft 的數據存儲系統其實可以認為是數據湖,對於 S3 而言,Lyft 也有一些性能的優化考量。 S3 本身內部也是有分區的,為了使其具有並行的讀寫性能,添加了 S3 的熵數前綴,在分區裡面也增加了標記文件,這兩種做法能夠極大地降低 S3 的 IO 性能的影響。標識符對於能否觸發 ETL 操作會產生影響,與此同時也是對於 presto 的集成,能夠讓 presto 決定什麼情況下能夠掃描多少個文件。

Lyft基於Flink的大規模準實時數據分析平台實踐 14

Parquet 優化方案

Lyft 的準實時數據分析平台在 Parquet 方面做了很多優化,比如文件數據值大小範圍統計信息、文件系統統計信息、基於主鍵數據值的排序加快 presto 的查詢速度以及二級索引的生成。

Lyft基於Flink的大規模準實時數據分析平台實踐 15

基於數據回填的平台容錯機制

如下兩個圖所示的是 Lyft 準實時數據分析平台的基於數據回填的平台容錯機制。對於Flink 而言,因為平台的要求是達到準實時,而Flink 的Job 出現失效的時候可能會超過一定的時間,當Job 重新開始之後就會形成兩個數據流,主數據流總是從最新的數據開始往下執行,附加數據流則可以回溯到之前中斷的位置進行執行直到中斷結束的位置。這樣的好處是既能保證主數據流的準實時特性,同時通過回填數據流保證數據的完整性。

Lyft基於Flink的大規模準實時數據分析平台實踐 16

對於 ETL 而言,基於數據回填的平台容錯機制則表現在 Airflow 的冪等調度系統、原子壓縮和 HMS 交換操作、分區自建自修復體系和 Schema 整合。

Lyft基於Flink的大規模準實時數據分析平台實踐 17

四、總結與未來展望

體驗與經驗教訓

利用 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基於Flink的大規模準實時數據分析平台實踐 18

未來展望

Lyft 對於準實時數據分析平台也有一些設想。

  • 首先,Lyft 希望將 Flink 部署在 Kubernetes 集群環境下運行,使得 Kubernetes 能夠管理這些 Flink Job,同時也能夠充分利用 Kubernetes 集群的高可擴展性。
  • 其次,Lyft 也希望實現通用的流數據導入框架,準實時數據分析平台不僅僅支持事件,也能夠支持數據庫以及服務日誌等數據。
  • 再次,Lyft 希望平台能夠實現 ETL 智能壓縮以及事件驅動 ETL,使得回填等事件能夠自動觸發相應的 ETL 過程,實現和以前的數據的合併,同時將延時數據導入來對於 ETL 過程進行更新。
  • 最後,Lyft 還希望準實時數據分析平台能夠實現存儲過程的改進以及查詢優化,借助Parquet 的統計數據來改善presto 的查詢性能,借助表格管理相關的開源軟件對存儲管理進行性能改善,同時實現更多的功能。

Lyft基於Flink的大規模準實時數據分析平台實踐 19

作者介紹:

徐贏博士是Lyft 數據平台流媒體平台的技術領導(Technical Lead),目前主導準實時數據分析平台的架構開發。在 Lyft 之前,他曾在領英(Linkedin)以及 IBM 擔任技術領導職位,主導領英跨數據中心數據庫複製的上線,以及 IBM 高速數據傳輸技術的研發。
高立博士在Lyft 的數據平台團隊中工作,目前領導 Lyft 數據平台內的多個數據基礎架構項目,包括實時數據倉庫,自服務機器學習平台項目等。曾在 Salesforce,Fitbit,Groupon 和其他初創公司擔任關鍵技術領導職務。