关于数据仓库 — ODS概念
ODS是一个面向主题的、集成的、可变的、当前的细节数据集合，用于支持企业对于即时性的、操作性的、集成的全体信息的需 求。常常被作为数据仓库的过渡，也是数据仓库项目的可选项之一。
根据Bill.Inmon的定义，“数据仓库是面向主题的、集成的、稳定的、随时间变化的，主要用于决策支持的数据库系统”
ODS是一个面向主题的、集成的、可变的、当前的细节数据集合，用于支持企业对于即时性的、操作性的、集成的全体信息的需 求。常常被作为数据仓库的过渡，也是数据仓库项目的可选项之一。
在Kimball的，他是这样定义的
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所不同的是，这时的细节数据不是“当前、不断变化的”数据，而是“历史的，不再变化的”数据。这样的数据仓库的存储压力和性能压力都是比较大的，因此对数据仓库的物理设计和逻辑设计提出了更高的要求。

ODS区是否应该存在一直都有争论，建设银行的数据仓库项目起初就没有ODS区也一样用了，只不过后来发现还是有ODS比较好的，但是又存在了ODS是否逻辑存在，物力不落地，如果落地落几次地等一系列的问题。眼前的几个数据仓库项目倒是都用了ODS。

建行怎么发现用ODS比较好呢？另外，国家开发银行的KM的ETL是用ODI实现的么？

因为现在负责DW建设，感觉到整体架构的重要性。感觉Staging Area对于我们这样多个系统的情况比较合适，而ODS对于我们OLTP功能欠缺、DW前景不明朗的情况下也比较合适，DMart则比较适合我们这种组织文化。但是，要考虑整体投资，所以只能在具体落地产品方面看能否有满足相关要求的。

好担忧乙方能不能经受住这样的考验。

建设银行的DW是NCR的金融模型，是基于分析主题域来做的，而真正业中还需要基于业务主题的数据，STA区仅仅是从生产系统中获得一个份静态的数据，基本上很少做加工，无法提供业务主题的数据。 在建设银行的DW项目运行了一段时间以后，终于意识到还是应该有ODS的，但是怎么构建ODS，则存在很大的争议。

建行的领导班子，偶还是很佩服的，精明强干，绝不是i那种吃闲饭的，他们在厦门的开发中心，针对DW项目有专门的ODS组、模型组、ETL组等，投入的人力也很大。现在ODS项目正在运作，看看过两年的成果吧！

开发银行的KM系统是好几年前建设的，ETL工具简单的部分是使用OWB，难点的地方都是使用手工代码，这套系统已经有点老了。
新的数据平台项目一共有STA，ODS、DW、DM四个部分组成，ETL部分使用的Informatic，起到主要的元数据管理的作用。
建行的ODS如何构建的争议主要体现在哪几方面？

建行的ODS是怎么定义的呢？如果是要“提供业务主题的数据”，我会考虑再建DW或对应的DMart。尽管这么安排投资是上去了，但却能够统一思想，快速务实解决实际需要。因为银行在业务方面的需求相对来说是比较明确的，而不象我们这里；正因此，时间赶上去了，投资上去点也是可以理解的。

另外，对于开发组织模式，除了分析/设计、开发/部署、维护/监控这样的组织模式之外，是否还有其他的组织模式？因为我对这种组织模式的项目了解之后发现有很多的管理问题。相关的技术衔接问题也在电信的ODS项目中出现过，尤其是非一家建设以及建设目的中包含非技术目的的情况下。

对于开发银行的项目，最关注的是其元数据管理部分的内容。能否简要定义一下其元数据概念以及元数据管理内涵？对于我来说，由于要处理多个系统，所以对元数据的定义及其管理范围的界定非常重要，也非常困难。如果处理得当，可以基于MME采用新型工具来做ETL，而且更可管理——我希望如此；但也要看乙方有没有这个能力。

不好意思，又问了这么多问题。我是非常希望能多跟各位学习的。
我的妈呀，又这么多！
建设银行的ODS的问题主要集中在：ODS区内需要划分几个层次，每个层次所实现的功能，哪个层次逻辑存在，哪个层次数据落地。如果落地，落地几次。 建设银行由于已经有了DW区，提供的是分析型的数据，但是很多系统还需要给予业务的数据，这个时候发现DW不能满足要求，必须能够提供基于建设应行业务的主题数据。
业内在金融方面一般都采用埃森哲、NCR、IBM的金融模型，主体无非关注7-9个：个人、团体、产品、地域、信用...

业务主题模型主要是在ODS里实施的，不是在DM里实施的。

在我与国外专家的交流过程中，国外专家对数据仓库项目是这样理解的：数据仓库项目在国外如果按着前期标书的预期结果，成功率只有20%，少的可怜，但是在实施的过程中能够将客户的业务规范化，能将客户的海量数据规整化，建立起指标体系，清除大量垃圾数据，那就是成功。

建设银行的ODS项目一共划分为以下几个组：
Accessment（这个词我不知道怎么翻译）
System
Data
Etl
Methods
Metadata
Cm/deployment


元数据方面：元数据分为两种——业务元数据和技术元数据。
业务元数据是技术元数据的主要依据，业务元数据是长期的业务理解、业务变化，需要客户业务主干确定业务的关系，形成文件。需要与多个业务人员进行业务交谈，通过不同层次的理解来收集业务数据。业务元数据专家建议使用BO或者Cognos这种前端产品来实现，BO（语义层）、Cognos（业务视图层）。或者自己单独开发一套系统来管理业务元数据。

主题域模型的趋向：一种是趋向于源系统模型，一种是趋向于目标系统模型。主体域的模型划分：一种是业务主体域的划分，一种是产品主体域的划分。

对于技术元数据则是通过ETL工具来实现，建设银行主要使用Datastage，技术元数据主要是在血统继承，元数据改变、对比上起作用。