数据 | 数据仓库分层

ODS,EDW,DM

来源：
akan957
知乎(Robin、艾伦)
简书(悟成)
bitcarmanlee
狂神314

操作型数据库（ODS），数据仓库（DW或EDW），数据集市（DM）是目前标准数仓结构的三个核心组件。

ODS

操作数据存储ODS（Operational Data Store）,操作型数据仓库，最早的数据仓库模型,是数据仓库体系结构中的一个可选部分，ODS具备数据仓库的部分特征和OLTP系统的部分特征。特点是数据模型采取了贴源设计，业务系统数据库数据结构是怎样的，ODS数据库的结构就是怎样的。所不同的是ODS数据库可以提供数据变化的历史，所以ODS数据库中每张表都会增加一个日期类型，表示数据的时点，将每天数据的变化情况都存下来，这样有利于数据的分析。
一般在带有ODS的系统体系结构中，ODS都设计为如下几个作用：

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

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

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

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

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

一般来说，带有ODS的数据仓库体系结构中，DW层所存储的数据都是进行汇总过的数据，并不存储每笔交易产生的细节数据，但是在某些特殊的应用中，可能需要对交易细节数据进行查询，这时就需要把细节数据查询的功能转移到ODS来完成，而且ODS的数据模型按照面向主题的方式进行存储，可以方便地支持多维分析等查询功能。
在一个没有ODS层的数据仓库应用系统体系结构中，数据仓库中存储的数据粒度是根据需要而确定的，但一般来说，最为细节的业务数据也是需要保留的，实际上也就相当于ODS，但与ODS所不同的是，这时的细节数据不是“当前、不断变化的”数据，而是“历史的，不再变化的”数据。

补充：顺带说一句，楼上几位目测混淆了ODS和贴源层（缓冲区）。贴源层的数据结构和数据内容是和源系统一模一样的，包括里面的垃圾数据，唯一不同的是，贴源层加了“时间戳”。ODS层，则要清洗掉垃圾数据，更改不能入库的格式为数仓支持的格式或优化后的格式，如nchar改为char或Varchar。他们在数仓架构中差异点大致如下（以标准理论为准，实际设计中都会有越界和妥协现象）

贴源层数据存放一般为一周左右，几乎不会超过一个月；而ODS则永久存放。

补充：操作型数据存储，存储的是当前的数据情况，给使用者提供当前的状态，提供即时性的、操作性的、集成的全体信息的需求。
ODS作为数据库到数据仓库的一种过渡形式，与数据仓库在物理结构上不同，能提供高性能的响应时间,ODS设计采用混合设计方式。
ODS中的数据是”实时值”,而数据仓库的数据却是”历史值”，一般ODS中储存的数据不超过一个月，而数据仓库为10年或更多.

EDW

数据仓库：简称EDW，企业级数据仓库，现在大家都在说的就是这个。所不同的是每个行业的EDW都有一个通用的数据模型，结构精简，扩展性强，应用性强，数据模型不像ODS那样会有很大的冗余。

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

DM

数据集市：简称DM，以某个应用为出发点而建设的局部DW，为什么这么说，DM只关心自己需要的数据。不会全盘考虑企业整体的数据架构和应用，每个应用都有自己的DM。所以DM可以基于仓库建设也可以独立建设。

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

DDS

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

ODS与EDW的区别

根据自己的理解与实际项目经验，说说ODS与EDW的异同。如果有不对的地方，欢迎大家批评指正。

维基百科对于ODS的定义为”An operational data store (or “ODS”) is a database designed to integrate data from multiple sources for additional operations on the data. Unlike a master data store, the data is not passed back to operational systems. It may be passed for further operations and to the data warehouse for reporting.”
翻译过来”ODS是一种数据架构或数据库设计的概念，出现原因是来自于当需要集成来自多个系统的数据，结果又要给一或多个系统使用时。”ODS全称为Operational Data Store，按照字面意思理解为操作型数据存储, 是“面向主题的、集成的、可变的、反映当前数据值的和详细的数据的集合，用来满足企业综合的、集成的以及操作型的处理需求”(Bill.Inmon)。ODS在数据仓库中是可选择的一部分，但不是必须的。EDW全称为Enterprise Data Warehouse，即企业级数据仓库，属于分析型数据。随着数据爆炸，数据量呈爆发式增长，机器学习与数据挖掘方法的不断改进，EDW在企业中处于越来越重要的位置。关于数据库，ODS，EDW之间的关系，以下这张图非常好地描述了三者之间的关系。

其中，ADB为传统的关系型数据库，A,B,C表示不同类型的数据流转。A环节表示生产环境中不同数据库之间直接交换数据，例如mysql,sqlserver,oracle等DB直接通过Informatic等工具交换数据。B表示生产环境中的应用数据通过ODS进行数据交换。C表示数据进行到EDW中。以下简要说说两者的区别：

1.使用人员的不同

ODS主要面向营业、渠道等一线生产人员和一线管理人员，为了实现准实时、跨系统的运营细节数据的查询，以获得细粒度的运营数据展现。ODS是可变数据，可以进行增删查改，是介于DB与DW的一种数据存储形态，目的是为了数据仓库的处理和决策系统要求与OLTP系统相隔离，减少决策系统对OLTP系统的性能影响。
EDW主要面向专业分析人员、辅助决策支持人员等，为了实现基于历史数据的统计分析和数据挖掘，以获得客户深层次的特征和市场发展的规律，例如专业分析人员的经营状况趋势分析由EDW提供支撑。

2.数据的规模不同

ODS支持OLTP类型的数据更新，而且一般保存近期数据，所以相对而言数据的量级不会太大；EDW保存的是全量历史数据，所以数据量要比ODS的规模大很多。

3.数据来源不同

ODS的数据来源于生产系统，而EDW的数据来源于ODS4.

4.数据获取性能与及时性

ODS支持OLTP类型的数据更新，数据更新时间短，数据可实现准实时更新，性能与及时性都高于EDW。
EDW因为存的是历史数据，而且数据量很大，一般都是通过批量的方式导入，所以数据的更新速度慢，无法实现实时更新，因此也不支持实时报表与事件监控类的需求。

5.数据粒度

ODS提供简单的操作数据的统计，一般保存的数据粒度较小。有可能也存在部分粗粒度的汇总数据，但是一般汇总的维度少而且简单。
EDW关注对历史数据的深层次分析与挖掘．从分析与挖掘的需要出发按不同主题维度来汇总与组织数据。
EDW提供历史数据的展示和分析，主要提供多层粗粒度汇总数据．汇总的维度多且复杂。

DW数据仓库与ODS的区别

参考一

http://www.cnblogs.com/liqiu/p/4947801.html(本部分为转)
我在公司的数据部门工作，每天的订单类数据处理流程大致如下：

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

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

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

数据毕竟是为了市场服务的，所以需求我们要跟上它的节奏，这就对数据系统提出了很大的挑战，导致数据质量下降、生产效率下降！该怎么解决哪？在解决这个问题的过程中，逐步发现了一点苗头：发现我们建立的数据仓库与它的定义不太符合。下面是数据仓库的定义：
数据仓库（Data Warehouse）：是一个面向主题的（Subject Oriented）、集成的（Integrated）、相对稳定的（Non-Volatile）、反映历史变化（Time Variant）的数据集合，用于支持管理决策(Decision Making Support)。
很明显我们并不符合相对稳定的和反应历史变化的两个条件，因为类似订单类数据，每天全量更新（原因是同一个订单状态随着时间会变化，比如今天买了，明天退货了）。这就明显不符合想对稳定这一概念了，更别说反应历史变化了！经过最近的思考，发现自己搭建的系统更符合ODS的定义：
ODS：是一个面向主题的、集成的、可变的、当前的细节数据集合，用于支持企业对于即时性的、操作性的、集成的全体信息的需求。
那么大家可能会问ods和数据仓库的区别是什么哪？答：ods是短期的实时的数据，供产品或者运营人员日常使用，而数据仓库是供战略决策使用的数据；ods是可以更新的数据，数据仓库是基本不更新的反应历史变化的数据，还有很多，这里就不一一列举了。

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

数据仓库和ODS并存方案

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

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

优点：这样做的好处是ODS的数据与数据仓库的数据高度统一；开发成本低，至少开发一次并应用到ODS即可；可见ODS是发挥承上启下的作用，调研阿里巴巴的数据部门也是这么实现的。
缺点：数据仓库需要的所有数据都需要走ODS，那么ODS的灵活性必然受到影响，甚至不利于扩展、系统的灵活性差

2、OB － ODS

优点：结构简单。一般的初创数据分析团队都是类似的结构，比如我们部门就应该归结到这一范畴
缺点：这样所有数据都归结到ODS，长期数据决策分析能力差，软硬件成本高，模块划分不清晰，通用性差

3、数据仓库和ODS并行

可见这个模型兼顾了上面提高的各自优点，且便于扩展，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、DW和DM概念区分

今天看了一些专业的解释，还是对ODS、DW和DM认识不深刻，下班后花时间分别查了查它们的概念。ODS——操作性数据DW——数据仓库DM——数据集市1.数据中心整体架构

数据中心整体架构

数据仓库的整理架构，各个系统的元数据通过ETL同步到操作性数据仓库ODS中，对ODS数据进行面向主题域建模形成DW（数据仓库），DM是针对某一个业务领域建立模型，具体用户（决策层）查看DM生成的报表。2.数据仓库的ODS、DW和DM概念

ods、dw、dm区分

ODS、DW、DM协作层次图

协作层次
通过一个简单例子看这几层的协作关系

例子
ODS到DW的集成示例

集成例子

小结
数据中心是一个全新的领域，要进这个门还需要正确理解数据中心领域所设计的专业词汇。

浅析ODS与EDW关系

转载：海阔天空
浅析ODS与EDW关系
刘智琼(中国电信集团广州研究院广州510630)

摘要

本文重点介绍了企业运营数据仓储(ODS)和企业数据仓库(EDW )的概念，并对ODS与EDW
之间的关系，包括两者相同点与不同点进行了详尽的对比与阐述，文章还对业界公认的ODS和EDW
两种不同建设方法也分别进行了说明，并给出了作者认为合理的建设方法。

1 前言

ODS(运营数据仓储)与EDW(企业数据仓储)都是中国电信企业数据架构的重要组成部分，它们一起构成企业统一数据平台。2007年大多数省级电信公司都陆续启动ODS与EDW的建设。经调查发现，各省电信公司在两个系统的建设过程中对两个系统在企业数据架构中的各自职能与分工存在一定的疑问与困惑，为帮助大家澄清这些疑问与困惑，本文对ODS与EDW在整个企业数据架构中的关系进行详尽阐述，包括对两者相同点的分析、不同点的对比。使读者在对比与分析过程中理解两者的联系与区别。同时本文还对ODS与EDW如何建设的两种观点逐一阐述与分析，并给出了相应的建议。

2 企业数据架构

EDW主要为企业提供分析决策服务。ODS主要实现企业数据整合、共享和准实时运营监控等功能，ODS是EDW的一个有益的补充和扩展。生产系统、ODS及EDW之间的数据关系如图1所示，

其中．ADB为应用数据库；A、B、C表示不同类型的数据流动：A表示操作环境中应用数据库之间的直接数据交换；B表示操作环境中应用数据库之间通过ODS进行数据交换;C表示数据从操作环境被抽取到分析环境。
操作环境下各生产系统中的运营数据通过ETL(抽取、转换、装载)过程进人到ODS中，生产系统之间准实时的数据交换由ODS系统完成，ODS系统同时还将整合好的操作环境下的运营数据通过ETL等方式传送到EDW中．完成运营数据从操作环境进人到分析环境的过程。
各生产系统的应用数据库、ODS、EDW构成了整个企业数据架构的主体。下文重点对企业数据架构中的ODS和EDW这两个实体的概念与作用做详细说明。

2．1 ODS的概念及作用

ODS存储了运营系统(如OLTP(联机事务处理)系统)近实时的详细数据。ODS的概念最早是由“数据仓库之父”——Bill
Inmon提出的。ODS最初引入是为了寻找能满足快速加载和数据整合的性能要求，并且减少面向分析需求的变更和扩充对生产系统影响的解决方案，这一解决方案便是在生产系统和EDW之间增加一个数据整合层(也叫做数据缓冲层)即ODS。具有数据整合层的作用，是提出ODS概念的主要出发点。随着技术的发展，近年来ODS被赋予的功能和作用也得到了延伸，目前业界普遍认同的观点是：ODS为企业原始运营数据存储提供了一个整合平台，它的信息来自于不同的运营型应用系统。通过数据接口,在数据整合业务规则作用下,进入ODS的信息是可靠的、可信的。ODS中数据的集成、实时特征决定了ODS主要有以下3个作用。
对运营数据进行清理整合，提高运营数据质量，是EDW的一个主要数据来源。ODS对生产系统产生的数据进行了初步的清洗、过滤和整合，存储了较为详细和全面的企业运营数据，ODS中的数据不仅具有较高的数据质量，而且比OLTP系统更有利于EDW对数据进行获取和进一步的转换、整合等处理，是EDW的主要数据来源之一。·
实现跨系统的近实时报表和查询统计应用。ODS从不同的运营应用系统中采集数据．整合各个系统的共享交易数据，形成企业级数据的整体视图。ODS最大的价值是集成了跨系统的数据，从而能够实现一些跨系统的报表和查询统计应用。另外，ODS也可以从EDW中获取自身所需的数据．如经过EDW统计分析后的一些结果性的数据，可以提供给统计分析人员和业务人员进行实时调用和备查。·
作为其他生产系统的数据同步源。ODS捕捉当前和近期的交易数据．数据具有实时性或准实时性，ODS中的数据按照需要可以与运营系统数据定期同步。由于ODS中的数据是“新”的。因而可以通过它使数据与其他生产系统中的数据同步。

2．2 EDW 的概念及作用

EDW依据企业的统一标准和规则对来自于企业内外的分散在不同系统的数据进行消除非一致性的集成和标准化处理(即ETL处理)，形成企业数据的全面统一视图。
EDW采用多维分析和数据挖掘等手段。细分市场和客户，支撑市场的经营分析、准确决策和快速反应能力。为各级部门和分析决策人员提供基于部门的和基于企业的全方位的数据和分析服务。通过EDW，从根本上解决了数据分散重复、共享困难和信息孤岛等问题，充分发挥了数据资源的价值，全面提升了企业在经营决策、运营管理、业务拓展和客户服务等方面的支撑能力。EDW中数据面向主题、集成及非易失的特征决定了EDW主要有以下两个作用。·
为企业各级的经营决策和市场营销提供及时、精确、全面的数据支持和科学、方便、体系化的分析工具和使用方法，为除生产系统以外的管理、分析等需求提供数据支撑，实现业务数据与分析数据的分离。
解决目前市场等部门信息获取能力和分析决策手段不能适应企业环境变化和精确化管理要求的问题，并通过各种形式的主题，专题分析，支撑针对性营销、上市信息披露、精确化管理．有效降低营销成本，减少客户流失，寻找商机，达到提升企业价值的目的。

3 ODS和EDW 的相同点与不同点

3．1 ODS与EDW的相同点

从ODS与EDW各自的概念与作用可以看出。ODS与EDW具有以下的共同之处。·
ODS与EDW都是企业数据架构中的独立系统，两个系统都不是直接产生运营数据的系统，两个系统中的数据都是由操作环境的数据经过抽取、转换、加载(ETL)的过程而来，还要进行进一步的清理、整合等工作(EDW的数据可由ODS加载装入)。· ODS与EDW一样都既有细粒度的数据。也有根据不同维度汇总的汇总数据。· ODS与EDW上均提供基于跨系统整合后数据的报表类应用。

3．2 ODS与EDW之间的差异

虽然ODS与EDW具有一些相似之处．但两者却是完全不同的实体，下面从多个角度对比两者的不同之处。
(1)使用角色·
ODS主要面向营业、渠道等一线生产人员和一线管理人员，为了实现准实时、跨系统的运营细节数据的查询，以获得细粒度的运营数据展现，例如渠道人员查询客户的全视图信息由ODS提供数据支撑。· EDW主要面向专业分析人员、辅助决策支持人员等，为了实现基于历史数据的统计分析和数据挖掘，以获得客户深层次的特征和市场发展的规律，例如专业分析人员的经营状况趋势分析由EDW提供支撑。
(2)数据来源·
ODS需要的大部分运营数据直接来源生产系统。 ODS中的部分分析结果数据来源于EDW，例如客户洞察信息等。· EDW需要的运营数据，如果在ODS中已存在，EDW则直接从ODS获取这部分数据。·
EDW需要的运营数据，如果在ODS中没有，EDW则直接从生产系统获取这部分数据。
(3)数据获取性能和及时性·
ODS支持OLTP类型的数据更新，数据更新时间短，数据可实现准实时更新，性能与及时性都高于EDW 。·
EDW中的数据一般通过批量加载进入，数据更新速度慢，无法实现准实时更新，数据更新时间不足以支持实时的报表和事件监控需求。
(4)数据架构
ODS以关注生产运营过程的统计与监控为主的生产视角主题域方式来组织数据。ODS提供操作数据的统计，主要提供应用需要的细粒度运营数据。ODS中也存在部分粗粒度汇总数据，但汇总的维度少且简单。EDW关注对历史数据的深层次分析与挖掘．从分析与挖掘的需要出发按不同主题维度来汇总与组织数据。EDW提供历史数据的展示和分析，主要提供多层粗粒度汇总数据．汇总的维度多且复杂。
(5)数据共享能力
ODS为其他生产系统提供运营数据的准实时数据共享服务。
EDW一般不为生产系统提供此类准实时的数据共享服务。系统中的数据只供本系统分析与挖掘应用使用。
(6)系统提供应用数据查询。
ODS提供生产环境下的数据查询，查询的交易量较小，不耗费太多资源，有确定的完成速度。而EDW提供分析环境下的查询，查询单元量较大，消耗的资源很多，完成的速度也不确定。固定报表。ODS提供生产环境下实时性较高的生产经营报表，而EDW提供分析环境下的主题分析与挖掘报表。动态报表。ODS提供面向少量维度的细粒度数据的统计，而EDW提供面向多个维度的多层粗粒度数据的主题统计、分析及深层次的挖掘。ODS提供绩效管理和统计、数据质量审计和监控管理等功能。EDW提供趋势分析、客户消费行为分析和评估等功能。
(7)数据存储
客户等关键实体数据。ODS长久保存当前数据，EDW长久保存当前与历史数据。详单数据。ODS保存1个月到3个月；EDW保存2年。汇总数据。ODS保存3年；EDW保存5年。其他数据。ODS保存l3个月；EDW保存3年。
(8)系统技术特征ODS主要面对大并发用户数、小数据量的访问，EDW主要面对小并发用户数、大数据量的访问。 ODS数据库优化同时侧重索引和分区技术；EDW数据库优化主要侧重分区技术。
ODS支持OLTP类型和OLAP(联机分析处理)类型的数据操作，EDW支持OLAP类型的数据操作。
(9)系统可靠性
;ODS参与运营．必须保证可靠性。
相对ODS．EDW可以允许有更多的脱机时间。
(1O)系统开放性因为需要与大量不同硬件、数据库配置的系统相互交换数据。ODS要求比较高的系统开放性。

EDW一般只获取数据．而不提供给其他应用系统以多种模式直接访问，解决方案上也可采用相对封闭的数据库、软硬件平台。

4 ODS与EDW 建设方案

从上述ODS与EDW
的分析与对比可知，ODS与EDW是两个定位与功能完全不同的实体．但在ODS与EDW的实际建设方式上，业界又有两种不同的声音，一种是以Bill
Inmon为代表的认为ODS应该作为一个独立系统单独建设．另一种是以Ralph
Kimball为代表的认为ODS应该纳入到EDW中．作为EDW的一部分，在一个独立系统中统一建设。下文对两种方案逐一进行说明。Bi11
Inmon在1996年写的《建立运营数据仓储》一书中正式提出了ODS的概念。Inmon认为分析决策需要基于越来越实时和细节的运营数据．同时这些数据又必须是集成的和面向主题的．而运营系统和数据仓库均无法满足相应的信息需求，因此提出了ODS的概念，并在整个IT支撑体系(即Inmon所说的企业信息工厂)中增加了独立的ODS组件。Bill
Inmon提出的两者建设架构如图2所示。

从图2可以看到．ODS的数据来自于各个分散的运营系统，这些数据在独立的ODS中进行整合．在ODS中形成面向主题的、集成的、易变的、当前值的、详细的运营数据．按照业务需求和性能的要求进行组织存储．并在ODS建立相应的应用以满足业务的要求。ODS中整合好的运营数据通过ETL处理过程进入到EDW中．ODS与EDW作为两个独立的系统分别建设。而另外一种观点的提出者Ralph Kimball认为在技术发展的情况下．Bill
Inmon认为的ODS单独存在的理由(ETL的限制无法实现实时数据加载、大量细粒度数据的存储、高性能的查询和7x24
h可靠性的要求．增加了数据仓库的负载．甚至会引起数据仓库的崩溃)不成立。Kimball认为，支撑EDW的软、硬件技术得到了发展．大数据量存储的数据仓库技术已经不是问题。也就是说数据仓库系统中存储细粒度的数据也是没有问题的，ETL的处理速度越来越快，通过高速的ETL工具已经可实现以所需要的任何频度抽取数据到EDW中；而且随着EDW本身的发展，EDW越变越大．分析更加细节的客户行为和更加具体的操作数据的需求也在增长．在大多数情况下．分析挖掘必须基于细粒度数据进行，细粒度的运营数据越来越多地在EDW中被使用．因而Kimball认为在这样的情况下．ODS已经没必要作为一个单独的系统．可看作是数据仓库系统的“前端边缘”。他将ODS重定义为EDW中的面向主题的、集成的、
经常扩展的细节数据的存储区域。同时Kimball认为把ODS纳入到数据仓库的环境后较其单独建设还会给维护者和使用者带来更大的便利与好处，包括只建立一个单独的抽取系统．减少ETL开发与维护工作量：运营细节数据在一个统一的系统中存储．减少数据的冗余存储等。Kimball提出的两者建设架构如图3所示。

在ODS与EDW的实际建设过程中．这两种观点都有不同的追随者．在系统架构设计上都有采用。作者也一度倾向于Kimball的ODS应作为EDW的一部分建设的观点，但是随着对ODS与EDW更进一步的研究。作者发现Kimball之所以建议将ODS作为EDW的一个部分建设，更多考虑的是．单一系统的数据获取频度与大数据量细粒度数据存储能力这两个方面能同时满足ODS与EDW的需要．但是ODS是否单独建设不仅需要考虑单一系统能否实时获取并存储大量运营细节数据。更应该考虑单一系统能否高效地同时支持ODS和EDW上的两种不同类型的前端应用。ODS与EDW上需要承载的应用是截然不同的，为更高效地支撑两种不同类型的应用，系统应采用的硬、软件的技术特点是各不相同的。如果按照Kimball的理论将两者建立在一个系统中．不是绝对不行．但是和它们分开建设相比。混合两种不同类型的工作到同一个系统需要耗费更多的资源和成本，而且更加难以保证服务水平，因此从系统的稳定性、性能、成本等方面综合考虑，原则上作者不建议ODS与EDW建设在一个系统中，两个实体应作为两个独立系统分开建设。但对于数据规模不大，EDW
已经建设完成的个别省，在EDW数据库产品、硬件设备、数据实时性及应用支撑能力等方面能较好地满足ODS应用支撑的功能及性能要求的前提下，作者认为将ODS与EDW合建在一个系统内也是切实可行的。

参考文献
1 lnmon W H著．王志海等译．数据仓库(原书第4版)．北京：机械工业出版社．2006
2 中国电信集团．中国电信CTG-MBOSS EDA分总V1．O规范．2oo5
3 Baragoin C，Marini M，Morgan C．Building the operational data
store．DB2 UDB IBM Redbook，2001
4 Kimball R．Relocating the ODS．DBMS Magazine，1997(10)
5 lnmon B．The operational data store．1nfoDB Magazine，1995(2)

数据仓库分层之辩

来源：nisjlvhudy的专栏

数据仓库的分层可以算是数据仓库架构的子话题。在前段时间参与的一次讨论中，笔者发现其中争论的焦点集中在每一层的作用、特点、是否有必要存在等问题。其中，大家虽然一致提到某些相关概念，但各方的理解却并非完全一致。例如对于ODS是什么、维度建模是什么等问题的解读，都是如此。
不妨想想看：数据从分散而异构的数据源中长途跋涉，到最终的报表、仪表盘、OLAP应用等等，让用户看到一致的结果，这是一个过程。记得以前有个矿泉水广告，说要经过N层的过滤才得到了那种水。而数据仓库也一样，从原来乱七八糟的数据到交付到用户手中的“纯净”数据，也需要这样一个过滤过程，需要各种不同的过滤装置。
这个过滤过程，我们可以称之为ETL；而那些过滤装置，就可以看作数据仓库的分层。从目前来看，还没有非常统一的分层方法，其中，Inmon和Kimball是最具代表性的两种分层方法。

Inmon与Kimball

在Inmon提出的CIF（Corporate Information Factory，企业信息工厂)中，他将ODS（Operational Data Store，操作型存储）、EDW（Enterprise Data Warehouse，企业数据仓库）、DM（DataMart，数据集市）区别开来，共分三层。相对于此，Kimball的总线架构强调多个数据集市合成了数据仓库，只是他们基于统一的维度而已。因此，总线架构的分层中，从数据源接口就直接到了DM了。
根据这两种思路，又可以衍生一些不同的方法。例如IBM就提出一种CDW的概念，叫做企业数据仓库层，这一层介于EDW和DM之间，起过渡作用（因为EDW和DM两层的建模理念是不同的）。
除了这些分层，大家都还认同一个Staging Area（集结地）的地方。这是用于ETL过程中数据的临时存储，可究竟这个区域是位于接口到ODS之间，还是ODS到DW之间，或是CDW到DM之间，并没有达成一致的意见。在笔者看来，既然它是用于ETL中间数据缓存的，那么，在以上每一层都会需要，它是一个每层共用的存储区域。

ODS层与DW层

对于ODS层，一般大家都能够认同它是一种操作型比较强的、未保留历史或者保留近期历史的数据。所谓操作型，是相对分析型而言的。后者多是汇总的、便于分析统计的结构。操作型的另一个特点就是经常会被更新，而分析型数据很少如此。然而，对于ODS的认识，也有不同。
常见的争议包括： ODS是否应该被最终用户访问？ODS存在的目的是仅仅供DW层获取经过清洗的数据，还是能够让用户从中得到统计报表？关于前一个问题，在笔者以前做经营分析的时候，就曾遇到这样的争议；关于后一个问题，如果让它仅仅具备前一项功能，倒是结构清晰、易于管理，是一种好的设计风格，但恐怕不能满足用户灵活的需求。而如果可以让用户查询统计，可能造成它统计的数据和DW统计的数据不一致。
对于DW层，一般大家都会认同，这是保留历史数据的地方。但它是按照第三范式还是维度建模呢？当然，最大的不同就是：是需要一个中心DW，还是一个由若干数据集市组成的“虚拟”的DW。至于DM层，对此基本有一致的认同，这是面向最终用户分析统计的，采用维度建模再好不过。
可因为对DW层建模方法的不同观点，因此也就出来了所谓CDW的提法。想想，如果DW是按照第三范式建模，而DM是按照维度建模的话，那么它们之间该如何过渡？看上去，CDW确实也有存在的必要，在这个区域，需要形成满足总线架构所需的一致性维度（Confirmed Dimension）和一致性事实（Confirmed Fact）。
但问题是，第三范式和维度建模难道就真得水火不相容？笔者更相信一个道理—架构中没有绝对的设计原则。所谓第三范式，只是指出一种理想的ER（实体-关系模型）设计模式，但实际做设计时，设计师大多会去做一些平衡，他们也许会说，“为了性能、应用方便，会考虑适当的冗余。”可这适当冗余不也就破坏了第三范式吗？而且这个“适当”谁也说不准是多少。因此，可以理解EDW并不是绝对的第三范式，而所谓维度建模又能够和第三范式有多少冲突呢？在其本身概念里面，星型模式是一种不太符合第三范式的ER结构，但只是不“太”，如果改成雪花模式，是不是也就是第三范式了呢？

名词与真义

具体要采用哪种分层方法还得视项目大小而言。对于大项目，或是大的集成商来实施，恐怕多会采用复杂的分层方法。其实分层越细，每层的功能也就越单一，它们之间的耦合程度也就越单一。当然这也是需要衡量的，因为分层多了，ETL过程自然也就复杂，那对于数据质量的控制也就变得麻烦——在多个层里面可能都存在同样意义的数据，需要保证它们是一致的。
像IBM、NCR这样的厂商，他们大多走的Inmon路线。经过多年的经验总结，都已有自己的企业概念模型，这也非常适合走分层明确、具有中心数据仓库的路线。在Inmon的体系中，EDW是按照第三范式建模的。之所以要强调这种思想，是因为第三范式能够让数据模型变得简洁、高度一致性。对数据仓库的一个目的——统一口径（Single Version of Truth），是非常有帮助的。
另一方面，Kimball的维度建模理论，即按照事实表、维表来构建数据仓库、数据集市，也已经在很多实践中被证明是非常有效的方法。可这种建模方法和第三范式多少有点冲突。例如在维表中，不同粒度的数据放在一种表里面，即存在大量的数据冗余。但这种方法对数据仓库四大特点之一的“面向主题”，又是有利的。
如此看来，大家提到的方法似乎都是从不同角度去看，没有绝对的对错，只是在为维护自己的观点而争论。具体采用何种分层，还得看项目投资大小、数据量多少以及业务逻辑复杂程度而定吧。
说句题外话，或许当概念太多的时候，我们最应该做的就是要抛开那些容易混淆视听的名词，去探察其真正的意义所在。