一种维度数据处理方法及装置与流程

本申请涉及数据处理领域，尤其涉及一种维度数据处理方法及装置。

背景技术：

随着信息技术的不断发展，基于互联网的业务呈现爆炸式增长。一种互联网业务通常有与之对应的业务数据。当业务数据达到较大规模时，为便于管理，通常采用基于维度建模的数据仓库技术对业务数据进行存储。

基于维度建模的数据仓库技术将业务的业务数据划分为多个维度。比如，当业务数据体现为业务的多个属性及对应的值时，可以将一类属性及其对应的值作为一个维度，该属性及其对应的值称为与该维度对应的维度数据。然后在数据仓库中采用数据表的形式保存该维度对应的维度数据。

在实际应用中，同一笔业务随着时间变化，可能接收到用于变更该笔业务的状态的业务信息，进而可能要根据该业务消息，通过对数据表中保存的该笔业务的某些维度的维度数据进行变更，实现对该笔业务的状态的变更。这种随着时间变化可能发生变更的维度可以称为缓慢变化维(slowlychangingdimensions，scd)。

在现有技术中，当要变更该笔业务的状态时，会对数据仓库中数据表内保存的这种缓慢变化维的维度数据记录进行相应变更，维度数据记录变更完成即意味着该笔业务的状态变更完成，并用变更后的维度数据记录表示该笔业务的最新状态。

但是，上述处理方式无法记录缓慢变化维的变化过程。

技术实现要素：

本申请实施例提供一种维度数据处理方法及装置，用以解决现有技术中的维度数据处理方式无法记录缓慢变化维的变化过程的问题。

本申请实施例提供的一种维度数据处理方法，包括：

接收用于变更业务的状态的业务消息；

根据所述业务消息，向数据表中插入所述业务的变更后状态的维度数据记录，所述维度数据记录具有与之对应的标记信息，所述数据表用于保存所述业务的各状态的维度数据记录；

根据插入维度数据记录后的数据表，对数据表中已保存的所述业务的各状态的维度数据记录的标记信息进行更新；

其中，所述标记信息用于表示与之对应的维度数据记录是否反映所述业务的最新状态。

本申请实施例提供的一种维度数据处理装置，包括：

接收模块，用于接收用于变更业务的状态的业务消息；

变更模块，用于根据所述业务消息，向数据表中插入所述业务的变更后状态的维度数据记录，所述维度数据记录具有与之对应的标记信息，所述数据表用于保存所述业务的各状态的维度数据记录；

更新模块，用于根据插入维度数据记录后的数据表，对数据表中已保存的所述业务的各状态的维度数据记录的标记信息进行更新；

其中，所述标记信息用于表示与之对应的维度数据记录是否反映所述业务的最新状态。

本申请实施例提供另一种维度数据处理方法及装置，用以解决现有技术中的维度数据处理方式无法记录缓慢变化维的变化过程的问题。

本申请实施例提供的一种维度数据处理方法，包括：

接收用于变更业务的状态的业务消息；

根据所述业务消息，创建并执行事务，其中，所述事务中包含的各步骤是按照如下顺序执行的：

根据所述业务消息，向数据表中插入所述业务的变更后状态的维度数据记录，所述维度数据记录具有与之对应的标记信息，所述数据表用于保存所述业务的各状态的维度数据记录；

针对插入维度数据记录后的数据表中已保存的所述业务的各状态的维度数据记录，将包含的业务消息创建时间最新的维度数据记录的标记信息更新为第一值，所述第一值表示对应的维度数据记录反映所述业务的最新状态；

针对插入维度数据记录后的数据表中已保存的所述业务的各状态的维度数据记录，将除了包含的业务消息创建时间最新的维度数据记录以外的、其他维度数据记录的标记信息更新为第二值，所述第二值表示对应的维度数据记录不反映所述业务的最新状态。

本申请实施例提供的一种维度数据处理装置，包括：

接收模块，用于接收用于变更业务的状态的业务消息；

处理模块，用于根据所述业务消息，创建并执行事务，其中，所述事务中包含的各步骤是按照如下顺序执行的：

根据所述业务消息，向数据表中插入所述业务的变更后状态的维度数据记录，所述维度数据记录具有与之对应的标记信息，所述数据表用于保存所述业务的各状态的维度数据记录；

针对插入维度数据记录后的数据表中已保存的所述业务的各状态的维度数据记录，将包含的业务消息创建时间最新的维度数据记录的标记信息更新为第一值，所述第一值表示对应的维度数据记录反映所述业务的最新状态；

针对插入维度数据记录后的数据表中已保存的所述业务的各状态的维度数据记录，将除了包含的业务消息创建时间最新的维度数据记录以外的、其他维度数据记录的标记信息更新为第二值，所述第二值表示对应的维度数据记录不反映所述业务的最新状态。

本申请实施例通过上述至少一种技术方案，在缓慢变化维的变化过程中，同一张数据表不仅可以保存最新维度数据记录，而且可以保存各历史维度数据 记录，从而解决了现有技术中的问题。此外，在本申请的技术方案中，还存在基于维度数据记录的标记信息，通过该标记信息可以区分历史维度数据记录和最新维度数据记录，从而有利于分析缓慢变化维的变化过程。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1为本申请实施例提供的维度数据处理方法的过程；

图2为本申请实施例提供的另一种维度数据处理方法的过程；

图3为本申请实施例提供的对应于图1的维度数据处理装置结构示意图；

图4为本申请实施例提供的对应于图2的维度数据处理装置结构示意图。

具体实施方式

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

为了便于理解，下面用以电子商务业务为例，对背景技术中提到的问题进行说明。

例如，对于一笔电子商务业务，可以根据该业务的属性类别将其划分为订单、时间、商户等多个维度，订单维度就是一种缓慢变化维。每笔电子商务业务一般可以有订单创建、订单支付中和订单支付完成三种状态，以订单维度而言：当业务初始化为订单创建状态时，会向数据表中插入一条订单维度的维度数据记录；当业务要由订单创建状态变更为订单支付中状态时，可以对该维度 数据记录相应地进行第一次变更，第一次变更完成后，业务处于订单支付中状态；当业务要由订单支付中状态变更为订单支付完成状态时，可以对第一次变更后的维度数据记录进行第二次变更，第二次变更完成后，业务处于订单支付完成状态。

可以看到，对于一笔电子商务业务的订单维度，任意时间数据表中只存在一条对应于订单维度的维度数据记录，这条维度数据记录可以反映业务的最新状态，但是无法记录订单维度的变化过程。

为了解决现有技术中的问题，在本申请实施例中，对于业务的各状态中的每种状态，当业务要变更为该状态时，可以向数据表中新插入一条与该状态对应的维度数据记录(简称为：该状态的维度数据记录)，而不是像现有技术那样只在原有维度数据记录上进行变更；并且可以为维度数据记录增加标记信息，该标记信息可以用于表示该维度数据是否反映业务的最新状态(是否反映该业务的缓慢变化维的维度数据的最新状态)，进一步地，还可以用标记信息对各维度数据记录进行区分，从而，可以在一张数据表中保存缓慢变化维在业务的各状态的维度数据记录，进而根据各维度数据记录，可以分析缓慢变化维的变化过程。

不仅如此，本申请实施例还考虑了在实际应用中，用于变更业务的状态的业务消息可能会发生乱序和/或并发的特殊场景，并提供了可以应对这些特殊场景的维度数据处理方案，从而可以进一步地提高本申请的方案的适用性和可靠性。

下面对本申请的方案进行具体说明。

图1为本申请实施例提供的维度数据处理方法的过程，该过程的执行主体可以是终端或服务器。所述终端包括但不限于：个人计算机、手机、平板电脑、智能手表、车载移动台等；所述服务器包括但不限于：个人计算机、大中型计算机、计算机集群等。执行主体并不构成对本申请的限定。为了便于描述，本申请实施例以执行主体是服务器为例进行说明。

在本申请实施例中，所述的维度可以是可能随着时间变化或业务状态变化而变化的维度，如缓慢变化维等。

图1中的过程具体可以包括以下步骤：

s101：接收用于变更业务的状态的业务消息。

在本申请实施例中，所述业务可以是电子商务业务、金融业务、通信业务等任意类型的业务，相应地，服务器可以是该业务的服务器。业务具有至少两种状态，所述业务消息可以是任意用于将业务初始化(这也属于一种变更)为一种状态，或者，用于将业务从一种状态变更为另一种状态的消息。本申请实施例对业务消息的格式和内容并不做限定。

例如，对于一笔电子商务业务，业务消息可以是请求创建订单的消息，用于将创建该笔电子商务业务，并将该笔电子商务业务初始化为订单创建状态；也可以是请求支付订单的消息，用于将该笔电子商务业务从订单创建状态变更为订单支付中状态；也可以是确定订单支付完成的消息，用于将该笔电子商务业务从订单支付中状态变更为订单支付完成状态。

又例如，对于一笔金融(假定为转账)业务，可以是请求转账的消息，用于将该笔金融业务初始化为转出方已扣款转入方尚未收款的状态；也可以是确定转账完成的消息，用于将该笔金融业务从转出方已扣款转入方尚未收款的状态，变更为转出方已扣款转入方已收款的状态。

s102：根据所述业务消息，向数据表中插入所述业务的变更后状态的维度数据记录，所述维度数据记录具有与之对应的标记信息，所述数据表用于保存所述业务的各状态的维度数据记录。

在本申请实施例中，所述业务消息中可以携带用于对生成或变更维度数据的参数，也可以携带用于请求任意设备生成或变更维度数据的指令。

在背景技术中已提到，在现有技术中，当业务状态变更时，是对数据表中已保存的、对应的维度数据记录进行变更，用变更后的维度数据记录反映业务的最新状态，可以看到，这种方案实质上是用变更后状态的维度数据记录替换 掉变更前状态的维度数据记录。

而在本申请实施例中，每当变更业务的状态时，可以通过向数据表中插入变更后状态的一条维度数据记录，实现变更业务的状态，这样的话，业务的各状态的维度数据记录都得以保存在数据表中。其中，插入的维度数据记录可以是基于接收的业务消息生成的。

沿用上例的电子商务业务进行说明。假定某笔电子商务业务处于订单支付完成，根据前面的说明可知，服务器至少接收过针对该笔电子商务业务的三条业务信息，导致该笔电子商务业务的状态至少变更三次，相应地，向数据表中至少插入过属于订单维度的三条维度数据记录。

所述标记信息在现有技术中是没有的，而是本申请的方案新增的，在步骤s103中对其进行具体说明。

s103：根据插入维度数据记录后的数据表，对数据表中已保存的所述业务的各状态的维度数据记录的标记信息进行更新；其中，所述标记信息用于表示与之对应的维度数据记录是否反映所述业务的最新状态。

在本申请实施例中，由于对于一笔业务的维度，数据表中可能要保存属于该维度的多条维度数据记录，因此，可以对所述多条维度数据记录进行区分，以便于查询及分析。

具体的，每条维度数据记录可以分别具有与之对应标记信息，具体的，每条维度数据记录可以包含或者关联一个标记信息，作为与该条维度数据记录对应的标记信息。为了便于描述，可以将维度数据记录包含或者关联的标记信息称为：维度数据记录的标记信息。本申请实施例对维度数据记录包含或关联标记信息的方式并不做限定。例如，可以为针对预先对维度数据记录的格式进行修改，增加一个预先字段，用该预定字段保存标记信息，这种方案只需针对数据表中的维度增加一个属性列(该属性列的属性即为该预定字段)即可，优点是实施成本小；或者，也可以用单独的文件，记录各维度数据记录关联的标记信息，这种方案是优点是对数据表的影响较小；等等。

在本申请实施例中，标记信息可以用于区分历史维度数据记录(业务的当前状态之前的各状态的维度数据记录)和最新维度数据记录(业务的当前状态的维度数据记录)。在这种情况下，维度数据记录的标记信息可以有两种取值(分别称为第一值、第二值)：第一值可以表示该维度数据记录是最新维度数据记录，也即，该维度记录反映业务的最新状态；第二值可以表示该维度数据记录是历史维度数据记录，也即，该维度记录不反映业务的最新状态。

标记信息还可以用于对各历史维度数据记录进一步地区分。在这种情况下，维度数据记录的标记信息可能的取值的数量，可以与业务可能的状态的数量相同，每一种取值可以对应于一种状态。从而，对于一笔业务的一个维度的各维度数据记录，每个维度数据记录的标记信息都是不相同的，因此，可以根据标记信息将所述各维度数据记录一一区分开来。这样的话，可以提高以后分析该维度的变化过程的效率。

在本申请实施例中，每当针对某笔业务，向数据表中插入了新的维度数据记录时，可以说明该笔业务的状态发生了变更，因此，可以对属于该笔业务的、与插入的新的维度数据记录属于同一维度的、部分或全部维度数据记录的标记信息相应地进行更新。在实际应用中，所述更新的操作的实时性越高，则标记信息的实时性和可靠性也越高。

在本申请实施例中，针对步骤s103中的各维度数据记录的标记信息执行的更新操作，也可以不全在步骤s103中执行，其中的一部分也可以在步骤s102中或步骤s102之前执行，所述其中的一部分可以指业务的各历史维度数据记录。

通过图1中的方法，在缓慢变化维的变化过程中，同一张数据表不仅可以保存最新维度数据记录，而且可以保存各历史维度数据记录，从而解决了现有技术中的问题。此外，在本申请的技术方案中，还存在基于维度数据记录的标记信息，通过该标记信息可以区分历史维度数据记录和最新维度数据记录，从而有利于分析缓慢变化维的变化过程。

为了便于理解，下面对图1中的步骤进一步地说明。

前面已经提到，维度数据记录包含或关联标记信息的方式可以有多种。本申请实施例主要针对预定字段的方式进行说明。具体的，所述维度数据记录的标记信息可以通过所述维度数据记录的预定字段进行保存。

例如，可以针对维度增加一个属性行，该属性行的属性即为该预定字段，假定该预定字段的名称为“tag”(为了便于，将该预定字段称为tag字段)，以及假定tag字段的数据类型为整型。

可以预先对tag字段的不同取值所表示含义进行定义。如tag字段可以等于1或0，其中，1作为第一值，0作为第二值，则当tag字段等于1时，可以表示对应的维度数据记录反映业务的最新状态，当tag字段等于0时，可以表示对应的维度数据记录不反映业务的最新状态。

当然，若要对各历史维度数据记录也进行区分的话，tag字段可以有更多的取值。例如，对于上述的电子商务业务，tag字段可以等于0或1或2，其中，当tag字段等于0时，可以表示对应的维度数据记录是订单创建状态的维度数据记录，当tag字段等于1时，可以表示对应的维度数据记录是订单支付中状态的维度数据记录，当tag字段等于2时，可以表示对应的维度数据记录是订单支付完成状态的维度数据记录，则在任意时刻，数据表中tag字段值最大的维度数据记录可以反映业务的最新状态。

需要说明的是，上例中的tag字段是该预定字段的一个示例，0、1是预定字段的取值的示例，本申请实施例对该预定字段的名称、数据类型、取值等并不做限定。

在本申请实施例中，所述的插入的操作可以通过数据库的插入(insert)指令实现，所述的更新的操作可以通过数据库的更新(update)指令实现。这些指令具体可以是结构化查询语言(structuredquerylanguage，sql)语句，也可以是其他形式的数据库操作语句。

在本申请实施例中，对于步骤s102和步骤s103，其在不同的场景下的具 体实施方式也可以不同，主要有三种场景：业务消息未乱序也未并发的场景、业务消息可能乱序的场景、业务消息可能乱序且可能并发的场景。下面分别进行说明。

对于业务消息未乱序也未并发的场景，说明如下：

在这种场景下，每当接收到用于变更业务的状态的业务消息，根据该业务消息，要向数据表中插入的、该业务的变更后状态的维度数据记录可以反映业务的最新状态。

因此，可以在插入该维度数据记录前，将数据表中已保存的、与该维度数据记录属于同一维度的各维度数据记录的标记信息更新为第二值，进而，在插入该维度数据记录后，可以将该维度数据记录的标记信息更新为第一值；或者，也可以先插入该维度数据记录，之后，再将该维度数据记录的标记信息更新为第一值，以及将数据表中已保存的、与该维度数据记录属于同一维度的各维度数据记录的标记信息更新为第二值；等等。其中，其中，第一值表示对应的维度数据记录反映业务的最新状态，第二值表示对应的维度数据记录不反映业务的最新状态。

对于业务消息可能乱序的场景，说明如下：

在这种场景下，最新插入的维度数据记录不一定反映业务的最新状态。因此，可以对数据表中的各维度数据记录进一步地分析，以确定反映业务的最新状态的维度数据记录，进而再对维度数据记录的标记信息进行更新。

在实际应用中，维度数据记录可以包含有特定信息，特定信息反映所述维度数据记录对应的业务消息在各业务消息中的逻辑顺序。基于这种前提，对于步骤s103，根据插入维度数据记录后的数据表，对数据表中已保存的所述业务的各状态的维度数据记录的标记信息进行更新，具体可以包括：根据所述业务的标识和插入维度数据记录后的数据表，确定数据表中已保存的所述业务的各状态的维度数据记录；根据确定的各维度数据记录包含的特定信息，对所述各维度数据记录的标记信息进行更新。

在本申请实施例中，维度数据记录中可以包含该维度数据记录所属业务的标识。例如，对于一笔电子商务业务，其标识可以是订单号，或者，其他可以用于唯一确定该笔业务的信息；类似地，对于一笔金融业务，其标识可以是交易号。

进一步地，上述的特定信息可以是业务消息创建时间，或者，用于标记维度数据记录对应的业务消息在各业务消息中的逻辑顺序的标识，如序号等。在此对所述的逻辑顺序进行说明。

逻辑顺序可以指创建以及发送各业务消息的顺序，这种顺序是与业务预定的逻辑匹配的。例如，对于一笔电子商务业务，其三种状态对应的三条业务消息可以为：请求创建订单的消息、请求支付订单的消息、确定订单支付完成的消息。从电子商务业务的业务逻辑上来说，只有在创建订单后，才可能开始进行订单支付，只有在开始支付之后，才可能支付完成，因此，请求创建订单的消息的逻辑顺序先于请求支付订单的消息，请求支付订单的消息先于确定订单支付完成的消息。

但是，在实际应用中，由于处理延迟或网络延迟等原因，可能会导致先创建及发送的消息反而晚于后创建及发送的消息到达服务器。这种情况即为上面提到的：业务消息乱序。

根据上面的说明，当特定信息是业务消息创建时间时，根据确定的各维度数据记录包含的特定信息，对所述各维度数据记录的标记信息进行更新，具体可以包括：根据确定的各维度数据记录包含的业务消息创建时间，在所述各维度数据记录中，将业务消息创建时间最新的维度数据记录的标记信息更新为第一值，以及将其他维度数据记录的标记信息更新为第二值，其中，所述第一值表示对应的维度数据记录反映所述业务的最新状态，所述第二值表示对应的维度数据记录不反映所述业务的最新状态。

通过上一段中的方案，由于是基于业务消息创建时间对标记信息进行更新的，因此，即使业务消息乱序，各标记信息仍能够被正确地更新，各更新后的 标记信息能够正确地表示对应的维度数据记录是否反映业务的最新状态。在实际应用中，上一段中的更新操作可以是在一条update语句中实现的，这样的话，这条update语句内的各操作可以由数据库底层事务保证原子性，也即，要么各操作全部操作成功，要么各操作全部操作失败，从而可以防止各标记信息更新错误。

对于业务消息可能乱序且可能并发的场景，说明如下：

在实际应用中，业务消息不仅可能乱序，而且可能并发。所述并发可以指：服务器在同一时间或在较短的时间间隔内，接收到同一笔业务的至少两条业务消息，从而导致服务器分别针对至少两条业务消息中的每条业务消息的、维度数据处理过程可能会并行执行。在这种场景下，并行执行维度数据处理过程可能会发生冲突，进而导致对标记信息更新错误。

基于事务可以解决这种场景下的问题，所述事务是数据库事务。下面进行对本申请针对这种场景的应对方案进行具体说明。

可以在同一个事务中执行步骤s102和步骤s103。则根据所述业务消息，向数据表中插入所述业务的变更后状态的维度数据记录，根据插入维度数据记录后的数据表，对数据表中已保存的所述业务的各状态的维度数据记录的标记信息进行更新，具体可以包括：

根据所述业务消息，创建并执行事务，所述事务中包含的各步骤是按照如下顺序执行的：

向数据表中插入所述业务的变更后状态的维度数据记录；

针对插入维度数据记录后的数据表中已保存的所述业务的各状态的维度数据记录，将包含的业务消息创建时间最新的维度数据记录的标记信息更新为第一值，所述第一值表示对应的维度数据记录反映业务的最新状态；

针对插入维度数据记录后的数据表中已保存的所述业务的各状态的维度数据记录，将除了包含的业务消息创建时间最新的维度数据记录以外的、其他维度数据记录的标记信息更新为第二值，所述第二值表示对应的维度数据记录 不反映业务的最新状态。

对该事务进一步地说明进行分析。可以看到，该事务中一共包含三个步骤，在具体实施时，每个步骤可以用一条或多条sql语句实现。下面以在实际应用场景下，一些可以用于实现该事务的sql语句作为示例进行说明。

对于该事务中的第一个步骤，可以根据业务消息，提取出要对维度的各属性进行赋值的属性值，进而将提取出的各属性值构成一条新的维度数据记录，并用insert语句将该维度数据记录插入数据表中。

为了便于理解，沿用上例的电子订单业务，对该事务中的第二个步骤和第三个步骤进行说明。

对于第二个步骤，可以采用以下sql语句(称为语句1)实现：

“updatetag＝1fromxxxorderbybiz_timedescwherebiz_order_no＝订单号limit1”；

tag字段即为维度数据记录的标记信息，“xxx”为数据表的名称，biz_time字段为用于记录业务消息创建时间的字段，biz_order_no字段为记录订单号的字段。

语句1中的订单号具体为接收到的业务消息所属业务的订单号。语句1的功能是指示数据库进行以下操作：将该笔业务的各维度数据记录全部筛选出来，并按照维度数据记录所记录的业务消息创建时间降序排列，将排在最前面的一条维度数据记录的标记信息修改为第一值。

对于第三个步骤，可以采用以下sql语句(称为语句2)实现：

“updatetag＝0fromxxxorderbybiz_timedescwherebiz_order_no＝订单号limit3offset1”；

语句2中的“3”表示该笔业务最多只有3种状态；语句2中的订单号具体为接收到的业务消息所属业务的订单号。语句1的功能是指示数据库进行以下操作：将该笔业务的各维度数据记录全部筛选出来，并按照维度数据记录所记录的业务消息创建时间降序排列，对于排在最前面的三条维度数据记录，将 除了排在最前面的一条维度数据记录以外的另外两条维度数据记录的标记信息修改为第一值。

通过上面的事务，是基于业务消息创建时间对标记信息进行更新的，通过事务保证了每条维度数据记录对应的处理步骤都能够完整执行，而且是先将包含的业务消息创建时间最新的维度数据记录的标记信息更新为第一值，再将除了包含的业务消息创建时间最新的维度数据记录以外的、其他维度数据记录的标记信息更新为第二值，因此，即使发生了业务消息乱序和/或并行的情况，仍然可以保证对于业务消息创建时间最新的维度数据记录，该维度数据记录的标记信息会被正确地更新至第一值。且可以保证在任意时间中，对于该笔业务的任一维度，有且只有一条属于该笔业务的该维度的、维度数据记录的标记信息处于第一值。

例如，假定在一段时间内并行接收到两条用于更新业务的状态的业务消息，分别为业务消息a、业务消息b，且按照业务逻辑顺序，业务消息a早于业务消息b创建，显然，根据业务消息b要插入的维度数据记录应当是反映业务的最新状态的。

则根据本申请的方案，基于业务消息a要创建并执行事务a(包含上述三个步骤，假定插入维度数据记录1)，针对业务消息b要创建并执行事务b(也包含上述三个步骤，假定要插入维度数据记录2)。基于事务的特性，事务a中的三个步骤会按照顺序执行，事务b中的三个步骤也会按照顺序执行，在并行场景下，事务a中的三个步骤与事务b中的三个步骤相互之间的执行顺序则是不确定的，但是无论是哪种执行顺序，在事务a和事务b均执行完成时，维度数据记录2的标记信息已被更新为第一值，而维度数据记录1已被更新为第二值，此时的更新结果是正确的、符合事实的。

需要说明的是，以上的各sql语句都是在实施本申请的方案时使用的sql语句的示例，并不构成对本申请的限定。在实际应用中，对于不同的业务，上述sql语句中的参数也可能不同。

以上为本申请实施例提供的维度数据处理方法，基于同样的思路，本申请实施例还提供了另一种维度数据处理方法，如图2所示，所述另一种维度数据处理方法是：用于应对业务消息可能乱序且可能并发的场景的完整方案。

图2为本申请实施例提供的另一种维度数据处理方法的过程，该过程的执行主体可以是终端或服务器。

图2中的过程具体可以包括以下步骤：

s201：接收用于变更业务的状态的业务消息。

s202：根据所述业务消息，创建并执行事务，其中，所述事务中包含的各步骤是按照如下顺序执行的(共s202a～s202c三个步骤)：

s202a：根据所述业务消息，向数据表中插入所述业务的变更后状态的维度数据记录，所述维度数据记录具有与之对应的标记信息，所述数据表用于保存所述业务的各状态的维度数据记录；

s202b：针对插入维度数据记录后的数据表中已保存的所述业务的各状态的维度数据记录，将包含的业务消息创建时间最新的维度数据记录的标记信息更新为第一值，所述第一值表示对应的维度数据记录反映所述业务的最新状态；

s202c：针对插入维度数据记录后的数据表中已保存的所述业务的各状态的维度数据记录，将除了包含的业务消息创建时间最新的维度数据记录以外的、其他维度数据记录的标记信息更新为第二值，所述第二值表示对应的维度数据记录不反映所述业务的最新状态。

通过图2中的方法，不仅可以实现图1中的方法的效果，还可以解决在业务消息乱序或并发的场景下，可能导致对标记信息更新错误的问题。

以上为本申请实施例提供的维度数据处理方法，基于同样的思路，本申请实施例还提供相应的维度数据处理装置，如图3、图4所示。

图3为本申请实施例提供的对应于图1的维度数据处理装置结构示意图，具体包括：

接收模块301，用于接收用于变更业务的状态的业务消息；

变更模块302，用于根据所述业务消息，向数据表中插入所述业务的变更后状态的维度数据记录，所述维度数据记录具有与之对应的标记信息，所述数据表用于保存所述业务的各状态的维度数据记录；

更新模块303，用于根据插入维度数据记录后的数据表，对数据表中已保存的所述业务的各状态的维度数据记录的标记信息进行更新；

其中，所述标记信息用于表示与之对应的维度数据记录是否反映所述业务的最新状态。

通过图3中的装置，在缓慢变化维的变化过程中，同一张数据表不仅可以保存最新维度数据记录，而且可以保存各历史维度数据记录，从而解决了现有技术中的问题。此外，在本申请的技术方案中，还存在基于维度数据记录的标记信息，通过该标记信息可以区分历史维度数据记录和最新维度数据记录，从而有利于分析缓慢变化维的变化过程。

可选地，所述维度数据记录的标记信息通过所述维度数据记录的预定字段进行保存。

可选地，所述维度数据记录包含有特定信息，所述特定信息反映所述维度数据记录对应的业务消息在各业务消息中的逻辑顺序；

可选地，所述更新模块303具体用于：根据所述业务的标识和插入维度数据记录后的数据表，确定数据表中已保存的所述业务的各状态的维度数据记录；根据确定的各维度数据记录包含的特定信息，对所述各维度数据记录的标记信息进行更新。

可选地，所述特定信息包括业务消息创建时间；

可选地，所述更新模块303具体用于：根据确定的各维度数据记录包含的业务消息创建时间，在所述各维度数据记录中，将业务消息创建时间最新的维度数据记录的标记信息更新为第一值，以及将其他维度数据记录的标记信息更新为第二值，其中，所述第一值表示对应的维度数据记录反映所述业务的最新 状态，所述第二值表示对应的维度数据记录不反映所述业务的最新状态。

可选地，所述变更模块302和所述更新模块303具体用于：根据所述业务消息，创建并执行事务，所述事务中包含的各步骤是按照如下顺序执行的：

向数据表中插入所述业务的变更后状态的维度数据记录；

针对插入维度数据记录后的数据表中已保存的所述业务的各状态的维度数据记录，将包含的业务消息创建时间最新的维度数据记录的标记信息更新为第一值，所述第一值表示对应的维度数据记录反映业务的最新状态；

针对插入维度数据记录后的数据表中已保存的所述业务的各状态的维度数据记录，将除了包含的业务消息创建时间最新的维度数据记录以外的、其他维度数据记录的标记信息更新为第二值，所述第二值表示对应的维度数据记录不反映业务的最新状态。

通过图3的装置，还可以解决在业务消息乱序和/或并发的场景下，可能导致对标记信息更新错误的问题。

具体的上述如图3所示的装置可以位于终端、服务器上。

图4为本申请实施例提供的对应于图2的维度数据处理装置结构示意图，具体包括：

接收模块401，用于接收用于变更业务的状态的业务消息；

处理模块402，用于根据所述业务消息，创建并执行事务，其中，所述事务中包含的各步骤是按照如下顺序执行的：

根据所述业务消息，向数据表中插入所述业务的变更后状态的维度数据记录，所述维度数据记录具有与之对应的标记信息，所述数据表用于保存所述业务的各状态的维度数据记录；

针对插入维度数据记录后的数据表中已保存的所述业务的各状态的维度数据记录，将包含的业务消息创建时间最新的维度数据记录的标记信息更新为第一值，所述第一值表示对应的维度数据记录反映所述业务的最新状态；

针对插入维度数据记录后的数据表中已保存的所述业务的各状态的维度 数据记录，将除了包含的业务消息创建时间最新的维度数据记录以外的、其他维度数据记录的标记信息更新为第二值，所述第二值表示对应的维度数据记录不反映所述业务的最新状态。

通过图4中的装置，可以实现图3中的装置的效果，主要解决了在业务消息乱序和/或并发的场景下，可能导致对标记信息更新错误的问题。

具体的上述如图4所示的装置可以位于终端、服务器上。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。

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

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

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

在一个典型的配置中，计算设备包括一个或多个处理器(cpu)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(ram)和/或非易失性内存等形式，如只读存储器(rom)或闪存(flashram)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(pram)、静态随机存取存储器(sram)、动态随机存取存储器(dram)、其他类型的随机存取存储器(ram)、只读存储器(rom)、电可擦除可编程只读存储器(eeprom)、快闪记忆体或其他内存技术、只读光盘只读存储器(cd-rom)、数字多功能光盘(dvd)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitorymedia)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。