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

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

（1）統一技術棧

DLink整體技術方案的核心理念就是“統一”。從底層Data Stack 的角度看，包括5 個部分：

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

關于 DLink的技術特點，在第四節會重點介紹一下。

實時數倉建設最重要的環節就是 ETL 任務，接下來我們結合實際場景和需求，看一下 Dlink 實時數倉是如何解決傳統 Lambda架構在 ETL 場景中遇到的各種問題。

（2）實時數倉 ETL 場景

下圖是DLink 流批一體數據平臺在實時數倉場景（典型的 ETL 場景）的一個數據流圖：

2.1 客戶需求

客戶之前完全使用 Oracle 搭建他們的數倉系統，在數據量達到一定規模之后，ETL 和數據分析的效率越來越低，亟需進行架構升級。對此，客戶提出以下需求：一，實時抽取和寫入：實時將 Oracle 的增量數據抽取并寫入 Iceberg 中，業務數據的并發量在3000 行 / 秒，端到端時延要求在1至5分鐘內；二，OLAP 統計分析：支持 DM 層數據的查詢分析。

總之，對數據處理的實時性和數據的分析提出了要求。

2.2 實時數倉數據流程

結合客戶的具體需求和 Dlink 的產品特性，我們設計了圖二的流批一體實時數倉架構，從數據生命周期的角度，數據流程可以分為以下三個部分：

• 數據采集消費（Extract & Transform）

FastData DCT組件（類似 Debezium）負責 Oracle binlog 的抓取并轉換成 dct-json 格式存儲在 Kafka，實現增量數據入到 Iceberg 實時數倉。

• 數據統一存儲（Unified Storage）

統一采用 iceberg 表格式存儲全量數據，包括數倉的 ODS、DWD、DWS 和 DM 層數據,并實現各層之間增量數據的流轉和處理。

• 數據實時處理（Transform & Load）

Flink 實際上在實時數倉 ETL 的以下階段發揮了作用：

1. 實時數據入湖：使用 Flink Kafka Source Connector 從 Kafka 拉取數據，并使用 Iceberg sink connector 將數據寫入到 ODS 層；
2. 增量數據讀取： 當 ODS 層有新增數據時，觸發 iceberg source connector 的增量讀取事件，經過 Flink 計算將增量數據通過 Iceberg sink connector寫入下面的 DWD 層，實現歷史數據的更新；
3. 更新下游數據：針對上游 ODS 明細數據的偶爾變更，觸發DLink計算任務對小批量數據進行準實時的重新計算，更新下游統計數據，并將變更繼續向下游傳播。

接下來，我們從數據的采集、轉換、存儲和分析的角度繼續來看：FastData DLink 流批一體大數據平臺集成了從數據采集到最終的數據計算、分析能力。結合圖二來看，具體涉及的流程如下：

·數據采集

采集流程中使用了FastData DCT 以及 Kafka 組件，實現了Oracle增量數據的實時采集。

· 數據轉換

轉換環節主要涉及數倉離線鏈路的處理。類似往期文章中提到的 Lambda 架構，我們實際上可以通過 Flink 批處理讀取某個 Iceberg 表的快照做全局分析，得到的結果可供不同場景（如Ad Hoc查詢、數據科學、機器學習）下的用戶讀取和分析。

· 數據存儲

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

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

同時，Apache Iceberg 的社區資源也非常豐富，Netflix、Apple、LinkedIn、Adobe等公司都有PB級別的生產數據,運行在Apache Iceberg之上。

· 數據分析

由于底層 Iceberg 存儲格式的打通，Trino 可實時讀取 Flink 寫入的 Iceberg 快照，從而實現了端到端近實時（1 分鐘之內）的分析。

那么，為了支撐以上產品特性，DLink 平臺中又引入了哪些創新的技術呢？

在構建 DLink 流批一體大數據平臺的過程中，基于 Iceberg、Flink 和 Trino 技術棧，結合客戶的實際場景和需求，我們在元數據管理、數據存儲格式和數據分析性能上做了一些工作，總結如下：

（1）統一元數據存儲（Catalog Manager）

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

同時，DLink CM可對外提供標準的 Hive Meta Store 接口。通過 HMS 接口，我們也計劃將 DLink 的內部托管數據源暴露給外部第三方數據引擎（Hive、Spark 等），實現 DLink與大數據生態的打通。

對于數據源和 Catalog 的管理，有三種情況：

1. 結構化元數據：可對接開源 Hive Meta Store；
2. 半結構化元數據：對于以 CSV、JSON等格式存儲在對象存儲和分布式文件系統上的元數據信息，可通過 Crawler 任務自動探索和解析，從而自動生成元數據信息；
3. JDBC：支持MySQL、PostgreSQL、Oracle 等數據源的接入。

（2）統一數據存儲（Iceberg）

Apache Iceberg 作為一個開放的數據湖表格存儲，接口定義清晰，支持Flink、Spark等各種大數據引擎，兼容性比較好。雖然有不少優點，社區也比較活躍，但目前還存在點查、更新性能差的問題，DLink 目前聯合Iceberg社區在索引和維表等技術之上做了增強和優化：

• Clustering 技術

通過z-order實現多維數據重新聚合排序，提升多維聚合性能，大幅提升查詢性能。

• 二級索引

增加了 Bloom Filter 索引，文件級別的過濾性能大大提升，從而加速點查性能。

• MOR（Merge On Read）優化

通過后臺自動調度的 Job，合并delete file 和 data file。避免在讀取時，查詢完data file后，還需要臨時合并 delete file 的結果，從而提升了讀性能。

• 小文件合并

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

• Lookup Table

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

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

（3）統一 SQL引擎

在統一元數據之后，為了進一步提升易用性，我們在 Trino 和 Flink 之上構建了統一的 ANSI SQL 層，提供了一致的使用體驗。數據入湖，DML、DDL等 SQL 操作均由一套 SQL 實現。在統一的 SQL 引擎及其優化器之上，我們做了如下優化：

Dynamic Filtering技術

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

在FastData DLink統一元數據與存儲的架構之上，FastData DLink將繼續優化流式計算和數據入湖的性能，優化端到端時延，秉承簡單、高效、易用的理念，構建流批一體、湖倉一體的實時大數據平臺。

2022 年，DLink 將在 Flink、Iceberg、Trino 等開源組件上的優化和新特性逐步回饋開源社區，與國內外同行共建良好的大數據生態。

由于本文篇幅的限制，對于DLink大數據流批一體處理、流式計算、多維分析和湖倉一體等，大家關心的下一代大數據平臺核心技術，后續我們會持續和大家分享，敬請期待！