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

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

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

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

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

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

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

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

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

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

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

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

QUOTE:

---

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

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

---

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