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