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統一儲存。