Flink 助力美團數倉增量生產

時間 2021-04-05

原文原文鏈接

簡介：本文由美團研究員、實時計算負責人鞠大升分享，主要介紹 Flink 助力美團數倉增量生產的應用實踐。內容包括：一、數倉增量生產；二、流式數據集成；三、流式數據處理；四、流式 OLAP 應用；五、將來規劃。

1、數倉增量生產

1.美團數倉架構安全

先介紹一下美團數倉的架構以及增量生產。以下圖所示，這是美團數倉的簡單架構，我把它叫作三橫四縱。所謂三橫，第一是貫穿全鏈路的元數據以及血緣，貫穿數據集成、數據處理、數據消費、以及數據應用的全過程鏈路。另一塊貫穿全鏈路的是數據安全，包括受限域的認證系統、權限系統、總體的審計系統。根據數據的流向，咱們把數據處理的過程分爲數據集成、數據處理、數據消費、以及數據應用這 4 個階段。多線程

在數據集成階段，咱們對於公司內部的，好比說用戶行爲數據、日誌數據、DB 數據、還有文件數據，都有相應的集成的系統把數據統一到咱們的數據處理的存儲中，好比說 Kafka 中。
在數據處理階段，分爲流式處理鏈路、批處理鏈路以及基於這套鏈路的數倉工做平臺（萬象平臺）。生產出來的數據，通過 Datalink 導入到消費的存儲中，最終經過應用以不一樣的形式呈現出來。架構

咱們目前在 Flink 上面應用比較普遍的地方，包括從 Kafka 把數據導到 Hive，包括實時的處理，數據導出的過程。今天的分享就集中在這些方面。框架

2.美團 Flink 應用概況運維

美團的 Flink 目前大概有 6000 臺左右的物理機，支撐了 3 萬左右的做業。咱們消費的 Topic 數在 5 萬左右，天天的高峯流量在 1.8 億條每秒這樣的水平上。分佈式

3.美團 Flink 應用場景工具

美團 Flink 主要應用的場景包括四大塊。阿里雲

第一，實時數倉、經營分析、運營分析、實時營銷。
第二，推薦、搜索。
第三，風控、系統監控。
第四，安全審計。

4.實時數倉 vs 數倉增量生產spa

接下來我要引入增量生產的概念。離線數倉關注的三塊需求，第一個就是時效性。第二個就是質量，產出的數據的質量。第三個就是成本。插件

關於時效性，有兩個更深層次的含義，第一個叫作實時，第二個叫準時。並非全部的業務需求都是實時的，不少時候咱們的需求是準時。好比作經營分析，天天拿到相應的昨天的經營數據狀況便可。實時數倉更多的是解決實時方面的需求。可是在準時這一塊，做爲一個企業，更但願在準時跟成本之間作一個權衡。因此，我把數倉的增量生產定義爲對離線數倉的一個關於準時跟成本的權衡。另外，數倉增量生產解決比較好的一個方面是質量，問題可以及時發現。

5.數倉增量生產的優點

數倉增量生產的優點有兩點。

可以及時發現數據質量問題，避免 T+1 修復數據。
充分利用資源，提早數據產出時間。

以下圖所示，咱們指望作的其實是第二幅圖。咱們指望把離線的生產佔用的資源下降，但同時但願它的產出時間可以提早一步。

2、流式數據集成

1.數據集成 V1.0

咱們來看一下流式數據集成的第一代。當數據量很是小以及庫很是少的時候，直接作一個批的傳輸系統。在天天凌晨的時候把相應的 DB 數據所有 load 一遍，導到數倉裏面。這個架構優點是很是簡單，易於維護，可是它的缺點也很是明顯，對於一些大的 DB 或者大的數據，load 數據的時間可能須要 2~3 個小時，很是影響離線數倉的產出時間。

2.數據集成 V2.0

基於這個架構，咱們增長了流式傳遞的鏈路，咱們會有通過流式傳輸的採集系統把相應的 Binlog 採集到 Kafka，同時會通過一個 Kafka 2 Hive 的程序把它導入到原始數據，再通過一層 Merge，產出下游須要的 ODS 數據。

數據集成 V2.0 的優點是很是明顯的，咱們把數據傳輸的時間放到了 T+0 這一天去作，在次日的時候只須要去作一次 merge 就能夠了。這個時間可能就從 2~3 個小時減小到一個小時了，節省出來的時間是很是可觀的。

3.數據集成 V3.0

在形式上，數據集成的第三代架構前面是沒什麼變化的，由於它自己已經作到了流式的傳輸。關鍵是後面 merge 的流程。天天凌晨 merge 一個小時，仍然是很是浪費時間資源的，甚至對於 HDFS 的壓力都會很是大。因此在這塊，咱們就迭代了 HIDI 架構。

這是咱們內部基於 HDFS 作的。

4.HIDI

咱們設計 HIDI，核心的訴求有四點。第一，支持 Flink 引擎讀寫。第二，經過 MOR 模式支持基於主鍵的 Upsert/Delete。第三，小文件管理 Compaction。第四，支持 Table Schema。

基於這些考慮，咱們來對比一下 HIDI，Hudi 和 Iceberg。

HIDI 的優點包括：

支持基於主鍵的 Upsert/Delete
支持和 Flink 集成
小文件管理 Compaction

劣勢包括：不支持增量讀。

Hudi 的優點包括：

支持基於主鍵的 Upsert/Delete
小文件管理 Compaction

劣勢包括：

寫入限定 Spark/DeltaStreamer
流讀寫支持 SparkStreaming

Iceberg 的優點包括：支持和 Flink 集成。

劣勢包括：

支持基於 Join 的 Upsert/Delete
流式讀取未支持。

5.流式數據集成效果

以下圖所示，咱們有數據產生，數據集成，ETL 生產三個階段。把流式數據集成作到 T+0，ETL 的生產就能夠提早了，節省了咱們的成本。

3、流式數據處理

1.ETL 增量生產

咱們來說一下 ETL 的增量生產過程。咱們的數據從前面進來，到 Kafka 以後，有 Flink 實時，而後到 Kafka，再到事件的服務，甚至到分析的場景中，這是咱們本身作的分析鏈路。

下面是批處理的一個鏈路，咱們經過 Flink 的集成，集成到 HDFS，而後經過 Spark 去作離線生產，再通過 Flink 把它導出到 OLAP 的應用中。在這樣的架構中，增量的生產實際上就是下圖標記爲綠色的部分，咱們指望用 Flink 的增量生產的結構去替換掉 Spark。

2.SQL 化是 ETL 增量生產的第一步

這樣的一個架構有三個核心的能力。

第一， Flink 的 SQL 的能力要對齊 Spark。
第二，咱們的 Table Format 這一層須要可以支持 Upsert/Delete 這樣的主鍵更新的實時操做。
第三，咱們的 Table Format 可以支持全量和增量的讀取。

咱們的全量用於查詢和修復數據，而咱們的增量是用來進行增量的生產。SQL 化是 ETL 增量生產的第一步，今天分享的主要是說咱們基於 Flink SQL 作的實時數倉平臺對這一塊的支持。

3.實時數倉模型

以下圖所示，這是實時數倉的模型。業界應該都看過這樣的一個模型。

4.實時數倉平臺架構

實時數倉的平臺架構，分爲資源層、存儲層、引擎層、SQL 層、平臺層、還有應用層。在這裏重點強調兩點。

第一，是對於 UDF 的支持。由於 UDF 是彌補算子能力中的很是重要的一環，咱們但願在這裏面作的 UDF 可以加大對於 SQL 能力的支持。
第二，是在這個架構裏面只支持了 Flink Streaming 的能力，咱們並無去作 Flink 的批處理的能力，由於咱們設想將來全部的架構都是基於 streaming 去作的，這跟社區的發展方向也是一致的。

5.實時數倉平臺 Web IDE

這是咱們數倉平臺的一個 Web IDE。在這樣的一個 IDE，咱們支持了一個 SQL 的建模的過程，支持了 ETL 的開發的能力。

4、流式 OLAP 應用

1.異構數據源同步

下面看關於流式的導出跟 OLAP 的應用這一塊。以下圖所示，是異構數據源的同步圖。業界有不少開源的產品作這一塊。好比說，不一樣的存儲裏面，數據老是在其中進行交換。咱們的想法是作一個 Datalink 這樣的一箇中間件，或者是中間的平臺。而後咱們把 N 對 N 的數據交換的過程，抽象成一個 N 對 1 的交換過程。

2.基於 DataX 的同步架構

異構數據源的初版是基於 DataX 來作同步的架構。在這套架構裏面，包含了工具平臺層、調度層、執行層。

工具平臺層的任務很是簡單，主要是對接用戶，配置同步任務，配置調度，運維。
調度層負責的是任務的調度，固然對於任務的狀態管理，以及執行機的管理，不少的工做都須要咱們本身去作。
在真正的執行層，經過 DataX 的進程，以及 Task 多線程的一個形式，真正執行把數據從源同步到目的地。
在這樣的一個架構裏面，發現兩個核心的問題。第一個問題就是擴展性的問題。開源的單機版的 DataX 是一個單機多線程的模型，當咱們須要傳輸的數據量很是大的時候，單機多線程模型的可擴展性是很大的問題。第二個問題在調度層，咱們須要去管理機器、同步的狀態、同步的任務，這個工做很是繁瑣。當咱們的調度執行機發生故障的時候，整個災備都須要咱們單獨去作這塊的事情。