一般在带有ODS的系统体系结构中，ODS都设计为如下几个作用：

1、在业务系统和数据仓库之间形成一个隔离层

一般的数据仓库应用系统都具有非常复杂的数据来源，这些数据存放在不同的地理位置、不同的数据库、不同的应用之中，从这些业务系统对数据进行抽取并不是一件容易的事。因此，ODS用于存放从业务系统直接抽取出来的数据，这些数据从数据结构、数据之间的逻辑关系上都与业务系统基本保持一致，因此在抽取过程中极大降低了数据转化的复杂性，而主要关注数据抽取的接口、数据量大小、抽取方式等方面的问题。

2、转移一部分业务系统细节查询的功能

在数据仓库建立之前，大量的报表、分析是由业务系统直接支持的，在一些比较复杂的报表生成过程中，对业务系统的运行产生相当大的压力。ODS的数据从粒度、组织方式等各个方面都保持了与业务系统的一致，那么原来由业务系统产生的报表、细节数据的查询自然能够从ODS中进行，从而降低业务系统的查询压力。

3、完成数据仓库中不能完成的一些功能

一般来说，带有ODS的数据仓库体系结构中，DW层所存储的数据都是进行汇总过的数据，并不存储每笔交易产生的细节数据，但是在某些特殊的应用中，可能需要对交易细节数据进行查询，这时就需要把细节数据查询的功能转移到ODS来完成，而且ODS的数据模型按照面向主题的方式进行存储，可以方便地支持多维分析等查询功能。

在一个没有ODS层的数据仓库应用系统体系结构中，数据仓库中存储的数据粒度是根据需要而确定的，但一般来说，最为细节的业务数据也是需要保留的，实际上也就相当于ODS，但与ODS所不同的是，这时的细节数据不是“当前、不断变化的”数据，而是“历史的，不再变化的”数据。

在ODS的概念定义中，已经描述了ODS的功能和特点，实际上ODS设计的目标就是以这些特点作为依据的。ODS设计与DW设计在着眼点上有所不同，ODS重点考虑业务系统数据是什么样子的，关系如何，在业务流程处理的哪个环节，以及数据抽取接口等问题。

数据调研

数据调研的内容和要求，在《调研规范》文档中做了详细定义，此处不再重复。

数据范围

确定数据范围实际上是对ODS进行主题划分的过程，这种划分是基于对业务系统的调研的基础上而进行的，并不十分关心整个数据仓库系统上端应用需求，但是需要把上端应用需求与ODS数据范围进行验证，以确保应用所需的数据都已经从业务系统中抽取出来，并且得到了很好的组织。一般来讲，主题的划分是以业务系统的信息模型为依据的，设计者需要综合各种业务系统的信息模型，并进行宏观的归并，得到企业范围内的高层数据视图，并加以抽象，划定几个逻辑的数据主题范围。在这个阶段，以ER模型表示数据主题关系最为恰当。第二步：根据数据范围进行数据分析和主题定义　在第一步中定义出来了企业范围内的高层数据视图，以及所收集到的各种业务系统的资料，在这一步中，需要对大的数据主题进行分解，并进行主题定义，直到每个主题能够直接对应一个主题数据模型为止。在这个阶段，将把第一步生成的每个ER图中的实体进行分解，分解的结果仍以ER表示为佳。

主题元素

定义维、度量、主题、粒度、存储期限

定义维的概念特性：

维名称，名称应该能够清晰表示出这个维的业务含义。

维成员，也就是这个维所代表的具体的数据，

维层次，维成员之间的隶属与包含的层次关系，每个层次需要定义名称

定义度量的概念特性：

度量名称，名称应该能够清晰表述这个度量的业务含义

定义主题的概念特性：

主题名称和含义，说明该主题主要包含哪些数据，用于什么分析；

主题所包含的维和度量；

主题的事实表，以及事实表的数据。

定义粒度：

主题中事实表的数据粒度说明，这种粒度可以通过对维的层次限制加以说明，也可以通过对事实表数据的业务细节程度进行说明。

定义存储期限：

主题中事实表中的数据存储周期。

第四步：迭代，归并维、度量的定义

在ODS中，因数据来自于多个系统，数据主题划分时虽然对数据概念进行了一定程度上的归并，但具体的业务代码所形成的各个维、以及维成员等还需要进一步进行归并，把概念统一的维定义成一个维，不允许同一个维存在不同的实体表示（象不同的业务系统中一样）。

第五步：物理实现

定义每个主题的数据抽取周期、抽取时间、抽取方式、数据接口，抽取流程和规则。

物理设计不仅仅是ODS部分的数据库物理实现，设计数据库参数、操作系统参数、数据存储设计之外，有关数据抽取接口等问题必须清晰定义。

简单说：

数据仓库存储是一个面向主题的，反映历史变化数据，用于支撑管理决策。

ODS

操作型数据存储，存储的是当前的数据情况，给使用者提供当前的状态，提供即时性的、操作性的、集成的全体信息的需求。

ODS作为数据库到数据仓库的一种过渡形式，与数据仓库在物理结构上不同，能提供高性能的响应时间,ODS设计采用混合设计方式。

ODS中的数据是"实时值",而数据仓库的数据却是"历史值"，一般ODS中储存的数据不超过一个月，而数据仓库为10年或更多.

Data Mart

为了特定的应用目的或应用范围，而从数据仓库中独立出来的一部分数据，也可称为部门数据或主题数据（subjectarea）。在数据仓库的实施过程中往往可以从一个部门的数据集市着手，以后再用几个数据集市组成一个完整的数据仓库。需要注意的就是在实施不同的数据集市时，同一含义的字段定义一定要相容，这样再以后实施数据仓库时才不会造成大麻烦。

DDS(decision-support system)决策支持系统：

用于支持管理决策的系统。通常，DSS包括以启发的方式对大量的数据单元进行的分析，通常不涉及数据更新。

参考一：http://www.cnblogs.com/liqiu/p/4947801.html

(本部分为转)我在公司的数据部门工作，每天的订单类数据处理流程大致如下：

删除分析数据库的历史订单数据
全量更新订单数据到分析数据库。（由于订单核心数据不大，所以经受得起这么折腾）
将数据简单清洗，并生成数据集市层
分析处理，产出报表。当然还有其他的数据也是这么处理的（比如产品的数据、景区的数据、票种的数据、供应商的数据等等）

还有日志类的数据，这里不是重点，就不介绍了！这么干了一年，发现有如下问题：

业务变化很快，比如业务数据表经常变化字段含义、增加各种逻辑数据等
业务数据源越来越多，随着品类越来越多，新部门逐步成立，数据源也就越来越多样化
需求越来越多，越来越复杂，以前只有大佬想我们要战略数据，可是现在所有的产品和运营都向我们要各种各样的用户行为数据、订单分析数据和竞对优势数据
数据的实时行要求越来越高，这到不是说秒级别就看见结果，而是早晨提出个新业务数据需求，晚上就要！

数据毕竟是为了市场服务的，所以需求我们要跟上它的节奏，这就对数据系统提出了很大的挑战，导致数据质量下降、生产效率下降！该怎么解决哪？在解决这个问题的过程中，逐步发现了一点苗头：发现我们建立的数据仓库与它的定义不太符合。下面是数据仓库的定义：

数据仓库（Data Warehouse）：是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策(Decision Making Support)。

很明显我们并不符合相对稳定的和反应历史变化的两个条件，因为类似订单类数据，每天全量更新（原因是同一个订单状态随着时间会变化，比如今天买了，明天退货了）。这就明显不符合想对稳定这一概念了，更别说反应历史变化了！经过最近的思考，发现自己搭建的系统更符合ODS的定义：

ODS：是一个面向主题的、集成的、可变的、当前的细节数据集合，用于支持企业对于即时性的、操作性的、集成的全体信息的需求。

那么大家可能会问ods和数据仓库的区别是什么哪？答：ods是短期的实时的数据，供产品或者运营人员日常使用，而数据仓库是供战略决策使用的数据；ods是可以更新的数据，数据仓库是基本不更新的反应历史变化的数据，还有很多，这里就不一一列举了。

讲到这里问题就明晰了，如何能搭建一个体系，既能支持战略决策使用的数据仓库数据，又能兼容业务快速的变化和运营产品人员日常需求的ODS数据哪？

数据仓库和ODS并存方案

经过调研，发现大体上有三种解法：

1、业务数据－ ODS －数据仓库

ODS-LMLPHP

优点：这样做的好处是ODS的数据与数据仓库的数据高度统一；开发成本低，至少开发一次并应用到ODS即可；可见ODS是发挥承上启下的作用，调研阿里巴巴的数据部门也是这么实现的。

缺点：数据仓库需要的所有数据都需要走ODS，那么ODS的灵活性必然受到影响，甚至不利于扩展、系统的灵活性差

2、OB － ODS

优点：结构简单。一般的初创数据分析团队都是类似的结构，比如我们部门就应该归结到这一范畴

缺点：这样所有数据都归结到ODS，长期数据决策分析能力差，软硬件成本高，模块划分不清晰，通用性差

3、数据仓库和ODS并行

ODS-LMLPHP

可见这个模型兼顾了上面提高的各自优点，且便于扩展，ODS和数据仓库各做各的，形成优势互补！可以解决现在互联网公司遇到的快速变化、快速开发等特点！特别是对于那些刚刚创建数据团队，数据开发人员紧缺的公司，可以尝试使用这个数据架构解决问题！

参考2:

http://blog.csdn.net/hero_hegang/article/details/8691912

背景知识：在当今这样一个信息技术发展迅速的时代，数据量也在不断的增长，面临这样的压力，总是会有大神提出一些解决方案。比如高层管理人员希望能查看整个公司的发展业绩，数据仓库(Data Warehouse, DW)正是解决该问题的主要方案，随之DW就这样产生了。可是时代在变，需求也会随着改变，比如保险公司的员工希望提高自己的业绩，拿更多的工资，那么他首先希望的就是能把更多的客户挖进来，其实这其中是有很多方法的。最基本的例子，比方说某保险公司的一个客服希望能够以最高的成功率向客户推荐相关的业务，一旦客户来电，客服可以立刻从数据库中调出该客户的相关的一连串信息，从而可以根据这些信息有针对性的向客户推荐相关的业务了，显然，这样的推荐方式明显可以提高成功率。那么问题就来了，怎么解决这样的问题呢？随之，操作型数据存储(Operational Data Store, ODS)的诞生给此类问题提供了良好的解决方案。从理论上讲，这两种解决方案到底有什么区别呢？现在进入正题。

ODS与DW的区别主要有以下几点：

1、数据的当前性

ODS包括的是当前或接近当前的数据，ODS反映的是当前业务条件的状态，ODS的设计与用户或业务的需要是有关联的，而DW则是更多的反映业务条件的历史数据。

2、数据的更新或加载

ODS中的数据是可以进行修改的，而DW中的数据一般是不进行更新的。ODS的更新是根据业务的需要进行操作的，而没有必要立即更新，因此它需要一种实时或近实时的更新机制。另外，DW中的数据是按照正常的或预先指定的时间进行数据的收集和加载的。

3、数据的汇总性

ODS主要是包括一些细节数据，但是由于性能的需要，可能还包括一些汇总数据，如果包括汇总数据，可能很难保证数据的当前性和准确性。ODS中的汇总数据生命周期比较短，所以可称作为动态汇总数据，如果细节数据经过了修改，则汇总数据同样需要修改。而DW中的数据可称为静态的汇总数据。

4、数据建模

ODS是站在记录层面访问的角度而设计的，DW或DM则是站在结果集层面访问的角度而设计的。ODS支持快速的数据更新，DW作为一个整体是面向查询的。

5、查询的事务

ODS中的事务操作比较多，可能一天中会不断的执行相同的事务，而DW中事务的到达是可以预测的。

6、用途

ODS用于每一天的操作型决策，是一种短期的；DW可以获取一种长期的合作广泛的决策。ODS是策略型的，DW是战略型的。

7、用户

ODS主要用于策略型的用户，比如保险公司每天与客户交流的客服；而DW主要用于战略型的用户，比如公司的高层管理人员。

8、数据量（主要区别之一）

ODS只是包括当前数据，而DW存储的是每一个主题的历史快照；

ODS-LMLPHP