浅析操作数据存储(ODS)

      在数据仓库架构中有一种部件叫Operational Data Store（ODS），中文一般翻译为“操作数据存储”。操作数据存储在通常的数据仓库架构中都是一个可选的部件，它和数据仓库起到互相补充的作用。

      最早给ODS下定义的应该是数据仓库之父Inmon。他的定义是，操作数据存储（ODS）是面向主题的、集成的、可变的、反映当前数据值的和详细的数据的集合，用来满足企业综合的、集成的以及操作型的处理需求。

      Inmon的这个定义与他对数据仓库的定义很像。其中前两个特性和数据仓库是一样的，即都是面向主题的和集成的，而后三个特性和数据仓库相差较大。

      ODS中的数据是可以变化的。这一点是Inmon相对与他的CIF中的数据仓库来说的，在CIF中，数据仓库中的数据是不进行更新的，对于错误的处理通常是采用新的快照来进行保存。而ODS是可以按常规方法进行更新的。

      ODS反映当前数据值。这一点是指ODS中不会长期的保留数据，通常ODS保留的数据的时限最长到一个月或三个月。而数据仓库可以保留五年、十年或更长的数据。

      ODS中保留详细数据。这一点是说ODS中只保留原子数据，而不保留汇总数据。而在数据仓库中原子数据和汇总数据都会进行保留。这和ODS可更新的特性相关，因为随时可能将操作型系统的数据变化更新到ODS中，并且数据的迁移时间间隔会很短，这都使汇总数据在ODS中的意义不大。

      Inmon在给ODS下了定义之后，进一步把ODS分成了四类。根据数据到达ODS的时间间隔，即数据从操作型系统生成开始到数据到达ODS为止的时间长短，ODS分为Class I、Class II、Class III和Class IV四类。

      Class I的ODS指时间间隔为秒级，即对用户来说，ODS是个透明的部件，操作型系统业务发生后，数据立刻就可以在ODS中看到。这类ODS事实上是很难实现的。秒级的数据迁移间隔，我们没有时间进行数据的整合。对于此类ODS，从技术和成本上来说，都是不合算的。

      Class II的ODS指时间间隔为小时级，即操作型系统业务发生后，数据要经个几个小时才能出现在ODS部件中。

      Class III的ODS指时间间隔为天级，即我们常见到的数据仓库的迁移频率，如每天晚上进行一次数据迁移。

      Class IV的ODS指时间间隔更长，可能为月级、甚至年级。Class IV和其他类尤为不同的一点是，Class IV的数据源经常是数据仓库。

      需要说明的一点是，虽然ODS从概念上分成这样的四类，但是在进行数据仓库的架构时，我们不必过于刻板，四类ODS同时使用也应该是很正常的选择。例如，对于非常敏感的个别数据，我们可以选择Class I，而对于一般的数据，选择Class II或者Class III。个人感觉，Class IV是Inmon尤为推荐的一类。

     Class I的ODS是实时数据仓库的一种实现方式。Class II和Class III的ODS是比较通常的ODS实现方式。Class IV的ODS非常有用的一类ODS实现方式。

     在Class IV的ODS中，最为常见的记录就是从数据仓库中总结出来的概况数据（Profile Record）。概况数据是数据情况的大纲。以客户为例，可以总结的概况数据如下：每月买衣服的件数，每周的销售量，每年会看两次眼科医生等等。ODS中的概况数据是从大量的详细数据中总结出来的，大部分是统计和挖掘处理的结果，它们存放到ODS中，供操作人员了解客户的情况。

     下面以点击流数据仓库举例来介绍一下Class IV的ODS。

      对于基于WEB环境的数据仓库系统来说，建立ODS是一个非常好的选择。WEB的点击流数据经过粒度管理器进入数据仓库，当需要对数据仓库中的数据进行访问时，一般会在数据仓库和WEB环境之间建立ODS，而将数据仓库中概况数据存入ODS中，迁移的频率可以根据具体情况自己来指定。这样，ODS和粒度管理器将数据仓库中的数据与WEB环境进行了隔离，提供给WEB环境高性能的查询。

 

      Kimball对操作数据存储的定义是，面向主题的、集成的、经常更新的细节数据存储，用集成的数据来支持事务系统。Kimball也认可Inmon对ODS的分类，但是他认为ODS应该以星型结构来进行建模。

      虽然Kimball对操作数据存储（ODS）的定义和Inmon基本上一样，但是他对操作数据存储的理解、作用与实现和Inmon有着较大的不同。

      Kimball认为ODS在两种情况下是需要的：第一种情况是提供操作型报表，这些报表需要提供面向主题的、集成的数据，所以操作型的源系统无法提供；这些报表和数据仓库中的报表也不相同，因为它们可以是一些定制好的，写死在程序中的报表。第二种情况是需要提供实时的信息时，由于数据仓库的更新频率一般都是24小时，而用户会有更急切的需求来了解数据源的信息，这时，建立操作数据存储是很有必要的。

      对于ODS是保存最细粒度数据的地方的说法，Kimball认为对于最细粒度数据，即原子数据层，应该保存在数据仓库中，而且应该置于维度框架和总线架构中。

      一个和操作数据存储（ODS）常混淆的概念就是数据准备区（Data Staging Area）。很多人把供数据迁移的数据准备区称为ODS。事实上，ODS和Staging Area有着较为明显的不同。

ODS和数据准备区最大的区别就是，ODS是支持用户访问的，而数据准备区是不支持用户访问的。数据准备区包括一组数据迁移的程序和为了清洗数据而建立一组表结构及表中的数据。数据准备区是介于源系统和数据仓库之间的所有内容。而ODS的作用在前面已经提及，它主要是给用户提供分析的数据。ODS的数据来源主要是数据准备区，也有些来源于数据仓库。

      另外，数据准备区的建模比较灵活，甚至可以不是关系型数据库。Staging的意思就是把数据写到磁盘上，而数据准备区用文件同样可以实现数据的清洗、整合过程。不多，大多的数据准备区都是建立在关系数据库之上。ODS的建模则需要考虑用户的需求，毕竟ODS是为用户提供数据的一个部件。

 

     下面谈谈个人对操作数据存储（ODS）的一些观点。

     首先要谈的是ODS的位置和作用。ODS应该位于源系统和数据仓库之间的一个独立部件，它的作用是给用户提供一些在源系统和数据仓库系统都不适合完成的功能。置于ODS应该对用户提供什么样的功能，我觉得没必要过于死板，可以根据自己的需要来定。

     ODS应该是面向主题的。这一点我觉得是有必要的，ODS名称中虽然有操作两个字，但是它的目的主要还是查询和分析。所以面向主题可以使ODS中的数据目的性更明显。

至于ODS是否应该是集成的，我觉得对于大部分情况都是应该的。毕竟集成的数据可以发挥更大的作用，使分析更全面。但是对于实时性要求比较高的情形，集成是不太现实的，因为这时留给ETL的时间很短。集成和实时是一对矛盾的要求。

对于Inmon的第四类ODS，我觉得适用面可能要更广一些。从数据仓库中出来的一些概况数据及数据挖掘等应用的分析结果对于用户可能会起到非常大的作用。我们把这些数据单独保存在ODS中，供操作用户随时快速的查看，给他们的工作提供了极大的方便。