CN102043800A - 数据存储实现方法及数据仓库 - Google Patents

Abstract

本发明公开了数据存储实现方法及数据仓库，以降低实现ODS时的资源消耗，该方法包括步骤：在用户访问数据对象时，判断所述数据对象对应的业务系统数据是否更新；在更新的情况下，抽取更新的业务系统数据作为操作数据；并用操作数据更新用户访问的数据对象，以将更新后的数据对象供用户访问。本发明一方面可以保证用户访问的数据对象是更新后的数据，另一方面避免了定时抽取数据浪费资源，尤其是实时性情况下资源大量浪费的问题，从而在保证实现ODS功能的前提下，节约了资源，尤其是在实现I类ODS的情况下，能够节约大量资源。

Description

数据存储实现方法及数据仓库

技术领域

本发明涉及数据库领域，尤其涉及数据存储(ODS，Operational Data Store)实现方法及数据仓库。

背景技术

图1为现有数据系统结构示意图，该数据系统包括若干个业务系统数据库(DB，Data Bases)及数据仓库10，图中画出DB11及DB12作为若干个DB的示意，所述DB一般存储业务部门数据，例如财务数据等；数据仓库10用于统一存储从DB11和DB12中抽取出来的数据，以供用户对这些数据综合使用。

为保持数据仓库10中的数据与DB的数据的时间对应性，目前业界通常在数据仓库10中采用操作数据存储方案，即实现ODS功能，所述操作数据通常是指业务部门进行业务操作带来的DB数据更新。

根据具体业务时间性要求的不同，ODS通常包含下述几类：

I类ODS：在操作数据的数量、业务系统数据库及数据仓库10所属设备等满足要求时，操作数据与DB数据之间的延迟为理论值为1～2秒，即在DB数据更新1～2秒后，将更新的DB数据抽取到数据仓库10中；

II类ODS：要求操作数据与DB数据之间的延迟为2～4小时，即在DB数据更新2～4小时后，将更新的DB数据抽取到数据仓库10中；

III类ODS：要求操作数据与DB数据之间的延迟为12～24小时，即在DB数据更新12～24小时后，将更新的DB数据抽取到数据仓库10中。

为实现ODS，目前采用的方案为：数据仓库10定时运行数据抽取工具从DB11和DB12等DB数据库抽取DB数据。这种方案的缺陷在于：

如果要实现I类ODS，数据仓库10将几乎每隔1～2秒运行数据抽取工具从DB11及DB12等DB数据库抽取DB数据，这将大量耗费数据仓库10所属设备资源。

对于II类和III类ODS，上述定时抽取DB数据的方案虽然可以实施，但是由于不管是否需要，每隔一段时间数据仓库10都会进行数据抽取，因此也存在浪费数据仓库10所属设备资源的问题。

发明内容

本发明提供了ODS实现方法及数据仓库，以降低实现ODS时的资源消耗。

本发明提供了ODS实现方法，包括步骤：判断用户访问的数据对象对应的业务系统数据是否更新；在更新的情况下，抽取更新的业务系统数据作为操作数据；并用操作数据更新用户访问的数据对象，以将更新后的数据对象供用户访问。

本发明还提供了数据仓库，包括：判断单元，用于判断用户访问的数据对象对应的业务系统数据是否更新；抽取单元，用于在判断单元判断出更新的情况下，抽取更新的业务系统数据作为操作数据；及更新单元，用于采用抽取单元抽取的操作数据更新用户访问的数据对象，以将更新后的数据对象供用户访问。

本发明实施例通过在判断出用户访问的数据对象对应的业务系统数据有更新后抽取业务系统更新数据作为操作数据，并将操作数据更新到所属数据对象中，以供用户访问，这一方面可以保证用户访问的数据对象是更新后的数据，另一方面避免了定时抽取数据浪费资源，尤其是实时性情况下资源大量浪费的问题，从而在保证实现ODS功能的前提下，节约了资源，尤其是在实现I类ODS的情况下，能够节约大量资源。

附图说明

图1为现有数据系统结构示意图；

图2为本发明实施例提供的ODS实现方法流程图；

图3为本发明第一实施例实现ODS的方法流程图；

图4为本发明实施例数据系统结构示意图；

图5为本发明第二实施例实现ODS的方法流程图；

图6为本发明实施例提供的数据仓库的结构示意图；

图7为本发明实施例提供的一种判断单元61结构示意图；

图8为本发明实施例提供的另一种判断单元61的结构示意图。

具体实施方式

针对背景技术提及的问题，如果能够在实现ODS的前提下减少数据仓库10从DB11和DB12等DB中抽取操作数据的次数，则可以降低资源消耗，尤其是在I类ODS的情况下，更能够大幅度降低资源消耗。基于该设计思路，本发明实施例提出下述ODS实现方法及数据仓库，以避免现有方案中定时抽取数据导致资源消耗多，尤其是在实现I类ODS时严重消耗资源的问题。

参照图2，为本发明实施例提供的ODS实现方法流程图，结合该图，本发明实施例提供的ODS实现方法包括步骤：

步骤1，在用户访问数据对象时，判断所述数据对象对应的业务系统数据是否更新；

所述数据对象一般是存储在数据仓库内，数据对象对应的业务系统数据存储在业务系统中，通常一种或多种业务系统数据被抽取到数据仓库后，会处理成一种或多种数据对象。

判断所述数据对象对应的业务系统数据是否更新的具体方式可以多种，本发明实施例提出下述判断方式：

1，根据最近一次抽取业务系统数据的时间来判断，例如如果在用户访问数据对象时，最近一次抽取业务系统数据的时间很近，则可以认为业务系统数据还未更新过，也就无需抽取数据。在具体实施时，可以由用户确定预定范围，如果最近一次抽取业务系统数据的时间在该预定范围内，则可以认为业务系统数据无更新。

2、根据业务系统数据实际是否更新来进行判断，例如在业务系统数据更新时接收指示信息，根据指示信息来判断出业务系统数据是否更新。在具体实施时，可以是接收用于指示业务系统数据已经更新的指示信息，并在未接收到该指示信息时判断未更新，或者也可以是接收用于指示业务系统数据未更新的指示信息，并在未接收到时判断出业务系统数据已经更新，此外也可以是无论是否更新均接收指示信息，该指示信息指示的内容为更新或未更新，然后根据指示信息指示的内容判断业务系统是否更新。

步骤2，在更新的情况下，抽取更新的业务系统数据作为操作数据；

如果已经判断出业务系统数据已更新，则可以抽取更新的业务系统数据作为操作数据；其中抽取数据时可以采用多种数据抽取工具，例如数据整合工具(ETL，Extraction-Transformation-Loading)等。

步骤3，用操作数据更新用户访问的数据对象，以将更新后的数据对象供用户访问。

上述方案通过在判断出业务系统数据是否有更新后才抽取操作数据，在实现ODS的前提下，减少了数据抽取次数，因此节约了数据抽取耗费的资源，尤其是在实现I类ODS时，如果根据现有技术，则每隔1～2秒就需要抽取一次数据，这将耗费大量的资源，而本发明实施例中上述方案则在判断出业务系统数据更新后抽取数据，无需定时抽取数据，减少了数据抽取次数，因此能够节约大量资源。

此外本方案还可以只在用户访问数据对象且业务系统数据有更新时才进行数据抽取工作，能够进一步减少数据抽取次数，如果不仅在用户访问数据对象时，而且在用户未访问数据对象时也可以抽取数据，则可以减少用户访问数据对象时抽取的数据的数量，即减少抽取时间，提高了用户访问数据对象的速率。

下面根据步骤1中判断业务系统数据是否更新的方式来具体阐述上述方案的实施过程。

实施例一，根据最近一次抽取业务系统数据的时间来判断业务系统数据是否更新。

图3为本发明第一实施例实现ODS的方法流程图，图4为本发明实施例数据系统结构示意图，结合该图，上述方案的一种实施过程为：

步骤a1，在用户访问数据仓库20中的数据对象时，数据仓库20获取最近一次抽取该数据对象对应业务系统数据的抽取时间；由于数据仓库20一般会存储有操作记录，因此所述抽取时间可以通过查询自身操作记录获得，此外也可以采用其他获取方式；

步骤a2，判断该抽取时间是否处于预定范围，如果是，转到步骤a3，否则转到步骤a5；

可选的，本实施例还可以包括确定预定范围的步骤，该步骤可以在用户访问数据对象时执行。

所述预定范围可以根据实际情况确定，确定因素可以但不限于是：需要实现的ODS类别，业务系统数据的更新时间及用户访问数据对象的时间等。

对于ODS类别，一般来说，如果需要实现的ODS类别越高，则要求业务系统数据更新后，需尽快更新其对应的数据对象，因此预定范围较小。比如对于I类ODS，则较佳的预定范围可以设置在2秒，即如果最近一次抽取业务系统数据的时间在2秒前，则最近一次抽取业务系统数据的时间未处于预定范围内；如果最近一次抽取业务系统数据的时间在2秒内，则最近一次抽取业务系统数据的时间处于预定范围内；对于II类ODS，可以设置在2个小时，对于III类ODS，可以设置在12个小时。

对于业务系统数据的更新时间，一般来说，如果业务系统数据更新时间间隔较长，例如几个小时更新一次，则即使预定范围较大，也基本能够在每次业务系统数据更新后，在用户访问其对应的数据对象时，保证用户访问的是更新后的数据对象，因此预定范围可以较大。如果业务系统数据更新时间间隔较小，则预定范围通常较小，以防止用户访问的数据对象未更新。

对于用户访问数据对象的时间，可以从几个方面考虑：

a，用户访问数据对象的频率，如果用户访问某一个或多个数据对象的频率很高，为保证用户访问的数据对象与其对应的业务系统数据基本一致，则预定范围通常较小，反之如果用户访问某一个或多个数据对象的频率很低，则预定范围可以较大。

b，将用户访问数据对象的时间和其对应的业务系统更新数据的时间结合起来考虑；如果用户访问数据对象的时间与业务系统数据更新的时间差别较大，那么预定范围可较大；如果用户访问数据对象的时间与业务系统数据更新时间差别较小，那么预定范围可较小。

在实施时通常综合考虑上述因素来确定预定范围。

步骤a3，数据仓库20从业务系统21抽取更新的业务数据作为操作数据；其中可以采用ETL工具来抽取业务数据；

步骤a4，数据仓库20用操作数据更新用户访问的数据对象，再将更新后的数据对象提供给用户访问。

步骤a5，数据仓库20将用户访问的数据对象提供给用户访问。

本实施例由于在确定预定范围时考虑到需要实现的ODS类别和/或业务系统数据的更新时间和/或用户访问数据对象的时间等因素，因而确定的预定范围较为科学，能够进一步实现用户访问的数据对象和其对应的业务系统数据的时间一致性，提高了实现ODS的效果。

实施例二、根据业务系统数据实际是否更新来进行判断业务系统数据是否更新。

图5为本发明第二实施例实现ODS的方法流程图，结合该图及图4，另一种实现ODS的实施过程为：

步骤b1，在用户访问数据仓库20中数据对象时，数据仓库20查询自身是否已经接收到业务系统21发来的业务系统数据更新指示信息，如果接收到，转到步骤b2，否则转到步骤b4；所述更新指示消息可以是业务系统21在更新数据后主动发送给数据仓库20，也可以是数据仓库20向业务系统21发送用于查询业务数据是否更新的查询信息，业务系统21获得该查询信息后，如果更新则发送更新指示信息，如果未更新则不发送更新指示信息，当然如果未更新也可以发送未更新指示信息给数据仓库10，则数据仓库10可根据接收到的未更新指示信息判断出未更新。

步骤b2，数据仓库20从业务系统21的数据库抽取更新的业务数据作为操作数据；

步骤b3，数据仓库20用操作数据更新用户访问的数据对象，再将更新后的数据对象提供给用户访问；

步骤b4，数据仓库20将用户访问的数据对象提供给用户访问。

上述两个实施例均可以基于.NET等工具实现。

本发明第二实施例在判断出业务系统数据实际更新后去抽取操作数据，并用操作数据来更新数据对象，因此能够保证业务系统数据更新后，用户访问的数据对象也是对应更新的，提高了数据对象和其对应的业务系统数据的同步性。

本发明实施例还提供了数据仓库，以在保证实现ODS功能的前提下，节约数据仓库所属设备的资源，尤其是在实现I类ODS的情况下，能够节约大量资源。

图6为本发明实施例提供的数据仓库的结构示意图，结合该图，该数据仓库60包括：

判断单元61，用于在用户访问数据对象时，判断所述数据对象对应的业务系统数据是否更新；

抽取单元62，用于在判断单元61判断出更新的情况下，抽取更新的业务系统数据作为操作数据；及

更新单元63，用于采用抽取单元62抽取的操作数据更新用户访问的数据对象，以将更新后的数据对象供用户访问。

由于本发明实施例提供的上述数据仓库60通过判断单元61在判断出更新的情况下由抽取单元62抽取出操作数据，并由更新单元63用所述操作数据来更新用户访问的数据对象，因此降低了数据抽取的次数，在保证实现ODS功能的前提下，节约数据仓库所属设备的资源，尤其是在实现I类ODS的情况下，能够节约大量资源。

由于判断单元61在判断业务系统数据是否更新时，可以有多种判断方案，对应的判断单元61的结构也有多种，下面给出几种判断单元61的结构：

1，如果根据最近一次抽取业务系统数据的时间来判断业务系统数据是否更新，则参照图7，为本发明实施例提供的一种判断单元61结构示意图，所述判断单元61可以具体包括：

抽取时间获取子单元610，用于获取最近一次抽取所述业务系统数据的抽取时间；

判断子单元611，用于判断该抽取时间获取子单元610获取的抽取时间是否处于预定范围内；

第一确定子单元612，用于在判断子单元611判断处于预定范围内时，确定所述数据对象对应的业务系统数据有更新，否则，确定所述业务系统数据未更新。

可选的，本实施例提供的判断单元61还可以包括预定范围确定子单元613，连接至判断子单元611，用于确定所述预定范围。其中预定范围子单元613在确定预定范围时可以根据很多因素确定，例如操作数据存储类别和/或业务系统数据的已有更新时间和/或用户访问数据对象的已有时间等因素，基于该考虑，所述预定范围确定子单元613的结构可以但不限于包括：用于获取操作数据存储类别和/或业务系统数据的已有更新时间的第一子单元；以及用于根据第一子单元获取的操作数据存储类别和/或业务系统数据的已有更新时间确定预定范围的第二子单元。

由于包含预定范围确定子单元613的数据仓库60可以但不限于根据需要实现的ODS类别和/或业务系统数据的更新时间和/或用户访问数据对象的时间等因素来确定预定范围，因此确定的预定范围较为科学，能够进一步实现用户访问的数据对象和其对应的业务系统数据的时间一致性，提高了实现ODS的效果。

2，如果根据业务系统数据实际是否更新来进行判断业务系统数据是否更新，则参照图8，为本发明实施例提供的另一种判断单元61的结构示意图，所述判断单元61可以具体包括：

指示信息获取子单元614，用于获取用于指示业务系统数据已更新的指示信息；

第二确定子单元615，用于在指示信息获取单元614获取到该指示信息时，确定所述业务系统数据已更新，否则确定所述业务系统数据未更新。

其中指示信息获取子单元614可以是接收发来的业务数据已更新指示信息，也可以是主动查询是否更新的查询信息，然后接收基于该查询信息发来的所述指示信息，因此本实施例提出指示信息获取子单元614的结构可以具体包括用于接收业务系统数据更新后发来的指示信息的子单元，也可以具体包括用于发送用于查询业务系统数据是否更新的查询信息的子单元；以及用于接收根据所述查询信息发来的用于指示业务系统数据已更新的指示信息的子单元。

如果在判断未更新时，判断单元61通过接收未更新指示信息判断业务系统数据是否更新，则判断单元61还可以具体包括：

未更新信息获取子单元616，用于获取用于指示业务系统数据未更新的未更新指示信息；以及

未更新确定子单元617，用于在未更新信息获取子单元616获取未更新指示信息后，确定所述业务系统数据未更新。

判断单元61包含未更新信息获取子单元616及未更新确定子单元617后，包含判断单元61的数据仓库60判断业务系统数据是否更新的判断速率将提高，从而提高了数据仓库60向用户提供其访问的数据对象的效率。

上述系统均可以基于.Net工具实现，抽取单元62可以用ETL工具实现，在判断出需要抽取数据时，可以由.Net调用ETL实现。

但上述的方案还可以采用其他工具实现，本发明实施例并不对此进行限制。

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

Claims (21)

1.一种数据存储实现方法，其特征在于，包括：

在用户访问数据对象时，判断所述数据对象对应的业务系统数据是否更新；

在更新的情况下，抽取更新的业务系统数据作为操作数据；并

用操作数据更新用户访问的数据对象，以将更新后的数据对象供用户访问。

2.如权利要求1所述的数据存储实现方法，其特征在于，判断所述数据对象对应的业务系统数据是否更新，具体包括步骤：

获取最近一次抽取所述业务系统数据的抽取时间；

判断该抽取时间是否处于预定范围内；

在处于预定范围内时，确定所述数据对象对应的业务系统数据有更新，否则，确定所述业务系统数据未更新。

3.如权利要求2所述的数据存储实现方法，其特征在于，还包括确定所述预定范围的步骤。

4.如权利要求3所述的数据存储实现方法，其特征在于，根据操作数据存储类别来确定预定范围。

5.如权利要求3所述的数据存储实现方法，其特征在于，根据业务系统数据的更新时间和/或用户访问对象的时间来确定预定范围。

6.如权利要求1所述的数据存储实现方法，其特征在于，判断所述数据对象对应的业务系统数据是否更新，具体包括步骤：

获取用于指示业务系统数据已更新的指示信息；

在获取到该指示信息时，确定所述业务系统数据已更新，否则确定所述业务系统数据未更新。

7.如权利要求6所述的数据存储实现方法，其特征在于，所述获取用于指示业务系统数据已更新的指示信息，具体包括步骤：接收业务系统数据更新后发来的指示信息。

8.如权利要求6所述的数据存储实现方法，其特征在于，所述获取用于指示业务系统数据已更新的指示信息，具体包括步骤：

发送用于查询业务系统数据是否更新的查询信息；

接收根据所述查询信息发来的用于指示业务系统数据已更新的指示信息。

9.如权利要求6所述的数据存储实现方法，其特征在于，判断所述数据对象对应的业务系统数据是否更新，还具体包括步骤：

获取用于指示业务系统数据未更新的未更新指示信息；以及

在获取到未更新指示信息后，确定所述业务系统数据未更新。

10.如1～9中任一项权利要求所述的数据存储实现方法，其特征在于，基于.Net工具来判断所述数据对象对应的业务系统数据是否更新。

11.如1～9中任一项权利要求所述的数据存储实现方法，其特征在于，采用数据整合工具来抽取操作数据。

12.一种数据仓库，其特征在于，包括：

判断单元，用于在用户访问数据对象时，判断所述数据对象对应的业务系统数据是否更新；

抽取单元，用于在判断单元判断出更新的情况下，抽取更新的业务系统数据作为操作数据；及

更新单元，用于采用抽取单元抽取的操作数据更新用户访问的数据对象，以将更新后的数据对象供用户访问。

13.如权利要求12所述的数据仓库，其特征在于，所述判断单元具体包括：

抽取时间获取子单元，用于获取最近一次抽取所述业务系统数据的抽取时间；

判断子单元，用于判断该抽取时间获取子单元获取的抽取时间是否处于预定范围内；

第一确定子单元，用于在判断子单元判断处于预定范围内时，确定所述数据对象对应的业务系统数据有更新，否则，确定所述业务系统数据未更新。

14.如权利要求13所述的数据仓库，其特征在于，还包括预定范围确定子单元，连接至判断子单元，用于确定所述预定范围。

15.如权利要求14所述的数据仓库，其特征在于，所述预定范围确定子单元具体包括：

用于获取操作数据存储类别和/或业务系统数据的已有更新时间的第一子单元；以及

用于根据第一子单元获取的操作数据存储类别和/或业务系统数据的已有更新时间确定预定范围的第二子单元。

16.如权利要求12所述的数据仓库，其特征在于，所述判断单元，具体包括：

指示信息获取子单元，用于获取用于指示业务系统数据已更新的指示信息；

第二确定子单元，用于在指示信息获取单元获取到该指示信息时，确定所述业务系统数据已更新，否则确定所述业务系统数据未更新。

17.如权利要求16所述的数据仓库，其特征在于，所述指示信息获取子单元，具体包括用于接收业务系统数据更新后发来的指示信息的子单元。

18.如权利要求16所述的数据仓库，其特征在于，所述指示信息获取子单元，具体包括：

用于发送用于查询业务系统数据是否更新的查询信息的子单元；

用于接收根据所述查询信息发来的用于指示业务系统数据已更新的指示信息的子单元。

19.如权利要求16所述的数据仓库，其特征在于，所述判断单元，还具体包括：

未更新信息获取子单元，用于获取用于指示业务系统数据未更新的未更新指示信息；以及

未更新确定子单元，用于在未更新信息获取子单元获取未更新指示信息后，确定所述业务系统数据未更新。

20.如12～19中任一项权利要求所述的数据仓库，其特征在于，所述判断单元基于.Net工具实现。

21.如12～19中任一项权利要求所述的数据仓库，其特征在于，所述抽取单元基于数据整合工具实现。

Images