傳統(tǒng)大數(shù)據(jù)平臺需求與痛點(diǎn)有哪些？

傳統(tǒng)大數(shù)據(jù)平臺交付運(yùn)維成本高、資源利用低效、迭代兼容性及安全性問題等關(guān)鍵痛點(diǎn)。

1.交付運(yùn)維成本高

傳統(tǒng)大數(shù)據(jù)平臺的建設(shè)和維護(hù)目前是一個(gè)重要且復(fù)雜的任務(wù)。這些平臺通常包括多種不同的組件，它們在技術(shù)棧、功能和架構(gòu)上存在顯著差異。這種多樣性不僅使得平臺的部署和配置變得極為復(fù)雜，也大幅增加了整體的運(yùn)維成本。 組件多樣性導(dǎo)致較高的人力需求： 大數(shù)據(jù)平臺包含多種組件，這些組件在技術(shù)棧（如Java、C++）、功能（如流處理、批處理，OLAP）和架構(gòu)（如C/S、MPP）方面各不相同。部署，配置和維護(hù)如此多樣的技術(shù)棧需要大量的專業(yè)人力，特別是在部署和交付新的大數(shù)據(jù)平臺時(shí)，人力資源的需求和成本會顯著增加。

運(yùn)維專業(yè)性與效率： 大數(shù)據(jù)組件的復(fù)雜性，具有較高的運(yùn)維知識門檻。這不僅增加了運(yùn)維團(tuán)隊(duì)的工作負(fù)擔(dān)，還可能導(dǎo)致效率低下和更頻繁的解決問題需求，從而增加成本。 工具與管理挑戰(zhàn)： 許多大數(shù)據(jù)組件缺乏開箱即用的日志、監(jiān)控和告警功能，導(dǎo)致運(yùn)維團(tuán)隊(duì)需要為每個(gè)組件單獨(dú)開發(fā)和適配這些工具。

每個(gè)組件可能有各自的集群和管理界面，使得整個(gè)平臺的統(tǒng)一管理和問題排查變得困難。這種分散性不僅降低了運(yùn)維效率，還可能導(dǎo)致問題解決的延遲，增加了管理成本。云原生技術(shù)可以有效緩解傳統(tǒng)大數(shù)據(jù)平臺的運(yùn)維挑戰(zhàn)。容器化通過屏蔽不同組件間的技術(shù)棧和基礎(chǔ)設(shè)施差異，簡化了運(yùn)維流程。工具如 Operator 實(shí)現(xiàn)了服務(wù)部署和運(yùn)維的標(biāo)準(zhǔn)化與自動(dòng)化，降低了復(fù)雜性和人力成本。在云原生架構(gòu)下，應(yīng)用和組件的更新僅需拉取新鏡像并重啟容器，確保環(huán)境一致性，加速應(yīng)用發(fā)布。此外，云原生環(huán)境提供統(tǒng)一管理界面，集中處理不同服務(wù)的發(fā)布和運(yùn)維，提高問題監(jiān)測和定位的效率。集成在Kubernetes Pods 和節(jié)點(diǎn)的監(jiān)控與告警工具，使得運(yùn)維團(tuán)隊(duì)可以通過統(tǒng)一界面清晰監(jiān)控基礎(chǔ)設(shè)施和服務(wù)狀態(tài)，有效跟蹤系統(tǒng)性能和健康狀況。

2.資源利用率低

組件混部困難：傳統(tǒng)的大數(shù)據(jù)平臺，為了避免組件間的相互影響，組件的集群往往是相互獨(dú)立部署的。這樣雖然對于整體的編排來說相對簡單，但是會降低資源利用率。 業(yè)務(wù)波動(dòng)性：由于大數(shù)據(jù)業(yè)務(wù)的特點(diǎn)，大數(shù)據(jù)組件在高峰期的資源利用率可以很高，但是在業(yè)務(wù)低峰期則會有較多閑置，此時(shí)集群整體資源利用率可能只有 20%-30%，綜合平均起來集群整體的資源利用率偏低。

彈性擴(kuò)縮容難度高：在業(yè)務(wù)高峰期時(shí)，如果現(xiàn)有的資源已經(jīng)無法支撐業(yè)務(wù)，這個(gè)時(shí)候可能需要通過較為繁瑣的運(yùn)維流程擴(kuò)容節(jié)點(diǎn)。到了業(yè)務(wù)低谷期時(shí)，這部分機(jī)器又很難通過運(yùn)維流程快速下線，擴(kuò)縮容的效率不高。 云原生領(lǐng)域在基礎(chǔ)資源基礎(chǔ)上抽象出了“資源池（計(jì)算、存儲、網(wǎng)絡(luò)等的組合）”的概念，資源池被所有的大數(shù)據(jù)組件公用，按需申請，可以避免重復(fù)規(guī)劃造成的資源浪費(fèi)。資源池可以承載不同類型的大數(shù)據(jù)集群，可以是批處理、也可以是流處理、MPP 等，得益于容器化較好的隔離性，不同的業(yè)務(wù)可以在一起混部，形成資源的分時(shí)復(fù)用；同時(shí)云原生領(lǐng)域有著豐富的工具來對資源池進(jìn)行彈性擴(kuò)縮容，甚至當(dāng)業(yè)務(wù)不存在的時(shí)候降到零副本，做到隨需啟停，做到Serverless化。

3.系統(tǒng)迭代與兼容性挑戰(zhàn)

傳統(tǒng)的大數(shù)據(jù)平臺，組件開發(fā)迭代不敏捷，周期長。組件版本往往比較固定，版本升級難度比較大。在部署新的大數(shù)據(jù)組件到現(xiàn)有的Hadoop 集群時(shí)。首先，必須確保這些新組件與現(xiàn)有的HDFS和Yarn版本兼容。由于許多新的大數(shù)據(jù)組件不支持舊版本的Hadoop，升級Hadoop 可能導(dǎo)致現(xiàn)有組件失效。其次，部署時(shí)還需考慮到不同Linux操作系統(tǒng)間的兼容性問題，這增加了額外的復(fù)雜性。因此，整合一個(gè)新的計(jì)算和存儲組件到現(xiàn)有架構(gòu)中通常是一個(gè)耗時(shí)的過程，可能需要幾天甚至幾周的時(shí)間。

云原生的定義中先天具有 DevOps、CI/CD 的思想，可以比較容易地做到IaC(Infrastructure as Code)和CaaS(Configuration as a Service)。組件的配置或代碼在 Git 中進(jìn)行保管，一旦發(fā)生變化，就會經(jīng)過CI 的環(huán)節(jié)進(jìn)行質(zhì)量驗(yàn)證，然后通過 CD 的管道打包成容器鏡像發(fā)布到運(yùn)行環(huán)境中。由于云原生中都是微服務(wù)架構(gòu)，你可以只單獨(dú)發(fā)布組件的一部分，不必整體組件一起發(fā)布；在組件的發(fā)布過程中，也可以更方便地實(shí)現(xiàn) A/B Test、灰度發(fā)布、發(fā)布回滾等操作。同時(shí)云原生中都是容器，啟停容器是輕量級動(dòng)作，效率高。

4.安全相關(guān)挑戰(zhàn)

傳統(tǒng)大數(shù)據(jù)平臺，在安全方面面臨著一系列挑戰(zhàn)。包括數(shù)據(jù)隔離、綜合訪問控制、數(shù)據(jù)加密和保護(hù)、審計(jì)與合規(guī)性、網(wǎng)絡(luò)安全、災(zāi)難恢復(fù)與數(shù)據(jù)備份等。針對這些挑戰(zhàn)，大數(shù)據(jù)開源社區(qū)已經(jīng)有一些解決方案，如使用 Kerberos 進(jìn)行認(rèn)證、Ranger 或Sentry 進(jìn)行訪問控制等，但這些解決方案往往伴隨著配置復(fù)雜、靈活性不足、自動(dòng)化程度低等缺點(diǎn)。 相比之下，云原生技術(shù)社區(qū)也提供了面對安全問題更全面、靈活且自動(dòng)化的安全解決方案。可以做到更好的網(wǎng)絡(luò)隔離，數(shù)據(jù)隔離，權(quán)限隔離，災(zāi)備等。