前言
好久不見（鞠躬
今年以來的主要工作方向之一就是部門內流批一體能力的建設與落地。雖然這個概念早已成爲老生常談，並且筆者現在還沒什麼fancy的成果（慚愧），但今天還是想隨便寫幾句來聊聊。
Why?
考慮經典的Lambda Architecture。
這種架構的出現是歷史必然，因爲那時的流計算引擎以Storm爲代表，而它們都無法提供Exactly-Once語義，所以任何一點小的擾動（延遲、網絡問題、系統異常、etc.）就很可能導致實時數據失真。而以Hive on MapReduce爲代表的批計算引擎和數據倉庫組件早已成熟，因此能夠提供準確的離線數據，並且還能爲實時數據做出修正。
Lambda Architecture的問題在於兩點：其一，speed layer和batch layer採用的是兩套技術棧、兩套API，開發及維護成本高；其二，流處理和批處理的範式一致性無法保證，產生的結果往往割裂。而Dataflow Model、流批一體及其後的各種implementations的出現，恰好解決了這兩個問題，用戶可以通過實現流批一體來降本增效，並對齊數據口徑。
What?
關於流批一體，至今實際上仍然缺乏統一的定義（如果有的話，請看官務必留言）。個人比較認同的定義如下，這句話來自Flink Forward Asia 2021 Online上莫問大佬的主題演講<<Flink Next, Beyond Stream Processing>>：
使用同一套API、同一套開發範式來實現大數據的流計算和批計算，進而保證處理過程與結果的一致性。
Google Dataflow Model提出，與Streaming / Batch這種像是描述計算引擎語義的字眼相對，它們原生面向的Unbounded / Bounded Data才更接近本質。由於有界數據天然地是無界流的一部分，就使得“流處理先行，將批處理作爲流處理特例”的思路成爲可能，同時形成了流批一體的理論基礎。
當然，相對於批處理，流處理要更多地考慮數據準確性、延遲、資源消耗之間的trade-off，所以需要施加額外的約束，主要包括窗口模型、觸發模型和增量更新模型。看官可參考論文原文，或筆者很久之前寫過的解析文章，不再贅述。
How?
計算和存儲是大數據這枚硬幣的兩面，具體到流批一體這個細分領域，仍然免不了要套用這樣的思路。
Computation
Flink從誕生起就遵循Dataflow Model的設計思想，也是這條道路上的先驅。從1.9版本開始到目前的1.15版本，Flink社區做了大量努力來將它打造成一個真正流批一體的引擎，包括但不限於：
- 統一SQL Catalog / Planner / Runtime
- 統一DataStream API
- 統一Source / Sink模型
- 統一Checkpoint / Failover語義
- 統一DAG / Scheduler實現
- 統一Shuffle服務
- ...
關於以上要點，筆者今後會寫文章專門闡述。
目前來看，Flink SQL由於其易學習性、通用性、互操作性和元數據能力，已經成爲實現流批一體計算的事實標準。特別地，Flink SQL對CDC數據接入、流批join/維表join操作、Hive集成、UDF等特性的深入支持，使得它在流批一體構建ETL pipeline和實時數倉方向具有天然的優勢。Flink SQL的Connector / Format體系被設計爲模塊化、易於擴展的，這也讓它能夠方便地對接各類外部系統和數據模型，打通數據壁壘。
Storage
衆所周知，OLAP引擎沒有銀彈，但是流批一體存儲似乎有比較接近銀彈的solution。
純Kappa Architecture已經被證明是不靠譜的，因爲雖然它的鏈路簡單、時效性最好，但傳統的消息隊列只有有限的存儲能力，一般只能保存有限量的Changelog，不能保存全量數據。並且分析型負載需要重放數據的overhead過大，也沒有謂詞下推等特性。新一代的消息隊列如Pulsar、Pravega等在這方面做了增強，如Pulsar採用以Segment爲中心的設計，支持層級化存儲和海量數據歸檔，並提供了類文件操作的API，但應用還不廣泛。
很多用戶可能也會選擇在streaming layer的上方額外接入類似ClickHouse、Doris等近實時OLAP組件，但這樣會導致架構退化到Lambda Architecture。
排除以上兩個option，數據湖組件顯然最合適。不管是Iceberg還是Hudi，它們都具備以下優點：
- 本質是DFS之上的Storage Format，存儲門檻低，原生列存；
- 與Flink相性好，支持流批讀寫；
- 支持ACID、MVCC、Time-Travel；
- 支持Schema Evolution；
- etc.
當然，數據湖本身也是近實時存儲，所以要犧牲一定的時效性。但在實際的業務中，要求達到亞秒級時效的場景很少，所以數據湖以及湖倉一體概念的興起也就很自然了。
The End
emm，寫得太潦草了。
晚安。