曾經爆火的「流批一體」現在怎麼樣了？

2021年和2022年，曾經有一個概念在整個資料開發方向傳播，不管是懂和不懂的人，都能扯上一兩句。那就是大家耳熟能詳的「流批一體」。

時至今日，已經很少有人再提起這個話題，這個概念在21、22年很多面試中也會被面試官問到，經常有同學問我這個問題，該怎麼回答?

今天咱們稍微聊聊這個話題。

當時這個概念被很多人提起，大概的意思就是這樣：期望一套程式碼能同時在批處理和流處理中執行。

這個概念神奇在哪呢?這個概念最初被Flink社群提起，因為期望能用Flink Batch 和 Flink Streaming一套程式碼同時做離線計算和實時計算，能解決資料的一致性、口徑等等問題。

這麼想當然沒什麼問題，是個很好的設想。但是前提是Flink能夠同時承擔離線和實時兩條鏈路的高效/穩定/低成本的執行。

小資料量下/小業務規模/小資料規模下，都沒有什麼問題。因為簡單，線上隨便整，問題也不會很多。

但是，一旦你的業務/資料規模變得很大，這是行不通的，所以真正能做到落地的公司和場景屈指可數。這也是至今，這個概念不再被廣泛提及的主要原因之一。

是不是這個方向沒什麼搞頭了?不是的。

其實大家可以換個思路，如果說在計算引擎上不能做到統一，那麼我們在資料側做到統一不就行了，我們統一不了計算引擎，但是我們統一資料出口。

所以，這個流批一體這個小領域，在業界分化出來了兩類做法。

第一類，和Kappa架構相互融合，把資料出口統一在實時側;

在業界的頭部公司有一些比較核心的業務場景，是不能接受離線/實時資料的差異性，或者容忍度很低。所以，業界的公司會在某個業務場景借鑑Kappa架構的設計，邏輯在實時側進行統一，同時向離線進行同步。說簡單點就是依賴Kafka->Hdfs這條同步鏈路，這條鏈路在業界頭部公司很成熟很穩定，久經考驗，這也為這種做法能夠實施打下了堅實的基礎。

這種做法，可以保證資料的邏輯是收口的，資料的下游在做複雜計算時不易產生口徑上的誤差。這種做法在大公司特定業務場景目前已經較為普遍，方案成熟，鏈路上實時計算側需要重點保障，離線資料一邊會變成分鐘/小時級可見的資料，時效性也會大大提升。

第二類，統一儲存引擎和計算引擎，同時能跑流和批計算;

能做到這件事的公司國內一隻手都數得過來，做法就是自研儲存引擎，能夠同時支援流讀(主要對接Flink SQL)也可以支援批讀(主要對接Spark SQL)，在語法上引擎側做到高度一致。保證資料是同源的，也能解決一部分流批一體的問題。(資料同源很重要，這是解決差異性的第一步，如果你的資料不同源，那麼未來資料有差異是遲早的問題)

但是我們必須得明白，在實時計算和離線計算中的語義有明顯的不同，這個不同主要就是由於「狀態」引起的。所以，只能在特定的場景中實現流批一體，不具有廣泛適用性。

時至今日，這個方向仍然在悄無聲息的發展，可能就在某家大公司的某個場景，大受裨益，有很多非常好的生產實踐。

這也是為什麼大家現在去面試，別人問你「流批一體」的真正落地，你欲言又止，思緒彷彿回到3年前，想說的很多，但是無從談起...