CN117520314A - 数据处理方法、装置、电子设备和可读介质 - Google Patents

Abstract

本申请实施例提供了数据处理方法、装置、电子设备和可读介质。所述方法的实施例包括：获取当前统计周期内产生的增量数据，按照事务类型对所述增量数据进行划分，得到分别与不同事务类型对应的增量数据表；获取活跃数据表，并将所述活跃数据表与各增量数据表进行数据关联，所述活跃数据表中包括截至所述当前统计周期的起始时刻未被归档的活跃数据；基于关联后的数据和已归档的静态数据，生成目标数据模型。该实施方式降低了数据处理过程中的数据存储压力和计算压力，同时提高数据处理效率。

Description

数据处理方法、装置、电子设备和可读介质

技术领域

本申请实施例涉及计算机技术领域，特别是涉及一种数据处理方法、装置、电子设备和可读介质。

背景技术

在数字化时代背景下，各类型的服务平台时时刻刻都在产生数据。每日所产生的数据不仅种类繁杂，数据量也极其庞大。随着时间的变化，数据存储压力和使用难度越来越大。

现有技术中，为便于数据使用，通常定期对全量数据进行关联，以得到数据模型。例如，若需要统计电商平台中近三年的交易订单的退款率等信息，则需要将近三年的交易订单数据、物流数据、签收数据、退款数据等进行关联，由于需要关联的数据量巨大，因此数据的储存压力和处理压力较大且数据处理效率较低。

发明内容

本申请实施例提出了数据处理方法、装置、电子设备和可读介质，以降低数据存储压力和处理压力，同时提高数据处理效率。

第一方面，本申请实施例提供了一种数据处理方法，包括：获取当前统计周期内产生的增量数据，按照事务类型对所述增量数据进行划分，得到分别与不同事务类型对应的增量数据表；获取活跃数据表，并将所述活跃数据表与各增量数据表进行数据关联，所述活跃数据表中包括截至所述当前统计周期的起始时刻未被归档的活跃数据；基于关联后的数据和已归档的静态数据，生成目标数据模型。

第二方面，本申请实施例提供了一种数据处理装置，包括：获取单元，用于获取当前统计周期内产生的增量数据，按照事务类型对所述增量数据进行划分，得到分别与不同事务类型对应的增量数据表；关联单元，用于获取活跃数据表，并将所述活跃数据表与各增量数据表进行数据关联，所述活跃数据表中包括截至所述当前统计周期的起始时刻未被归档的活跃数据；生成单元，用于基于关联后的数据和已归档的静态数据，生成目标数据模型。

第三方面，本申请实施例还提供了一种电子设备，包括：处理器；以及存储器，其上存储有可执行代码，当所述可执行代码被执行时，使得所述处理器执行如本申请实施例中一个或多个所述的数据处理方法。

第四方面，本申请实施例还提供了一个或多个机器可读介质，其上存储有可执行代码，当所述可执行代码被执行时，使得处理器执行如本申请实施例中一个或多个所述的数据处理方法。

与现有技术相比，本申请实施例包括以下优点：

在本申请实施例中，首先获取当前统计周期内产生的增量数据，并按照事务类型对该增量数据进行划分，以得到分别与不同事务类型对应的增量数据表，之后获取包含截至当前统计周期的起始时刻未被归档的活跃数据的活跃数据表，并将活跃数据表与所各增量数据表进行数据关联，最后基于关联后的数据和已归档的静态数据，生成目标数据模型。由此，数据关联操作按照统计周期执行，在数据关联过程中，使用当前统计周期内产生的增量数据进行数据关联，由于增量数据的数据量远远小于全量数据，因此大大降低了处理的数据量。此外，通过归档的方式将数据划分成了活跃数据和静态数据，仅针对未被归档的活跃数据进行关联，无需对已归档的静态数据进行查询、遍历等数据处理操作，进一步降低了处理的数据量。从而，可显著降低数据处理过程中的数据存储压力和计算压力，同时提高数据处理效率。

附图说明

通过阅读参照以下附图所作的对非限制性实施例所作的详细描述，本申请的其它特征、目的和优点将会变得更明显：

图1A是本申请的数据处理方法的一个应用场景的示意图；

图1B是本申请的数据处理方法中事务发生顺序的示意图；

图1C是本申请的数据处理方法中主数据表与增量数据表的关联过程示意图；

图1D是本申请的数据处理方法中多级归档过程的示意图；

图1E是本申请的数据处理方法所适用的存储系统的架构图；

图2是本申请的数据处理方法的一个实施例的流程图；

图3是本申请的数据处理方法的又一个实施例的流程图；

图4是本申请的数据处理装置的一个实施例的结构示意图。

图5是本申请一实施例提供的装置的结构示意图。

具体实施方式

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

需要指出的是，本申请中所有获取信号、信息或数据的动作都是在遵照所在地国家相应的数据保护法规政策的前提下，并获得由相应装置所有者给予授权的情况下进行的。

需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本申请。

本申请实施例可应用于各领域的数据处理场景，例如，电商领域的数据处理场景、物流领域的数据处理场景等。在这些场景中，每日可产生海量数据，且所产生的数据种类繁杂。例如，电商平台或物流平台每日均可产生海量交易数据、发货数据、物流数据、签收数据、退款数据、评价数据、投诉数据等。

通常，各类型的数据相互独立存储于不同的数据表，若需要使用这些数据，需要将各个数据表中的数据进行关联，以构建数据模型。例如，若需统计过去三年的交易下单的支付转化率、退款率、发货及时率、妥投率、签收效率、好评率等，通常需要将各个数据表中近三年的全量数据进行关联。在海量数据的情况下，对于平台而言处理压力将难以应对。即使采用半全量数据(只刷新近一段时间，比如半年内的数据)的关联方式，运算量也非常巨大。

本申请实施例可以按照统计周期，周期性地执行数据关联操作。在数据关联过程中，使用当前统计周期内产生的增量数据进行数据关联，增量数据的数据量远远小于全量数据，因此可大大降低处理的数据量。此外，通过归档的方式将数据划分成了活跃数据和静态数据，仅针对未被归档的活跃数据进行关联，无需对已归档的静态数据执行查询、遍历等数据处理操作，可进一步降低了处理的数据量。从而，可显著降低数据处理过程中的数据存储压力和计算压力，同时提高数据处理效率。

请参见图1A。图1A为本申请的数据处理方法的一个应用场景的示意图，此场景可以是电商场景或物流场景。服务端可维护有电商平台或者物流平台等服务平台。客户端可以是物流平台客户端、电商平台客户端等。用户可通过客户端进行下单、签收、评价、投诉等操作。服务端可在与客户端交互的过程中存储多种数据。例如，可以包括但不限于以下至少一项数据：交易订单数据、物流数据、签收数据、退款数据、评价数据、投诉数据等。

在服务端所存储的数据中，一些数据会随着时间迁移可发生变化。例如，未签收或者已签收未满30天的订单的相关数据，随着时间推移可能会新增退款数据、评价数据、投诉数据等。由此，可以将随着时间迁移可发生变化的数据作为活跃数据，使其参与数据关联操作。相反，一些数据随着时间迁移不会发生变化。例如，已签收满30天的订单的相关数据，由于交易已关闭，因此随着时间推移不会产生与其相关的数据。若使其参与数据关联过程，则关联过程中对其进行的遍历、查询等操作，将会造成不必要的存储资源浪费以及计算资源浪费。鉴于此，可将此类数据归档为静态数据，避免其参与数据关联过程，从而降低存储压力和计算压力。实践中，可设定活跃数据与静态数据的划分条件(例如，订单已签收满30天)，通过该划分条案进行活跃数据和静态数据的划分以及静态数据的归档。例如，若某一订单已签收满30天，则该订单对应的数据可被归为静态数据，并进行归档。需要说明的是，活跃数据与静态数据的划分条件不限于上述示例，还可以根据需要进行其他设定，例如，还可设定为：订单产生评价数据、订单产生退款数据、订单产生投诉数据、订单已签收满30天中的一项或多项。

数据处理方法的执行主体可以是服务端。服务端可将每一自然日(例如，每日0:00:00至23:59:59)作为一个统计周期，将已结束的最新统计周期(即前一日0:00:00至23:59:59)作为当前统计周期，在指定的统计时间(例如，每日10:00)，对当前统计周期(即前一日0:00:00至23:59:59)所存储的增量数据、以及截至当前统计周期的起始时刻(例如，前一日0:00:00)的活跃数据执行一次数据关联操作。具体可以参见如下过程：

服务端首先获取当前统计周期(即前一日0:00:00至23:59:59)所存储的增量数据。增量是指在一个观测时间下，把当前统计时间周期数据存储在一起，不同观测时间周期内数据物理上互相区隔，不重叠交叉。全量是指在一个观测时间下，把全周期数据存储在一起，不做物理上区隔，不同观测时间下会重复存储。在大数据场景下，增量数据的数据量远远小于全量数据，且不存在数据重复计算的问题。将增量数据进行关联，相较于全量数据关联，可提高数据关联效率，降低数据处理压力。

在得到当前统计周期(即前一日0:00:00至23:59:59)所存储的增量数据后，服务端可以按照事务类型对上述增量数据进行划分，得到分别与不同事务类型对应的增量数据表。例如，上述增量数据可涉及交易事务、发货事务、物流事务、签收事务、评价事务、投诉事务和退款事务等多种事务类型，则将增量数据进行划分后，可得到交易事务对应的增量数据表A、发货事务对应的增量数据表B、物流事务对应的增量数据表C、签收事务对应的增量数据表D、评价事务对应的增量数据表E、投诉事务对应的增量数据表F和退款事务对应的增量数据表G等多个增量数据表。

需要说明的是，事务划分方式不限于上述示例，还可以根据需要采用其他划分方式。例如，可将与交易相关的事务(例如，下单、支付等)统称为交易事务，将与时效相关的事务(例如，发货、物流、派送等)统称为时效事务，将服务相关的事务(例如，退款、评价等)统称为服务事务，将考核规则相关的事务(例如，考核规则变更、订单剔除等)统称为考核规则事务，将其余事务统称为其他事务等，此处不作具体限定。

在得到不同事务类型对应的增量数据表后，服务端可以获取活跃数据表。该活跃数据表中可包括截至当前统计周期的起始时刻(即前一日0:00:00)未被归档(即未被归档为静态数据)的活跃数据。该活跃数据表可在对前一统计周期的增量数据处理后得到，在本次数据处理过程中可对其进行更新。需要说明的是，获取活跃数据表的操作也可以在增量数据的获取操作之前执行，此处对获取先后顺序不作限定。

在生成增量数据表以及获取到活跃数据表后，服务端可将活跃数据表与各增量数据表进行数据关联。例如，活跃数据表中包括某订单的订单数据、支付数据和发货数据，增量数据表中包括该订单的物流数据和签收数据，则可以通过数据库指令，将该订单的订单数据、发货数据、物流数据和签收数据进行关联。由此，在查询该订单的数据时，可获得该订单相关的全部数据。

在进行数据关联后，服务端可基于关联后的数据和已归档的静态数据，生成目标数据模型。例如，可将关联后的数据和已归档的静态数据进行合并，将合并后所得到的数据表作为目标数据模型。通过查询目标数据模型，能够以精准的方式识别每个订单的生命周期，并跟踪至该订单生命周期的结束，从而方便快捷地使用每个订单生命周期中的各项数据。

通过周期性地(例如，每日10:00)执行数据关联操作，在每次数据关联过程中，使用当前统计周期内产生的增量数据进行数据与未被归档的活跃数据进行关联，进而基于关联结果和已归档的静态数据生成目标数据模型，可大大降低数据关联过程中的数据量和数据处理的复杂度，减少重复存储与计算，显著降低了数据处理过程中的数据存储压力和计算压力，同时提高了数据处理效率。此外，若需使用长时段(例如，3年)的数据，则可以通过周期性地执行数据关联操作，实现长时段内的增量数据的关联，其结果与全量数据的关联结果等价。在降低数据存储压力和计算压力的同时，还可使目标数据模型实时保持最新。

在一些可选的实施例中，为便于进一步方便技术人员获取所需数据，目标数据模型还可包括其他形式的数据表。例如，累计快照事实表。上述累计快照事实表具体可包括但不限于支付视角下的累积快照事实表(即支付时间回刷表)、支付视角下的累积快照事实表(即签收时间回刷表)等。通过存储不同形式的数据表，可便于技术人员进行数据查询和使用。实践中，在数据仓库技术中，实际发生过的事件叫做事实，数据表分为事务粒度事实表、周期快照事实表、累计快照粒度事实表。其中，事务粒度事实表也可称为原子事实表，可记录发生在某一个时间节点的事件的信息，例如，在某时刻点击收藏、下单、付款、评价、退货等事件。周期快照事实表可记录发生在某一个连续时间区间的事件的信息，例如，在前一个月的店铺收藏数、下单数、付款数、好评数等。累计快照事实表中可记录一个完整的生命周期内多个关键里程碑事件的信息，例如，某订单从创建到完结期间各事件的信息、目标时段(例如，三年)内的支付信息或者交易信息等。

在一些可选的实施例中，在生成目标数据模型之后，还可基于目标数据模型，执行一种或多种数据处理，得到所需的一种或多种处理结果。例如，可以确定目标时段(例如，一年、三年等)内的交易订单的以下至少一项：支付转化率、退款率、发货及时率、物流妥投率、签收效率、好评率、投诉率。由于目标数据模型能够以精准的方式识别每个订单的生命周期，并记录有每个订单生命周期中的各项数据，因此，基于目标数据模型，能够方便快捷地使用已存储的数据。

在一些可选的实施例中，为便于快速获取到可用的增量数据表，服务端在生成不同事务类型对应的增量数据表时，可依次经过快照捕获、快照比对、事实拆解、碎片化数据汇总四个步骤。具体地，第一步，获取当前统计周期的起始时刻的第一全量数据和当前统计周期的结束时刻的第二全量数据。上述第一全量数据和第二全量数据可作为不同的快照。第二步，基于第一全量数据和第二全量数据，确定当前统计周期内产生的增量数据。此处，可通过快照比对，确定出第二全量数据相较于第一全量数据的增量数据，具体可包括新增数据、变更数据和移除数据。第三步，按照事务粒度，将增量数据拆解为多个事务粒度事实表。每个事务粒度事实表可视为一个碎片化数据。第四步，按照事务类型，将所拆解的事务粒度事实表进行汇总，得到分别与不同事务类型对应的增量数据表。由此，可将碎片化数据进行汇总，得到可用的数据。通过上述步骤，可快速获取到可用的增量数据表。

在一些可选的实施例中，为进一步避免数据重复运算，可以对活跃数据和增量数据分级进行关联。可以理解的是，活跃数据可随着时间的变化逐渐转化为静态数据。通常，在某些事务发生后，活跃数据的变化频次会大幅降低。鉴于此，可预先设定活跃数据分级条件，以确定关键事务(也可称为卡点)，基于该关键事务的发生与否，将活跃数据进一步划分为一级活跃数据和二级活跃数据。作为示例，可将签收事务作为关键事务。若某一订单尚未签收，则其数据变化频次通常较高，易产生新的数据，如发货数据、物流数据、签收数据等，故可将该订单的数据视为一级活跃数据。若某一订单已签收但不满30天，则其可能会发生数据变化，例如退款、评价、投诉等，也可能不会发生数据变化，故可将该订单的数据视为二级活跃数据。由于活跃数据被划分为一级活跃数据和二级活跃数据，因此，所获取的活跃数据表也可包括一级活跃数据表和二级活跃数据表，不同级的活跃数据可存储于不同的活跃数据表中。

相应地，增量数据表也可以基于上述活跃数据分级条件进行分级。在将活跃数据表与各增量数据表进行数据关联时，可针对不同级的活跃数据表，关联所需级别的增量数据表。具体地，可按照如下步骤执行：

第一步，基于预设的活跃数据分级条件，确定关键事务。上述活跃数据分级条件可根据需要预先设置。例如，可设定为订单已签收，若某一活跃数据对应的订单未满足订单已签收这一条件，则可作为一级活跃数据；若某一活跃数据对应的订单满足订单已签收这一条件，则可作为二级活跃条件。相应的，关键事务可以是签收事务。

第二步，基于各事务类型对应的事务与关键事务的发生先后顺序，将所生成的增量数据表划分为一级增量数据数据表和二级增量数据表。具体地，可以将发生于关键事务之前的事务对应的增量数据表以及关键事务对应的增量数据表，确定为一级增量数据表。将发生于关键事务之后的事务对应的增量数据表，确定为二级增量数据表。

作为示例，参见图1B所示的事务发生顺序的示意图。事务发生顺序依次为：下单、支付、发货、派送、签收、评价、投诉和退款。若关键事务是签收事务，则可以将发生于签收事务之前的事务(包括：下单、支付、发货、派送和签收)对应的增量数据表以及签收事务对应的增量数据表，确定为一级增量数据表。将发生于签收事务之后的事务(包括：评价、投诉和退款)对应的增量数据表，确定为二级增量数据表。需要说明的是，1B所示出的事务仅为示例，还可以根据需要设定其他事务，或者替换为其他名称。例如，下单和支付可统称为交易，发货和派送之间还可包括物流相关的一项或多项事务，上述物流相关的事务和上述派送事务可统称为物流事务等，此处不作具体限定。

第三步，将一级活跃数据表与各增量数据表(包括各一级数据表和各二级数据表)进行数据关联，并将二级活跃数据表与二级增量数据表进行数据关联。可以理解的是，一级活跃数据表存储的数据为未签收订单的相关数据，该订单还可继续产生物流数据、签收数据、评价数据、投诉数据和退款数据中的一项或多项增量数据。上述增量数据对应的增量数据表既包含一级增量数据表，也包含二级增量数据表，因此，一级活跃数据表可与上述各增量数据表(包括一级增量数据表和二级增量数据表)进行数据关联。二级活跃数据表存储的数据为已签收订单的相关数据，该订单还可继续产生评价数据、投诉数据和退款数据中的一项或多项增量数据。上述增量数据对应的增量数据表均为二级增量数据表，因此，二级活跃数据表可与二级增量数据表进行数据关联。

通过对活跃数据和增量数据进一步进行分级，能够使活跃程度不同的活跃数据关联准确的增量数据表，使数据关联更具针对性，避免了无用的数据处理过程(例如，将下单数据、发货数据、签收数据与已签收订单的相关数据进行关联时的遍历、查询过程)，进一步降低了所需处理的数据量以及数据处理压力，同时进一步提高了数据处理效率。

在一些可选的实施例中，增量数据中可包括新增主数据。服务端在将一级活跃数据表与各增量数据表进行数据关联时，可首先将新增主数据合并至一级活跃数据表，得到主数据表。新增主数据可以用于为一级活跃数据表增加记录，使得一级活跃数据表的行数增加。作为示例，事务类型可包括交易事务，交易事务对应的增量数据表中可以包括新增交易订单数据，可以将新增交易订单数据作为新增主数据。实践中，新增交易订单数据可以包括新增交易订单的订单号，主数据表中也包含订单号这一字段。可通过对活跃数据表和交易事务对应的增量数据表执行Union命令，实现新增交易订单数据与一级活跃数据表中数据的合并。其中，Union命令是一种数据库命令，使用Union命令，可实现两个记录集的合并，得到一个新的记录集。也即，根据字段共同属性将表与表之间数据进行上下拼接。通过上述操作，可将活跃数据表与新增交易订单数据相融合，得到待进行数据关联的主数据表。在得到主数据表后，可将主数据表与各增量数据表进行数据关联。例如，可通过对主数据表和各增量数据表执行Join命令，实现主数据表与各增量数据表进行数据关联。实践中，Join命令是一种数据库命令，使用Join命令，可实现两表中条件相同的部分记录产生一个记录集。也即，根据共同字段，将数据左右拼接。通过上述操作，可实现主数据表与各增量数据表中的数据的关联。

进一步地，由于各增量数据表与主数据表的主键的不同，且不同增量数据表与主数据表的关联键不同(例如，支付事务对应的增量数据表用订单号关联，物流事务对应的增量数据表用运单号关联、签收事务对应的增量数据表用交易单号关联)，导致需要执行多次数据关联操作，关联过程较为繁琐。鉴于此，在一些可选的实施例中，在将主数据表与各增量数据表进行关联时，可首先基于主数据表的主键，对各增量数据表进行字段扩充，得到各增量数据表对应的缓存数据表。各缓存数据表的字段中包括主键。而后，可以基于主键，将主数据表与各缓存数据表进行数据关联。

作为示例，若新增主数据包括新增交易订单数据，则主键可以包括交易订单的订单号。参见图1C主数据表与增量数据表的关联过程示意图。主数据表(参见标号101所示)的主键为order_id(例如，订单号)。增量数据表(参见标号102所以)的主键为key1。可首先对增量数据表进行字段扩充，使其包含order_id字段，得到缓存数据表(参见标号103所示)。而后，对缓存数据表与主数据表执行Join命令，得到关联后的数据表(参见标号104所示)。对于其他增量数据表，可执行相同的字段扩充操作。从而，可以通过一次关联操作，将多个增量数据表对应的缓存数据表与主数据表进行数据关联，减少了数据关联操作的次数，从而提高了数据关联效率。需要说明的是，为提高数据关联效率，可以并行将主数据表与各缓存数据表进行数据关联。

为进一步提高并行度，提高数据关联效率，在一些可选的实施例中，还可以在将主数据表与各缓存数据表进行数据关联时，首先基于主键(例如，订单号)的值中的目标位字符(例如，末位数字)，将主数据表划分为多个第一子表，并将各缓存数据表中的数据划分为多个第二子表。例如，按照订单号的末位数字0～9，将主数据表划分为10个第一子表，将每个缓存数据表10个第二子表。每个子表中的订单号的末位数据相同。之后，将对应相同目标位字符的第一子表和第二子表作为待关联子表组，并行地对各待关联子表组中的子表进行数据关联。由此，可分配多线程并行进行数据关联，进一步提高数据关联效率。

在一些可选的实施例中，在进行数据关联后，还可以采用多级归档策略进行数据归档，并基于各级活跃数据和各级归档数据，生成目标数据模型。最终所生成的目标数据模型包括目标数据表。此处，归档条件可包括一级归档条件和二级归档条件。可将活跃数据分级条件(例如，订单已签收)作为一级归档条件，将静态数据与活跃数据的划分条件(例如，订单已签收满30天)作为二级归档条件。

具体地，在将一级活跃数据表与各增量数据表进行数据关联后，可以将关联后满足一级归档条件(例如，订单已签收)的数据作为一级归档数据，将一级归档数据汇总，得到当前统计周期对应的一级归档数据表。例如，若关联后的数据指示某订单在当前统计周期内被用户签收，则该订单对应的数据可被归档为一级归档数据，存入一级归档数据表，该订单对应的数据可从一级活跃数据表中删除。此外，在将一级活跃数据表与各增量数据表进行数据关联后，可将合并后不满足一级归档数据的数据保留至一级活跃数据表，得到更新后的一级活跃数据表。例如，若关联后的数据指示某订单未被签收，则该订单对应的数据可被保留至一级活跃数据表。

在一些实现方式中，二级活跃数据表中可以包括连续多个历史统计周期(例如，连续30天)对应的历史一级归档数据表中的数据，上述连续多个历史统计周期中的末尾统计周期的下一统计周期为当前统计周期的上一统计周期(例如，前天0:00:00-23:59:59)。具体地，在对每个统计周期内产生的增量数据进行关联后，所得到的一级归档数据表可保留一个统计周期(例如，一天)，在对下一统计周期内产生的增量数据进行关联的过程中，被作为二级活跃数据，归入二级活跃数据表。如此，可避免一级归档数据表和二级活跃数据表存在重复数据。由于所获取的二级活跃数据表中的数据为截至当前统计周期的起始时刻(例如，昨日0:00:00)的二级活跃数据，因此该二级活跃数据表中尚未包含上一统计周期(例如，前天0:00:00-23:59:59)对应的一级归档数据。鉴于此，在将二级活跃数据表与二级增量数据表进行数据关联时，可首先将上一统计周期对应的历史一级归档数据表中的数据合并至二级活跃数据表中，以便将上一统计周期新增订单的订单号进行合并。而后，可将合并数据后的二级活跃数据表与二级增量数据表进行数据关联。

在将二级活跃数据表与各二级增量数据表进行数据关联后，可以将关联后满足预设的二级归档条件的数据作为二级归档数据，归入预先生成的用于存储已归档的静态数据的二级归档数据表。将关联后不满足二级归档条件的数据保留至二级活跃数据表，得到更新后的二级活跃数据表。例如，若关联后的数据指示某订单签收已满30天，则该订单对应的数据可被归档为二级归档数据，并可从二级活跃数据表中删除该订单对应的数据。若关联后的数据指示某订单已签收仍未满30天，则该订单对应的数据可被保留至二级活跃数据表。需要说明的是，当前统计周期对应的一级归档数据，可在对下一统计周期内产生的增量数据进行关联的环节，作为二级活跃数，归入二级活跃数据表，由此，避免当前所得到的一级归档数据与当前的二级活跃数据中存在重复数据。

在进行各级活跃数据表、归档数据表的更新或生成后，可以基于更新后的一级活跃数据表、更新后的二级活跃数据表、所得到的一级归档数据表以及二级归档数据表，生成目标数据表。作为示例，可以从二级归档数据表中提取目标时段(例如，近三年)对应的二级归档数据。而后，将更新后的一级活跃数据表中的数据、一级归档数据表中的数据、更新后的二级活跃数据表中的数据以及所提取的二级归档数据进行汇总，生成目标数据表。

参见图1D所示的多级归档过程的示意图。可将各增量数据表中的增量数据作为原始资源数据。原始资源数据首先与截至当前统计周期的起始时刻的一级活跃数据进行数据关联。关联后不满足一级归档条件的数据保留至一级活跃数据表。关联后满足一级归档条件的数据被归档为一级归档数据，得到一级归档数据表。接着，上一统计周期对应的一级归档数据表中的一级归档数据被汇总至二级活跃数据表，该二级活跃数据表与原始资源数据中的二级增量数据表进行数据关联。关联后不满足二级归档条件的数据被保留至二级活跃数据表。关联后满足二级归档条件的数据被归档至二级活跃数据表。最终，基于各级归档数据以及活跃数据，可得到目标数据模型。

需要说明的是，多级归档策略还可以根据需要进行三级归档、四级归档的设定，例如，可将签收满半年的订单涉及的数据归档为三级数据，将签收满3年的订单对应的数据归档为四级数据等，此处不作具体限定。通过多级归档，可针对性地分级合并不同事务类型的数据，减少计算资源以及存储资源的浪费。

请参见图1E，其示出了本申请的数据处理方法所适用的存储系统的架构图。如图1E所示，上述存储系统可以包括原始资源片段区、归一化资源片段区、增量归档区和目标数据区。

原始资源片段区可用于存储原始数据资源。例如，可存储不同事务类型对应的增量数据表：“T日增量数据表A”、“T日增量数据表B”、“T日增量数据表C”、“T日增量数据表D”、“T日增量数据表E”、“T日增量数据表F”和“T日增量数据表G”等多个增量数据表。其中，“T日增量数据表A”中可包括增量主数据，以及其他数据。作为示例，在电商场景或者物流场景中，上述增量数据可涉及交易事务、发货事务、物流事务、签收事务、评价事务、投诉事务和退款事务等多种事务类型，则上述“T日增量数据表A”、“T日增量数据表B”、“T日增量数据表C”、“T日增量数据表D”、“T日增量数据表E”、“T日增量数据表F”和“T日增量数据表G”可分别对应交易事务、发货事务、物流事务、签收事务、评价事务、投诉事务和退款事务。“T日增量数据表A”中的新增主数据可以包括新增交易订单数据，具体可包括新增订单的订单号、交易时间、商品信息等，“T日增量数据表A”中的其他数据可以包括历史交易订单的变更数据、支付数据等。需要说明的是，在不同的场景中，或者，针对相同场景的不同需求，原始资源片段区中所存储的原始数据资源可以不同，事务类型也可以不同，此处不作具体限定。例如，在物流场景中，上述“新增主数据”可以为“新增投诉工单数据”等；在维修场景中，上述“新增主数据”可以为“新增维修工单数据”等，此处不再一一赘述。

增量归档区可用于存储数据关联结果，即各级活跃数据表以及各级归档数据表。在对当前统计周期(可记为T日0:00:00至23:59:59)的增量数据关联之前，增量归档区可存储有截至当前统计周期的起始时刻(即T日0:00:00)的一级活跃数据表和二级活跃数据表。由于当前统计周期与前一统计周期为连续周期，因此截至当前统计周期的起始时刻(即T日0:00:00)的一级活跃数据表，也即上一统计周期的结束时刻(也即T-1日23:59:59)的一级活跃数据表。鉴于此，可将截至当前统计周期的起始时刻的一级活跃数据表记为“截至T-1日一级活跃数据表”。同理，截至当前统计周期的起始时刻(即T日0:00:00)的二级活跃数据表，也即上一统计周期的结束时刻(也即T-1日23:59:59)的二级活跃数据表。鉴于此，可将截至当前统计周期的起始时刻的一级活跃数据表记为“截至T-1日二级活跃数据表”。

归一化资源片段区中可用于存储主数据表，以及依次与“T日增量数据表A”、“T日增量数据表B”、“T日增量数据表C”、“T日增量数据表D”、“T日增量数据表E”、“T日增量数据表F”和“T日增量数据表G”对应的“T日缓存数据表A’”、“T日缓存数据表B’”、“T日缓存数据表C’”、“T日缓存数据表D’”、“T日缓存数据表E’”、“T日缓存数据表F’”和“T日缓存数据表G’”。其中，主数据表可通过将“T日增量数据表A”中的新增主数据合并至“截至T-1日一级活跃数据表”后得到。各缓存数据表可通过对相应的增量数据表进行字段扩展后得到，因此视为更新后的增量数据表。其中，“T日缓存数据表A’”、“T日缓存数据表B’”、“T日缓存数据表C’”、“T日缓存数据表D’”对应的事务可发生于关键事务(例如，签收事务)之前或为关键事务，可作为一级增量数据表。“T日缓存数据表E’”、“T日缓存数据表F’”和“T日缓存数据表G’”对应的事务可发生于关键事务之后，可作为二级增量数据表。

对在当前统计周期的增量数据关联的过程中，可采用分级归档方式，首先将主数据表与各增量数据表对应的缓存数据表(即“T日缓存数据表A’”、“T日缓存数据表B’”、“T日缓存数据表C’”、“T日缓存数据表D’”、“T日缓存数据表E’”、“T日缓存数据表F’”和“T日缓存数据表G’”)进行数据关联。将关联后满足第一归档条件的数据(例如，已签收的订单对应的数据)归为第一归档的数据，得到“T日第一归档数据表”。将关联后不满足第一归档条件的数据保留至第一活跃数据表，得到“截至T日一级活跃数据表”。之后，将上一统计周期得到的“T-1日第一归档数据表”中的数据合并至上一统计周期得到的“截至T-1日第二活跃数据表”，并将合并后的“截至T-1日第二活跃数据表”与“T日缓存数据表E’”、“T日缓存数据表F’”和“T日缓存数据表G’”进行数据关联，将关联后满足第二归档条件的数据(例如，已签收满30日的订单对应的数据)归为第二归档数据，得到“截至T日第二归档的数据表”。将关联后不满足第二归档条件的数据保留至第二活跃数据表，得到“截至T日第二活跃数据表”。在对当前统计周期的增量数据关联结束后，增量归档区可存储最新的数据关联结果，包括“截至T日一级活跃数据表”、“T日一级归档数据表”、“截至T日二级活跃数据表”、“截至T日二级归档数据表”。

目标数据区可用于存储目标数据模型。目标数据模型可包括至少一种形式的目标数据表。目标数据表可通过将“截至T日一级活跃数据”、“T日一级归档数据表”、“截至T日二级活跃数据表”以及“截至T日二级归档数据表”中的部分数据进行汇总得到。例如，若需得到近半年订单的全量数据，可以从“截至T日二级归档数据表”中提取近半年的订单对应的二级归档数据，并分别从“截至T日一级活跃数据”、“T日一级归档数据表”以及“截至T日二级活跃数据表”中提取全部数据，通过汇总，得到近半年订单的全量数据。

通过周期性地(例如，每日10:00)执行数据关联操作，在每次数据关联过程中，使用当前统计周期内产生的增量数据进行数据与未被归档的活跃数据进行关联，进而基于关联结果和已归档的静态数据生成目标数据模型，可大大降低数据关联过程中的数据量和数据处理的复杂度，减少重复存储与计算，显著降低了数据处理过程中的数据存储压力和计算压力，同时提高了数据处理效率。此外，若需使用长时段(例如，180天)的数据，则可以通过周期性地执行数据关联操作，实现长时段内的增量数据的关联，其结果与全量数据的关联结果等价。在降低数据存储压力和计算压力的同时，还可使目标数据模型实时保持最新。

继续参考图2，其示出了本申请的数据处理方法的一个实施例的流程图。该数据处理方法可应用于服务端。该数据处理方法的流程，可以包括以下步骤：

步骤201，获取当前统计周期内产生的增量数据，按照事务类型对上述增量数据进行划分，得到分别与不同事务类型对应的增量数据表。

在本实施例中，数据处理方法可以在每个数据统计周期结束后执行，从而可以周期性地执行。数据统计周期的长度可根据需要进行设定，例如，可将一个自然日设定为一个数据统计周期。数据处理方法的执行主体(例如，服务器)可将当前待进行数据处理的统计周期(例如，前一日)作为当前统计周期，获取当前统计周期内产生的增量数据。在得到增量数据后，可以按照事务类型对增量数据进行划分，得到分别与不同事务类型对应的增量数据表。

作为示例，上述增量数据可涉及交易事务、发货事务、物流事务、签收事务、评价事务、投诉事务和退款事务等多种事务类型，则将增量数据进行划分后，可得到交易事务对应的增量数据表对应的增量数据表、物流事务对应的增量数据表、签收事务对应的增量数据表、评价事务对应的增量数据表、投诉事务对应的增量数据表和退款事务对应的增量数据表等多个增量数据表。

作为又一示例，可将与交易相关的事务(例如，下单、支付等)统称为交易事务，将与时效相关的事务(例如，发货、物流、派送等)统称为时效事务，将服务相关的事务(例如，退款、评价等)统称为服务事务，将考核规则相关的事务(例如，考核规则变更、订单剔除等)统称为考核规则事务。在将增量数据进行划分后，可得到交易事务对应的增量数据表、时效事务对应的增量数据表、服务事务对应的增量数据表、考核规则事务对应的增量数据表以及其他对应的增量数据表。

在一些可选的实现方式中，为便于快速获取到可用的增量数据表，服务端在生成不同事务类型对应的增量数据表时，可依次经过快照捕获、快照比对、事实拆解、碎片化数据汇总四个步骤。具体地，第一步，获取当前统计周期的起始时刻的第一全量数据和当前统计周期的结束时刻的第二全量数据。上述第一全量数据和第二全量数据可作为不同的快照。第二步，基于第一全量数据和第二全量数据，确定当前统计周期内产生的增量数据。此处，可通过快照比对，确定出第二全量数据相较于第一全量数据的增量数据，具体可包括新增数据、变更数据和移除数据。第三步，按照事务粒度，将增量数据拆解为多个事务粒度事实表。每个事务粒度事实表可视为一个碎片化数据。第四步，按照事务类型，将所拆解的事务粒度事实表进行汇总，得到分别与不同事务类型对应的增量数据表。由此，可将碎片化数据进行汇总，得到可用的数据。通过上述步骤，可快速获取到可用的增量数据表。

步骤202，获取活跃数据表，并将上述活跃数据表与各增量数据表进行数据关联。

在本实施例中，截至当前统计周期的起始时刻已存储的数据可被预先划分为活跃数据和静态数据。静态数据可被归档，从而不参数数据关联过程。实践中，可通过预先设定的归档条件(也即活跃数据与静态数据的划分条件)，进行活跃数据和静态数据的划分。

以电商场景或者物流场景为例，可将归档条件设定为订单已签收满30天。不满足该条件的订单涉及的数据，可视为活跃数据。随着时间推移，可能会新增该订单对应的退款数据、评价数据、投诉数据等，由此，该订单涉及的数据可参与数据关联操作。反之，满足该条件的订单涉及的数据，可视为静态数据。满足该条件的订单，由于交易已关闭，因此随着时间推移不会产生与其相关的新增数据，若使其参与数据关联过程，则关联过程中对其进行的遍历、查询等操作，将会造成不必要的存储资源浪费以及计算资源浪费。鉴于此，避免其参与数据关联过程，可降低存储压力和计算压力。

在本实施例中，截至当前统计周期的起始时刻未被归档的活跃数据可被存储至活跃数据表。上述执行主体可以获取活跃数据表，并将上述活跃数据表与各增量数据表进行数据关联。例如，活跃数据表中包括某订单的订单数据、支付数据和发货数据，某个增量数据表中包括该订单的物流数据，另一增量数据表中包括该订单的签收数据，则可以通过数据库指令，将该订单的订单数据、发货数据、物流数据和签收数据进行关联。由此，在查询该订单的数据时，可获得该订单相关的全部数据。

步骤203，基于关联后的数据和已归档的静态数据，生成目标数据模型。

在本实施例中，在进行数据关联后，上述执行主体可基于关联后的数据和已归档的静态数据，生成目标数据模型。例如，可将关联后的数据和已归档的静态数据中的部分数据(例如，近半年的数据、或者近三年的数据等)或全部数据进行合并，将合并后所得到的数据表作为目标数据模型。通过查询目标数据模型，能够以精准的方式识别每个订单的生命周期，并跟踪至该订单生命周期的结束，从而方便快捷地使用每个订单生命周期中的各项数据。

在一些可选的实现方式中，为便于进一步方便技术人员获取所需数据，目标数据模型还可包括其他形式的数据表。例如，累计快照事实表。上述累计快照事实表具体可包括但不限于支付视角下的累积快照事实表(即支付时间回刷表)、支付视角下的累积快照事实表(即签收时间回刷表)等。通过存储不同形式的数据表，可便于技术人员进行数据查询和使用。

在一些可选的实现方式中，在生成目标数据模型之后，还可基于目标数据模型，执行一种或多种数据处理，得到所需的一种或多种处理结果。例如，可以确定目标时段(例如，一年、三年等)内的交易订单的以下至少一项：支付转化率、退款率、发货及时率、物流妥投率、签收效率、好评率、投诉率。由于目标数据模型能够以精准的方式识别每个订单的生命周期，并记录有每个订单生命周期中的各项数据，因此，基于目标数据模型，能够方便快捷地使用已存储的数据。

本实施例各步骤与上述实施例对应步骤描述类似，具体可参见上述实施例的描述。

本申请的上述实施例提供的方法，首先获取当前统计周期内产生的增量数据，并按照事务类型对该增量数据进行划分，以得到分别与不同事务类型对应的增量数据表，之后获取包含截至当前统计周期的起始时刻未被归档的活跃数据的活跃数据表，并将活跃数据表与所各增量数据表进行数据关联，最后基于关联后的数据和已归档的静态数据，生成目标数据模型。由此，数据关联操作按照统计周期执行，在数据关联过程中，使用当前统计周期内产生的增量数据进行数据关联，由于增量数据的数据量远远小于全量数据，因此大大降低了处理的数据量。此外，通过归档的方式将数据划分成了活跃数据和静态数据，仅针对未被归档的活跃数据进行关联，无需对已归档的静态数据执行查询、遍历等数据处理操作，进一步降低了处理的数据量。从而，可显著降低数据处理过程中的数据存储压力和计算压力，同时提高数据处理效率。此外，若需使用长时段(例如，3年)的数据，则可以通过周期性地执行数据关联操作，实现长时段内的增量数据的关联，其结果与全量数据的关联结果等价。在降低数据存储压力和计算压力的同时，还可使目标数据模型实时保持最新。

继续参考图3，示出了本申请的数据处理方法的一个实施例的流程图。该数据处理方法可应用于服务端。该数据处理方法的流程，包括以下步骤：

步骤301，获取当前统计周期内产生的增量数据，按照事务类型对增量数据进行划分，得到分别与不同事务类型对应的增量数据表。

步骤302，获取一级活跃数据表和二级活跃数据表。

在本实施例中，活跃数据可以指未被归档为静态数据的数据。活跃数据可随着时间的变化逐渐转化为静态数据，因此，活跃数据的活跃程度不同。通常，在某些事务发生后，活跃数据的变化频次会大幅降低。鉴于此，可预先设定活跃数据分级条件，以确定关键事务(也可称为卡点)，基于该关键事务的发生与否，将活跃数据进一步划分为一级活跃数据和二级活跃数据。由于活跃数据可包括一级活跃数据和二级活跃数据，因此，所获取的活跃数据表也可包括一级活跃数据表和二级活跃数据表，不同级的活跃数据可存储于不同的活跃数据表中。一级活跃数据表中可包括截至当前统计周期的起始时刻未被归档的一级活跃数据。二级活跃数据表中可包括截至当前统计周期的起始时刻未被归档的二级活跃数据。

以电商场景或物流场景为例，可将签收事务作为关键事务。若某一订单尚未签收，则其数据变化频次通常较高，易产生新的数据，如发货数据、物流数据、签收数据等，故可将该订单的数据视为一级活跃数据，存储于一级活跃数据表。若某一订单已签收但不满30天，则其可能会发生数据变化，例如退款、评价、投诉等，也可能不会发生数据变化，故可将该订单的数据视为二级活跃数据，存储于二级活跃数据表。

步骤303，基于预设的活跃数据分级条件，确定关键事务。

在本实施例中，上述活跃数据分级条件可根据需要预先设置。例如，可设定为订单已签收。若某一活跃数据涉及的订单未满足订单已签收这一条件，则可作为一级活跃数据；若某一活跃数据涉及的订单满足订单已签收这一条件，则可作为二级活跃条件。相应的，关键事务可以是签收事务。

步骤304，基于各事务类型对应的事务与关键事务的发生先后顺序，将所生成的增量数据表划分为一级增量数据数据表和二级增量数据表。

在本实施例中，可以将发生于关键事务之前的事务对应的增量数据表以及关键事务对应的增量数据表，确定为一级增量数据表。将发生于关键事务之后的事务对应的增量数据表，确定为二级增量数据表。以电商场景或者物流场景为例，事务发生顺序依次为：交易事务、发货事务、物流事务、签收事务、评价事务、投诉事务和退款事务。若关键事务是签收事务，则可以将发生于签收事务之前的事务(包括：交易事务、发货事务、物流事务和签收事务)对应的增量数据表以及签收事务对应的增量数据表，确定为一级增量数据表。将发生于签收事务之后的事务(包括：评价事务、投诉事务和退款事务)对应的增量数据表，确定为二级增量数据表。

步骤305，将一级活跃数据表与各增量数据表进行数据关联。

在本实施例中，为避免数据重复运算，可以对活跃数据和增量数据分级进行关联。具体地，可将一级活跃数据表与各增量数据表(包括各一级数据表和各二级数据表)进行数据关联，并将二级活跃数据表与二级增量数据表进行数据关联。

以电商场景或者物流场景为例，一级活跃数据表存储的数据为未签收订单的相关数据，该订单可能发生支付事务、物流事务、签收事务、评价事务、投诉事务和退款事务中的一项或多项。上述可能发生的事务对应的增量数据表既包含一级增量数据表，也包含二级增量数据表，因此，一级活跃数据表可与上述各项事务对应的增量数据表进行数据关联。二级活跃数据表存储的数据为已签收订单的相关数据，该订单可能发生评价事务、投诉事务和退款事务中的一项或多项。上述可能发生的事务对应的增量数据表均为二级增量数据表，因此，二级活跃数据表可与二级增量数据表进行数据关联。

通过对活跃数据和增量数据进一步进行分级，能够使活跃程度不同的活跃数据关联准确的增量数据表，使数据关联更具针对性，避免了无用的数据处理过程(例如，将下单数据、发货数据、签收数据与已签收订单的相关数据进行关联时的遍历、查询过程)，进一步降低了所需处理的数据量以及数据处理压力，同时进一步提高了数据处理效率。

在一些可选的实现方式中，增量数据中可包括新增主数据。服务端在将一级活跃数据表与各增量数据表进行数据关联时，可首先将新增主数据合并至一级活跃数据表，得到主数据表。新增主数据可以用于为一级活跃数据表增加记录，从而增加一级活跃数据表的行数。以电商场景为例，事务类型可包括交易事务，交易事务对应的增量数据表中可以包括新增交易订单数据，可将新增交易订单数据作为新增主数据。实践中，新增交易订单数据可以包括新增交易订单的订单号，主数据表中也包含订单号这一字段。可通过对活跃数据表和交易事务对应的增量数据表执行Union命令，实现新增交易订单数据与一级活跃数据表中数据的合并。而后，可将主数据表与各增量数据表进行数据关联。例如，可通过对主数据表和各增量数据表执行Join命令，实现主数据表与各增量数据表进行数据关联。

进一步地，由于各增量数据表与主数据表的主键的不同，且不同增量数据表与主数据表的关联键不同(例如，支付事务对应的增量数据表用订单号关联，物流事务对应的增量数据表用运单号关联、签收事务对应的增量数据表用交易单号关联)，导致需要执行多次数据关联操作，关联过程较为繁琐。鉴于此，在一些可选的实现方式中，在将主数据表与各增量数据表进行关联时，可首先基于主数据表的主键，对各增量数据表进行字段扩充，得到各增量数据表对应的缓存数据表。各缓存数据表的字段中包括主键。而后，可以基于主键，将主数据表与各缓存数据表进行数据关联。例如，新增主数据可以包括新增交易订单数据，主键可以包括交易订单的订单号。需要说明的是，为提高数据关联效率，可以并行将主数据表与各缓存数据表进行数据关联。

进一步地，为进一步提高数据关联的并行度，在一些可选的实现方式中，还可以在将主数据表与各缓存数据表进行数据关联时，首先基于主键(例如，订单号)的值中的目标位字符(例如，末位数字)，将主数据表划分为多个第一子表，并将各缓存数据表中的数据划分为多个第二子表。例如，按照订单号的末位数字0～9，将主数据表划分为10个第一子表，将每个缓存数据表10个第二子表。每个子表中的订单号的末位数据相同。之后，将对应相同目标位字符的第一子表和第二子表作为待关联子表组，并行地对各待关联子表组中的子表进行数据关联。由此，可分配多线程并行进行数据关联，进一步提高数据关联效率。

步骤306，将关联后满足预设的一级归档条件的数据作为一级归档数据，将一级归档数据汇总，得到当前统计周期对应的一级归档数据表，将合并后不满足一级归档数据的数据保留至一级活跃数据表，得到更新后的一级活跃数据表。

在本实施例中，在进行数据关联后，还可以采用多级归档策略进行数据归档，并基于各级活跃数据和各级归档数据，以便于生成目标数据模型。具体地，在将一级活跃数据表与各增量数据表进行数据关联后，可以将关联后满足一级归档条件(例如，订单已签收)的数据作为一级归档数据，将一级归档数据汇总，得到当前统计周期对应的一级归档数据表。例如，若关联后的数据指示某订单在当前统计周期内被用户签收，则该订单对应的数据可被归档为一级归档数据，存入一级归档数据表，该订单对应的数据可从一级活跃数据表中删除。此外，在将一级活跃数据表与各增量数据表进行数据关联后，可将合并后不满足一级归档数据的数据保留至一级活跃数据表，得到更新后的一级活跃数据表。例如，若关联后的数据指示某订单未被签收，则该订单对应的数据可被保留至一级活跃数据表。

步骤307，将上一统计周期对应的历史一级归档数据表中的数据合并至二级活跃数据表中，将合并数据后的二级活跃数据表与二级增量数据表进行数据关联。

在本实施例中，二级活跃数据表中可以包括连续多个历史统计周期(例如，连续30天)对应的历史一级归档数据表中的数据，上述连续多个历史统计周期中的末尾统计周期的下一统计周期为当前统计周期的上一统计周期(例如，前天)。具体地，在对每个统计周期内产生的增量数据进行关联后，所得到的一级归档数据表可保留一个统计周期(例如，一天)，在对下一统计周期内产生的增量数据进行关联的过程中，被作为二级活跃数据，归入二级活跃数据表。如此，可避免一级归档数据表和二级活跃数据表存在重复数据。由于所获取的二级活跃数据表中的数据为截至当前统计周期的起始时刻(例如，昨天0:00:00)的二级活跃数据，因此该二级活跃数据表中尚未包含上一统计周期(例如，前天0:00:00-23:59:59)对应的一级归档数据。鉴于此，在将二级活跃数据表与二级增量数据表进行数据关联时，可首先将上一统计周期对应的历史一级归档数据表中的数据合并至二级活跃数据表中，以便将上一统计周期新增订单的订单号进行合并。而后，可将合并数据后的二级活跃数据表与二级增量数据表进行数据关联。

步骤308，将关联后满足预设的二级归档条件的数据作为二级归档数据，归入预先生成的用于存储已归档的静态数据的二级归档数据表，将关联后不满足二级归档条件的数据保留至二级活跃数据表，得到更新后的二级活跃数据表。

在本实施例中，在将二级活跃数据表与各二级增量数据表进行数据关联后，可以将关联后满足预设的二级归档条件的数据作为二级归档数据，归入预先生成的用于存储已归档的静态数据的二级归档数据表。将关联后不满足二级归档条件的数据保留至二级活跃数据表，得到更新后的二级活跃数据表。例如，若关联后的数据指示某订单签收已满30天，则该订单对应的数据可被归档为二级归档数据，并可从二级活跃数据表中删除该订单对应的数据。若关联后的数据指示某订单已签收仍未满30天，则该订单对应的数据可被保留至二级活跃数据表。需要说明的是，当前统计周期对应的一级归档数据，可在对下一统计周期内产生的增量数据进行关联的环节，作为二级活跃数，归入二级活跃数据表，由此，避免当前所得到的一级归档数据与当前的二级活跃数据中存在重复数据。

需要说明的是，多级归档策略还可以根据需要进行三级归档、四级归档的设定，例如，可将签收满半年的订单涉及的数据归档为三级数据，将签收满3年的订单对应的数据归档为四级数据等，此处不作具体限定。通过多级归档，可针对性地分级合并不同事务类型的数据，减少计算资源以及存储资源的浪费。

步骤309，基于更新后的一级活跃数据表、一级归档数据表、更新后的二级活跃数据表以及二级归档数据表，生成目标数据表。

在本实施例中，在进行各级活跃数据表、归档数据表的更新或生成后，可以基于更新后的一级活跃数据表、更新后的二级活跃数据表、所得到的一级归档数据表以及二级归档数据表，生成目标数据表。作为示例，可以从二级归档数据表中提取目标时段(例如，近三年)对应的二级归档数据。而后，将更新后的一级活跃数据表中的数据、一级归档数据表中的数据、更新后的二级活跃数据表中的数据以及所提取的二级归档数据进行汇总，生成目标数据表。

在一些可选的实现方式中，为便于进一步方便技术人员获取所需数据，目标数据模型还可包括其他形式的数据表。例如，累计快照事实表。上述累计快照事实表具体可包括但不限于支付视角下的累积快照事实表(即支付时间回刷表)、支付视角下的累积快照事实表(即签收时间回刷表)等。通过存储不同形式的数据表，可便于技术人员进行数据查询和使用。

在一些可选的实现方式中，在生成目标数据模型之后，还可基于目标数据模型，执行一种或多种数据处理，得到所需的一种或多种处理结果。例如，可以确定目标时段(例如，一年、三年等)内的交易订单的以下至少一项：支付转化率、退款率、发货及时率、物流妥投率、签收效率、好评率、投诉率。由于目标数据模型能够以精准的方式识别每个订单的生命周期，并记录有每个订单生命周期中的各项数据，因此，基于目标数据模型，能够方便快捷地使用已存储的数据。

本实施例各步骤与上述实施例对应步骤描述类似，具体可参见上述实施例的描述。

本申请的上述实施例提供的方法，通过多级归档，可针对性地分级合并不同事务类型的数据，避免数据重复运算，减少计算资源以及存储资源的浪费，进一步提高数据处理效率。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请实施例并不受所描述的动作顺序的限制，因为依据本申请实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请实施例所必须的。

进一步参考图4，在上述实施例的基础上，本申请提供了一种数据处理装置的一个实施例，该装置具体可以应用于各种电子设备中。

如图4所示，本实施例的数据处理装置400包括：获取单元401，用于获取当前统计周期内产生的增量数据，按照事务类型对上述增量数据进行划分，得到分别与不同事务类型对应的增量数据表；关联单元402，用于获取活跃数据表，并将上述活跃数据表与各增量数据表进行数据关联，上述活跃数据表中包括截至上述当前统计周期的起始时刻未被归档的活跃数据；生成单元403，用于基于关联后的数据和已归档的静态数据，生成目标数据模型。

在一些可选的实现方式中，上述目标数据模型中包括以下至少一项数据：交易订单数据、发货数据、物流数据、签收数据、退款数据、评价数据、投诉数据；上述装置还包括确定单元，用于基于上述目标数据模型，确定目标时段内的交易订单的以下至少一项：支付转化率、退款率、发货及时率、物流妥投率、签收效率、好评率、投诉率。

在一些可选的实现方式中，上述获取单元401，进一步用于获取上述当前统计周期的起始时刻的第一全量数据和上述当前统计周期的结束时刻的第二全量数据，并基于上述第一全量数据和上述第二全量数据，确定上述当前统计周期内产生的增量数据；按照事务粒度，将上述增量数据拆解为多个事务粒度事实表；按照事务类型，将所拆解的事务粒度事实表进行汇总，得到分别与不同事务类型对应的增量数据表。

在一些可选的实现方式中，上述活跃数据表包括一级活跃数据和二级活跃数据，上述活跃数据表包括一级活跃数据表和二级活跃数据表；上述关联单元402，进一步用于基于预设的活跃数据分级条件，确定关键事务；基于各事务类型对应的事务与上述关键事务的发生先后顺序，将所生成的增量数据表划分为一级增量数据数据表和二级增量数据表；将上述一级活跃数据表与各增量数据表进行数据关联，并将上述二级活跃数据表与上述二级增量数据表进行数据关联。

在一些可选的实现方式中，上述事务类型包括以下至少一项：交易事务、发货事务、物流事务、签收事务、评价事务、投诉事务、退款事务；上述关键事务包括签收事务；上述关联单元402，进一步用于将发生于上述签收事务之前的事务对应的增量数据表以及上述签收事务对应的增量数据表，确定为一级增量数据表；将发生于上述签收事务之后的事务对应的增量数据表，确定为二级增量数据表。

在一些可选的实现方式中，上述增量数据包括新增主数据；上述关联单元402，进一步用于将上述新增主数据合并至上述活跃数据表，得到主数据表；将上述主数据表与各增量数据表进行数据关联。

在一些可选的实现方式中，上述关联单元402，进一步用于基于上述主数据表的主键，对各增量数据表进行字段扩充，得到各增量数据表对应的缓存数据表，各缓存数据表的字段中包括上述主键；基于上述主键，将上述主数据表与各缓存数据表进行数据关联；其中，上述新增主数据包括新增交易订单数据，上述主键包括交易订单的订单号。

在一些可选的实现方式中，上述关联单元402，进一步用于基于上述主键的值中的目标位字符，将上述主数据表划分为多个第一子表，并将各缓存数据表中的数据划分为多个第二子表；将对应相同目标位字符的第一子表和第二子表作为待关联子表组，并行地对各待关联子表组中的子表进行数据关联。

在一些可选的实现方式中，上述方法还包括第一归档单元，用于将关联后满足预设的一级归档条件的数据作为一级归档数据，将上述一级归档数据汇总，得到上述当前统计周期对应的一级归档数据表，将合并后不满足上述一级归档数据的数据保留至上述一级活跃数据表，得到更新后的一级活跃数据表；第二归档单元，用于在上述将上述二级活跃数据表与上述二级增量数据表进行数据关联后，上述方法还包括：将关联后满足预设的二级归档条件的数据作为二级归档数据，归入预先生成的用于存储已归档的静态数据的二级归档数据表，将关联后不满足上述二级归档条件的数据保留至上述二级活跃数据表，得到更新后的二级活跃数据表；上述生成单元403，进一步用于基于上述更新后的一级活跃数据表、上述一级归档数据表、上述更新后的二级活跃数据表以及上述二级归档数据表，生成目标数据表。

在一些可选的实现方式中，上述生成单元403，进一步用于从上述二级归档数据表中提取目标时段对应的二级归档数据；将上述更新后的一级活跃数据表中的数据、上述一级归档数据表中的数据、上述更新后的二级活跃数据表中的数据以及所提取的二级归档数据进行汇总，生成目标数据表。

在一些可选的实现方式中，上述二级活跃数据表中包括连续多个历史统计周期对应的历史一级归档数据表中的数据，上述连续多个历史统计周期中的末尾统计周期的下一统计周期为上述当前统计周期的上一统计周期；上述关联单元402，进一步用于将上述上一统计周期对应的历史一级归档数据表中的数据合并至上述二级活跃数据表中，将合并数据后的二级活跃数据表与上述二级增量数据表进行数据关联。

本申请的上述实施例提供的装置，首先获取当前统计周期内产生的增量数据，并按照事务类型对该增量数据进行划分，以得到分别与不同事务类型对应的增量数据表，之后获取包含截至当前统计周期的起始时刻未被归档的活跃数据的活跃数据表，并将活跃数据表与所各增量数据表进行数据关联，最后基于关联后的数据和已归档的静态数据，生成目标数据模型。由此，数据关联操作按照统计周期执行，在数据关联过程中，使用当前统计周期内产生的增量数据进行数据关联，由于增量数据的数据量远远小于全量数据，因此大大降低了处理的数据量。此外，通过归档的方式将数据划分成了活跃数据和静态数据，仅针对未被归档的活跃数据进行关联，无需对已归档的静态数据执行查询、遍历等数据处理操作，进一步降低了处理的数据量。从而，可显著降低数据处理过程中的数据存储压力和计算压力，同时提高数据处理效率。

本申请实施例还提供了一种非易失性可读存储介质，该存储介质中存储有一个或多个模块(programs)，该一个或多个模块被应用在设备时，可以使得该设备执行本申请实施例中各方法步骤的指令(instructions)。

本申请实施例提供了一个或多个机器可读介质，其上存储有指令，当由一个或多个处理器执行时，使得电子设备执行如上述实施例中一个或多个所述的方法。本申请实施例中，所述电子设备包括终端设备、服务器(集群)等各类型的设备。

本公开的实施例可被实现为使用任意适当的硬件，固件，软件，或及其任意组合进行想要的配置的装置，该装置可包括终端设备、服务器(集群)等电子设备。图5示意性地示出了可被用于实现本申请中所述的各个实施例的示例性装置500。

对于一个实施例，图5示出了示例性装置500，该装置具有一个或多个处理器502、被耦合到(一个或多个)处理器502中的至少一个的控制模块(芯片组)504、被耦合到控制模块504的存储器506、被耦合到控制模块504的非易失性存储器(NVM)/存储设备508、被耦合到控制模块504的一个或多个输入/输出设备510，以及被耦合到控制模块504的网络接口512。

处理器502可包括一个或多个单核或多核处理器，处理器502可包括通用处理器或专用处理器(例如图形处理器、应用处理器、基频处理器等)的任意组合。在一些实施例中，装置500能够作为本申请实施例中所述终端设备、服务器(集群)等设备。

在一些实施例中，装置500可包括具有指令514的一个或多个计算机可读介质(例如，存储器506或NVM/存储设备508)以及与该一个或多个计算机可读介质相合并被配置为执行指令514以实现模块从而执行本公开中所述的动作的一个或多个处理器502。

对于一个实施例，控制模块504可包括任意适当的接口控制器，以向(一个或多个)处理器502中的至少一个和/或与控制模块504通信的任意适当的设备或组件提供任意适当的接口。

控制模块504可包括存储器控制器模块，以向存储器506提供接口。存储器控制器模块可以是硬件模块、软件模块和/或固件模块。

存储器506可被用于例如为装置500加载和存储数据和/或指令514。对于一个实施例，存储器506可包括任意适当的易失性存储器，例如，适当的DRAM。在一些实施例中，存储器506可包括双倍数据速率类型四同步动态随机存取存储器(DDR4SDRAM)。

对于一个实施例，控制模块504可包括一个或多个输入/输出控制器，以向NVM/存储设备508及(一个或多个)输入/输出设备510提供接口。

例如，NVM/存储设备508可被用于存储数据和/或指令514。NVM/存储设备508可包括任意适当的非易失性存储器(例如，闪存)和/或可包括任意适当的(一个或多个)非易失性存储设备(例如，一个或多个硬盘驱动器(HDD)、一个或多个光盘(CD)驱动器和/或一个或多个数字通用光盘(DVD)驱动器)。

NVM/存储设备508可包括在物理上作为装置500被安装在其上的设备的一部分的存储资源，或者其可被该设备访问可不必作为该设备的一部分。例如，NVM/存储设备508可通过网络经由(一个或多个)输入/输出设备510进行访问。

(一个或多个)输入/输出设备510可为装置500提供接口以与任意其他适当的设备通信，输入/输出设备510可以包括通信组件、音频组件、传感器组件等。网络接口512可为装置500提供接口以通过一个或多个网络通信，装置500可根据一个或多个无线网络标准和/或协议中的任意标准和/或协议来与无线网络的一个或多个组件进行无线通信，例如接入基于通信标准的无线网络，如WiFi、2G、3G、4G、5G等，或它们的组合进行无线通信。

对于一个实施例，(一个或多个)处理器502中的至少一个可与控制模块504的一个或多个控制器(例如，存储器控制器模块)的逻辑封装在一起。对于一个实施例，(一个或多个)处理器502中的至少一个可与控制模块504的一个或多个控制器的逻辑封装在一起以形成系统级封装(SiP)。对于一个实施例，(一个或多个)处理器502中的至少一个可与控制模块504的一个或多个控制器的逻辑集成在同一模具上。对于一个实施例，(一个或多个)处理器502中的至少一个可与控制模块504的一个或多个控制器的逻辑集成在同一模具上以形成片上系统(SoC)。

在各个实施例中，装置500可以但不限于是：服务器、台式计算设备或移动计算设备(例如，膝上型计算设备、手持计算设备、平板电脑、上网本等)等终端设备。在各个实施例中，装置500可具有更多或更少的组件和/或不同的架构。例如，在一些实施例中，装置500包括一个或多个摄像机、键盘、液晶显示器(LCD)屏幕(包括触屏显示器)、非易失性存储器端口、多个天线、图形芯片、专用集成电路(ASIC)和扬声器。

其中，装置中可采用主控芯片作为处理器或控制模块，传感器数据、位置信息等存储到存储器或NVM/存储设备中，传感器组可作为输入/输出设备，通信接口可包括网络接口。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

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

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

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

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

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本申请所提供的数据处理方法、装置、电子设备和可读介质，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (10)

1.一种数据处理方法，其特征在于，所述方法包括：

获取当前统计周期内产生的增量数据，按照事务类型对所述增量数据进行划分，得到分别与不同事务类型对应的增量数据表；

获取活跃数据表，并将所述活跃数据表与各增量数据表进行数据关联，所述活跃数据表中包括截至所述当前统计周期的起始时刻未被归档的活跃数据；

基于关联后的数据和已归档的静态数据，生成目标数据模型。

2.根据权利要求1所述的方法，其特征在于，所述活跃数据表包括一级活跃数据和二级活跃数据，所述活跃数据表包括一级活跃数据表和二级活跃数据表；所述将所述活跃数据表与各增量数据表进行数据关联，包括：

基于预设的活跃数据分级条件，确定关键事务；

基于各事务类型对应的事务与所述关键事务的发生先后顺序，将所生成的增量数据表划分为一级增量数据数据表和二级增量数据表；

将所述一级活跃数据表与各增量数据表进行数据关联，并将所述二级活跃数据表与所述二级增量数据表进行数据关联。

3.根据权利要求2所述的方法，其特征在于，所述增量数据包括新增主数据；所述将所述一级活跃数据表与各增量数据表进行数据关联，包括：

将所述新增主数据合并至所述活跃数据表，得到主数据表；

将所述主数据表与各增量数据表进行数据关联。

4.根据权利要求3所述的方法，其特征在于，所述将所述主数据表与各增量数据表进行数据关联，包括：

基于所述主数据表的主键，对各增量数据表进行字段扩充，得到各增量数据表对应的缓存数据表，各缓存数据表的字段中包括所述主键；

基于所述主键，将所述主数据表与各缓存数据表进行数据关联；

其中，所述新增主数据包括新增交易订单数据，所述主键包括交易订单的订单号。

5.根据权利要求4所述的方法，其特征在于，所述将所述主数据表与各缓存数据表进行数据关联，包括：

基于所述主键的值中的目标位字符，将所述主数据表划分为多个第一子表，并将各缓存数据表中的数据划分为多个第二子表；

将对应相同目标位字符的第一子表和第二子表作为待关联子表组，并行地对各待关联子表组中的子表进行数据关联。

6.根据权利要求2所述的方法，其特征在于，所述目标数据模型包括目标数据表；

在所述将所述一级活跃数据表与各增量数据表进行数据关联后，所述方法还包括：将关联后满足预设的一级归档条件的数据作为一级归档数据，将所述一级归档数据汇总，得到所述当前统计周期对应的一级归档数据表，将合并后不满足所述一级归档数据的数据保留至所述一级活跃数据表，得到更新后的一级活跃数据表；

在所述将所述二级活跃数据表与所述二级增量数据表进行数据关联后，所述方法还包括：将关联后满足预设的二级归档条件的数据作为二级归档数据，归入预先生成的用于存储已归档的静态数据的二级归档数据表，将关联后不满足所述二级归档条件的数据保留至所述二级活跃数据表，得到更新后的二级活跃数据表；

所述基于关联后的数据和已归档的静态数据，生成目标数据模型，包括：基于所述更新后的一级活跃数据表、所述一级归档数据表、所述更新后的二级活跃数据表以及所述二级归档数据表，生成目标数据表。

7.根据权利要求6所述的方法，其特征在于，所述二级活跃数据表中包括连续多个历史统计周期对应的历史一级归档数据表中的数据，所述连续多个历史统计周期中的末尾统计周期的下一统计周期为所述当前统计周期的上一统计周期；

所述将所述二级活跃数据表与所述二级增量数据表进行数据关联，包括：

将所述上一统计周期对应的历史一级归档数据表中的数据合并至所述二级活跃数据表中，将合并数据后的二级活跃数据表与所述二级增量数据表进行数据关联。

8.一种数据处理装置，其特征在于，所述装置包括：

获取单元，用于获取当前统计周期内产生的增量数据，按照事务类型对所述增量数据进行划分，得到分别与不同事务类型对应的增量数据表；

关联单元，用于获取活跃数据表，并将所述活跃数据表与各增量数据表进行数据关联，所述活跃数据表中包括截至所述当前统计周期的起始时刻未被归档的活跃数据；

生成单元，用于基于关联后的数据和已归档的静态数据，生成目标数据模型。

9.一种电子设备，其特征在于，包括：

处理器；以及

存储器，其上存储有可执行代码，当所述可执行代码被执行时，使得所述处理器执行如权利要求1-7中任一所述的方法。

10.一个或多个机器可读介质，其上存储有可执行代码，当所述可执行代码被执行时，使得处理器执行如权利要求1-7中任一所述的方法。