CN113760922A - 一种业务数据处理系统、方法、服务器和存储介质 - Google Patents

Abstract

本发明实施例公开了一种业务数据处理系统、方法、服务器和存储介质，该系统包括：数据仓库集市数据层，用于按照预设频率将各业务数据源的全量数据同步到数据仓库数据集市，并对所述全量数据进行处理，得到业务宽表全量数据；增量数据层，用于与所述各业务数据源对接，获取各业务数据源的实时增量数据，得到业务宽表增量数据；业务处理层，用于对所述业务宽表全量数据进行校验，并将经过校验的业务宽表全量数据与所述业务宽表增量数据进行数据融合得到目标业务宽表数据。通过本发明实施例的技术方案，可以实现多业务部门间繁琐对接流程的解耦，而且保障了多数据源的对接时数据的一致性。

Description

一种业务数据处理系统、方法、服务器和存储介质

技术领域

本发明实施例涉及计算机技术领域，尤其涉及一种业务数据处理系统、方法、服务器和存储介质。

背景技术

目前，随着智能化数据管理需求的普及，业务方不仅仅关系实时数据的分析展示，同样关心历史日期同时刻下的对比数据，通过两部分数据对比分析，可以让业务人员更好的了解各项指标的数据趋势，把握业务动态，进而更好的执行计划和指导实际的生产操作。

目前，常规的业务对接方案是通过如图1所示的数据处理框架来完成的，不同的数据源均通过接口调用的方式将全量数据一次同步到业务方的数据库中生成业务宽表全量数据。

但是，在实现本发明的过程中，发明人发现现有技术中至少存在以下技术问题：随着自身业务模型的发展，自身业务宽表将对接多个系统获取基础宽表数据，将全量数据一次性对接，不能保证数据异构后的事务一致性。

发明内容

本发明实施例提供了一种业务数据处理系统、方法、服务器和存储介质，以减少同步全量数据时不同业务数据源之间的耦合，并能保证数据的一致性与准确性。

第一方面，本发明实施例提供了一种业务数据处理系统，该系统包括：

数据仓库集市数据层，用于按照预设频率将各业务数据源的全量数据同步到数据仓库数据集市，并对所述全量数据进行处理，得到业务宽表全量数据；

增量数据层，用于与所述各业务数据源对接，获取各业务数据源的实时增量数据，得到业务宽表增量数据；

业务处理层，用于对所述业务宽表全量数据进行校验，并将经过校验的业务宽表全量数据与所述业务宽表增量数据进行数据融合得到目标业务宽表数据。

可选的，所述数据仓库集市数据层具体用于：

以天为单位，每天将当前数据同步时刻之前的所述各业务数据源的全量数据同步到所述数据仓库数据集市并记录数据同步的时间戳；

按照当前业务方的业务模型将所述全量数据进行整合得到当日业务宽表全量数据；

将所述当日业务宽表全量数据以及所述时间戳推送到所述当前业务方的业务数据库。

可选的，所述业务处理层对所述业务宽表全量数据进行校验，包括：

确定所述各业务数据源的全量数据是否发生变化；

若是，则根据变化后的全量数据更新所述当日业务宽表全量数据。

可选的，所述业务处理层进行数据融合时，通过调用Job任务在预设时间，将所述当日业务宽表全量数据和所述时间戳后的增量数据进行去重合并得到当日目标业务宽表数据。

可选的，所述增量数据层通过消息队列方式对接所述各业务数据源。

可选的，所述业务处理层在进行数据融合前还用于对所述业务宽表增量数据进行数据校验和过滤。

可选的，所述业务处理层将所述业务宽表增量数据存储到MySQL数据库中，并使用分布式锁以保证所述各业务数据源增量数据的事务一致性。

可选的，所述系统还包括：业务存储层，用于将所述当日目标业务宽表数据存储到所述业务数据库中，并将所述当日目标业务宽表数据之前的目标业务宽表数据归档到ClickHouse数据库中进行分区存储。

第二方面，本发明实施例还提供了一种业务数据处理方法，应用于业务数据处理系统，该方法包括：

从数据仓库数据集市中获取当日业务宽表全量数据，其中，所述数据仓库数据集市包括每日更新的各业务数据源的全量数据，所述当日业务宽表全量数据是在所述数据仓库数据集市中对所述各业务数据源的全量数据进行处理得到的；

从所述各业务数据源实时获取增量数据，得到业务宽表增量数据；

将所述当日业务宽表全量数据与业务宽表增量数据进行数据融合得到当日目标业务宽表数据。

可选的，所述在所述数据仓库数据集市中对所述各业务数据源的全量数据进行处理，包括：

每天将当前数据同步时刻之前的所述各业务数据源的全量数据同步到所述数据仓库数据集市并记录数据同步的时间戳；

按照当前业务方的业务模型将所述全量数据进行整合得到所述当日业务宽表全量数据。

可选的，所述方法还包括：

将所述当日目标业务宽表数据存储到MySQL数据库中，并将所述当日目标业务宽表数据之前的目标业务宽表数据归档到ClickHouse数据库中进行分区存储。

可选的，所述方法还包括：

所述业务宽表增量数据存储到MySQL数据库中，并使用分布式锁以保证所述各业务数据源增量数据的事务一致性。

第三方面，本发明实施例还提供了一种服务器，所述服务器包括：

一个或多个处理器；

存储器，用于存储一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如本发明任意实施例所提供的业务数据处理方法步骤。

第四方面，本发明实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本发明任意实施例所提供的业务数据处理方法步骤。

上述发明中的实施例具有如下优点或有益效果：

通过数据仓库集市数据层、增量数据层以及业务处理层组成业务数据处理系统，在数据仓库集市数据层将数据仓库数据仓库作为数据集市并按照预设频率同步多数据原的全量数据，并将各数据源的全量数据进行处理得到业务方的业务宽表全量数据，再由业务处理层对业务宽表全量数据进行校验，将通过校验的业务宽表全量数据与增量数据层得到的业务宽表增量数据进行融合得到目标业务宽表，使业务处理层在得到目标业务宽表过程中无需按照业务逻辑到相应的业务数据源读取数据，实现了多业务部门间繁琐对接流程的解耦，而且该系统按照一定频率同步数据，并对业务宽表全量数据进行校验保障了多数据源的对接时数据的一致性。

附图说明

图1是现有技术中业务数据处理架构的结构示意图；

图2是本发明实施例一提供的一种业务数据处理系统的结构示意图；

图3是本发明实施例二提供的一种业务数据处理系统的结构示意图；

图4是本发明实施例二提供的一种业务数据处理系统实例架构图；

图5是本发明实施例三提供的一种业务数据处理方法的流程图；

图6是本发明实施例三提供的一种数据查询页面的示意图；

图7是本发明实施例四提供的一种服务器的结构示意图。

具体实施方式

下面结合附图和实施例对本发明作进一步的详细说明。可以理解的是，此处所描述的具体实施例仅仅用于解释本发明，而非对本发明的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本发明相关的部分而非全部结构。

实施例一

图2为本发明实施例一提供的一种业务数据处理系统的结构示意图，本实施例可适用于业务方对接多数据源进行业务数据整合的情况。该系统可以由软件和/或硬件的方式来实现，集成于具有应用开发功能的设备中。该系统具体包括以下结构：

数据仓库集市数据层110、增量数据层120以及业务处理层130。

其中，数据仓库集市数据层110，用于按照预设频率将各业务数据源的全量数据同步到数据仓库数据集市，并对所述全量数据进行处理，得到业务宽表全量数据。

具体的，数据仓库集市数据层110将Hive数据仓库作为一个存储有大量数据的Hive数据集市(数据仓库数据集市)，是一种可以存储、查询和分析存储在Hadoop中的大规模数据的机制。其中的数据是按照预设频率从当前业务方相关的业务数据源同步过来的数据。当前业务方可以是一个销售商家或是平台，业务数据源即为当前业务方销售的各种商品具体售卖信息生成的源头。预设频率可以是是每几个小时同步一次数据，或是以天(一天、两天等任意天数)为单位进行数据同步，通常是以天为单位，每日进行一次数据同步。

进一步的，在数据仓库集市数据层110还对同步的数据进行初步的处理的，得到符合当前业务方的业务模型的业务宽表全量数据，并将业务宽表全量数据存储到业务方的业务数据库中。这样，当前业务方在梳理业务数据时便无需根据业务处理逻辑再到各个相关的业务数据源读取相应的业务数据了，可以解耦各业务部门繁琐的对接流程，具有良好的业务解耦性，节省全量异构时过多的接口对接和联调的开销。

示例性的，在一个具体的实施方式中，可以以天为单位，在每天固定时刻(如00:00)将各业务数据源历史数据，即当前时刻之前的所有数据(T+1数据)，同步到Hive集市上并记录数据同步的时间戳，按照当前业务方的业务模型将所述全量数据进行整合得到当日业务宽表全量数据，并每日推送到业务数据库。其中，业务数据库可以是MySQL数据库。

增量数据层120，用于与所述各业务数据源对接，获取各业务数据源的实时增量数据，得到业务宽表增量数据。具体的，增量数据层通过消息队列方式(MQ)的点对点方式或是发布-订阅消息传递方式(kafka)对接所述各业务数据源，获取到增量数据。

通常，在对每天的业务数据进行分析处理时，会相对于获取的历史全量数据有一个延时时差。例如，每天的00:00点获取当天之前的所有历史全量数据，而当前业务方需要在当天的15:00完成当天的业务数据统计，那么在从00：00-15:00这一时间段内，业务数据还会发生变化，这就需要在整理当日数据之前收集到所有的动态变化信息，例如，商品销售过程中，商品库存是变化的，可以是补货增加库存，也可以是销售减少库存。进一步的，再由业务处理层130进行数据处理。

业务处理层130，用于对业务宽表全量数据进行校验，并将经过校验的业务宽表全量数据与所述业务宽表增量数据进行数据融合得到目标业务宽表数据。

具体的，业务处理层对业务宽表全量数据进行校验，包括确定所述各业务数据源的全量数据是否发生变化，例如，一些数据是否还具有有效性等变化；若是，则根据变化后的全量数据更新所述业务宽表全量数据。或者，也可以直接使用每天全量数据同步之后的新数据进行数据处理。这样可以保证每天进行数据处理之后的业务数据与数据源数据保持一致。

由于全量数据和增量数据叠加可能会出现数据重复和先后顺序混乱，后期数据的聚合查询的准确性将会受到影响，因此需要对数据进行去重合，保证数据的有序性以及完整性。当业务数据库接收到业务宽表全量数据后，会有一张状态记录表记录数据接收成功状态，在预设时刻，业务处理层中的JOB任务会触发校验接收到的业务宽表全量数据，然后根据时间戳版本将每日最新的业务宽表全量数据和增量消息去重合并处理，得到达到数据准确的每日目标业务宽表数据。示例性的，假设增量信息为商品P的库存信息，在第一时刻，P的库存信息变为零，在第二时刻，P的库存信息变为10，在第三时刻，P的库存信息变为2，第四时刻，P的库存信息又变为10，那么在进行数据合并的时候，只把第四时刻的P的库存数据更新即可，第一、第二以及第三时刻的数据可以过滤掉，这样得到的目标业务宽表数据即为最新的数据。

本实施例的技术方案，通过Hive集市数据层、增量数据层以及业务处理层组成业务数据处理系统，在Hive集市数据层将Hive数据仓库作为数据集市并按照预设频率同步多数据原的全量数据，并将各数据源的全量数据进行处理得到业务方的业务宽表全量数据，再由业务处理层对业务宽表全量数据进行校验，将通过校验的业务宽表全量数据与增量数据层得到的业务宽表增量数据进行融合得到目标业务宽表，使业务处理层在得到目标业务宽表过程中无需按照业务逻辑到相应的业务数据源读取数据，实现了多业务部门间繁琐对接流程的解耦，而且该系统按照一定频率同步数据，并对业务宽表全量数据进行校验保障了多数据源的对接时数据的一致性。

实施例二

图3为本发明实施例二提供的一种业务数据处理系统的结构示意图，本实施例在上述实施例的基础上，进一步完善业务数据处理系统，增加了业务数据存储层。其中与上述实施例相同或相应的术语的解释在此不再赘述。

参见图3，本实施例提供的业务数据处理系统具体包括以下结构：

数据仓库集市数据层110、增量数据层120、业务处理层130和业务存储层140。

其中，数据仓库集市数据层110，用于按照预设频率将各业务数据源的全量数据同步到Hive数据集市，并对所述全量数据进行处理，得到业务宽表全量数据；增量数据层120，用于与所述各业务数据源对接，获取各业务数据源的实时增量数据，得到业务宽表增量数据；业务处理层130，用于对所述业务宽表全量数据进行校验，并将经过校验的业务宽表全量数据与所述业务宽表增量数据进行数据融合得到目标业务宽表数据；业务存储层140，用于将当日目标业务宽表数据存储到业务数据库中，并将当日目标业务宽表数据之前的目标业务宽表数据归档到ClickHouse数据库中进行分区存储。

进一步的，在业务处理层130还会按照预设约束条件对增量数据进行过滤，例如，预设条件为只显示库存数量小于等于1的商品，那么在多个数据源的增量信息中，商品库存大于1的信息将会被过滤掉。在实际的应用中，可以根据业务需求设定相应的约束条件。

在一种优选地实施方式中，为了保障增量数据的事务性，选择将增量数据存储在Mysql数据库中，同时通过分布式锁保障数据的事务性和一致性，分布式锁可以是Redis分布式锁或是其他形式的分布式锁。

进一步的，业务存储层140，用于将日目标业务宽表数据存储到所述业务数据库中，并将当日目标业务宽表数据之前的目标业务宽表数据归档到ClickHouse数据库中进行分区存储。其中，业务数据库为MySQL数据库。选择Mysql和ClickHouse，主要是根据数据特点选择的，每日数据由于包括要大量的增量数据和全量数据更新，对事务性要求和插入更新性能要就较高，因此Mysql是很好的选择。而当日目标业务宽表数据之前的目标业务宽表数据(即历史数据)由于数据量很大选用ClickHouse数据库存储此部分数据，不选用常规Mysql分库分表解决方案主要原因是，如果使用Mysql分库分表，会使存储性能和后期的不同字段的聚合查询性能受到影响(实际场景应用中，2000万数据，使用Mysql数据库聚合查询会延迟10s以上)，并且此部分数据还有以下特点：数据量较大，不需要更改，且需要复杂的聚合查询，因此本系统引入ClickHouse数据库，实现归档数据的分区存储。ClickHouse是一个列式数据库，适合大数据量数据聚合操作，查询性能比较好(秒级查询)，解决了以上业务场景的存储和查询问题，可以支撑住业务在未来的数据量的增加。具体的，当当日目标业务宽表数据成为历史数据时，会被推送到Hive数据集市中，进而在数据集市中通过调度任务同步归档数据到ClickHouse分区。

图4为一个具体的实例中的业务数据处理系统架构，在该架构下包括Hive集市数据层(数据仓库集市数据层)、增量数据层、业务处理层以及业务数据存储层。在该图中仅示出了三个不同的业务数据源作为多个业务数据源的代表，即业务1、业务2和业务3。在每天固定时刻(如00:00)将各业务数据源历史数据，即当前时刻之前的所有数据(T+1数据)，同步到Hive数据集市上并记录数据同步的时间戳，按照当前业务方的业务模型将同步得到的全量数据进行整合得到业务宽表全量数据(业务宽表T+1数据)，并推送到业务数据库。其中，业务数据库可以是MySQL数据库。可以理解的是，每天进行一次业务数据源的历史数据同步即完成了历史数据的每日校验。进一步的，业务数据处理系统调用相应的接口与各个业务数据源相连接，并通过MQ或是Binlog方式接收增量数据，得到业务宽表增量数据。在业务处理层对增量数据进行数据指标加工，包括业务校验、数据补充等，并实现接口的幂等性和事务性保障(即图4中的核心逻辑处理)，然后将经过处理的增量数据与全量数据进行数据合并得到目标业务宽表数据，在该层还可以记录数据处理日志，对数据处理进行监控。进一步的，经过业务处理层得到的目标业务宽表数据会被存储到MySQL数据库中，当次日，该目标业务宽表数据成为历史书时便会被归档到ClickHouse数据库中。可以提供给业务方进行历史数据联表查询以及历史数据对比。

本实施例的技术方案，通过数据仓库集市数据层、增量数据层以及业务处理层组成业务数据处理系统，在数据仓库集市数据层将Hive数据仓库作为数据集市并按照预设频率同步多数据原的全量数据，并将各数据源的全量数据进行处理得到业务方的业务宽表全量数据，再由业务处理层对业务宽表全量数据进行校验，将通过校验的业务宽表全量数据与增量数据层得到的业务宽表增量数据进行融合得到目标业务宽表，使业务处理层在得到目标业务宽表过程中无需按照业务逻辑到相应的业务数据源读取数据，实现了多业务部门间繁琐对接流程的解耦，而且该系统按照一定频率同步数据，并对业务宽表全量数据进行校验保障了多数据源的对接时数据的一致性。而且将当日目标业务宽表存储到MySQL数据库中，将历史目标业务宽表归档到ClickHouse数据库中，提数据高查询效率。

以下是本发明实施例提供的业务数据处理方法的实施例，该方法与上述各实施例的业务数据处理系统属于同一个发明构思，可通过上述各实施例的业务数据处理系统执行该方法。在业务数据处理方法的实施例中未详尽描述的细节内容，可以参考上述业务数据处理系统的实施例。

实施例三

图5为本发明实施例三提供的一种业务数据处理方法的流程图，本实施例可适用于业务方对接多数据源进行业务数据整合的情况。该方法具体包括以下步骤：

S210、从数据仓库数据集市中获取当日业务宽表全量数据，其中，所述数据仓库数据集市包括每日更新的各业务数据源的全量数据，所述当日业务宽表全量数据是在所述数据仓库数据集市中对所述各业务数据源的全量数据进行处理得到的。

具体的，业务数据处理系统中包括数据仓库集市数据层，该层将Hive数据仓库作为一个存储有大量数据的Hive数据集市，是一种可以存储、查询和分析存储在Hadoop中的大规模数据的机制。其中的数据是每天从当前业务方相关的业务数据源同步过来的数据，同时还记录了同步数据的时间戳(也即某一时刻的数据快照)。当前业务方可以是一个销售商家或是平台，业务数据源即为当前业务方销售的各种商品具体售卖信息生成的源头。

进一步的，在数据仓库集市数据层还对每天同步的数据进行初步的处理的，得到符合当前业务方的业务模型的当日业务宽表全量数据，并将当日业务宽表全量数据存储到业务方的业务数据库中。这样，当前业务方在梳理业务数据时便无需根据业务处理逻辑再到各个相关的业务数据源读取相应的业务数据了，可以解耦各业务部门繁琐的对接流程，具有良好的业务解耦性，节省全量异构时过多的接口对接和联调的开销。

S220、从所述各业务数据源实时获取增量数据，得到业务宽表增量数据。

具体的，在业务数据处理系统中，增量数据层通过消息队列方式(MQ)的点对点方式或是发布-订阅消息传递方式(kafka)对接各业务数据源，获取到业务宽表增量数据。业务宽表增量数据存储到MySQL数据库中，并使用分布式锁以保证所述各业务数据源增量数据的事务一致性。

通常，在对每天的业务数据进行分析处理时，会相对于获取的历史全量数据有一个延时时差。例如，每天的00:00点获取当天之前的所有历史全量数据，而当前业务方需要在当天的15:00完成当天的业务数据统计，那么在从00：00-15:00这一时间段内，业务数据还会发生变化，这就需要在整理当日数据之前收集到所有的动态变化信息，例如，商品销售过程中，商品库存是变化的，可以是补货增加库存，也可以是销售减少库存。

S230、将所述当日业务宽表全量数据与业务宽表增量数据进行数据融合得到当日目标业务宽表数据。

由于当日业务宽表全量数据和增量数据叠加可能会出现数据重复和先后顺序混乱，后期数据的聚合查询的准确性将会受到影响，因此需要对数据进行去重合，保证数据的有序性以及完整性。当业务数据库接收到业务宽表全量数据后，会有一张状态记录表记录数据接收成功状态，在预设时刻，业务处理层中的JOB任务会触发校验接收到的业务宽表全量数据，然后根据时间戳版本将每日最新的业务宽表全量数据和增量消息去重合并处理，得到达到数据准确的每日目标业务宽表数据。示例性的，假设增量信息为商品P的库存信息，在第一时刻，P的库存信息变为零，在第二时刻，P的库存信息变为10，在第三时刻，P的库存信息变为2，第四时刻，P的库存信息又变为10，那么在进行数据合并的时候，只把第四时刻的P的库存数据更新即可，第一、第二以及第三时刻的数据可以过滤掉，这样得到的当日目标业务宽表数据即为最新的数据。

进一步的，业务数据处理系统还会将当日目标业务宽表数据存储到MySQL数据库中，并将所述当日目标业务宽表数据之前的目标业务宽表数据归档到ClickHouse数据库中进行分区存储，以供用户进行历史数据的查询以及对比。这是因为ClickHouse是一个列式数据库，适合大数据量数据聚合操作，查询性能比较好(秒级查询)，解决了本实施例的业务场景中存储和查询问题，可以支撑住业务在未来的数据量的增加。

示例性的，现以商城应用APP缺货分析业务场景来举例说明：

具体的，APP缺货分析主要希望展示两部分数据，一部分是此刻实时缺货的数据分析，另一部分是同时刻下历史数据的对比分析(如现在时刻Time1，对比昨天Time1时刻的快照数据)。

在业务数据处理系统中，全量数据通过Hive数据集市的库存模型、商品模型等业务模型加工而来，生成APP缺货业务模型，数据为T+1每日全量数据，是通过调度任务由Hive数据集市推送给Mysql数据库。增量数据通过对接全渠道库存MQ消息获取，并保存在Mysql数据库中。

出于增量数据的高并发和数据一致性考虑，使用了redis分布式锁对每一个主键数据进行事务保障，比如在这个业务场景下，通过对storeId+skuId+status+qty(门店Id+商品Id+上下架等状态+库存数量)进行校验和事务保障，其中校验过程参考表1中记录的内容，即只有同日期下上下架状态变化或者库存变化(库存由0变为非0或者非0变为0)的数据，需要新增到数据库了。进一步，通过分组聚合查询，可以查出每日最新状态是缺货的商品(sku)，进行统计和详情查询。同时，全量数据同步任务执行成功后触发的JOB任务可以合并全量数据和增量数据两部分数据，针对时间顺序进行数据去重。

表1

SKU

库存

时间

渠道

状态

日期

是否新增

sku1

0

10:00

APP

上架

02-19

是，新数据

sku1

0

10:00

APP

上架

02-20

是，日期不同

sku1

0

10:20

APP

上架

02-20

否，库存不变

sku1

3

11:00

APP

上架

02-20

是，库存变化

sku1

2

11:10

APP

上架

02-20

否，库存仍非0

sku1

0

12:00

APP

上架

02-20

是，库存变化

sku1

0

13:00

APP

下架

02-20

是，状态变化

进一步的，任务数据处理系统还可以通过调度任务将每日缺货分析数据由Mysql推送到Hive数据集市中，推送成功后，将该数据归档数据同步到ClickHouse中，按日期分区存储。还可以提供聚合查询和页面数据支持，查询页面如图6所示。在图6中展示了一个缺货统计数据页面，在该页面中包括商品的品类信息，可以选择餐饮美食、生鲜、或生活百货某一品类下的数据，在该界面中还显示了实时缺货监控数据，如缺货的商品数量为1807件，该实时缺货数量对比日期是2020-2-28日同一个时间的数据下降了94.6％。其中，数据对比的时期可以选择任意一天的历史过往数据。此外，在图6界面中，还可以显示不同店铺当日缺货的商品(shu)数量以及对比日缺货商品数量，还可以进一步的获取单品缺货单等数据。

本实施例的技术方案，通过业务数据处理系统每天在Hive集市获取当日业务宽表全量数据，再通过消息队列的方式获取增量数据，将当日业务宽表全量数据与增量数据层得到的业务宽表增量数据进行融合得到当日目标业务宽表，在得到目标业务宽表过程中无需按照业务逻辑到相应的业务数据源读取数据，实现了多业务部门间繁琐对接流程的解耦，而且该系统按照一定频率同步数据，并对业务宽表全量数据进行校验保障了多数据源的对接时数据的一致性。而且将当日目标业务宽表存储到MySQL数据库中，将历史目标业务宽表归档到ClickHouse数据库中，提数据高查询效率。

实施例四

图7为本发明实施例四提供的一种服务器的结构示意图。图7示出了适于用来实现本发明实施方式的示例性服务器12的框图。图7显示的服务器12仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图7所示，服务器12以通用计算设备的形式表现。服务器12的组件可以包括但不限于：一个或者多个处理器或者处理单元16，系统存储器28，连接不同系统组件(包括系统存储器28和处理单元16)的总线18。

总线18表示几类总线结构中的一种或多种，包括存储器总线或者存储器控制器，外围总线，图形加速端口，处理器或者使用多种总线结构中的任意总线结构的局域总线。举例来说，这些体系结构包括但不限于工业标准体系结构(ISA)总线，微通道体系结构(MAC)总线，增强型ISA总线、视频电子标准协会(VESA)局域总线以及外围组件互连(PCI)总线。

服务器12典型地包括多种计算机系统可读介质。这些介质可以是任何能够被服务器12访问的可用介质，包括易失性和非易失性介质，可移动的和不可移动的介质。

系统存储器28可以包括易失性存储器形式的计算机系统可读介质，例如随机存取存储器(RAM)30和/或高速缓存存储器32。服务器12可以进一步包括其它可移动/不可移动的、易失性/非易失性计算机系统存储介质。仅作为举例，存储系统34可以用于读写不可移动的、非易失性磁介质(图7未显示，通常称为“硬盘驱动器”)。尽管图7中未示出，可以提供用于对可移动非易失性磁盘(例如“软盘”)读写的磁盘驱动器，以及对可移动非易失性光盘(例如CD-ROM,DVD-ROM或者其它光介质)读写的光盘驱动器。在这些情况下，每个驱动器可以通过一个或者多个数据介质接口与总线18相连。系统存储器28可以包括至少一个程序产品，该程序产品具有一组(例如至少一个)程序模块，这些程序模块被配置以执行本发明各实施例的功能。

具有一组(至少一个)程序模块42的程序/实用工具40，可以存储在例如系统存储器28中，这样的程序模块42包括但不限于操作系统、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。程序模块42通常执行本发明所描述的实施例中的功能和/或方法。

服务器12也可以与一个或多个外部设备14(例如键盘、指向设备、显示器24等)通信，还可与一个或者多个使得用户能与该服务器12交互的设备通信，和/或与使得该服务器12能与一个或多个其它计算设备进行通信的任何设备(例如网卡，调制解调器等等)通信。这种通信可以通过输入/输出(I/O)接口22进行。并且，服务器12还可以通过网络适配器20与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器20通过总线18与服务器12的其它模块通信。应当明白，尽管图中未示出，可以结合服务器12使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理单元、外部磁盘驱动阵列、RAID系统、磁带驱动器以及数据备份存储系统等。

处理单元16通过运行存储在系统存储器28中的程序，从而执行各种功能应用以及数据处理，例如实现本发实施例所提供的一种业务数据处理方法步骤，该方法包括：

从数据仓库数据集市中获取当日业务宽表全量数据，其中，所述数据仓库数据集市包括每日更新的各业务数据源的全量数据，所述当日业务宽表全量数据是在所述数据仓库数据集市中对所述各业务数据源的全量数据进行处理得到的；

从所述各业务数据源实时获取增量数据，得到业务宽表增量数据；

将所述当日业务宽表全量数据与业务宽表增量数据进行数据融合得到当日目标业务宽表数据。

当然，本领域技术人员可以理解，处理器还可以实现本发明任意实施例所提供的业务数据处理方法的技术方案。

实施例五

本实施例五提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现如本发明任意实施例所提供的业务数据处理方法步骤，该方法包括：

从数据仓库数据集市中获取当日业务宽表全量数据，其中，所述数据仓库数据集市包括每日更新的各业务数据源的全量数据，所述当日业务宽表全量数据是在所述数据仓库数据集市中对所述各业务数据源的全量数据进行处理得到的；

从所述各业务数据源实时获取增量数据，得到业务宽表增量数据；

将所述当日业务宽表全量数据与业务宽表增量数据进行数据融合得到当日目标业务宽表数据。

本发明实施例的计算机存储介质，可以采用一个或多个计算机可读的介质的任意组合。计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质。计算机可读存储介质例如可以是但不限于：电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本文件中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。

计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

可以以一种或多种程序设计语言或其组合来编写用于执行本发明操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言，诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言，诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

本领域普通技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个计算装置上，或者分布在多个计算装置所组成的网络上，可选地，他们可以用计算机装置可执行的程序代码来实现，从而可以将它们存储在存储装置中由计算装置来执行，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件的结合。

注意，上述仅为本发明的较佳实施例及所运用技术原理。本领域技术人员会理解，本发明不限于这里所述的特定实施例，对本领域技术人员来说能够进行各种明显的变化、重新调整和替代而不会脱离本发明的保护范围。因此，虽然通过以上实施例对本发明进行了较为详细的说明，但是本发明不仅仅限于以上实施例，在不脱离本发明构思的情况下，还可以包括更多其他等效实施例，而本发明的范围由所附的权利要求范围决定。

Claims (14)

1.一种业务数据处理系统，其特征在于，包括：

数据仓库集市数据层，用于按照预设频率将各业务数据源的全量数据同步到数据仓库数据集市，并对所述全量数据进行处理，得到业务宽表全量数据；

增量数据层，用于与所述各业务数据源对接，获取各业务数据源的实时增量数据，得到业务宽表增量数据；

业务处理层，用于对所述业务宽表全量数据进行校验，并将经过校验的业务宽表全量数据与所述业务宽表增量数据进行数据融合得到目标业务宽表数据。

2.根据权利要求1所述的系统，其特征在于，所述数据仓库集市数据层具体用于：

以天为单位，每天将当前数据同步时刻之前的所述各业务数据源的全量数据同步到所述数据仓库数据集市并记录数据同步的时间戳；

按照当前业务方的业务模型将所述全量数据进行整合得到当日业务宽表全量数据；

将所述当日业务宽表全量数据以及所述时间戳推送到所述当前业务方的业务数据库。

3.根据权利要求2所述的系统，其特征在于，所述业务处理层对所述业务宽表全量数据进行校验，包括：

确定所述各业务数据源的全量数据是否发生变化；

若是，则根据变化后的全量数据更新所述当日业务宽表全量数据。

4.根据权利要求2所述的系统，其特征在于，所述业务处理层进行数据融合时，通过调用Job任务在预设时间，将所述当日业务宽表全量数据和所述时间戳后的增量数据进行去重合并得到当日目标业务宽表数据。

5.根据权利要求1所述的系统，其特征在于，所述增量数据层通过消息队列方式对接所述各业务数据源。

6.根据权利要求1-5中任一所述的系统，其特征在于，所述业务处理层在进行数据融合前还用于对所述业务宽表增量数据进行数据校验和过滤。

7.根据权利要求6所述的系统，其特征在于，所述业务处理层将所述业务宽表增量数据存储到MySQL数据库中，并使用分布式锁以保证所述各业务数据源增量数据的事务一致性。

8.根据权利要求4所述的系统，其特征在于，所述系统还包括：业务存储层，用于将所述当日目标业务宽表数据存储到所述业务数据库中，并将所述当日目标业务宽表数据之前的目标业务宽表数据归档到ClickHouse数据库中进行分区存储。

9.一种业务数据处理方法，应用于业务数据处理系统，其特征在于，包括：

从数据仓库数据集市中获取当日业务宽表全量数据，其中，所述数据仓库数据集市包括每日更新的各业务数据源的全量数据，所述当日业务宽表全量数据是在所述数据仓库数据集市中对所述各业务数据源的全量数据进行处理得到的；

从所述各业务数据源实时获取增量数据，得到业务宽表增量数据；

将所述当日业务宽表全量数据与业务宽表增量数据进行数据融合得到当日目标业务宽表数据。

10.根据权利要求9所述的方法，其特征在于，所述在所述数据仓库数据集市中对所述各业务数据源的全量数据进行处理，包括：

每天将当前数据同步时刻之前的所述各业务数据源的全量数据同步到所述数据仓库数据集市并记录数据同步的时间戳；

按照当前业务方的业务模型将所述全量数据进行整合得到所述当日业务宽表全量数据。

11.根据权利要求9所述的方法，其特征在于，所述方法还包括：

将所述当日目标业务宽表数据存储到MySQL数据库中，并将所述当日目标业务宽表数据之前的目标业务宽表数据归档到ClickHouse数据库中进行分区存储。

12.根据权利要求9所述的方法，其特征在于，所述方法还包括：

所述业务宽表增量数据存储到MySQL数据库中，并使用分布式锁以保证所述各业务数据源增量数据的事务一致性。

13.一种服务器，其特征在于，所述服务器包括：

一个或多个处理器；

存储器，用于存储一个或多个程序；

当所述一个或多个程序被所述一个或多个处理器执行，使得所述一个或多个处理器实现如权利要求9-12中任一所述的业务数据处理方法。

14.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，该程序被处理器执行时实现如权利要求9-12中任一所述的业务数据处理方法。

Images