这个项目在年前已经完成，回顾起来小问题挺多。有点乱。还是从需求说起。

   一.单纯讲需求每个行业的都不同。很难划一而论。总体来说也就是这几个方面

   1.时间窗 

    常见的分类也就1类ODS ,II类ODS ，III类ODS

     I类ODS：与应用系统的数据延迟为1~2秒，实时或近似实时

     II 类ODS：与应用系统的数据延迟为2~4小时

    III类ODS：与应用系统的数据延迟为12~24小时

    IV类ODS：数据仓库中部分决策分析数据回流至ODS中

   数据实时性越高，越好CPU ，软件成本越高。在 选型时也不同，

  如果确定数据的实时性需要实时同步的话，就是I类ODS，通常需要EAI ，消息队列，消息通信的机制。稍微差点可以用某些数据库的高级功能比如ORACLE 从REDO LOG中抽取，目前支持厂商也不少，下下策就是 使用数据库触发器，工作量挺大的，都是些无聊的重复性代码，重用性也不高。

  II类ODS  这种好像不多了，以前银行转账有几个小时后到账的业务。现在已经很少了，如果硬是建设此类估计 也采用性能更高的III类ODS 的建设。

  III类ODS 这种很常见，常说说的ETL ，也就是批量的数据处理是此类必配的项目。厂商也很多，但是要从易用性，性能，同本地数据库的结合等方面来衡量。

我们采用这种构架。使用基本上也是大厂商的软件ORACLE,IBM等。

  IV类ODS 一般是在ODS数据上，再汇总的数据。做数据分析的朋友，会同此类系统打交道，如SAS，SPSS，R等。

      2.数据量级

      任何数据只要量级上来了，都挺困难。我们做过测试数据量吞吐量 在G 级别的，使用传统的数据库还勉强可以搞定。要是超过这个量级，不管是在ETL，DATAANYLSE 都你不从心。

     需要使用大数据的构架，也不是完全的使用大数据，而是大数据+传统数据库结合的方案。目前我们正在测试这一方案。其中很多构架都要变，更要命的是ETL变得更复杂了，传统的ETL工具很多都没有跟上。

    如果数据量再大要到PB级别，之前的所有的构架都要推倒重来，使用纯粹的大数据构架，这不是一般的公司可以做到的。暂且不谈这个。

    3.数据属性确认

    这个占用了我们在ODS建模（同BI建模类似）的大量工作，

    维数据和事实表数据（日志数据），是我们在业务上没有偏离的重要保证。

    数据来源（JMS，DATABASE，File,EAI ） 其中涉及到处理的不同的技术。

    数据处理（统计，非统计） ：是影响ETL性能的关键。

转：http://www.cnblogs.com/jerryxing/archive/2013/02/20/2918130.html

OLAP -- ODS 项目总结 -- BI 中的关键