前言
好久不見（鞠躬
今年以來的主要工作方向之一就是部門內流批一體能力的建設與落地。雖然這個概念早已成為老生常談蒿涎，并且筆者現在還沒什么fancy的成果（慚愧），但今天還是想隨便寫幾句來聊聊哨坪。
Why?
考慮經典的Lambda Architecture贩幻。
這種架構的出現是歷史必然轿腺，因為那時的流計算引擎以Storm為代表，而它們都無法提供Exactly-Once語義丛楚，所以任何一點小的擾動（延遲族壳、網絡問題、系統異常趣些、etc.）就很可能導致實時數據失真仿荆。而以Hive on MapReduce為代表的批計算引擎和數據倉庫組件早已成熟，因此能夠提供準確的離線數據坏平，并且還能為實時數據做出修正拢操。
Lambda Architecture的問題在于兩點：其一，speed layer和batch layer采用的是兩套技術棧舶替、兩套API令境，開發(fā)及維護成本高；其二顾瞪，流處理和批處理的范式一致性無法保證舔庶，產生的結果往往割裂抛蚁。而Dataflow Model、流批一體及其后的各種implementations的出現惕橙，恰好解決了這兩個問題瞧甩，用戶可以通過實現流批一體來降本增效，并對齊數據口徑吕漂。
What?
關于流批一體亲配，至今實際上仍然缺乏統一的定義（如果有的話，請看官務必留言）惶凝。個人比較認同的定義如下吼虎，這句話來自Flink Forward Asia 2021 Online上莫問大佬的主題演講<<Flink Next, Beyond Stream Processing>>：
使用同一套API、同一套開發(fā)范式來實現大數據的流計算和批計算苍鲜，進而保證處理過程與結果的一致性思灰。
Google Dataflow Model提出，與Streaming / Batch這種像是描述計算引擎語義的字眼相對混滔，它們原生面向的Unbounded / Bounded Data才更接近本質洒疚。由于有界數據天然地是無界流的一部分，就使得“流處理先行坯屿，將批處理作為流處理特例”的思路成為可能油湖，同時形成了流批一體的理論基礎。
當然领跛，相對于批處理乏德，流處理要更多地考慮數據準確性、延遲吠昭、資源消耗之間的trade-off喊括，所以需要施加額外的約束，主要包括窗口模型矢棚、觸發(fā)模型和增量更新模型郑什。看官可參考論文原文蒲肋，或筆者很久之前寫過的解析文章蘑拯，不再贅述。
How?
計算和存儲是大數據這枚硬幣的兩面兜粘，具體到流批一體這個細分領域申窘，仍然免不了要套用這樣的思路。
Computation
Flink從誕生起就遵循Dataflow Model的設計思想妹沙，也是這條道路上的先驅偶洋。從1.9版本開始到目前的1.15版本，Flink社區(qū)做了大量努力來將它打造成一個真正流批一體的引擎距糖，包括但不限于：
- 統一SQL Catalog / Planner / Runtime
- 統一DataStream API
- 統一Source / Sink模型
- 統一Checkpoint / Failover語義
- 統一DAG / Scheduler實現
- 統一Shuffle服務
- ...
關于以上要點玄窝，筆者今后會寫文章專門闡述牵寺。
目前來看，Flink SQL由于其易學習性恩脂、通用性帽氓、互操作性和元數據能力，已經成為實現流批一體計算的事實標準俩块。特別地黎休，Flink SQL對CDC數據接入、流批join/維表join操作玉凯、Hive集成势腮、UDF等特性的深入支持，使得它在流批一體構建ETL pipeline和實時數倉方向具有天然的優(yōu)勢漫仆。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溯警，它們都具備以下優(yōu)點：
- 本質是DFS之上的Storage Format趣苏，存儲門檻低，原生列存梯轻；
- 與Flink相性好食磕，支持流批讀寫；
- 支持ACID喳挑、MVCC彬伦、Time-Travel；
- 支持Schema Evolution伊诵；
- etc.
當然单绑，數據湖本身也是近實時存儲，所以要犧牲一定的時效性曹宴。但在實際的業(yè)務中询张，要求達到亞秒級時效的場景很少，所以數據湖以及湖倉一體概念的興起也就很自然了浙炼。
The End
emm份氧，寫得太潦草了。
晚安弯屈。
