歡迎關注公眾號：ApacheHudi
1. ApacheHudi對個人和組織何時有用
如果你希望將數據快速提取到HDFS或雲存儲中，Hudi可以提供幫助。另外，如果你的ETL /hive/spark作業很慢或占用大量資源，那么Hudi可以通過提供一種增量式讀取和寫入數據的方法來提供幫助。
作為一個組織，Hudi可以幫助你構建高效的數據湖，解決一些最復雜的底層存儲管理問題，同時將數據更快地交給數據分析師，工程師和科學家。
2. Hudi不打算達成的目標
Hudi不是針對任何OLTP案例而設計的，在這些情況下，通常你使用的是現有的NoSQL / RDBMS數據存儲。Hudi無法替代你的內存分析數據庫（至少現在還沒有！）。Hudi支持在幾分鍾內實現近乎實時的攝取，從而權衡了延遲以進行有效的批處理。如果確實希望亞-分鍾處理延遲，請使用你最喜歡的流處理解決方案。
3. 什么是增量處理？ 為什么Hudi一直在談論它
增量處理是由Vinoth Chandar在O'reilly博客中首次引入的，博客中闡述了大部分工作。用純粹的技術術語來說，增量處理僅是指以流處理方式編寫微型批處理程序。典型的批處理作業每隔幾個小時就會消費所有輸入並重新計算所有輸出。典型的流處理作業會連續/每隔幾秒鍾消費一些新的輸入並重新計算新的/更改以輸出。盡管以批處理方式重新計算所有輸出可能會更簡單，但這很浪費並且耗費昂貴的資源。Hudi具有以流方式編寫相同批處理管道的能力，每隔幾分鍾運行一次。
雖然可將其稱為流處理，但我們更願意稱其為增量處理，以區別於使用Apache Flink，Apache Apex或Apache Kafka Streams構建的純流處理管道。
4. 寫時復制（COW）與讀時合並（MOR）存儲類型之間有什么區別
寫時復制（Copy On Write）：此存儲類型使客戶端能夠以列式文件格式（當前為parquet）攝取數據。使用COW存儲類型時，任何寫入Hudi數據集的新數據都將寫入新的parquet文件。更新現有的行將導致重寫整個parquet文件（這些parquet文件包含要更新的受影響的行）。因此，所有對此類數據集的寫入都受parquet寫性能的限制，parquet文件越大，攝取數據所花費的時間就越長。
讀時合並（Merge On Read）：此存儲類型使客戶端可以快速將數據攝取為基於行（如avro）的數據格式。使用MOR存儲類型時，任何寫入Hudi數據集的新數據都將寫入新的日志/增量文件，這些文件在內部將數據以avro進行編碼。壓縮（Compaction）過程（配置為嵌入式或異步）將日志文件格式轉換為列式文件格式（parquet）。
兩種不同的格式提供了兩種不同視圖（讀優化視圖和實時視圖），讀優化視圖取決於列式parquet文件的讀取性能，而實時視圖取決於列式和/或日志文件的讀取性能。
更新現有的行將導致：a）寫入從以前通過壓縮（Compaction）生成的基礎parquet文件對應的日志/增量文件更新；或b）在未進行壓縮的情況下寫入日志/增量文件的更新。因此，對此類數據集的所有寫入均受avro /日志文件寫入性能的限制，其速度比parquet快得多（寫入時需要復制）。雖然，與列式（parquet）文件相比，讀取日志/增量文件需要更高的成本（讀取時需要合並）。
點擊此處了解更多。
5. 如何為工作負載選擇存儲類型
Hudi的主要目標是提供更新功能，該功能比重寫整個表或分區要快幾個數量級。
如果滿足以下條件，則選擇寫時復制（COW）存儲：
- 尋找一種簡單的替換現有的parquet表的方法，而無需實時數據。
- 當前的工作流是重寫整個表/分區以處理更新，而每個分區中實際上只有幾個文件發生更改。
- 想使操作更為簡單（無需壓縮等），並且攝取/寫入性能僅受parquet文件大小以及受更新影響文件數量限制
- 工作流很簡單，並且不會突然爆發大量更新或插入到較舊的分區。COW寫入時付出了合並成本，因此，這些突然的更改可能會阻塞攝取，並干擾正常攝取延遲目標。
如果滿足以下條件，則選擇讀時合並（MOR）存儲：
- 希望數據盡快被攝取並盡可能快地可被查詢。
- 工作負載可能會突然出現模式的峰值/變化（例如，對上游數據庫中較舊事務的批量更新導致對DFS上舊分區的大量更新）。異步壓縮（Compaction）有助於緩解由這種情況引起的寫放大，而正常的提取則需跟上上游流的變化。
不管選擇何種存儲，Hudi都將提供：
- 快照隔離和原子寫入批量記錄
- 增量拉取
- 重復數據刪除能力
點擊此處了解更多
6. Hudi是分析型數據庫嗎
典型的數據庫有一些長時間運行的服務器，以便提供讀寫服務。Hudi的體系結構與之不同，它高度解耦讀寫，為對應擴容挑戰可以獨立擴展寫入和查詢/讀取。因此，它可能並不總是像數據庫一樣。
盡管如此，Hudi的設計非常像數據庫，並提供類似的功能（更新，更改捕獲）和語義（事務性寫入，快照隔離讀取）。
7. 如何對存儲在Hudi中的數據建模
在將數據寫入Hudi時，可以像在鍵-值存儲上那樣對記錄進行建模：指定鍵字段（對於單個分區/整個數據集是唯一的），分區字段（表示要放置鍵的分區）和preCombine/combine邏輯（用於指定如何處理一批寫入記錄中的重復記錄）。該模型使Hudi可以強制執行主鍵約束，就像在數據庫表上一樣。請參閱此處的示例。
當查詢/讀取數據時，Hudi只是將自己顯示為一個類似於json的層次表，每個人都習慣於使用Hive/Spark/Presto 來對Parquet/Json/Avro進行查詢。
8. Hudi是否支持雲存儲/對象存儲
一般來說，Hudi能夠在任何Hadoop文件系統實現上提供該功能，因此可以在Cloud Store（Amazon S3或Microsoft Azure或Google Cloud Storage）上讀寫數據集。Hudi還進行了特定的設計，使在雲上構建Hudi數據集變得非常容易，例如S3的一致性檢查，數據文件涉及的零移動/重命名。
9. Hudi支持Hive/Spark/Hadoop的哪些版本
從2019年9月開始，Hudi可以支持Spark 2.1 +，Hive 2.x，Hadoop 2.7+（非Hadoop 3）。
10. Hudi如何在數據集中實際存儲數據
從更高層次上講，Hudi基於MVCC設計，將數據寫入parquet/基本文件以及包含對基本文件所做更改的日志文件的不同版本。所有文件都以數據集的分區模式存儲，這與Apache Hive表在DFS上的布局方式非常相似。請參考這里了解更多詳情。
