本文探讨了流批一体的概念在2021-2022年的热度以及其背后的挑战。作者分析了两种主要实践方式：一是与Kappa架构融合，确保数据一致性；二是自研存储引擎支持流批一体。尽管存在限制，但该领域仍在特定场景中有实际应用和发展。
2021年和2022年，曾经有一个概念在整个数据开发方向传播，不管是懂和不懂的人，都能扯上一两句。那就是大家耳熟能详的「流批一体」。
时至今日，已经很少有人再提起这个话题，这个概念在21、22年很多面试中也会被面试官问到，经常有同学问我这个问题，该怎么回答？
今天咱们稍微聊聊这个话题。
当时这个概念被很多人提起，大概的意思就是这样：期望一套代码能同时在批处理和流处理中运行。
这个概念神奇在哪呢？这个概念最初被Flink社区提起，因为期望能用Flink Batch 和 Flink Streaming一套代码同时做离线计算和实时计算，能解决数据的一致性、口径等等问题。
这么想当然没什么问题，是个很好的设想。但是前提是Flink能够同时承担离线和实时两条链路的高效/稳定/低成本的运行。
小数据量下/小业务规模/小数据规模下，都没有什么问题。因为简单，线上随便整，问题也不会很多。
但是，一旦你的业务/数据规模变得很大，这是行不通的，所以真正能做到落地的公司和场景屈指可数。这也是至今，这个概念不再被广泛提及的主要原因之一。
是不是这个方向没什么搞头了？不是的。
其实大家可以换个思路，如果说在计算引擎上不能做到统一，那么我们在数据侧做到统一不就行了，我们统一不了计算引擎，但是我们统一数据出口。
所以，这个流批一体这个小领域，在业界分化出来了两类做法。
第一类，和Kappa架构相互融合，把数据出口统一在实时侧；
在业界的头部公司有一些比较核心的业务场景，是不能接受离线/实时数据的差异性，或者容忍度很低。所以，业界的公司会在某个业务场景借鉴Kappa架构的设计，逻辑在实时侧进行统一，同时向离线进行同步。说简单点就是依赖Kafka->Hdfs这条同步链路，这条链路在业界头部公司很成熟很稳定，久经考验，这也为这种做法能够实施打下了坚实的基础。
这种做法，可以保证数据的逻辑是收口的，数据的下游在做复杂计算时不易产生口径上的误差。这种做法在大公司特定业务场景目前已经较为普遍，方案成熟，链路上实时计算侧需要重点保障，离线数据一边会变成分钟/小时级可见的数据，时效性也会大大提升。
第二类，统一存储引擎和计算引擎，同时能跑流和批计算；
能做到这件事的公司国内一只手都数得过来，做法就是自研存储引擎，能够同时支持流读(主要对接Flink SQL)也可以支持批读(主要对接Spark SQL)，在语法上引擎侧做到高度一致。保证数据是同源的，也能解决一部分流批一体的问题。(数据同源很重要，这是解决差异性的第一步，如果你的数据不同源，那么未来数据有差异是迟早的问题)
但是我们必须得明白，在实时计算和离线计算中的语义有明显的不同，这个不同主要就是由于「状态」引起的。所以，只能在特定的场景中实现流批一体，不具有广泛适用性。
时至今日，这个方向仍然在悄无声息的发展，可能就在某家大公司的某个场景，大受裨益，有很多非常好的生产实践。
这也是为什么大家现在去面试，别人问你「流批一体」的真正落地，你欲言又止，思绪仿佛回到3年前，想说的很多，但是无从谈起...
如果这个文章对你有帮助，不要忘记 「在看」 「点赞」 「收藏」 三连啊喂！
Flink CDC我吃定了耶稣也留不住他！| Flink CDC线上问题小盘点
扫一扫
661
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
