?

雖然 Databricks 的工程師反復(fù)強(qiáng)調(diào)性能測(cè)試來(lái)自第三方 Databeans，并且他們沒有主動(dòng)要求 Databeans做這項(xiàng)測(cè)試，但如果全程看完 delta2.0 發(fā)布會(huì)，會(huì)發(fā)現(xiàn)在 delta2.0 即將開放的 key feature 中，特別列出了 Iceberg 到 Delta 的轉(zhuǎn)換功能，并且官方著重講到了 Adobe 從 Iceberg 遷移到 Delta2.0 的實(shí)踐，這就難免讓人浮想聯(lián)翩了。

過去兩年，我們團(tuán)隊(duì)在新型數(shù)據(jù)湖技術(shù)的研究、探索和實(shí)踐上投入了大量精力，雖然我們主要投入的方向是 Iceberg，但 delta2.0 的開源，以及 Databricks 自身對(duì) Iceberg 的重視，更加堅(jiān)定了我們對(duì)數(shù)據(jù)湖，湖倉(cāng)一體這個(gè)方向的信心，開源之爭(zhēng)，本質(zhì)上是標(biāo)準(zhǔn)之爭(zhēng)，競(jìng)爭(zhēng)會(huì)加速標(biāo)準(zhǔn)的確認(rèn)和落地，而所有大數(shù)據(jù)的從業(yè)者都將從中獲益。

由于我們的工作更多將 Iceberg 當(dāng)做一個(gè)底層依賴使用，在架構(gòu)上具備解耦的可能，我們完全可以擁抱 Delta，所以這里我想站在一個(gè)第三方立場(chǎng)上講講對(duì) Lakehouse 這個(gè)方向，以及幾個(gè)主流開源產(chǎn)品的理解和思考，順帶也會(huì)簡(jiǎn)單講講我們的工作，另外希望大家可以和我共同思考和探索下面這個(gè)問題：

企業(yè)究竟需要怎樣的數(shù)據(jù)湖？

1、Table format 三強(qiáng)之爭(zhēng)

Table format 最早由 Iceberg 提出，目前已經(jīng)成為行業(yè)共識(shí)的概念， table format 是什么？簡(jiǎn)單概括的話：

• Table format 定義了哪些文件構(gòu)成一張表，這樣任何引擎都可以根據(jù) table format 查詢和檢索數(shù)據(jù)；
• Table format 規(guī)范了數(shù)據(jù)和文件的分布方式，任何引擎寫入數(shù)據(jù)都要遵照這個(gè)標(biāo)準(zhǔn)，通過 format 定義的標(biāo)準(zhǔn)支持 ACID，模式演進(jìn)等高階功能。

目前國(guó)內(nèi)外同行將 delta、iceberg 和 hudi 作為數(shù)據(jù)湖 table format 的對(duì)標(biāo)方案，我們先來(lái)聊聊 delta，iceberg，hudi 這三個(gè)開源數(shù)據(jù)湖的背景。

1.1 Delta

delta 是 databricks 公司在 2017 年立項(xiàng)、2018 年公布、2019 年開源的數(shù)據(jù)湖產(chǎn)品，可以看到 delta 立項(xiàng)時(shí) databricks 已成立 4 年，經(jīng)歷過幾次融資，并且在有條不紊地布局商業(yè)版圖，彼時(shí) hadoop 發(fā)行版還不是公認(rèn)難做的生意，delta 的誕生更像是 databricks 根據(jù)自身 spark 創(chuàng)始團(tuán)隊(duì)的基因打造的核心競(jìng)爭(zhēng)力，這樣也不難理解，為什么 delta 1.0 幾乎不向其他引擎開放。

delta 的推出是為了解決傳統(tǒng)數(shù)據(jù)湖在事務(wù)處理，流計(jì)算，BI 分析上的不足，Databricks 用極強(qiáng)的講故事能力為 delta 打造了一個(gè) lakehouse 的概念，時(shí)至今日，lakehouse 和湖倉(cāng)一體的概念已經(jīng)深入人心，甚至老對(duì)手 snowflake 也采納了這個(gè)概念，并且在官網(wǎng)中給出了更貼合自家產(chǎn)品的定義。在 2021 Gartener 數(shù)據(jù)庫(kù)領(lǐng)導(dǎo)力象限中，Databricks 和 snowflake 一起晉升第一象限，lakehouse 也首次進(jìn)入 hype cycle for data management，定位躍升期，依據(jù) Gartner 的定義，lakehouse 技術(shù)距離完全成熟可能還有 3 - 5 年的時(shí)間。

按照 Databricks 的構(gòu)想，delta1.0 作為 lakehouse 解決方案，可以讓數(shù)據(jù)湖更多，更快地作用于實(shí)時(shí)和 AI 場(chǎng)景，databricks 提出 delta 架構(gòu)幫助用戶從 lambda 架構(gòu)中解放出來(lái)，核心思想是數(shù)據(jù)湖既可以跑批，也可以跑流，流計(jì)算和批計(jì)算的流程和代碼可以復(fù)用，這樣用戶沒有了維護(hù) lambda 架構(gòu)的負(fù)擔(dān)，當(dāng)然計(jì)算引擎必須是 spark。遺憾的是 spark streaming 和 struct streaming 在國(guó)內(nèi)用戶體量很小，絕大部分用戶對(duì) delta1.0 是望梅止渴，對(duì) spark 的深度綁定也一定程度上限制了 delta 社區(qū)的發(fā)展，給 iceberg 的崛起預(yù)埋了伏筆，截止 2022 Q1 社區(qū)活躍度的一個(gè)對(duì)比如下：

但另一方面，我們也絕不能忽略 Databricks 作為一家運(yùn)營(yíng)多年的商業(yè)公司，已有相當(dāng)體量的付費(fèi)用戶，再加上對(duì) spark 社區(qū)的主導(dǎo)權(quán)，成熟的營(yíng)銷和渠道能力，也許很容易重新建立開源上的優(yōu)勢(shì)。

Delta 是 Lakehouse 的解決方案，Databricks 也被當(dāng)做 lakehouse 的代表，但是 delta 這個(gè)項(xiàng)目自身的定義卻經(jīng)歷了一些變化，我關(guān)注到去年某個(gè)時(shí)間點(diǎn)之前， delta 定義為 open format，引擎中可以直接用 delta 替換 parquet。

Format 的定義與 iceberg 的 table format 的定義非常相似，但在目前官網(wǎng)中，以及各種相關(guān)的分享和博客中，再也見不到此類描述，目前 delta 被官方定義為 lakehouse storage framework，當(dāng)然，無(wú)論 format 還是 framework，湯還是那個(gè)湯，只是菜譜更加豐滿了。

1.2 Iceberg 

Iceberg 是由 Netflix 團(tuán)隊(duì)研發(fā)并開源的數(shù)據(jù)湖 table format，創(chuàng)始人 Ryan Blue 是 spark，parquet，avro 的 PMC，在數(shù)據(jù)分析領(lǐng)域有非常豐富的經(jīng)驗(yàn)和人脈，co-fonder 中還有一位來(lái)自 Cloudera 的資深工程師，從時(shí)間線上看，iceberg 2018年進(jìn)入 apache 孵化，2020 年畢業(yè)，考慮到項(xiàng)目本身的研發(fā)周期，很難評(píng)判它和 delta 的時(shí)間先后，再加上創(chuàng)始人本身是活躍的 spark 貢獻(xiàn)者，兩個(gè)項(xiàng)目從一開始就高度相似。

從功能上看，套用知乎上的一句話：不能說非常相似，只能說一模一樣。從發(fā)展上看，iceberg 更加符合一個(gè)開源項(xiàng)目的氣質(zhì)，早期這個(gè)項(xiàng)目更多是為了應(yīng)對(duì) Netflix 對(duì)大體量數(shù)據(jù)分析的需求，重點(diǎn)強(qiáng)調(diào)了以下的特性：

ACID 和 MVCC 的特性，讀數(shù)據(jù)時(shí)不會(huì)讀到寫入的不一致狀態(tài)

• Data skipping，通過在 table format 這一層 skip 文件，在一些場(chǎng)景下 query 性能有較大提升
• Plan 時(shí)不像 hive 需要過多地依賴 namenode，對(duì)超大集群來(lái)說 plan 的性能有巨大提升
• 設(shè)計(jì)時(shí)更多考慮了 S3 上搭建 table format，讓 iceberg 成為數(shù)據(jù)湖上云的一個(gè)很好選型
• Schema evolve 和 hidden partition，讓表的變更和維護(hù)變的更加輕松

創(chuàng)始人非常強(qiáng)調(diào) iceberg 之于 hive 的優(yōu)勢(shì)，并且切實(shí)戳中了開發(fā)者，尤其有上云需求的用戶痛點(diǎn)，很多圈內(nèi)人提出 iceberg 會(huì)成為下一代的 hive，iceberg 引擎平權(quán)的特性，進(jìn)一步促進(jìn)了外圍廠商的認(rèn)同，目前公開信息可以了解到 Cloudera 主推 iceberg；snowflake 上支持 iceberg 外表；starrocks 支持 iceberg 外表；Amazon Athena 可以使用 iceberg 表，與 delta 相比，iceberg 的出身更加純粹，被各家追捧也不奇怪，雖然 delta 2.0 也開始吸引 spark 之外的引擎開發(fā)者參與，但追趕目前 iceberg 的外圍生態(tài)還需要一定的時(shí)間。

我本人是在 2020 年接觸 iceberg，當(dāng)時(shí)在為 flink 尋找比 hive 更好的數(shù)據(jù)湖方案，以解決 upsert, 以及批流場(chǎng)景開發(fā)和運(yùn)維割裂的問題，當(dāng)時(shí) iceberg 和 hudi 都在孵化，delta 依然是 spark 的 delta，而 hudi 當(dāng)時(shí)也是一個(gè) spark lib，只有 iceberg 讓人眼前一亮，iceberg 也是最早支持 flink connector。

Iceberg 社區(qū)對(duì) roadmap 一直很克制，任何對(duì)底層表格式的修改都慎之又慎，保障了對(duì)任何引擎都足夠友好，操作的可擴(kuò)展性和 row-level api 則給開發(fā)者留足了想象空間，在引擎平權(quán)方面，iceberg 是獨(dú)樹一幟的，未來(lái)怎么樣值得我們持續(xù)觀察。

1.3 Hudi

Hudi 開源和孵化的時(shí)間線與 iceberg 比較相近，回溯開源之初，hudi 的全稱是 hadoop upsert and incremental，核心功能是在 hadoop 上支持 upsert 和 incremental process，發(fā)展至今，hudi 已經(jīng)不再局限于 hadoop 以及名字上的兩個(gè)功能，hudi 不強(qiáng)調(diào)自己的數(shù)據(jù) format，經(jīng)過幾次大的迭代，對(duì)自己的定義變地有些復(fù)雜，打開官網(wǎng)我們會(huì)看到這樣的描述：

Hudi is a rich platform to build streaming data lakes with incremental data pipelines on a self-managing database layer while being optimized for lake engines and regular batch processing.

可以看出 hudi 想干很多事，并且給自己建立了像數(shù)據(jù)庫(kù)一樣的目標(biāo)，這個(gè)目標(biāo)的達(dá)成有很長(zhǎng)的路要走。Hudi 在三個(gè)項(xiàng)目中最早提供 stream upsert 能力 ，如果不做二次開發(fā)，hudi 是開箱即用的數(shù)據(jù)湖 upsert 方案，并且 hudi 社區(qū)對(duì)開發(fā)者非常開放，和 iceberg 專注又謹(jǐn)慎的調(diào)性可謂兩個(gè)極端，但 hudi 大版本之間的變化很大，這個(gè)方面先壓下不表，有機(jī)會(huì)專門開個(gè)文章聊聊。

最早的時(shí)候 hudi 只有 spark 下的實(shí)現(xiàn)，為了支持 flink 在重構(gòu)方面社區(qū)下了很大的功夫（delta類似），這也是 2020 年沒有選擇 hudi 的最重要原因，在 hudi 的核心團(tuán)隊(duì)創(chuàng)業(yè)成立 Onehouse 之后，hudi 的定位明顯和其他兩家產(chǎn)生了較大的分化，databricks 作為一家商業(yè)公司，delta 是他吸引流量的重要手段，商業(yè)化上再通過上層的數(shù)據(jù)開發(fā)，治理和 AI platform 變現(xiàn)，同理從公開信息看， Ryan Blue 成立的 Tabular 也是在 iceberg 之上構(gòu)建 platform，和 table format 涇渭分明。而 hudi 自身已經(jīng)將自己拔到 platform 的高度，雖然功能上還距離很遠(yuǎn)，但可以預(yù)見長(zhǎng)期的 roadmap 會(huì)產(chǎn)生較大不同。

出于競(jìng)爭(zhēng)的考慮，delta 和 iceberg 有的，hudi 可能都會(huì)跟進(jìn)，所以 hudi 也可以作為 table format 來(lái)使用。當(dāng)我們?yōu)槠髽I(yè)做技術(shù)選型時(shí)，需要考慮是選擇一個(gè)純凈的 table format 整合到自己的 platform 中，還是選擇一個(gè)新的 platform 或者將 platform 融合。

2、Iceberg 背刺與 delta2.0 的反擊

現(xiàn)在下判斷，為時(shí)尚早。

如果一定要對(duì)比，我更加喜歡對(duì)比 delta 和 iceberg，因?yàn)?hudi 的愿景和前兩個(gè)有較大的不同，換句話說，就 table format 而言，delta 和 iceberg 可能更懂要做什么，就懂的層面兩講，iceberg 我認(rèn)為更勝一籌。拿最近 delta 2.0 發(fā)布的內(nèi)容來(lái)看，有興趣的同學(xué)可以去看下 Databricks 官方舉辦的 Data + AI summit 2022 的 相關(guān)分享。

發(fā)布會(huì)重點(diǎn)提及的功能總結(jié)如下：

• Data skipping via column stats：通過 format 級(jí)別的元數(shù)據(jù)做 data skipping
• Optimize ZOrder：這個(gè)應(yīng)該是 delta 一直有的功能，只是在 2.0 中正式開源了
• Change data feed：支持 UPDATE/DELETE/MERGE INTO 下的 CDC 功能
• Column mapping：delta 也能像 iceberg 一樣模式演進(jìn)了，功能上相差不大
• Full ACID guarantees on S3：在提交階段引入 DynamoDB，在 S3 上也能保障 ACID
• Flink、presto、trino connector：重點(diǎn)強(qiáng)調(diào)了 flink 和 trino，connector 和 delta 項(xiàng)目分開管理 
• Delta standalone：我理解是提供了一層 format api，像 iceberg 一樣不用通過引擎也可以操作數(shù)據(jù)

對(duì) Iceberg 不太了解的同學(xué)，可以去看下 iceberg 官網(wǎng)，引用上文中的一句話，不能說非常相似，只能說一模一樣，而且大部分功能在 2 年前的 iceberg 中已經(jīng)相當(dāng)成熟了。

在發(fā)布會(huì)后段，Databricks 工程師重點(diǎn)介紹了：

• Adobe 公司從 iceberg 到 delta 的遷移實(shí)踐，對(duì) iceberg 的重視可謂是寫在臉上了
• Delta 不只是 databricks 公司貢獻(xiàn)，2.0 中也 involve 了來(lái)自 flink，trino 社區(qū)的開發(fā)者，不過引擎開發(fā)者貢獻(xiàn)的部分單獨(dú)在一個(gè) connector 項(xiàng)目，與 delta 的主體區(qū)分開，未來(lái)在引擎平權(quán)方面能不能做到或超越 iceberg，還需要觀察
• 引用第三方 Databeans 的測(cè)試，delta 2.0 性能比 iceberg 快 1.7 倍，比 hudi 快 4.3 倍

我們團(tuán)隊(duì)也用 benchmark 工具對(duì) delta2.0 和 iceberg 進(jìn)行了對(duì)比，測(cè)試方案是在 trino 下測(cè)試 100 個(gè) warehouse 的 tpch（測(cè)試工具實(shí)際是為測(cè) stream lakehouse 量身定制的 chbenchmark，下文也有提及），當(dāng)我們采用 delta 和 iceberg 開源版本默認(rèn)的參數(shù)，對(duì)比下來(lái) delta 確實(shí)驚艷，平均響應(yīng)時(shí)間 delta 比 iceberg 快 1.4 倍左右，但我們注意到默認(rèn)參數(shù)中有兩個(gè)重要的區(qū)別：

• Trino 下 delta 和 iceberg 的默認(rèn)壓縮算法不同，trino寫入 iceberg 默認(rèn)的壓縮算法是 ZSTD,而寫入delta 默認(rèn)的壓縮算法是 SNAPPY，ZSTD 具有比 SNAPPY 更高的壓縮比，通過實(shí)際觀測(cè)ZSTD壓縮出來(lái)的文件大小只有 SNAPPY 大小的 60%，但是在查詢時(shí)SNAPPY對(duì)于CPU更友好，查詢效率更高；
• Delta 和 iceberg 默認(rèn) read-target-size 不同，delta 默認(rèn)32m，iceberg 默認(rèn) 128m，plan 階段組裝更小的文件可以在執(zhí)行計(jì)劃采用更多并發(fā)度，當(dāng)然這會(huì)帶來(lái)更多資源消耗，從實(shí)踐上看 32m 的文件大小對(duì)響應(yīng)時(shí)間敏感的數(shù)據(jù)分析而言或許是更好的選擇。

將 delta 和 iceberg 的壓縮算法設(shè)置相同，read-target-size 設(shè)置為 32m，實(shí)測(cè)下來(lái) tpch 平均響應(yīng)時(shí)間不再有差別，從原理上看，排除占比極低的元數(shù)據(jù)讀取和 plan 時(shí)間，在相同的配置下，benchmark 測(cè)試的主要是 parquet 這類文件格式的 IO 性能，沒有差異是比較合理的。后續(xù) Onehouse 在性能測(cè)試上給出的 回?fù)?也佐證這一點(diǎn)：

作為一名相關(guān)從業(yè)者，Delta2.0 的完全開源是一件振奮人心的事，幾乎可以下結(jié)論，delta2.0 和 iceberg 重疊的功能，會(huì)成為數(shù)據(jù)湖 table format 的事實(shí)標(biāo)準(zhǔn)，在這個(gè)方向上提前投資的產(chǎn)品和開發(fā)者有可能更快地收獲果實(shí)。

至于誰(shuí)更優(yōu)秀？iceberg 的開放，專注和執(zhí)行力讓人嘆服，delta 的影響力，商業(yè)資源和成熟度不可忽略。從功能和外圍生態(tài)看，iceberg 依然有至少 1-2 年的先發(fā)優(yōu)勢(shì)，但是生長(zhǎng)在 iceberg 上原汁原味的 Tablur 還沒影，delta 的平臺(tái)背書本就超強(qiáng)，再向其他引擎開放了 connector 和 API 之后，相信開源的貢獻(xiàn)者和影響力也會(huì)同步跟進(jìn)，期待 delta 社區(qū)在活躍度上可以迎頭趕上。

3、新技術(shù)推廣的困局

作為一名基礎(chǔ)軟件工程師，自底向上倒逼需求是非常艱難的，想要業(yè)務(wù)團(tuán)隊(duì)切換基礎(chǔ)軟件可能同時(shí)需要天時(shí)地利人和，而研究數(shù)據(jù)湖的同學(xué)相信在過去兩年推動(dòng)業(yè)務(wù)時(shí)多少會(huì)遇到力不從心的局面，這里我來(lái)分享一些我的理解。

我們將目前數(shù)據(jù)湖 Format 已經(jīng)形成的標(biāo)準(zhǔn)能力做一個(gè)小結(jié)：

• 結(jié)構(gòu)自由，用戶可以自由變更表結(jié)構(gòu)，包括加列改列刪列，數(shù)據(jù)無(wú)需重寫
• 讀寫自由，通過 commit 原語(yǔ)保障 ACID，可以并發(fā)寫入和讀取，不會(huì)讀寫到不一致狀態(tài)
• 流批同源，除了批讀和批寫外，通過增量讀和流式攝取支持流計(jì)算
• 引擎平權(quán)，支持大部分用戶會(huì)用到的主流計(jì)算引擎，包括 flink、spark、trino 等

現(xiàn)在用戶使用數(shù)據(jù)湖，基本是在一個(gè)成熟的數(shù)據(jù)生產(chǎn)力平臺(tái)中使用，代表有阿里 Dataworks，網(wǎng)易數(shù)帆有數(shù)平臺(tái)，借用同事對(duì)網(wǎng)易大數(shù)據(jù)業(yè)務(wù)過去十年的發(fā)展實(shí)踐，大體分為三個(gè)階段：

1. 大數(shù)據(jù)平臺(tái)：能夠在 Hadoop 平臺(tái)上開發(fā)工作流，支持基礎(chǔ)的數(shù)據(jù)開發(fā)和運(yùn)維，有一定數(shù)據(jù)治理能力。
2. 數(shù)據(jù)中臺(tái)：將數(shù)據(jù)業(yè)務(wù)的更多共性需求抽象到中臺(tái)層，圍繞業(yè)務(wù)主題域構(gòu)建指標(biāo)體系，并打通數(shù)據(jù)模型、數(shù)據(jù)開發(fā)運(yùn)維、為業(yè)務(wù)構(gòu)建權(quán)限和質(zhì)量評(píng)估體系，資產(chǎn)平臺(tái)為業(yè)務(wù)提供更高階的數(shù)據(jù)治理能力。
3. 3D 平臺(tái)：我們從數(shù)據(jù)中臺(tái)，升級(jí)到 Dataops，Datafusion，Dataproduct 的 3D 體系，3D 更加強(qiáng)調(diào)體系化和流程標(biāo)準(zhǔn)化，強(qiáng)調(diào) CICD，強(qiáng)調(diào)多數(shù)據(jù)源融合。

在市面上除了阿里，數(shù)據(jù)生產(chǎn)力平臺(tái)基本還是圍繞 Hadoop，Hive 的數(shù)據(jù)湖體系，或者云端的對(duì)象存儲(chǔ)來(lái)構(gòu)建，相比于 Delta，Iceberg 這類數(shù)據(jù)湖 Format，Hive 和對(duì)象存儲(chǔ)的結(jié)構(gòu)不自由，讀寫不自由的問題基本已通過流程規(guī)范和上層規(guī)避克服掉了。在新數(shù)據(jù)湖技術(shù)興起階段，大家津津樂道的模式演進(jìn)， ACID，對(duì)一個(gè)成熟的數(shù)據(jù)生產(chǎn)力平臺(tái)以及它所面向的平臺(tái)運(yùn)維，數(shù)據(jù)消費(fèi)者，分析師基本無(wú)感，而引擎平權(quán)的特性，hive 自己已經(jīng)做到了最佳。

至于流批同源，在實(shí)踐中歸納起來(lái)有以下兩點(diǎn)：

• 用數(shù)據(jù)湖 CDC 替代消息隊(duì)列，理論上能夠帶來(lái)成本收益，但也會(huì)引入小文件問題；
• 數(shù)據(jù)湖 + 讀時(shí)合并，在一定程度上對(duì) kudu，clickhouse，doris 等實(shí)時(shí)數(shù)倉(cāng)方案形成替代方案。

總體來(lái)說，以上兩點(diǎn)是行業(yè)內(nèi)討論最多的數(shù)據(jù)湖實(shí)踐，但這套技術(shù)在實(shí)踐上客觀說還不夠成熟，比如說用數(shù)據(jù)湖 CDC 替代 kafka，延遲降低到分鐘級(jí)別，先不說產(chǎn)品的適配成本，業(yè)務(wù)接受這種能力降級(jí)往往需要比成本優(yōu)化更充分的理由，而且數(shù)據(jù)湖 CDC 還會(huì)引入小文件問題。對(duì)讀時(shí)合并這點(diǎn)，我們測(cè)試下來(lái)，用流式攝取方式往 iceberg 表寫入兩個(gè)小時(shí)，AP 的性能下降至少一半。當(dāng)然 delta/iceberg 帶來(lái)的新功能不止于此，比如模式演進(jìn)對(duì)特征的場(chǎng)景非常有用，MERGE INTO 的語(yǔ)法對(duì)補(bǔ)數(shù)的場(chǎng)景非常有用，UPDETE/DELETE SQL 對(duì)國(guó)外 GDPR/CPAA 的執(zhí)行是強(qiáng)需求，但這些特性比較細(xì)，往往只是對(duì)特定場(chǎng)景有吸引。

兩年來(lái)我們跟不少同行做實(shí)踐上的交流，大家大體上遇到的都是這樣的問題：業(yè)務(wù)吸引不夠，相比替代方案好像沒有帶來(lái)質(zhì)的提升；產(chǎn)品適配意愿不強(qiáng)，三個(gè)項(xiàng)目都很牛，但似乎看不到能給產(chǎn)品帶來(lái)什么實(shí)質(zhì)的好處，又怕站錯(cuò)邊選錯(cuò)路；疊加經(jīng)濟(jì)形勢(shì)下行，業(yè)務(wù)風(fēng)險(xiǎn)偏好降低，對(duì)新技術(shù)也沒那么上心了。

所以當(dāng)我們真正把新的數(shù)據(jù)湖技術(shù)應(yīng)用到產(chǎn)品和實(shí)踐中，不妨先自頂向下地思考這個(gè)問題：企業(yè)究竟需要怎樣的數(shù)據(jù)湖？?

4、企業(yè)需要怎樣的數(shù)據(jù)湖？

這個(gè)問題其實(shí) Databricks 已經(jīng)給了我們答案，Delta 用一套數(shù)據(jù)湖存儲(chǔ)，將批計(jì)算和流計(jì)算融合，將傳統(tǒng)數(shù)倉(cāng)在數(shù)據(jù)分析上的優(yōu)勢(shì)，數(shù)據(jù)湖在 AI，數(shù)據(jù)科學(xué)上的優(yōu)勢(shì)結(jié)合起來(lái)，基于 Lakehouse 這個(gè)存儲(chǔ)底座，實(shí)現(xiàn)數(shù)據(jù)業(yè)務(wù)的全場(chǎng)景覆蓋?？偨Y(jié)為一點(diǎn)，Delta 給 Databricks 帶來(lái)的價(jià)值是用一套基礎(chǔ)數(shù)據(jù)湖軟件，實(shí)現(xiàn)全場(chǎng)景覆蓋。

那么這套方法論適用于其他企業(yè)嗎？我認(rèn)為答案是肯定的，但是要稍作修改，首先 Databricks 公司做這個(gè)項(xiàng)目比較早，并且是作為一個(gè)戰(zhàn)略型項(xiàng)目來(lái)做，它的產(chǎn)品，上層建筑一定是同步跟進(jìn)的，這也讓他的整套 platform 受益于 Lakehouse 非常簡(jiǎn)潔，而大部分企業(yè)用戶歷史負(fù)擔(dān)要重很多，產(chǎn)品適配牽一發(fā)動(dòng)全身。

另一方面，國(guó)內(nèi)基本上實(shí)時(shí)計(jì)算用 Flink，這里不評(píng)價(jià) Flink 和 Spark 哪個(gè)更好，現(xiàn)實(shí)是絕大多數(shù)企業(yè)不會(huì)綁定一個(gè)計(jì)算引擎，這也是為什么引擎平權(quán)對(duì)數(shù)據(jù)湖極為重要，重要到 Delta 也不得不妥協(xié)，不同引擎的應(yīng)用可以吸收各家優(yōu)勢(shì)，但會(huì)帶來(lái)產(chǎn)品割裂的問題，主流大數(shù)據(jù)平臺(tái)的供應(yīng)商大多把實(shí)時(shí)計(jì)算作為一個(gè)單獨(dú)的產(chǎn)品入口，當(dāng)然這背后的原因不光是引擎的問題 ，最重要的依然是存儲(chǔ)方案的不統(tǒng)一。產(chǎn)品割裂在大數(shù)據(jù)方法論的迭代中被更加放大，比如在數(shù)據(jù)中臺(tái)中，指標(biāo)系統(tǒng)，數(shù)據(jù)模型，數(shù)據(jù)質(zhì)量，數(shù)據(jù)資產(chǎn)這一套中臺(tái)模塊基本是圍繞離線場(chǎng)景打造，而在強(qiáng)調(diào) CICD 的 Dataops 中，流計(jì)算的需求和場(chǎng)景因?yàn)榇鎯?chǔ)和計(jì)算的不統(tǒng)一更加難以被納入考量。

這個(gè)狀況的直接結(jié)果是實(shí)時(shí)數(shù)倉(cāng)，流計(jì)算對(duì)應(yīng)的場(chǎng)景和需求在大數(shù)據(jù)平臺(tái)的方法論迭代中被邊緣化，用戶無(wú)法在實(shí)時(shí)場(chǎng)景下體驗(yàn)到數(shù)據(jù)安全，數(shù)據(jù)質(zhì)量，數(shù)據(jù)治理帶來(lái)的收益，變本加厲的是，很多既需要實(shí)時(shí)也需要離線的場(chǎng)景下，用戶需要維護(hù)流表和批表兩套模型，兩套代碼，并且時(shí)刻警惕語(yǔ)義和模型的二義性。

了解了 Lakehouse 意義，立足于現(xiàn)實(shí)，以網(wǎng)易數(shù)帆為例，新的數(shù)據(jù)湖技術(shù)應(yīng)當(dāng)幫助 dataops 拓展邊界，讓數(shù)據(jù)開發(fā)和運(yùn)維，數(shù)據(jù)治理的整套體系囊括實(shí)時(shí)和 AI 的場(chǎng)景，流批一體的數(shù)據(jù)湖肩負(fù)著為業(yè)務(wù)實(shí)現(xiàn)去 lambda 的架構(gòu)，產(chǎn)品的交互和體驗(yàn)應(yīng)當(dāng)更加簡(jiǎn)潔和高效，讓算法分析師，數(shù)據(jù)科學(xué)家，對(duì)時(shí)效性更加敏感的風(fēng)控等場(chǎng)景也能按照 Dataops 的標(biāo)準(zhǔn)和規(guī)范快速上手，可以用數(shù)據(jù)治理的方法論優(yōu)化成本。

聊到這里，可能會(huì)覺得越來(lái)越抽象，我們來(lái)舉一個(gè)數(shù)據(jù)分析的 lambda 架構(gòu)：

場(chǎng)景中用 Hive 做批表，kafka 做流表，整個(gè)離線遵循數(shù)據(jù)中臺(tái)和 Dataops 的方法論，實(shí)時(shí)場(chǎng)景下需要用戶構(gòu)建同步到 hbase 的流計(jì)算任務(wù)，需要用戶實(shí)現(xiàn) join hbase 維表的流計(jì)算任務(wù)，把數(shù)據(jù)寫到支持實(shí)時(shí)更新的 kudu 中，最后由業(yè)務(wù)根據(jù)實(shí)時(shí)和離線的需要選擇查詢 kudu 表還是 hive 表，在此之前，用戶需要分別在數(shù)據(jù)模型中建表，使用 kudu 的工具建表，并且自己處理兩個(gè)系統(tǒng)的差異。在這個(gè)架構(gòu)中，用戶遭受了割裂的體驗(yàn)，并且需要在上層做很多工作。

企業(yè)需要的數(shù)據(jù)湖，應(yīng)當(dāng)能夠幫助業(yè)務(wù)解決割裂的問題，用數(shù)據(jù)湖實(shí)現(xiàn) ETL 、data pipeline 以及 olap 全流程，實(shí)現(xiàn)下面的效果：

因?yàn)閷?shí)時(shí)和離線使用了一套模型，在理論上已經(jīng)可以將中臺(tái)和 dataops 的很多能力應(yīng)用到實(shí)時(shí)場(chǎng)景中，比如數(shù)據(jù)質(zhì)量，當(dāng)然這個(gè)過程中還需要在細(xì)節(jié)上做出更多的創(chuàng)新。核心的一點(diǎn)，數(shù)據(jù)湖技術(shù)的應(yīng)用和推廣不應(yīng)當(dāng)立足在某個(gè)或某些特定功能之上，應(yīng)當(dāng)結(jié)合數(shù)據(jù)平臺(tái)的方法論全局來(lái)看，讓數(shù)據(jù)分析、AI、流計(jì)算各個(gè)場(chǎng)景各個(gè)環(huán)節(jié)都能從中受益。

5、我們的工作

在這樣的目標(biāo)驅(qū)動(dòng)下，過去兩年我們團(tuán)隊(duì)開發(fā)了 Arctic 這個(gè)項(xiàng)目，并且在 7 月底默默開源了。

首先，我們的工作不是另起爐灶，做一個(gè)跟 delta/iceberg 競(jìng)爭(zhēng)的產(chǎn)品，這不符合企業(yè)的需求，Arctic 是立足于開源數(shù)據(jù)湖 Format 之上的服務(wù)，如前文所說，目前我們基于 iceberg。

其次，我們的目標(biāo)要將 Dataops 的邊界拓展到流計(jì)算，所以 Arctic 會(huì)為用戶提供更加優(yōu)化的流的能力，包括 stream upsert，CDC，生產(chǎn)可用的讀時(shí)合并技術(shù)，提供分鐘級(jí)別新鮮度的數(shù)據(jù)分析能力，用一句話概括，Arctic 是適配多引擎的流式湖倉(cāng)服務(wù)：

通過 Arctic 的幾個(gè)核心特性可以看出我們是怎么聚焦于拓展大數(shù)據(jù)平臺(tái)的邊界。

• Arctic 具備持續(xù)自優(yōu)化的能力（self-optimized）
• 提供 hive 或 iceberg 兩種兼容模式，可以把一張 Arctic 表當(dāng)成開源的 hive 表或 iceberg 表來(lái)使用，用戶永遠(yuǎn)不用擔(dān)心 iceberg 的新功能用不上，也不用擔(dān)憂老業(yè)務(wù)的 hive 表不能使用 Arctic 功能
• 支持多引擎并發(fā)寫入，并且保障主鍵場(chǎng)景下的數(shù)據(jù)一致性，流和批各寫各的，arctic 會(huì)解決相同主鍵寫入的數(shù)據(jù)沖突
• 提供實(shí)時(shí)數(shù)據(jù)湖的標(biāo)準(zhǔn)化 metrics 和管理工具，并且向平臺(tái)提供 thrift API

Arctic 作為服務(wù)可以去適配不同的數(shù)據(jù)湖 Format，這樣產(chǎn)品無(wú)需擔(dān)心數(shù)據(jù)湖技術(shù)的選型問題，持續(xù)自優(yōu)化的能力讓數(shù)據(jù)分析即插即用，平替實(shí)時(shí)數(shù)倉(cāng)，兼容模式則可以讓產(chǎn)品在選型上更加沒有后顧之憂，實(shí)踐中可以針對(duì)性的設(shè)計(jì)升級(jí)和灰度方案，并發(fā)沖突解決和一致性讓數(shù)據(jù)流管理變的簡(jiǎn)單。

性能也是 Arctic 非常關(guān)注的點(diǎn)，尤其在讀時(shí)合并方面，我們做了大量工作，面向流式湖倉(cāng)性能測(cè)試工具我們做出了針對(duì)性的方案，這塊的工作今年晚些時(shí)候我們也會(huì)向大家開放，簡(jiǎn)單來(lái)說，我們使用 HTAP 的 chbenchmark 思路，tpcc 持續(xù)寫入的數(shù)據(jù)通過 FlinkCDC 流式寫入 arctic 和 hudi，benchmark 的測(cè)試結(jié)果用 tpch 來(lái)衡量，測(cè)試的對(duì)象是 olap 場(chǎng)景下的讀時(shí)合并性能，arctic 和 hudi 的數(shù)據(jù)新鮮度都設(shè)置為 1 分鐘，目前 arctic 開源版本測(cè)試結(jié)果如下（數(shù)值越小性能越好）：

測(cè)試方案、環(huán)境和配置會(huì)在 Arctic 的官網(wǎng)中公開，同時(shí)我們將在8月11號(hào)的分享中公布更多benchmark 的細(xì)節(jié)，感興趣的同學(xué)，或者對(duì)測(cè)試結(jié)果有疑問，歡迎參加我們的發(fā)布會(huì)了解更多信息。

雖然我們?cè)?table format 之上，引擎之下做了很多優(yōu)化工作，但 Arctic 不會(huì)魔改 format 的內(nèi)部實(shí)現(xiàn)， Arctic 依賴的都是社區(qū)發(fā)布的 release 包，未來(lái) Arctic 也將堅(jiān)持這一點(diǎn)，并通過 format 兼容的特性為用戶帶來(lái)最佳的方案。

我們即將在 2022 年 8 月 11 日在線上舉辦一個(gè)簡(jiǎn)單的發(fā)布會(huì)，我會(huì)花 30 分鐘左右的時(shí)間來(lái)講講 Arctic 的目標(biāo)、特性、規(guī)劃，以及可以給開源用戶帶來(lái)的價(jià)值。從調(diào)性上看，Arctic 作為基礎(chǔ)軟件會(huì)是一個(gè)完全開源的項(xiàng)目，相關(guān)商業(yè)化（如果有）會(huì)由另外的團(tuán)隊(duì)推進(jìn)，未來(lái)?xiàng)l件允許的情況下我們也會(huì)積極推動(dòng)項(xiàng)目向基金會(huì)的孵化，從這篇文章中可以看到??網(wǎng)易數(shù)帆領(lǐng)導(dǎo)層對(duì)開源的態(tài)度??。

如果你對(duì) Arctic 的定位、功能，或者任何與他相關(guān)的部分感興趣，歡迎觀看我們的直播或錄播，或者通過下面的鏈接了解 arctic：

• Arctic 文檔地址：https://arctic.netease.com/ch/
• Git 地址：https://github.com/NetEase/arctic

6、總結(jié)

Delta2.0 的發(fā)布，標(biāo)志著數(shù)據(jù)湖 table format 標(biāo)準(zhǔn)開始走向明確，delta、iceberg 和 hudi 的競(jìng)爭(zhēng)變得白熱化的同時(shí)，企業(yè)以及相關(guān)的供應(yīng)商應(yīng)當(dāng)開始認(rèn)真考慮怎樣引入數(shù)據(jù)湖 table format 技術(shù)，給平臺(tái)用戶帶來(lái) Lakehouse 的最佳實(shí)踐。

Lakehouse 給企業(yè)帶來(lái)的價(jià)值，應(yīng)當(dāng)是用一套數(shù)據(jù)湖底座，拓展數(shù)據(jù)平臺(tái)的邊界，改善產(chǎn)品、數(shù)據(jù)孤島和流程規(guī)范割裂帶來(lái)的低效和成本浪費(fèi)，首先要做的，是將圍繞傳統(tǒng)離線數(shù)倉(cāng)打造的數(shù)據(jù)中臺(tái)，或者衍生的 Dataops 方法論，拓展到實(shí)時(shí)場(chǎng)景，未來(lái)的數(shù)據(jù)產(chǎn)品方法論，在 Lakehouse 以及相關(guān)技術(shù)的推動(dòng)下，相信會(huì)向流批融合的大方向上大步前進(jìn)。

但是企業(yè)和開發(fā)者需要理解，開源的數(shù)據(jù)湖 Format 不等價(jià)于 Lakehouse，包括創(chuàng)造出 Lakehouse 這個(gè)概念的 Databricks 自己，也從未將 Delta 與 Lakehouse 劃等號(hào)，如何幫助企業(yè)構(gòu)建 lakehouse，是我們此次開源 Arctic 項(xiàng)目的意義，Arctic 目前的定位是流式湖倉(cāng)服務(wù)，流式強(qiáng)調(diào)向?qū)崟r(shí)能力的拓展，服務(wù)則強(qiáng)調(diào)管理，標(biāo)準(zhǔn)化度量，以及其他可以抽象到基礎(chǔ)軟件中的 lakehouse 能力。以 Arctic 持續(xù)自優(yōu)化的功能舉例：

Arctic 為管理員和開發(fā)者提供了持續(xù)優(yōu)化的度量和管理工具，以幫助用戶實(shí)現(xiàn)時(shí)效性，存儲(chǔ)和計(jì)算成本的測(cè)量，標(biāo)定和規(guī)劃。進(jìn)一步說，在以數(shù)據(jù)湖構(gòu)建的離線場(chǎng)景中，成本和性能呈非常線性的關(guān)系，當(dāng)性能或容量不足時(shí)，SRE 只需要考慮加多少機(jī)器。而當(dāng)我們將數(shù)據(jù)湖的能力拓展到實(shí)時(shí)場(chǎng)景，成本，性能和數(shù)據(jù)新鮮度的關(guān)系將呈現(xiàn)更為復(fù)雜和微妙的狀態(tài)，Arcitic 的服務(wù)和管理功能，將為用戶和上層平臺(tái)理清這一層三角關(guān)系：