導讀：今天的分享主要介紹阿里云云原生數據湖Iceberg產品實現方案和對數據湖技術的一些思考。今天的分享圍繞下幾點展開：

數據湖背景介紹

上云面臨的挑戰(zhàn)

Iceberg解決方案

總結

01、數據湖背景介紹

數據湖和數據庫、數據倉庫的區(qū)別在哪里？這些系統(tǒng)的特點分別是什么？

常用的數據庫如MySQL、HBase、Redis和Neo4j圖數據庫。數據庫的特點是QPS吞吐高，單機QPS幾千到上萬。請求延遲低，一般是毫秒級延遲，單次請求數據集比較小。OLTP數據庫在大數據集的掃描和聚合性能表現不如OLAP數據庫。數據庫對宕機的容忍度低，一般如果MySQL或Redis服務出現異常，業(yè)務方會第一時間找到基礎服務測催促恢復服務，需要在分鐘級時間段內恢復服務。

數據庫使用B-Tree、LSMTree等索引，目的是優(yōu)化請求延遲，其存儲成本較高。數據類型方面的話，交易數據、在線的數據偏多。數據庫的計算模型相對簡單、固定，MySQL是SQL模型，Redis、HBase等KV數據庫支持點查，圖數據庫使用圖的方式查詢數據庫。

數據倉庫領域內成熟的產品如Hive、ClickHouse、Snowflake。Hive常用于離線數倉，ClickHouse常用于秒級和分鐘級別的純實時數據的存儲，Snowflake是云上數據倉庫。數據倉庫單次查詢的數據集大，單次請求響應延遲一般在秒級、分鐘級甚至小時級。數據倉庫對可用性的容忍程度稍高一些，例如當數倉服務發(fā)生故障時，可在數倉服務恢復后，重啟數倉的離線作業(yè)繼續(xù)執(zhí)行計算任務。數倉存儲的數據量大，存儲成本高，ClickHouse會建立更復雜的索引進行查詢加速、優(yōu)化；存儲的數據類型也會是經過數倉加工后的數據類型。數倉的計算場景比較固定，以SQL查詢?yōu)橹鳎瑢τ趫D、機器學習等計算，還需要把數倉中存儲的數據導出到對應的數據庫中進行進一步分析。

數據湖常見的是Delta Lake、Iceberg、Hudi。數據湖的一些場景和特性與數據倉庫類似，但數據湖直接構建在列存文件之上，省去了為數據建立復雜索引的操作，存儲成本更低。數據湖存儲的數據一般是原始數據集。數據湖的計算模式比數據倉庫更豐富，它規(guī)定了入湖的數據格式，對上層計算模型沒有綁定，SQL、圖、機器學習訓練都可以支持。數據湖定義了數據格式，上層可以選擇任意的模式進行數據計算。

常見的數據湖架構如下圖所示，上層可以是Spark、Flink、Hive，甚至是機器學習計算引擎，第二層是數據湖對Table Format的定義，其下層是存儲系統(tǒng)。存儲系統(tǒng)分為兩部分，一部分是數據文件實際存儲的位置，可以是對象存儲、HDFS等；另一部分是數據緩存，作用是加速數據訪問。在存儲計算分離的場景下每一次數據訪問都需要通過網絡做數據查詢，太多數據網絡數據查詢會影響整體系統(tǒng)性能。如果對最近訪問的熱點數據做本地緩存，則可以大大加速查詢性能。

02、上云面臨的挑戰(zhàn)

1. 為何上云？

有一些用戶使用了Hadoop和HDFS，在傳統(tǒng)的環(huán)境下已經可以做到很流暢地擴容，那么云可以為這類用戶帶來什么？

云提供了彈性。在非云環(huán)境中部署的HDFS，遇到容量不夠的問題時擴容操作復雜、時間長，對突發(fā)的流量高峰響應不及時、擴容后流量高峰已過資源被浪費。云上的對象存儲可以認為存儲容量是無限大的，但HDFS需要用戶時刻關心HDFS存儲容量是否已經用完、是否需要進行存儲擴容操作。

OSS和S3的存儲成本比HDFS低很多，這是由于云廠商的存儲做了EC優(yōu)化、云存儲有硬件加速和協(xié)議棧優(yōu)化等。云廠商的規(guī)模效應讓所有客戶都可以享受到云平臺對存儲組件優(yōu)化帶來的紅利，云廠商對用戶需求也能夠做到專業(yè)且及時的響應。

使用云服務，不再需要自己維護基礎組建，使用云廠商提供的服務減少了用戶自己維護基礎存儲組件的麻煩，能夠更專注地做業(yè)務。

2. 以Hive為例，數倉上云

Netflix的所有基礎設施都是基于AWS的云服務，做過Hive上云的嘗試。在Hive上云的過程中發(fā)現了一些問題：

數據變更和回溯困難：由于Hive系統(tǒng)設計問題，很難做到ACID語義的保證，當數據有變更時很難做到讀寫影響相互隔離，如數據改動會影響分析任務。Hive也無法解決多個數據改動者同時寫入造成的數據沖突。Hive無法有效回溯歷史版本。

存儲替換HDFS為S3困難：Hive數據訪問接口直接依賴HDFS API。S3在文件操作的語義上支持并不完善，Hive使用rename完成原子性寫文件的操作，這在S3等對象存儲上無法實現相同的語義。Hive大量依賴文件目錄list接口，而對象存儲的文件list操作效率低。

太多細節(jié)問題：Schema變更時，不同文件格式行為不一致。不同 FileFormat 甚至連數據類型的支持都不一致，如Timestamp在不同數據格式上的精度不同，需要在開發(fā)過程中時刻關心數據精度，對業(yè)務開發(fā)造成了很大負擔。Hive Metastore僅維護partition級別的統(tǒng)計信息，在擴容metastore時甚至需要搭建分布式MySQL集群，維護困難、難以擴展。非partition字段不能做partition prune，對開發(fā)人員不友好。

3. 數據湖上云的挑戰(zhàn)

統(tǒng)一的元數據中心：數據湖需要對數據做標準化的定義，數據源數量多的情況下如何管理來自異構存儲的數據源是一個大問題。另一個問題是如何讓數據湖與其他上層系統(tǒng)無縫對接，能讓閉源和開源的計算服務訪問到數據。在數據源多的情況下元數據信息多，如何保障元數據中心服務的可擴展性也是需要面對的問題。

多源實時數據入湖方案：數據入湖直接把Kafka的數據導入就好了，考慮多源實時入湖有意義嗎？為不同的客戶接入數據時數據入湖有很多需要考慮的細節(jié)。數據入湖需要隔離寫入對分析的影響，例如需要考慮增加字段后，數據流如何不斷開、分析作業(yè)能不崩潰。如何保證穩(wěn)定可靠的端到端數據變更。數據實時入湖對系統(tǒng)的壓力，如元數據激增、數據文件數量增長，如何保障數據分析性能。數據實時入湖和分析CDC數據如何做。

企業(yè)級的數據安全保證：私有化的大數據系統(tǒng)對數據加密和權限隔離天然地具有數據隔離的特點，但作為云上的數據湖服務提供商，就必須要提供嚴格的數據正確性、端到端數據加密、租戶之間的權限隔離。例如用戶向Iceberg內寫數據，其他用戶是否可以通過S3拿到數據？數據的安全性在公有云服務上是必須要保障的。

03、Iceberg解決方案

接下來我們詳細介紹阿里云的Iceberg云原生數據湖解決方案。

1. Apache Iceberg核心特性

Iceberg是向通用化的方向設計，既不會特別面向某個存儲設計、也不會特別面向哪個計算引擎設計，有利于設立Table Format的標準。

2. Apache Iceberg存儲結構

Iceberg的data和metadata都是存儲在文件系統(tǒng)中的。

3. Apache Iceberg Snapshot視圖

從存儲視角上看Iceberg分為三層。最底層是具體的文件，中間是每次transaction提交時生成的manifest對象，最上層是快照。快照指的是每個時間點看到的整個表全局數據。下面幾張圖有助于快速理解數據存儲和快照：

第一次Transaction時候寫了陰影部分的文件，讀取也是讀取陰影部分的數據。

第二次Transaction寫入數據后，讀到的數據是新的陰影部分數據。

第三次Transaction時候讀取的是下圖的陰影數據。

第四次Transaction時讀取的是下圖的陰影數據。

Iceberg寫入的流程在Table Format的設計上考慮了流和批的兩種場景。Iceberg把流和批的場景進行了融合，可以高效地做批量讀取、流式增量讀取、歷史版本回溯，能做到較好的近實時處理。

4. 選擇Apache Iceberg的公司數量眾多

Netflix、阿里云、網易等公司都在不同場合分享過Iceberg的使用。

5. 阿里云如何解決Iceberg數據庫上云的挑戰(zhàn)？

在阿里云的Iceberg數據湖產品中，Iceberg作為Table Fomat位于一個中間核心位置，數據通過Flink寫入阿里云OSS。數據湖的訪問分為兩部分，一部分是“入湖”，是不同數據源寫入數據到數據湖中；另一部分是“出湖”，使用流分析、批分析甚至機器學習的方式分析數據，此時需要根據業(yè)務場景選擇計算框架，如Hive、Presto、Spark等。

(1) 統(tǒng)一的元數據中心——DLF

元數據分為兩部分，包括Database、Table和Table到location的映射關系；另一部分包含了Table內的數據的信息，包括Table的Schema、partition、partition內文件分布和文件內的Schema信息。對于云原生數據湖架構，Table以上的元數據由DLF Catalog管理，該服務對的外名稱為阿里云數據湖構建(Data Lake Formation，DLF)產品。Iceberg對Table一下的信息做了很好的抽象，管理元數據方便，因此Table以下的元數據由Iceberg進行管理。

DLF做了統(tǒng)一的元數據管理，只要入湖，都可以在DLF中找到數據的表名、歸屬的Database和Catalog。有統(tǒng)一的元數據視圖后，數據不會特別混亂。元數據還可以用來追蹤數據的血緣關系，一份數據從A轉換到B后各數據之間的依賴關系可以通過元數據管理工具做到數據血緣關系的追蹤。

數據湖會和上游的計算框架、模型做對接，對接的入口就是DLF。例如Spark訪問某一個表，表的Location對應著文件系統(tǒng)上的位置，通過DLF可以拿到該位置。

關于權限和認證問題，由于數據湖是一個統(tǒng)一數據中心，公司內部、不同組織的業(yè)務方做數據訪問必須做數據隔離，否則機密數據可以被所有人訪問會導致很多問題。DFL作為數據的入口，也負責管理數據訪問權限。

(2) 多源實時數據入湖方案

隔離寫一半的數據對分析作業(yè)的影響

寫入作業(yè)如何隔離和分析作業(yè)的影響？阿里云主推Flink配合Iceberg，隔離同時讀和寫的影響。Flink可以很好地實現Exactly Once語義，在故障情況下也可以保障數據一致性的語義。Flink數據管道范圍內可以保障數據不多一條、不少一條。Iceberg可以通過存儲的ACID特性隔離寫入對數據分析作業(yè)的影響。當不斷有數據寫入數據湖時，由于Iceberg的ACID特性，分析作業(yè)讀取數據湖的表時一直在讀Transaction內的數據，其他的寫入任務不會影響讀取的數據。最終數據的計算結果是一致性的結果。

保證穩(wěn)定可靠的端到端數據變更

入湖容易遇到數據源、數據管道、數據湖之間的數據變更，最典型的場景是增加字段。如果要實現字段新增，舊的數據變更方案中，首先要在數據源中改掉字段；然后修改Flink任務，使Flink可以識別該字段；最后在數據湖中把數據湖中所有的數據都加上該字段。這個流程冗長，成本和開銷比較大，我們嘗試利用Flink配合Iceberg進行優(yōu)化。

目前我們在推進的新方案是：Flink可以直接捕捉到上游DDL變更事件、轉發(fā)變更事件到下游，下游收到事件后直接應用到數據湖。Iceberg支持Schema變更的能力，利用該功能可以瞬間完成Schema同步。用戶不再需要感知到端到端數據變更，數據入湖的鏈路已經自動化地處理了Schema變更的問題。解放了管理數據湖入湖流程的人力。

實時數據入湖的副作用與應對方法

當遇到數據從小時級別延遲縮短到分鐘級的改造需求時候，需要對數據入湖鏈路做實時化改造。實時化改造會遇到多種問題：數據要盡可能快地提交到數倉/數據湖，如果利用Hive做數據存儲，Hive的元數據會快速增長，小文件數量很多、查詢效率會變慢、元數據存儲介質也需要進行響應改造和升級。

在阿里云的云原生數據湖方案中，Iceberg很好地解決了元數據中心化的問題。Iceberg的Table Format把Table內的元信息托管到文件系統(tǒng)中，因此元數據的擴展性與文件系統(tǒng)的擴展性近似。統(tǒng)計信息存儲到對象存儲中，非常方便地實現了可擴展性。

隨著小文件增多，查詢效率變低，有三種實現解決該問題：第一種方式是在Flink寫入數據時按照數據湖設定的Bucket來Shuffle方式進行寫入，一個Bucket的數據只有一個并發(fā)寫入，寫入時已經減小了小文件生成的概率。第二種方式是使用批處理任務，定期批量檢查、合并小文件。第三種方式是自動增量合并小文件。Flink流式增量合并適合處理小量的增量合并，大規(guī)模合并會影響流作業(yè)的穩(wěn)定性、對資源的開銷比較大。流式入湖合并適合做小范圍的文件合并，可以以較低的成本實現較好的性能，全表級別的小文件合并需要交給批作業(yè)，減小資源消耗。

實時入湖并處理CDC數據

當前市面上能夠處理更改數據捕獲（Change Data Capture，CDC）的存儲不多、而且各有缺陷。

Flink是一個實時性很好的Exactly once的流式計算引擎，適合作為MySQL CDC與數據湖之間的管道。Iceberg能很好地在云上存儲和分析CDC數據，利用開源的解決方案就可以做到CDC鏈路串通。

首先定義MySQL源表，再在Iceberg里定義Sink表，中間使用Flink作業(yè)即可利用Insert into語句從Mysql源表導入數據到Iceberg。生產環(huán)境中使用該方案依然可能遇到小文件多的問題，需要進行批量compaction；但批量compaction操作可能和流式入湖的任務有沖突，對語義有一定影響。在Iceberg社區(qū)對這個問題已經進行了很好的討論，后續(xù)阿里云會把與此相關的優(yōu)化工作推到社區(qū)。

(3) 企業(yè)級的數據安全保證

經過上述的MySQL源、Flink數據管道，數據進入數據湖，數據湖內的數據再提供給各個計算引擎，每個系統(tǒng)之間的串聯比較復雜。如果發(fā)現數據有問題，最常出問題的點是數據入湖這一過程。數據一旦入湖，基本不會再對數據有進一步操作，因此核心要保障數據入湖的服務穩(wěn)定、準確。

為了保障服務穩(wěn)定性、數據正確性，我們專門為數據入湖出湖的整套流程設計了一套測試框架，對數據做了自動化的、嚴謹的端到端驗證。我們會人為地產生一些數據，使用Flink入湖，再通過多計算引擎（Flink / Spark / Hive / Presto）對比驗證數據的一致性；使用Flink入湖，多種批處理引擎驗證源數據和計算引擎框架計算結果。測試框架已經應用到研發(fā)過程中，主要檢查數據從源端到入湖的正確性，保障項目迭代過程中軟件的準確性。

我們?yōu)榱吮Ｕ袭惓Ｇ闆r下的數據準確性，測試框架也會模擬一些異常情況，注入異常并檢查數據正確性。我們注入的異常包括：JobManager重啟或掛掉，一個TaskManager重啟或掛掉，多個TaskManager重啟或掛掉，無法正常訪問HDFS / OSS服務，無法正常訪問DLF / Hive-metastore服務，機器負載高、某個CPU利用率長期100%、某塊磁盤訪問慢、網絡不可訪問或丟包嚴重等錯誤注入等。

04、總結

阿里云Iceberg云原生數據湖方案核心優(yōu)勢有以下四點：

1. 數據格式開放

完全兼容Iceberg Table Format格式。Parquet、ORC、Avro格式也可以很平滑地遷移到Iceberg。如果歷史數據存儲在OSS、HDFS，不需要做數據文件級別拷貝，只需要利用一個Spark或Flink作業(yè)，為存量數據parquet文件重新生成一份Iceberg元數據即可完成入湖。對parquet格式的存量數據用戶也非常友好。

2.計算多樣性

數據湖核心優(yōu)勢之一是能支持不同計算場景、滿足用戶的需求。計算多樣性對業(yè)務場景的迭代和研發(fā)很靈活。

3. 資源彈性化

相對于自己部署的軟件，云原生的彈性擴縮容特性實現了用戶按需付費。

4. 服務專業(yè)性

阿里云每個細分產品都有幾十到上百人的團隊進行支持，用戶可以享受到專業(yè)性很強的服務。