在當(dāng)前的數(shù)據(jù)處理行業(yè)，企業(yè)們追求提升性能、解決兼容性問(wèn)題以及控制成本等目標(biāo)，這一過(guò)程充滿了挑戰(zhàn)和意外的收獲。以CDH5升級(jí)至CDH6的集群為例，其中的變化確實(shí)值得詳細(xì)研究。

集群升級(jí)帶來(lái)的性能提升

在CDH5到CDH6集群升級(jí)初期，計(jì)算引擎由Hive升級(jí)至HiveOnSpark。這一改動(dòng)顯著提升了性能，增幅相當(dāng)可觀。這意味著在完成相同任務(wù)時(shí)，所需時(shí)間大幅減少。節(jié)省的時(shí)間直接轉(zhuǎn)化為生產(chǎn)力的提升。同時(shí)，還解決了眾多兼容性問(wèn)題，包括SQL語(yǔ)法、UDF、數(shù)據(jù)文件格式和運(yùn)行參數(shù)等，使數(shù)據(jù)處理流程更加流暢穩(wěn)定。

集群升級(jí)并非易事，需全方位考量。企業(yè)需投入人力和物力進(jìn)行遷移測(cè)試，以防數(shù)據(jù)丟失等風(fēng)險(xiǎn)。盡管升級(jí)有許多益處，但過(guò)程并不輕松。

Canal數(shù)據(jù)解析與處理

在IDC中，Canal扮演著關(guān)鍵角色。它負(fù)責(zé)解析Sink數(shù)據(jù)，并將其發(fā)送至Kafka。這樣的處理方式，有助于實(shí)現(xiàn)上下游系統(tǒng)的解耦。一旦上下游系統(tǒng)實(shí)現(xiàn)獨(dú)立，那么它們各自的升級(jí)或修改，就不會(huì)對(duì)彼此造成太大的影響。

在這種架構(gòu)中，實(shí)現(xiàn)數(shù)據(jù)回溯變得相對(duì)簡(jiǎn)單。我們能夠獲取到Kafka在特定時(shí)間點(diǎn)的消費(fèi)數(shù)據(jù)，這對(duì)追溯歷史數(shù)據(jù)、追蹤錯(cuò)誤數(shù)據(jù)的來(lái)源非常有益。工程師在此過(guò)程中需細(xì)致設(shè)置Canal與Kafka的連接，確保數(shù)據(jù)傳輸既準(zhǔn)確又迅速。任何配置上的失誤都可能導(dǎo)致數(shù)據(jù)傳輸中斷或數(shù)據(jù)丟失。

原始數(shù)據(jù)處理的困境

原始數(shù)據(jù)通常不能直接用于制作業(yè)務(wù)報(bào)表。企業(yè)常常需要對(duì)這些數(shù)據(jù)進(jìn)行大量加工，這本身就是一個(gè)不小的挑戰(zhàn)。比如說(shuō)，不能直接利用Kudu的原始表來(lái)提供查詢服務(wù)。盡管Kudu有其優(yōu)勢(shì)，但在成本、性能和擴(kuò)展性等方面，僅憑Kudu構(gòu)建數(shù)據(jù)倉(cāng)庫(kù)并非最佳選擇。因此，企業(yè)需持續(xù)尋找新的數(shù)據(jù)處理方式，以滿足業(yè)務(wù)報(bào)表的制作需求。

面對(duì)龐大的數(shù)據(jù)處理需求，問(wèn)題愈發(fā)明顯。數(shù)據(jù)處理的計(jì)算需求很高，若在此投入過(guò)多資源，將對(duì)企業(yè)整體效益造成影響。

Hudi的優(yōu)勢(shì)與應(yīng)用

Hudi是處理數(shù)據(jù)問(wèn)題的有效方法。它對(duì)數(shù)據(jù)處理中的某些功能提供了出色支持，比如能夠?qū)崿F(xiàn)接近實(shí)時(shí)的分鐘級(jí)延遲寫(xiě)入。這種特性在那些需要快速更新數(shù)據(jù)但又不允許實(shí)時(shí)性要求過(guò)高的場(chǎng)合特別有用。此外，它還具備多種靈活機(jī)制，例如支持亂序數(shù)據(jù)導(dǎo)入、部分字段更新和自定義操作等。

在實(shí)際應(yīng)用中，例如在Flink進(jìn)行多表連接操作時(shí)，我們可以利用這些特性來(lái)達(dá)成目的。這樣一來(lái)，F(xiàn)link便無(wú)需擔(dān)憂狀態(tài)過(guò)時(shí)和順序混亂的問(wèn)題。在企業(yè)層面，采用Hudi能夠提升數(shù)據(jù)處理的效能與適應(yīng)性。然而，配置與運(yùn)用Hudi確實(shí)要求技術(shù)人員具備一定的專業(yè)素養(yǎng)。

Spark寫(xiě)入操作與性能優(yōu)化

在處理數(shù)據(jù)時(shí)，我們通過(guò)Spark讀取Kafka上多個(gè)主題的變更數(shù)據(jù)，并將其寫(xiě)入到900張Hudi表中。在此過(guò)程中，嘗試用Spark作業(yè)并行寫(xiě)入這些表，啟動(dòng)多個(gè)線程以加速操作。然而，快速恢復(fù)和業(yè)務(wù)優(yōu)先級(jí)等問(wèn)題迅速顯現(xiàn)。實(shí)踐表明，單個(gè)作業(yè)多線程寫(xiě)入多張表的效率并不理想，相比之下，多個(gè)作業(yè)分別寫(xiě)入多張表的效果更好。這主要是因?yàn)镋MR對(duì)Spark進(jìn)行了性能上的優(yōu)化，對(duì)源代碼進(jìn)行了調(diào)整，但API層仍然與開(kāi)源版本保持一致。

并發(fā)寫(xiě)入涉及文件鎖等特殊機(jī)制，當(dāng)對(duì)正在執(zhí)行寫(xiě)入操作的表進(jìn)行操作時(shí)，這種文件鎖的設(shè)置確實(shí)帶來(lái)了方便。另外，在Spark寫(xiě)入Hudi的過(guò)程中，參數(shù)的調(diào)整同樣關(guān)鍵。例如，適當(dāng)?shù)靥嵘承﹨?shù)的數(shù)值，將某些參數(shù)設(shè)置為真，以提升數(shù)據(jù)集的檢索效率。

硬件成本的降低與整體方案優(yōu)勢(shì)

采用Hudi方案后，與EMR集群共享計(jì)算資源顯著降低了成本。硬件費(fèi)用較之前減少了75%以上，這一降幅令人矚目。此外，它還能實(shí)現(xiàn)接近實(shí)時(shí)的寫(xiě)入，每分鐘延遲極低，這對(duì)于數(shù)據(jù)新鮮度和成本控制都是一大優(yōu)勢(shì)。利用S3作為數(shù)據(jù)湖，數(shù)據(jù)得以在多種計(jì)算引擎間自由流動(dòng)。這樣的設(shè)計(jì)使得不同計(jì)算引擎間的數(shù)據(jù)共享和協(xié)同處理效率大大提升。

末了，我想請(qǐng)教大家一個(gè)問(wèn)題：在處理數(shù)據(jù)時(shí)，是否也遇到過(guò)性能有所提高卻遭遇其他難題的情形？期待大家的踴躍留言交流，同時(shí)也很樂(lè)意看到大家對(duì)這篇文章的點(diǎn)贊與轉(zhuǎn)發(fā)。