当前位置: 首页 > 科技观察

当我们在做流批集成的时候,我们在做什么?

时间:2023-03-15 15:46:07 科技观察

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