隨着大數據存儲和處理需求越來越多樣化，如何構建一個統一的數據湖存儲，並在其上進行多種形式的數據分析，成了企業構建大數據生態的一個重要方向。如何快速、一致、原子性地在數據湖存儲上構建起 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前景可期。
延伸閱讀：
深度對比delta、iceberg和hudi三大開源數據湖方案
嘉賓介紹：
邵賽賽，騰訊數據平臺部數據湖內核技術負責人，資深大數據工程師，Apache Spark PMC member & committer, Apache Livy PMC member，曾就職於 Hortonworks，Intel 。
在QCon北京2020的分享中，邵賽賽老師將詳細介紹Iceberg的設計初衷、優點和能力，讓你對錶格式這一領域有充分的瞭解，點擊瞭解詳情。
