隨著大數據存儲和處理需求越來越多樣化，如何構建一個統一的數據湖存儲，並在其上進行多種形式的數據分析，成了企業構建大數據生態的一個重要方向。如何快速、一致、原子性地在數據湖存儲上構建起 Data Pipeline，成了亟待解決的問題。為此，Uber 開源了 Apache Hudi，Databricks 提出了 Delta Lake，而 Netflix 則發起了 Apache Iceberg 項目，一時間這種具備 ACID 能力的表格式中間件成為了大數據、數據湖領域炙手可熱的方向。
雖然現階段國內仍然缺乏數據湖概念上的優秀商業方案，但在基礎軟體開源化的趨勢下，國內企業在數據湖技術點上的探索與跟進並不比國外企業落後太多。騰訊在 2018 年加入大數據存儲開源項目 Apache Ozone，後又於 2019 年開始投入研發 Apache Iceberg；阿里巴巴也正聯合 Apache Iceberg 社區積極推動 Flink 實時數據湖技術方案的落地。那麼，Iceberg 和其他兩個開源項目有何不同？為什麼阿里和騰訊都在積極投入 Iceberg 的開源生態？Iceberg 有什麼獨到之處？近期 InfoQ 採訪了騰訊數據平臺部數據湖內核技術負責人、資深大數據工程師邵賽賽，他與我們分享了騰訊選擇 Iceberg 前後的一些思考和採用 Iceberg 之後所做的優化工作，本文基於採訪整理而成。邵賽賽還將在 QCon 全球軟體開發大會（北京站）2020 帶來主題為《Iceberg - 新一代的數據湖表格式》的演講分享，感興趣的讀者可以關注。
計算引擎之下、存儲之上的新技術
資料庫大牛、圖靈獎獲得者 Michael Stonebraker 曾在 MapReduce 誕生之初撰寫過一篇文章，題為「MapReduce: A major step backwards」，Michael Stonebraker 在文章中直截了當地指出：MapReduce 忽視了資料庫領域積累超過 40 年的技術經驗。雖然大數據技術的出現和迭代降低了用戶處理海量數據的門檻，但另一方面，與資料庫這樣高度優化的技術相比，大數據技術的抽象和實現還是太原始和初級。因此大數據技術在後續十幾年的發展中，一直以資料庫為目標，將更多資料庫的成熟技術和理念借鑑到大數據中。
當前，大數據分析領域已經相當成熟，如何借鑑更多資料庫的成熟技術和理念來提升大數據的能力呢？Apache Iceberg、Hudi 和 Delta Lake 這三個定位類似的開源項目正是從資料庫方法論中汲取了靈感，將事務能力帶到了大數據領域，並抽象成統一的中間格式供不同引擎適配對接。
如何定義這類新技術？
簡單地說，這類新技術是介於上層計算引擎和底層存儲格式之間的一個中間層，我們可以把它定義成一種「數據組織格式」，Iceberg 將其稱之為「表格式」也是表達類似的含義。它與底層的存儲格式（比如 ORC、Parquet 之類的列式存儲格式）最大的區別是，它並不定義數據存儲方式，而是定義了數據、元數據的組織方式，向上提供統一的「表」的語義。它構建在數據存儲格式之上，其底層的數據存儲仍然使用 Parquet、ORC 等進行存儲。
Apache Iceberg、Hudi 和 Delta Lake 誕生於不同公司，需要解決的問題存在差異，因此三者在設計初衷上稍有不同。
其中，Iceberg 的設計初衷更傾向於定義一個標準、開放且通用的數據組織格式，同時屏蔽底層數據存儲格式上的差異，向上提供統一的操作 API，使得不同的引擎可以通過其提供的 API 接入；Hudi 的設計初衷更像是為了解決流式數據的快速落地，並能夠通過 upsert 語義進行延遲數據修正；Delta Lake 作為 Databricks 開源的項目，更側重於在 Spark 層面上解決 Parquet、ORC 等存儲格式的固有問題，並帶來更多的能力提升。
雖然這三個項目在設計初衷上稍有不同，但實現的思路和提供的能力卻非常相似，他們都提供了 ACID 的能力，都基於樂觀鎖實現了衝突解決和提供線性一致性，同時相應地提供了 time travel 的功能。
但是因為設計初衷的不同，三個項目當前的能力象限各有不同，Iceberg 在其格式定義和核心能力上最為完善，但是上遊引擎的適配上稍顯不足；Hudi 基於 Spark 打造了完整的流式數據落地方案，但是其核心抽象較弱，與 Spark 耦合較緊；Delta Lake 同樣高度依賴於 Spark 生態圈，與其他引擎的適配尚需時日。不過邵賽賽認為，這三個項目現有的差異會隨著社區的推動和改進以及時間的累積慢慢磨平，最終可能會變得更趨於相同。
Apache Iceberg 在騰訊的採用情況
騰訊在 Iceberg 還未進入 Apache 孵化器時就已經開始關注，隨著這幾個技術的開源以及進入孵化器，這一領域開始逐漸升溫，從 2019 年下半年開始，騰訊正式在該技術上進行探索和投入。
為什麼選擇 Iceberg？
談及引入 Iceberg 的原因，邵賽賽表示，當時團隊在構建大數據生態的過程中遇到了幾個痛點，而 Iceberg 恰好能解決這幾個痛點：
T+0 的數據落地和處理。傳統的數據處理流程從數據入庫到數據處理通常需要一個較長的環節、涉及許多複雜的邏輯來保證數據的一致性，由於架構的複雜性使得整個流水線具有明顯的延遲。Iceberg 的 ACID 能力可以簡化整個流水線的設計，降低整個流水線的延遲。降低數據修正的成本。傳統 Hive/Spark 在修正數據時需要將數據讀取出來，修改後再寫入，有極大的修正成本。Iceberg 所具有的修改、刪除能力能夠有效地降低開銷，提升效率。至於為何最終選擇採用 Iceberg，而不是其他兩個開源項目，技術方面的考量主要有以下幾點：
Iceberg 的架構和實現並未綁定於某一特定引擎，它實現了通用的數據組織格式，利用此格式可以方便地與不同引擎（如 Flink、Hive、Spark）對接，這對於騰訊內部落地是非常重要的，因為上下遊數據管道的銜接往往涉及到不同的計算引擎；良好的架構和開放的格式。相比於 Hudi、Delta Lake，Iceberg 的架構實現更為優雅，同時對於數據格式、類型系統有完備的定義和可進化的設計；面向對象存儲的優化。Iceberg 在數據組織方式上充分考慮了對象存儲的特性，避免耗時的 listing 和 rename 操作，使其在基於對象存儲的數據湖架構適配上更有優勢。除去技術上的考量，邵賽賽和團隊也對代碼質量、社區等方面做了詳細的評估：
整體的代碼質量以及未來的進化能力。整體架構代碼上的抽象和優勢，以及這些優勢對於未來進行演化的能力是團隊非常關注的。一門技術需要能夠在架構上持續演化，而不會具體實現上需要大量的不兼容重構才能支持。社區的潛力以及騰訊能夠在社區發揮的價值。社區的活躍度是另一個考量，更重要的是在這個社區中騰訊能做些什麼，能發揮什麼樣的價值。如果社區相對封閉或已經足夠成熟，那麼騰訊再加入後能發揮的價值就沒有那麼大了，在選擇技術時這也是團隊的一個重要考量點。技術的中立性和開放性。社區能夠以開放的態度去推動技術的演化，而不是有所保留地向社區貢獻，同時社區各方相對中立而沒有一個相對的強勢方來完全控制社區的演進。優化和改進
從正式投入研發到現在，騰訊在開源版本的基礎上對 Iceberg 進行了一些優化和改進，主要包括：
實現了行級的刪除和更新操作，極大地節省了數據修正和刪除所帶來的開銷；對 Spark 3.0 的 DataSource V2 進行了適配，使用 Spark 3.0 的 SQL 和 DataFrame 可以無縫對接 Iceberg 進行操作；增加了對 Flink 的支持，可以對接 Flink 以 Iceberg 的格式進行數據落地。這些改進點提高了 Iceberg 在落地上的可用性，也為它在騰訊內部落地提供了更為吸引人的特性。同時騰訊也在積極擁抱社區，大部分的內部改進都已推往社區，一些內部定製化的需求也會以更為通用的方式貢獻回社區。
目前團隊正在積極嘗試將 Iceberg 融入到騰訊的大數據生態中，其中最主要的挑戰在於如何與騰訊現有系統以及自研系統適配，以及如何在一個成熟的大數據體系中尋找落地點並帶來明顯的收益。邵賽賽具體提到了以下幾點：
Iceberg 的上下遊配套能力的建設相對缺乏，需要較多的配套能力的建設，比如 Spark、Hive、Flink 等不同引擎的適配；其次是 Iceberg 核心能力成熟度的驗證，它是否能夠支撐起騰訊大數據量級的考驗，其所宣稱的能力是否真正達到了企業級可用，都需要進一步驗證和加強；最後，騰訊內部大數據經過多年發展，已經形成了一整套完整的數據接入分析方案，Iceberg 如何能夠在內部落地，優化現有的方案非常重要。Iceberg 的不足和未來
Iceberg 誕生的時間不長，雖然擁有高度抽象和非常優雅的設計，但功能上仍有不足，尤其在圍繞生態系統的建立和周邊能力的打造上還有很多工作需要做。邵賽賽認為，當前 Iceberg 最重要的缺失點是和上層引擎的對接。現在 Iceberg 和 Spark 的對接是最為完善的，但是由於 DataSource V2 API 仍在不斷地改進中，對於一些語義的下推仍然缺失，因此能力上和內置的存儲格式相比仍有欠缺（比如 bucket join 的支持）。而對於 Hive、Flink 的支持尚在開發中。因為 Iceberg 是一個統一的數據組織格式，想要全面使用的話必須使所有的上層引擎能夠對接適配，因此這一塊環節的補足是當前最為重要的。
其次，Iceberg 缺少行級更新、刪除能力。騰訊內部已經為 Iceberg 增加了行級更新、刪除的能力，但在 Iceberg 社區尚未有這樣的能力，這些能力所需的格式定義仍在設計中。行級更新、刪除能力是現有數據組織格式的最大賣點，因此該功能的補強對於 Iceberg 的推廣和落地十分重要。
在騰訊內部，後續對於 Iceberg 的規劃主要還是以適配不同的引擎以及優化核心能力為主，同時會圍繞 Iceberg 和上下遊的引擎提供端到端的面向終端用戶的數據管道能力。
目前相比於 Hudi、Delta Lake，Iceberg 在國內的關注度較少，這主要是由於其主要開發團隊在技術推廣和運營上面的工作偏少，而且 Iceberg 的開發者多為海外開發者，但是現在已經有越來越多大公司加入到了 Iceberg 的貢獻中，包括 Netflix、Apple、Adobe、Expedia 等國外大廠，也包括騰訊、阿里、網易等國內公司。邵賽賽非常看好 Iceberg 未來在國內發展的前景，在他看來，一個好的技術架構可能暫時不引人矚目，但最終還是會得到更多人的認可。隨著國內推廣的增多，以及國內開發者在這個項目上的投入、運營，未來在國內 Iceberg 前景可期。
關注我並轉發此篇文章，私信我「領取資料」，即可免費獲得InfoQ價值4999元迷你書！