当前位置：首页 → 问答吧 → 关于数据仓库 — ODS概念

关于数据仓库 — ODS概念

时间：2006-12-16

来源：互联网

ODS是一个面向主题的、集成的、可变的、当前的细节数据集合，用于支持企业对于即时性的、操作性的、集成的全体信息的需求。常常被作为数据仓库的过渡，也是数据仓库项目的可选项之一。

根据Bill.Inmon的定义，“数据仓库是面向主题的、集成的、稳定的、随时间变化的，主要用于决策支持的数据库系统”

ODS是一个面向主题的、集成的、可变的、当前的细节数据集合，用于支持企业对于即时性的、操作性的、集成的全体信息的需求。常常被作为数据仓库的过渡，也是数据仓库项目的可选项之一。

在Kimball的<<数据仓库生命周期工具集The Data WareHouse Liftcycle Toolkit>>，他是这样定义的

1. 是操作型系统中的集成,用于当前，历史以及其它细节查询(业务系统的一部分)

2. 为决策支持提供当前细节数据(数据仓库的一部分)

因此操作数据存储（ODS）是用于支持企业日常的全局应用的数据集合，ODS的数据具有面向主题、集成的、可变的和数据是当前的或是接近当前的4个基本特征。同样也可以看出ODS是介于DB和DW 之间的一种数据存储技术，和原来面向应用的分散的DB相比，ODS中的数据组织方式和数据仓库（DW）一样也是面向主题的和集成的，所以对进入ODS的数据也象进入数据仓库的数据一样进行集成处理。另外ODS只是存放当前或接近当前的数据，如果需要的话还可以对ODS中的数据进行增、删和更新等操作，虽然DW中的数据也是面向主题和集成的，但这些数据一般不进行修改，所以ODS和DW的区别主要体现数据的可变性、当前性、稳定性、汇总度上。

由于ODS仍然存储在普通的关系数据库中，出于性能、存储和备份恢复等数据库的角度以及对源数据库的性能影响角度，个人不建议ODS保存相当长周期的数据，同样ODS中的数据也尽量不做转换，而是原封不动地与业务数据库保持一致。即ODS只是业务数据库的一个备份或者映像，目的是为了使数据仓库的处理和决策支持要求与OLTP系统相隔离，减少决策支持要求对OLTP系统的影响。

为什么需要有一个ODS系统呢？一般在带有ODS的系统体系结构中，ODS都具备如下几个作用：

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

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

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

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

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

一般来说，带有ODS的数据仓库体系结构中，DW层所存储的数据都是进行汇总过的数据和运营指标，并不存储每笔交易产生的细节数据，但是在某些特殊的应用中，可能需要对交易细节数据进行查询，这时就需要把细节数据查询的功能转移到ODS来完成，而且ODS的数据模型按照面向主题的方式进行存储，可以方便地支持多维分析等查询功能。即数据仓库从宏观角度满足企业的决策支持要求，而ODS层则从微观角度反映细节交易数据或者低粒度的数据查询要求。

在一个没有ODS层的数据仓库应用系统体系结构中，数据仓库中存储的数据粒度是根据需要而确定的，但一般来说，最为细节的业务数据也是需要保留的，实际上也就相当于ODS，但与ODS所不同的是，这时的细节数据不是“当前、不断变化的”数据，而是“历史的，不再变化的”数据。这样的数据仓库的存储压力和性能压力都是比较大的，因此对数据仓库的物理设计和逻辑设计提出了更高的要求。

作者: bq_wang 发布时间: 2006-12-16

我觉得对这些细节, 现在还有很多争论, 所以大家要多看看实际项目的处理解决方案. 比如ODS, 可以是作为实时BI的, 而有很多项目是不用ODS作为更多前端应用的.比如很多报表\查询功能不是通过ODS的, 而是通过数据仓库或者数据集市. 而有的数据仓库也保留了低粒度的数据以供查询, 而并不是这些留给ODS去做.

有的项目ODS的集成程度都没有数据仓库/集市高, 并没有汇总多个系统数据,那么也就以为着不能提供复杂的查询,于是很多项目ODS只提供少量的前端服务.

我想楼主的这些知识可以给初学者一些参考, 可不能作为教科书呀,呵呵

作者: innovate511 发布时间: 2006-12-17

一直认为ODS不是必须的，要依据需求而定。

作者: 神呐救救我发布时间: 2006-12-18

关注。。。

作者: mountainshu 发布时间: 2006-12-19

QUOTE:最初由神呐救救我发布
一直认为ODS不是必须的，要依据需求而定。

视情况而定，一般说的数据仓库都有多个数据源，数据源多而复杂的话，最好还是用ODS过渡。

作者: innovate511 发布时间: 2006-12-19

QUOTE:最初由神呐救救我发布
一直认为ODS不是必须的，要依据需求而定。

ODS本来就不是必须的啊

主要看dw的粒度是怎么定的，业务需求是怎么样的

作者: NinGoo 发布时间: 2006-12-19

第一句话，就说了ODS是数据仓库项目的可选项之一！

ODS是一个面向主题的、集成的、可变的、当前的细节数据集合，用于支持企业对于即时性的、操作性的、集成的全体信息的需求。常常被作为数据仓库的过渡，也是数据仓库项目的可选项之一。

作者: bq_wang 发布时间: 2006-12-19

想了解一下ods在保持实时性方面是怎么实现的

是业务系统完成ods的加载呢，还是做一个接近实时的etl过程，或者其它一些方法？

作者: gary_yang2002 发布时间: 2006-12-19

呵呵，这个问题问得好！
保持实时性有很多种办法
1、利用数据库的特性，Oracle的logminer，SQLServer的分发订阅都可以实现，本质上都是通过数据库的日志分析来完成的。许多ETL工具即利用数据库的特性来实现实时操作。
2、Oracle数据库的话有standby方式，也可以认为是一个ODS数据库，即脱离联机在线OLTP的功能，达到数据整合的目的就行了。
3、Oracle的物化视图方式，也可以实现实时性的目的。当然也有一定的延迟！
4、准实时性的，就是普通的ETL抽取，1小时~1天不等的进行数据的定期抽取！

下面有篇不错的英文文章可以供参考一下：
变化数据捕捉的一些方法的总结
http://www.itpub.net/showthread.php?s=&threadid=649241

QUOTE:最初由 gary_yang2002 发布
想了解一下ods在保持实时性方面是怎么实现的

是业务系统完成ods的加载呢，还是做一个接近实时的etl过程，或者其它一些方法？

作者: bq_wang 发布时间: 2006-12-19

我们当前的这个项目中,有HDS,ODS,DDS,
其中HDS是直接从源数据来数据.可是从HDS到DDS的时候已经开始做了一些转换了.
这和楼主说的DDS概念是不是有点违背。
不过如果按上所说ods是直接从数据源业数，那么转换在哪里做呢？
请教

作者: folkstone 发布时间: 2006-12-20

在ODS前可以有一个数据暂存区，即为了避免与业务数据库的直接交互，而是用一些平面文件，XML文件，临时表，之类的。
实际上在数据仓库项目中，数据暂存区、ODS、数据集市，数据仓库区，这四项都并非必选的；后面的三项只要拥有一项，就可以认为是数据仓库了。
而他们的转换也并非局限在一点上，要视乎业务需要和所设计的框架而定！
仅是个人看法，请指正，

作者: bq_wang 发布时间: 2006-12-20

我在ttnn google群里把数据仓库和建筑业做了形象的比较。

在我们看来，很多简单的建筑，比如农舍，这些甚至根本不需要钢筋水泥就可以建起来。而类似摩天大厦的建筑，光是钢筋水泥这些建筑材料是不行的了，需要设计其架构，地基要打好，然后内部房间布置和装修规范，然后运用规范的建筑建设思路去建筑，才能建成稳固的摩天大楼。

同样，数据仓库小到你只分析一个星型模型，数据上千条，你可以用my sql都没关系，而业务庞大的世界500强企业或者中国、美国这样大国的国家级数据仓库，就必须从选材到项目架构设计、模型设计、开发、测试流程、项目管理各个层次都要做好才行。那么这种大型项目目前使用“材料”，也就是我们的数据库就很有讲究了，超大型项目使用teradata, DB2的多点，其次Oracle, SQL\Sybase的比较少了，使用my sql的可能没有。

然后就是物理架构设计和逻辑架构组织，其中物理架构就是厂家常宣传的XX数据仓库解决方案，主要是如何是数据库效率更高，稳定性更好。而逻辑架构则需要项目实施者自己去根据实际情况设计，一般几大常见的组织结构一个都不会少，甚至会多出一些中间层在常见组织结构中作为过滤和缓冲，提高项目稳定性和效率。从另一角度看，对开发和测试的要求也会高很多，这和建筑业的摩天大楼的建设地位是一样的，各个细节一个都不能少。同样，如果是简单的项目，就如你搭建一个农舍似的，焉需用牛刀，就不需要打什么地基了吧？

作者: innovate511 发布时间: 2006-12-20

比喻很形象，很贴切啊，一切由业务驱动！

作者: gary_yang2002 发布时间: 2006-12-20

个人倒是认为不管草舍也好，摩天大楼也好，框架都是一样的，地基、骨架、外面的耗材、装修等等都应该有，也就是说流程是一样的，草舍可以作适当的裁减，地基不用那么多东西、骨架不用钢材等等，甚至不用装修也可以。

作者: bq_wang 发布时间: 2006-12-20

感觉还是斑竹有水平，阐述的比较通彻和全面

作者: jiew9404202 发布时间: 2007-03-12

我一直将ods层，理解成staging area层和数据仓库层的一种过渡，具有两个层的一些特点又不同于任何一个层，满足一些两个层无法实现或者说是实现起来很麻烦的一些功能。

作者: zzy_911_78 发布时间: 2007-03-12

其实需要统筹考虑的，ODS可以作为EDW的补充和支持
在规划EDW的时候，应该合理考虑ODS的地位和作用

作者: zhonghua936 发布时间: 2007-05-25

这个东西可以细分的,视需求而定,如果数据源非常复杂,需要多步转换的,可以用ods,甚至hds,也有比较简单,直接从业务系统经过转换直接进dw的.

作者: xx_adam 发布时间: 2007-05-26

个人认为判断DW是否需要ODS有两点：
1、数据源太复杂。
2、客户需要实时报表。
曾经碰到过要求在数据仓库出实时报表的需求。我们就是通过建立ODS，且通过消息中间件建立ODS与数据源连接，实现数据实时同步的

作者: davidhealth 发布时间: 2007-05-28

**********************************************************
具体实践的例子吗？
而且这个实时性的完成，是否会牺牲较多的性能那？还是说这个损耗比较小，可以忽略不计

作者: 0yingzi0 发布时间: 2007-05-29

[QUOTE]最初由 innovate511 发布
我在ttnn google群里把数据仓库和建筑业做了形象的比较。

在我们看来，很多简单的建筑，比如农舍，这些甚至根本不需要钢筋水泥就可以建起来。而类似摩天大厦的建筑，光是钢筋水泥这些建筑材料是不行的了，需要设计其架构，地基要打好，然后内部房间布置和装修规范，然后运用规范的建筑建设思路去建筑，才能建成稳固的摩天大楼。

同样，数据仓库小到你只分析一个星型模型，数据上千条，你可以用my sql都没关系，而业务庞大的世界500强企业或者中国、美国这样大国的国家级数据仓库，就必须从选材到项目架构设计、模型设计、开发、测试流程、项目管理各个层次都要做好才行。那么这种大型项目目前使用“材料”，也就是我们的数据库就很有讲究了，超大型项目使用teradata, DB2的多点，其次Oracle, SQL\Sybase的比较少了，使用my sql的可能没有。

然后就是物理架构设计和逻辑架构组织，其中物理架构就是厂家常宣传的XX数据仓库解决方案，主要是如何是数据库效率更高，稳定性更好。而逻辑架构则需要项目实施者自己去根据实际情况设计，一般几大常见的组织结构一个都不会少，甚至会多出一些中间层在常见组织结构中作为过滤和缓冲，提高项目稳定性和效率。从另一角度看，对开发和测试的要求也会高很多，这和建筑业的摩天大楼的建设地位是一样的，各个细节一个都不能少。同样，如果是简单的项目，就如你搭建一个农舍似的，焉需用牛刀，就不需要打什么地基了吧？ [/QUOTE

呵呵,你不懂建筑业,别在这个用BI和建筑业比较,这样会玷污建筑业.我父亲从事建筑施工50多年,我兄长20多年,我太太从事建筑结构设计(就是你所说的物理架构设计和逻辑架构组织)10年.建筑业是所有行业最规范的行业. 你的说法在建筑业刚好相反,摩天大楼首先是建筑师按照业主方要求和艺术结合的杰作,然后是结构师根据建筑师的设计,并根据土质报告,地区环境等做结构设计,并在结构设计中指定材料范围,最后交给施工方来施工.而这个摩天大楼整个项目经理肯定是建筑师担任.

你别不懂建筑,就用建筑的流程来比较BI,太搞笑.

作者: interstage 发布时间: 2007-05-30

唉,看不懂啊

作者: 是我还好呢发布时间: 2007-05-30

呵呵, interstatge 对建筑业流程阐述的很明白，受教了

ODS 作为stageing, 是面向对象的、整合的、集成和可变的,

可能要具体内容具体分析,没有太严格限制,看业务要求和关注的角度了

呵呵,个人体会而已,多指教

作者: pastime_Wang 发布时间: 2007-05-31

作者: irenetongying 发布时间: 2007-07-04

问个菜鸟问题：
ODS和datamart有什么区别，是不是根据存储数据的粒度来划分的

作者: taloyoung 发布时间: 2007-07-05

阶段不一样,范围不一样,目的不一样

粒度也不一样

作者: bq_wang 发布时间: 2007-07-05

受教了，以前就曾经有过教训，为了满足一些实时细节业务报表的需求，在DW设计中粒度设置过细，导致性能发生很大问题。

作者: ls17 发布时间: 2007-07-05

去研究一下SAP BW的ODS就知道了.

SAP BW 3.5 稱為ODS

SAP BI7.0 稱為DSO --- Data Store Object.

ODS這東西, 沒有定式. SAP把其功能擴展了.在BI7.0中有三種
DSO

1-- Standard ODS (用於數據統合一致,也用於after image的數據源的增量抽取)
2-- Transaction ODS (主要用於Datar Mart, 也能使用與Report)
3-- Optimizer ODS
(主要用與寫入數據用的,優化data load 性能,但有能產生即時的Report)

作者: wrkskl 发布时间: 2007-09-20

QUOTE:最初由 bq_wang 发布
个人倒是认为不管草舍也好，摩天大楼也好，框架都是一样的，地基、骨架、外面的耗材、装修等等都应该有，也就是说流程是一样的，草舍可以作适当的裁减，地基不用那么多东西、骨架不用钢材等等，甚至不用装修也可以。

赞同，按标准流程建设，可能会慢，但利于将来扩展

作者: 神呐救救我发布时间: 2007-09-21

ODS，DM，EDW怎么搞都行
只要客户给钱！

作者: andy心晴发布时间: 2007-09-21