大数据环境下实现实时数据关联的系统及方法
【专利摘要】本发明涉及一种大数据环境下实现实时数据关联的系统及方法，其中系统包括关联调度框架，用以对业务对象进行组内关联、组间关联和并发调度；分布式存储框架，用以为每个Redis服务器的主服务器创建一个连接池、存储当前数据关联相关的数据、将超过更新时间限制的冷数据和超过内存容量限制的超量数据发送至关系数据库以及对已经转移到所述的关系数据库的组内关联键值和组间关联键值进行查询；关系数据库，用以存储组内关联键值、组间关联键值、组内上下文和监控上下文；Redis服务器。采用该种结构的大数据环境下实现实时数据关联的系统及方法，可以实现支撑海量流式数据的实时关联，满足各种场景下的复杂关联需求，模型的通用性强，具有更广泛应用范围。
【专利说明】大数据环境下实现实时数据关联的系统及方法
【技术领域】
[0001]本发明涉及计算机应用领域，尤其涉及高吞吐量流式数据的实时监控领域，具体是指一种大数据环境下实现实时数据关联的系统及方法。
【背景技术】
[0002]大数据计算的时代已经到来，该领域主要分为两个方向:静态数据的批量处理，流式数据的实时处理。实时数据关联是接收多个数据源实时产生的数据流，并按照一定的业务相关性进行过滤、去重/变更、生成关联键值、组内关联、组间关联、多方拆分、后续环节触发等一系列处理。关联后的数据呈现出一个个数据上下文的分组，可以满足如流程还原、告警判断、趋势分析、状态监控等后续处理环节的需要。大数据的实时关联是整个流式数据处理过程中的一个关键环节，对性能、伸缩性、可用性等质量指标都有很高的要求。例如对关联逻辑的通用性设计，对大数据的支撑能力需求、对关联性能的低延迟需求等，都是较为复杂的技术问题。
[0003]业界对于数据关联最常见的实现方式就是通过关系数据库。很多监控类系统也都是基于SQL和数据仓库技术对海量数据进行关联的。其关联机制大致如下:在系统上线之初对期初数据进行处理，数据分析系统或业务监控系统通常会从各业务系统中导入大量的历史数据，然后根据关联规则对这些历史数据进行重新组合；在系统运行过程中，会采用数据复制或ETL技术自动从各业务系统抽取数据加载到数据仓库，导入之后触发一系列存储过程来完成数据关联逻辑。
[0004]以上技术方案都是基于SQL和关系数据库进行数据关联，虽然能够利用关系数据库强大的计算能力，但也带来一些无法克服的缺点。数据仓库是用来存储海量静态数据的，SQL的执行过程是每次对两个表进行关联，在业务数据类型众多的实际场景下，将产生大量的事实表关联，随着数据量的增长，关联环节的效率会出现明显的下降。并且基于SQL的方式本质上是一种批量处理，无法支撑实时流式数据的场景，这种场景需要很低的处理延时。数据关联环节本身也是一个复杂的处理过程，包括过滤、去重、变更、关联、拆分、触发后续环节等。关联本身也是层次化的，有关联键值的生成、组内关联、组间关联、并行关联等，这一套复杂的处理逻辑还需要满足高吞吐量低延迟、良好的横向扩展能力等质量需求，这些都是基于SQL的技术方案很难达到的。
【发明内容】
[0005]本发明的目的是克服了上述现有技术的缺点，提供了一种能够实现支撑海量流式数据的实时关联、满足各种场景下的复杂关联需求、模型的通用性强、架构的伸缩性强、具有更广泛应用范围的大数据环境下实现实时数据关联的系统及方法。
[0006]为了实现上述目的，本发明的大数据环境下实现实时数据关联的系统及方法具有如下构成:
[0007]该大数据环境下实现实时数据关联的系统，其主要特点是，所述的系统包括:[0008]关联调度框架，用以对业务对象进行组内关联、组间关联和并发调度；
[0009]分布式存储框架，用以为每个Redis服务器的主服务器创建一个连接池、存储当前数据关联相关的数据、将超过更新时间限制的冷数据和超过内存容量限制的超量数据发送至关系数据库以及对已经转移到所述的关系数据库的组内关联键值和组间关联键值进行查询；
[0010]关系数据库，用以存储组内关联键值、组间关联键值、组内上下文和监控上下文，所述的关系数据库与所述的分布式存储框架相连接；
[0011 ] Redis服务器，与所述的分布式存储框架相连接。
[0012]较佳地，所述的关联调度框架包括:
[0013]业务对象生成模块,用以生成业务对象；
[0014]关联配置管理模块，用以管理关联过程中用到的所有规则；
[0015]业务对象去重模块，用以根据组内关联的结果对业务对象进行去重或变更操作
[0016]组内关联模块，用以对分组内的业务数据对象进行关联；
[0017]附加对象关联模块，用以对附加类型的业务对象进行附加关联操作；
[0018]组间关联模块，用以对多个分组进行关联；
[0019]多方拆分模块，用以根据多方组的组内上下文将当前的监控上下文进行拆分；
[0020]后续环节触发模块，用以对当前监控上下文进行还原点判断并当代表着还原点的业务对象已到来时将监控上下文发送至后续环节；
[0021 ] 并行调度控制模块，用以对业务对象进行调度控制。
[0022]较佳地，所述的分布式存储框架包括:
[0023]连接池管理模块，用以根据配置表中Redis服务器的地址以及连接池参数为每个Redis服务器的主服务器创建一个连接池；
[0024]分片分库模块，用以存储当前数据关联相关的数据；
[0025]宕机等待模块，用以进行宕机后的线程等待；
[0026]主从复制模块，用以将主机的数据复制到从机中进行保存；
[0027]自动运维模块，用以通过主从复制功能提供内存数据的快照冗余副本、通过自动备份功能保存多个时间点的数据快照备份以及通过日志重写功能降低日志文件的大小；
[0028]冷数据与超量数据转历史模块，用以将超过更新时间限制的冷数据和超过内存容量限制的超量数据发送至所述的关系数据库；
[0029]布隆过滤模块，用以对已经转移到所述的关系数据库的组内关联键值和组间关联键值进行查询。
[0030]本发明还涉及一种基于所述的系统大数据环境下实现实时数据关联的方法，其主要特点是，所述的方法包括以下步骤:
[0031](I)所述的关联调度框架对业务对象进行组内关联、组间关联和并发调度；
[0032](2)所述的关联调度框架从所述的分布式存储框架中获取连接；
[0033](3)所述的分布式存储框架在定义的时间点进行冷数据与超量数据的转移以及布隆过滤器的重建。
[0034]较佳地，所述的关联调度框架包括业务对象生成模块、关联配置管理模块、业务对象去重模块、组内关联模块、附加对象关联模块、组间关联模块、多方拆分模块、后续环节触发模块和并行调度控制模块，所述的关联调度框架对业务对象进行组内关联、组间关联和并发调度，包括以下步骤:
[0035](11)所述的关联调度框架进行启动初始化操作；
[0036]( 12)所述的分布式存储框架进行启动初始化操作；
[0037](13)所述的关联调度框架收到业务数据并生成服务数据对象；
[0038]( 14)所述的关联调度框架根据业务数据类型过滤出对应的关联配置；
[0039](15)根据获取的关联配置，所述的组内关联模块对服务数据对象进行处理；
[0040](16)所述的业务对象去重模块根据组内关联的结果对业务对象进行去重或变更操作；
[0041]( 17)所述的附加对象关联模块对附加类型的业务对象进行附加关联操作；
[0042](18)所述的组间关联模块收到组内关联输出的结果，进行组间关联操作；
[0043](19)所述的多方拆分模块收到组间关联的结果，根据多段与多方组的配置进行多方拆分操作；
[0044](1-10)所述的后续环节触发模块收到多方拆分的结果，根据还原点配置判断是否触发后续环节。
[0045]更佳地，所述的关联调度框架进行启动初始化操作，包括以下步骤:
[0046](111)从数据库模型表中查询关联配置信息并加载到所述的关联调度框架的缓存；
[0047](112)从数据库模型表中查询业务对象配置信息并加载到所述的关联调度框架的缓存；
[0048](113)从数据库模型表中查询组间与组内关联键值对应的业务规则表达式并加载到所述的关联调度框架的缓存；
[0049](114)构建出业务对象类型与关联配置的对应关系；
[0050](115)从数据库配置表中查询所述的关联调度框架的配置参数；
[0051](116)使用所述的关联调度框架的配置参数初始化组内关联模块与组间关联模块；
[0052](117)使用关联配置信息中的数据权限和引用规则初始化关联配置管理模块；
[0053](118)使用多段与多方组信息初始化多方拆分模块；
[0054](119)使用还原点配置信息后续环节触发模块。
[0055]更佳地，所述的分布式存储框架进行启动初始化操作，包括以下步骤:
[0056](121)从配置库中读取所有Redis服务器的信息，包括服务节点名、主从节点的ip与端口、最大最小连接数、连接等待时间、获取连接时是否测试连通性；
[0057](122)根据配置信息，为每一个Redis服务器初始化连接池；
[0058](123)以Redis节点名为key，把所有Redis服务器放入连接池缓存中；
[0059](124)从Redis分片配置表中获取关联配置定义名与Redis服务器节点名的对应关系;
[0060](125)以关联配置名为键，以Redis节点名为值，构建本地的分片缓存；
[0061](126)轮询Redis节点连接池缓存，对每一个Redis节点获取连接，使用连接调用selectO方法进入dbO即初始信息区域；[0062](127)在dbO中读取分库信息，即关联配置定义名与分库号的对应关系，以关联配置名为键，以库号为值，在本地构建分库信息缓存；
[0063](128)轮询分库缓存,调用select方法进入每一个分库,如果当前分库不存在有序集合MC-DATE，则查询当前分库所有的监控上下文的id，以MCID作为key，以当前日期数字作为score，构建有序集合MC-DATE，作为冷数据和超量数据转历史的判断依据；
[0064](129)从配置表中查询批量转历史的触发时间点、冷数据的未使用天数、内存超量的百分比，构建布隆过滤器，启动转历史定时线程。
[0065]更佳地，所述的收到业务数据并生成服务数据对象，包括以下步骤:
[0066](131)根据业务对象名从业务对象模型缓存中获取业务对象配置信息；
[0067](132)根据业务对象命名空间与业务对象名字拼在一起为typename,调用第三方commonj-sdo组件从缓存中清除该typename ；
[0068](133)从业务对象配置信息中取出xsd字符串，解析xsd字符串并加载xsd ；
[0069](134)根据指定的名称空间和业务对象名称，构建业务对象服务数据对象-commonj.sd0.DataObject ；
[0070](135)从服务数据对象中获取类型commonj.sd0.Type,继而获取属性名commonj.sd0.Property ；
[0071](136)根据属性名从业务数据中获取对应的值并设置到服务数据对象中。
[0072]更佳地，所述的根据业务数据类型过滤出对应的关联配置，包括以下步骤:
[0073](141)根据业务数据的类型从关联配置缓存中口获取所有关联配置；
[0074](142)获取业务目录数据权限的开关，如果开启则获取数据权限字段名并验证数据权限；
[0075](143)从关联配置中获取其所述的业务目录，进而获取该业务目录对应的数据权限值；
[0076](144)根据数据权限字段名，从当前业务对象中获取字段值；
[0077](145)对比业务目录数据权限值和当前业务对象的数据权限值，如果匹配成功则将该关联配置加入待处理的关联配置集合；
[0078](146)根据关联配置的引用规则和当前业务对象，使用业务规则表达式组件计算出结果值并过滤掉结果为失败的关联配置。
[0079]更佳地，所述的对服务数据对象进行处理，包括以下步骤:
[0080](151)以关联配置id为参数从分布式存储框架中获取连接；
[0081](152)根据当前业务对象的组内关联键值生成规则，调用表达式解析器生成组内关联键值；
[0082](153)以所有生成的组内关联键值为冲突检测的观察对象，调用Redis连接的Watch方法监视所有关联键值；
[0083](154)根据当前业务对象的业务主键生成规则，调用表达式解析器生成业务主键的值；
[0084](155)根据生成的组内关联键值，调用Redis连接的查询方法，查询出与该组内关联键值对应的组内上下文的所有id组成的列表；
[0085](156)开始事务，调用Redis连接的Multi命令；[0086](157)当没有查询到组内上下文时，使用布隆过滤器提供的哈希函数对关联键值进行哈希后再到布隆过滤器中查询，如果命中则从关系数据库中把相关的信息一并提取出来重新放入Redis ；
[0087](158)当没有查询到组内上下文且布隆过滤器也没有查询到结果时，生成新的组内上下文并置入当前业务数据，调用Redis连接的方法保存这个新生的组内上下文，保存组内关联键值与该组内上下文的id的对应关系；
[0088](159)当查询到一个组内上下文时，使用业务主键值在当前组内上下文中查找业务对象，如果找到，则继续步骤(15-10)，否则继续步骤(15-11);
[0089](15-10)把当前业务对象放入其中，保存该组内上下文；
[0090](15-11)根据配置，如果配置为变更则删除该业务对象并把当前业务对象放入组内上下文中并保存，如果配置为去重则抛弃当前业务对象，阻断关联过程并返回；
[0091](15-12)当查询到两个组内上下文时，将这两个组内上下文合并为一个新的组内上下文并根据业务主键在其中做去重或变更，保存这个新的组内上下文并删除查询到的两个组内上下文；
[0092](15-13)提交事务，调用Redis连接的Exec命令；
[0093](15-14)根据提交事务的返回值判断事务是否提交成功；如果成功则继续处理下一条业务数据，否则继续步骤(15-15)；
[0094](15-15)记录关联过程的重试次数并为当前线程生成随机休眠时间；
[0095](15-16)将组内关联处理的结果组内上下文发往组间关联模块。
[0096]更佳地，所述的根据组内关联的结果对业务对象进行去重或变更操作，包括以下步骤:
[0097](161)根据业务对象类型，从当前关联配置中取出该业务对象的业务主键规则；
[0098](162)根据业务主键生成规则表达式与当前业务对象的服务数据对象，调用规则表达式组件生成业务主键；
[0099](163)在查询出的组内上下文中匹配具有相同业务主键值的业务对象并判断关联配置中对业务主键处理方式设置为变更还是去重，如果是变更，则继续步骤(164)，否则继续步骤(165)；
[0100](164)从组内上下文中删除具有相同业务主键值的业务对象，将当前业务对象放入组内上下文；
[0101](165)丢弃当前业务对象，阻断处理过程并返回。
[0102]更佳地，所述的对附加类型的业务对象进行附加关联操作，包括以下步骤:
[0103](171)收到业务对象后判断其业务对象类型是否在附加对象列表中，如果是，则继续步骤(172)，否则继续步骤(18)；
[0104](172)根据其关联键值所查询到的组内上下文不合并，只是把当前业务对象放入组内上下文中；
[0105](173)将附加业务对象存入当前分库的附加区域中，该附加业务对象类型所对应的每一个关联配置获得一个当前附加业务对象的副本；
[0106](174)在当前分库的附加对象区域中进行业务主键去重或变更操作；
[0107](175)当附加业务对象无法关联到任何组内上下文时，需要在附加区域再关联一次，当关联上另一个附加对象后将这两个对象作为一个整体再与组内上下文区域进行关联。
[0108]更佳地，所述的进行组间关联操作，包括以下步骤:
[0109](181)根据关联配置信息，验证当前组内上下文是否为多段，如果是，则继续步骤
(183)，否则继续步骤(182)；
[0110](182)根据当前组内上下文生成监控上下文，从分布式存储框架获取连接保存新生的监控上下文，处理过程结束；
[0111](183)验证生成组间关联键值所需的业务对象是否已经到齐，如果是，则继续步骤
(185)，否则继续步骤(184)；
[0112](184)阻断组间关联过程并继续步骤(13)；
[0113](185)调用表达式解析器根据组间关联键值生成规则和当前组内上下文生成组间关联键值；
[0114](186)以关联配置id为参数，调用分布式存储框架的接口获取连接；
[0115](187)以所有生成的组内关联键值为冲突检测的观察对象，调用Redis连接的Watch方法监视所有关联键值；
[0116](188)以组间关联键值为参数，调用Redis连接的查询方法，查询与该组间关联键值值对应的监控上下文的id列表；
[0117](189)开始事务，调用Redis连接的Multi命令；
[0118](18-10)如果没有查询到监控上下文，使用布隆过滤器提供的哈希函数对关联键值进行哈希后再到布隆过滤器中查询，如果命中则从关系数据库中把相关的信息一并提取出来重新放入Redis ；
[0119](18-11)如果没有查询到监控上下文且布隆过滤器也没有查出结果时，生成新的监控上下文，置入当前组内上下文，调用Redis连接的方法保存监控上下文以及组间关联键值与监控上下文的id之间的对应关系；
[0120](18-12)如果查询到一个监控上下文，则置入当前组内上下文，并调用Redis连接的方法保存变更后的监控上下文；
[0121](18-13)如果查询到两个监控上下文，将它们合并为一个新的监控上下文并保存，删除原先的监控上下文，并维护组间关联键值与监控上下文的id之间的对应关系；
[0122](18-14)提交事务，调用Redis连接的Exec命令；
[0123](18-15)根据提交事务的返回值判断事务是否提交成功；如果成功则继续处理下一条业务数据，否则继续步骤(18-16)；
[0124](18-16)记录关联过程的重试次数并为当前线程生成随机休眠时间。
[0125]更佳地，所述的根据多段与多方组的配置进行多方拆分操作，包括以下步骤:
[0126](19-1)根据多方配置信息，对当前的监控上下文中的组内上下文进行多方验证；
[0127](19-2)如果存在多方组，则从监控上下文中取出多方组内上下文和单方组内上下文；
[0128](19-3)为所有组内上下文重新生成组间关联键值；
[0129](19-4)每一个多方组内上下文都和所有其他单方组内上下文组成新的监控上下文；[0130](19-5)删除当前监控上下文，并保存多方拆分后所有新生的监控上下文。
[0131]更佳地，所述的根据还原点配置判断是否触发后续环节，包括以下步骤:
[0132](1-10-1)从关联配置中获取还原点列表配置信息；
[0133](1-10-2)在各个监控上下文中查询代表还原点的业务对象是否已经到来，如果是，则继续步骤(1-10-3)，否则继续步骤(1-10-2)；
[0134](1-10-3)将当前监控上下文发往后续处理环节。
[0135]更佳地，所述的分布式存储框架包括连接池管理模块，所述的关联调度框架从所述的分布式存储框架中获取连接，包括以下步骤:
[0136](21)从本地线程变量中获取连接并判断是否为null，如果是，则继续步骤(23)，否则继续步骤(22);
[0137](22)返回连接给关联调度框架使用；
[0138](23)根据当前的关联配置名从本地的分片信息缓存中取出分片名作为Redis服务节点名；
[0139](24)根据当前的关联配置名到本地的分库信息缓存中获取分库信息dbid并判断dbid是否为空，如果是，则继续步骤(25)，否则继续步骤(27)；
[0140](25)根据当前分片节点中最大的dbid递增生成新的dbid ；
[0141](26)把新生的分库信息存入Redis服务器分片节点的配置信息区以及本地分库
息缓存;
[0142](27)根据分片名调用连接池管理模块获取该分片节点对应的连接池服务，从连接池中获取连接；
[0143](28)调用Redis服务器连接的ping命令对当前连接做连通性验证，如果ping命令结果返回正常，则继续步骤(29)，否则继续步骤(2-11)；
[0144](29)调用Redis服务器连接的select dbid方法进入对应的分库；
[0145](2-10)把连接返回给组内关联模块或组间关联模块，连接获取过程结束；
[0146](2-11)进入宕机等待的处理流程，阻塞当前线程，每隔几秒对主Redis服务器进行连通性验证，直到其重新启动，继续步骤(2-12 );
[0147](2-12)对ping的异常返回结果进行分析，如果是网络连接或主机宕机原因导致则休眠一段时间后继续步骤(28)。
[0148]更进一步地，所述的分布式存储框架在定义的时间点进行冷数据与超量数据的转移以及布隆过滤器的重建，包括以下步骤:
[0149](31)冷数据与超量数据转历史线程被定时触发；
[0150](32)根据分片信息的本地缓存，轮询每一个Redis分片节点，根据分片名从连接池管理模块中获取连接池，进而获取Redis连接；
[0151](33)根据关联配置名从本地分库信息缓存中获取dbid，根据该dbid调用Redis连接的select方法进入对应的分库区；
[0152](34 )根据冷数据的配置天数，查询当前分库中的有序集合MC-DATE，获取冷数据的MCID ；
[0153](35)根据MCID查询出该监控上下文以及其下的组内上下文；
[0154](36)将监控上下文保存至关系数据库并从Redis中删除；[0155](37)轮询每一个Redis服务器节点，查询出节点配置的内存最大使用量和当前的已用量，如果内存已用量的占比超过了配置的超量数据百分百阀值，则继续步骤(38)，否则继续步骤(3-10)；
[0156](38)轮询当前分片节点的每一个分库；
[0157](39)查询分库中的有序集合MC-DATE,根据score即最后使用时间值找出最不活跃的那20%的MCID ；
[0158](3-10)根据MCID查询出监控上下文并转移到所述的关系数据库后从Redis中删除；
[0159](3-11)重置布隆过滤器；
[0160](3-12)使用布隆过滤器中内置的哈希函数对所有被转移的组内关联键值和组间关联键值信息进行处理并设置位数组。
[0161]采用了该发明中的大数据环境下实现实时数据关联的系统及方法，具有如下有益效果:
[0162]本发明针对上述常用解决方案的不足之处，即依赖关系数据库的数据关联存在性能瓶颈、无法支撑海量流数据的实时处理、无法有效支持复杂冗长的数据关联逻辑。提出了一种大数据环境下的实时数据关联系统及方法，该技术方案由通用关联模型、并行关联调度框架、分布式存储框架三个方面有机结合而成。这种数据关联系统能够支撑海量流式数据的实时关联，能够满足各种场景下的复杂关联需求，并且模型的通用性强、架构的伸缩性强。可以应用在性能要求苛刻的实时业务监控或分析类系统中，使IT系统迈入实时的大数据时代，具有广泛的应用范围。
[0163]目前在某业务活动监控产品中，我们实现并应用了本发明专利中描述的大数据环境下的实时关联系统及方法。在性能测试中，对比之前的产品版本，数据关联的速度提升了60倍，并且在1000万、2000万和1个亿的存量数据下，性能保持稳定。同时，因为摒弃了依赖关系数据库的关联方式，数据库服务器的压力即CPU占用率下降了 5倍。
[0164]在国家电网运营监控中心项目中，我们成功的运用了该业务活动监控产品中的数据关联系统，目前支撑了物资供应链管理、项目全过程管理、计划与预算、购售电、资金收支等多个流程的业务数据监控，支撑了国家电网总部和30多个网省的数据监控业务。数据关联系统运行稳定、性能表现优异，得到了国家电网领导的肯定。
【专利附图】
【附图说明】
[0165]图1为本发明的大数据环境下实现实时数据关联的系统的结构示意图。
[0166]图2为本发明的关联调度框架的内部结构示意图。
[0167]图3为本发明的关联调度框架的组内关联流程图。
[0168]图4为本发明的关联调度框架的组间关联流程图。
[0169]图5为本发明的关联调度框架的并发调度流程图。
[0170]图6为本发明的分布式存储框架启动初始化流程图。
[0171]图7为本发明的分布式存储框架获取连接流程图。
[0172]图8为本发明的分布式存储框架的冷数据与超量数据转历史流程图。【具体实施方式】
[0173]为了能够更清楚地描述本发明的技术内容，下面结合具体实施例来进行进一步的描述。
[0174]本发明涉及高吞吐量流式数据的实时监控类或分析类系统中的数据关联环节，内含了关联模型、并行关联调度框架、以及基于NoSQL数据库的分布式存储框架等技术方案。
[0175]本发明中的数据关联系统主要涉及三个方面的技术方案与架构思想:一是基于监控上下文和关联键值的思想设计了一套通用的关联模型；二是对于过滤、去重/变更、生成关联键值、组内关联、组间关联等处理环节设计了一套并行的关联调度框架；三是基于NoSQL数据库Redis实现了一套分布式存储框架，用以支持海量流数据的实时关联。
[0176]为了支撑大数据的存储与实时计算，本发明设计和实现了一种可用于集群环境的分布式存储框架。分布式存储框架对一种开源的NoSQL数据库Redis进行了封装。Redis属于面向聚合的键值型内存数据库，在互联网行业应用很广泛。但Redis定位在单机版，不是天然的无中心分布式数据库，本方案中的分布式存储框架在其外围做了很多功能提升。
[0177]本发明使用了布隆过滤算法。在一些企业级应用场景下，数据在业务含义上是永远不会退出的。当把一部分冷数据或超量数据转移到关系数据库之后，数据关联的逻辑会有所改变，当关联键值匹配不到时需要再次去数据库匹配。这将导致频繁访问二级存储，严重违反了流计算和实时计算的原则，对数据库的压力增大、关联速度下降，根本原因是某些企业级应用场景要求保留所有数据而非抽样、要绝对精确而非近似。本发明中提出的解决方案是布隆过滤技术，把转移到关系数据库中的关联键值用哈希函数散列到一个位数组中。布隆过滤器是一种基于二进制向量和一系列随机函数的数据结构，允许一个大范围空间内的值被一个很小的内存所代表，它结合了位图和Hash表两者的优点，既节省空间又能够处理字符串。
[0178]本发明使用了基于冲突检测的并行调度思想。行关联的核心思想是把并发编程中的拆分锁和冲突检测的思想引入到数据关联系统，将关联的并行度提高到业务对象实例的级别。广泛使用的乐观锁就是基于冲突检测的思想，比如在操作之前观察一个版本号，当提交事务时如果版本号已经改变则说明其他线程已经先于自己提交成功了，这就是发生了冲突，需要重试。对于关联的执行机制，不同关联配置下的业务对象可以并发关联，不会冲突；同一个监控上下文中的业务对象只要生成的UK不同，也能并发关联，不会冲突；同一个监控上下文中的业务对象如果生成的UK相同，只要一个事务的提交在另一个线程的watch操作之前，也不会冲突；只有同一个监控上下文中的业务对象生成的UK相同且一个事务的提交在另一个线程的watch之后，才会因冲突检测而致事务失败，这种情况下需要重试。
[0179]根据数据关联领域的普遍特点，本技术方案抽象出了一套独立的关联模型。这套模型不依赖具体的业务数据类型或属性，只要求每一类业务数据要有一个唯一的定义名、每一条业务数据要有唯一的序列号和业务主键。只要符合这些基本的规范，任何类型的业务数据都可以基于这套模型来进行关联。
[0180]关联模型是从通用的关联语义和关联机制中抽象出了以下一些概念，包括业务对象、业务对象实例、关联配置、业务主键、引用规则、还原点、业务对象组、多方组、GroupContext (组内上下文)、MonitorContext (组间上下文或称监控上下文)、UK (业务对象关联值，组内关联键值)、GUK (组间关联键值)。关联模型中的对象与概念将会应用于关联调度框架的各个执行环节。
[0181]业务对象:对业务源数据建立的模型，包括属性名称和属性类型。针对每一类业务数据，需要在管理控制台配置该业务对象的定义。
[0182]业务对象实例:业务对象的实例，代表一条业务数据。每一条业务数据进入数据关联系统后会根据业务对象的唯一定义名找到该定义，并根据定义中对于属性和数据类型的描述自动转换为业务对象实例。
[0183]关联配置:关联配置是对一种数据关联的完整过程所需的全部配置信息进行定义，包括业务主键、引用规则、组内UK、组间GUK、还原点等，还会引用业务对象的定义。
[0184]业务主键:同一条业务数据可能多次进入关联系统，有可能是业务系统的失误导致多次吐出相同的业务数据，也可能是该数据的属性已经改变需要重新吐出。这些情况下，需要根据一个有业务含义的唯一主键来判断是否用新数据代替老数据并且重新把监控上下文发送到关联系统的后续处理环节。
[0185]引用规则:一类业务数据可能会在多个关联配置下使用，比如一种报销凭证数据中可能有一些数据用于报销流程的还原，而另一些数据用于KPI指标的计算。此时就需要根据当前业务数据和引用规则，通过表达式解析器计算出它应被哪个关联配置接收。
[0186]数据权限:一个数据源吐出的同一种类型的业务数据中，可能对应着不同的关联配置，比如一个数据流中包含了多个网省的数据，根据数据权限就可以过滤出各个关联配置所需要的网省数据。需要配置数据权限的字段名和字段值。
[0187]还原点:关联系统的后续处理模块需要接收监控上下文MonitorContext,或进行流程还原、或进行KPI计算、或进行其他方式的处理，总之都是对监控上下文中已经关联在一起的业务数据进行再次加工并应用于分析和监控。但并不是每一条业务数据的到来都需要把监控上下文发往后续环节，这需要根据具体业务场景来判断，还原点就是这样一种判断机制，只有被设置为还原点的业务数据到来时才会向后续环节发送监控上下文。
[0188]业务对象组:对关联在一起的数据所进行的处理和分析是多样化的，比如要针对关联的数据进行流程还原，流程可能就是多段的，每一段都分属于不同的业务系统，这就需要对关联起来的数据进行分组。因此本技术方案提出业务对象组的概念，以及组内的关联键值UK和组间的关联键值GUK。
[0189]Union Key (UK):组内业务对象之间进行关联的值，使用表达式解析器根据配置的规则和业务对象计算出来，在当前业务对象类型所属的关联配置下的所有GroupContext中进行UK匹配。
[0190]Group Union Key (GUK):业务对象组之间进行关联的值，使用表达式解析器根据配置的规则和业务对象计算出来，在当前业务对象类型所属的关联配置下的所有MonitorContext 中进行 GUK 匹配。
[0191]GroupContext:组内上下文，由多个业务对象组成。
[0192]MonitorContext:监控上下文，业务对象及业务对象组之间关联的数据集合，由多个 GroupContext 组成。
[0193]本发明中的数据关联方法主要由三方面的设计组成:一是基于监控上下文和关联键值的思想设计了一套通用的关联模型；二是对于过滤、去重、组内关联、组间关联、多方拆分、触发后续环节等处理环节设计了一套并行的关联调度框架；三是基于NoSQL数据库Redis设计了可以横向扩展的分布式存储框架，关联操作在内存数据库中运行可以满足低延迟的需求，而分布式存储框架则实现了连接池管理、分片与分库、冷数据与超量数据转历史、布隆过滤、主从复制、宕机等待等高级功能来支撑大数据关联。本技术方案的架构图如图1所示。
[0194]关联调度框架:
[0195]关联调度框架由9个模块组成:业务对象生成、关联配置管理、业务主键去重/变更、组内关联、附加对象关联、组间关联、多方拆分、后续环节触发、并行调度控制。如图2所示展现了关联调度框架中9个主要的模块以及模块间的依赖关系。
[0196]关联配置管理:关联配置管理模块用于管理关联过程中用到的所有规则，包括UK/GUK生成规则、业务主键生成规则、引用规则等，以及业务对象类型与关联配置的对应关系。关联调度框架首先会调用该模块的接口获取当前业务对象的关联配置集合。
[0197]组内关联:组内关联模块用于对分组内的业务数据对象进行关联。
[0198]组间关联:组间关联模块用于对多个分组进行关联。
[0199]并行调度:从关联的语义来看，关联的粒度会自然被定在业务对象并集，即一个关联配置下的多个业务对象定义要串行处理，一个业务对象定义下的多个业务对象实例也要串行处理，如果不这样，经过多线程测试后几乎100%会出现关联错误。在这种很粗的关联粒度下，性能难以被充分挖掘出来。并行关联的核心思想是把并发编程中的拆分锁和冲突检测的思想引入到数据关联系统，将关联的并行度提高到业务对象实例的级别。
[0200]多方拆分:多方拆分模块会对MonitorContext中的GroupContext进行多方判断，如果有一个GroupContext是多方组,就会根据这个多方组把当前的MonitorContext拆分成多个MonitorContext。这种特性可以用于后续环节更具针对性的处理，比如子流程的还原等。
[0201]后续环节触发:后续触发模块会根据关联配置对当前的MonitorContext进行还原点判断，如果代表着还原点的业务对象已经到来，则将MonitorContext发送至后续环节。
[0202]分布式存储框架:
[0203]关联调度框架中根据UK查询GroupContext、根据GUK查询MonitorContext、以及对组内上下文和监控上下文的增删改查操作都是调用分布式存储框架实现的，因此该框架的运算能力将直接决定关联过程的实时性。
[0204]分片分库模块使其具备横向扩展的能力，随着低端PC机的增加，存储容量与处理速度呈现线性增长，可以满足大数据量下的低延迟运算需求。
[0205]冷数据与超量数据转历史模块用以将超过更新时间限制的冷数据和超过内存容量限制的超量数据发送至所述的关系数据库，布隆过滤模块能够对已经转移到关系数据库的UK/GUK进行快速查询。
[0206]连接池管理模块会根据配置表中Redis服务器的地址以及连接池参数，为每个Redis服务器的主服务器创建一个连接池，主服务器和从服务器会使用同一个Redis服务器名称。
[0207]自动运维模块使其具备较高的可用性，通过主从复制功能提供内存数据的快照冗余副本，通过自动备份功能保存多个时间点的数据快照备份，通过日志重写功能可以有效降低日志文件的大小，进而在恢复数据库时缩短初始化时间。
[0208]本技术方案中的分布式存储框架定位在企业级应用，要求强一致性，因此不提供主从切换和读写分离的功能。从主机到从机的数据复制是有延时的，当主机宕机后，从机的数据快照可能并不是最新最全的，这属于复制一致性问题。同样的，写入数据到主机，然后从从机读取该数据，可能因网络延迟而无法立刻读出来，这属于读写一致性问题。为了提供企业级应用所需的强一致性，本技术方案增加了宕机等待模块，当分布式存储框架对Redis的操作返回异常时，通过对异常信息的分析，如果是判断是网络问题或主机宕机问题则挂起当前线程，采取间隔时间等待和重试，直到主机重新启动。
[0209]本技术方案的整体处理流程包括:
[0210]1、对关联配置信息进行定义；
[0211]2、对分布式存储框架的配置信息进行定义；
[0212]3、启动初始化分布式存储框架；
[0213]4、启动初始化关联调度框架；
[0214]5、关联调度框架收到业务数据后根据业务对象类型获取关联配置；
[0215]6、关联配置管理模块根据数据权限和引用规则对关联配置进行过滤；
[0216]7、组内关联模块为业务对象生成UK和业务主键；
[0217]8、组内关联模块调用分布式存储框架接口获取对应分片的连接并放入本地线程;
[0218]9、组内关联模块根据UK调用分布式存储框架接口查找GroupContext ；
[0219]10、组内关联模块根据业务主键在查找到的GroupContext中进行去重或变更；
[0220]11、组内关联模块对GroupContext进行合并和保存；
[0221]12、组内关联模块把处理后的GroupContext发送到组间关联模块；
[0222]13、组间关联模块对GroupContext进行是否多段和生成GUK所需业务对象是否到齐的判断；
[0223]14、组间关联模块为GroupContext生成GUK并据此查询MonitorContext ；
[0224]15、组间关联模块对MonitorContext进行合并和保存；
[0225]16、多方拆分模块对MonitorContext进行是否多段和是否存在多方组的判断并据此进行拆分处理；
[0226]17、后续触发模块对拆分后的MonitorContext进行还原点判断并决定是否发往后续环节；
[0227]18、分布式存储框架在定义的时间点进行冷数据与超量数据的转移以及布隆过滤
器的重建。
[0228]如图3?8所示，该大数据环境下的实时数据关联的系统及方法，包括执行并发关联调度的服务器节点以及分布式存储集群中的所有内存数据库服务器，在关联调度环节包括以下步骤:
[0229]( 1)关联调度框架进行启动初始化操作；
[0230](2)分布式存储框架进行启动初始化操作；
[0231](3)关联调度框架收到业务数据，生成SD0对象(服务数据对象)；
[0232](4)关联调度框架根据业务数据类型，过滤出对应的关联配置；[0233](5)根据获取的关联配置，组内关联模块对SD0对象进行处理；
[0234](6)根据组内关联的结果对业务对象进行去重或变更操作；
[0235](7)如果是附加类型的业务对象，则进行附加关联操作；
[0236](8)组间关联模块收到组内关联输出的结果，进行组间关联操作；
[0237](9)多方拆分模块收到组间关联的结果，根据多段与多方组的配置进行多方拆分操作；
[0238](10)后续环节触发模块收到多方拆分的结果，根据还原点配置判断是否触发后续模块。
[0239]所述的关联调度框架进行启动初始化操作，具体包括以下步骤:
[0240](1-1)从数据库模型表中查询关联配置信息并加载到缓存；
[0241](1-2)从数据库模型表中查询业务对象配置信息并加载到缓存；
[0242](1-3)从数据库模型表中查询组间与组内关联键值对应的业务规则表达式并加载到缓存；
[0243](1-4)构建出业务对象类型与关联配置的对应关系；
[0244](1-5)从数据库配置表中查询关联调度框架的配置参数；
[0245](1-6)使用关联调度框架的配置参数，如线程池的线程数、等待队列容量、批量处理业务数据量等，初始化组内关联模块与组间关联模块；
[0246](1-7)使用关联配置信息中的数据权限、引用规则初始化关联配置过滤模块；
[0247]( 1-8)使用多段与多方组信息初始化多方拆分模块；
[0248]( 1-9)使用还原点配置信息后续环节触发模块。
[0249]所述的分布式存储框架进行启动初始化操作，具体包括以下步骤:
[0250](2-1)从配置库中读取所有Redis-server的信息，包括服务节点名、主从节点的ip与端口、最大最小连接数、连接等待时间、获取连接时是否测试连通性；
[0251](2-2)根据配置信息，为每一个Redis服务器初始化连接池；
[0252](2-3)以Redis节点名为key，把所有Redis服务器放入连接池缓存中；
[0253](2-4)从Redis分片配置表中获取关联配置定义名与Redis服务器节点名的对应关系;
[0254](2-5)以关联配置名为键，以Redis节点名为值，构建本地的分片缓存；
[0255](2-6)轮询Redis节点连接池缓存，对每一个Redis节点获取连接，使用连接调用selectO方法进入dbO即初始信息区域；
[0256](2-7)在dbO中读取分库信息，即关联配置定义名与分库号的对应关系，以关联配置名为键，以库号为值，在本地构建分库信息缓存；
[0257](2-8)轮询分库缓存，调用select方法进入每一个分库，如果当前分库不存在有序集合MC-DATE,则查询当前分库所有的MonitorContext的id,以MCID作为key,以当前日期数字作为score，构建有序集合MC-DATE，作为冷数据和超量数据转历史的判断依据；
[0258](2-9)从配置表中查询批量转历史的触发时间点、冷数据的未使用天数、内存超量的百分比，构建布隆过滤器，启动转历史定时线程。
[0259]所述的关联调度框架收到业务数据，生成SD0对象，具体包括以下步骤:
[0260](3-1)根据业务对象名从业务对象模型缓存中获取业务对象配置信息；[0261](3-2)根据业务对象命名空间与业务对象名字拼在一起为typename，调用第三方commonj-sdo组件从缓存中清除该typename ；
[0262](3-3)从业务对象配置信息中取出xsd字符串，解析xsd字符串并加载xsd ；
[0263](3-4)根据指定的名称空间和业务对象名称,构建业务对象的SD0对象-commonj.sd0.DataObject；
[0264](3-5)从SDO对象中获取类型commonj.sd0.Type,继而获取属性名commonj.sd0.Property ；
[0265](3-6)根据属性名从业务数据中获取对应的值并设置到SD0对象中；
[0266]所述关联调度框架根据业务数据类型，过滤出对应的关联配置，具体包括以下步骤:
[0267](4-1)根据业务数据的类型从关联配置缓存中口获取所有关联配置；
[0268](4-2)获取业务目录数据权限的开关，如果开启则获取数据权限字段名并验证数据权限；
[0269](4-3)从关联配置中获取其所述的业务目录，进而获取该业务目录对应的数据权限值；
[0270](4-4)根据数据权限字段名，从当前业务对象中获取字段值
[0271](4-5)对比业务目录数据权限值和当前业务对象的数据权限值，如果匹配成功则将该关联配置加入待处理的关联配置集合；
[0272](4-6)根据关联配置的引用规则和当前业务对象，使用业务规则表达式组件计算出结果值，结果为false则过滤掉当前关联配置。
[0273]所述的组内关联模块对SD0对象进行处理，具体包括以下步骤:
[0274](5-1)以关联配置id为参数从分布式存储框架中获取连接；
[0275](5-2)根据当前业务对象的UK生成规则，调用表达式解析器生成UK关联键值；
[0276](5-3)以所有生成的UK为冲突检测的观察对象，调用Redis连接的watch方法监视所有关联键值；
[0277](5-4)根据当前业务对象的业务主键生成规则，调用表达式解析器生成业务主键的值；
[0278](5-5)根据生成的UK值，调用Redis连接的查询方法，查询出与该UK对应的GroupContext的所有id组成的列表；
[0279](5-6)开始事务，调用Redis连接的multi命令；
[0280](5-7)当没有查询到GroupContext时，使用布隆过滤器提供的哈希函数对关联键值进行哈希后再到布隆过滤器中查询，如果命中则从关系数据库中把相关的UK/GUK/GroupContext/MonitorContext 信息一并提取出来重新放入 Redis ；
[0281 ] (5-8 )当没有查询到GroupContext且布隆过滤器也没有查询到结果时，生成新的GroupContext并置入当前业务数据，调用Redis连接的方法保存这个新生的GroupContext,保存UK与该GroupContext的id的对应关系；
[0282](5-9)当查询到一个GroupContext时，使用业务主键值在当前GroupContext中查找业务对象；
[0283](5-10)如果没有找到则把当前业务对象放入其中，保存该GroupContext ；[0284](5-11)如果找到了业务对象则根据配置，如果配置为变更则删除该业务对象并把当前业务对象放入GroupContext中并保存,如果配置为去重则抛弃当前业务对象，阻断关联过程并返回；
[0285](5-12)当查询到两个GroupContext时，将这两个GroupContext合并为一个新的GroupContext并根据业务主键在其中做去重或变更,保存这个新的GroupContext并删除查询到的两个GroupContext ；
[0286](5-13)提交事务，调用Redis连接的exec命令；
[0287](5-14)根据提交事务的返回值判断事务是否提交成功；如果成功则继续处理下一条业务数据；
[0288](5-15)如果事务提交失败，记录关联过程的重试次数；为当前线程生成随机休眠时间，这是为了减小碰撞概率；使当前线程休眠一段随机时间，再继续重试关联处理过程。
[0289](5-16)将组内关联处理的结果GroupContext发往组间关联模块。
[0290]所述的根据组内关联的结果对业务对象进行去重或变更操作，具体包括以下步骤:
[0291](6-1)根据业务对象类型，从当前关联配置中取出该业务对象的业务主键规则；
[0292](6-2)根据业务主键生成规则表达式与当前业务对象的SD0对象，调用规则表达式组件生成业务主键；
[0293](6-3)在查询出的GroupContext中匹配具有相同业务主键值的业务对象；
[0294](6-4)如果关联配置中对业务主键处理方式设置为变更，则从GroupContext中删除具有相同业务主键值的业务对象，将当前业务对象放入GroupContext ；
[0295](6-5)如果关联配置中对业务主键处理方式设置为去重，则丢弃当前业务对象，并且阻断处理过程并返回。
[0296]所述的如果是附加类型的业务对象，则进行附加关联操作，具体步骤如下:
[0297](7-1)关联模块收到业务对象后判断其业务对象类型是否在附加对象列表中；
[0298](7-2)如果是附加业务对象，则根据其关联键值所查询到的GroupContext不合并，只是把当前业务对象放入GroupContext中；
[0299](7-3)附加业务对象可能先到或只到一次，附加业务对象需要存入当前分库的附加区域中，该附加业务对象类型所对应的每一个关联配置都会获得一个当前附加业务对象的副本；
[0300](7-4)在当前分库的附加对象区域中进行业务主键去重或变更操作；
[0301](7-5)当附加业务对象无法关联到任何GroupContext时，需要在附加区域再关联一次，当关联上另一个附加对象后还要把这两个对象作为一个整体再与GroupContext区域关联。
[0302]所述的组间关联模块收到组内关联输出的结果，进行组间关联操作，具体包括以下步骤:
[0303](8-1)根据关联配置信息，验证当前GroupContext是否为多段；
[0304](8-2)如果不是多段，根据当前GroupContext生成MonitorContext,从分布式存储框架获取连接保存新生的MonitorContext,处理过程结束；
[0305](8-3)如果是多段，验证生成GUK所需的业务对象是否已经到齐；[0306](8-4)如果生成GUK所需的业务对象没有到齐，则阻断组间关联过程并返回；
[0307](8-5)如果生成GUK所需的业务对象已经到齐，则调用表达式解析器根据GUK生成规则和当前GroupContext生成GUK ；
[0308](8-6)以关联配置id为参数，调用分布式存储框架的接口获取连接；
[0309](8-7)以所有生成的UK为冲突检测的观察对象，调用Redis连接的watch方法监视所有关联键值；
[0310](8-8)以GUK为参数，调用Redis连接的查询方法，查询与该GUK值对应的MonitorContext 的 id 列表；
[0311](8-9)开始事务，调用Redis连接的multi命令；
[0312](8-10)如果没有查询到MonitorContext,使用布隆过滤器提供的哈希函数对关联键值进行哈希后再到布隆过滤器中查询，如果命中则从关系数据库中把相关的UK/GUK/GroupContext/MonitorContext 信息一并提取出来重新放入 Redis ；
[0313](8-11)如果没有查询到MonitorContext且布隆过滤器也没有查出结果时，生成新的MonitorContext,置入当前GroupContext,调用Redis连接的方法保存MonitorContext 以及 GUK 与 MonitorContext 的 id 之间的对应关系；
[0314](8-12)如果查询到一个MonitorContext,则置入当前GroupContext,并调用Redis连接的方法保存变更后的MonitorContext ；
[0315](8-13)如果查询到两个MonitorContext,将它们合并为一个新的MonitorContext并保存，删除原先的MonitorContext,并维护GUK与MonitorContext的id之间的对应关系;
[0316](8-14)提交事务，调用Redis连接的exec命令；
[0317](8-15)根据提交事务的返回值判断事务是否提交成功；如果成功则继续处理下一条业务数据；
[0318](8-16)如果事务提交失败，记录关联过程的重试次数；为当前线程生成随机休眠时间，这是为了减小碰撞概率；使当前线程休眠一段随机时间，再继续重试关联处理过程。
[0319]所述的多方拆分模块收到组间关联的结果，根据多段与多方组的配置进行多方拆分操作，具体包括以下步骤:
[0320](9-1)根据多方配置信息，对当前的MonitorContext中的GroupContext进行多方验证；
[0321](9-2)如果存在多方组，则从MonitorContext中取出多方GroupContext和单方GroupContext ；
[0322](9-3)为所有 GroupContext 重新生成 GUK ；
[0323](9-4 )每一个多方GroupContext都和所有其他单方GroupContext组成新的MonitorContext ；
[0324](9-5)删除当前MonitorContext,并保存多方拆分后所有新生的MonitorContext ；
[0325]所述的后续环节触发模块收到多方拆分的结果，根据还原点配置判断是否触发后续模块，具体包括以下步骤:
[0326](10-1)从关联配置中获取还原点列表配置信息；[0327](10-2)在每一个MonitorContext中查询代表还原点的业务对象是否已经到来；
[0328](10-3)如果还原点没有全部到来，返回；
[0329](10-4)如果还原点全部到来,则将当前MonitorContext发往后续处理环节。
[0330]同时，组内关联与组间关联均要从分布式存储框架中获取连接，该操作包括以下步骤:
[0331](1)从本地线程变量中获取连接；
[0332](2)如果不为null则返回给关联调度框架使用；
[0333](3)如果为null则根据当前的关联配置名从本地的分片信息缓存中取出分片名，该分片名就是Redis服务节点名；
[0334](4)根据当前的关联配置名到本地的分库信息缓存中获取分库信息dbid ；
[0335](5)如果dbid为空，则根据当前分片节点中最大的dbid递增生成新的dbid ；
[0336](6)把新生的分库信息存入Redis分片节点的配置信息区以及本地分库信息缓存；
[0337](7)根据分片名调用连接池管理模块获取该分片节点对应的连接池服务，从连接池中获取连接；
[0338](8)如果dbid不为空则直接执行第7步；
[0339](9)调用Redis连接的ping命令对当前连接做连通性验证；
[0340](10)如果ping命令结果返回正常则调用Redis连接的select dbid方法进入对应的分库；
[0341](11)把连接返回给组内关联模块或组间关联模块，连接获取过程结束；
[0342](12)如果ping命令结果返回不正常则进入宕机等待的处理流程，阻塞当前线程，每隔几秒对主Redis服务器进行连通性验证，直到其重新启动，继续当前操作；
[0343](13)对ping的异常返回结果进行分析，如果是网络连接或主机宕机原因导致则休眠一段时间后继续回到第9步。
[0344]本发明的分布式存储框架中，冷数据与超量数据转历史模块的实现步骤如下(参阅图6 ):
[0345](1)冷数据与超量数据转历史线程被定时触发
[0346](2)根据分片信息的本地缓存，轮询每一个Redis分片节点，根据分片名从连接池管理模块中获取连接池，进而获取Redis连接
[0347](3)根据关联配置名从本地分库信息缓存中获取dbid，根据该dbid调用Redis连接的select方法进入对应的分库区
[0348](4)根据冷数据的配置天数，查询当前分库中的有序集合MC-DATE，获取冷数据的MCID
[0349](5)根据MCID查询出该MonitorContext以及其下的GroupContext等全部信息
[0350](6)将MonitorContext保存至关系数据库并从Redis中删除
[0351](7)轮询每一个Redis服务器节点，查询出节点配置的内存最大使用量和当前的
已用量
[0352](8)如果内存已用量的占比超过了配置的超量数据百分百阀值，则轮询当前分片节点的每一个分库[0353](9)查询分库中的有序集合MC-DATE，根据score即最后使用时间值找出最不活跃的那20%的MCID
[0354](10)根据MCID查询出MonitorContext,执行转移到关系数据库并从Redis中删除
[0355](11)重置布隆过滤器
[0356](12)使用布隆过滤器中内置的哈希函数对所有被转移的UK/GUK信息进行处理并设置位数组
[0357]在上述实施例中，使用的是基于Java语言的描述，当然也可以根据需要采用其它的面向对象编程语目。
[0358]采用上述的大数据环境下的实时数据关联系统及方法，可以解决高吞吐量流式数据场景下的复杂关联需求。关联模型有较高的抽象程度，关联调度过程通用性强，存储与计算架构具备横向扩展能力，能够有效支撑大数据的存储与和实时关联。将本发明应用在实时监控或分析类系统中，可以推动该类系统进入大数据的实时处理时代。
[0359]采用了该发明中的大数据环境下实现实时数据关联的系统及方法，具有如下有益效果:
[0360]本发明针对上述常用解决方案的不足之处，即依赖关系数据库的数据关联存在性能瓶颈、无法支撑海量流数据的实时处理、无法有效支持复杂冗长的数据关联逻辑。提出了一种大数据环境下的实时数据关联系统及方法，该技术方案由通用关联模型、并行关联调度框架、分布式存储框架三个方面有机结合而成。这种数据关联系统能够支撑海量流式数据的实时关联，能够满足各种场景下的复杂关联需求，并且模型的通用性强、架构的伸缩性强。可以应用在性能要求苛刻的实时业务监控或分析类系统中，使IT系统迈入实时的大数据时代，具有广泛的应用范围。
[0361]目前在某业务活动监控产品中，我们实现并应用了本发明专利中描述的大数据环境下的实时关联系统及方法。在性能测试中，对比之前的产品版本，数据关联的速度提升了60倍，并且在1000万、2000万和1个亿的存量数据下，性能保持稳定。同时，因为摒弃了依赖关系数据库的关联方式，数据库服务器的压力即CPU占用率下降了 5倍。
[0362]在国家电网运营监控中心项目中，我们成功的运用了该业务活动监控产品中的数据关联系统，目前支撑了物资供应链管理、项目全过程管理、计划与预算、购售电、资金收支等多个流程的业务数据监控，支撑了国家电网总部和30多个网省的数据监控业务。数据关联系统运行稳定、性能表现优异，得到了国家电网领导的肯定。
[0363]在此说明书中，本发明已参照其特定的实施例作了描述。但是，很显然仍可以作出各种修改和变换而不背离本发明的精神和范围。因此，说明书和附图应被认为是说明性的而非限制性的。
【权利要求】
1.一种大数据环境下实现实时数据关联的系统，其特征在于，所述的系统包括: 关联调度框架，用以对业务对象进行组内关联、组间关联和并发调度； 分布式存储框架，用以为每个Redis服务器的主服务器创建一个连接池、存储当前数据关联相关的数据、将超过更新时间限制的冷数据和超过内存容量限制的超量数据发送至关系数据库以及对已经转移到所述的关系数据库的组内关联键值和组间关联键值进行查询； 关系数据库，用以存储组内关联键值、组间关联键值、组内上下文和监控上下文，所述的关系数据库与所述的分布式存储框架相连接； Redis服务器，与所述的分布式存储框架相连接。
2.根据权利要求1所述的大数据环境下实现实时数据关联的系统，其特征在于，所述的关联调度框架包括: 业务对象生成模块,用以生成业务对象； 关联配置管理模块，用以管理关联过程中用到的所有规则； 业务对象去重模块，用以根据组内关联的结果对业务对象进行去重或变更操作 组内关联模块，用以对分组内的业务数据对象进行关联； 附加对象关联模块，用以对附加类型的业务对象进行附加关联操作； 组间关联模块，用以对多个分组进行关联； 多方拆分模块，用以根据多方组的组内上下文将当前的监控上下文进行拆分； 后续环节触发模块，用以对当前监控上下文进行还原点判断并当代表着还原点的业务对象已到来时将监控上下文发送至后续环节； 并行调度控制模块，用以对业务对象进行调度控制。
3.根据权利要求1所述的大数据环境下实现实时数据关联的系统，其特征在于，所述的分布式存储框架包括: 连接池管理模块，用以根据配置表中Redis服务器的地址以及连接池参数为每个Redis服务器的主服务器创建一个连接池； 分片分库模块，用以存储当前数据关联相关的数据； 宕机等待模块，用以进行宕机后的线程等待； 主从复制模块，用以将主机的数据复制到从机中进行保存； 自动运维模块，用以通过主从复制功能提供内存数据的快照冗余副本、通过自动备份功能保存多个时间点的数据快照备份以及通过日志重写功能降低日志文件的大小； 冷数据与超量数据转历史模块，用以将超过更新时间限制的冷数据和超过内存容量限制的超量数据发送至所述的关系数据库； 布隆过滤模块，用以对已经转移到所述的关系数据库的组内关联键值和组间关联键值进行查询。
4.一种基于权利要求1至3所述的系统大数据环境下实现实时数据关联的方法，其特征在于，所述的方法包括以下步骤: (1)所述的关联调度框架对业务对象进行组内关联、组间关联和并发调度； (2)所述的关联调度框架从所述的分布式存储框架中获取连接； (3)所述的分布式存储框架在定义的时间点进行冷数据与超量数据的转移以及布隆过滤器的重建。
5.根据权利要求4所述的大数据环境下实现实时数据关联的方法，其特征在于，所述的关联调度框架包括业务对象生成模块、关联配置管理模块、业务对象去重模块、组内关联模块、附加对象关联模块、组间关联模块、多方拆分模块、后续环节触发模块和并行调度控制模块，所述的关联调度框架对业务对象进行组内关联、组间关联和并发调度，包括以下步骤: (11)所述的关联调度框架进行启动初始化操作； (12)所述的分布式存储框架进行启动初始化操作； (13)所述的关联调度框架收到业务数据并生成服务数据对象； (14)所述的关联调度框架根据业务数据类型过滤出对应的关联配置； (15)根据获取的关联配置，所述的组内关联模块对服务数据对象进行处理； (16)所述的业务对象去重模块根据组内关联的结果对业务对象进行去重或变更操作； (17)所述的附加对象关联模块对附加类型的业务对象进行附加关联操作；` (18)所述的组间关联模块收到组内关联输出的结果，进行组间关联操作； (19)所述的多方拆分模块收到组间关联的结果，根据多段与多方组的配置进行多方拆分操作； (1-10)所述的后续环节触发模块收到多方拆分的结果，根据还原点配置判断是否触发后续环节。
6.根据权利要求5所述的大数据环境下实现实时数据关联的方法，其特征在于，所述的关联调度框架进行启动初始化操作，包括以下步骤: (111)从数据库模型表中查询关联配置信息并加载到所述的关联调度框架的缓存； (112)从数据库模型表中查询业务对象配置信息并加载到所述的关联调度框架的缓存； (113)从数据库模型表中查询组间与组内关联键值对应的业务规则表达式并加载到所述的关联调度框架的缓存； (114)构建出业务对象类型与关联配置的对应关系； (115)从数据库配置表中查询所述的关联调度框架的配置参数； (116)使用所述的关联调度框架的配置参数初始化组内关联模块与组间关联模块； (117)使用关联配置信息中的数据权限和引用规则初始化关联配置管理模块； (118)使用多段与多方组信息初始化多方拆分模块； (119)使用还原点配置信息后续环节触发模块。
7.根据权利要求5所述的大数据环境下实现实时数据关联的方法，其特征在于，所述的分布式存储框架进行启动初始化操作，包括以下步骤: (121)从配置库中读取所有Redis服务器的信息，包括服务节点名、主从节点的ip与端口、最大最小连接数、连接等待时间、获取连接时是否测试连通性； (122)根据配置信息，为每一个Redis服务器初始化连接池； (123)以Redis节点名为key，把所有Redis服务器放入连接池缓存中； (124)从Redis分片配置表中获取关联配置定义名与Redis服务器节点名的对应关系; (125)以关联配置名为键，以Redis节点名为值，构建本地的分片缓存； (126)轮询Redis节点连接池缓存，对每一个Redis节点获取连接，使用连接调用selectO方法进入dbO即初始信息区域； (127)在dbO中读取分库信息，即关联配置定义名与分库号的对应关系，以关联配置名为键，以库号为值，在本地构建分库信息缓存； (128)轮询分库缓存，调用select方法进入每一个分库，如果当前分库不存在有序集合MC-DATE，则查询当前分库所有的监控上下文的id，以MCID作为key，以当前日期数字作为score，构建有序集合MC-DATE，作为冷数据和超量数据转历史的判断依据； (129)从配置表中查询批量转历史的触发时间点、冷数据的未使用天数、内存超量的百分比，构建布隆过滤器，启动转历史定时线程。
8.根据权利要求5所述的大数据环境下实现实时数据关联的方法，其特征在于，所述的收到业务数据并生成服务数据对象，包括以下步骤: (131)根据业务对象名从业务对象模型缓存中获取业务对象配置信息； (132)根据业务对象命名空间与业务对象名字拼在一起为typename，调用第三方commonj-sdo组件从缓存中清除该typename ； (133)从业务对象配置信息中取出xsd字符串，解析xsd字符串并加载xsd； (134)根据指定的名称空间和业务对象名称,构建业务对象服务数据对象-commonj.sd0.DataObject ； (135)从服务数据对象中获取类型commonj.sd0.Type,继而获取属性名commonj.sd0.Property ； (136)根据属性名从业务数据中获取对应的值并设置到服务数据对象中。
9.根据权利要求5所述的大数据环境下实现实时数据关联的方法，其特征在于，所述的根据业务数据类型过滤出对应的关联配置，包括以下步骤: (141)根据业务数据的类型从关联配置缓存中口获取所有关联配置； (142)获取业务目录数据权限的开关，如果开启则获取数据权限字段名并验证数据权限； (143)从关联配置中获取其所述的业务目录，进而获取该业务目录对应的数据权限值； (144)根据数据权限字段名，从当前业务对象中获取字段值； (145)对比业务目录数据权限值和当前业务对象的数据权限值，如果匹配成功则将该关联配置加入待处理的关联配置集合； (146)根据关联配置的引用规则和当前业务对象，使用业务规则表达式组件计算出结果值并过滤掉结果为失败的关联配置。
10.根据权利要求5所述的大数据环境下实现实时数据关联的方法，其特征在于，所述的对服务数据对象进行处理，包括以下步骤: (151)以关联配置id为参数从分布式存储框架中获取连接； (152)根据当前业务对象的组内关联键值生成规则，调用表达式解析器生成组内关联键值；(153)以所有生成的组内关联键值为冲突检测的观察对象，调用Redis连接的Watch方法监视所有关联键值； (154)根据当前业务对象的业务主键生成规则，调用表达式解析器生成业务主键的值； (155)根据生成的组内关联键值，调用Redis连接的查询方法，查询出与该组内关联键值对应的组内上下文的所有id组成的列表； (156)开始事务，调用Redis连接的Multi命令； (157)当没有查询到组内上下文时，使用布隆过滤器提供的哈希函数对关联键值进行哈希后再到布隆过滤器中查询，如果命中则从关系数据库中把相关的信息一并提取出来重新放入Redis ； (158)当没有查询到组内上下文且布隆过滤器也没有查询到结果时，生成新的组内上下文并置入当前业务数据，调用Redis连接的方法保存这个新生的组内上下文，保存组内关联键值与该组内上下文的id的对应关系； (159)当查询到一个组内上下文时，使用业务主键值在当前组内上下文中查找业务对象，如果找到，则继续步骤(15-10),否则继续步骤(15-11); (15-10)把当前业务对象放入其中，保存该组内上下文； (15-11)根据配置，如果配置为变更则删除该业务对象并把当前业务对象放入组内上下文中并保存，如果配置为去重则抛弃当前业务对象，阻断关联过程并返回； (15-12)当查询到两个组内上下文时，将这两个组内上下文合并为一个新的组内上下文并根据业务主键在其中做去重或变更，保存这个新的组内上下文并删除查询到的两个组内上下文； (15-13)提交事务,调用Redis连接的Exec命令； (15-14)根据提交事务的返回值判断事务是否提交成功；如果成功则继续处理下一条业务数据，否则继续步骤(15-15)； (15-15)记录关联过程的重试次数并为当前线程生成随机休眠时间； (15-16)将组内关联处理的结果组内上下文发往组间关联模块。
11.根据权利要求5所述的大数据环境下实现实时数据关联的方法，其特征在于，所述的根据组内关联的结果对业务对象进行去重或变更操作，包括以下步骤: (161)根据业务对象类型，从当前关联配置中取出该业务对象的业务主键规则； (162)根据业务主键生成规则表达式与当前业务对象的服务数据对象，调用规则表达式组件生成业务主键； (163)在查询出的组内上下文中匹配具有相同业务主键值的业务对象并判断关联配置中对业务主键处理方式设置为变更还是去重，如果是变更，则继续步骤(164)，否则继续步骤(165)； (164)从组内上下文中删除具有相同业务主键值的业务对象，将当前业务对象放入组内上下文； (165)丢弃当前业务对象，阻断处理过程并返回。
12.根据权利要求5所述的大数据环境下实现实时数据关联的方法，其特征在于，所述的对附加类型的业务对象进行附加关联操作，包括以下步骤:(171)收到业务对象后判断其业务对象类型是否在附加对象列表中，如果是，则继续步骤(172)，否则继续步骤(18)； (172)根据其关联键值所查询到的组内上下文不合并，只是把当前业务对象放入组内上下文中； (173)将附加业务对象存入当前分库的附加区域中，该附加业务对象类型所对应的每一个关联配置获得一个当前附加业务对象的副本； (174)在当前分库的附加对象区域中进行业务主键去重或变更操作； (175)当附加业务对象无法关联到任何组内上下文时，需要在附加区域再关联一次，当关联上另一个附加对象后将这两个对象作为一个整体再与组内上下文区域进行关联。
13.根据权利要求5所述的大数据环境下实现实时数据关联的方法，其特征在于，所述的进行组间关联操作，包括以下步骤: (181)根据关联配置信息，验证当前组内上下文是否为多段，如果是，则继续步骤(183)，否则继续步骤(182)； (182)根据当前组内上下文生成监控上下文，从分布式存储框架获取连接保存新生的`监控上下文，处理过程结束； (183)验证生成组间关联键值所需的业务对象是否已经到齐，如果是，则继续步骤(185)，否则继续步骤(184)； (184)阻断组间关联过程并继续步骤(13)； (185)调用表达式解析器根据组间关联键值生成规则和当前组内上下文生成组间关联键值； (186)以关联配置id为参数，调用分布式存储框架的接口获取连接； (187)以所有生成的组内关联键值为冲突检测的观察对象，调用Redis连接的Watch方法监视所有关联键值； (188)以组间关联键值为参数，调用Redis连接的查询方法，查询与该组间关联键值值对应的监控上下文的id列表； (189)开始事务，调用Redis连接的Multi命令； (18-10)如果没有查询到监控上下文，使用布隆过滤器提供的哈希函数对关联键值进行哈希后再到布隆过滤器中查询，如果命中则从关系数据库中把相关的信息一并提取出来重新放入Redis ； (18-11)如果没有查询到监控上下文且布隆过滤器也没有查出结果时，生成新的监控上下文，置入当前组内上下文，调用Redis连接的方法保存监控上下文以及组间关联键值与监控上下文的id之间的对应关系； (18-12)如果查询到一个监控上下文，则置入当前组内上下文，并调用Redis连接的方法保存变更后的监控上下文； (18-13)如果查询到两个监控上下文，将它们合并为一个新的监控上下文并保存，删除原先的监控上下文，并维护组间关联键值与监控上下文的id之间的对应关系； (18-14)提交事务,调用Redis连接的Exec命令； (18-15)根据提交事务的返回值判断事务是否提交成功；如果成功则继续处理下一条业务数据，否则继续步骤(18-16)；(18-16)记录关联过程的重试次数并为当前线程生成随机休眠时间。
14.根据权利要求5所述的大数据环境下实现实时数据关联的方法，其特征在于，所述的根据多段与多方组的配置进行多方拆分操作，包括以下步骤: (19-1)根据多方配置信息，对当前的监控上下文中的组内上下文进行多方验证； (19-2)如果存在多方组，则从监控上下文中取出多方组内上下文和单方组内上下文； (19-3)为所有组内上下文重新生成组间关联键值； (19-4)每一个多方组内上下文都和所有其他单方组内上下文组成新的监控上下文； (19-5)删除当前监控上下文，并保存多方拆分后所有新生的监控上下文。
15.根据权利要求5所述的大数据环境下实现实时数据关联的方法，其特征在于，所述的根据还原点配置判断是否触发后续环节，包括以下步骤: (1-10-1)从关联配置中获取还原点列表配置信息； (1-10-2)在各个监控上下文中查询代表还原点的业务对象是否已经到来，如果是，则继续步骤(1-10-3)，否则继续步骤(1-10-2)； (1-10-3)将当前监控上下文 发往后续处理环节。
16.根据权利要求5所述的大数据环境下实现实时数据关联的方法，其特征在于，所述的分布式存储框架包括连接池管理模块，所述的关联调度框架从所述的分布式存储框架中获取连接，包括以下步骤: (21)从本地线程变量中获取连接并判断是否为null，如果是，则继续步骤(23)，否则继续步骤(22)； (22)返回连接给关联调度框架使用； (23)根据当前的关联配置名从本地的分片信息缓存中取出分片名作为Redis服务节点名； (24)根据当前的关联配置名到本地的分库信息缓存中获取分库信息dbid并判断dbid是否为空，如果是，则继续步骤(25)，否则继续步骤(27)； (25)根据当前分片节点中最大的dbid递增生成新的dbid； (26)把新生的分库信息存入Redis服务器分片节点的配置信息区以及本地分库信息缓存； (27)根据分片名调用连接池管理模块获取该分片节点对应的连接池服务，从连接池中获取连接； (28)调用Redis服务器连接的ping命令对当前连接做连通性验证,如果ping命令结果返回正常，则继续步骤(29 )，否则继续步骤(2-11); (29)调用Redis服务器连接的selectdbid方法进入对应的分库； (2-10)把连接返回给组内关联模块或组间关联模块，连接获取过程结束； (2-11)进入宕机等待的处理流程，阻塞当前线程，每隔几秒对主Redis服务器进行连通性验证，直到其重新启动，继续步骤(2-12)； (2-12)对ping的异常返回结果进行分析，如果是网络连接或主机宕机原因导致则休眠一段时间后继续步骤(28)。
17.根据权利要求16所述的大数据环境下实现实时数据关联的方法，其特征在于，所述的分布式存储框架在定义的时间点进行冷数据与超量数据的转移以及布隆过滤器的重建，包括以下步骤: (31)冷数据与超量数据转历史线程被定时触发； (32)根据分片信息的本地缓存，轮询每一个Redis分片节点，根据分片名从连接池管理模块中获取连接池，进而获取Redis连接； (33)根据关联配置名从本地分库信息缓存中获取dbid，根据该dbid调用Redis连接的select方法进入对应的分库区； (34)根据冷数据的配置天数，查询当前分库中的有序集合MC-DATE，获取冷数据的MCID ； (35)根据MCID查询出该监控上下文以及其下的组内上下文； (36)将监控上下文保存至关系数据库并从Redis中删除； (37)轮询每一个Redis服务器节点，查询出节点配置的内存最大使用量和当前的已用量，如果内存已用量的占比超过了配置的超量数据百分百阀值，则继续步骤(38)，否则继续步骤(3-10)； (38)轮询当前分片节点的每一个分库； (39)查询分库中的有序集合MC-DATE,根据score即最后使用时间值找出最不活跃的那 20% 的 MCID ； (3-10)根据MCID查询出监控上下文并转移到所述的关系数据库后从Redis中删除； (3-11)重置布隆过滤器； (3-12)使用布隆过滤器中内置的哈希函数对所有被转移的组内关联键值和组间关联键值信息进行处理并设置位数组。
【文档编号】G06F17/30GK103646111SQ201310728924
【公开日】2014年3月19日 申请日期:2013年12月25日 优先权日:2013年12月25日
【发明者】苏阳 申请人:普元信息技术股份有限公司