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

創(chuàng)新互聯(lián)是一家專業(yè)提供北戴河企業(yè)網(wǎng)站建設(shè),專注與做網(wǎng)站、成都網(wǎng)站制作、H5開發(fā)、小程序制作等業(yè)務(wù)。10年已為北戴河眾多企業(yè)、政府機(jī)構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)站制作公司優(yōu)惠進(jìn)行中。

1.近實(shí)時(shí)攝取

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

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

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

即使對于像Kafka這樣的不可變數(shù)據(jù)源，Hudi也會強(qiáng)制在DFS上保持最小文件大小，從而解決Hadoop領(lǐng)域中的古老問題以便改善NameNode的運(yùn)行狀況。這對于事件流尤為重要，因?yàn)槭录鳎ɡ鐔螕袅鳎┩ǔ］^大，如果管理不善，可能會嚴(yán)重?fù)p害Hadoop集群性能。

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

2. 近實(shí)時(shí)分析

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

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

3. 增量處理管道

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

上述示例忽略了延遲到達(dá)的數(shù)據(jù)，即 processing_time和 event_time分開的情況。不幸的是在后移動(dòng)和物聯(lián)網(wǎng)前的時(shí)代，數(shù)據(jù)延遲到達(dá)是非常常見的情況。在這種情況下，保證正確性的唯一方法是每小時(shí)重復(fù)處理最后幾個(gè)小時(shí)的數(shù)據(jù)，這會嚴(yán)重?fù)p害整個(gè)生態(tài)系統(tǒng)的效率。想象下在數(shù)百個(gè)工作流中每小時(shí)重新處理TB級別的數(shù)據(jù)。

Hudi可以很好的解決上述問題，其通過記錄粒度（而非文件夾或分區(qū)）來消費(fèi)上游Hudi表 HU中的新數(shù)據(jù)，下游的Hudi表 HD應(yīng)用處理邏輯并更新/協(xié)調(diào)延遲數(shù)據(jù)，這里 HU和 HD可以以更頻繁的時(shí)間（例如15分鐘）連續(xù)進(jìn)行調(diào)度，并在 HD上提供30分鐘的端到端延遲。

為了實(shí)現(xiàn)這一目標(biāo)，Hudi從流處理框架如Spark Streaming、發(fā)布/訂閱系統(tǒng)如Kafka或數(shù)據(jù)庫復(fù)制技術(shù)如Oracle XStream中引入了類似概念。若感興趣可以在此處找到有關(guān)增量處理（與流處理和批處理相比）更多優(yōu)勢的更詳細(xì)說明。

4. DFS上數(shù)據(jù)分發(fā)

Hadoop的經(jīng)典應(yīng)用是處理數(shù)據(jù)，然后將其分發(fā)到在線存儲以供應(yīng)用程序使用。例如使用Spark Pipeline將Hadoop的數(shù)據(jù)導(dǎo)入到ElasticSearch供Uber應(yīng)用程序使用。一種典型的架構(gòu)是在Hadoop和服務(wù)存儲之間使用 隊(duì)列進(jìn)行解耦，以防止壓垮目標(biāo)服務(wù)存儲，一般會選擇Kafka作為隊(duì)列，該架構(gòu)會導(dǎo)致相同數(shù)據(jù)冗余存儲在DFS（用于對計(jì)算結(jié)果進(jìn)行離線分析）和Kafka（用于分發(fā)）上。

Hudi可以通過以下方式再次有效地解決此問題：將Spark Pipeline 插入更新輸出到Hudi表，然后對表進(jìn)行增量讀?。ň拖馣afka主題一樣）以獲取新數(shù)據(jù)并寫入服務(wù)存儲中，即使用Hudi統(tǒng)一存儲。

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