DLink 流批一體技術(shù)架構(gòu)及優(yōu)勢(shì) | 滴普科技FastData系列解讀

在上期的兩篇連載文章中，我們分析了Lambda 和 Kappa 架構(gòu)固有的一些問題，同時(shí)也引出了流批一體架構(gòu)的優(yōu)勢(shì)，本文就 FastData流批一體大數(shù)據(jù)平臺(tái)DLink ，如何基于 Flink + Iceberg 流批一體技術(shù)及其實(shí)踐進(jìn)行初步探討。

傳統(tǒng)的基于離線（比如 Hive）數(shù)倉有很高的成熟度和穩(wěn)定性，但在一些時(shí)延要求比較高的場(chǎng)景，則需要借助實(shí)時(shí)數(shù)倉 Flink 的幫助，將延時(shí)降低到秒級(jí)（或分鐘級(jí)），但兩套并存的數(shù)倉架構(gòu)，勢(shì)必帶來雙倍的資源消耗和開發(fā)維護(hù)工作量。那么，是否存在可以將離線和實(shí)時(shí)任務(wù)、批處理和流式任務(wù)，統(tǒng)一放在一套架構(gòu)中調(diào)度和運(yùn)行的架構(gòu)呢？答案自然是肯定的。這就是 Dlink 的統(tǒng)一技術(shù)棧。

（1）統(tǒng)一技術(shù)棧

DLink整體技術(shù)方案的核心理念就是“統(tǒng)一”。從底層Data Stack 的角度看，包括5 個(gè)部分：

1. 數(shù)據(jù)存儲(chǔ)：首先是數(shù)據(jù)存儲(chǔ)格式的統(tǒng)一。利用 Iceberg 基于快照的讀寫分離和回溯（backfill）、流批統(tǒng)一的寫入和讀取、不強(qiáng)綁定計(jì)算存儲(chǔ)引擎、ACID 語義及數(shù)據(jù)多版本、表schema和 partition evolution 等能力。
2. Catalog Manager：統(tǒng)一Data Catalog，兼容 Hive Meta Store 接口，可實(shí)現(xiàn) Flink、Trino、Hive 等常用大數(shù)據(jù)分析、計(jì)算引擎的無縫接入和良好的互操作性。
3. 計(jì)算引擎：Unified DataStream，F(xiàn)link 引擎在 DataStream 和 Table API 中均支持 batch 和 streaming 兩種執(zhí)行模式。
4. 調(diào)度引擎：流批一體調(diào)度器，同時(shí)支持流批調(diào)度模式。在調(diào)度器內(nèi)部通過 DAG 的合并和拆解、資源的細(xì)粒度配置等規(guī)則，對(duì)物理執(zhí)行計(jì)劃進(jìn)行自適應(yīng)調(diào)優(yōu)。
5. SQL引擎：統(tǒng)一了流式計(jì)算 SQL 與分析、點(diǎn)查等 Serving 類SQL 語義（兼容 ANSI SQL 標(biāo)準(zhǔn)）。所有的 SQL 類操作使用統(tǒng)一的 SQL 引擎。

關(guān)于 DLink的技術(shù)特點(diǎn)，在第四節(jié)會(huì)重點(diǎn)介紹一下。

實(shí)時(shí)數(shù)倉建設(shè)最重要的環(huán)節(jié)就是 ETL 任務(wù)，接下來我們結(jié)合實(shí)際場(chǎng)景和需求，看一下 Dlink 實(shí)時(shí)數(shù)倉是如何解決傳統(tǒng) Lambda架構(gòu)在 ETL 場(chǎng)景中遇到的各種問題。

（2）實(shí)時(shí)數(shù)倉 ETL 場(chǎng)景

下圖是DLink 流批一體數(shù)據(jù)平臺(tái)在實(shí)時(shí)數(shù)倉場(chǎng)景（典型的 ETL 場(chǎng)景）的一個(gè)數(shù)據(jù)流圖：

2.1 客戶需求

客戶之前完全使用 Oracle 搭建他們的數(shù)倉系統(tǒng)，在數(shù)據(jù)量達(dá)到一定規(guī)模之后，ETL 和數(shù)據(jù)分析的效率越來越低，亟需進(jìn)行架構(gòu)升級(jí)。對(duì)此，客戶提出以下需求：一，實(shí)時(shí)抽取和寫入：實(shí)時(shí)將 Oracle 的增量數(shù)據(jù)抽取并寫入 Iceberg 中，業(yè)務(wù)數(shù)據(jù)的并發(fā)量在3000 行 / 秒，端到端時(shí)延要求在1至5分鐘內(nèi)；二，OLAP 統(tǒng)計(jì)分析：支持 DM 層數(shù)據(jù)的查詢分析。

總之，對(duì)數(shù)據(jù)處理的實(shí)時(shí)性和數(shù)據(jù)的分析提出了要求。

2.2 實(shí)時(shí)數(shù)倉數(shù)據(jù)流程

結(jié)合客戶的具體需求和 Dlink 的產(chǎn)品特性，我們?cè)O(shè)計(jì)了圖二的流批一體實(shí)時(shí)數(shù)倉架構(gòu)，從數(shù)據(jù)生命周期的角度，數(shù)據(jù)流程可以分為以下三個(gè)部分：

• 數(shù)據(jù)采集消費(fèi)（Extract & Transform）

FastData DCT組件（類似 Debezium）負(fù)責(zé) Oracle binlog 的抓取并轉(zhuǎn)換成 dct-json 格式存儲(chǔ)在 Kafka，實(shí)現(xiàn)增量數(shù)據(jù)入到 Iceberg 實(shí)時(shí)數(shù)倉。

• 數(shù)據(jù)統(tǒng)一存儲(chǔ)（Unified Storage）

統(tǒng)一采用 iceberg 表格式存儲(chǔ)全量數(shù)據(jù)，包括數(shù)倉的 ODS、DWD、DWS 和 DM 層數(shù)據(jù),并實(shí)現(xiàn)各層之間增量數(shù)據(jù)的流轉(zhuǎn)和處理。

• 數(shù)據(jù)實(shí)時(shí)處理（Transform & Load）

Flink 實(shí)際上在實(shí)時(shí)數(shù)倉 ETL 的以下階段發(fā)揮了作用：

1. 實(shí)時(shí)數(shù)據(jù)入湖：使用 Flink Kafka Source Connector 從 Kafka 拉取數(shù)據(jù)，并使用 Iceberg sink connector 將數(shù)據(jù)寫入到 ODS 層；
2. 增量數(shù)據(jù)讀?。?當(dāng) ODS 層有新增數(shù)據(jù)時(shí)，觸發(fā) iceberg source connector 的增量讀取事件，經(jīng)過 Flink 計(jì)算將增量數(shù)據(jù)通過 Iceberg sink connector寫入下面的 DWD 層，實(shí)現(xiàn)歷史數(shù)據(jù)的更新；
3. 更新下游數(shù)據(jù)：針對(duì)上游 ODS 明細(xì)數(shù)據(jù)的偶爾變更，觸發(fā)DLink計(jì)算任務(wù)對(duì)小批量數(shù)據(jù)進(jìn)行準(zhǔn)實(shí)時(shí)的重新計(jì)算，更新下游統(tǒng)計(jì)數(shù)據(jù)，并將變更繼續(xù)向下游傳播。

接下來，我們從數(shù)據(jù)的采集、轉(zhuǎn)換、存儲(chǔ)和分析的角度繼續(xù)來看：FastData DLink 流批一體大數(shù)據(jù)平臺(tái)集成了從數(shù)據(jù)采集到最終的數(shù)據(jù)計(jì)算、分析能力。結(jié)合圖二來看，具體涉及的流程如下：

·數(shù)據(jù)采集

采集流程中使用了FastData DCT 以及 Kafka 組件，實(shí)現(xiàn)了Oracle增量數(shù)據(jù)的實(shí)時(shí)采集。

· 數(shù)據(jù)轉(zhuǎn)換

轉(zhuǎn)換環(huán)節(jié)主要涉及數(shù)倉離線鏈路的處理。類似往期文章中提到的 Lambda 架構(gòu)，我們實(shí)際上可以通過 Flink 批處理讀取某個(gè) Iceberg 表的快照做全局分析，得到的結(jié)果可供不同場(chǎng)景（如Ad Hoc查詢、數(shù)據(jù)科學(xué)、機(jī)器學(xué)習(xí)）下的用戶讀取和分析。

· 數(shù)據(jù)存儲(chǔ)

Iceberg 作為通用的表格式存儲(chǔ)，很好地分離了計(jì)算引擎（Flink、Spark、Hive、Presto等） 和底下的存儲(chǔ)層，這樣就可以很好地兼容多種計(jì)算引擎和文件格式（Parquet、ORC、Avro 等），正在成為數(shù)據(jù)湖上Table Format 層的事實(shí)標(biāo)準(zhǔn)。

Iceberg manifest和snapshot的設(shè)計(jì)，有效地隔離了不同transaction的變更，非常方便批處理和增量計(jì)算。

同時(shí)，Apache Iceberg 的社區(qū)資源也非常豐富，Netflix、Apple、LinkedIn、Adobe等公司都有PB級(jí)別的生產(chǎn)數(shù)據(jù),運(yùn)行在Apache Iceberg之上。

· 數(shù)據(jù)分析

由于底層 Iceberg 存儲(chǔ)格式的打通，Trino 可實(shí)時(shí)讀取 Flink 寫入的 Iceberg 快照，從而實(shí)現(xiàn)了端到端近實(shí)時(shí)（1 分鐘之內(nèi)）的分析。

那么，為了支撐以上產(chǎn)品特性，DLink 平臺(tái)中又引入了哪些創(chuàng)新的技術(shù)呢？

在構(gòu)建 DLink 流批一體大數(shù)據(jù)平臺(tái)的過程中，基于 Iceberg、Flink 和 Trino 技術(shù)棧，結(jié)合客戶的實(shí)際場(chǎng)景和需求，我們?cè)谠獢?shù)據(jù)管理、數(shù)據(jù)存儲(chǔ)格式和數(shù)據(jù)分析性能上做了一些工作，總結(jié)如下：

（1）統(tǒng)一元數(shù)據(jù)存儲(chǔ)（Catalog Manager）

基于 DLink 統(tǒng)一的 Catalog Manager (簡(jiǎn)稱 CM)和 統(tǒng)一元數(shù)據(jù)模型，實(shí)現(xiàn)了 Flink 和 Trino 引擎在catalog、database、表、視圖（包括物化視圖）和數(shù)據(jù)類型的統(tǒng)一和 良好的互操作性，徹底解決大數(shù)據(jù)引擎元數(shù)據(jù)格式不同造成的各種問題，用戶無需代碼開發(fā)，真正實(shí)現(xiàn) Define Once，Query Anywhere！

同時(shí)，DLink CM可對(duì)外提供標(biāo)準(zhǔn)的 Hive Meta Store 接口。通過 HMS 接口，我們也計(jì)劃將 DLink 的內(nèi)部托管數(shù)據(jù)源暴露給外部第三方數(shù)據(jù)引擎（Hive、Spark 等），實(shí)現(xiàn) DLink與大數(shù)據(jù)生態(tài)的打通。

對(duì)于數(shù)據(jù)源和 Catalog 的管理，有三種情況：

1. 結(jié)構(gòu)化元數(shù)據(jù)：可對(duì)接開源 Hive Meta Store；
2. 半結(jié)構(gòu)化元數(shù)據(jù)：對(duì)于以 CSV、JSON等格式存儲(chǔ)在對(duì)象存儲(chǔ)和分布式文件系統(tǒng)上的元數(shù)據(jù)信息，可通過 Crawler 任務(wù)自動(dòng)探索和解析，從而自動(dòng)生成元數(shù)據(jù)信息；
3. JDBC：支持MySQL、PostgreSQL、Oracle 等數(shù)據(jù)源的接入。

（2）統(tǒng)一數(shù)據(jù)存儲(chǔ)（Iceberg）

Apache Iceberg 作為一個(gè)開放的數(shù)據(jù)湖表格存儲(chǔ)，接口定義清晰，支持Flink、Spark等各種大數(shù)據(jù)引擎，兼容性比較好。雖然有不少優(yōu)點(diǎn)，社區(qū)也比較活躍，但目前還存在點(diǎn)查、更新性能差的問題，DLink 目前聯(lián)合Iceberg社區(qū)在索引和維表等技術(shù)之上做了增強(qiáng)和優(yōu)化：

• Clustering 技術(shù)

通過z-order實(shí)現(xiàn)多維數(shù)據(jù)重新聚合排序，提升多維聚合性能，大幅提升查詢性能。

• 二級(jí)索引

增加了 Bloom Filter 索引，文件級(jí)別的過濾性能大大提升，從而加速點(diǎn)查性能。

• MOR（Merge On Read）優(yōu)化

通過后臺(tái)自動(dòng)調(diào)度的 Job，合并delete file 和 data file。避免在讀取時(shí)，查詢完data file后，還需要臨時(shí)合并 delete file 的結(jié)果，從而提升了讀性能。

• 小文件合并

類似 MOR Job 的后臺(tái)任務(wù)。基于 Iceberg 的快照隔離和讀寫分離的優(yōu)秀特性，我們開發(fā)了小文件自動(dòng)合并功能。后臺(tái) Job 自動(dòng)合并小文件，持續(xù)優(yōu)化讀取性能?；诙喟姹镜目煺崭綦x能力，文件合并操作不阻塞用戶正常讀寫。

• Lookup Table

維度表在流式計(jì)算的應(yīng)用很廣，通過 SQL 的 join 操作實(shí)現(xiàn)數(shù)據(jù)的補(bǔ)全。比如, source stream 是MySQL Binlog 日志中的訂單信息，但日志中僅記錄了商品的 ID，這樣當(dāng)訂單信息入倉，我們進(jìn)行日志流 Join 的時(shí)候，就可以通過查詢維表的方式，補(bǔ)全商品名稱的信息。

DLink Lookup Table 將熱數(shù)據(jù)高效緩存在本地，冷數(shù)據(jù)存儲(chǔ)在 Iceberg，同時(shí)基于數(shù)據(jù)局部性原理和統(tǒng)計(jì)分析，我們加入了自研的緩存替換算法，緩存命中率較高。同時(shí)，查詢維表時(shí)，通過 Projection 與 Filter push down 極大降低緩存的數(shù)據(jù)量，進(jìn)一步提高了緩存的命中率。我們初步測(cè)試 Streaming Join 維表性能較 Flink 原生 Lookup Table 性能提升2倍以上。

（3）統(tǒng)一 SQL引擎

在統(tǒng)一元數(shù)據(jù)之后，為了進(jìn)一步提升易用性，我們?cè)?Trino 和 Flink 之上構(gòu)建了統(tǒng)一的 ANSI SQL 層，提供了一致的使用體驗(yàn)。數(shù)據(jù)入湖，DML、DDL等 SQL 操作均由一套 SQL 實(shí)現(xiàn)。在統(tǒng)一的 SQL 引擎及其優(yōu)化器之上，我們做了如下優(yōu)化：

Dynamic Filtering技術(shù)

Dynamic Filtering 技術(shù)早在 2005 年就在 Oracle中實(shí)現(xiàn)。借鑒數(shù)據(jù)庫的思路，我們基于 Trino 引擎在Iceberg connector 上實(shí)現(xiàn)了 Dynamic Filtering 技術(shù)，大大減少了 tableScan 算子掃描的數(shù)據(jù)量。

在FastData DLink統(tǒng)一元數(shù)據(jù)與存儲(chǔ)的架構(gòu)之上，F(xiàn)astData DLink將繼續(xù)優(yōu)化流式計(jì)算和數(shù)據(jù)入湖的性能，優(yōu)化端到端時(shí)延，秉承簡(jiǎn)單、高效、易用的理念，構(gòu)建流批一體、湖倉一體的實(shí)時(shí)大數(shù)據(jù)平臺(tái)。

2022 年，DLink 將在 Flink、Iceberg、Trino 等開源組件上的優(yōu)化和新特性逐步回饋開源社區(qū)，與國內(nèi)外同行共建良好的大數(shù)據(jù)生態(tài)。

由于本文篇幅的限制，對(duì)于DLink大數(shù)據(jù)流批一體處理、流式計(jì)算、多維分析和湖倉一體等，大家關(guān)心的下一代大數(shù)據(jù)平臺(tái)核心技術(shù)，后續(xù)我們會(huì)持續(xù)和大家分享，敬請(qǐng)期待！