一、美團數(shù)倉架構圖

如上圖，是美團最新的數(shù)倉架構圖。

整個架構圖分為三層，從下往上看，最下面一層是數(shù)據(jù)安全，包括受限域認證系統(tǒng)、加工層權限系統(tǒng)，應用層權限系統(tǒng)，安全審計系統(tǒng)，來保證最上層數(shù)據(jù)集成與處理的安全；

中間一層是統(tǒng)一的元數(shù)據(jù)中心和全鏈路血緣，覆蓋了全鏈路的加工過程；

最上層根據(jù)數(shù)據(jù)的流向，分成數(shù)據(jù)集成，數(shù)據(jù)處理，數(shù)據(jù)消費，數(shù)據(jù)應用，四個階段；

在數(shù)據(jù)集成階段，對于不同的數(shù)據(jù)來源（包括用戶行為數(shù)據(jù)，日志數(shù)據(jù)，DB 數(shù)據(jù)，文件數(shù)據(jù)），都有相對應的數(shù)據(jù)集成系統(tǒng)，把數(shù)據(jù)收集到統(tǒng)一的存儲之中，包括 Kafka 和 Hive 等。

在數(shù)據(jù)處理階段，有一個面向用戶的數(shù)據(jù)開發(fā)平臺（萬象平臺），可以使用兩條數(shù)據(jù)處理鏈路來加工數(shù)據(jù)，一個是流式處理鏈路，一個是離線處理鏈路。

數(shù)據(jù)加工好了之后，使用內(nèi)部自研的 DeltaLink 同步數(shù)據(jù)到其他的應用中，例如即席分析，即席查詢，報表等應用。

上圖中標紅的地方，Kafka -> HDFS，F(xiàn)link，DeltaLink 是本次重點分享的內(nèi)容。

二、美團當前 Flink 應用場景和規(guī)模

美團 Flink 應用場景包括：

實時數(shù)倉、經(jīng)營分析、運營分析、實時營銷
推薦、搜索
風控、系統(tǒng)監(jiān)控
安全審計

Flink 集群規(guī)模如下（高峰流量是每天最高峰的流量）：

三、基于 Flink 的流式數(shù)據(jù)集成

數(shù)據(jù)集成經(jīng)歷了多個版本的迭代

1. 數(shù)據(jù)集成 V1.0

V1.0 版本很簡單，是完全批量同步的架構。

在數(shù)據(jù)量比較少的情況下，這樣的批同步的架構，優(yōu)勢很明顯，架構簡單，非常簡單易于維護。

但是缺點也很明顯，光是數(shù)據(jù)傳輸就 1 - 2 個小時。

2. 數(shù)據(jù)集成 V2.0

在 V2.0 中，增加了流式傳輸?shù)逆溌罚ㄏ旅娴逆溌罚?，把?shù)據(jù)實時傳輸?shù)?ODS 中（批量傳輸?shù)逆溌啡匀皇潜仨毜?，作為第一次全量的導入）?/span>

流式傳輸系統(tǒng)，使用 canal （阿里開源）采集 Mysql 的 binlog 日志到 kafka。后邊有一個 Kafka2Hive 系統(tǒng)，這個系統(tǒng)經(jīng)過了多個版本的迭代。

Kafka2Hive 模塊，最開始是使用 Camus ，每一個小時拉一次數(shù)據(jù)，跑在 Spark 上。后面改成使用 SparkStreaming ，但是 Spark Streaming 在資源的利用方面有一些問題的，所以最終弄全部遷移到了 Flink 框架上來。

這樣的架構，優(yōu)勢是非常明顯的：把數(shù)據(jù)傳輸放在了 T+0 的時間去做，T + 1 的時間只需要經(jīng)過一次 Merge 即可，花費的時間可能就從 2 - 3 個小時減少到 1 個小時了，提升是非常明顯的。

3. 數(shù)據(jù)集成 V3.0

數(shù)據(jù)集成 V3.0 的架構，前面的部分和 V2.0 一樣，關鍵的是后面這一部分。

在 V2.0 架構中，凌晨需要對數(shù)據(jù)做一次 Merge，這個操作對于 Hdfs 的壓力非常大，要把幾十 T 的數(shù)據(jù)讀過來，清洗一遍，再把幾十 T 的數(shù)據(jù)寫入到 Hdfs。

所以，在 V3.0 架構中，引用了 Hidi 架構（Hidi 是美團內(nèi)部基于 Hdfs 開發(fā)的類似 Hudi 或者 Iceberg 的文件格式）。

4. 美團自研的 Hidi

要做到增量生產(chǎn)，最關鍵的特性在于

支持增量讀取，也就是讀取當前時間到前一段時間的數(shù)據(jù)，才能做到增量；
支持基于主鍵的 Upsert/Delete。Hidi 是美團在 2，3 年前，在內(nèi)部自研的架構，此架構的特性在于：
支持 Flink 引擎讀寫；
通過 MOR 模式支持基于主鍵的 upsert/Delete；
小文件管理 Compaction；
Table Schema

可以對比 Hidi、Hudi、Iceberg，如下：

Hudi 最亮眼的特性是支持基于主鍵的 Upsert/Delete，但劣勢是深度和 Spark 綁定，但在國內(nèi) Flink 框架這么火熱的情況下，難免會有點美中不足。

Iceberg 不依賴于執(zhí)行引擎，可以深度和 Flink 集成。

美團自研的 Hidi 則根據(jù)自己的需求實現(xiàn)了諸多的特性，目前仍然在完善中。

四、基于 Flink 的增量生產(chǎn)

1、傳統(tǒng)離線數(shù)倉特性分析

一般我們說數(shù)倉，都是指離線數(shù)倉。離線數(shù)倉有三個重要的指標，一是時效性，二是質(zhì)量，三是成本。

首先是時效性，有兩個更深層次的含義，一個是實時，一個是準時。

實時就是實時流式處理，來一條處理一條，實時處理消耗的資源很多。

準時，就是按時處理。比如廣告需求，可能只需要在每個整點，統(tǒng)計過去一小時或者在每個整點統(tǒng)計當天的數(shù)據(jù)即可，沒有必要做到實時，只需要到點能產(chǎn)出數(shù)據(jù)就行。

所以，總結下來，離線數(shù)倉和實時數(shù)倉各有利弊，離線數(shù)倉在質(zhì)量和成本上會有優(yōu)勢，但是時效性不足；實時數(shù)倉，在時效性上很有優(yōu)勢，但是質(zhì)量和成本都略遜色。

2. 增量生產(chǎn)

如下圖，是離線數(shù)倉、實時數(shù)倉和增量計算的對比

所謂增量計算，就是企業(yè)在時效性、質(zhì)量、成本上做一個權衡，時效性需要高一點，但是不用做到 RealTime，OnTime 也可以接受（ 8 點看報表，提前到 3 點計算好也沒有很大的意義），但是質(zhì)量要高，成本也需要盡量少。

3. 增量計算的優(yōu)點

增量計算最大的優(yōu)點，就是可以盡快的發(fā)現(xiàn)問題。

一般我們會在第二天花 8 個小時到 12 個小時，把前一天的數(shù)據(jù)生產(chǎn)出來。但是如果第二天發(fā)現(xiàn)數(shù)據(jù)錯了，可能要花一天的時間去修復數(shù)據(jù)，這個時候，準時性和質(zhì)量都被打破了。

如下圖，橫坐標是時間（T 表示當天，T+1 表示第二天），黑色線表示離線生產(chǎn)，大概利用 T + 1 一半資源去生產(chǎn)。紅色線是實時生產(chǎn)，在當天就生產(chǎn)數(shù)據(jù)，占用的資源比離線計算高。

下圖是增量生產(chǎn)的示意圖。

綠色線是增量計算，在當天就計算好。

黑色線是離線計算，在第二天的前半天計算。

增量計算，是在當天計算，在當天就能提前發(fā)現(xiàn)問題，避免 T + 1 修復數(shù)據(jù)。并且還可以充分利用資源，提前產(chǎn)出數(shù)據(jù)的時間，并且占用資源更少。

4. 增量生產(chǎn)架構圖

下圖是美團增量生產(chǎn)的架構圖（目前的架構正在逐步完善中，還沒有完全實現(xiàn)）

如圖，最上面是實時處理的鏈路，F(xiàn)link 消費 Kafka 數(shù)據(jù) 到下游的 kafka，輸出結果給下游使用或者供 OLAP 分析。

下面的鏈路是批處理，首先 kafka 數(shù)據(jù)經(jīng)過 Flink 集成到 HDFS，再通過 Spark 做離線的生產(chǎn)，最終經(jīng)過 Flink 導出到 OLAP 應用里面去。

上文提到的增量生產(chǎn)，就是圖中標綠色的部分，希望可以用增量生產(chǎn)來替換掉 Spark 離線計算，做到計算引擎的統(tǒng)一。

要能支持增量生產(chǎn)，需要具備幾個核心的能力：

Flink SQL 能力能夠?qū)R Spark SQL；
Hidi 支持 Upsert/Delete 特性（Hidi 已支持）；
Hidi 支持全量和增量的讀取，全量讀取用于查詢和修復數(shù)據(jù)，增量讀取用來增量生產(chǎn)；

五、實時數(shù)倉模型與架構

如下圖是實時數(shù)倉的模型，基本上都見過

下圖是實時數(shù)倉平臺的架構圖

整個架構，分為資源層、存儲層、引擎層、SQL 層、平臺層和應用層。

六、流式導出與 OLAP 應用

1. 異構數(shù)據(jù)源的同步

如上圖，是異構數(shù)據(jù)源的同步。數(shù)據(jù)會在不同的存儲系統(tǒng)中交換，所以我們做了一個 Deltalink 的平臺，把數(shù)據(jù) N 對 N 的交換過程，抽象成 N 對 1 的交換過程。

我們也迭代改進了很多版本。

2. 第一版實現(xiàn)

第一版是基于 DataX （阿里開源）來做同步，包含工具平臺層，調(diào)度層，執(zhí)行層。

工具平臺層，對接用戶，用來配置同步任務，配置調(diào)度，運維任務；
調(diào)度層，負責任務的調(diào)度，管理任務狀態(tài)管理，以及執(zhí)行機的管理，這其中有非常多的額外工作都需要自己做；
執(zhí)行層，通過 DataX 進程，以及 Task 線程從源存儲同步到目標存儲。

但劣勢也很明顯，開源版的 DataX 是一個單機多線程的模型，當數(shù)據(jù)量非常大的時候，單機多線程是成為了瓶頸，限制了可擴展性；

然后在調(diào)度層，需要管理機器，管理同步的任務和狀態(tài)，非常繁瑣；

當調(diào)度執(zhí)行機發(fā)生故障的時候，整個災備都需要單獨去做。

3. 第二版實現(xiàn)

在第二版中，改成了基于 Flink 同步的架構，看起來就清爽了很多。

工具平臺層沒有變，調(diào)度層的任務調(diào)度和執(zhí)行機管理都交給 Yarn 去做。

調(diào)度層的任務狀態(tài)管理，可以遷移到 Client 中去做。

基于 Flink 的 DeltaLink 的架構，解決了可擴展性問題，而且架構非常簡單。

當把同步的任務拆細之后，可以分布式的分布到不同的 TaskManager 里去執(zhí)行。

并且離線和實時的同步，都可以統(tǒng)一到 Flink 框架中去，這樣離線和實時同步的 Source 和 Sink 組件都可以共用一套。

4. 基于 Flink 的同步架構關鍵設計

避免跨 TaskManager 的 Shuffle，避免不必要的序列化成本；Source 和 Sink 盡量在同一個 TaskManager；
務必設計臟數(shù)據(jù)收集旁路和失敗反饋機制；數(shù)據(jù)同步遇到臟數(shù)據(jù)的時候，比如失敗了 1% 的時候，直接停下來；
利用 Flink 的 Accumulators 對批任務設計優(yōu)雅退出機制；數(shù)據(jù)傳輸完之后，通知下游數(shù)據(jù)同步完了；
利用 S3 統(tǒng)一管理 Reader/Writer 插件，分布式熱加載，提升部署效率；很多傳輸任務都是小任務，而作業(yè)部署時間又非常長，所以需要要提前部署插件；

5. 基于 Flink 的 OLAP 生產(chǎn)平臺

基于 Flink 做了 Deltalink ，數(shù)據(jù)導出的平臺；

基于數(shù)據(jù)導出的平臺，做了 OLAP 平臺，對于資源，模型，任務和權限都做了管理。

七、未來規(guī)劃

經(jīng)過多次迭代，把 Flink 用到了數(shù)據(jù)集成、數(shù)據(jù)處理、離線數(shù)據(jù)導出、OLAP 等場景，但事情還沒有結束。

未來的目標，是要做到流批一體，把離線作業(yè)都遷移到 Flink 上來；

同時數(shù)據(jù)也要做到批流一體，這個很重要。如果數(shù)據(jù)仍然是兩份，是兩套 Schema 定義，那么不管如何處理，都需要去對數(shù)據(jù)，就不是真正的流批統(tǒng)一。

所以不管是計算還是存儲，都使用 Flink，達到真正的流批一體。

Flink 數(shù)據(jù)湖 助力美團數(shù)倉增量生產(chǎn)

一、美團數(shù)倉架構圖