建站
咨詢
售后
建站咨詢
新聞中心
這篇文章將為大家詳細(xì)講解有關(guān)Apache Hudi典型應(yīng)用場景有哪些，文章內(nèi)容質(zhì)量較高，因此小編分享給大家做個參考，希望大家閱讀完這篇文章后對相關(guān)知識有一定的了解。
創(chuàng)新互聯(lián)是一家專業(yè)提供北戴河企業(yè)網(wǎng)站建設(shè),專注與做網(wǎng)站、成都網(wǎng)站制作、H5開發(fā)、小程序制作等業(yè)務(wù)。10年已為北戴河眾多企業(yè)、政府機構(gòu)等服務(wù)。創(chuàng)新互聯(lián)專業(yè)網(wǎng)站制作公司優(yōu)惠進行中。
1.近實時攝取
將數(shù)據(jù)從外部源如事件日志、數(shù)據(jù)庫提取到Hadoop數(shù)據(jù)湖 中是一個很常見的問題。在大多數(shù)Hadoop部署中，一般使用混合提取工具并以零散的方式解決該問題，盡管這些數(shù)據(jù)對組織是非常有價值的。
對于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ù)量相匹配。
即使對于像Kafka這樣的不可變數(shù)據(jù)源，Hudi也會強制在DFS上保持最小文件大小，從而解決Hadoop領(lǐng)域中的古老問題以便改善NameNode的運行狀況。這對于事件流尤為重要，因為事件流（例如單擊流）通常較大，如果管理不善，可能會嚴(yán)重?fù)p害Hadoop集群性能。
對于所有數(shù)據(jù)源，Hudi都提供了通過提交將新數(shù)據(jù)原子化地發(fā)布給消費者，從而避免部分提取失敗。
2. 近實時分析
通常實時數(shù)據(jù)集市由專門的分析存儲，如Druid、Memsql甚至OpenTSDB提供支持。這對于需要亞秒級查詢響應(yīng)（例如系統(tǒng)監(jiān)視或交互式實時分析）的較小規(guī)模（相對于安裝Hadoop）數(shù)據(jù)而言是非常完美的選擇。但由于Hadoop上的數(shù)據(jù)令人難以忍受，因此這些系統(tǒng)通常最終會被較少的交互查詢所濫用，從而導(dǎo)致利用率不足和硬件/許可證成本的浪費。
另一方面，Hadoop上的交互式SQL解決方案（如Presto和SparkSQL），能在幾秒鐘內(nèi)完成的查詢。通過將數(shù)據(jù)的更新時間縮短至幾分鐘，Hudi提供了一種高效的替代方案，并且還可以對存儲在DFS上多個更大的表進行實時分析。此外，Hudi沒有外部依賴項（例如專用于實時分析的專用HBase群集），因此可以在不增加運營成本的情況下，對更實時的數(shù)據(jù)進行更快的分析。
3. 增量處理管道
Hadoop提供的一項基本功能是構(gòu)建基于表的派生鏈，并通過DAG表示整個工作流。工作流通常取決于多個上游工作流輸出的新數(shù)據(jù)，傳統(tǒng)上新生成的DFS文件夾/Hive分區(qū)表示新數(shù)據(jù)可用。例如上游工作流 U可以每小時創(chuàng)建一個Hive分區(qū)，并在每小時的末尾（ processing_time）包含該小時（ event_time）的數(shù)據(jù)，從而提供1小時的數(shù)據(jù)新鮮度。然后下游工作流 D在 U完成后立即開始，并在接下來的一個小時進行處理，從而將延遲增加到2個小時。
上述示例忽略了延遲到達的數(shù)據(jù)，即 processing_time和 event_time分開的情況。不幸的是在后移動和物聯(lián)網(wǎng)前的時代，數(shù)據(jù)延遲到達是非常常見的情況。在這種情況下，保證正確性的唯一方法是每小時重復(fù)處理最后幾個小時的數(shù)據(jù)，這會嚴(yán)重?fù)p害整個生態(tài)系統(tǒng)的效率。想象下在數(shù)百個工作流中每小時重新處理TB級別的數(shù)據(jù)。
Hudi可以很好的解決上述問題，其通過記錄粒度（而非文件夾或分區(qū)）來消費上游Hudi表 HU中的新數(shù)據(jù)，下游的Hudi表 HD應(yīng)用處理邏輯并更新/協(xié)調(diào)延遲數(shù)據(jù)，這里 HU和 HD可以以更頻繁的時間（例如15分鐘）連續(xù)進行調(diào)度，并在 HD上提供30分鐘的端到端延遲。
為了實現(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ù)存儲之間使用 隊列進行解耦，以防止壓垮目標(biāo)服務(wù)存儲，一般會選擇Kafka作為隊列，該架構(gòu)會導(dǎo)致相同數(shù)據(jù)冗余存儲在DFS（用于對計算結(jié)果進行離線分析）和Kafka（用于分發(fā)）上。
Hudi可以通過以下方式再次有效地解決此問題：將Spark Pipeline 插入更新輸出到Hudi表，然后對表進行增量讀?。ň拖馣afka主題一樣）以獲取新數(shù)據(jù)并寫入服務(wù)存儲中，即使用Hudi統(tǒng)一存儲。
關(guān)于Apache Hudi典型應(yīng)用場景有哪些就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，可以學(xué)到更多知識。如果覺得文章不錯，可以把它分享出去讓更多的人看到。
當(dāng)前標(biāo)題：ApacheHudi典型應(yīng)用場景有哪些
文章轉(zhuǎn)載：http://www.dlmjj.cn/article/gsdpco.html
