作者：徐贏 高立 來源：InfoQ

如何基于 Flink 搭建大規(guī)模準(zhǔn)實(shí)時(shí)數(shù)據(jù)分析平臺(tái)?在 Flink Forward Asia 2019 上，來自 Lyft 公司實(shí)時(shí)數(shù)據(jù)平臺(tái)的徐贏博士和計(jì)算數(shù)據(jù)平臺(tái)的高立博士分享了 Lyft 基于 Apache Flink 的大規(guī)模準(zhǔn)實(shí)時(shí)數(shù)據(jù)分析平臺(tái)的建設(shè)實(shí)踐。

本次分享主要分為四個(gè)方面：

♦  Lyft 的流數(shù)據(jù)與場景
♦  準(zhǔn)實(shí)時(shí)數(shù)據(jù)分析平臺(tái)和架構(gòu)
♦  平臺(tái)性能及容錯(cuò)深入分析
♦  總結(jié)與未來展望

一、Lyft 的流數(shù)據(jù)與場景

關(guān)于 Lyft

Lyft 是位于北美的一個(gè)共享交通平臺(tái)，和大家所熟知的 Uber 和國內(nèi)的滴滴類似，Lyft 也為民眾提供共享出行的服務(wù)。Lyft 的宗旨是提供世界最好的交通方案來改善人們的生活。

 

 

Lyft 的流數(shù)據(jù)場景

Lyft 的流數(shù)據(jù)可以大致分為三類，秒級(jí)別、分鐘級(jí)別和不高于 5 分鐘級(jí)別。分鐘級(jí)別流數(shù)據(jù)中，自適應(yīng)定價(jià)系統(tǒng)、欺詐和異常檢測系統(tǒng)是最常用的，此外還有 Lyft 最新研發(fā)的機(jī)器學(xué)習(xí)特征工程。不高于 5 分鐘級(jí)別的場景則包括準(zhǔn)實(shí)時(shí)數(shù)據(jù)交互查詢相關(guān)的系統(tǒng)。

 

 

Lyft 數(shù)據(jù)分析平臺(tái)架構(gòu)

如下圖所示的是 Lyft 之前的數(shù)據(jù)分析平臺(tái)架構(gòu)。Lyft 的大部分流數(shù)據(jù)都是來自于事件，而事件產(chǎn)生的來源主要有兩種，分別是手機(jī) APP 和后端服務(wù)，比如乘客、司機(jī)、支付以及保險(xiǎn)等服務(wù)都會(huì)產(chǎn)生各種各樣的事件，而這些事件都需要實(shí)時(shí)響應(yīng)。

 

 

在分析平臺(tái)這部分，事件會(huì)流向 AWS 的 Kinesis 上面，這里的 Kinesis 與 Apache Kafka 非常類似，是一種 AWS 上專有的 PubSub 服務(wù)，而這些數(shù)據(jù)流都會(huì)量化成文件，這些文件則都會(huì)存儲(chǔ)在 AWS 的 S3 上面，并且很多批處理任務(wù)都會(huì)彈出一些數(shù)據(jù)子集。在分析系統(tǒng)方面，Lyft 使用的是開源社區(qū)中比較活躍的 presto 查詢引擎。Lyft 數(shù)據(jù)分析平臺(tái)的用戶主要有四種，即數(shù)據(jù)工程師、數(shù)據(jù)分析師以及機(jī)器學(xué)習(xí)專家和深度學(xué)習(xí)專家，他們往往都是通過分析引擎實(shí)現(xiàn)與數(shù)據(jù)的交互。

既往平臺(tái)的問題

Lyft 之所以要基于 Apache Flink 實(shí)現(xiàn)大規(guī)模準(zhǔn)實(shí)時(shí)數(shù)據(jù)分析平臺(tái)，是因?yàn)橐酝�的平臺(tái)存在一些問題。比如較高的延遲，導(dǎo)入數(shù)據(jù)無法滿足準(zhǔn)實(shí)時(shí)查詢的要求;并且基于 Kinesis Client Library 的流式數(shù)據(jù)導(dǎo)入性能不足;導(dǎo)入數(shù)據(jù)存在太多小文件導(dǎo)致下游操作性能不足;數(shù)據(jù) ETL 大多是高延遲多日多步的架構(gòu);此外，以往的平臺(tái)對(duì)于嵌套數(shù)據(jù)提供的支持也不足。

 

 

二、準(zhǔn)實(shí)時(shí)數(shù)據(jù)分析平臺(tái)和架構(gòu)

準(zhǔn)實(shí)時(shí)平臺(tái)架構(gòu)

在新的準(zhǔn)實(shí)時(shí)平臺(tái)架構(gòu)中，Lyft 采用 Flink 實(shí)現(xiàn)流數(shù)據(jù)持久化。Lyft 使用云端存儲(chǔ)，而使用 Flink 直接向云端寫一種叫做 Parquet 的數(shù)據(jù)格式，Parquet 是一種列數(shù)據(jù)存儲(chǔ)格式，能夠有效地支持交互式數(shù)據(jù)查詢。Lyft 在 Parquet 原始數(shù)據(jù)上架構(gòu)實(shí)時(shí)數(shù)倉，實(shí)時(shí)數(shù)倉的結(jié)構(gòu)被存儲(chǔ)在 Hive 的 Table 里面，Hive Table 的 metadata 存儲(chǔ)在 Hive metastore 里面。

平臺(tái)會(huì)對(duì)于原始數(shù)據(jù)做多級(jí)的非阻塞 ETL 加工，每一級(jí)都是非阻塞的 (nonblocking)，主要是壓縮和去重的操作，從而得到更高質(zhì)量的數(shù)據(jù)。平臺(tái)主要使用 Apache Airflow 對(duì)于 ETL 操作進(jìn)行調(diào)度。所有的 Parquet 格式的原始數(shù)據(jù)都可以被 presto 查詢，交互式查詢的結(jié)果將能夠以 BI 模型的方式顯示給用戶。

 

 

平臺(tái)設(shè)計(jì)

Lyft 基于 Apache Flink 實(shí)現(xiàn)的大規(guī)模準(zhǔn)實(shí)時(shí)數(shù)據(jù)分析平臺(tái)具有幾個(gè)特點(diǎn)：

首先，平臺(tái)借助 Flink 實(shí)現(xiàn)高速有效的流數(shù)據(jù)接入，使得云上集群規(guī)�？s減為原來的十分之一，因此大大降低了運(yùn)維成本。

其次，Parquet 格式的數(shù)據(jù)支持交互式查詢，當(dāng)用戶僅對(duì)于某幾個(gè)列數(shù)據(jù)感興趣時(shí)可以通過分區(qū)和選擇列的方式過濾不必要的數(shù)據(jù)，從而提升查詢的性能。

再次，基于 AWS 的云端存儲(chǔ)，平臺(tái)的數(shù)據(jù)無需特殊存儲(chǔ)形式。

之后，多級(jí) ETL 進(jìn)程能夠確保更好的性能和數(shù)據(jù)質(zhì)量。

最后，還能夠兼顧性能容錯(cuò)及可演進(jìn)性。

 

 

平臺(tái)特征及應(yīng)用

Lyft 準(zhǔn)實(shí)時(shí)數(shù)據(jù)分析平臺(tái)需要每天處理千億級(jí)事件，能夠做到數(shù)據(jù)延遲小于 5 分鐘，而鏈路中使用的組件確保了數(shù)據(jù)完整性，同時(shí)基于 ETL 去冗余操作實(shí)現(xiàn)了數(shù)據(jù)單一性保證。

 

 

數(shù)據(jù)科學(xué)家和數(shù)據(jù)工程師在建模時(shí)會(huì)需要進(jìn)行自發(fā)的交互式查詢，此外，平臺(tái)也會(huì)提供實(shí)時(shí)機(jī)器學(xué)習(xí)模型正確性預(yù)警，以及實(shí)時(shí)數(shù)據(jù)面板來監(jiān)控供需市場健康狀況。

基于 Flink 的準(zhǔn)實(shí)時(shí)數(shù)據(jù)導(dǎo)入

下圖可以看到當(dāng)事件到達(dá) Kinesis 之后就會(huì)被存儲(chǔ)成為 EventBatch。通過 Flink-Kinesis 連接器可以將事件提取出來并送到 FlatMap 和 Record Counter 上面，F(xiàn)latMap 將事件打撒并送到下游的 Global Record Aggregator 和 Tagging Partitioning 上面，每當(dāng)做 CheckPoint 時(shí)會(huì)關(guān)閉文件并做一個(gè)持久化操作，針對(duì)于 StreamingFileSink 的特征，平臺(tái)設(shè)置了每三分鐘做一次 CheckPoint 操作，這樣可以保證當(dāng)事件進(jìn)入 Kinesis 連接器之后在三分鐘之內(nèi)就能夠持久化。

 

 

以上的方式會(huì)造成太多數(shù)量的小文件問題，因?yàn)閿?shù)據(jù)鏈路支持成千上萬種文件，因此使用了 Subtasks 記錄本地事件權(quán)重，并通過全局記錄聚合器來計(jì)算事件全局權(quán)重并廣播到下游去。而 Operator 接收到事件權(quán)重之后將會(huì)將事件分配給 Sink。

ETL 多級(jí)壓縮和去重

上述的數(shù)據(jù)鏈路也會(huì)做 ETL 多級(jí)壓縮和去重工作，主要是 Parquet 原始數(shù)據(jù)會(huì)經(jīng)過每小時(shí)的智能壓縮去重的 ETL 工作，產(chǎn)生更大的 Parquet File。同理，對(duì)于小時(shí)級(jí)別壓縮去重不夠的文件，每天還會(huì)再進(jìn)行一次壓縮去重。對(duì)于新產(chǎn)生的數(shù)據(jù)會(huì)有一個(gè)原子性的分區(qū)交換，也就是說當(dāng)產(chǎn)生新的數(shù)據(jù)之后，ETL Job 會(huì)讓 Hive metastore 里的表分區(qū)指向新的數(shù)據(jù)和分區(qū)。這里的過程使用了啟發(fā)性算法來分析哪些事件必須要經(jīng)過壓縮和去重以及壓縮去重的時(shí)間間隔級(jí)別。此外，為了滿足隱私和合規(guī)的要求，一些 ETL 數(shù)據(jù)會(huì)被保存數(shù)以年計(jì)的時(shí)間。

 

 

三、平臺(tái)性能及容錯(cuò)深入分析

事件時(shí)間驅(qū)動(dòng)的分區(qū)感測

Flink 和 ETL 是通過事件時(shí)間驅(qū)動(dòng)的分區(qū)感測實(shí)現(xiàn)同步的。S3 采用的是比較常見的分區(qū)格式，最后的分區(qū)是由時(shí)間戳決定的，時(shí)間戳則是基于 EventTime 的，這樣的好處在于能夠帶來 Flink 和 ETL 共同的時(shí)間源，這樣有助于同步操作。此外，基于事件時(shí)間能夠使得一些回填操作和主操作實(shí)現(xiàn)類似的結(jié)果。Flink 處理完每個(gè)小時(shí)的事件后會(huì)向事件分區(qū)寫入一個(gè) Success 文件，這代表該小時(shí)的事件已經(jīng)處理完畢，ETL 可以對(duì)于該小時(shí)的文件進(jìn)行操作了。

 

 

Flink 本身的水印并不能直接用到 Lyft 的應(yīng)用場景當(dāng)中，主要是因?yàn)楫?dāng) Flink 處理完時(shí)間戳并不意味著它已經(jīng)被持久化到存儲(chǔ)當(dāng)中，此時(shí)就需要引入分區(qū)水印的概念，這樣一來每個(gè) Sink Source 就能夠知道當(dāng)前寫入的分區(qū)，并且維護(hù)一個(gè)分區(qū) ID，并且通過 Global State Aggregator 聚合每個(gè)分區(qū)的信息。每個(gè) Subtasks 能夠知道全局的信息，并將水印定義為分區(qū)時(shí)間戳中最小的一個(gè)。

 

 

ETL 主要有兩個(gè)特點(diǎn)，分別是及時(shí)性和去重，而 ETL 的主要功能在于去重和壓縮，最重要的是在非阻塞的情況下就進(jìn)行去重。前面也提到 Smart ETL，所謂 Smart 就是智能感知，需要兩個(gè)相應(yīng)的信息來引導(dǎo) Global State Aggregator，分別是分區(qū)完整性標(biāo)識(shí) SuccessFile，在每個(gè)分區(qū)還有幾個(gè)相應(yīng)的 States 統(tǒng)計(jì)信息能夠告訴下游的 ETL 怎樣去重和壓縮以及操作的頻率和范圍。

 

 

Schema 演進(jìn)的挑戰(zhàn)

ETL 除了去重和壓縮的挑戰(zhàn)之外，還經(jīng)常會(huì)遇到 Schema 的演化挑戰(zhàn)。Schema 演化的挑戰(zhàn)分為三個(gè)方面，即不同引擎的數(shù)據(jù)類型、嵌套結(jié)構(gòu)的演變、數(shù)據(jù)類型演變對(duì)去重邏輯的影響。

 

 

S3 深入分析

Lyft 的數(shù)據(jù)存儲(chǔ)系統(tǒng)其實(shí)可以認(rèn)為是數(shù)據(jù)湖，對(duì)于 S3 而言，Lyft 也有一些性能的優(yōu)化考量。S3 本身內(nèi)部也是有分區(qū)的，為了使其具有并行的讀寫性能，添加了 S3 的熵?cái)?shù)前綴，在分區(qū)里面也增加了標(biāo)記文件，這兩種做法能夠極大地降低 S3 的 IO 性能的影響。標(biāo)識(shí)符對(duì)于能否觸發(fā) ETL 操作會(huì)產(chǎn)生影響，與此同時(shí)也是對(duì)于 presto 的集成，能夠讓 presto 決定什么情況下能夠掃描多少個(gè)文件。

 

 

Parquet 優(yōu)化方案

Lyft 的準(zhǔn)實(shí)時(shí)數(shù)據(jù)分析平臺(tái)在 Parquet 方面做了很多優(yōu)化，比如文件數(shù)據(jù)值大小范圍統(tǒng)計(jì)信息、文件系統(tǒng)統(tǒng)計(jì)信息、基于主鍵數(shù)據(jù)值的排序加快 presto 的查詢速度以及二級(jí)索引的生成。

 

 

基于數(shù)據(jù)回填的平臺(tái)容錯(cuò)機(jī)制

如下兩個(gè)圖所示的是 Lyft 準(zhǔn)實(shí)時(shí)數(shù)據(jù)分析平臺(tái)的基于數(shù)據(jù)回填的平臺(tái)容錯(cuò)機(jī)制。對(duì)于 Flink 而言，因?yàn)槠脚_(tái)的要求是達(dá)到準(zhǔn)實(shí)時(shí)，而 Flink 的 Job 出現(xiàn)失效的時(shí)候可能會(huì)超過一定的時(shí)間，當(dāng) Job 重新開始之后就會(huì)形成兩個(gè)數(shù)據(jù)流，主數(shù)據(jù)流總是從最新的數(shù)據(jù)開始往下執(zhí)行，附加數(shù)據(jù)流則可以回溯到之前中斷的位置進(jìn)行執(zhí)行直到中斷結(jié)束的位置。這樣的好處是既能保證主數(shù)據(jù)流的準(zhǔn)實(shí)時(shí)特性，同時(shí)通過回填數(shù)據(jù)流保證數(shù)據(jù)的完整性。

 

 

對(duì)于 ETL 而言，基于數(shù)據(jù)回填的平臺(tái)容錯(cuò)機(jī)制則表現(xiàn)在 Airflow 的冪等調(diào)度系統(tǒng)、原子壓縮和 HMS 交換操作、分區(qū)自建自修復(fù)體系和 Schema 整合。

 

 

四、總結(jié)與未來展望

體驗(yàn)與經(jīng)驗(yàn)教訓(xùn)

利用 Flink 能夠準(zhǔn)實(shí)時(shí)注入 Parquet 數(shù)據(jù)，使得交互式查詢體驗(yàn)為可能。同時(shí)，F(xiàn)link 在 Lyft 中的應(yīng)用很多地方也需要提高，雖然 Flink 在大多數(shù)情況的延時(shí)都能夠得到保證，但是重啟和部署的時(shí)候仍然可能造成分鐘級(jí)別的延時(shí)，這會(huì)對(duì)于 SLO 產(chǎn)生一定影響。

此外，Lyft 目前做的一件事情就是改善部署系統(tǒng)使其能夠支持 Kubernetes，并且使得其能夠接近 0 宕機(jī)時(shí)間的效果。因?yàn)?Lyft 準(zhǔn)實(shí)時(shí)數(shù)據(jù)分析平臺(tái)在云端運(yùn)行，因此在將數(shù)據(jù)上傳到 S3 的時(shí)候會(huì)產(chǎn)生一些隨機(jī)的網(wǎng)絡(luò)情況，造成 Sink Subtasks 的停滯，進(jìn)而造成整個(gè) Flink Job 的停滯。而通過引入一些 Time Out 機(jī)制來檢測 Sink Subtasks 的停滯，使得整個(gè) Flink Job 能夠順利運(yùn)行下去。

ETL 分區(qū)感應(yīng)能夠降低成本和延遲，成功文件則能夠表示什么時(shí)候處理完成。此外，S3 文件布局對(duì)性能提升的影響還是非常大的，目前而言引入熵?cái)?shù)還屬于經(jīng)驗(yàn)總結(jié)，后續(xù) Lyft 也會(huì)對(duì)于這些進(jìn)行總結(jié)分析并且公開。因?yàn)槭褂?Parquet 數(shù)據(jù)，因此對(duì)于 Schema 的兼容性要求就非常高，如果引入了不兼容事件則會(huì)使得下游的 ETL 癱瘓，因此 Lyft 已經(jīng)做到的就是在數(shù)據(jù)鏈路上游對(duì)于 Schema 的兼容性進(jìn)行檢查，檢測并拒絕用戶提交不兼容的 Schema。

 

 

未來展望

Lyft 對(duì)于準(zhǔn)實(shí)時(shí)數(shù)據(jù)分析平臺(tái)也有一些設(shè)想。

首先，Lyft 希望將 Flink 部署在 Kubernetes 集群環(huán)境下運(yùn)行，使得 Kubernetes 能夠管理這些 Flink Job，同時(shí)也能夠充分利用 Kubernetes 集群的高可擴(kuò)展性。

其次，Lyft 也希望實(shí)現(xiàn)通用的流數(shù)據(jù)導(dǎo)入框架，準(zhǔn)實(shí)時(shí)數(shù)據(jù)分析平臺(tái)不僅僅支持事件，也能夠支持?jǐn)?shù)據(jù)庫以及服務(wù)日志等數(shù)據(jù)。

再次，Lyft 希望平臺(tái)能夠?qū)崿F(xiàn) ETL 智能壓縮以及事件驅(qū)動(dòng) ETL，使得回填等事件能夠自動(dòng)觸發(fā)相應(yīng)的 ETL 過程，實(shí)現(xiàn)和以前的數(shù)據(jù)的合并，同時(shí)將延時(shí)數(shù)據(jù)導(dǎo)入來對(duì)于 ETL 過程進(jìn)行更新。

最后，Lyft 還希望準(zhǔn)實(shí)時(shí)數(shù)據(jù)分析平臺(tái)能夠?qū)崿F(xiàn)存儲(chǔ)過程的改進(jìn)以及查詢優(yōu)化，借助 Parquet 的統(tǒng)計(jì)數(shù)據(jù)來改善 presto 的查詢性能，借助表格管理相關(guān)的開源軟件對(duì)存儲(chǔ)管理進(jìn)行性能改善，同時(shí)實(shí)現(xiàn)更多的功能。

 

 

作者介紹：

徐贏博士是 Lyft 數(shù)據(jù)平臺(tái)流媒體平臺(tái)的技術(shù)領(lǐng)導(dǎo)(Technical Lead)，目前主導(dǎo)準(zhǔn)實(shí)時(shí)數(shù)據(jù)分析平臺(tái)的架構(gòu)開發(fā)。在 Lyft 之前，他曾在領(lǐng)英 (Linkedin) 以及 IBM 擔(dān)任技術(shù)領(lǐng)導(dǎo)職位，主導(dǎo)領(lǐng)英跨數(shù)據(jù)中心數(shù)據(jù)庫復(fù)制的上線，以及 IBM 高速數(shù)據(jù)傳輸技術(shù)的研發(fā)。

高立博士在 Lyft 的數(shù)據(jù)平臺(tái)團(tuán)隊(duì)中工作，目前領(lǐng)導(dǎo) Lyft 數(shù)據(jù)平臺(tái)內(nèi)的多個(gè)數(shù)據(jù)基礎(chǔ)架構(gòu)項(xiàng)目，包括實(shí)時(shí)數(shù)據(jù)倉庫，自服務(wù)機(jī)器學(xué)習(xí)平臺(tái)項(xiàng)目等。 曾在 Salesforce，F(xiàn)itbit，Groupon 和其他初創(chuàng)公司擔(dān)任關(guān)鍵技術(shù)領(lǐng)導(dǎo)職務(wù)。

標(biāo)簽： 數(shù)據(jù)分析平臺(tái) Flink

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。