前言
好久不见（鞠躬
今年以来的主要工作方向之一就是部门内流批一体能力的建设与落地。虽然这个概念早已成为老生常谈，并且笔者现在还没什么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，写得太潦草了。
晚安。
