CN106909598A - 一种保障计算数据一致性的处理方法、装置及系统 - Google Patents

Abstract

本申请提供一种保障计算数据一致性的处理方法、装置及系统。所述方法包括：读取离线数据库中的离线数据，根据所述离线数据的存储统计时间确定所述离线数据同步延迟的延迟时间；从预先设置的实时流计算结果数据库中读取当前统计时间的实时数据，并读取出与所述延迟时间相对应的实时数据作为业务计算的补偿数据；基于所述离线数据、实时数据和补偿数据执行业务计算。利用本申请各个实施例，可以实现解决因数据同步时间的不确定和延迟导致数据的不一致问题，保证推荐排序分计算准确性，降低业务计算的性能损耗，提高计算效率。

Description

一种保障计算数据一致性的处理方法、装置及系统

技术领域

本申请属于数据库数据处理技术领域，尤其涉及一种保障计算数据一致性的处理方法、装置及系统。

背景技术

在目前的许多业务系统中，如商品推荐、精华帖推荐等，许多业务的统计、计算等常常需要使用离线存储的历史数据和当前实时数据相结合来计算输出结果，以保障统计、计算结果的准确性。

例如在商品推荐系统中，可以根据用户商品浏览的历史记录和当前浏览的商品，向用户精确推荐用户可能需要/正在寻找的商品。在商品推荐系统中，存储的商品浏览次数特征数据通常既有第t-1天的历史浏览次数hpv，也有实时统计的当日t实时浏览次特征数据rpv。目前在根据浏览次数进行统计计算时只是简单的将这两个特征数据简单的加权计算a*hpv(t-1)+b*rpv。同样的，在例如社区高质量帖子推荐系统中，在计算帖子的质量分时需要用到用户对帖子的互动行为作为帖子质量分的计算因子，具体的通常可以包括历史互动次数和实时互动次数(可以按天为同步时间单位)。

在如上述使用历史离线数据和实时数据的商品或帖子推荐系统中，在计算推荐结果的数据处理时需要将历史离线数据和实时数据进行同步合并，如将实时数据存入到历史离线数据库中，由业务系统调用读取历史离线数据库中的次数数据进行计算处理。但在实际的数据存储应用时，当天t生成的实时数据需要转化为当天t的历史离线数据同步存储到数据库中，但由于延时或网络故障以及其他数据处理需求等，并不能保障每天生成的数据在设定时刻内都能进行同步存储。假如设置将当天生成的历史数据在每日零点开始同步，由于故障原因导致历史数据延迟同步一天。那么在紧接着的第二天的商品或帖子推荐计算时，计算的值就变成a*hpv(t-2)+b*rpv，中间就会缺失了第t-1天的统计数据。目前来说，历史数据延迟同步多长时间，通常就会有多长时间的统计数据缺失。

在如上述使用历史离线数据和实时数据的帖子推荐系统中，由于帖子的更新频率较快，尤其是帖子最近几日的互动行为对帖子质量分的计算影响较大，如果计算第t天的统计结果时中间缺少了例如第t-1天的统计数据，那么显然会严重影响帖子最终质量分计算的准确性。同样的如用户商品推荐、热点关键词搜索等这些需要将历史离线数据和实时数据同步后结合统计计算输出结果的系统中，因数据同步时间的延迟或不确定等，常常会导致计算处理的数据不一致，缺少延迟同步的数据，不能保证计算结果的准确性，甚至使得无法正常完成数据计算。

发明内容

本申请目的在于提供一种保障计算数据一致性的处理方法、装置及系统，可以让历史离线数据与实时流计算的结果数据能够实现无缝的结合，不会因数据同步时间的不确定和延迟导致数据的不一致，保证业务计算结果的准确性，降低业务计算的性能损耗，提高计算效率。

本申请提供的一种保障计算数据一致性的处理方法、装置及系统是这样实现的：

一种保障计算数据一致性的处理方法，所述方法包括：

读取离线数据库中的离线数据，根据所述离线数据的存储统计时间确定所述离线数据同步延迟的延迟时间；

从预先设置的实时流计算结果数据库中读取当前统计时间的实时数据，并读取出与所述延迟时间相对应的实时数据作为业务计算的补偿数据；

基于所述离线数据、实时数据和补偿数据执行业务计算。

一种保障计算数据一致性的处理装置，所述装置包括：

延迟判断模块，用于读取离线数据库中的离线数据，根据所述离线数据的存储统计时间确定所述离线数据同步延迟的延迟时间；

数据补偿模块，用于从预先设置的实时流计算结果数据库中读取当前统计时间的实时数据，并读取出与所述延迟时间相对应的实时数据作为业务计算的补偿数据；

业务计算模块，用于基于所述离线数据、实时数据和补偿数据执行业务计算。

一种业务计算系统，所述系统包括：

离线数据库，用于存储同步得到的离线数据；

实时数据库，用于存储采用实时流计算方式得到的实时数据；

处理单元，用于读取离线数据库中的离线数据，根据所述离线数据的存储统计时间确定所述离线数据同步延迟的延迟时间；还用于从预先设置的实时流计算结果数据库中读取当前统计时间的实时数据，以及与所述延迟时间相对应的实时数据；还用于基于读取的离线数据和实时数据，按照判断出的融合计算方式进行业务计算。

本申请提供的一种保障计算数据一致性的处理方法、装置及系统，提供了一套基于实时数据多天分区备份数据与离线的历史数据进行融合的方式，解决由于离线数据延迟同步导致的数据不一致问题。在业务数据获取存储时，可以通过实时流计算平台计算出业务实时的最终的新增数据，然后将流计算的结果数据分区存储一段时间(如N天)。在业务计算时，可以通过离线数据库中存储的数据的存储统计时间来判断离线数据是否延迟。如果延迟，则获取相应的延迟天数的实时数据进行补充。这样，就会将实时数据融合到存在延迟而缺少数据的离线数据中，保障业务数据计算的完整性、一致性，提高业务计算结果的准确性。并且，本申请中存储的实时数据是通过流计算得到的最终可直接参与业务计算的结果数据，将业务计算中需要调用到的离线数据库中的数据提前计算、合并，将合并结果保存下来，以空间换时间，降低业务计算时的性能损耗(如大量并发访问离线数据库)，提高业务系统计算性能和处理效率。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请中记载的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本申请提供的一种保障计算数据一致性的处理方法一种实施例的方法流程图；

图2是本申请提供的一种流式计算并存储实时数据的应用场景实施示意图；

图3是本申请中具体的一种离线数据及实时数据生成、融合的流程示意图；

图4是本申请一种应用场景中数据生成、类型判断、融合计算的业务计算流程示意图；

图5是本申请提供的一种保障计算数据一致性的处理装置的一种实施例模块结构示意图；

图6是本申请提供的业务计算模块的一种实施例模块结构示意图；

图7是本申请提供的类型判断模块的一种实施例模块结构示意图；

图8是本申请提供的融合计算模块的一种实施例模块结构示意图；

图9是本申请提供的一种业务计算系统一种实施例构架结构示意图。

具体实施方式

为了使本技术领域的人员更好地理解本申请中的技术方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

图1是本申请所述一种保障计算数据一致性的处理方法一种实施例的方法流程图。虽然本申请提供了如下述实施例或附图所示的方法操作步骤或装置结构，但基于常规或者无需创造性的劳动在所述方法或装置中可以包括更多或者更少的操作步骤或模块单元。在逻辑性上不存在必要因果关系的步骤或结构中，这些步骤的执行顺序或装置的模块结构不限于本申请实施例或附图所示的执行顺序或模块结构。所述的方法或模块结构的在实际中的装置或终端产品应用时，可以按照实施例或者附图所示的方法或模块结构进行顺序执行或者并行执行(例如并行处理器或者多线程处理的环境、甚至包括分布式处理的实施环境)。

本申请的一个实施例以社区帖子质量评分的应用场景对本申请方案进行详细说明。在目前的推荐系统中，质量评分计算使用离线服务器存储的离线特征数据与实时特征数据时都没有考虑到两类数据的无缝结果，只是将两类特征数据做独立的特征数据读取使用。如果t-1天的历史数据延迟一天同步，则帖子质量分计算的值就变成a*hpv(t-2)+b*rpv。本申请解决的问题之一包括数据同步时间的不确定和延迟导致数据的不一致(或不完整)问题。具体的如图1所述，本申请提供的一种保障计算数据一致性的处理方法的一种实施例可以包括：

S1：读取离线数据库中的离线数据，根据所述离线数据的存储统计时间确定所述离线数据同步延迟的延迟时间。

在业务计算时可以先读取业务系统中存储在离线数据库中的离线数据。所述的离线数据具体的在不同的应用场景下可以对应不同的数据类型、结构等。例如在本实施例社区帖子质量评分的业务计算中，可以设置一个或者多个用于存储计算帖子质量评分需要的相关数据的离线数据表。

具体的，在本实施例计算社区帖子质量评分的应用场景中，可以设置以天为统计单位，帖子质量分计算数学模型如下：

令当日统计时刻为t，昨日统计时刻为t-1，以此类推；

历史累计到t-1日点赞数为h_pop_cnt(t-1)；

历史累计到t-1日回复数h_reply_cnt(t-1)；

帖子发帖时间距离当日的天数为d；

时间衰减系数为c，点赞权重为a0，回复权重为a1，大V用户基础分b；

当日实时新增质量分c_pop_cnt(t)；

当日实时新增回复数c_reply_cnt(t)；

帖子历史累计质量分为：h(t-1)＝(h_pop_cnt(t-1)*a0+h_reply_cnt(t-1)*a1)*c^d+b；

帖子的当日实时新增质量分为：c(t)＝(c_pop_cnt(t)*a0+c_reply_cnt(t)*a1)*c^d+b

帖子的最终质量分为：Q(t)＝h(t-1)+c(t)。

根据本实施例帖子质量评分的应用场景特征，可以在所述离线数据库中设置包括如下结构的离线数据表：

离线数据表A结构：

离线数据表B结构：

user_id 表示为用户ID，

user_role 表示为用户角色。

另外，本申请还改进设计了存储实时数据的实时流计算结果数据库的表结构，作用之一是采用流计算的方式融合实时数据，将原本实时数据存储到同步到离线数据库后仍需调用其他数据表信息才能完成最终业务计算的至少两次数据批量访问，采用流计算方式将原本多批次数据提前计算合成，将合并的计算结果存储下来，保持在实时流计算结果数据库中，达到使用空间换取时间，避免后期大量高并发数据访问，提供计算性能。具体的，根据本实施例帖子质量评分的应用场景特征，可以在所述实时流计算结果数据库中设置包括如下结构的离线数据表：

实时数据表C结构：

实时数据表D结构：

当然，实际的离线数据库或者实时流计算结果数据库中数据表结果在不同的应用场景中可以根据实际需求进行设计，上述的离线数据表或实时数据表中也可以包括其他与帖子质量评分的相关字段数据。

本实施例中，可以从离线数据库中读取帖子质量评分计算所需的离线数据。然后可以根据所述离线数据在所述数据库中存储记录的统计时间确定所述离线数据库是否完成了最新的同步，是否存在同步延迟。如离线数据表A中stat_date字段记录了这份包括帖子ID、帖子质量分、排名等数据记录在离线数据表A中的统计时间。本实施例中离线数据表中可以存储数据的统计时间这个字段，用来判定离线数据是哪天产出的，可以用来确定离线数据同步是否存储延迟。假如当前统计时间标记为cur_date，离线数据统计时间为stat_data。如果cur_date-stat_date＝1，则可以表示离线数据同步没有延迟，或延迟时间为0。如果cur_date-stat_date！＝1，则可以表示离线数据的同步存在延迟，具体的计入cur_date-stat_date＝2，则可以表示离线数据库中的离线数据同步延迟了一天的数据，cur_date-stat_date＝3，则表示延迟了两天的数据。上述的1可以表示为一个统计周期，如一天或一个小时、一周等。

因此，本实施例中可以根据所述离线素具的存储统计时间确定所述离线数据同步延迟的延迟时间。当然，在一些实施例的实施方式中，如果当前统计时间减去存储统计时间后的延迟时间在设置的统计周期内，如没有到同步时间，则可以认为此时离线数据不存在延迟，延时时间为0。如上述帖子质量评分应用场景中，加入设置每日天0点才将当天实时数据同步到离线数据库中，那么cur_date-stat_date的延迟时间在一天内，可以计为延迟时间为0天。但本申请并不排除在其他的实施例中，所述的延迟时间以小于统计周期的时间单位进行计算，帖子质量评分数据为每日一次同步更新到离线数据库中，而在某次帖子质量分计算时得到的延迟时间为12小时，此时的延迟时间12小时仍计为有效的延迟时间，可以用于后续使用实时数据作为补偿。

本实施例中，可以读取离线数据库中需要进行业务计算的离线数据，然后可以根据所述离线数据的存储统计时间确定所述离线数据同步延迟的延迟时间。按照预先设置的延迟计算规则，如果没有延迟或延迟时间小于同步周期则所述延迟时间为0。

S2：从预先设置的实时流计算结果数据库中读取当前统计时间的实时数据，并读取出与所述延迟时间相对应的实时数据作为业务计算的补偿数据。

在本实施例业务计算时需要离线数据与实时数据两类数据，上述后期离线数据并确定出延迟时间后，则可以进一步的读取预先设置的实施流计算结果数据库中的当前统计时间的实时数据。以及，根据计算得到的延迟时间相应的从所述实时流计算结果数据库中读取出延迟时间的实时数据，将该实时数据作为离线数据库中缺失的离线数据的补偿数据。具体的，例如本实时流帖子质量分计算应用场景中，对于延迟的离线数据将采用实时数据表D中的实时数据进行弥补。假如确定出的离线数据库中的离线数据延迟时间为一天，则将从实时流计算结果数据库中读取t-1天的实时数据以及当天t的实时数据。如果有延迟时间为两天，则相应的读取第t-2天、第t-1天以及当天t的实时数据。上述读取的实时数据中，将因同步延迟读取的第t-1天或第t-2天实时数据作为业务计算的补偿数据。

本申请中所述预先设置的实时流计算结果数据库，其作用之一是改进计算性能，采用流计算融合模式将多次数据批量访问提前计算得出最终合并访问结果。如本实施例应用场景中，实时数据表D是离线数据表B通过流计算融合模式与实时数据表C融合而成。离线数据表B主要用于判定用户是否大V。在计算帖子质量分时，需要根据用户角色的不同，增加不同的分数。传统的做法是先获取一批帖子的用户列表，批量访问类似的离线数据表B，从而获得用户角色信息，这种做法会比较损耗性能。因为帖子的数量会很多，有些热点社区产生的帖子数据可以达到成百上千万级别，此时每次推荐帖子时都需要进行这么大量的访问，显然这样访问耗时较长，业务计算系统响应性能将会受到很大的挑战。本申请则通过空间换时间的方法来提高计算性能问题，例如将离线数据表B和离线数据表C提前融合，那么计算帖子质量分时，原本发生要每次请求要计算许多帖子用户的用户角色，要分别访问离线数据库和实时数据库，只要访问两个中的其中一个数据表D就好可以了，可以有效提高业务计算性能，提高处理效率。而实时数据存储时流计算的融合方式可以根据场景和数据处理需求进行设置。本申请提供一种流计算融合的实时数据处理、存储方式，具体的，本申请所述一种保障计算数据一致性的处理方法的另一种实施例中，所述实时流计算结果数据库被设置成存储采用下述方式得到数据：

S201：读取业务源数据库的业务统计数据，获取所述业务的变更数据；

S202：根据设置在所述变更数据中静态属性字段访问相应的数据单元，根据访问结果对对所述变更数据进行流式计算，得到实时的流式计算结果数据；

S203：存储所述实时的流式计算结果数据。

图2是本申请提供的一种流式计算并存储实时数据的应用场景实施示意图。具体的实施过程中可以采用实时流计算平台计算帖子实时新增数据，然后将实时新增数据写入到在线的实时数据库中。如图2所示，本实施例中采取了在生成实时数据表C的流计算过程中获取用户角色信息的方式，提前将用户角色的信息存储下来，融合生成实时数据表D，在计算帖子质量分时，在获取帖子实时新增数据时，一并获取了用户角色数据，空间换时间，提高了计算性能。

一般的，常规业务计算使用的实时数据库与离线数据库可以为同一数据库，如离线数据库为专门设置的存储统计出的业务数据的大型数据库，而实时数据库可以为所述大型数据库中开辟出来的一块临时存储区域，可以用于存储当天(或多天)的实时数据。在当天实时数据同步到离线数据库中后即清除，再存储t+1天的实时数据。本申请的提供的一种保障计算数据一致性的处理方法的另一种实施例中，采用数据分区备份的融合方式，将实时数据与离线数据进行分区多天备份，通过统计时间来进行离线数据和实时数据的无缝融合，防止离线数据延迟导致的数据不一致。所述离线数据库与所述实时流计算结果数据库分别被设置成，包括：

S22：所述离线数据库与所述实时流计算结果数据库采用分区存储的方式存储数据，且所述分区存储离线数据库中的指定实时数据表至少存一个数据同步周期的实时数据。

如在帖子质量分计算过程中，需要对帖子的离线历史质量分和实时质量分进行融合计算。但离线历史质量分从离线计算环境同步到在线数据库的时间是无法保证在每天的同一时间同步的，会相差几小时，甚至一两天。这就导致离线历史质量分与实时质量分的融合计算不能无缝结合，会出现偏差。本实施例实施方案中可以对离线历史质量分与实时质量分多天分区备份的数据融合方式来解决此问题。具体的可以对离线历史质量分即离线数据表A和实时质量分即实时数据表D分区存储N天的数据。本实施例中所述的分区存储可以表示离线数据与实时数据分别存储在逻辑上不同的数据库中。

本申请实施例中，可以从预先设置的实时流计算结果数据库中读取当前统计时间的实时数据，并读取出与所述延迟时间相对应的实时数据作为业务计算的补偿数据。

S3：基于所述离线数据、实时数据和补偿数据执行业务计算。

获取业务计算的实时数据与离线数据，并根据是否存在离线数据同步延迟以及延迟时间获取得到离线数据的补偿数据，则可以将实时数据与离线数据进行无缝融合，保障业务计算的数据的一致性。图3是本申请中具体的一种离线数据及实时数据生成、融合的流程示意图。如图3所示，具体到帖子质量分计算过程中，通过实时本申请实施方案可以解决的离线用户角色数据与帖子实时新增数据的融合，及离线帖子历史热度值与帖子的实时新增热度值的融合，实现保证数据无缝结合，数据一致性，保障质量分计算的准确性。

需要说明的是，在一些实施例中，如果判定出来的结果为延迟时间为0，则此时获取的补充数据可以空，即，虽然本实施例步骤中提到基于包括补偿数据执行业务计算，但在延迟时间为0的情况下，所述补偿数据可以为空。

本申请实施例提供实时数据与离线数据无缝融合的业务计算方式，可以解决由于离线数据延迟同步导致的数据不一致问题。在获取存储实时数据时，可以通过实时流计算平台计算出业务实时的最终的新增数据，然后将流计算的结果数据分区存储一段时间(如N天)。在业务计算时，可以通过离线数据库中存储的数据的存储统计时间来判断离线数据是否延迟。如果延迟，则获取相应的延迟天数的实时数据进行补充。这样，就会将实时数据融合到存在延迟而缺少数据的离线数据中，保障业务数据计算的完整性、一致性，提高业务计算结果的准确性。并且，本申请中存储的实时数据是通过流计算得到的最终可直接参与业务计算的结果数据，将业务计算中需要调用到的离线数据库中的数据提前计算、合并，将合并结果保存下来，以空间换时间，降低业务计算时的性能损耗(如大量并发访问离线数据库)，提高业务系统计算性能和处理效率。

本申请提供的所示一种保障计算数据一致性的处理方法的另一种实施例中，在具体的业务计算时，还可以根据业务数据存储在离线数据还是实时流计算结果数据库来判断业务数据所属的业务类型，然后不同的业务类型设置有不同的融合计算方式。因此，在基于所述离线数据、实时数据和补偿数据执行业务的融合计算时，所述根据所述离线数据、实时数据和补偿数据执行业务计算可以包括：

S501：判断进行业务计算的业务数据所属的数据类型，采用与所述数据类型对应的数据融合计算方式进行业务计算。

这里可以预先设置业务数据所属的数据类型，所述本实施例中可以根据业务数据所在的数据表进行判断确定。具体的如一种实施例中，所述判断进行业务计算的业务数据所属的数据类型可以包括：

S502：确定需要进行业务计算的业务数据在所述离线数据库和实时流计算结果数据库中的数据表，根据所述业务数据所在的数据表的信息判断出所述业务数据属于的预先划分的数据类型；

所述预先划分的数据类型包括：历史产生且无变更的第一数据类型、当前统计时间实时新增的第二数据类型、历史产生且实时发生变更的第三数据类型。

图4是本申请一种应用场景中数据生成、类型判断、融合计算的业务计算流程示意图。如图4所示，对帖子业务数据类型划分判定中，不同帖子类型的对离线数据与实时数据的无缝融合计算方式不同，这里将帖子分为三类：A--历史产生但实时无变化的帖子、B--实时新增的帖子、C--历史产生且实时发生变化的帖子。如果帖子只存在于上述离线数据表A中，则该帖子为A类帖子；如果帖子只存在于实时数据表D中，则为B类帖子；如果帖子同时存在于离线数据表A和实时数据表D中，则为C类帖子。

这样，确定业务数据的数据类型，然后采用相应的融合计算方式进行业务计算，可以提高计算结果准确性，保障数据一致性。

当然，不同的融合计算方式可以根据业务场景进行实际设计，如上帖子质量评分的实施场景中，如果是A类帖子，则可以直接取离线数据表A的历史质量分；如果是B类帖子，则可以根据实时新增数据按帖子的当日实时新增质量分计算公式计算；相应的，如果是C类帖子，则可以将历史质量分与新增质量分相加而得最终质量分。所述融合计算方式包括：

S5011：当判断业务计算的当前业务数据为第一数据类型时，根据离线数据和补偿数据获取所述当前业务数据的第一计算结果；

S5012：当判断业务计算的当前业务数据为第二数据类型时，根据实时数据获取所述当前业务数据的第二计算结果；

S5013：当判断业务计算的当前业务数据为第三数据类型时，将根据离线数据和补偿数据获取的第一计算结果、根据实时数据获取的第二计算结果合并计算得到当前业务数据的计算结果。

上述实施例所述的方法不限于帖子质量得分计算的应用场景，其他的根据离线数据和实时数据进行业务计算的实施场景同样可以采用本申请实施例方案，使得离线数据与实时数据无缝融合、提高计算性能，保障计算数据的一致性。本申请的实施方式可以通过基于各种平台的实施实现，如ODPS分布式计算平台、storm实时流计算平台等。

基于本申请所述的一种保障计算数据一致性的处理方法，本申请还提供一种数据处理装置，具体的包括可以实现保障计算数据一致性的处理装置。图5是本申请提供的一种保障计算数据一致性的处理装置的一种实施例模块结构示意图，如图5所示，所述装置可以包括：

延迟判断模块101，可以用于读取离线数据库中的离线数据，根据所述离线数据的存储统计时间确定所述离线数据同步延迟的延迟时间；

数据补偿模块102，可以用于从预先设置的实时流计算结果数据库中读取当前统计时间的实时数据，并读取出与所述延迟时间相对应的实时数据作为业务计算的补偿数据；

业务计算模块103，可以用于基于所述离线数据、实时数据和补偿数据执行业务计算。

本申请实施例提供的装置，基于实时数据多天分区备份数据与离线的历史数据进行融合的方式，解决由于离线数据延迟同步导致的数据不一致问题。在业务数据获取存储时，可以通过实时流计算平台计算出业务实时的最终的新增数据，然后将流计算的结果数据分区存储一段时间(如N天)。在业务计算时，可以通过离线数据库中存储的数据的存储统计时间来判断离线数据是否延迟。如果延迟，则获取相应的延迟天数的实时数据进行补充。这样，就会将实时数据融合到存在延迟而缺少数据的离线数据中，保障业务数据计算的完整性、一致性，提高业务计算结果的准确性。并且，本申请中存储的实时数据是通过流计算得到的最终可直接参与业务计算的结果数据，将业务计算中需要调用到的离线数据库中的数据提前计算、合并，将合并结果保存下来，以空间换时间，降低业务计算时的性能损耗(如大量并发访问离线数据库)，提高业务系统计算性能和处理效率。

本申请所述装置的一种实施中，所述实时流计算结果数据库被设置成可以存储采用下述方式得到数据：

读取业务源数据库的业务统计数据，获取所述业务的变更数据；

根据设置在所述变更数据中静态属性字段访问相应的数据单元，根据访问结果对对所述变更数据进行流式计算，得到实时的流式计算结果数据；

存储所述实时的流式计算结果数据。

具体的实施过程中如上述帖子质量分计算的实施例应用场中所述，可以采用实时流计算平台计算帖子实时新增数据，然后将实时新增数据写入到在线的实时数据库中。如图2所示，本实施例中采取了在生成实时数据表C的流计算过程中获取用户角色信息的方式，提前将用户角色的信息存储下来，融合生成实时数据表D，在计算帖子质量分时，在获取帖子实时新增数据时，一并获取了用户角色数据，空间换时间，提高了计算性能。

本申请的提供的一种保障计算数据一致性的处理方法的另一种实施例中，采用数据分区备份的融合方式，将实时数据与离线数据进行分区多天备份，通过统计时间来进行离线数据和实时数据的无缝融合，防止离线数据延迟导致的数据不一致。因此，另一种实施例中，所述离线数据库与所述实时流计算结果数据库分别被设置成，可以包括：

所述离线数据库与所述实时流计算结果数据库采用分区存储的方式存储数据，且所述分区存储离线数据库中的指定实时数据表至少存一个数据同步周期的实时数据。

在具体的业务计算时，还可以根据业务数据存储在离线数据还是实时流计算结果数据库来判断业务数据所属的业务类型，然后不同的业务类型设置有不同的融合计算方式。图6是本申请提供的业务计算模块的一种实施例模块结构示意图，如图6所示，本申请所述装置的另一种实施例中，所述业务计算模块103可以包括：

类型判断模块1031，可以用于判断进行业务计算的业务数据所属的数据类型；

融合计算模块1032，可以用于采用与所数据类型对应的数据融合计算方式进行业务计算。

图7是本申请提供的类型判断模块的一种实施例模块结构示意图，如图7所示，本申请所述装置的另一种实施例中，所述类型判断模块1031可以包括：

类型划分模块311，可以用于预先划分数据类型，包括历史产生且无变更的第一数据类型、当前统计时间实时新增的第二数据类型、历史产生且实时发生变更的第三数据类型；

数据表确认模块312，可以用于确定需要进行业务计算的业务数据在所述离线数据库和实时流计算结果数据库中的数据表；

判断模块313，可以用于根据所述业务数据所在的数据表的信息判断出所述业务数据属于的预先划分的数据类型。

确定业务数据的数据类型，然后采用相应的融合计算方式进行业务计算，可以提高计算结果准确性，保障数据一致性。当然，不同的融合计算方式可以根据业务场景进行实际设计，如上帖子质量评分的实施场景中，如果是A类帖子，则可以直接取离线数据表A的历史质量分；如果是B类帖子，则可以根据实时新增数据按帖子的当日实时新增质量分计算公式计算；相应的，如果是C类帖子，则可以将历史质量分与新增质量分相加而得最终质量分。本申请所述装置的另一种实施例中，所述融合计算模块1032可以包括：

第一融合计算模块321，可以用于当判断业务计算的当前业务数据为第一数据类型时，根据离线数据和补偿数据获取所述当前业务数据的第一计算结果；

第二融合计算模块322，可以用于当判断业务计算的当前业务数据为第二数据类型时，根据实时数据获取所述当前业务数据的第二计算结果；

第三融合计算模块323，可以用于当判断业务计算的当前业务数据为第三数据类型时，将根据离线数据和补偿数据获取的第一计算结果、根据实时数据获取的第二计算结果合并计算得到当前业务数据的计算结果。

图8是本申请提供的融合计算模块的一种实施例模块结构示意图。

上述实施例所述的方法或装置可以用于规则业务推荐系统中，如社区高质量或精彩帖子推荐系统、基于用于历史浏览和当前浏览商品统计次数的商品推荐系统等等，可以保障离线数据同步延迟时系统进行业务计算的数据的一致性，并且采用流计算方式存储实时数据，还可以避免业务计算时的多数据库/表高发并访问，进而提高系统数据处理性能。因此，本申请还提供一种业务计算系统，具体的一种实施例中，参照前述方法和/或装置所述，所述系统可以包括：

离线数据库，用于存储同步得到的离线数据；

实时数据库，用于存储采用实时流计算方式得到的实时数据；

处理单元，用于读取离线数据库中的离线数据，根据所述离线数据的存储统计时间确定所述离线数据同步延迟的延迟时间；还用于从预先设置的实时流计算结果数据库中读取当前统计时间的实时数据，以及与所述延迟时间相对应的实时数据；还用于基于读取的离线数据和实时数据，按照判断出的融合计算方式进行业务计算。

图9是本申请提供的一种业务计算系一种实施例构架结构示意图。如图9所述的系统，不会因数据同步时间的不确定和延迟导致业务计算的数据不一致，保证业务计算结果的准确性，降低业务系统的计算性能损耗，提高系统计算效率。

尽管本申请内容中提到数据库中离线或实时数据表的结构、不同的融合计算判断条件及计算方式、分区存储、数据读取、分布式/流计算平台等的数据生成、构造、存储、处理、信息交互/判断方式等的描述，但是，本申请并不局限于必须是数据库数据存储规则、信息交互/判断、平台标准流计算或实施例所描述的情况等，某些行业标准或者使用自定义方式或实施例描述的实施基础上略加修改后的实施方案也可以实现上述实施例相同、等同或相近、或变形后可预料的实施效果。应用这些修改或变形后的数据获取、存储、判断、处理方式等获取的实施例，仍然可以属于本申请的可选实施方案范围之内。

虽然本申请提供了如实施例或流程图所述的方法操作步骤，但基于常规或者无创造性的手段可以包括更多或者更少的操作步骤。实施例中列举的步骤顺序仅仅为众多步骤执行顺序中的一种方式，不代表唯一的执行顺序。在实际中的装置或客户端产品执行时，可以按照实施例或者附图所示的方法顺序执行或者并行执行(例如并行处理器或者多线程处理的环境，甚至为分布式数据处理环境)。术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、产品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、产品或者设备所固有的要素。在没有更多限制的情况下，并不排除在包括所述要素的过程、方法、产品或者设备中还存在另外的相同或等同要素。

上述实施例阐明的单元、装置或模块等，具体可以由计算机芯片或实体实现，或者由具有某种功能的产品来实现。为了描述的方便，描述以上装置时以功能分为各种模块分别描述。当然，在实施本申请时可以把各模块的功能在同一个或多个软件和/或硬件中实现，也可以将实现同一功能的模块由多个子模块或子单元的组合实现等。

本领域技术人员也知道，除了以纯计算机可读程序代码方式实现控制器以外，完全可以通过将方法步骤进行逻辑编程来使得控制器以逻辑门、开关、专用集成电路、可编程逻辑控制器和嵌入微控制器等的形式来实现相同功能。因此这种控制器可以被认为是一种硬件部件，而对其内部包括的用于实现各种功能的装置也可以视为硬件部件内的结构。或者甚至，可以将用于实现各种功能的装置视为既可以是实现方法的软件模块又可以是硬件部件内的结构。

本申请可以在由计算机执行的计算机可执行指令的一般上下文中描述，例如程序模块。一般地，程序模块包括执行特定任务或实现特定抽象数据类型的例程、程序、对象、组件、数据结构、类等等。也可以在分布式计算环境中实践本申请，在这些分布式计算环境中，由通过通信网络而被连接的远程处理设备来执行任务。在分布式计算环境中，程序模块可以位于包括存储设备在内的本地和远程计算机存储介质中。

通过以上的实施方式的描述可知，本领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件平台的方式来实现。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，移动终端，服务器，或者网络设备等)执行本申请各个实施例或者实施例的某些部分所述的方法。

本说明书中的各个实施例采用递进的方式描述，各个实施例之间相同或相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。本申请可用于众多通用或专用的计算机系统环境或配置中。例如：个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器系统、基于微处理器的系统、置顶盒、可编程的电子设备、网络PC、小型计算机、大型计算机、包括以上任何系统或设备的分布式计算环境等等。

虽然通过实施例描绘了本申请，本领域普通技术人员知道，本申请有许多变形和变化而不脱离本申请的精神，希望所附的权利要求包括这些变形和变化而不脱离本申请的精神。

Claims (13)

1.一种保障计算数据一致性的处理方法，其特征在于，所述方法包括：

读取离线数据库中的离线数据，根据所述离线数据的存储统计时间确定所述离线数据同步延迟的延迟时间；

从预先设置的实时流计算结果数据库中读取当前统计时间的实时数据，并读取出与所述延迟时间相对应的实时数据作为业务计算的补偿数据；

基于所述离线数据、实时数据和补偿数据执行业务计算。

2.如权利要求1所述的一种保障计算数据一致性的处理方法，其特征在于，所述实时流计算结果数据库被设置成存储采用下述方式得到数据：

读取业务源数据库的业务统计数据，获取所述业务的变更数据；

根据设置在所述变更数据中静态属性字段访问相应的数据单元，根据访问结果对对所述变更数据进行流式计算，得到实时的流式计算结果数据；

存储所述实时的流式计算结果数据。

3.如权利要求1所述的一种保障计算数据一致性的处理方法，其特征在于，所述离线数据库与所述实时流计算结果数据库分别被设置成，包括：

所述离线数据库与所述实时流计算结果数据库采用分区存储的方式存储数据，且所述实时流计算结果数据库中的指定实时数据表至少存一个数据同步周期的实时数据。

4.如权利要求1至3中任意一项所述的一种保障计算数据一致性的处理方法，其特征在于，所述根据所述离线数据、实时数据和补偿数据执行业务计算，包括：

判断进行业务计算的业务数据所属的数据类型，采用与所数据类型对应的数据融合计算方式进行业务计算。

5.如权利要求4所述的一种保障计算数据一致性的处理方法，其特征在于，所述判断进行业务计算的业务数据所属的数据类型，包括：

确定需要进行业务计算的业务数据在所述离线数据库和实时流计算结果数据库中的数据表，根据所述业务数据所在的数据表的信息判断出所述业务数据属于的预先划分的数据类型；

所述预先划分的数据类型包括：历史产生且无变更的第一数据类型、当前统计时间实时新增的第二数据类型、历史产生且实时发生变更的第三数据类型。

6.如权利要求5所述的一种保障计算数据一致性的处理方法，其特征在于，所述融合计算方式包括：

当判断业务计算的当前业务数据为第一数据类型时，根据离线数据和补偿数据获取所述当前业务数据的第一计算结果；

当判断业务计算的当前业务数据为第二数据类型时，根据实时数据获取所述当前业务数据的第二计算结果；

当判断业务计算的当前业务数据为第三数据类型时，将根据离线数据和补偿数据获取的第一计算结果、根据实时数据获取的第二计算结果合并计算得到当前业务数据的计算结果。

7.一种保障计算数据一致性的处理装置，其特征在于，所述装置包括：

延迟判断模块，用于读取离线数据库中的离线数据，根据所述离线数据的存储统计时间确定所述离线数据同步延迟的延迟时间；

数据补偿模块，用于从预先设置的实时流计算结果数据库中读取当前统计时间的实时数据，并读取出与所述延迟时间相对应的实时数据作为业务计算的补偿数据；

业务计算模块，用于基于所述离线数据、实时数据和补偿数据执行业务计算。

8.如权利要求7所述的一种保障计算数据一致性的处理装置，其特征在于，所述实时流计算结果数据库被设置成存储采用下述方式得到数据：

读取业务源数据库的业务统计数据，获取所述业务的变更数据；

根据设置在所述变更数据中静态属性字段访问相应的数据单元，根据访问结果对对所述变更数据进行流式计算，得到实时的流式计算结果数据；

存储所述实时的流式计算结果数据。

9.如权利要求7所述的一种保障计算数据一致性的处理装置，其特征在于，所述离线数据库与所述实时流计算结果数据库分别被设置成，包括：

所述离线数据库与所述实时流计算结果数据库采用分区存储的方式存储数据，且所述分区存储离线数据库中的指定实时数据表至少存一个数据同步周期的实时数据。

10.如权利要求7至9中任意一项所述的一种保障计算数据一致性的处理装置，其特征在于，所述业务计算模块包括：

类型判断模块，用于判断进行业务计算的业务数据所属的数据类型；

融合计算模块，用于采用与所数据类型对应的数据融合计算方式进行业务计算。

11.如权利要求10所述的一种保障计算数据一致性的处理装置，其特征在于，所述类型判断模块包括：

类型划分模块，用于预先划分数据类型，包括历史产生且无变更的第一数据类型、当前统计时间实时新增的第二数据类型、历史产生且实时发生变更的第三数据类型；

数据表确认模块，用于确定需要进行业务计算的业务数据在所述离线数据库和实时流计算结果数据库中的数据表；

判断模块，用于根据所述业务数据所在的数据表的信息判断出所述业务数据属于的预先划分的数据类型。

12.如权利要求11所述的一种保障计算数据一致性的处理装置，其特征在于，所述融合计算模块包括：

第一融合计算模块，用于当判断业务计算的当前业务数据为第一数据类型时，根据离线数据和补偿数据获取所述当前业务数据的第一计算结果；

第二融合计算模块，用于当判断业务计算的当前业务数据为第二数据类型时，根据实时数据获取所述当前业务数据的第二计算结果；

第三融合计算模块，用于当判断业务计算的当前业务数据为第三数据类型时，将根据离线数据和补偿数据获取的第一计算结果、根据实时数据获取的第二计算结果合并计算得到当前业务数据的计算结果。

13.一种业务计算系统，其特征在于，所述系统包括：

离线数据库，用于存储同步得到的离线数据；

实时数据库，用于存储采用实时流计算方式得到的实时数据；

处理单元，用于读取离线数据库中的离线数据，根据所述离线数据的存储统计时间确定所述离线数据同步延迟的延迟时间；还用于从预先设置的实时流计算结果数据库中读取当前统计时间的实时数据，以及与所述延迟时间相对应的实时数据；还用于基于读取的离线数据和实时数据，按照判断出的融合计算方式进行业务计算。