CN110543478A - 公共层宽表建设方法、装置及服务器 - Google Patents

Abstract

本说明书实施例提供了一种公共层宽表建设方法、装置及服务器，根据预设延时时长延时获取主业务表中的主增量数据，利用了预设延时时长等待副业务表中副增量数据的到达，保证副业务表中需要关联的数据全部到达，主业务表的每一行数据记录都能够与副业务表中热点数据进行成功匹配，保证能关联到完整数据成功避免业务数据的飘移，保证了小时级公共层宽表的正确产出。

Description

公共层宽表建设方法、装置及服务器

技术领域

本说明书实施例涉及数据处理领域，尤其涉及一种公共层宽表建设方法、装置及服务器。

背景技术

目前国际贸易越来越普及，国际业务的开展会涵盖众多国家，各个国家都有自己的时区。离线数据仓库建设的时间一半为T+1，即：如果希望在今天早上八点之前能够看到昨天全天的明细数据及汇总数据，可以在今天凌晨0点时开始对昨天的业务数据进行ETL处理，但是对于其它时区的业务数据而言，会晚于凌晨0点开始ETL处理。若多时区的数据场景下，若建设与每个时区相匹配的调度时间以及业务统计时间，在时效性与业务统计复杂性上都很难满足目前的业务诉求，也不利于数据架构的扩展与国际业务的整体数据洞察。

发明内容

本说明实施例提供一种公共层宽表建设方法、装置及服务器。

第一方面，本说明实施例提供一种公共层宽表建设方法，应用于流式计算平台，所述方法包括：根据预设延时时长，延时获取主业务表中的主增量数据，所述主业务表以及与所述主业务表相关的至少一个副业务表属于同一业务系统；对目标数据库中每个与所述主业务表相关的热点数据表进行检索，获取与所述主增量数据匹配的目标热点数据，所述目标热点数据与所述热点数据表对应的副业务表中幅增量数据对应；将所述目标热点数据与所述主业务表中的主增量数据进行拼接处理，形成写入离线批处理平台的拼接结果数据，使得所述离线批处理平台处理所述拼接结果数据表，以产出小时级公共层宽表。

第二方面，本说明实施例提供一种用于建设小时级公共层宽表的流式计算装置，包括：延时获取单元，用于根据预设延时时长，延时获取主业务表中的主增量数据，所述主业务表以及与所述主业务表相关的至少一个副业务表属于同一业务系统；检索单元，用于对目标数据库中每个与所述主业务表相关的热点数据表表进行检索，获取与所述主增量数据匹配的目标热点数据，所述目标热点数据与所述热点数据表对应的副业务表中幅增量数据对应；拼接单元，用于将所述目标热点数据与所述主业务表中的主增量数据进行拼接处理，形成写入离线批处理平台的拼接结果数据，使得所述离线批处理平台处理所述拼接结果数据表，以产出小时级公共层宽表。

第三方面，本说明书实施例提供一种服务器，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现上述任一项所述公共层宽表建设方法的步骤。

第四方面，本说明书实施例提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现上述任一项所述公共层宽表建设方法的步骤。

本说明书实施例有益效果如下：

本说明书实施例提供的公共层宽表建设方法，通过对属于同一业务系统的业务表划分主、副业务表，根据预设延时时长延时获取主业务表中的主增量数据，而利用这段预设延时时长，主业务表就可以等待需要关联的副业务表中数据全部到达，从而使得主业务表的每一行数据记录都能够与副业务表中热点数据进行成功匹配，进而关联到完整数据。由此成功避免了因业务数据的飘移导致的数据流点位不一致的情况下，会出现的关联不到部分或全部数据的问题，保证了小时级公共层宽表的正确产出，提高了公共层数据质量。

附图说明

图1为本说明书实施例提供的公共层宽表建设方法的应用场景示意图；

图2为本说明书实施例提供的公共层宽表建设方法的流程图；

图3为本说明书实施例提供的公共层宽表建设方法应用在支付场景下的数据架构图；

图4为本说明书实施例提供的公共层宽表建设方法应用在支付场景下，主支付表的数据链路；

图5为本说明书实施例提供的公共层宽表建设方法应用在支付场景下，所有副支付表的数据链路；

图6为本说明书实施例提供的流式计算装置的结构示意图；

图7为本说明书实施例提供的服务器的结构示意图。

具体实施方式

为了更好的理解上述技术方案，下面通过附图以及具体实施例对本说明书实施例的技术方案做详细的说明，应当理解本说明书实施例以及实施例中的具体特征是对本说明书实施例技术方案的详细的说明，而不是对本说明书技术方案的限定，在不冲突的情况下，本说明书实施例以及实施例中的技术特征可以相互组合。

参考图1所示，图1对本说明实施例提供的公共层宽表建设方法的应用架构进行描述：

业务系统100，业务系统100包括关系型数据库管理系统，具体的，关系型数据库可以是Oracle关系型数据库管理系统或者Mysql关系型数据库管理系统。对业务系统100的数据库中所有业务表被划分为主业务表，以及与该主业务表相关的至少一个副业务表。

流式计算平台200，以流式计算的方式进行实时处理加工数据。流式计算平台200根据预设延时时长，延时获取主业务表中的主增量数据；对目标数据库中每个与主业务表相关的热点数据表表进行检索，获取与主增量数据匹配的目标热点数据，目标热点数据来源于对应的副业务表；将目标热点数据拼接至主业务表中的主增量数据，形成拼接结果数据并写入离线批处理平台。

离线批处理平台300，处理拼接结果数据，产出小时级公共层宽表。

进一步，本说明书实施例提及的应用架构还可以包括实时数据流复制中心 400，实时数据流复制中心400提供实时数据库数据记录变更的订阅服务，以及同构和异构数据库之间实时同步的服务，如果有实时数据流复制中心400，则主业务表和每个副业务表中的数据经过实时数据流复制中心400进行ETL 处理，得到主业务表的主增量数据、每个副业务表的副增量数据，并将主业务表的主增量数据、每个副业务表的副增量数据写入至实时数据流复制中心400。流式计算平台200接实时数据流复制中心400的数据源，从实时数据流复制中心400延时读取主增量数据，而实时读取副增量数据。

第一方面，本说明书实施例提供一种公共层宽表建设方法，应用于流式计算平台200。从而基于流式计算平台200进行小时级公共层宽表的建设，利用了流式计算的特性，能够能处理数十亿级别的数据，进一步提高了小时级公共层宽表的数据质量。相对于采用离线批处理方式进行小时级公共层表的建设而言，时效性更高，进而能够在数据量较大时保障小时级公共宽表的及时产出。离线批处理方式是将上一个小时的所有业务表的增量数据同步到离线批处理平台中进行关联。离线批处理方式处理的上一小时的数据量比较大，就无法在下一个小时的调度开始时将上一个小时的数据处理完成，进而会造成小时级公共宽表产出延时，严重影响后续依赖的业务报表产出。并且，离线批处理方式还会有数据飘移的问题，导致部分数据关联不上全部数据，进而计算出错误的小时表数据，严重影响数据质量，而本说明书实施例，通过流式计算平台200 和延时获取主业务表产生的增量数据这两方面的结合，来应对数据漂移，确保在数据量大的情况下仍然关联上全部数据，保证了公共层宽表的数据质量。

参考图2，本说明书实施例提供的公共层宽表建设方法，包括如下步骤：

S201、流式计算平台根据预设延时时长，延时获取主业务表中的主增量数据，主业务表以及与主业务表相关的至少一个副业务表属于同一业务系统。

需要说明的是，公共层(CDM，Common Dimenions Model)，即公共维度模型层，是数据仓库建设的一种分层方法，公共层细分为DWD(明细数据层) 和DWS(汇总数据层)，采用维度模型方法作为理论基础，采用一些维度退化方法，将维度退化至事实表中，减少事实表和维表的关联，提高明细数据表的易用性，同时在汇总数据层，加强指标的维度退化，采取更多的宽表化手段构建公共指标数据层，提升公共指标的复用性。

具体的，预设延时时长可以为固定延时时长。根据对主业务表进行固定延时以等待与主业务表相关的每个副业务表中对应副增量数据的到达，保证主业务表能关联到副业务表中完整数据。预设延时时长可以固定为30分钟。当然，在具体实施过程中，也可以视业务情况增加或减少延时来保证需要关联的每个副业务表的数据全部到达。

在本说明书实施例中，主业务表包含一条业务链路的主要数据，主业务表的主键具有唯一性，其他业务表被划分为副业务表。主业务表和每个副业务表中的数据均通过ETL(Extract-Transform-Load)处理，将主业务表和每个副业务表的数据从数据仓库经过萃取(extract)、转置(transform)、加载(load) 至目的端。

主业务表的数据链路由业务系统的主业务表进行驱动。在一可选的实施方式中，主业务表发生数据变更会产生数据修改日志。实时数据流复制中心解析该主业务表产生的数据修改日志，得到主增量数据。将解析得到的主增量数据写入实时数据流复制中心。基于此，S201具体为：流式计算平台根据预设延时时长，延时从实时数据流复制中心获取主增量数据。实时数据流复制中心是实时数据流基础设施，提供了实时数据库数据记录变更的订阅服务，以及同构和异构数据库之间实时同步的服务。具备对多种数据库的日志解析能力。具体来讲，以预设延时时长为30分钟为例，在主业务表产生某个主增量数据后30分钟，流式计算平台从实时数据流复制中心读取该主增量数据。

举例来讲，主业务表在3:22:36时刻发生数据变更，实时数据流复制中心实时对该主业务表发生数据变更而产生的数据修改日志进行解析，得到主增量数据A并将主增量数据A写入实时数据流复制中心。流式计算平台延时在30 分钟后，也即在3:52:36时刻从实时数据流复制中心读取主增量数据A。

具体的，数据修改日志为可以BINLOG日志，针对Mysql关系型数据库管理系统而言，数据修改日志具体为Mysql Binlog日志，需要说明的是，Mysql Binlog日志是二进制格式的日志文件，用来记录Mysql内部对数据库的改动(只记录对数据的修改操作)，主要用于该数据库的主从复制以及增量恢复。对于其他关系型数据库管理系统，则是其他的用来记录内部对数据库进行改动的日志。针对其他关系型数据库管理系统而言，可以根据是否用来记录内部对数据库的修改操作来确定具体的数据修改日志。

当然，在具体实施过程中，也可以根据预设延时时长，直接从业务系统的主业务表读取主增量数据，而不通过实时数据流复制中心，或者可以依赖其他的实时数据流基础设施。

S202、流式计算平台对目标数据库中每个与主业务表相关的热点数据表表进行检索，获取与主增量数据匹配的目标热点数据，目标热点数据与热点数据表对应的副业务表中幅增量数据对应。

主业务表，以及与主业务表相关的每个副业务表在同一业务系统的关系型数据库中，业务系统的关系型数据库与目标数据库为不同数据库。

在本说明书实施例中，热点数据表与副业务表一一对应，举例来讲，与主业务表相关的有3个副业务表X、Y、Z。则在目标数据库中有与副业务表X 对应的热点数据表X1，热点数据表X1中的热点数据来源于副业务表X，有与副业务表Y对应的热点数据表Y1、热点数据表Y1中的热点数据来源于副业务表Y；与副业务表Z对应的热点数据表Z1。

在S202中，流式计算平台可以通过用户自定义函数(UDF，User DefinedFunction)与目标数据库交互，从而完成对目标数据库中每个与主业务表相关的热点数据表进行检索，获取与主增量数据匹配的目标热点数据。具体来讲，流式计算平台每读取主增量数据的一行数据记录，则调用用户自定义函数，针对该行数据记录在目标数据库中检索所有与主业务表相关的热点数据表，得到与该行数据记录匹配的热点数据记录。

具体的，根据主增量数据中每行数据记录的主键值查询到目标热点数据。查询目标数据库中每行热点数据记录的主键值，并将主键值与主增量数据中任一行数据记录的主键值匹配的每行热点数据记录取出，作为目标热点数据。可以将热点数据记录以json(JavaScript Object Notation，是一种轻量级的数据交换格式)格式从目标数据库中取出。

在本说明实施例中，对被存入目标数据库中对应热点数据表下的每行数据记录设置TTL(Time To Live，生存时间)，所述生存时间用于使该行数据记录在热点数据表下成为热点数据记录。需要说明的是，在本说明书实施例中，热点数据中“热点”的含义是指能够被该数据处于能被外部检索到的状态。具体的，在目标数据库的每个热点数据表中，保留有预设历史时段的副增量数据所形成的热点数据。对于每个热点数据表中达到TTL的到期时间的任一行热点数据记录，目标数据库自动删除该行热点数据记录。比如，TTL可以设置为一年，实现副业务表中的副增量数据不断存储到目标数据库中，能够保留副业务表一年的历史增量数据作为热点数据。当然，可以根据实际业务情况缩短或者延长TTL，并不限制TTL为一年。

进一步的，为了保证目标数据库中的热点数据与主增量数据一一对应，对业务系统中每个副业务表产生的副增量数据进行流式预处理，将每个副业务表对应的流式预处理后的幅增量数据写入目标数据库中对应的热点数据表。

具体的，流式计算平台实时获取业务系统中每个副业务表发生数据变更所产生的副增量数据；对每个副业务表产生的副增量数据进行流式预处理，将每个副业务表对应的流式预处理后的幅增量数据存储至目标数据库中对应的热点数据表下。与延时获取主增量数据过程不同的是，流式计算平台实时读取副业务表产生的副增量数据之后，实时对读取的副增量数据进行处理，中间没有经过延时，从而使副增量数据尽快到达目标数据库中，确保在预设延时时长的这段等待时间内，副增量数据全部到达目标数据库。

每个副业务表的数据链路由对应的副业务表进行驱动，在一可选的实施方式下，流式计算平台实时从实时数据流复制中心获取每个副业务表产生的副增量数据。任一副业务表发生数据变更会对应产生数据修改日志，实时数据流复制中心解析该副业务表发生数据变更所产生的数据修改日志，得到该副业务表的副增量数据。

目标数据库可以是分布式数据库，比如，HBase数据库。HBase数据库是建立在Hadoop文件系统之上的分布式面向列的开源数据库，提供对数据的随机实时读/写访问。当然，也可以是其他分布式数据库，或者未来新的分布式数据库也可以应用在此处。

在本说明书实施例中，主业务表的主键是唯一的，而副业务表用于与主业务表进行关联的外键不唯一，进行主、副业务表直接关联会导致关联出错。因此本说明书实施例，通过对每个副业务表产生的副增量数据进行流式预处理，使得在目标数据库中进行检索时每个热点数据的关联主键是唯一的。本说明书中，对每个副业务表产生的副增量数据进行流式预处理具体可以有如下两种实施方式：

实施方式一，具体包括如下步骤：

步骤1、在副增量数据入目标数据库之前，对每个副业务表产生的副增量数据进行数据记录的行合并和/或数据记录的行筛选，得到目标入库数据，目标入库数据的数据记录与主增量数据中数据记录一一对应。

具体来讲，在每个副业务表的副增量数据入目标数据库之前，根据业务系统中的业务逻辑对副增量数据对该副增量数据进行数据记录的行合并和/或数据记录的行筛选。

其中，数据记录的行合并，是：对每个副业务表产生的副增量数据中多行数据记录合并为一行数据记录，其中，副增量数据中需要合并为一行数据记录的多行数据记录对应主增量数据中同一行数据记录。数据记录筛选是：对副增量数据中重复的多行数据记录，只保留其中一行数据记录，删除其余行数据记录。

举例来讲，主增量数据中的一行数据记录为：收入账户XX；支出账户YY；金额：200元；在副增量数据中对应有两行数据记录：

数据记录一：收入账户XX；支出账户YY；金额：150元；账单分类：消费-生活日用；创建时间20190517 20:45:28；订单号：20190517058795465；

数据记录二：收入账户XX；支出账户YY；金额：50元；账单分类：消费-生活日用；创建时间20190517 20:45:29；订单号：20190517058795465。

数据记录三：收入账户XX；支出账户YY；金额：50元；账单分类：消费-生活日用；创建时间20190517 20:45:29；订单号：20190517058795465。

针对如上三个数据记录，需要将数据记录一与数据记录二进行合并，并删除数据记录三，得到目标入库数据的一行数据记录与主增量数据中的该行数据记录“收入账户XX；支出账户YY；金额：200元”对应。

步骤2、确定出主增量数据中每行数据记录的主键值。

步骤3、针对主增量数据中每行数据记录，对该行数据记录的主键值进行加盐处理，形成目标入库数据中对应行数据记录的关联主键值。

具体来说，加盐处理就是在每行数据记录的主键值上加入其他成分(比如随机数)，形成目标入库数据中每行数据记录的关联主键值。如果对目标入库数据的主键值不加任何处理，数据记录往往会集中在几个区域Region中，通过在对数据记录的行合并和/或数据记录的行筛选的基础上再进行加盐处理，不仅使得入库数据具有唯一外键，还能够使不同的入库数据能够相对均匀的分布到各个region中，实现负载均衡。

若使用上述实施方式一设计目标数据库中每行数据记录的关联主键值，则执行步骤S202进行检索时可以直接进行检索。

实施方式二：将主增量数据中每行数据记录的主键值与副增量数据中对应数据记录的主键值进行拼接，形成副增量数据中每行数据记录的关联主键值。具体的，可以通过逗号或者其他符号进行主键值的拼接。通过实施方式二能够避免数据记录合并、筛选的过程，时效性更高。

若使用实施方式二设计关联主键值，则S202具体包括：

步骤2021、根据所述主增量数据中每行数据记录的主键值及其对应的关联主键值，在与主业务表相关的热点数据表中确定出与主增量数据中数据记录匹配的全量热点数据记录。

对目标数据库进行范围扫描的方式，对每个与主业务表相关的热点数据表进行检索，得到关联主键值与主增量数据中主键值匹配的的热点数据记录。

具体来讲，在本实施方式下，根据主增量数据中的同一行数据记录的主键值，通过范围扫描的方式能够从热点数据表中匹配到一行或者多行热点数据记录。此处的“匹配”具体是指：热点数据记录的关联主键值包含主增量数据中任一行数据记录的主键值。举例来讲，若主业务表为主支付表，其主键为“账单编号”，主增量数据中某行数据记录的主键值为“0003”，关联主键值中包含主键值“0003”的所有热点数据记录均与该数据记录匹配。比如“0003；收入账户： 26845226677”、“0003；收入账户：29645238317”。

如果针对主增量数据中同一行数据记录匹配到多行热点数据记录，则需要经过步骤2022的处理：

步骤2022、根据主增量数据中每行数据记录对全量热点数据记录中与该行数据记录匹配的多行热点数据记录进行行合并处理，和/或根据全量热点数据记录对主增量数据中的数据记录进行行拆分处理，以得到目标热点数据。

需要说明的是，热点数据记录的行合并处理可以参考前文所述。而对主增量数据中数据记录的行拆分处理，具体是将主增量数据中同一行数据记录拆分为多行数据记录。比如，主增量数据中同一行数据记录与M行热点数据记录匹配，则将主增量数据中的该行数据记录拆分为M行数据记录。

在一可选的实施方式下，创建对目标数据库的单次连接；基于单次连接对目标数据库中每个与主业务表相关的热点数据表表进行检索，检索到与主增量数据匹配的目标热点数据。由于只创建一次对目标数据库的连接而对多个表进行检索，由此避免了多次创建连接的性能问题，如果是Hbase数据库，也能更好的利用了Hbase的检索性能，保障可靠性。

S203、将目标热点数据与主业务表中的主增量数据进行拼接处理，形成写入离线批处理平台的拼接结果数据，使得离线批处理平台处理拼接结果数据表，以产出小时级公共层宽表。

为了减小后续处理的资源消耗，在步骤S203中，流式计算平台实时将目标热点数据拼接至主业务表中的主增量数据后，按照预设时间间隔将拼接结果数据写入离线批处理平台，从而每次写入离线批处理平台的数据包括在一持续时段内所拼接得到的全部拼接结果数据。从而在离线批处理平台中再经过定时对写入的拼接结果数据进行去重处理，生成小时级公共层宽表。

本说明书实施例提供的公共层宽表建设方法，可以应用于各种需要由多个业务表进行关联(join)而成公共层表的业务场景下。结合图3-图5，以支付场景为例，给出应用本说明实施例提供的方法建设小时级公共层宽表的一示例的实施过程：

用户在线购买一件商品时有很多支付渠道，如普通支付、余额支付、红包支付、外部工具支付等，不同的支付渠道对应不同的副支付表，而现在各支付渠道对应的副支付表与主支付表进行关联，形成公共层小时级表。形成公共层小时级表主要涉及两条数据链路，一条为针对主支付表的数据链路，另一条为所有需要副支付表的数据链路。下面，以目标数据库为Hbase数据库为例，分别对两条数据链路进行描述：

如图3和图4所示，主支付表的数据链路由业务系统中的主支付表进行驱动，当主支付表发生数据变更，因数据变更产生的binlog日志实时被主DRC(主的实时数据流复制中心)解析，主DRC解析出主支付表的主增量数据写入到主 DRC。主的流式计算平台接主DRC的数据源，从主增量数据被存入到主DRC 的时刻开始计算延时，主的流式计算平台在固定延时之后，便从主DRC读取该条主增量数据，每读取一条主增量数据，主的流式计算平台实时通过UDF(用户自定义函数)去Hbase数据库中检索所有相关的副支付表，在Hbase数据库中检索到关联主键值与该条主增量数据的主键值匹配的热点数据记录时，便从 Hbase数据库中将该行热点数据记录以json(JSON(JavaScript Object Notation，一种轻量级的数据交换格式)格式取出，实时与主支付表的该条主增量数据进行拼接处理，不断积累拼接结果数据，主的流式计算平台每半小时向离线批处理平台写入积累的拼接结果数据(多条)，在离线批处理平台中定时去重处理被存入的多条拼接结果数据，生成最终结果表，即：生成公共层的小时级支付数据表。

如图3和图5所示，当副支付表发生数据变更，因数据变更产生的binlog 日志实时被副的流式计算平台解析，解析出副支付表的副增量数据写入到副 DRC中。与主支付表的数据链路不同的是，副的流式计算平台没有延时，副的流式计算平台接副DRC的数据源，实时对来自副DRC的副增量数据进行流式预处理，经过流式预处理后写入Hbase数据库，对Hbase数据库中每条写入的数据记录设置TTL，在Hbase数据库对应的数据表中形成热点数据，在本示例里面，主支付表的主键是唯一的，而副支付表与主支付表进行关联的外键不唯一，需要进行Hbase数据库中关联主键的设计，关联主键的设计参考前文所述两种实施方式，为了说明书的简洁，在此不再赘述。

第二方面，基于与前述公共层宽表建设方法实施例同样的发明构思，本说明书实施例提供一种用于建设小时级公共层宽表的流式计算装置，参考图6所示，包括：

延时获取单元601，用于根据预设延时时长，延时获取主业务表中的主增量数据，所述主业务表以及与所述主业务表相关的至少一个副业务表属于同一业务系统；

检索单元602，用于对目标数据库中每个与所述主业务表相关的热点数据表表进行检索，获取与所述主增量数据匹配的目标热点数据，所述目标热点数据与所述热点数据表对应的副业务表中幅增量数据对应；

拼接单元603，用于将所述目标热点数据与所述主业务表中的主增量数据进行拼接处理，形成写入离线批处理平台的拼接结果数据，使得所述离线批处理平台处理所述拼接结果数据表，以产出小时级公共层宽表。

在一可选的实施方式中，所述装置还包括：

实时获取单元604，用于实时获取所述业务系统中每个副业务表产生的副增量数据；

预处理单元605，用于对每个副业务表产生的副增量数据进行流式预处理；

写入单元606，用于将每个副业务表对应的流式预处理后的幅增量数据存储至所述目标数据库中对应的热点数据表下。

在一可选的实施方式中，所述实时获取单元604具体用于：

实时从实时数据流复制中心获取所述副增量数据，其中，所述副增量数据由所述实时数据流复制中心解析每个副业务表的数据修改日志得到，每个副业务表的数据修改日志为对应副业务表发生数据变更所产生。

在一可选的实施方式中，所述预处理单元605具体用于：

对每个副业务表产生的副增量数据进行数据记录的行合并和/或数据记录的行筛选，得到目标入库数据，所述目标入库数据的数据记录与所述主增量数据中数据记录一一对应；

确定出所述主增量数据中每行数据记录的主键值；

针对所述主增量数据中每行数据记录，对该行数据记录的主键值进行加盐处理，形成所述目标入库数据中对应行数据记录的关联主键值。

在一可选的实施方式中，所述预处理单元605具体用于：

将所述主增量数据中每行数据记录的主键值与所述副增量数据中对应数据记录的主键值进行拼接，形成所述副增量数据中每行数据记录的关联主键值。

在一可选的实施方式中，所述检索单元602具体用于：

根据所述主增量数据中每行数据记录的主键值及其对应的关联主键值，在与所述主业务表相关的热点数据表中确定出与所述主增量数据匹配的全量热点数据记录；

根据所述主增量数据中每行数据记录，对所述全量热点数据记录中对应热点数据记录进行行合并处理，和/或根据所述全量热点数据记录对所述主增量数据中对应的数据记录进行拆分处理，得到所述目标热点数据。

在一可选的实施方式中，所述装置还包括：

热点设置单元607，用于对被存入所述目标数据库中对应的热点数据表下的每行数据记录设置生存时间，所述生存时间用于使该行数据记录在热点数据表中成为热点数据记录。

在一可选的实施方式中，所述检索单元602具体用于：

创建对所述目标数据库的单次连接；

基于所述单次连接，对所述目标数据库中每个与所述主业务表相关的热点数据表表进行检索。

在一可选的实施方式中，所述延时获取单元601具体用于：

根据所述预设延时时长，延时从实时数据流复制中心获取所述主增量数据，其中，所述主增量数据由所述实时数据流复制中心解析所述主业务表发生数据变更时的数据修改日志得到，并被实时写入至所述实时数据流复制中心。

在一可选的实施方式中，所述主业务表，以及与所述主业务表相关的每个副业务表在所述业务系统的关系型数据库中，所述业务系统的关系型数据库与所述目标数据库为不同数据库。

需要说明的是，第二方面实施例中流式计算装置的实施细节可以参考前述公共层宽表建设方法实施例中的实施细节，为了说明书的简洁，不再赘述。

第三方面，基于与前述公共层宽表建设方法实施例同样的发明构思，本发明还提供一种服务器，如图7所示，包括存储器704、处理器702及存储在存储器704上并可在处理器702上运行的计算机程序，所述处理器702执行所述程序时实现前文所述身份识别方法的任一方法的步骤。

其中，在图7中，总线架构(用总线700来代表)，总线700可以包括任意数量的互联的总线和桥，总线700将包括由处理器702代表的一个或多个处理器和存储器704代表的存储器的各种电路链接在一起。总线700还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口706在总线700和接收器701和发送器703之间提供接口。接收器701和发送器703 可以是同一个元件，即收发机，提供用于在传输介质上与各种其他装置通信的单元。处理器702负责管理总线700和通常的处理，而存储器704可以被用于存储处理器702在执行操作时所使用的数据。

第四方面，基于与前述公共层宽表建设方法实施例的发明构思，本发明还提供一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现前文所述身份识别方法的任一方法的步骤。

本说明书是参照根据本说明书实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的设备。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令设备的制造品，该指令设备实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本说明书的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本说明书范围的所有变更和修改。

显然，本领域的技术人员可以对本说明书进行各种改动和变型而不脱离本说明书的精神和范围。这样，倘若本说明书的这些修改和变型属于本说明书权利要求及其等同技术的范围之内，则本说明书也意图包含这些改动和变型在内。

Claims (22)

1.一种公共层宽表建设方法，应用于流式计算平台，所述方法包括：

根据预设延时时长，延时获取主业务表中的主增量数据，所述主业务表以及与所述主业务表相关的至少一个副业务表属于同一业务系统；

对目标数据库中每个与所述主业务表相关的热点数据表进行检索，获取与所述主增量数据匹配的目标热点数据，所述目标热点数据与所述热点数据表对应的副业务表中幅增量数据对应；

将所述目标热点数据与所述主业务表中的主增量数据进行拼接处理，形成写入离线批处理平台的拼接结果数据，使得所述离线批处理平台处理所述拼接结果数据表，以产出小时级公共层宽表。

2.如权利要求1所述的公共层宽表建设方法，还包括：

实时获取所述业务系统中每个副业务表产生的副增量数据；

对每个副业务表产生的副增量数据进行流式预处理；

将每个副业务表对应的流式预处理后的幅增量数据存储至所述目标数据库中对应的热点数据表下。

3.如权利要求2所述的公共层宽表建设方法，所述实时获取所述业务系统中每个副业务表产生的副增量数据，包括：

实时从实时数据流复制中心获取所述副增量数据，其中，所述副增量数据由所述实时数据流复制中心解析每个副业务表的数据修改日志得到，每个副业务表的数据修改日志为对应副业务表发生数据变更所产生。

4.如权利要求2所述的公共层宽表建设方法，所述对每个副业务表产生的副增量数据进行流式预处理，包括：

对每个副业务表产生的副增量数据进行数据记录的行合并和/或数据记录的行筛选，得到目标入库数据，所述目标入库数据中数据记录与所述主增量数据中数据记录一一对应；

确定出所述主增量数据中每行数据记录的主键值；

针对所述主增量数据中每行数据记录，对该行数据记录的主键值进行加盐处理，形成所述目标入库数据中对应行数据记录的关联主键值。

5.如权利要求2所述的公共层宽表建设方法，所述对每个副业务表产生的副增量数据进行流式预处理，包括：

将所述主增量数据中每行数据记录的主键值与所述副增量数据中对应行数据记录的主键值进行拼接，形成所述副增量数据中每行数据记录的关联主键值。

6.如权利要求5所述的公共层宽表建设方法，所述对目标数据库中每个与所述主业务表相关的热点数据表表进行检索，获取与所述主增量数据匹配的目标热点数据，包括：

根据所述主增量数据中每行数据记录的主键值及其对应的关联主键值，在与所述主业务表相关的热点数据表中确定出与所述主增量数据匹配的全量热点数据记录；

根据所述主增量数据中每行数据记录，对所述全量热点数据记录中对应的热点数据记录进行行合并处理，和/或根据所述全量热点数据记录对所述主增量数据中对应的数据记录进行行拆分处理，得到所述目标热点数据。

7.如权利要求2所述的公共层宽表建设方法，所述将每个副业务表对应的流式预处理后的幅增量数据存储至所述目标数据库中对应的热点数据表下，包括：

对被存入所述目标数据库中对应的热点数据表下的每行数据记录设置生存时间，所述生存时间用于使该行数据记录在热点数据表中成为热点数据记录。

8.如权利要求1-7中任一所述的公共层宽表建设方法，所述对目标数据库中每个与所述主业务表相关的热点数据表表进行检索，包括：

创建对所述目标数据库的单次连接；

基于所述单次连接，对所述目标数据库中每个与所述主业务表相关的热点数据表表进行检索。

9.如权利要求1所述的公共层宽表建设方法，所述根据预设延时时长，延时获取主业务表中的主增量数据，包括：

根据所述预设延时时长，延时从实时数据流复制中心获取所述主增量数据，其中，所述主增量数据由所述实时数据流复制中心解析所述主业务表发生数据变更时的数据修改日志得到，并被实时写入至所述实时数据流复制中心。

10.如权利要求1所述的公共层宽表建设方法，所述主业务表，以及与所述主业务表相关的每个副业务表在所述业务系统的关系型数据库中，所述业务系统的关系型数据库与所述目标数据库为不同数据库。

11.一种用于建设小时级公共层宽表的流式计算装置，包括：

延时获取单元，用于根据预设延时时长，延时获取主业务表中的主增量数据，所述主业务表以及与所述主业务表相关的至少一个副业务表属于同一业务系统；

检索单元，用于对目标数据库中每个与所述主业务表相关的热点数据表表进行检索，获取与所述主增量数据匹配的目标热点数据，所述目标热点数据与所述热点数据表对应的副业务表中幅增量数据对应；

拼接单元，用于将所述目标热点数据与所述主业务表中的主增量数据进行拼接处理，形成写入离线批处理平台的拼接结果数据，使得所述离线批处理平台处理所述拼接结果数据表，以产出小时级公共层宽表。

12.如权利要求11所述的流式计算装置，所述装置还包括：

实时获取单元，用于实时获取所述业务系统中每个副业务表产生的副增量数据；

预处理单元，用于对每个副业务表产生的副增量数据进行流式预处理；

写入单元，用于将每个副业务表对应的流式预处理后的幅增量数据存储至所述目标数据库中对应的热点数据表下。

13.如权利要求12所述的流式计算装置，所述实时获取单元具体用于：

实时从实时数据流复制中心获取所述副增量数据，其中，所述副增量数据由所述实时数据流复制中心解析每个副业务表的数据修改日志得到，每个副业务表的数据修改日志为对应副业务表发生数据变更所产生。

14.如权利要求12所述的流式计算装置，所述预处理单元具体用于：

对每个副业务表产生的副增量数据进行数据记录的行合并和/或数据记录的行筛选，得到目标入库数据，所述目标入库数据中数据记录与所述主增量数据中数据记录一一对应；

确定出所述主增量数据中每行数据记录的主键值；

针对所述主增量数据中每行数据记录，对该行数据记录的主键值进行加盐处理，形成所述目标入库数据中对应行数据记录的关联主键值。

15.如权利要求12所述的流式计算装置，所述预处理单元具体用于：

将所述主增量数据中每行数据记录的主键值与所述副增量数据中对应数据记录的主键值进行拼接，形成所述副增量数据中每行数据记录的关联主键值。

16.如权利要求15所述的流式计算装置，所述检索单元具体用于：

根据所述主增量数据中每行数据记录的主键值及其对应的关联主键值，在与所述主业务表相关的热点数据表中确定出与所述主增量数据匹配的全量热点数据记录；

根据所述主增量数据中每行数据记录，对所述全量热点数据记录中对应热点数据记录进行行合并处理，和/或根据所述全量热点数据记录对所述主增量数据中对应的数据记录进行拆分处理，得到所述目标热点数据。

17.如权利要求12所述的流式计算装置，所述装置还包括：

热点设置单元，用于对被存入所述目标数据库中对应的热点数据表下的每行数据记录设置生存时间，所述生存时间用于使该行数据记录在热点数据表中成为热点数据记录。

18.如权利要求11-17中任一所述的流式计算装置，所述检索单元具体用于：

创建对所述目标数据库的单次连接；

基于所述单次连接，对所述目标数据库中每个与所述主业务表相关的热点数据表表进行检索。

19.如权利要求11所述的流式计算装置，所述延时获取单元，具体用于：

根据所述预设延时时长，延时从实时数据流复制中心获取所述主增量数据，其中，所述主增量数据由所述实时数据流复制中心解析所述主业务表发生数据变更时的数据修改日志得到，并被实时写入至所述实时数据流复制中心。

20.如权利要求1所述的流式计算装置，所述主业务表，以及与所述主业务表相关的每个副业务表在所述业务系统的关系型数据库中，所述业务系统的关系型数据库与所述目标数据库为不同数据库。

21.一种服务器，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现权利要求1-9任一项所述方法的步骤。

22.一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现权利要求1-10任一项所述方法的步骤。