https://blog.csdn.net/qq_19248065/article/details/103481123
1、Hudi簡介
Hudi是Hadoop Updates and Incrementals的縮寫，用於管理HDFS上的大型分析數據集存儲，主要目的是高效的減少入庫延時。
Hudi是一個開源Spark三方庫，支持在Hadoop上執行upserts/insert/delete操作。
Hudi數據集通過自定義的InputFormat與當前的Hadoop生態系統（Hive、parquet、spark）集成，使該框架對最終用戶來說是無縫的。
2、Hudi邏輯視圖
讀優化視圖：在列式存儲上提供出色的查詢性能，非常像parquet表
增量視圖：在數據集上提供一個變更流並提供給下游的作業和etl任務
準實時表：使用列存儲和行存儲以提供對實時數據的查詢
3、Hudi存儲引擎
Hudi將數據集組織到basePath下的分區目錄中，類似與傳統的hive表。數據集被分成分區，分區時包含該分區的數據文件的目錄。每個分區由其相對於basepath的partitionpath唯一標識。在每個分區中，記錄被分佈到多個數據文件中。每個數據文件都由唯一的field和生成該文件的commit標識。對於更新，多個數據文件可以共享同一個field，但對應於不同的commit。
每條記錄都由一個記錄鍵（record key）唯一標識，並映射到一個field。一旦記錄的第一個版本被寫入文件，記錄鍵和field之間的映射關係就永久不變。簡而言之，field標識一組文件，而這些文件包含所有記錄的所有版本數據。
Hudi的存儲引擎由三個不同的部分組成：
Metadata： Hudi以時間軸的形式將數據集上的各項操作對應的元數據維護起來，從而支持數據集的即時視圖，這部分元數據存儲於根目錄下的元數據目錄中。
Commits ：一個單獨的 commit 包含對數據集之上一批數據的一次原子寫入操作的相關信息。Commits 由單調遞增的時間戳標識，表示寫操作的開始；
Cleans：用於清除數據集中不再被查詢所用到的舊版本文件的後臺活動；
Compactions：協調 Hudi 中不同數據結構的後臺活動，比如將基於行更新的文件轉換成列式存儲格式。
Index： Hudi維護了一個索引，以便在記錄鍵已經存在的情況下快速地將傳入的記錄鍵映射到field，索引實現是可插拔的，以下是目前可用的選項：
BloomFilter：存儲在每個數據文件的頁腳中，默認就是用這個，因爲不依賴任何外部系統。數據和索引始終保持一致。
HBase：可高效的查找一小批key，在索引標記期間，這個索引實現可能會快幾秒
Data： Hudi以兩種不同的存儲格式存儲所有攝入的數據。但實際使用的存儲格式是可插拔的，但所選的存儲格式需要以下特徵：
掃描優化的列存儲格式，默認是parquet
寫優化的行格式，默認是avro
4、對比
Apache Hudi填補了在DFS上處理數據的巨大空白，並可以和這些技術很好地共存。然而， 通過將Hudi與一些相關係統進行對比，來了解Hudi如何適應當前的大數據生態系統，並知曉這些系統在設計中做的不同權衡仍將非常有用。
1、Kudu
Apache Kudu是一個與Hudi具有相似目標的存儲系統，該系統通過對upserts支持來對PB級數據進行實時分析。 一個關鍵的區別是Kudu還試圖充當OLTP工作負載的數據存儲，而Hudi並不希望這樣做。 因此，Kudu不支持增量拉取(截至2017年初)，而Hudi支持以便進行增量處理。
Kudu與分佈式文件系統抽象和HDFS完全不同，它自己的一組存儲服務器通過RAFT相互通信。 與之不同的是，Hudi旨在與底層Hadoop兼容的文件系統(HDFS，S3或Ceph)一起使用，並且沒有自己的存儲服務器羣，而是依靠Apache Spark來完成繁重的工作。 因此，Hudi可以像其他Spark作業一樣輕鬆擴展，而Kudu則需要硬件和運營支持，特別是HBase或Vertica等數據存儲系統。 到目前爲止，我們還沒有做任何直接的基準測試來比較Kudu和Hudi(鑑於RTTable正在進行中)。 但是，如果我們要使用CERN， 我們預期Hudi在攝取parquet上有更卓越的性能。
2、Hive事務
Hive事務/ACID是另一項類似的工作，它試圖實現在ORC文件格式之上的存儲讀取時合併。 可以理解，此功能與Hive以及LLAP之類的其他工作緊密相關。 Hive事務不提供Hudi提供的讀取優化存儲選項或增量拉取。 在實現選擇方面，Hudi充分利用了類似Spark的處理框架的功能，而Hive事務特性則在用戶或Hive Metastore啓動的Hive任務/查詢的下實現。 根據我們的生產經驗，與其他方法相比，將Hudi作爲庫嵌入到現有的Spark管道中要容易得多，並且操作不會太繁瑣。 Hudi還設計用於與Presto/Spark等非Hive引擎合作，並計劃引入除parquet以外的文件格式。
3、HBase
儘管HBase最終是OLTP工作負載的鍵值存儲層，但由於與Hadoop的相似性，用戶通常傾向於將HBase與分析相關聯。 鑑於HBase經過嚴格的寫優化，它支持開箱即用的亞秒級更新，Hive-on-HBase允許用戶查詢該數據。 但是，就分析工作負載的實際性能而言，Parquet/ORC之類的混合列式存儲格式可以輕鬆擊敗HBase，因爲這些工作負載主要是讀取繁重的工作。 Hudi彌補了更快的數據與分析存儲格式之間的差距。從運營的角度來看，與管理分析使用的HBase region服務器集羣相比，爲用戶提供可更快給出數據的庫更具可擴展性。 最終，HBase不像Hudi這樣重點支持提交時間、增量拉取之類的增量處理原語。
4、流式處理
一個普遍的問題：”Hudi與流處理系統有何關係？”，我們將在這裏嘗試回答。簡而言之，Hudi可以與當今的批處理(寫時複製存儲)和流處理(讀時合併存儲)作業集成，以將計算結果存儲在Hadoop中。 對於Spark應用程序，這可以通過將Hudi庫與Spark/Spark流式DAG直接集成來實現。在非Spark處理系統(例如Flink、Hive)情況下，可以在相應的系統中進行處理，然後通過Kafka主題/DFS中間文件將其發送到Hudi表中。從概念上講，數據處理 管道僅由三個部分組成：輸入，處理，輸出，用戶最終針對輸出運行查詢以便使用管道的結果。Hudi可以充當將數據存儲在DFS上的輸入或輸出。Hudi在給定流處理管道上的適用性最終歸結爲你的查詢在Presto/SparkSQL/Hive的適用性。
更高級的用例圍繞增量處理的概念展開， 甚至在處理引擎內部也使用Hudi來加速典型的批處理管道。例如：Hudi可用作DAG內的狀態存儲(類似Flink使用的[rocksDB(https://ci.apache.org/projects/flink/flink-docs-release-1.2/ops/state_backends.html#the-rocksdbstatebackend))。 這是路線圖上的一個項目並將最終以Beam Runner的形式呈現。
參考文獻：
https://www.iteblog.com/archives/9660.html
http://hudi.apache.org/cn/comparison.html