背景

我們已經看到，人們更熱衷于高效可靠的解決方案，擁有為數據湖提供應對突變和事務處理的能力。在數據湖中，用戶基于一組數據生成報告是非常常見的。隨著各種類型的數據匯入數據湖，數據的狀態不會一層不變。需要改變各種數據的用例包括隨時間變化的時序數據、延遲到達的時延數據、平衡實時可用性和回填、狀態變化的數據（如CDC）、數據快照、數據清理等，在生成報告時，這些都將被寫入/更新在同一組表。

由于Hadoop分布式文件系統（HDFS）和對象存儲類似于文件系統，因此它們不是為提供事務支持而設計的。在分布式處理環境中實現事務是一個具有挑戰性的問題。例如，日常考慮到鎖定對存儲系統的訪問，這會以犧牲整體吞吐量性能為代價。像Apache CarbonData、OpenDelta Lake、Apache Hudi等存儲解決方案，通過將這些事務語義和規則推送到文件格式本身或元數據和文件格式組合中，有效地解決了數據湖的ACID需求。

很多用戶看到這三種主要解決方案時，將陷入兩難的境地，在不同情況下不知怎么選擇？今天我們對比了三大方案，幫助用戶更好的根據自己的場景選擇解決方案。

Apache Hudi

Apache Hudi是Uber為滿足內部數據分析需求而設計的項目?？焖賣psert/delete和compaction功能可以解決許多實時用例。該項目在Apache社區非?；钴S，2020年4月取得了最高項目地位。

從Hudi的名字就能看出他的設計目標， Hadoop Upserts Deletes and Incrementals，主要支持Upserts、Deletes和增量數據處理。其關鍵特性如下：

1.文件管理

Hudi在DFS上將表組織為basepath下的目錄結構。表被劃分為分區，這些分區是包含該分區的數據文件的文件夾，類似于Hive表。

2.索引

Hudi通過索引機制將給定的HoodieKey（記錄鍵+分區路徑）一致地映射到文件id，從而提供高效的upserts。

3.表類型

Hudi支持的表類型如下：

• 寫入時復制：使用專有的列文件格式（如parquet）存儲數據。在寫入時執行同步合并，只需更新版本并重寫文件。
• 讀取時合并：使用列（如parquet） +行（如Avro）文件格式的組合存儲數據。更新記錄到增量文件，并隨后壓縮以同步或異步生成列文件的新版本。

4.查詢類型

Hudi支持三種查詢類型：

• 快照查詢：查詢是在給定的提交或壓縮操作之后對表進行快照的請求。利用快照查詢時，copy-on-write表類型僅公開最新文件切片中的基/列文件，并保證相同的列查詢性能。
• 增量查詢：對于寫入時復制表，增量查詢提供自給定提交或壓縮后寫入表的新數據，提供更改流以啟用增量數據管道。
• 讀取優化查詢：查詢查看指定提交/壓縮操作后表的最新快照。只暴露最新文件版本的base/columnar文件，保證列查詢性能與非Hudi列表相同。僅在讀取表合并時支持

5.Hudi工具

Hudi由不同的工具組成，用于將不同數據源的數據快速采集到HDFS，作為Hudi建模表，并與Hive元存儲進一步同步。工具包括：DeltaStreamer、Hoodie-Spark的Datasource API、HiveSyncTool、HiveIncremental puller。

Apache CarbonData

Apache CarbonData是三個產品中最早的，由華為貢獻給社區，助力華為云產品的數據平臺和數據湖解決方案應對PB級負載。這是一個雄心勃勃的項目，將許多能力都集中在一個項目中。除了支持更新、刪除、合并操作、流式采集外，它還擁有大量高級功能，如時間序列、物化視圖的數據映射、二級索引，并且還被集成到多個AI平臺，如Tensorflow。

CarbonData沒有 HoodieKey 設計，不強調主鍵。更新/刪除/合并等操作通過優化的粒度連接實現。CarbonData與Spark緊密集成，在CarbonData層中有很多優化，比如數據跳躍、下推等。在查詢方面，CarbonData支持Spark、Hive、Flink、TensorFlow、pyTorch和Presto。一些關鍵特性包括：

1.查詢加速

諸如多級索引、壓縮和編碼技術等優化旨在提高分析查詢的性能，這些查詢可能包括過濾器、聚合和用戶期望PB級數據的點查詢響應時間亞秒級。高級下推優化與Spark深度集成，確保計算在靠近數據處執行，以最小化數據讀取、處理、轉換和傳輸的數量。

2.ACID：數據一致性

沒有關于故障的中間數據，按快照隔離工作，分離讀取和寫入。對數據（查詢、IUD【插入更新刪除】、索引、數據映射、流式處理）的每個操作均符合ACID標準。支持使用基于列和行的格式進行近實時分析，以平衡分析性能和流式采集以及自動切換。

3.一份數據

通過集成Spark、Hive、Presto、Flink、Tensorflow、Pytorch等多種引擎。數據湖解決方案現在可以保留一個數據副本。

4.各種優化指標

其他索引，如二級索引、Bloom、Lucene、Geo-Spatial、實體化視圖，可以加速點、文本、聚合、時間序列和Geo空間查詢。通過Polygon UDF，CarbonData支持地理空間數據模型。

5.更新和刪除

支持合并、更新和刪除操作，以啟用諸如更改-數據-捕獲、緩慢更改-維（SCD-2）操作等復雜用例。

6.高擴展性

Scale存儲和處理分離，也適用于云架構。分布式索引服務器可以與查詢引擎（如spark, presto）一起啟動，以避免跨運行重新加載索引，并實現更快和可擴展的查找。

Delta【開源】

Delta Lake項目于2019年通過Apache License開放源碼，是Databricks解決方案的重要組成部分。Delta定位為數據湖存儲層，集成流式和批處理，支持更新/刪除/合并。為Apache Spark和大數據工作負載提供ACID事務能力。一些關鍵特性包括：

1.ACID事務

Delta Lake將ACID事務帶到您的數據湖中。Delta Lake存儲一個事務日志，以跟蹤對表目錄所做的所有提交，以提供ACID事務。它提供可串行化的隔離級別，確保數據在多個用戶之間的一致性。

2.方案管理與執行

Delta Lake利用Spark分布式處理能力處理所有元數據，通過提供指定模式和幫助實施模式的能力，避免不良數據進入數據湖。它通過提供合理的錯誤消息來防止不良數據進入系統，甚至在數據被集成到數據湖之前就進入系統，從而防止數據損壞。

3.數據版本控制和時間旅行

將對數據湖中的數據進行版本控制，并提供快照，以便您可以像該快照是系統當前狀態一樣查詢它們。這有助于我們恢復到舊版本的數據湖中進行審計、回滾和類似的操作。

4.開放格式

Delta Lake 中的所有數據都以Apache Parquet格式存儲，使得Delta Lake能夠利用Parquet本地的高效壓縮和編碼方案。

5.統一的批量流式sink

近似實時分析。Delta Lake中的表既是一個批處理表，也是流源和sink，為Lambda架構提供了一個解決方案，但又向前邁進了一步，因為批處理和實時數據都下沉在同一個sink中。

與CarbonData類似，Delta不強調主鍵，因此更新/刪除/合并都是基于spark的連接函數實現的。在數據寫入方面，Delta和Spark是強綁定關系。與Spark的深度集成可能是最好的特性，事實上，它是唯一一個具有Spark SQL特定命令（例如：MERGE），它還引入了有用的DML，如直接在Spark中更新WHERE或DELETE WHERE。Delta Lake不支持真正的數據血緣關系（即跟蹤數據何時以及如何在Delta Lake中復制數據的能力），但是有審計和版本控制（在元數據中存儲舊模式）。

最后

Hudi在IUD性能和讀取合并等功能方面具有競爭優勢。例如，如果您想知道是否要與Flink流一起使用，那么它目前不是為這樣的用例設計的。Hudi Delta Streamer支持流式數據采集。這里的“流式處理”實際上是一個連續的批處理周期。但從本質上講，這仍不是一種存粹的流式的采集。該社區由Uber提供，并已開放其所有功能。

Delta的主要優勢之一是它能夠與Spark集成，特別是其流批一體化設計。Delta擁有良好的用戶API和文檔。該社區由Databricks提供，它擁有一個具有附加功能的商用版本。

CarbonData是市場上最早的產品，由于物化視圖、二級索引等先進的索引，它具有一定的競爭優勢，并被集成到各種流/AI引擎中，如Flink、TensorFlow，以及Spark、Presto和Hive。社區由華為提供，所有特性均已開源。

隨著新版的發布，這三個都在不斷填補他們缺失的能力，并可能在未來相互融合或競爭。當然，也可以把重點放在自己的情景上，構建自身優勢的門檻。對這些解決方案進行性能比較有助于更好地了解它們的產品。因此，勝負仍是未知之數。

下表從多個維度總結了這三者。需要注意的是，本表所列能力僅突出2020年8月底的能力。

特性對比表

社區現狀（截至2020年8月）