Flink 助力美团数仓增量生产的应用实践
本文由美團研究員、實時計算負責人鞠大升分享，主要介紹 Flink 助力美團數(shù)倉增量生產的應用實踐。內容包括：
一、數(shù)倉增量生產
1.美團數(shù)倉架構
先介紹一下美團數(shù)倉的架構以及增量生產。如下圖所示，這是美團數(shù)倉的簡單架構，我把它叫做三橫四縱。所謂三橫，第一是貫穿全鏈路的元數(shù)據(jù)以及血緣，貫穿數(shù)據(jù)集成、數(shù)據(jù)處理、數(shù)據(jù)消費、以及數(shù)據(jù)應用的全過程鏈路。另外一塊貫穿全鏈路的是數(shù)據(jù)安全，包括受限域的認證系統(tǒng)、權限系統(tǒng)、整體的審計系統(tǒng)。根據(jù)數(shù)據(jù)的流向，我們把數(shù)據(jù)處理的過程分為數(shù)據(jù)集成、數(shù)據(jù)處理、數(shù)據(jù)消費、以及數(shù)據(jù)應用這 4 個階段。
在數(shù)據(jù)集成階段，我們對于公司內部的，比如說用戶行為數(shù)據(jù)、日志數(shù)據(jù)、DB 數(shù)據(jù)、還有文件數(shù)據(jù)，都有相應的集成的系統(tǒng)把數(shù)據(jù)統(tǒng)一到我們的數(shù)據(jù)處理的存儲中，比如說 Kafka 中。
在數(shù)據(jù)處理階段，分為流式處理鏈路、批處理鏈路以及基于這套鏈路的數(shù)倉工作平臺（萬象平臺）。生產出來的數(shù)據(jù)，經過 Datalink 導入到消費的存儲中，最終通過應用以不同的形式呈現(xiàn)出來。
我們目前在 Flink 上面應用比較廣泛的地方，包括從 Kafka 把數(shù)據(jù)導到 Hive，包括實時的處理，數(shù)據(jù)導出的過程。今天的分享就集中在這些方面。
2.美團 Flink 應用概況
美團的 Flink 目前大概有 6000 臺左右的物理機，支撐了 3 萬左右的作業(yè)。我們消費的 Topic 數(shù)在 5 萬左右，每天的高峰流量在 1.8 億條每秒這樣的水平上。
3.美團 Flink 應用場景
美團 Flink 主要應用的場景包括四大塊。
- 第一，實時數(shù)倉、經營分析、運營分析、實時營銷。
- 第二，推薦、搜索。
- 第三，風控、系統(tǒng)監(jiān)控。
- 第四，安全審計。
4.實時數(shù)倉 vs 數(shù)倉增量生產
接下來我要引入增量生產的概念。離線數(shù)倉關注的三塊需求，第一個就是時效性。第二個就是質量，產出的數(shù)據(jù)的質量。第三個就是成本。
關于時效性，有兩個更深層次的含義，第一個叫做實時，第二個叫準時。并不是所有的業(yè)務需求都是實時的，很多時候我們的需求是準時。比如做經營分析，每天拿到相應的昨天的經營數(shù)據(jù)情況即可。實時數(shù)倉更多的是解決實時方面的需求。但是在準時這一塊，作為一個企業(yè)，更希望在準時跟成本之間做一個權衡。所以，我把數(shù)倉的增量生產定義為對離線數(shù)倉的一個關于準時跟成本的權衡。另外，數(shù)倉增量生產解決比較好的一個方面是質量，問題能夠及時發(fā)現(xiàn)。
5.數(shù)倉增量生產的優(yōu)勢
數(shù)倉增量生產的優(yōu)勢有兩點。
- 能夠及時發(fā)現(xiàn)數(shù)據(jù)質量問題，避免 T+1 修復數(shù)據(jù)。
- 充分利用資源，提前數(shù)據(jù)產出時間。
如下圖所示，我們期望做的實際上是第二幅圖。我們期望把離線的生產占用的資源降低，但同時希望它的產出時間能夠提前一步。
二、流式數(shù)據(jù)集成
1.數(shù)據(jù)集成 V1.0
我們來看一下流式數(shù)據(jù)集成的第一代。當數(shù)據(jù)量非常小以及庫非常少的時候，直接做一個批的傳輸系統(tǒng)。在每天凌晨的時候把相應的 DB 數(shù)據(jù)全部 load 一遍，導到數(shù)倉里面。這個架構優(yōu)勢是非常簡單，易于維護，但是它的缺點也非常明顯，對于一些大的 DB 或者大的數(shù)據(jù)，load 數(shù)據(jù)的時間可能需要 2~3 個小時，非常影響離線數(shù)倉的產出時間。
2.數(shù)據(jù)集成 V2.0
基于這個架構，我們增加了流式傳遞的鏈路，我們會有經過流式傳輸?shù)牟杉到y(tǒng)把相應的 Binlog 采集到 Kafka，同時會經過一個 Kafka 2 Hive 的程序把它導入到原始數(shù)據(jù)，再經過一層 Merge，產出下游需要的 ODS 數(shù)據(jù)。
數(shù)據(jù)集成 V2.0 的優(yōu)勢是非常明顯的，我們把數(shù)據(jù)傳輸?shù)臅r間放到了 T+0 這一天去做，在第二天的時候只需要去做一次 merge 就可以了。這個時間可能就從 2~3 個小時減少到一個小時了，節(jié)省出來的時間是非常可觀的。
3.數(shù)據(jù)集成 V3.0
在形式上，數(shù)據(jù)集成的第三代架構前面是沒什么變化的，因為它本身已經做到了流式的傳輸。關鍵是后面 merge 的流程。每天凌晨 merge 一個小時，仍然是非常浪費時間資源的，甚至對于 HDFS 的壓力都會非常大。所以在這塊，我們就迭代了 HIDI 架構。
這是我們內部基于 HDFS 做的。
4.HIDI
我們設計 HIDI，核心的訴求有四點。第一，支持 Flink 引擎讀寫。第二，通過 MOR 模式支持基于主鍵的 Upsert/Delete。第三，小文件管理 Compaction。第四，支持 Table Schema。
基于這些考慮，我們來對比一下 HIDI，Hudi 和 Iceberg。
HIDI 的優(yōu)勢包括：
- 支持基于主鍵的 Upsert/Delete
- 支持和 Flink 集成
- 小文件管理 Compaction
劣勢包括：不支持增量讀。
Hudi 的優(yōu)勢包括：
- 支持基于主鍵的 Upsert/Delete
- 小文件管理 Compaction
劣勢包括：
- 寫入限定 Spark/DeltaStreamer
- 流讀寫支持 SparkStreaming
Iceberg 的優(yōu)勢包括： 支持和 Flink 集成。
劣勢包括：
- 支持基于 Join 的 Upsert/Delete
- 流式讀取未支持。
5.流式數(shù)據(jù)集成效果
如下圖所示，我們有數(shù)據(jù)產生，數(shù)據(jù)集成，ETL 生產三個階段。把流式數(shù)據(jù)集成做到 T+0，ETL 的生產就可以提前了，節(jié)省了我們的成本。
三、流式數(shù)據(jù)處理
1.ETL 增量生產
我們來講一下 ETL 的增量生產過程。我們的數(shù)據(jù)從前面進來，到 Kafka 之后，有 Flink 實時，然后到 Kafka，再到事件的服務，甚至到分析的場景中，這是我們自己做的分析鏈路。
下面是批處理的一個鏈路，我們通過 Flink 的集成，集成到 HDFS，然后通過 Spark 去做離線生產，再經過 Flink 把它導出到 OLAP 的應用中。在這樣的架構中，增量的生產實際上就是下圖標記為綠色的部分，我們期望用 Flink 的增量生產的結構去替換掉 Spark。
2.SQL 化是 ETL 增量生產的第一步
這樣的一個架構有三個核心的能力。
- 第一， Flink 的 SQL 的能力要對齊 Spark。
- 第二， 我們的 Table Format 這一層需要能夠支持 Upsert/Delete 這樣的主鍵更新的實時操作。
- 第三， 我們的 Table Format 能夠支持全量和增量的讀取。
我們的全量用于查詢和修復數(shù)據(jù)，而我們的增量是用來進行增量的生產。SQL 化是 ETL 增量生產的第一步，今天分享的主要是說我們基于 Flink SQL 做的實時數(shù)倉平臺對這一塊的支持。
3.實時數(shù)倉模型
如下圖所示，這是實時數(shù)倉的模型。業(yè)界應該都看過這樣的一個模型。
4.實時數(shù)倉平臺架構
實時數(shù)倉的平臺架構，分為資源層、存儲層、引擎層、SQL 層、平臺層、還有應用層。在這里重點強調兩點。
- 第一，是對于 UDF 的支持。因為 UDF 是彌補算子能力中的非常重要的一環(huán)，我們希望在這里面做的 UDF 能夠加大對于 SQL 能力的支持。
- 第二，是在這個架構里面只支持了 Flink Streaming 的能力，我們并沒有去做 Flink 的批處理的能力，因為我們設想未來所有的架構都是基于 streaming 去做的，這跟社區(qū)的發(fā)展方向也是一致的。
5.實時數(shù)倉平臺 Web IDE
這是我們數(shù)倉平臺的一個 Web IDE。在這樣的一個 IDE，我們支持了一個 SQL 的建模的過程，支持了 ETL 的開發(fā)的能力。
四、流式 OLAP 應用
1.異構數(shù)據(jù)源同步
下面看關于流式的導出跟 OLAP 的應用這一塊。如下圖所示，是異構數(shù)據(jù)源的同步圖。業(yè)界有很多開源的產品做這一塊。比如說，不同的存儲里面，數(shù)據(jù)總是在其中進行交換。我們的想法是做一個 Datalink 這樣的一個中間件，或者是中間的平臺。然后我們把 N 對 N 的數(shù)據(jù)交換的過程，抽象成一個 N 對 1 的交換過程。
2.基于 DataX 的同步架構
異構數(shù)據(jù)源的第一版是基于 DataX 來做同步的架構。在這套架構里面，包含了工具平臺層、調度層、執(zhí)行層。
- 工具平臺層的任務非常簡單，主要是對接用戶，配置同步任務，配置調度，運維。
- 調度層負責的是任務的調度，當然對于任務的狀態(tài)管理，以及執(zhí)行機的管理，很多的工作都需要我們自己去做。
在真正的執(zhí)行層，通過 DataX 的進程，以及 Task 多線程的一個形式，真正執(zhí)行把數(shù)據(jù)從源同步到目的地。 - 在這樣的一個架構里面，發(fā)現(xiàn)兩個核心的問題。第一個問題就是擴展性的問題。開源的單機版的 DataX 是一個單機多線程的模型，當我們需要傳輸?shù)臄?shù)據(jù)量非常大的時候，單機多線程模型的可擴展性是很大的問題。第二個問題在調度層，我們需要去管理機器、同步的狀態(tài)、同步的任務，這個工作非常繁瑣。當我們的調度執(zhí)行機發(fā)生故障的時候，整個災備都需要我們單獨去做這塊的事情。
3.基于 Flink 的同步架構
基于這樣的架構，我們把它改成了一個 Flink 的同步的架構。前面不變，還是工具平臺層。在原有的架構里面，我們把調度層里面關于任務調度和執(zhí)行機的管理這一塊都交給了 Yarn 去做，這樣我們就從中解脫出來了。第二個，我們在調度層里面的任務狀態(tài)管理可以直接遷移到 cluster 里面去。
基于 Flink 的 Datalink 的架構優(yōu)勢非常明顯。
- 第一， 可擴展性問題得到解決了，同時架構也非常簡單。現(xiàn)在當我們把一個同步的任務拆細之后，它在 TaskManager 里面可以擴散到分布式的集群中。
- 第二， 離線跟實時的同步任務，都統(tǒng)一到了 Flink 框架。我們所有同步的 Source 和 Sink 的主鍵，都可以進行共用，這是非常大的一個優(yōu)勢。
3.基于 Flink 的同步架構關鍵設計
我們看一下基于 Flink 的同步架構的關鍵設計，這里總結的經驗有四點。
- 第一，避免跨 TaskManager 的 Shuffle，避免不必要的序列化成本；
- 第二，務必設計臟數(shù)據(jù)收集旁路和失敗反饋機制；
- 第三，利用 Flink 的 Accumulators 對批任務設計優(yōu)雅退出機制；
- 第四，利用 S3 統(tǒng)一管理 Reader/Writer 插件，分布式熱加載，提升部署效率。
4.基于 Flink 的 OLAP 生產平臺
基于 Flink 我們做了 Datalink 這樣的一個數(shù)據(jù)導出的平臺，基于 Datalink 的導出平臺做了 OLAP 的生產平臺，在這邊除了底層的引擎層之外，我們做了平臺層。在這上面，我們對于資源、模型、任務、權限，都做了相應的管理，使得我們進行 OLAP 的生產非常快捷。
這是我們的 OLAP 生產的兩個截圖。一個是對于 OLAP 中的模型的管理，一個是對于 OLAP 中的任務配置的管理。
五、未來規(guī)劃
經過相應的迭代，我們把 Flink 用到了數(shù)據(jù)集成、數(shù)據(jù)處理、離線數(shù)據(jù)的導出，以及 OLAP 生產的過程中。我們期望未來對于流批的處理能夠是統(tǒng)一的，希望數(shù)據(jù)也是流批統(tǒng)一的。我們希望，不管是實時的鏈路，還是增量處理的鏈路，在未來數(shù)據(jù)統(tǒng)一之后，統(tǒng)一用 Flink 處理，達到真正的流批一體。
原文鏈接：https://developer.aliyun.com/article/781482?
版權聲明：本文內容由阿里云實名注冊用戶自發(fā)貢獻，版權歸原作者所有，阿里云開發(fā)者社區(qū)不擁有其著作權，亦不承擔相應法律責任。具體規(guī)則請查看《阿里云開發(fā)者社區(qū)用戶服務協(xié)議》和《阿里云開發(fā)者社區(qū)知識產權保護指引》。如果您發(fā)現(xiàn)本社區(qū)中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區(qū)將立刻刪除涉嫌侵權內容。 與50位技術專家面對面20年技術見證，附贈技術全景圖總結
以上是生活随笔為你收集整理的Flink 助力美团数仓增量生产的应用实践的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 浩鲸科技携手阿里云原生共同打造“场域运营
- 下一篇： 边缘计算在天猫精灵云应用上的落地实践