具体实施方式

为进一步说明各实施例，本发明提供有附图，这些附图为本发明揭露内容的一部分，其主要用以说明实施例，并可配合说明书的相关描述来解释实施例的运作原理，配合参考这些内容，本领域普通技术人员应能理解其他可能的实施方式以及本发明的优点，图中的组件并未按比例绘制，而类似的组件符号通常用来表示类似的组件。

根据本发明的实施例，提供了一种动态实时同步多源大表数据的增强实时计算方法。

现结合附图和具体实施方式对本发明进一步说明，如图1-2所示，根据本发明实施例的动态实时同步多源大表数据的增强实时计算方法，该方法包括以下步骤：

S1、基于虚拟节点一致性哈希算法与结构化查询语言通过单节点存储引擎搭建分布式动态表管理组件；

S2、通过结构化查询语言在分布式动态表管理组件中创建分布式动态表，并通过分布式动态表来标准化多源库表的数据结构；

具体的，在分布式动态表管理组件中通过简易的SQL（结构化查询语言）语句创建分布式动态表，通过动态表来标准化多源的库表数据结构。创建分布式动态表，可以对接多种类型的离线库如：Oracle、PostgrESQL、Godendb、OceanDb、Tidb、ClickHouse等类型的库表，创建动态表语句如：

create table rdm_[库名].[动态表名]（字段名称 类型，字段名称 类型，...，PRIMARY KEY（主键））；

with（dbtype=’oracle’，db=’’，table=’’，dataSourceCode=’’）；

表结构数据存储到MySQL存储介质中，其中，

rdm_：固定格式，表示是分布式动态表；

PRIMARY KEY：指定表的主键；

dbtype：表示对接同步数据的数据库类型；

db：表示对接的库名，主要用来对接多源中库名称，可以不填，系统默认的值为def；

table：表示对接的表名，对接多源类型的表的名称，尽量保持同源表的表名一致，这样可以更好的管理与源表的对应关系；

dataSourceCode：表示配置的数据源编码，通过编码可以关联到配置的数据源连接等信息。

针对查询条件可以创建索引，提升查询的性能，如下语句：

create index on rdm_[库名].[动态表名]（字段名称，字段名称...）；

在分布式动态表管理组件中实现对元数据信息的存储，以方便实时数据开发、管理、运维时使用。

此外，为实现多源库表的数据在实时计算过程的标准化，同时结合分布动态表的特征，需满足实时秒级快速查询、千万或亿级大表的数据存储要求等，因此在设计上选择元数据分布式快速存储，以便于可快速加载元数据，将元数据信息存储到分布式动态表管理组件，方便实时任务开发、运维、管理、稽核等方式可以快速使用多源库表数据。

元数据的创建库通过SQL的create table语句，利用Calcite解析SQL后，将元数据拆分成key-value形式存储到rocksdb组件，如put（rdm_[库名].[动态表名]，字段集）；

为减少元数据与存储设备进行写I/O交互，考虑将元数据：

1，元数据信息比较分散，随机操作多，如果元数据信息直接写到硬盘，性能较顺序写差，所以需要随机变顺序的实现：分布式动态表管理组件使用了日志技术，提交元数据到后备存储之前，首先将元数据写入一个单独的存储区，该区域叫journal（日志）。一个随机写首先写入一个连续的journal，这样就把随机操作变为顺序操作，性能就提升了。

2，元数据修改频繁，如果修改一次，写一次硬盘，性能也会受到影响，所以需要写合并的实现：使用日志技术，针对经变化的数据先写到内存一个区域，后将内存中的日志对应的脏元数据落盘。即使对某个库表的元数据连续修改10次，只需要落盘1次就够了，提升落盘效率。

S3、通过实时同步技术管理分布式动态表元数据变更信息的同步更新；

具体的，当多源库表的字段、数据类型、主键、索引等元数据发生变更时，可以通过实时同步技术（CDC）及时通知分布式动态表管理组件更新元数据信息，同时保障实时数据处理的正确性。

S4、初始化批量导入分布式动态表数据；

具体的，在动态表创建初期，表中没有任何数据，此时需要将离线库表中的数据批量加载到动态表中，批量加载通常发生在实时计算启动之前，由于有些表的数据量过大，批量导入耗时较长，为此批量处采用多种策略实现对大表数据的快速导入，可配置根据需要按需要导入。

S5、核对导入数据的完整性；

具体的，数据在批量同步过程中，由于存在网络、源、实时计算端的稳定性等原因，会导致数据初始化过程中数据丢失，此处提供对导入数据的核对功能（具体见下文）。

S6、对分布式动态表中的数据进行实时更新；

具体的，数据在源端库表中发生INSERT（新增数据）、UPDATE（修改数据）、DELETE（删除数据）操作时，通过异步CDC（Change Data Capture）技术实时捕获离线库表中变化的数据，并将捕获的数据向其它数据库（同构或异构）或应用系统同步，此处主要同步数据给分布式动态表转换存储，及时更新动态表中的数据，通过短事务保障数据的正确性。

S7、对数据同步更新过程进行实时数据的同步监控；

S8、将分布式动态表中的数据通过结构化查询语言转换成实时流数据的虚拟表；

S9、将虚拟表中的数据与预先配置的流数据进行结合流计算；

S10、输出流计算结果。

具体的，通过一个实例呈视多源大表生成、使用分布式动态表的过程，通过实例表明分布式动态表的性能完全可以满足实时计算对多源大表的计算秒级性能要求。

在一个实施例中，所述基于虚拟节点一致性哈希算法与结构化查询语言通过单节点存储引擎搭建分布式动态表管理组件还包括以下步骤：

S11、基于虚拟节点一致性哈希算法实现数据的均衡分布存储；

S12、分析结构化查询语言并转换成可获取到库表信息代码，再通过分布算法与单节点存储引擎的应用程序接口实现数据的读写操作。

具体的，搭建一个分布式存储动态表数据的组件，实现对多源数据库类型的数据的统一管理与存储，为实时计算提供标准的数据接入方式，满足实时任务高效的读写性能、支持分布式扩缩容存储，满足亿级大表的存储需求，提供方便简易的SQL操作支撑，可快速接入与使用分布式动态表管理组件。

分布式动态表管理组件以RocksDB存储引擎为基础，RocksDB是一个嵌入式的key-value存储引擎，其中key和value都可以是任意的字节流，没有大小的限制。接合分布式技术如RPC（远程过程调用），是分布式系统中最基本的技术之一，用于分布式系统中节点间的相互通信。

RocksDB是单节点存储引擎，具备良好高效的存储性能，可满足实时计算数据存储与计算的秒级性能要求，利用RocksDB存储引擎良好的性能，并基于对当前分布式存储系统架构以及相关技术的研究，通过虚拟节点一致性哈希算法分布均衡存储，简易的SQL数据高效读写，设计并实现一个能够提供高效、稳定和可靠的持久化存储服务的分布式动态表管理组件。

利用一致性哈希数据分布策略，有效均衡存储数据，一致性的意义在于：当增加或者删除节点时，只影响与变动节点临近的一个或两个节点，哈希表的其他部分保持不变，一致性哈希的哈希函数与节点数无关，可以方便节点的扩缩容，以及来分布式存储大表的数据。

在一个实施例中，所述基于虚拟节点一致性哈希算法实现数据的均衡分布存储还包括以下步骤：

S111、将整个哈希空间抽象成为虚拟圆环；

具体的，假设哈希函数的值空间为0−（2^32−1），即32位无符号整数，此值可以根据实际部署规模调整，默认为：1024（虚拟节点总数M）。

S112、对哈希函数的值进行存取路由时，首先路由到虚拟节点上，再由虚拟节点寻找到真实的节点；

具体的，如图3所述，A1、B1、E1、C2、A2、D1、C1、D2、B2、E2都是虚拟节点，而物理节点只有A、B、C、D和E五个，物理节点A负责存储虚拟节点A1、A2上的数据，物理节点B负责存储虚拟节点B1、B2上的数据，物理节点C负责存储虚拟节点C1、C2上的数据，物理节点D负责存储虚拟节点D1、D2上的数据，而物理节点E负责存储虚拟节点E1、E2上的数据。

S113、在虚拟圆环上虚拟P个物理节点，将每个物理节点虚拟出N个虚拟节点，再将总的虚拟节点随机映射到虚拟圆环上；

具体的，将虚拟圆环上虚拟一定数量虚拟节点数P，并且都是均匀分布，所以将不会再造成“雪崩”现象，每个虚拟节点都将只对应一个物理节点，将每个物理节点虚拟出N虚拟节点（虚拟节点数量可依据物理机的性能情况适当分配N的值，默认为3），再将这些虚拟节点随机映射到环上。

通过与虚拟总数M取模计算，在虚拟圆环上根据物理节点生成虚拟节点，其中需要以N的值循环生成虚拟节点：

循环（i=0；<N；i++）{

Vcode=hash（md5（随机码+hostName+i））%M

}

其中：

Vcode：虚拟节点的值；

N：单个物理节点的虚拟节点数；

M：虚拟节点总数；

i：自增变量；

随机码：通过随机方法产生的虚拟节点M内的数字；

hostName：表示物理节点名称；

md5：通过md5算法散列化虚拟节点；

Hash：取散列化后的hash值。

以上公式计算的结果通过哈希表保存虚拟节点与物理节点的关系，同时增加版本号来管理修改的信息，由于集群中数据节点的增加或者删除，哈希表也会发生变化，缓存的数据可能过期，所以设计中为哈希表添加了版本号，每次数据哈希表有变化都更新版本号，客户端收到版本号后会与保存的哈希表的版本号对比，如果自己目前保存的哈希表的版本号较低，则就主动向控制节点请求最新的哈希表，缓存到本地。

S114、数据存储与获取；

具体的，客户端会从控制节点获取到数据哈希表，该表记录了每一个虚拟节点存储的数据节点的地址。客户端做hash（key）%M（虚拟总数）运算，即对数据的key值进行MurmurHash哈希，生成哈希值，再对虚拟节点的总个数M求余得到虚拟节点的编号。最后通过查找哈希表得到该虚拟节点所在的数据节点地址列表。接下来客户端就可以访问该虚拟节点的数据节点将数据存储到这个数据节点对应的rocksdb中。key到虚拟节点之间的映射是固定的，但是虚拟节点到数据节点之间的映射是无法固定的，可能的原因有：节点故障不可用；节点增加或者删减。当出现这些情况时，需要重建虚拟节点到数据节点的映射关系，即重建哈希表。

其中，虚拟节点总数公式为：

虚拟节点总数（M）=物理节点数（P）*虚拟节点数（N）。

具体的，在分布式存储中，将数据分布到多个存储节点上，需要达到三个目的：分布均匀，即每个存储节点上的数据量尽可能相近；负载均衡，即每个存储节点上的请求量要尽可能相近；扩缩容时产生的数据迁移尽可能少。

于是引入虚拟节点的一致性哈希，一致性的意义在于：当增加或者删除节点时，只影响与变动节点临近的一个或两个节点，哈希表的其他部分保持不变，某种程度上可以理解为：一致性哈希的哈希函数与节点数无关。

此外，通过Calcite分析SQL语句如：insert into db.table（field1，field2，...）select f1，f2，.. from sroucedb.table，转换成代码可获取到库表名称、字段、源端数据等信息，再将通过分布算法与rocksdb的api实现数据的读写操作；

Apache Calcite是一款开源SQL解析工具，可以将各种SQL语句解析成抽象语法术AST（Abstract Syntax Tree），之后通过操作AST就可以把SQL中所要表达的算法与关系体现在具体代码之中，实时计算Flink内部的SQL实现就是采用Calcite实现，此处主要在Flink中增加Calcite对分布式动态表管理组件的SQL能力。

（1）主要在Calcite的工厂类中增加动态表管理组件的解析工厂；

（2）解析SQL语句，将SQL拆分成分布式动态表管理组件的相关的功能对应；

（3）优化相关的SQL操作，主要对常用的关联操作逻辑执行计划阶段进行优化，

对关联（join）右边节点结果行数如果小于100万这个阈值，则对右边节点的数据进行广播分发，并且因为结果行数较少，放入内存计算。

关联（join）操作时合并时，在合并前先sort（排序），然后合并后才join（关联），以及来提升join计算的性能。

在一个实施例中，所述通过实时同步技术管理分布式动态表元数据变更信息的同步更新还包括以下步骤：

S31、字段变更；

S32、主键与索引字段的变更；

其中，所述字段变更包括字段编码及字段数据类型变更。

具体的，字段编码、字段的数据类型变更时同步更新动态表的元数据；主键与索引字段的变更关系到存储数据key值的变更，此处采用元数据映射关系表来统一管理主键与索引字段的变更。

此外，此处主要实现对元数据变更信息的同步更新，通过实时监控技术（CDC），监控到库表结构数据变化，实时通知分布式动态表管理组件，此处通过：

1）在线化的解析引擎LogRulESplit，可支持解析python，jar文件、Dsl规则语言开发的日志解析器；

2）实现主键、索引字段变更时成本最少化的方式，满足快速变更的要求，通常情况下主键变更会与其关键的外键表字段也需要同步变更方可生效，这样会遍历整个库表元数然后修改，耗时成本0（n），设计通过元数据的拉链表的形式，记录主键的元数据变更与变更时间，在查询时，提供自动转换映射字段能力，实现主键变更成本0（1）。

如图4和5所示，在一个实施例中，所述初始化批量导入分布式动态表数据还包括以下步骤：

S41、根据获取的库表名称，从内存中获取库表的元数据信息；包括主键、索引、属性如连接等信息，然后通过Reader插件连接数据源读取相应的数据；

S42、利用分布式动态表管理组件的入库语句（put key field value [fieldvalue…]）将多个域值（field-value）对应设置到哈希表（key）中；

S43、利用分区策略保存数据，并形成表数据存储格式（利用上述组装key=rdm_[库名]_[表名]_[主键值1]，获取key对应的field value的值，利用put保存数据；如果有创建索引数据，需要同时组装索引的key：rdm_[库名]_[表名]_[索引字段名]_[索引字段值]，value为主表的key值：rdm_[库名]_[表名]_[主键值]，利用put保存数据）。

具体的，可按需导入数据，可选择指定帐期，导入只需要参与计算的帐期数据；配置多通道，并发多线程方式快速导入数据；初始导入可以实现中断续导、重导入、补数据的能力。

此外，分布式动态表管理组件是一种高效的缓存，具备内存数据库，响应非常快的特点，也支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用，其速度远超数据库，性能极高，能读的速度是110000次/s，写的速度是81000次/s，能有效提高系统的性能。

在一个实施例中，所述核对导入数据的完整性还包括以下步骤：

S51、提供批量导入数据，记录成功的记录总数及失败记录总数；

S52、获取读取源表的记录数，并与导入的数据记录进行对比。

具体的，组件实现以初始化数据量记录，主要实现为：

1）通过设计在读取多源库表数据后，利用读的hook（回调）方法，实时记录每一次的读取总数、以及时间，存储到分布式动态表管理组件中，key=rdm_[库名]_[表名]_READER_[序号]，保存的value为“总数（ReadRecords）、发生时间（op_time）”；

2）数据写入分布式动态表管理组件中后，利用写的hook（回调）方法，实时记录每一次的写入成功记录数、失败记录数、以及时间，key=rdm_[库名]_[表名]_WRITER_[序号]，保存的value为“成功记录数（SucESsRecords）、失败记录数（FailRecords）、发生时间（op_time）”；

3）导入完成后，自动根据rdm_[库名]_[表名]_READER*与key=rdm_[库名]_[表名]_WRITER，统计出数据总数，可即时对比导入数据的完整性，以便确认是否重导数据，保障数据有效完整的导入成功。

如图6所示，在一个实施例中，所述对分布式动态表中的数据进行实时更新还包括以下步骤：

S61、连接数据库获取上一次解析成功的位置（如果第一次启动，则获取初始指定的位置或者是当前数据库的log位点）；

S62、连接数据库建立连接，发送DUMP协议指令，模拟同步数据的模式；

S63、离线数据开始推送新增数据、修改数据及删除数据的更新日志数据；

S64、实数据解析器接收日志数据，根据日志类型调用相应的日志解析器进行协议解析并补充相关信息（补充一些特定信息，补充字段名字，字段类型，主键信息，索引信息，以及unsigned类型处理等），解析完成后数据通过库表与主键的哈希值分发送到相应的实时数据接收器；

S65、实时数据接收器接收数据并进行数据存储（同一个表的数据通过排列的机制传递到同一个RealDataSink模块实例，保障数据的顺序）；

S66、利用实时数据接收器的事务机制对该数据进行保障（RealDataSink实现数据的数据存储，是一个阻塞操作，直到存储成功）；

S67、数据更新存储成功后，更新日志的位置数据。

具体的，数据在实时同步更新时，为满足参与实时计算的数据正确性，提供了几种事务的机制，如下：

1）读未提交：如果一个事务已经开始写数据，则另外一个事务不允许同时进行写操作，但允许其他事务读此行数据，该隔离级别可以通过“排他写锁”，但是不排斥读线程实现。这样就避免了更新丢失，却可能出现脏读，也就是说事务B读取到了事务A未提交的数据，保持写数据的一次性，但有可能出现读取的数据不是最新的数据。

2）可重复读取：可重复读取是指在一个事务内，多次读同一个数据，在这个事务还没结束时，其他事务不能访问该数据（包括了读写），这样就可以在同一个事务内两次读到的数据是一样的，因此称为是可重复读隔离级别，读取数据的事务将会禁止写事务（但允许读事务），写事务则禁止任何其他事务（包括了读写），这样避免了不可重复读和脏读。保障参与计算的数据的正确性，数据发生变动时，先根据数据的主键字段值锁定数据行记录，保障此行不再被读写，待操作完成此行数据才可被再次读写。

在一个实施例中，所述对数据同步更新过程进行实时数据的同步监控还包括以下步骤：

S71、提供实时变动写入成功的记录总数、失败记录总数，并根据时间段获取记录总数；

S72、记录实时变动的记录数，根据时间段获取记录总数；

S73、提供补数据的能力，对失败写入重复消息，实现数据补全。

具体的，数据在实时同步过程中，由于网络等原因，会导致同步记录失败，此步提供数据实时监控的能力。

数据在实时同步过程，为保障数据同步有效性，可以实时监控到数据同步的效果，主要实现为：

1）实时累加记录数据以及累计的时间；

2）记录异常或脏记录的数据数量，以及详细的信息；

3）记录同步过程的异常日志，通过分异常日志，实时反馈同步数据过程的异常情况，异常日志分析方式，由于此处的日志格式相当比较固定，利用规则与正则表达式分析提取异常日志中的数据。

如图7所示，实现动态表在流计算中应用，并可以基于flink的SQL机制可以读取分布式动态表的数据，在一个实施例中，所述将分布式动态表中的数据通过结构化查询语言转换成实时流数据的虚拟表还包括以下步骤：

S81、编写读取分布式动态表的结构化查询语言；可包括关联之类的SQL，根据业务场景的特点参与实时计算的动态表的查询条件需要是主键或索引字段，可支持对主键或索引的模糊与精确查询；

S82、通过解析器和验证器分析与校验结构化查询语言的合规性；

S83、将结构化查询语言拆分成代码可编写的算子，识别包括分布式动态表及相关字段信息，分析出字段与值，并根据表数据存储格式进行模糊查询；分析SQL，将SQL拆分成一个个代码可编写的算子，识别rdm_开头的动态表以及相关的字段等信息，通过where条件分析出字段与值，根据前面存储的数据格式拼装出的一系列key或key的模糊查询，根据key值获取通过hmget（key*，f1，f2）或模糊方式SCAN cursor [MATCH pattern] [COUNTcount]，pattern指明key的模糊规则如key*等之类查询一系统的key的数据；

S84、通过应用程序接口及事务机制，保障虚拟表名与分布式动态表名的一致性，实现分布式动态表的数据转换成流数据。

按需从动态表中加载数据到内存的虚拟表中，虚拟表利用flink的窗口或内存来按需存储数据，虚拟表由系统自动创建，表名与动态表保持一致，在生成table格式的虚拟表数据时，需要利用上步提到事务机制，保障此行数据在更新时不读取脏数据，虚拟表名与分布动态表名保持一样，从而实现分布式动态表的数据转换成流数据，在使用的过程中步骤S5会详细介绍加载数据的方法。

利用calcite的对SQL的性能优化的能力，优化组装执行的SQL，Optimizer主要目的就是减小SQL所处理的数据量、减少所消耗的资源并最大程度提高SQL执行效率如：剪掉无用的列、合并投影、子查询转化成JOIN、JOIN重排序、下推投影、下推过滤等。目前主要有两类优化方法：基于语法（RBO）与基于代价（CBO）的优化。

RBO（Rule Based Optimization）通俗一点的话就是事先定义一系列的规则，然后根据这些规则来优化执行计划。假如某一个RelNode树：

LogicalFilter

LogicalProject

LogicalTablEScan

则可优化成：

LogicalProject

LogicalFilter

LogicalTablEScan

FilterJoinRule

此Rule的使用场景为Filter在Join之上，可以先做Filter然后再做Join， 以减少Join的数量等等，还有很多类似的规则。

CBO（Cost Based Optimization）通过某种算法计算SQL所有可能的执行计划的“代价”，选择某一个代价较低的执行计划，一般来说RBO无法判断哪种执行计划优化更好，只有分别计算每一种JOIN方法的代价，选中其中最好的一种。根据优化的SQL通过flink的实时计算引擎执行SQL，并产生实时数据结果。

具体的，通过SQL语句，可连续查询分布式动态表的数据，按需加载分布式动态表的数据转换成流数据，SQL的写法如：select r1.name，r1.price from rdm_[库名].[分布式动态表名] where [索引字段或主键字段]；

其中：

rdm_：表示是读取的分布式动态表；

[库名]：用来区分从哪个源端的库同步过来的数据；

[分布式动态表名]：通过create table创建的表名，通常要求同源端的库表名称保持一致；

[where]：主要针对表的主键字段与索引字段的过虑来定位到具体记录；

将动态表的数据通过SQL加载，然后转换成实时流数据的虚拟表，虚拟表由系统自动创建，表名与动态表保持一致，同时在读取数据过程通过事务控制数据一致性。

如图8和图9所示，在一个实施例中，所述将虚拟表中的数据与预先配置的流数据进行结合流计算还包括以下步骤：

S91、利用实时计算引擎的结构化查询语言读取虚拟表与流表的数据；利用FlinkSQL读取虚拟表与流表的数据，如读取虚拟表（rdm_db.dim1）与流表（flow.t1）的关联计算SQL，利用Flink的算子能力计算数据：

select a.pkey，a.fkey，a.udata，b.udatetype from flow.t1 a， rdm_db.dim1b where a.fkey=b.fkey；

S92、按需加载虚拟表的数据，解析加载虚拟表的数据的条件，根据条件通过异步多线程方式从分布式动态表中加载数据到实时计算引擎的内存中；按需加载虚拟表的数据，解析加载虚拟表的数据的条件，根据条件通过异步多线程方式从分布式动态表中加载数据到实时算引擎的内存中；

S93、虚拟表数据加载过程中，启用异步多并发方式传递数据，根据数据量大小来动态分配传递的并发数；虚拟表数据加载过程中，启用异步多并发方式传递数据，根据数据量大小来动态分配传递的并发数，提升传递数据的性能；

S94、加载时根据表分组、数据的读取范围以及集群资源的空闲情况拆分成并发取数端，并进行并发读取数据。加载时根据表分组，根据数据的读取范围以及集群资源的空闲情况拆分成适当的并发取数端，并发读取数据，保障上步中的数据可以快速实时传递。

具体的，为实现流数据与虚拟表的结合计算，充分利用flink SQL或api开发各种流计算应用，Flink是最适合的低时延的数据处理（Data ProcESsing），且具备高并发处理数据，兼具可靠性等特性，通过下图8所示的5步分步实现流数据与虚拟表的计算，从而实现结合外部源过亿大表的复杂业务逻辑的实时计算秒级要求。通过上步创建的虚拟表，利用flink的SQL读取虚拟表的数据，同时可以将虚拟表的数据与流的数据进行关联、聚合、比较等的计算，参与计算的步骤为：

1）利用flink SQL的现有能力，可直接读取虚拟表的数据，如图8，第1步列出的3条SQL语句分别代表关联计算、聚合计算、取值等；

2）同样利用flink的现有能力，对虚拟表（virtual table）的数据（virtual data）与流表（flow table）的数（flow data）据进行各种类型的计算，如关联（join）、聚合（Aggregate）、取值（GetOneRecord）等计算，此处需要保障虚拟表的数据已到达，数据到达的通过下面的步骤实现，并利用上面提到的flink 中的calcite的优化能力，优化SQL的执行计划，从而加速提升计算的性能；

3）按需加载虚拟表的数据，利用上面提到的calcite解析SQL，拆分出虚拟表部分的SQL，由于本次对虚拟表主要通过主键或索引的模糊与精确查询，所以可以转换api形式如hmget（key*，f1，f2）（见步骤S4），然后预判取数的形式（单条数据，多条固定数据量的记录，关联查询的记录等）计算将要生成的取数记录数来切分取数的任务，将取数据的语句的任务切分成多个小的子任务，以便于并发执行。

预判取数记录量依据为：

单条数据、多条固定数据量的记录：

records=count（split（数据集，分隔符））；

说明：

分隔符默认为’，’；

通过split方法拆根据指定的分隔符来拆分数据集，然后用count计算记录数；

关联查询的记录等未知数据量：

records=历史记录数或类似的表记录数（N）*（1+10%）+log2N；

说明：根据历史的记录数或类似的表推算数据的10%的误差，如果没有历史记录数或类似的表的数据，根据经验设定默认记录5万条，再加上log2N的一个数据增涨值；

4）步骤3）的传递方式判断依据，虚拟表数据加载过程中，启用异步多并发方式传递每个表的数据，根据表的数据量大小来动态分配传递的并发数，提升传递数据的性能；

数据传递动态分配传递的并发数判断依据：

每个表的并发数=max（RECORDS/100/响应时长，平均cpu核数）*并发收益率；

其中，records表示记录数，响应时长表示数据加载的时长通常在秒级内，同时系统为保障性能，最少可利用的硬件资源（平均cpu核数，一般为8核），并发收益率表示可以利用到硬件资源的比率，根据经验值默认为0.6；

5）计算取数据并发数判断依据，加载时根据表分组，根据数据的读取范围以及集群资源的空闲情况拆分成适当的并发取数端，并发读取数据，保障上步中的数据可以快速实时传递；

分组数=count（表的数量）；

为保障读取的数据可以及时传递，采用读取与传递通道一对一的方案，即：每个表取数的并发数=每个表传递数据的并发数；每一个Reader（读）任务都由Group（表分组）负责启动，Reader启动后，会固定启动Reader—>传递数据—>虚拟表的线程来完成任务同步工作。

具体的，针对步骤S10输出流计算结果实例效果呈视：

例如某电信公司自然人数据归整，实时收集某些电子渠道数据与某电集的自有系统的数据对比更新数据，更新规则为：

客户的证件类型+证件号码一致情况下，客户名称不一致的更新规则：

1级规则：订单来源，某类型电子渠道订单>存量系统的来更新客户名称；

2级规则：证件有效期，证件有效期年限更长的来更新客户名称；

3级规则：是否有用户，有用户大于没用户的来更新客户名称；

针对以上需求，实现步骤如下：

1）创建分布式动态表客户信息表、用户表；

2）初始化加载分布式动态表客户信息表（亿级）、用户表的数据（亿级）；

3）配置源表与分布式动态表的实时数据同步任务；

4）通过SQL实现实时业务逻辑开发：

Select客户名称，证件有效期，订单来源from rdm_xxtel.custinfo（动态表中的客户信息表）where certi_no（证件号码）=[value]（具体的值）and certi_type（证件类型）=[value]（具体的值）；

Select count（1）from rdm_xxtel.userinfo（动态表中的用户信息表） wherecust_id（客户主键）=[value]（具体的值）；

5）电子渠道数据通过流数据接入与上述的4）接合计算判断：

如果：订单来源=电子渠道，某类型电子渠道订单，更新存量系统的客户名称；

如果：电子渠道，证件有效期>动态表中的客户信息表，证件有效期，更新存量系统的客户名称；

如果：动态表中的用户信息表，用户数<0，刚更新存量系统的客户名称；

说明：此案例多次用到动态表中的数据参与实时计算过程，如上面4）5）步，均需要根据存量系统的客户信息表（亿级大表），用户信息表（亿级大表）来判断业务逻辑。

如图9所示，性能表现如下：（读、写分布式动态表的数据可以达到秒级，完全满足实时计算要求）。

为了方便理解本发明的上述技术方案，以下就本发明在实际过程中的工作原理或者操作方式进行详细说明。

在实际应用时，实时计算补全性能满足实时计算要求：在实时数据搬迁过程中，因为修改的业务逻辑只传递了修改的字段，大部分字段需要通过关联外部数据源实现数据补全，外部数据源如大数据组件hbase、clickhouse，关系型数据库mySQL、oralce，非结构数据库等获取数据时满足实时计算性能的要求。

复杂过虑的条件满足实时计算要求：在实时计算过程，需要接合已经存在的数据条件过来过虑实时流的数据，此时依然需要连接外部数据，通过外部接入的数据来判断流数据是否满足过虑条件，通过存在读取外部数据源的性能以及连接数据限制等问题，此发明主要解决外部数据源读取的性能以及限制登录数限制等问题。

复杂业务逻辑转换满足实时计算要求：实时计算在计算过程，通过业务逻辑要求数据从一种状态转换到另一种状态，如外部数据源的数据进行聚合计算、状态的值转换等均需要外部数据源的数据深度参入实时计算，此时对外部数据源的读写性能要求都要求非常，需要外部数据能够实时计算秒级的要求。

支撑多种外部数据源加入增强型实时计算，并满足秒级的实时计算要求：外部数据源如大数据组件hbase、hive、hdfs、kudu、clickhouse，关系型数据库mySQL、oralce、PostgrESQL等，非结构数据库ES等。

综上所述，借助于本发明的上述技术方案，通过利用当前优秀的开源技术的组合，优化修改开源组件，并在适当的环节，巧妙利用技术通过层层分解，分步分层加载大表数据，按需加载大表数据，有效将大表按需拆分解成小表，同时充分有效利用内存的高效特性，提供大表存储数据组件，标准化多源库表数据的结构，加速了实时计算的性能，有效的解决实时业务对存量大表的计算性能痛苦问题；利用批量与推送协议的方式同步源端的数据，不对源端库表造成访问的压力，可以满足大部分实时流与离线数据结合计算的业务场景要求，拓宽了实时计算能支持的业务范围，很好的解决了实时计算结合外部数据源过亿大表下的复杂业务逻辑的实时计算要求。基于当前主流的实时计算引擎Flink，在流数据与多源外部数据源的大小表数据结合时计算，依然可以满足实时的性能要求，满足大并发，高吞量的实时数据处理的复杂业务处理能力，主要解决流计算与外部数据源的大表进行联合计算时秒级性能要求，外部源的主要有大数据组件hbase、hive、hdfs等，关系型数据库mySQL、oralce等，非结构数据库ES等，同时在流计算与外部源数据计算，需要满足外部源的增量数据也可以实时同步参与联合计算，保障实时流复杂业务计算过程中的性能与正确性。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。