丰满少妇,久久99精品人妻一区二区,亚洲综合视频在线,亚洲人成电影在线网址

在過去的文章里面經(jīng)常會提到云原生大數(shù)據(jù)、存算分離架構(gòu)、傳統(tǒng)大數(shù)據(jù)的轉(zhuǎn)型和迭代還有對于數(shù)據(jù)倉庫相關(guān)的技術(shù)，對于流計算相關(guān)的好像涉及的非常少，但不得不說，流計算是目前以及未來大數(shù)據(jù)發(fā)展的主要趨勢，無論是AI時代需要實(shí)時的數(shù)據(jù)流交互，還是在實(shí)際的處理業(yè)務(wù)場景中對于實(shí)時性的要求都會越來越高。

架構(gòu)的簡單化

為什么大數(shù)據(jù)技術(shù)這些年發(fā)展的會那么快，基本上每年都會有一些新的技術(shù)誕生，也或許是一個新的數(shù)據(jù)處理手段出現(xiàn)，原因并不是現(xiàn)在技術(shù)不能滿足業(yè)務(wù)需求，而是使用成本和復(fù)雜度越來越高，在軟件開發(fā)領(lǐng)域有一個“3-5年法則”，也就是說一套系統(tǒng)性的程序，再經(jīng)過3-5年的時間之后，就會有一個新的重構(gòu)版本出現(xiàn)，要么是這個系統(tǒng)廢棄了，要么是這個系統(tǒng)得到了系統(tǒng)性的升級改造，在大數(shù)據(jù)領(lǐng)域來說，最近的十多年基本上沒一兩年就出現(xiàn)一些重大的技術(shù)組件更新，從hadoop、kafka、spark、storm、flink、doris、elasticserach、hudi、iceberg再到現(xiàn)在的一些向量化能力支持等等，從時間軸上來看，大約在3-5年的時間。

那回到架構(gòu)簡單化，回想對于大數(shù)據(jù)組件升級有多少是因為現(xiàn)在的組件不能夠滿足業(yè)務(wù)需求而升級的？ 我認(rèn)為這種情況是少部分，而大部分來說，是因為現(xiàn)在的組件維護(hù)成本太高，一套業(yè)務(wù)實(shí)現(xiàn)下來，可能需要7，8個甚至更多的大數(shù)據(jù)組件來支撐，那這里面每個環(huán)節(jié)都需要來運(yùn)維維護(hù)，從可靠性、穩(wěn)定性、冗災(zāi)能力等等方便都要考慮，所以，從近些年云原生大數(shù)據(jù)、數(shù)據(jù)湖技術(shù)開始，整個技術(shù)組件生態(tài)都是簡單化去演變。

其實(shí)近幾年對于計算引擎的迭代來說，大家會發(fā)現(xiàn)大多數(shù)的計算引擎都設(shè)計了自己的數(shù)據(jù)湖引擎，例如：Flink推出了Fluss和Paimono來實(shí)現(xiàn)其流場景的服務(wù)能力，Databricks的Delta Live Tables 來支持基于Spark Streaming的場景，為什么所有這些流處理系統(tǒng)都在向整合存儲和服務(wù)的方向發(fā)展？答案還是在于簡化架構(gòu)。傳統(tǒng)上，流處理系統(tǒng)被設(shè)計來處理數(shù)據(jù)，而存儲和服務(wù)層由獨(dú)立的系統(tǒng)管理。然而，為單個應(yīng)用程序維護(hù)多個系統(tǒng)會引入顯著的操作開銷，增加復(fù)雜性和成本。通過將攝取、處理和服務(wù)層整合到一個系統(tǒng)中，流處理平臺可以實(shí)現(xiàn)更流暢的數(shù)據(jù)流動，減輕維護(hù)負(fù)擔(dān)。

流計算的存算分離設(shè)計

從數(shù)據(jù)倉庫到數(shù)據(jù)湖，從分布式文件存儲到對象存儲，從分布式計算和存儲的一體化部署到計算和存儲的分開部署，計算保持彈性、靈活的能力，存儲支撐海量、可擴(kuò)展、低成本的能力，這些在過去幾年發(fā)展基本都比較成熟了，無論是國內(nèi)外都有相關(guān)的成熟產(chǎn)品可以供參考和使用，但是，貌似對于流計算來說，存算分離架構(gòu)設(shè)計一直還沒有大的改進(jìn)。

流計算里面最核心的就是狀態(tài)維護(hù)，需要通過不斷記錄內(nèi)部信息來進(jìn)行增量計算，而現(xiàn)在狀態(tài)維護(hù)基本都是在引擎本身去維護(hù)的，一般都是在本地內(nèi)存或者磁盤中保存，而采用存儲和計算分離的架構(gòu)模式，則可以將狀態(tài)保存到對象存儲中，對象存儲相比于本地來說，成本更加的低廉、擴(kuò)展性也更好，當(dāng)在流計算處理大型狀態(tài)（有時候比較大的狀態(tài)信息，會導(dǎo)致計算Task進(jìn)程OOM）操作時，

當(dāng)然，這里還有一個很關(guān)鍵的問題，就是S3這種對象存儲引擎他們的數(shù)據(jù)查詢延遲是比較大的，如果不是一個精準(zhǔn)的Key來查看，而是模糊匹配的話，那么它會通過scan的方式來全局掃描，這可比我們過去所使用的文件系統(tǒng)類的操作要慢好多，所以，對于流處理的來說這目前依舊是一個關(guān)鍵突破點(diǎn)。

不過，在技術(shù)領(lǐng)域中有一個非常好的氛圍，對于工程師來說，遇到問題就會想辦法去解決問題，那么對象存儲的問題來說，也會有對應(yīng)的一些開源解決方案，例如JuiceFS可以直接掛在S3、OSS等等的對象存儲，可以實(shí)現(xiàn)像訪問本地文件系統(tǒng)來訪問對象存儲的數(shù)據(jù)，這里面還支持分布式緩存能力，在某種程度上也算是解決了一些問題，但是在流計算的場景中，這些依舊無法徹底滿足。

另一個解決方案是Alluxio，它是位于計算和存儲之間的一個分布式服務(wù)，可以簡單理解為在我們計算引擎和對象存儲服務(wù)之間，有一個Alluxio的分布式服務(wù)，我們不直接操作對象存儲服務(wù)，而是通過它來操作，Aullxio借助自身的分布式緩存、元數(shù)據(jù)管理、透明加速能力，可以讓我們像訪問HDFS一樣訪問對象存儲服務(wù)，這種場景在對于大數(shù)據(jù)開發(fā)來說非常友好。

在2025年，流計算在基于S3這種對象存儲服務(wù)的作為基礎(chǔ)架構(gòu)的應(yīng)用場景會越來越多，對應(yīng)的流計算技術(shù)的支撐能力也會越來越強(qiáng)，例如：在Flink2.0版本中就引入了存儲計算分離的計劃，這里對于混合存儲、分布式緩存系統(tǒng)以及更多的緩存策略有很多特性的演進(jìn)，如果沒有這些緩存策略，在實(shí)際生產(chǎn)環(huán)境中很難能夠支撐大數(shù)據(jù)量、高負(fù)載的處理效率。

然而，數(shù)據(jù)流和數(shù)據(jù)湖的融合不僅僅是關(guān)于數(shù)據(jù)攝取。隨著 Databricks 的 Delta Live Tables 功能，對數(shù)據(jù)湖上增量計算的需求日益增長。由于 Iceberg 還沒有完全支持 CDC（變更數(shù)據(jù)捕獲），所以在iceberg中還無法提供對于增量數(shù)據(jù)的計算能力，但是在icerberg V3的版本設(shè)計中，已經(jīng)有了關(guān)于這方面的提案設(shè)計。

所以，從Lakehouse到StreamHouse的時刻某種意義上即將到來，在數(shù)據(jù)湖的這個短短幾年的發(fā)展中，將迎來新的里程碑。

Kafka作為流處理必然繞不過去的

既然在聊流計算技術(shù)的方向，那么Kafka是其中的核心話題之一，在這么多年的流計算領(lǐng)域里，kafka已經(jīng)是作為數(shù)據(jù)流傳輸?shù)募榷?biāo)準(zhǔn)，然而，Kafka 并非是唯一能夠促進(jìn)數(shù)據(jù)傳輸?shù)墓ぞ?，在流計算系統(tǒng)中也支持對于數(shù)據(jù)源的數(shù)據(jù)集成能力，例如Flink、Spark Streaming這樣的系統(tǒng)可以直接支持從上游的Postgres、Mysql和MongoDB中消費(fèi)CDC（變更數(shù)據(jù)捕獲）數(shù)據(jù)，所以，這也對整個流處理架構(gòu)進(jìn)行了優(yōu)化。

但是，不得不說Kafka依舊是大數(shù)據(jù)生態(tài)中的核心主導(dǎo)位置，而且其本身也支持了Kafka Stream和ksqlDb的能力，但是在大規(guī)模復(fù)雜的數(shù)據(jù)場景中，這些還是過于耦合了，只能說作為一個單點(diǎn)集成能力在進(jìn)行使用，目前還沒見過在真實(shí)的業(yè)務(wù)場景中，直接使用Kafka的stream和sql來對接線上能力的。

而Apache Pulsar作為最近幾年非?；钴S的基于存算分離的消息隊列引擎，新的架構(gòu)模式、新的性能吞吐量以及和周邊生態(tài)的集成能力的快速迭代，也得到了越來越多的認(rèn)可，我們目前就有很多業(yè)務(wù)在大規(guī)模的使用pulsar在進(jìn)行數(shù)據(jù)類的傳輸。

從未來幾年來看，流計算系統(tǒng)不太可能取代kafka來作為數(shù)據(jù)流的平臺，Kafka作為雖然是一個消息流系統(tǒng)，但是也充當(dāng)著對于數(shù)據(jù)容錯、故障轉(zhuǎn)移、數(shù)據(jù)順序性等等角色，應(yīng)用的場景非常的廣泛，這些在流處理系統(tǒng)中是無法直接滿足的，所以，這些也確保Kafka在整個大數(shù)據(jù)生態(tài)系統(tǒng)的位置是很難以撼動的。

最后

人工智能現(xiàn)在已經(jīng)是全社會都在討論的話題，那在大數(shù)據(jù)技術(shù)領(lǐng)域中，計算引擎系統(tǒng)也在面臨著更快速的迭代，來適配人工智能相關(guān)的需求，例如過去OLAP引擎相關(guān)都不具備向量化能力，現(xiàn)在StarRocks、Click house、TiDB已經(jīng)支持使用向量化數(shù)據(jù)庫能力來進(jìn)行向量搜索了，這是在大數(shù)據(jù)領(lǐng)域中非常重要的一個趨勢，后面可以結(jié)合計算引擎的CDC的能力（和消息隊列系統(tǒng)）來進(jìn)行實(shí)時進(jìn)行數(shù)據(jù)采集，計算引擎基于數(shù)據(jù)特征進(jìn)行數(shù)據(jù)處理和標(biāo)注，最后將數(shù)據(jù)保存在向量化數(shù)據(jù)庫中，在實(shí)際業(yè)務(wù)中進(jìn)行實(shí)時的問答以及結(jié)合智能BI分析能力，來展示實(shí)時的智能分析能力。