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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

如上圖的中間部分，Hudi 以兩種不同的存儲格式存儲所有攝取的數(shù)據(jù)。

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

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

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

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

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

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

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

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

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

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