目錄

• Kudu、Hudi和Delta Lake的比較
  • 存儲機制
  • 讀數(shù)據(jù)
  • 更新數(shù)據(jù)
  • 其他
  • 如何選擇合適的存儲方案

Kudu声滥、Hudi和Delta Lake的比較

kudu、hudi和delta lake是目前比較熱門的支持行級別數(shù)據(jù)增刪改查的存儲方案确徙，本文對三者之間進行了比較醒串。

存儲機制

kudu

kudu的存儲機制和hudi的寫優(yōu)化方式有些相似。

kudu的最新數(shù)據(jù)保存在內存鄙皇，稱為MemRowSet（行式存儲芜赌，基于primary key有序），
當MemRowSet寫滿（默認1G或者120s）后flush到磁盤伴逸，形成DiskRowSet（列式存儲）缠沈。

DiskRowSet包含baseData與DeltaStores兩部分，DeltaStores包含一個DeltMemStore和多個DeltaFile错蝴，
后續(xù)的更新數(shù)據(jù)存放在DeltMemStore中洲愤，增長到一定程度后flush成DeltaFile文件。

kudu會定期執(zhí)行compaction操作顷锰，將DeltaFile中的更新合并到DiskRowSet柬赐，或者合并DiskRowSet，清除已刪除的數(shù)據(jù)官紫，并減少DiskRowSet的數(shù)量肛宋。

hudi

hudi維護了一個時間軸，記錄了在不同時刻對數(shù)據(jù)集進行的所有操作束世。

hudi擁有2種存儲優(yōu)化酝陈，讀優(yōu)化適合讀多寫少的場景，寫優(yōu)化適合讀少寫多的場景毁涉。

• 讀優(yōu)化（Copy On Write）：在每次commit后都將最新的數(shù)據(jù)compaction成列式存儲（parquet）沉帮；

• 寫優(yōu)化（Merge On Read）：對增量數(shù)據(jù)使用行式存儲（avro），后臺定期將它compaction成列式存儲贫堰。

delta lake

delta lake的存儲機制和hudi的讀優(yōu)化方式相似穆壕。

delta lake的數(shù)據(jù)不會保存在內存中，而是直接寫到新的數(shù)據(jù)文件中（parquet格式）其屏，同時在commit log中添加AddFile這種FileAction粱檀，快照新建/更新時讀取事務日志，會加載新的數(shù)據(jù)文件信息漫玄。

讀數(shù)據(jù)

kudu

先根據(jù)要掃描數(shù)據(jù)的主鍵范圍，定位到目標的tablets，然后讀取tablets中的DiskRowSet睦优。

在讀取每個DiskRowSet時渗常，先根據(jù)主鍵過濾要scan的范圍，然后加載范圍內的baseData汗盘，再找到對應的DeltaStores皱碘，
應用所有變更，最后union上MemRowSet中的內容隐孽，最后返回數(shù)據(jù)給client癌椿。

kudu提供range分區(qū)和hash分區(qū)兩種分區(qū)方式，通過多種索引（主鍵范圍索引菱阵、bloomfilter踢俄、主鍵索引），支持隨機讀取數(shù)據(jù)和高效的批量讀取數(shù)據(jù)晴及。

hudi

hudi也維護著一個索引都办，以此將key快速映射到對應的fileId。索引的實現(xiàn)是插件式的虑稼，默認是bloomFilter琳钉，也可以使用HBase。

hudi提供3種查詢視圖蛛倦。

• 讀優(yōu)化視圖：僅提供compaction后的列式存儲的數(shù)據(jù)歌懒；

• 增量視圖：僅提供一次compaction/commit前的增量數(shù)據(jù)；

• 實時視圖：包括列式存儲數(shù)據(jù)和寫優(yōu)化的行式存儲數(shù)據(jù)溯壶。

delta lake

通過讀取事務日志的checkpoint文件（parquet格式）和之后版本的commit文件（json格式）及皂，
建立當前最新的快照，該快照包含了當前版本所有數(shù)據(jù)文件的地址茸塞，然后使用spark讀取數(shù)據(jù)躲庄。

更新數(shù)據(jù)

kudu

client向master發(fā)出請求，通過索引定位到具體的tablet钾虐，然后根據(jù)元數(shù)據(jù)連接tablet對應的tserver噪窘。

若數(shù)據(jù)在磁盤（DiskRowSet）上，則將更新信息寫入DeltMemStore中效扫，若數(shù)據(jù)在內存（MemRowSet）中倔监，則將信息寫入所在行的mutation鏈表中。

hudi

hudi沒有傳統(tǒng)意義的更新菌仁，只有append和重寫浩习。

hudi寫數(shù)據(jù)的時候需要指定以下3個key。

• RECORDKEY_FIELD_OPT_KEY：每條記錄的唯一id济丘，支持多個字段谱秽；

• PRECOMBINE_FIELD_OPT_KEY：在數(shù)據(jù)合并的時候使用到洽蛀，當RECORDKEY_FIELD_OPT_KEY相同時，默認取PRECOMBINE_FIELD_OPT_KEY屬性配置的字段最大值所對應的行疟赊；

• PARTITIONPATH_FIELD_OPT_KEY：用于存放數(shù)據(jù)的分區(qū)字段郊供。

hudi更新數(shù)據(jù)和插入數(shù)據(jù)很相似（寫法幾乎一樣），更新數(shù)據(jù)時近哟，會根據(jù)以上三個字段對數(shù)據(jù)進行Merge驮审。

delta lake

delta lake更新數(shù)據(jù)時會先定位待更新數(shù)據(jù)所在的文件，使用spark join獲得結果數(shù)據(jù)集吉执，將更新后的數(shù)據(jù)和文件中其他不需要更新的數(shù)據(jù)一起寫入到新的文件里疯淫，同時在commit log中記錄AddFile（新文件）和RemoveFile（舊文件）兩種action。

其他

如何選擇合適的存儲方案

kudu

1. 不同于hudi和delta lake是作為數(shù)據(jù)湖的存儲方案固额，kudu設計的初衷是作為hive和hbase的折中眠蚂，因此它同時具有隨機讀寫和批量分析的特性。

2. kudu允許對不同列使用單獨的編碼和壓縮格式斗躏，擁有強大的索引支持逝慧，搭配range分區(qū)和hash分區(qū)的合理劃分，
   對分區(qū)查看啄糙、擴容和數(shù)據(jù)高可用性的支持都非常好笛臣，適用于既有隨機訪問，也有批量數(shù)據(jù)掃描的復合場景隧饼。

3. kudu可以和impala沈堡、spark集成，支持sql操作燕雁，除此之外诞丽，kudu能夠充分發(fā)揮高性能存儲設備的優(yōu)勢鲸拥。

4. 相比較其他兩者，kudu不支持云存儲率拒，也不支持版本回滾和增量處理崩泡。

hudi

1. hudi的產生背景是為了解決Uber的增量更新問題，它提供了豐富的視圖和存儲優(yōu)化方式猬膨，
   可以適配批量訪問場景，增量處理場景呛伴，以及近實時查詢場景勃痴，無論是讀多寫少還是讀少寫多，hudi都能提供對應的優(yōu)化方案热康，
   用戶可以根據(jù)自身場景靈活選擇合適的配置沛申。

2. 三者之中，hudi的兼容性最好姐军，它原生支持spark铁材、presto、hive和mapreduce等大數(shù)據(jù)生態(tài)系統(tǒng)奕锌，并且讀寫底層文件實現(xiàn)了自己的InputFormat著觉，更容易與其它系統(tǒng)做兼容。

3. hudi目前還不支持通過sql操作數(shù)據(jù)惊暴，（19年12月）社區(qū)已經將其作為下一步的方向饼丘，但完成時間不確定。

4. hudi不存在鎖機制辽话，因此不支持多客戶端同時寫一張表肄鸽，這是需要注意的一點。

delta lake

1. delta lake深度綁定spark油啤，支持版本回滾典徘，在寫入的時候對數(shù)據(jù)進行合并，因此對讀取比較友好益咬。

2. delta lake有樂觀鎖機制逮诲，允許并發(fā)寫操作。但目前源碼中對沖突檢測很嚴格础废，對多用戶同時更新的場景支持并不好汛骂，適用于寫少讀多（或者only append寫多更新少）的場景。

3. delta lake開源版目前基本不支持sql操作數(shù)據(jù)（0.5版本支持hive和presto讀數(shù)據(jù)）评腺，應該在spark3.0發(fā)布后才會支持delete帘瞭、update和merge操作。

4. 開源版目前還存在小文件合并問題（商業(yè)版有優(yōu)化蒿讥，但是因為涉及到Databricks的Runtime功能蝶念，所以不準備開源抛腕，因此得自己手動合并小文件）。

5. 總體來說媒殉，delta lake是一個較為優(yōu)秀的數(shù)據(jù)湖存儲方案担敌，但直接使用開源版本還需要用戶稍微進行一些針對性的優(yōu)化。

轉自: https://www.cnblogs.com/kehanc/p/12153409.html