隨著互聯(lián)網(wǎng)高速發(fā)展，大數(shù)據(jù)技術(shù)快速發(fā)展和迅速迭代，降低了用戶(hù)處理海量數(shù)據(jù)的門(mén)檻，越來(lái)越多的應(yīng)運(yùn)場(chǎng)景出現(xiàn)在我們的身邊存儲(chǔ)和處理需求越來(lái)越多樣化，逐漸呈現(xiàn)出數(shù)據(jù)倉(cāng)庫(kù)往數(shù)據(jù)湖方向發(fā)展、批處理往流式處理發(fā)展、本地部署往云模式發(fā)展的趨勢(shì)。

但在技術(shù)發(fā)展層面，逐漸出現(xiàn)了諸多的掣肘，不斷有新的問(wèn)題出現(xiàn)，僅僅就存儲(chǔ)方面來(lái)講，與數(shù)據(jù)庫(kù)這樣高度優(yōu)化的技術(shù)相比，大數(shù)據(jù)技術(shù)的抽象和實(shí)現(xiàn)還是太原始和初級(jí)。

目前的數(shù)據(jù)倉(cāng)庫(kù)技術(shù)出現(xiàn)了一定的局限性，比如單一不變的 schema 和模型已經(jīng)無(wú)法滿(mǎn)足各類(lèi)不同場(chǎng)景和領(lǐng)域的數(shù)據(jù)分析的要求、流批一體的數(shù)據(jù)存儲(chǔ)引擎和計(jì)算引擎適配問(wèn)題以及Hadoop體系文件系統(tǒng)的ACID能力缺失等問(wèn)題急需要解決，但就目前的技術(shù)棧而言，打破這些技術(shù)的桎梏，似乎多少有些力不從心，這個(gè)過(guò)程中，一項(xiàng)重大變革似乎在破曉前顯得尤為必要。

在不停地探索和思考中，大數(shù)據(jù)人開(kāi)始慢慢醒悟，回頭看向成名已久的數(shù)據(jù)庫(kù)，將更多數(shù)據(jù)庫(kù)的成熟技術(shù)和理念借鑒到大數(shù)據(jù)中，似乎是一條高效又穩(wěn)健的道路。至此，數(shù)據(jù)湖技術(shù)應(yīng)運(yùn)而生，在諸多方面向數(shù)據(jù)庫(kù)看齊，你可以說(shuō)是學(xué)習(xí)，當(dāng)然，也可以說(shuō)是致敬，是業(yè)界針對(duì)這些問(wèn)題的一種解決方案。

那么，什么是數(shù)據(jù)湖技術(shù)呢?

計(jì)算引擎之下、數(shù)據(jù)存儲(chǔ)之上，處于中間層的數(shù)據(jù)湖。

簡(jiǎn)單地說(shuō)，這類(lèi)新技術(shù)是介于上層計(jì)算引擎和底層存儲(chǔ)格式之間的一個(gè)中間層，我們可以把它定義成一種“數(shù)據(jù)組織格式”。其最核心的點(diǎn)便是將事務(wù)能力帶到了大數(shù)據(jù)領(lǐng)域，并抽象成統(tǒng)一的中間格式供不同引擎適配對(duì)接。

為此，Uber開(kāi)源了Apache Hudi，Databricks提出了Delta Lake，而 Netflix 則發(fā)起了 Apache Iceberg 項(xiàng)目，一時(shí)間這種具備 ACID 能力的表格式中間件成為了大數(shù)據(jù)、數(shù)據(jù)湖領(lǐng)域炙手可熱的方向。

Iceberg 將其稱(chēng)之為“表格式”也是表達(dá)類(lèi)似的含義。它與底層的存儲(chǔ)格式(比如 ORC、Parquet 之類(lèi)的列式存儲(chǔ)格式)最大的區(qū)別是，它并不定義數(shù)據(jù)存儲(chǔ)方式，而是定義了數(shù)據(jù)、元數(shù)據(jù)的組織方式，向上提供統(tǒng)一的“表”的語(yǔ)義。它構(gòu)建在數(shù)據(jù)存儲(chǔ)格式之上，其底層的數(shù)據(jù)存儲(chǔ)仍然使用 Parquet、ORC 等進(jìn)行存儲(chǔ)。

Apache Iceberg、Hudi 和 Delta Lake 誕生于不同公司，需要解決的問(wèn)題存在差異，因此三者在設(shè)計(jì)初衷上稍有不同。

其中，Iceberg 的設(shè)計(jì)初衷更傾向于定義一個(gè)標(biāo)準(zhǔn)、開(kāi)放且通用的數(shù)據(jù)組織格式，同時(shí)屏蔽底層數(shù)據(jù)存儲(chǔ)格式上的差異，向上提供統(tǒng)一的操作 API，使得不同的引擎可以通過(guò)其提供的 API 接入;Hudi 的設(shè)計(jì)初衷更像是為了解決流式數(shù)據(jù)的快速落地，并能夠通過(guò) upsert 語(yǔ)義進(jìn)行延遲數(shù)據(jù)修正;Delta Lake 作為 Databricks 開(kāi)源的項(xiàng)目，更側(cè)重于在 Spark 層面上解決 Parquet、ORC 等存儲(chǔ)格式的固有問(wèn)題，并帶來(lái)更多的能力提升。

雖然這三個(gè)項(xiàng)目在設(shè)計(jì)初衷上稍有不同，但實(shí)現(xiàn)的思路和提供的能力卻非常相似，他們都提供了 ACID 的能力，都基于樂(lè)觀鎖實(shí)現(xiàn)了沖突解決和提供線(xiàn)性一致性，同時(shí)相應(yīng)地提供了 time travel 的功能。

但是因?yàn)樵O(shè)計(jì)初衷的不同，三個(gè)項(xiàng)目當(dāng)前的能力象限各有不同，Iceberg 在其格式定義和核心能力上最為完善，但是上游引擎的適配上稍顯不足;Hudi 基于 Spark 打造了完整的流式數(shù)據(jù)落地方案，但是其核心抽象較弱，與 Spark 耦合較緊;Delta Lake 同樣高度依賴(lài)于 Spark 生態(tài)圈，與其他引擎的適配尚需時(shí)日。

那么，當(dāng)下數(shù)據(jù)湖技術(shù)呈現(xiàn)的三足鼎立的技術(shù)場(chǎng)面，優(yōu)劣點(diǎn)如何看待，技術(shù)選型如何去做，當(dāng)然是我們最關(guān)心的問(wèn)題，下文逐步解析。

Delta Lake，spark生態(tài)圈急先鋒

傳統(tǒng)的 lambda 架構(gòu)需要同時(shí)維護(hù)批處理和流處理兩套系統(tǒng)，資源消耗大，維護(hù)復(fù)雜。

基于 Hive 的數(shù)倉(cāng)或者傳統(tǒng)的文件存儲(chǔ)格式(比如 parquet / ORC)，都存在一些難以解決的問(wèn)題：小文件問(wèn)題、并發(fā)讀寫(xiě)問(wèn)題、有限的更新支持及海量元數(shù)據(jù)(例如分區(qū))導(dǎo)致 metastore 不堪重負(fù)問(wèn)題等。

如上圖，Delta Lake 是 Spark 計(jì)算框架和存儲(chǔ)系統(tǒng)之間帶有 Schema 信息的存儲(chǔ)中間層。

它集中解決了傳統(tǒng)hive數(shù)倉(cāng)的諸多問(wèn)題，使得實(shí)時(shí)數(shù)據(jù)湖變得優(yōu)雅又絲滑，不見(jiàn)了天生的慵懶，只看到輕盈又婀娜的身姿。重要變化如下：

1. 設(shè)計(jì)了基于 HDFS 存儲(chǔ)的元數(shù)據(jù)系統(tǒng)，解決 metastore 不堪重負(fù)的問(wèn)題;
2. 支持更多種類(lèi)的更新模式，比如 Merge / Update / Delete 等操作，配合流式寫(xiě)入或者讀取的支持，讓實(shí)時(shí)數(shù)據(jù)湖變得水到渠成;
3. 流批操作可以共享同一張表;
4. 版本概念，可以隨時(shí)回溯，避免因?yàn)橐淮握`操作或者代碼邏輯而無(wú)法恢復(fù)的災(zāi)難性后果。

基于Parquet的列式存儲(chǔ)層，在多并發(fā)寫(xiě)入之間提供 ACID 事務(wù)保證。每次寫(xiě)入都是一個(gè)事務(wù)，并且在事務(wù)日志中記錄了寫(xiě)入的序列順序。

但是，Delta Lake定位于spark流批一體的數(shù)據(jù)處理工具，地主家的公子，自己家的事情如數(shù)家珍，輕松搞定，但走出家門(mén)后，難免會(huì)有些水土不服。

Apache Hudi，有天生缺陷的優(yōu)等生

Apache Hudi 代表 Hadoop Upserts and Incrementals，能夠使HDFS數(shù)據(jù)集在分鐘級(jí)的時(shí)延內(nèi)支持變更，也支持下游系統(tǒng)對(duì)這個(gè)數(shù)據(jù)集的增量處理。

Hudi數(shù)據(jù)集通過(guò)自定義的inputFormat 兼容當(dāng)前 Hadoop 生態(tài)系統(tǒng)，包括 Apache Hive，Apache Parquet，Presto 和 Apache Spark，使得終端用戶(hù)可以無(wú)縫的對(duì)接。

如下圖，基于 Hudi 簡(jiǎn)化的服務(wù)架構(gòu)，分鐘級(jí)延遲。

Hudi 會(huì)維護(hù)一個(gè)時(shí)間軸，在每次執(zhí)行操作時(shí)(如寫(xiě)入、刪除、合并等)，均會(huì)帶有一個(gè)時(shí)間戳。

通過(guò)時(shí)間軸，可以實(shí)現(xiàn)在僅查詢(xún)某個(gè)時(shí)間點(diǎn)之后成功提交的數(shù)據(jù)，或是僅查詢(xún)某個(gè)時(shí)間點(diǎn)之前的數(shù)據(jù)。

這樣可以避免掃描更大的時(shí)間范圍，并非常高效地只消費(fèi)更改過(guò)的文件(例如在某個(gè)時(shí)間點(diǎn)提交了更改操作后，僅 query 某個(gè)時(shí)間點(diǎn)之前的數(shù)據(jù)，則仍可以 query 修改前的數(shù)據(jù))。

如上圖的左邊，Hudi 將數(shù)據(jù)集組織到與 Hive 表非常相似的基本路徑下的目錄結(jié)構(gòu)中。

數(shù)據(jù)集分為多個(gè)分區(qū)，每個(gè)分區(qū)均由相對(duì)于基本路徑的分區(qū)路徑唯一標(biāo)識(shí)。

如上圖的中間部分，Hudi 以?xún)煞N不同的存儲(chǔ)格式存儲(chǔ)所有攝取的數(shù)據(jù)。

讀優(yōu)化的列存格式(ROFormat)：僅使用列式文件(parquet)存儲(chǔ)數(shù)據(jù)。在寫(xiě)入/更新數(shù)據(jù)時(shí)，直接同步合并原文件，生成新版本的基文件(需要重寫(xiě)整個(gè)列數(shù)據(jù)文件，即使只有一個(gè)字節(jié)的新數(shù)據(jù)被提交)。此存儲(chǔ)類(lèi)型下，寫(xiě)入數(shù)據(jù)非常昂貴，而讀取的成本沒(méi)有增加，所以適合頻繁讀的工作負(fù)載，因?yàn)閿?shù)據(jù)集的最新版本在列式文件中始終可用，以進(jìn)行高效的查詢(xún)。

寫(xiě)優(yōu)化的行存格式(WOFormat)：使用列式(parquet)與行式(avro)文件組合，進(jìn)行數(shù)據(jù)存儲(chǔ)。在更新記錄時(shí)，更新到增量文件中(avro)，然后進(jìn)行異步(或同步)的compaction，創(chuàng)建列式文件(parquet)的新版本。此存儲(chǔ)類(lèi)型適合頻繁寫(xiě)的工作負(fù)載，因?yàn)樾掠涗浭且詀ppending 的模式寫(xiě)入增量文件中。但是在讀取數(shù)據(jù)集時(shí)，需要將增量文件與舊文件進(jìn)行合并，生成列式文件。

Apache Iceberg，基礎(chǔ)扎實(shí)，后生可畏

Iceberg 作為新興的數(shù)據(jù)湖框架之一，開(kāi)創(chuàng)性地抽象出“表格式”table format)這一中間層，既獨(dú)立于上層的計(jì)算引擎(如Spark和Flink)和查詢(xún)引擎(如Hive和Presto)，也和下層的文件格式(如Parquet，ORC和Avro)相互解耦。

此外 Iceberg 還提供了許多額外的能力：

• ACID事務(wù);
• 時(shí)間旅行(time travel)，以訪問(wèn)之前版本的數(shù)據(jù);
• 完備的自定義類(lèi)型、分區(qū)方式和操作的抽象;
• 列和分區(qū)方式可以進(jìn)化，而且進(jìn)化對(duì)用戶(hù)無(wú)感，即無(wú)需重新組織或變更數(shù)據(jù)文件;
• 隱式分區(qū)，使SQL不用針對(duì)分區(qū)方式特殊優(yōu)化;
• 面向云存儲(chǔ)的優(yōu)化等;

Iceberg的架構(gòu)和實(shí)現(xiàn)并未綁定于某一特定引擎，它實(shí)現(xiàn)了通用的數(shù)據(jù)組織格式，利用此格式可以方便地與不同引擎(如Flink、Hive、Spark)對(duì)接。

所以 Iceberg 的架構(gòu)更加的優(yōu)雅，對(duì)于數(shù)據(jù)格式、類(lèi)型系統(tǒng)有完備的定義和可進(jìn)化的設(shè)計(jì)。

綜合而言，三個(gè)引擎的初衷場(chǎng)景并不完全相同，Hudi 為了 incremental 的 upserts，相對(duì)而言最為成熟，但底層架構(gòu)設(shè)計(jì)較差，擴(kuò)展性及生態(tài)延續(xù)方面難度較大;Iceberg 定位于高性能的分析與可靠的數(shù)據(jù)管理，底層架構(gòu)的抽象及架構(gòu)的開(kāi)放性方面做的很好，數(shù)據(jù)湖upsert和compaction兩個(gè)關(guān)鍵的功能也趨于完善，正在快速發(fā)展期;Delta 定位于流批一體的數(shù)據(jù)處理，無(wú)縫對(duì)接Spark生態(tài)。

我們?cè)诩夹g(shù)選型的時(shí)候，不僅要知到要到哪里去，更要明確我們從哪里來(lái)，選擇適合自己當(dāng)下業(yè)務(wù)需求的技術(shù)，才能更快速、更高效輔助業(yè)務(wù)開(kāi)發(fā)。