ApacheHudi常見問題都有哪些

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上的布局方式非常相似。

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。