1。前言这篇文章主要是分享一下博主所了解的流批一体化的背景，想解决的问题，以及后续可能实现的思路，并介绍几个案例。抛砖引玉，让大家不仅能停留在流批整合这件事上，更能深入思考其背后的原因。2.背景在介绍流批一体化之前，我们先了解一下流批领域常用的引擎：批任务：常用的有Hive和Spark。流式任务：常用Flink。SparkStreaming和Storm目前在Streaming场景的使用比Flink少。3.什么问题导致了流批一体化的概念？一个前提：在生产场景中，当同口径的指标使用流任务生产实时数据和批任务生产离线数据时，会去考虑是否需要做流批整合。如果一个指标只需要离线输出，那谈何流批一体化呢？观点一：博主认为流批融合应该从stream的角度来考虑，stream任务输出的结果在batch字段（或者以batch形式的数据形式）进行复用，而不仅仅是在引擎端，API接口层面的统一。这个观点和下图中阿里（FromFFA2020）的观点类似。博主理解，离线领域的实时复用可能是对阿里列举的问题的抽象。因为如果可以重复使用，下图中的三个问题就不存在了！待解决的问题：基于以上前提和思考角度，博主认为目前最需要解决的问题是解决流式任务产生的数据质量，这也是流式数据能够被接受的前提。在批处理场景中重复使用。使用过Flink实时数据开发的同学应该都遇到过Flink在生产数据时出现的一些异常情况（比如使用window可能会导致数据丢失），这可能会导致与离线Hive和Spark生产的数据有些细微的差异。这样就无法实现离线领域实时数据的复用。博主理解，流批一体化的重点就是解决这个问题，其他在资源节约、人力效率提升等方面的优势，都是基于这个附加值。4、那么流式任务中数据质量出现问题的原因有哪些，常见的场景有哪些？博主认为，目前最重要的原因之一是数据乱序导致的数据质量问题。实时领域最常用和常见的场景如下：第一种是Flink任务打开一个窗口的场景。比如开启了TUMBLEWINDOW的Flink任务，遇到严重的数据乱序情况（用户配置的最大乱序顺序、允许延迟等参数无法解决），任务会丢弃数据。这种场景下会导致实时数据和离线数据的差异。二是实时维表关联的场景。如果事实表中的数据先到，则维度表中的数据不会关联。从而产生与线下的差异。当然还有其他的场景，这里就不一一列举了。5、解决上述数据质量问题的可行思路是什么？理想思路：以TUMBLEWINDOW为例。大数据无法处理，所以我们可以将TUMBLEWINDOW换成GROUPAGG（retractstream，或CDC模式）进行计算。当有迟到数据时，GROUPAGG会正常处理并撤回最后的结果，并发送重新计算的新结果。但是这种方式的问题是，如果我们要以CDC方式运行任务，就需要将整个链路以CDC方式运行，包括计算引擎、消息队列、OLAP引擎等，同时还要保证Exactly-once.（不过说到CDC，有没有想到数据湖？这也可能是后续的一个发展方向）。以阿里提到的分钟/小时累计指标（FromFFA2020）为例，来看看阿里是怎么做的。其实阿里是用GROUPAGG来做计算的（只是不知道后续链接是否跑在CDC）。阿里的分钟/小时累计指标的思路（来自FFA2020）：如下图，阿里的思路是如果流批融合的输入源不同，需要批任务调度修正结果。场景二是如果流批结果一样，没有运行批任务。第一种情况无话可说；但如果是第二种情况，这里简单分析一下：我们知道，验证同批结果的前提是，运行批任务产生的结果是主动与流任务的结果进行比较，但是在场景二，批处理任务实际上并没有运行！！！所以这里可以想到的是，需要在事前、事中、事后做大量的监控，保证流任务输出的整体过程没有问题，从而保证和预期的结果一样实现批量输出。新旧研发模式对比总结：上面第一种思路比较理想，基本上是从流任务输出的数据可以批处理方式复用的角度思考，暂且不谈批任务执行的过程。阿里FFA2020的第二个想法在链接软硬件条件上没有那么高，博主觉得比较可行。6.小结本文主要介绍以下三个部分：流批一体化是为解决同一个指标的离线和实时任务输出的数据差异（数据质量）问题而诞生的。数据差异的根本原因是数据乱序。如果要解决理想情况下，这个问题是全链路CDC。更多实用思路请参考阿里FFA2020
