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

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

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

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性能的关键。