前言

好久不見(jiàn)（鞠躬

今年以來(lái)的主要工作方向之一就是部門(mén)內(nèi)流批一體能力的建設(shè)與落地。雖然這個(gè)概念早已成為老生常談，并且筆者現(xiàn)在還沒(méi)什么fancy的成果（慚愧），但今天還是想隨便寫(xiě)幾句來(lái)聊聊。

Why?

考慮經(jīng)典的Lambda Architecture。

這種架構(gòu)的出現(xiàn)是歷史必然，因?yàn)槟菚r(shí)的流計(jì)算引擎以Storm為代表，而它們都無(wú)法提供Exactly-Once語(yǔ)義，所以任何一點(diǎn)小的擾動(dòng)（延遲、網(wǎng)絡(luò)問(wèn)題、系統(tǒng)異常、etc.）就很可能導(dǎo)致實(shí)時(shí)數(shù)據(jù)失真。而以Hive on MapReduce為代表的批計(jì)算引擎和數(shù)據(jù)倉(cāng)庫(kù)組件早已成熟，因此能夠提供準(zhǔn)確的離線(xiàn)數(shù)據(jù)，并且還能為實(shí)時(shí)數(shù)據(jù)做出修正。

Lambda Architecture的問(wèn)題在于兩點(diǎn)：其一，speed layer和batch layer采用的是兩套技術(shù)棧、兩套API，開(kāi)發(fā)及維護(hù)成本高；其二，流處理和批處理的范式一致性無(wú)法保證，產(chǎn)生的結(jié)果往往割裂。而Dataflow Model、流批一體及其后的各種implementations的出現(xiàn)，恰好解決了這兩個(gè)問(wèn)題，用戶(hù)可以通過(guò)實(shí)現(xiàn)流批一體來(lái)降本增效，并對(duì)齊數(shù)據(jù)口徑。

What?

關(guān)于流批一體，至今實(shí)際上仍然缺乏統(tǒng)一的定義（如果有的話(huà)，請(qǐng)看官務(wù)必留言）。個(gè)人比較認(rèn)同的定義如下，這句話(huà)來(lái)自Flink Forward Asia 2021 Online上莫問(wèn)大佬的主題演講<<Flink Next, Beyond Stream Processing>>：

使用同一套API、同一套開(kāi)發(fā)范式來(lái)實(shí)現(xiàn)大數(shù)據(jù)的流計(jì)算和批計(jì)算，進(jìn)而保證處理過(guò)程與結(jié)果的一致性。

Google Dataflow Model提出，與Streaming / Batch這種像是描述計(jì)算引擎語(yǔ)義的字眼相對(duì)，它們?cè)嫦虻腢nbounded / Bounded Data才更接近本質(zhì)。由于有界數(shù)據(jù)天然地是無(wú)界流的一部分，就使得“流處理先行，將批處理作為流處理特例”的思路成為可能，同時(shí)形成了流批一體的理論基礎(chǔ)。

當(dāng)然，相對(duì)于批處理，流處理要更多地考慮數(shù)據(jù)準(zhǔn)確性、延遲、資源消耗之間的trade-off，所以需要施加額外的約束，主要包括窗口模型、觸發(fā)模型和增量更新模型。看官可參考論文原文，或筆者很久之前寫(xiě)過(guò)的解析文章，不再贅述。

How?

計(jì)算和存儲(chǔ)是大數(shù)據(jù)這枚硬幣的兩面，具體到流批一體這個(gè)細(xì)分領(lǐng)域，仍然免不了要套用這樣的思路。

Computation

Flink從誕生起就遵循Dataflow Model的設(shè)計(jì)思想，也是這條道路上的先驅(qū)。從1.9版本開(kāi)始到目前的1.15版本，F(xiàn)link社區(qū)做了大量努力來(lái)將它打造成一個(gè)真正流批一體的引擎，包括但不限于：

• 統(tǒng)一SQL Catalog / Planner / Runtime
• 統(tǒng)一DataStream API
• 統(tǒng)一Source / Sink模型
• 統(tǒng)一Checkpoint / Failover語(yǔ)義
• 統(tǒng)一DAG / Scheduler實(shí)現(xiàn)
• 統(tǒng)一Shuffle服務(wù)
• ...

關(guān)于以上要點(diǎn)，筆者今后會(huì)寫(xiě)文章專(zhuān)門(mén)闡述。

目前來(lái)看，F(xiàn)link SQL由于其易學(xué)習(xí)性、通用性、互操作性和元數(shù)據(jù)能力，已經(jīng)成為實(shí)現(xiàn)流批一體計(jì)算的事實(shí)標(biāo)準(zhǔn)。特別地，F(xiàn)link SQL對(duì)CDC數(shù)據(jù)接入、流批join/維表join操作、Hive集成、UDF等特性的深入支持，使得它在流批一體構(gòu)建ETL pipeline和實(shí)時(shí)數(shù)倉(cāng)方向具有天然的優(yōu)勢(shì)。Flink SQL的Connector / Format體系被設(shè)計(jì)為模塊化、易于擴(kuò)展的，這也讓它能夠方便地對(duì)接各類(lèi)外部系統(tǒng)和數(shù)據(jù)模型，打通數(shù)據(jù)壁壘。

Storage

眾所周知，OLAP引擎沒(méi)有銀彈，但是流批一體存儲(chǔ)似乎有比較接近銀彈的solution。

純Kappa Architecture已經(jīng)被證明是不靠譜的，因?yàn)殡m然它的鏈路簡(jiǎn)單、時(shí)效性最好，但傳統(tǒng)的消息隊(duì)列只有有限的存儲(chǔ)能力，一般只能保存有限量的Changelog，不能保存全量數(shù)據(jù)。并且分析型負(fù)載需要重放數(shù)據(jù)的overhead過(guò)大，也沒(méi)有謂詞下推等特性。新一代的消息隊(duì)列如Pulsar、Pravega等在這方面做了增強(qiáng)，如Pulsar采用以Segment為中心的設(shè)計(jì)，支持層級(jí)化存儲(chǔ)和海量數(shù)據(jù)歸檔，并提供了類(lèi)文件操作的API，但應(yīng)用還不廣泛。

很多用戶(hù)可能也會(huì)選擇在streaming layer的上方額外接入類(lèi)似ClickHouse、Doris等近實(shí)時(shí)OLAP組件，但這樣會(huì)導(dǎo)致架構(gòu)退化到Lambda Architecture。

排除以上兩個(gè)option，數(shù)據(jù)湖組件顯然最合適。不管是Iceberg還是Hudi，它們都具備以下優(yōu)點(diǎn)：

• 本質(zhì)是DFS之上的Storage Format，存儲(chǔ)門(mén)檻低，原生列存；
• 與Flink相性好，支持流批讀寫(xiě)；
• 支持ACID、MVCC、Time-Travel；
• 支持Schema Evolution；
• etc.

當(dāng)然，數(shù)據(jù)湖本身也是近實(shí)時(shí)存儲(chǔ)，所以要犧牲一定的時(shí)效性。但在實(shí)際的業(yè)務(wù)中，要求達(dá)到亞秒級(jí)時(shí)效的場(chǎng)景很少，所以數(shù)據(jù)湖以及湖倉(cāng)一體概念的興起也就很自然了。

The End

emm，寫(xiě)得太潦草了。

晚安。