Apache Hudi典型應用場景有哪些

這篇文章將為大家詳細講解有關Apache Hudi典型應用場景有哪些，文章內容質量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關知識有一定的了解。

1.近實時攝取

將數據從外部源如事件日志、數據庫提取到Hadoop數據湖 中是一個很常見的問題。在大多數Hadoop部署中，一般使用混合提取工具并以零散的方式解決該問題，盡管這些數據對組織是非常有價值的。

對于RDBMS攝取，Hudi通過Upserts提供了更快的負載，而非昂貴且低效的批量負載。例如你可以讀取MySQL binlog日志或Sqoop增量導入，并將它們應用在DFS上的Hudi表，這比批量合并作業或復雜的手工合并工作流更快/更高效。

對于像Cassandra / Voldemort / HBase這樣的NoSQL數據庫，即使規模集群不大也可以存儲數十億行數據，此時進行批量加載則完全不可行，需要采用更有效的方法使得攝取速度與較頻繁的更新數據量相匹配。

即使對于像Kafka這樣的不可變數據源，Hudi也會強制在DFS上保持最小文件大小，從而解決Hadoop領域中的古老問題以便改善NameNode的運行狀況。這對于事件流尤為重要，因為事件流（例如單擊流）通常較大，如果管理不善，可能會嚴重損害Hadoop集群性能。

對于所有數據源，Hudi都提供了通過提交將新數據原子化地發布給消費者，從而避免部分提取失敗。

2. 近實時分析

通常實時數據集市由專門的分析存儲，如Druid、Memsql甚至OpenTSDB提供支持。這對于需要亞秒級查詢響應（例如系統監視或交互式實時分析）的較小規模（相對于安裝Hadoop）數據而言是非常完美的選擇。但由于Hadoop上的數據令人難以忍受，因此這些系統通常最終會被較少的交互查詢所濫用，從而導致利用率不足和硬件/許可證成本的浪費。

另一方面，Hadoop上的交互式SQL解決方案（如Presto和SparkSQL），能在幾秒鐘內完成的查詢。通過將數據的更新時間縮短至幾分鐘，Hudi提供了一種高效的替代方案，并且還可以對存儲在DFS上多個更大的表進行實時分析。此外，Hudi沒有外部依賴項（例如專用于實時分析的專用HBase群集），因此可以在不增加運營成本的情況下，對更實時的數據進行更快的分析。

3. 增量處理管道

Hadoop提供的一項基本功能是構建基于表的派生鏈，并通過DAG表示整個工作流。工作流通常取決于多個上游工作流輸出的新數據，傳統上新生成的DFS文件夾/Hive分區表示新數據可用。例如上游工作流 U可以每小時創建一個Hive分區，并在每小時的末尾（ processing_time）包含該小時（ event_time）的數據，從而提供1小時的數據新鮮度。然后下游工作流 D在 U完成后立即開始，并在接下來的一個小時進行處理，從而將延遲增加到2個小時。

上述示例忽略了延遲到達的數據，即 processing_time和 event_time分開的情況。不幸的是在后移動和物聯網前的時代，數據延遲到達是非常常見的情況。在這種情況下，保證正確性的唯一方法是每小時重復處理最后幾個小時的數據，這會嚴重損害整個生態系統的效率。想象下在數百個工作流中每小時重新處理TB級別的數據。

Hudi可以很好的解決上述問題，其通過記錄粒度（而非文件夾或分區）來消費上游Hudi表 HU中的新數據，下游的Hudi表 HD應用處理邏輯并更新/協調延遲數據，這里 HU和 HD可以以更頻繁的時間（例如15分鐘）連續進行調度，并在 HD上提供30分鐘的端到端延遲。

為了實現這一目標，Hudi從流處理框架如Spark Streaming、發布/訂閱系統如Kafka或數據庫復制技術如Oracle XStream中引入了類似概念。若感興趣可以在此處找到有關增量處理（與流處理和批處理相比）更多優勢的更詳細說明。

4. DFS上數據分發

Hadoop的經典應用是處理數據，然后將其分發到在線存儲以供應用程序使用。例如使用Spark Pipeline將Hadoop的數據導入到ElasticSearch供Uber應用程序使用。一種典型的架構是在Hadoop和服務存儲之間使用 隊列進行解耦，以防止壓垮目標服務存儲，一般會選擇Kafka作為隊列，該架構會導致相同數據冗余存儲在DFS（用于對計算結果進行離線分析）和Kafka（用于分發）上。

Hudi可以通過以下方式再次有效地解決此問題：將Spark Pipeline 插入更新輸出到Hudi表，然后對表進行增量讀取（就像Kafka主題一樣）以獲取新數據并寫入服務存儲中，即使用Hudi統一存儲。

關于Apache Hudi典型應用場景有哪些就分享到這里了，希望以上內容可以對大家有一定的幫助，可以學到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。