在過去的文章里面經(jīng)常會(huì)提到云原生大數(shù)據(jù)、存算分離架構(gòu)、傳統(tǒng)大數(shù)據(jù)的轉(zhuǎn)型和迭代還有對(duì)于數(shù)據(jù)倉庫相關(guān)的技術(shù),對(duì)于流計(jì)算相關(guān)的好像涉及的非常少,但不得不說,流計(jì)算是目前以及未來大數(shù)據(jù)發(fā)展的主要趨勢(shì),無論是AI時(shí)代需要實(shí)時(shí)的數(shù)據(jù)流交互,還是在實(shí)際的處理業(yè)務(wù)場景中對(duì)于實(shí)時(shí)性的要求都會(huì)越來越高。
架構(gòu)的簡單化
為什么大數(shù)據(jù)技術(shù)這些年發(fā)展的會(huì)那么快,基本上每年都會(huì)有一些新的技術(shù)誕生,也或許是一個(gè)新的數(shù)據(jù)處理手段出現(xiàn),原因并不是現(xiàn)在技術(shù)不能滿足業(yè)務(wù)需求,而是使用成本和復(fù)雜度越來越高,在軟件開發(fā)領(lǐng)域有一個(gè)“3-5年法則”,也就是說一套系統(tǒng)性的程序,再經(jīng)過3-5年的時(shí)間之后,就會(huì)有一個(gè)新的重構(gòu)版本出現(xiàn),要么是這個(gè)系統(tǒng)廢棄了,要么是這個(gè)系統(tǒng)得到了系統(tǒng)性的升級(jí)改造,在大數(shù)據(jù)領(lǐng)域來說,最近的十多年基本上沒一兩年就出現(xiàn)一些重大的技術(shù)組件更新,從hadoop、kafka、spark、storm、flink、doris、elasticserach、hudi、iceberg再到現(xiàn)在的一些向量化能力支持等等,從時(shí)間軸上來看,大約在3-5年的時(shí)間。
那回到架構(gòu)簡單化,回想對(duì)于大數(shù)據(jù)組件升級(jí)有多少是因?yàn)楝F(xiàn)在的組件不能夠滿足業(yè)務(wù)需求而升級(jí)的? 我認(rèn)為這種情況是少部分,而大部分來說,是因?yàn)楝F(xiàn)在的組件維護(hù)成本太高,一套業(yè)務(wù)實(shí)現(xiàn)下來,可能需要7,8個(gè)甚至更多的大數(shù)據(jù)組件來支撐,那這里面每個(gè)環(huán)節(jié)都需要來運(yùn)維維護(hù),從可靠性、穩(wěn)定性、冗災(zāi)能力等等方便都要考慮,所以,從近些年云原生大數(shù)據(jù)、數(shù)據(jù)湖技術(shù)開始,整個(gè)技術(shù)組件生態(tài)都是簡單化去演變。
其實(shí)近幾年對(duì)于計(jì)算引擎的迭代來說,大家會(huì)發(fā)現(xiàn)大多數(shù)的計(jì)算引擎都設(shè)計(jì)了自己的數(shù)據(jù)湖引擎,例如:Flink推出了Fluss和Paimono來實(shí)現(xiàn)其流場景的服務(wù)能力,Databricks的Delta Live Tables 來支持基于Spark Streaming的場景,為什么所有這些流處理系統(tǒng)都在向整合存儲(chǔ)和服務(wù)的方向發(fā)展?答案還是在于簡化架構(gòu)。傳統(tǒng)上,流處理系統(tǒng)被設(shè)計(jì)來處理數(shù)據(jù),而存儲(chǔ)和服務(wù)層由獨(dú)立的系統(tǒng)管理。然而,為單個(gè)應(yīng)用程序維護(hù)多個(gè)系統(tǒng)會(huì)引入顯著的操作開銷,增加復(fù)雜性和成本。通過將攝取、處理和服務(wù)層整合到一個(gè)系統(tǒng)中,流處理平臺(tái)可以實(shí)現(xiàn)更流暢的數(shù)據(jù)流動(dòng),減輕維護(hù)負(fù)擔(dān)。
流計(jì)算的存算分離設(shè)計(jì)
從數(shù)據(jù)倉庫到數(shù)據(jù)湖,從分布式文件存儲(chǔ)到對(duì)象存儲(chǔ),從分布式計(jì)算和存儲(chǔ)的一體化部署到計(jì)算和存儲(chǔ)的分開部署,計(jì)算保持彈性、靈活的能力,存儲(chǔ)支撐海量、可擴(kuò)展、低成本的能力,這些在過去幾年發(fā)展基本都比較成熟了,無論是國內(nèi)外都有相關(guān)的成熟產(chǎn)品可以供參考和使用,但是,貌似對(duì)于流計(jì)算來說,存算分離架構(gòu)設(shè)計(jì)一直還沒有大的改進(jìn)。
流計(jì)算里面最核心的就是狀態(tài)維護(hù),需要通過不斷記錄內(nèi)部信息來進(jìn)行增量計(jì)算,而現(xiàn)在狀態(tài)維護(hù)基本都是在引擎本身去維護(hù)的,一般都是在本地內(nèi)存或者磁盤中保存,而采用存儲(chǔ)和計(jì)算分離的架構(gòu)模式,則可以將狀態(tài)保存到對(duì)象存儲(chǔ)中,對(duì)象存儲(chǔ)相比于本地來說,成本更加的低廉、擴(kuò)展性也更好,當(dāng)在流計(jì)算處理大型狀態(tài)(有時(shí)候比較大的狀態(tài)信息,會(huì)導(dǎo)致計(jì)算Task進(jìn)程OOM)操作時(shí),
當(dāng)然,這里還有一個(gè)很關(guān)鍵的問題,就是S3這種對(duì)象存儲(chǔ)引擎他們的數(shù)據(jù)查詢延遲是比較大的,如果不是一個(gè)精準(zhǔn)的Key來查看,而是模糊匹配的話,那么它會(huì)通過scan的方式來全局掃描,這可比我們過去所使用的文件系統(tǒng)類的操作要慢好多,所以,對(duì)于流處理的來說這目前依舊是一個(gè)關(guān)鍵突破點(diǎn)。
不過,在技術(shù)領(lǐng)域中有一個(gè)非常好的氛圍,對(duì)于工程師來說,遇到問題就會(huì)想辦法去解決問題,那么對(duì)象存儲(chǔ)的問題來說,也會(huì)有對(duì)應(yīng)的一些開源解決方案,例如JuiceFS可以直接掛在S3、OSS等等的對(duì)象存儲(chǔ),可以實(shí)現(xiàn)像訪問本地文件系統(tǒng)來訪問對(duì)象存儲(chǔ)的數(shù)據(jù),這里面還支持分布式緩存能力,在某種程度上也算是解決了一些問題,但是在流計(jì)算的場景中,這些依舊無法徹底滿足。
另一個(gè)解決方案是Alluxio,它是位于計(jì)算和存儲(chǔ)之間的一個(gè)分布式服務(wù),可以簡單理解為在我們計(jì)算引擎和對(duì)象存儲(chǔ)服務(wù)之間,有一個(gè)Alluxio的分布式服務(wù),我們不直接操作對(duì)象存儲(chǔ)服務(wù),而是通過它來操作,Aullxio借助自身的分布式緩存、元數(shù)據(jù)管理、透明加速能力,可以讓我們像訪問HDFS一樣訪問對(duì)象存儲(chǔ)服務(wù),這種場景在對(duì)于大數(shù)據(jù)開發(fā)來說非常友好。
在2025年,流計(jì)算在基于S3這種對(duì)象存儲(chǔ)服務(wù)的作為基礎(chǔ)架構(gòu)的應(yīng)用場景會(huì)越來越多,對(duì)應(yīng)的流計(jì)算技術(shù)的支撐能力也會(huì)越來越強(qiáng),例如:在Flink2.0版本中就引入了存儲(chǔ)計(jì)算分離的計(jì)劃,這里對(duì)于混合存儲(chǔ)、分布式緩存系統(tǒng)以及更多的緩存策略有很多特性的演進(jìn),如果沒有這些緩存策略,在實(shí)際生產(chǎn)環(huán)境中很難能夠支撐大數(shù)據(jù)量、高負(fù)載的處理效率。
然而,數(shù)據(jù)流和數(shù)據(jù)湖的融合不僅僅是關(guān)于數(shù)據(jù)攝取。隨著 Databricks 的 Delta Live Tables 功能,對(duì)數(shù)據(jù)湖上增量計(jì)算的需求日益增長。由于 Iceberg 還沒有完全支持 CDC(變更數(shù)據(jù)捕獲),所以在iceberg中還無法提供對(duì)于增量數(shù)據(jù)的計(jì)算能力,但是在icerberg V3的版本設(shè)計(jì)中,已經(jīng)有了關(guān)于這方面的提案設(shè)計(jì)。
所以,從Lakehouse到StreamHouse的時(shí)刻某種意義上即將到來,在數(shù)據(jù)湖的這個(gè)短短幾年的發(fā)展中,將迎來新的里程碑。
Kafka作為流處理必然繞不過去的
既然在聊流計(jì)算技術(shù)的方向,那么Kafka是其中的核心話題之一,在這么多年的流計(jì)算領(lǐng)域里,kafka已經(jīng)是作為數(shù)據(jù)流傳輸?shù)募榷?biāo)準(zhǔn),然而,Kafka 并非是唯一能夠促進(jìn)數(shù)據(jù)傳輸?shù)墓ぞ撸诹饔?jì)算系統(tǒng)中也支持對(duì)于數(shù)據(jù)源的數(shù)據(jù)集成能力,例如Flink、Spark Streaming這樣的系統(tǒng)可以直接支持從上游的Postgres、Mysql和MongoDB中消費(fèi)CDC(變更數(shù)據(jù)捕獲)數(shù)據(jù),所以,這也對(duì)整個(gè)流處理架構(gòu)進(jìn)行了優(yōu)化。
但是,不得不說Kafka依舊是大數(shù)據(jù)生態(tài)中的核心主導(dǎo)位置,而且其本身也支持了Kafka Stream和ksqlDb的能力,但是在大規(guī)模復(fù)雜的數(shù)據(jù)場景中,這些還是過于耦合了,只能說作為一個(gè)單點(diǎn)集成能力在進(jìn)行使用,目前還沒見過在真實(shí)的業(yè)務(wù)場景中,直接使用Kafka的stream和sql來對(duì)接線上能力的。
而Apache Pulsar作為最近幾年非?;钴S的基于存算分離的消息隊(duì)列引擎,新的架構(gòu)模式、新的性能吞吐量以及和周邊生態(tài)的集成能力的快速迭代,也得到了越來越多的認(rèn)可,我們目前就有很多業(yè)務(wù)在大規(guī)模的使用pulsar在進(jìn)行數(shù)據(jù)類的傳輸。
從未來幾年來看,流計(jì)算系統(tǒng)不太可能取代kafka來作為數(shù)據(jù)流的平臺(tái),Kafka作為雖然是一個(gè)消息流系統(tǒng),但是也充當(dāng)著對(duì)于數(shù)據(jù)容錯(cuò)、故障轉(zhuǎn)移、數(shù)據(jù)順序性等等角色,應(yīng)用的場景非常的廣泛,這些在流處理系統(tǒng)中是無法直接滿足的,所以,這些也確保Kafka在整個(gè)大數(shù)據(jù)生態(tài)系統(tǒng)的位置是很難以撼動(dòng)的。
最后
人工智能現(xiàn)在已經(jīng)是全社會(huì)都在討論的話題,那在大數(shù)據(jù)技術(shù)領(lǐng)域中,計(jì)算引擎系統(tǒng)也在面臨著更快速的迭代,來適配人工智能相關(guān)的需求,例如過去OLAP引擎相關(guān)都不具備向量化能力,現(xiàn)在StarRocks、Click house、TiDB已經(jīng)支持使用向量化數(shù)據(jù)庫能力來進(jìn)行向量搜索了,這是在大數(shù)據(jù)領(lǐng)域中非常重要的一個(gè)趨勢(shì),后面可以結(jié)合計(jì)算引擎的CDC的能力(和消息隊(duì)列系統(tǒng))來進(jìn)行實(shí)時(shí)進(jìn)行數(shù)據(jù)采集,計(jì)算引擎基于數(shù)據(jù)特征進(jìn)行數(shù)據(jù)處理和標(biāo)注,最后將數(shù)據(jù)保存在向量化數(shù)據(jù)庫中,在實(shí)際業(yè)務(wù)中進(jìn)行實(shí)時(shí)的問答以及結(jié)合智能BI分析能力,來展示實(shí)時(shí)的智能分析能力。
上一篇: 各行業(yè)數(shù)字化轉(zhuǎn)型概況
下一篇: 工業(yè)互聯(lián)網(wǎng)激活“數(shù)”動(dòng)力!我國工業(yè)互聯(lián)網(wǎng)已覆蓋全部工業(yè)大類
違法和不良信息舉報(bào)投訴電話:0377-62377728 舉報(bào)郵箱:fbypt@m.4729d.com
網(wǎng)絡(luò)警察提醒你 a>
中國互聯(lián)網(wǎng)舉報(bào)中心
網(wǎng)絡(luò)舉報(bào)APP下載
掃黃打非網(wǎng)舉報(bào)專區(qū)