这个项目在年前已经完成,回顾起来小问题挺多。有点乱。还是从需求说起。
一.单纯讲需求每个行业的都不同。很难划一而论。总体来说也就是这几个方面
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