一种基于流数据的实时建宽表的方法与流程

1.本技术涉及一种基于流数据的实时建宽表的方法，属于数据处理领域。


背景技术：

2.无论是传统数仓建设，还是现代数据驱动的应用业务，大部分的数据开发工作就是要构建一些新的数据表，为各种分析模型或业务模型服务。特别是互联网公司由于数据量普遍偏大，多表关联的方式通常不会被采用。这种情况下构建宽表用于支持各种业务查询是非常主流的数据开发工作。
3.传统的建模、建表都是基于sql来完成的。基于sql的方式有这些局限性：1、目标模型表和原始表数据脱节：sql是基于一个固定数据集来进行查询计算并输出到目标表的方式，适合于定期批量运算。如果涉及到的原始表比较大，那这种操作往往会需要执行数分钟甚至数小时，这样会造成目标的数据无法反应当前真实的状态。
4.2、并发任务性能瓶颈：由于传统建模的全表计算模式，在数仓内同时进行的任务基本不能超过2-3个。这个严重限制了传统数据平台跑批建模的能力。


技术实现要素：

5.根据本技术的一个方面，提供了一种基于流数据的实时建宽表的方法，该方法具有实时性高、灵活性高、快速响应、全局模型关联、支持跨库乱序的特性。
6.基于流数据的实时建宽表的方法，至少包括以下步骤：数据引擎采集数据，保存至数据库中；将采集到的所述数据转化为结构化数据；将所述结构化数据保存到数据缓存库；模型计算引擎接收数据更新事件，根据所述结构化数据与目标模型是否存在映射关系，提取与目标主表相关联的所述结构化数据，更新到所述目标主表中。
7.可选地，所述数据缓存库为mongodb。
8.可选地，所述结构化数据保存在所述数据缓存库的统一数据缓冲层中。
9.可选地，所述统一数据缓冲层为fdm层。
10.可选地，所述数据引擎采集数据的同时，日志采集器形成数据日志，并将所述数据日志保存到所述数据缓存库的日志存储中心；所述日志存储中心将所述数据日志与任务采集器同步，从而实现数据日志与用户目标数据库的共享。
11.可选地，所述模型计算引擎接收数据更新事件，包括：所述模型计算引擎接收到的数据更新日志；发送数据库共享关联指令；
若数据日志与用户目标数据库的共享成功，逐步判断所述数据更新日志是否包含日志采集任务，所述日志采集任务是否包含所需要的表，所述日志采集任务的起始采集时间是否早于上一次同步任务的起始时间，如是，则通过所述日志存储中心读取数据日志，作为增量数据日志；若数据日志与用户目标数据库的共享不成功，或所述数据更新日志不包含日志采集任务，或所述日志采集任务不包含所需要的表，或所述日志采集任务的起始采集时间晚于上一次同步任务的起始时间，则所述模型计算引擎直接读取所述数据库中的数据日志，作为增量数据日志。
12.可选地，对于与目标模型存在映射关系的所述结构化数据，从所述数据缓存库中查询含有该结构化数据的表，即子表，将所述子表与目标主表数据合并，更新目标主表；对于与目标模型不存在映射关系的所述结构化数据，将该结构化数据写入数据缓存库的子表缓存表中，根据新建立的映射关系，将子表更新到目标主表中。
13.本技术能产生的有益效果包括：1）本技术所提供的基于流数据的实时建宽表的方法，实时监听源数据的增量变化，能达到亚秒级的延时，与传统定时轮询方式（基于sql语句）相比，具备更高的实时性；2）本技术所提供的基于流数据的实时建宽表的方法，具备多模型存储能力，支持随时修改模型，与传统关系型模型（模型预先创建且修改成本较高）相比，对于模型变化的需求响应更加及时且全局灵活性。
14.3）本技术所提供的基于流数据的实时建宽表的方法，基于已有的数据模型进行简单的配置，创建数据同步任务，就可以实现数据建模；现有的数据处理平台（flink）需要代码需要编码的配合，开发周期较长，与之相比，本技术方法具有低代码数据开发、甚至零代码的能力，达到了快速响应业务的目的。
15.4）本技术所提供的基于流数据的实时建宽表的方法，在同步过程中会有统一数据缓存层，因此支持关联全局数据，与flink支持时间窗口时间缓存相比，功能更强大。
16.5）本技术所提供的基于流数据的实时建宽表的方法，将所有数据源汇聚到统一数据缓存层；当子表事件先进入时，会先写入数据缓存层，后续主表事件过来可以从数据缓存层中查询相关联的子表数据，进行模型合并计算，具有支持跨库乱序的特点。
附图说明
17.图1为本技术方法一种实施方式的流程示意图；图2为本技术方法中共享模式的流程示意图；图3为本技术的更新事件流程示意图。
具体实施方式
18.下面结合实施例详述本技术，但本技术并不局限于这些实施例。
19.本技术一种基于流数据的实时建宽表的方法，其流程如图1所示，包括以下步骤：数据引擎采集数据，保存至数据库中；如图2所示，所述数据引擎采集数据的同时，需要对日志数据进行挖掘和共享，具体为：
日志采集器形成数据日志，并将所述数据日志保存到所述数据缓存库的日志存储中心；所述日志存储中心将所述数据日志与任务采集器同步，从而实现数据日志与用户目标数据库的共享。
20.将采集到的所述数据转化为结构化数据；将所述结构化数据保存到数据缓存库；模型计算引擎接收数据更新事件，根据所述结构化数据与目标模型是否存在映射关系，提取与目标主表相关联的所述结构化数据，更新到所述目标主表中。
21.如图3所示，所述模型计算引擎接收数据更新事件，包括：所述模型计算引擎接收到的数据更新日志；发送数据库共享关联指令；若数据日志与用户目标数据库的共享成功，逐步判断所述数据更新日志是否包含日志采集任务，所述日志采集任务是否包含所需要的表，所述日志采集任务的起始采集时间是否早于上一次同步任务的起始时间，如是，则通过所述日志存储中心读取数据日志，作为增量数据日志；若数据日志与用户目标数据库的共享不成功，或所述数据更新日志不包含日志采集任务，或所述日志采集任务不包含所需要的表，或所述日志采集任务的起始采集时间晚于上一次同步任务的起始时间，则所述模型计算引擎直接读取所述数据库中的数据日志，作为增量数据日志。
22.对于与目标模型存在映射关系的所述结构化数据，从所述数据缓存库中查询含有该结构化数据的表，即子表，将所述子表与目标主表数据合并，更新目标主表；对于与目标模型不存在映射关系的所述结构化数据，将该结构化数据写入数据缓存库的子表缓存表中，根据新建立的映射关系，将子表更新到目标主表中。
23.本技术将源端数据库的日志，抽取到数据缓存库（mongodb）中，后续任务作为消费者，直接从数据缓存库中获取自身需要的数据，再传递到后续的任务处理当中。目前日志数据的挖掘共享模式可用于oracle，mysql，postgresql，sqlserver，mongodb等。mongodb作为数据缓存库的优势有：内存数据库的高性能，又可以像mysql一样持久化。由于日志数据缓存在mongodb（间接是在硬盘上），这样可以快速解决大事务场景，特异性事务，同步故障后无法溯源的问题。
24.在处理大事务的场景下，日志数据的挖掘共享以缓存mongodb为载体，记录大事务中所有的数据变化，当大事务结束后，所有的数据变化从mongodb中直接取出消费，与大事务无关的其他事务正常处理，两者互不干扰，从而减少大事务对同步性能的影响，同时由于使用mongodb记录，系统不会因为大事务的发生导致数据丢失或者软件因为内存溢出崩溃。在这个大事务场景中，一般产生的数据变化量较大，由于我们使用的是mongodb作为中间载体，其毫秒级别的插入/查询速度的特性，不会造成同步时间的增长，这点经过实测比oracle ogg处理最大事务还要大3.2倍。
25.在针对特异性事务（部分回滚，违反约束事务等）情形下，因为各种数据库实现不同，源库的事务往往会有很复杂的非常规场景，例如部分回滚，违反数据库约束的事务等。在源库内对这些复杂场景进行直接进行处理需要耗费大量的源库资源，影响业务。在使用
基于缓存的共享日志以后，我们能够基于我们积累的事务只是针对各种复杂场景进行较为全面的分析匹配，并进行相应的处理。
26.非缓存模式的日志通常很快就会被清除或者归档。基于缓存以后，由于有持久化能力，可以按需求动态调整日志缓存的日期和大小。这样对以后发现数据不一致时进行追溯，提供了历史变化数据，使得同步故障后溯源更加便捷。
27.在日志数据的挖掘共享模式下，比如oracle为源库的同步场景中，系统只需要1个logminer进程，即可获得这个数据库中所有的目标数据及其实时变化（注：在oracle中每启动一个logminer进程都会增加源库的内存，磁盘，cpu损耗，并且会产生日志级别的争用，logminer任务大于5个就会源数据库产生性能上的影响），即减小了数据增量更新过程对于源库的影响。
28.每种数据库的日志挖掘都有不小的差异性，tapdata结合共享挖掘模式对每种数据库的挖掘都进行优化，以oracle为例，在经过大量的内部实验以及客实际场景的验证，我们总结出来logminer的优化项，性能上有50-100倍的差别。对于挖掘的先决条件我们形成了固定配置项，包含了源端oracle的优化设置，用于减少源端的性能损耗以及提高logminer的性能。对于挖掘过程中，在不同同步场景中，我们设置了数个关键参数，能够识别当前同步效率、同步状态，动态调整同步参数，时刻保证最优的同步效率。例如参数cursor fetch size，这个参数决定oracle每次输送日志到系统的行数，在大事务场景下，这个参数需要设置成更大的值，比如1000，此时同步效率会有50-100倍的差别，但是不利于正常事务的同步，因为oracle会基于这个值的设置捕获到足够的fetch size数量后才会推送到系统，如果设置为1000，则需要捕获够1000个事件才会开始推送，这样不利于小事务的同步，当小事务频繁发生时候，因为fetch size过大导致同步延迟，这时候系统会根据同步效率，动态调整这个参数，无需人工干预，即能保持最优同步效率。
29.场景例构建客户保单视图（customerpolicy）时，具体技术实现流程：a、客户表（customer）和保单表（policy），一个客户有多份保单，属于一（客户）对多（保单）的关联关系，通过客户表的客户id（id）和保单表的客户id（customer_id）进行关联；b.在实际的数据采集过程中，会遇到时序问题，以下为时序问题场景及处理方式：i.老客户新创建一份保单，数据采集时会先读取到一条客户（customer）记录，将客户数据根据客户id（id）写入到目标（customerpolicy）；第二再读取到保单（policy）数据，根据保单信息中的客户id（customer_id）与目标（customerpolicy）的客户id（id）进行关联写入，合并成内嵌数组。
30.ii.新客户新创建一份保单，当客户数据和保单数据在同一事务中提交时，数据采集有可能会先读取到保单（policy）信息，但目标（customerpolicy）中还没有客户信息，因此会将保单信息先缓存中临时表中；后面读取到客户（customer）信息时，再根据客户id（id）与临时表中找到客户对应的保单信息，再同步到目标表（customerpolicy）。
31.以上所述，仅是本技术的几个实施例，并非对本技术做任何形式的限制，虽然本技术以较佳实施例揭示如上，然而并非用以限制本技术，任何熟悉本专业的技术人员，在不脱离本技术技术方案的范围内，利用上述揭示的技术内容做出些许的变动或修饰均等同于等
效实施案例，均属于技术方案范围内。