曾经爆火的「流批一体」现在怎么样了?

2021年和2022年，曾经有一个概念在整个数据开发方向传播，不管是懂和不懂的人，都能扯上一两句。那就是大家耳熟能详的「流批一体」。

时至今日，已经很少有人再提起这个话题，这个概念在21、22年很多面试中也会被面试官问到，经常有同学问我这个问题，该怎么回答？

今天咱们稍微聊聊这个话题。

当时这个概念被很多人提起，大概的意思就是这样：期望一套代码能同时在批处理和流处理中运行。

这个概念神奇在哪呢？这个概念最初被Flink社区提起，因为期望能用Flink Batch 和 Flink Streaming一套代码同时做离线计算和实时计算，能解决数据的一致性、口径等等问题。

这么想当然没什么问题，是个很好的设想。但是前提是Flink能够同时承担离线和实时两条链路的高效/稳定/低成本的运行。

小数据量下/小业务规模/小数据规模下，都没有什么问题。因为简单，线上随便整，问题也不会很多。

但是，一旦你的业务/数据规模变得很大，这是行不通的，所以真正能做到落地的公司和场景屈指可数。这也是至今，这个概念不再被广泛提及的主要原因之一。

是不是这个方向没什么搞头了？不是的。

其实大家可以换个思路，如果说在计算引擎上不能做到统一，那么我们在数据侧做到统一不就行了，我们统一不了计算引擎，但是我们统一数据出口。

所以，这个流批一体这个小领域，在业界分化出来了两类做法。

第一类，和Kappa架构相互融合，把数据出口统一在实时侧；

在业界的头部公司有一些比较核心的业务场景，是不能接受离线/实时数据的差异性，或者容忍度很低。所以，业界的公司会在某个业务场景借鉴Kappa架构的设计，逻辑在实时侧进行统一，同时向离线进行同步。说简单点就是依赖Kafka->Hdfs这条同步链路，这条链路在业界头部公司很成熟很稳定，久经考验，这也为这种做法能够实施打下了坚实的基础。

这种做法，可以保证数据的逻辑是收口的，数据的下游在做复杂计算时不易产生口径上的误差。这种做法在大公司特定业务场景目前已经较为普遍，方案成熟，链路上实时计算侧需要重点保障，离线数据一边会变成分钟/小时级可见的数据，时效性也会大大提升。

第二类，统一存储引擎和计算引擎，同时能跑流和批计算；

能做到这件事的公司国内一只手都数得过来，做法就是自研存储引擎，能够同时支持流读(主要对接Flink SQL)也可以支持批读(主要对接Spark SQL)，在语法上引擎侧做到高度一致。保证数据是同源的，也能解决一部分流批一体的问题。(数据同源很重要，这是解决差异性的第一步，如果你的数据不同源，那么未来数据有差异是迟早的问题)

但是我们必须得明白，在实时计算和离线计算中的语义有明显的不同，这个不同主要就是由于「状态」引起的。所以，只能在特定的场景中实现流批一体，不具有广泛适用性。

时至今日，这个方向仍然在悄无声息的发展，可能就在某家大公司的某个场景，大受裨益，有很多非常好的生产实践。

这也是为什么大家现在去面试，别人问你「流批一体」的真正落地，你欲言又止，思绪仿佛回到3年前，想说的很多，但是无从谈起...

300万字！全网最全大数据学习面试社区等你来！