## 1.近實時攝取 將資料從外部源如事件日誌、資料庫提取到[Hadoop資料湖](http://martinfowler.com/bliki/DataLake.html) 中是一個很常見的問題。在大多數Hadoop部署中，一般使用混合提取工具並以零散的方式解決該問題，儘管這些資料對組織是非常有價值的。 對於RDBMS攝取，Hudi通過Upserts提供了更快的負載，而非昂貴且低效的批量負載。例如你可以讀取MySQL binlog日誌或[Sqoop增量匯入](https://sqoop.apache.org/docs/1.4.2/SqoopUserGuide.html#_incremental_imports)，並將它們應用在DFS上的Hudi表，這比[批量合併作業](https://sqoop.apache.org/docs/1.4.0-incubating/SqoopUserGuide.html#id1770457)或[複雜的手工合併工作流](http://hortonworks.com/blog/four-step-strategy-incremental-updates-hive/)更快/更高效。 對於像[Cassandra](http://cassandra.apache.org/) / [Voldemort](http://www.project-voldemort.com/voldemort/) / [HBase](https://hbase.apache.org/)這樣的NoSQL資料庫，即使規模叢集不大也可以儲存數十億行資料，此時進行批量載入則完全不可行，需要採用更有效的方法使得攝取速度與較頻繁的更新資料量相匹配。 即使對於像[Kafka](https://kafka.apache.org/)這樣的不可變資料來源，Hudi也會強制在DFS上保持最小檔案大小，從而解決Hadoop領域中的[古老問題](https://blog.cloudera.com/blog/2009/02/the-small-files-problem/)以便改善NameNode的執行狀況。這對於事件流尤為重要，因為事件流（例如單擊流）通常較大，如果管理不善，可能會嚴重損害Hadoop叢集效能。 對於所有資料來源，Hudi都提供了通過提交將新資料原子化地釋出給消費者，從而避免部分提取失敗。 ## 2. 近實時分析 通常實時[資料集市](https://en.wikipedia.org/wiki/Data_mart)由專門的分析儲存，如[Druid](http://druid.io/)、[Memsql](http://www.memsql.com/)甚至[OpenTSDB](http://opentsdb.net/)提供支援。這對於需要亞秒級查詢響應（例如系統監視或互動式實時分析）的較小規模（[相對於安裝Hadoop](https://blog.twitter.com/2015/hadoop-filesystem-at-twitter)）資料而言是非常完美的選擇。但由於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`分開的情況。不幸的是在後移動和物聯網前的時代，資料延遲到達是非常常見的情況。在這種情況下，保證正確性的唯一方法是每小時重複處理[最後幾個小時](https://falcon.apache.org/FalconDocumentation.html#Handling_late_input_data)的資料，這會嚴重損害整個生態系統的效率。想象下在數百個工作流中每小時重新處理TB級別的資料。 Hudi可以很好的解決上述問題，其通過記錄粒度（而非資料夾或分割槽）來消費上游Hudi表`HU`中的新資料，下游的Hudi表`HD`應用處理邏輯並更新/協調延遲資料，這裡`HU`和`HD`可以以更頻繁的時間（例如15分鐘）連續進行排程，並在`HD`上提供30分鐘的端到端延遲。 為了實現這一目標，Hudi從流處理框架如[Spark Streaming](https://spark.apache.org/docs/latest/streaming-programming-guide.html#join-operations)、釋出/訂閱系統如[Kafka](http://kafka.apache.org/documentation/#theconsumer)或資料庫複製技術如[Oracle XStream](https://docs.oracle.com/cd/E11882_01/server.112/e16545/xstrm_cncpt.htm#XSTRM187)中引入了類似概念。若感興趣可以在[此處](https://www.oreilly.com/ideas/ubers-case-for-incremental-processing-on-hadoop)找到有關增量處理（與流處理和批處理相比）更多優勢的更詳細說明。 ## 4. DFS上資料分發 Hadoop的經典應用是處理資料，然後將其分發到線上儲存以供應用程式使用。例如使用Spark Pipeline將Hadoop的資料匯入到ElasticSearch供Uber應用程式使用。一種典型的架構是在Hadoop和服務儲存之間使用`佇列`進行解耦，以防止壓垮目標服務儲存，一般會選擇Kafka作為佇列，該架構會導致相同資料冗餘儲存在DFS（用於對計算結果進行離線分析）和Kafka（用於分發）上。 Hudi可以通過以下方式再次有效地解決此問題：將Spark Pipeline 插入更新輸出到Hudi表，然後對錶進行增量讀取（就像Kafka主題一樣）以獲取新資料並寫入服務儲存中，即使用Hudi統一