通常情况下我们使用CDC实时监听表销售或订单表数据的LOG时会形成流式的数据，即订单变化时数据是按照变化时间不断的传入到ETL的流程中的，业务希望实时看到订单数据的报表。

CDC每次传入的数据有可能是一条也可能是多条，监听到的流式数据都是订单表的单条数据，但在业务上单表的数据在业务价值上可能缺少一些关键的维度业务数据字段，例如要计算毛利合并客户及产品数据等。

为了补充这些缺少的数据字段之前的做法是先让他入库，然后再用SQL语句或者ETL流程再给他变换一次形成我们需要的宽表数据，虽然这样也可以实现这个业务需求但是失去了数据处理的时效性，即本来是实时流的数据但是到了业务那里变成不是实时的了，因为我们中间有一个定时变换的数据过程。

而现在批流一体化架构的数据集成平台都是采用实时批流合并的方式来实现，下面就介绍ETLCloud如何实现实时的批流合并:

方案一

首先我们设计一个这样的流程来监听订单表数据

这里的关键点就是要拉入一个实时输入流节点，这个节点会接管住所有流入的实时流式数据，后面再用多流合并的节点即可把T00002的批数据拆分后的所有行数据进行合并，这样T00006节点拿到的数据已经是实时合并的宽表数据了，这样就避免了在ODS层中再做一次变换，同时也可以直接就传输给业务系统使用。

当有实时流进入时流程就会执行数据的计算并最终输出宽表数据 这样就解了业务部门想看到实时的订单报表数据的问题了,不需要数仓即可解决.

方案二

我们也可以直接用SQL节点或者脚本节点去把实时流数据进行补全或运算

在SQL节点中逐行去补全数据

例如下面表中的客户数据只有客户的相应信息，如果CDC监听到有客户数据发生变化时希望能实时合并这个客户的订单的相关数据到这条记录中就可以通过上方式进行实现

上述表中只有客户数据，没有订单数据

订单数据在另外一张表中，但是CDC监听到的是客户变化数据

通过客户表中的id和订单表中的customer_id进行关联合并订单表中的数据到客户表中

在实时流节点后面的sql中写上sql语句即可合并数据到实时监听到的数据流中

SQL数据处理节点配置

方案对比

方案一、把实时数据流用图形化的方式进行数据合并后期运维比较方便，如果能用图形描述出来的尽量用图形来做这个流程，这样后期运维方便，而且数据也好监控。

方案二、流程做起来相对简单好理解，如果觉得图形描述这个SQL太复杂就直接贴SQL上来，但是有可能那个SQL语句要合并很多维度数据可能会有几百行,这样后期换其他人来运维就麻烦一点，sql太复杂后面可能不太好理解业务，我们目前发现大部企业是采用这种模式的，因为没有好的图形化ETL所以就被迫做了这样。

方案三、把中间SQL节点用JAVA脚本替代，因为java代码比起sql来说可能对于会编程的人来说更好理解