带你看透数据仓库的演变史 _数据仓库

文|傅一平

2004年笔者进入公司后就从事数据仓库的工作，伴随着中国移动经营分析系统的发展而成长，主导过多次数据仓库的重构建设，见证了数据仓库从ORACLE到DB2、从DB2到ASTER、从ASTER到一体机、从一体机到GBASE、从GBASE拓展到Hadoop、再从Hadoop演进到实时数据仓库的历程。
这其中不仅仅有技术和认知，也有自己的故事，但时间就像一个沙漏，会让存封的记忆变成没有记忆，在沙子漏光之前，笔者还是想努力做些回忆，将其中的片段串起来分享给大家。
一、2004年，Oracle的美好小时代2004年毕业进公司的时候，那个时候还没有所谓的高大上的数据仓库，公司仅仅有个基于小机的Oracle报表数据库，主要服务于公司的报表和取数。由于CRM/BOSS等源端系统都是Oracle数据库，因此ETL是极其简单的，直接DBLINK 。
DBLINK在那个时代真是太强大了，也真是太方便了。
每次公司业务增加了一个数据库，我们就会要求DBA给我们一个取数用的数据库账号，然后建个DBLINK就可以直接取数了（后来被禁止了，因为影响源端的稳定性），也可以在凌晨基于DBLINK抽取源端数据到报表库后再取数。
你会发现那个时代我们的取数脚本往往会出现数不清的@jf，@zw，@kf，jf是计费数据库的意思，zw是账务数据库的意思，kf是客服数据库的意思，看看下面这个配置脚本是不是很熟悉？

文章插图

如果Oracle一统天下，ETL就失去了意义，数据湖这个概念都不好意思提出来，因为没有意义。Oracle DBLINK就是简约而不简单的代名词，其生命力之强大令人发指，这是真正的技术集约化提升生产力。
即使到今天，我们的数据集市还留有源端系统的DBLINK后门，因为数据获取快捷实时，可以小而美的解决一些问题，当然源端业务数据库变成了BC库或者容灾库，虽然DBLINK备受耦合的骂名。
那个时候还没有建模的概念，但公司的报表、取数前辈已经基于实践沉淀出了很多汇总表和宽表，当你的公司业务不够复杂、数据量还不够大的时候，谈关系建模，维度建模都没什么意义，前辈创建的中间表就是一切，只要能快速的满足报表取数需求。
有了DBLINK和宽表，那么Oracle时代最强大的Pass是什么呢？
当然是PL/SQL Developer这个集成开发工具，其是专门开发面向Oracle数据库的应用，PL/SQL叫做过程化SQL语言（Procedural Language/SQL），是Oracle数据库对SQL语句的扩展，其在普通SQL语句的使用上增加了编程语言的特点，比如把数据操作和查询语句组织在PL/SQL代码的过程性单元中，通过逻辑判断、循环等操作实现复杂的功能或者计算。

文章插图

直到今天我们的大数据开发管理平台的很多设计理念都是直接借鉴 PL/SQL Developer 。每次我都会对DACP的产品经理说，学习下 PL/SQL Developer的功能和体验，直接抄也行啊，大多也源于我对PL/SQL Developer的感情吧，不过它的确太优秀了。
这里贴一段以前做ALL表时的SQL代码，各种decode，我的代码生涯至少做过3000个类似的脚本。

文章插图

再贴一段以前的存储过程代码，也很方便。

文章插图

即使是现在，只要企业的源端数据库没有去O，Oracle作为数据集市来讲也是非常合适的，况且Oracle的一体机一点不含糊，应对一般的报表取数绰绰有余。
二、2005年，DB2开启了数据仓库时代在我进入公司的那一年，中国移动轰轰烈烈的经营分析系统1.0建设已经开始了，关于数据仓库采用Oracle还是DB2当时存在路线之争。
建议用Oracle其实是非常务实的，因为Oracle的生态非常好，大家也都用习惯了，当然相对保守一点。
建议用DB2的则认为从全球来看其在数据仓库领域占据领先位置（其实还有Teradata），而且Oralce毕竟不是为分析系统量身定做的，所谓OLTP和OLAP的区别。大家都会举一个例子，DB2的count统计非常快。
我当时看到DB2这么好的性能也挺惊讶的，觉得用DB2是正确的选择，但后来发现如果从使用的全流程体验来看，ORACLE性价比还是很高的，特别是当你的技术保障能力没跟上的话，DB2就是个坑。
但无论如何，我们还是踏上了与DB2相伴的10年，爱恨情仇。
公司的第一代数据仓库建设笔者赶上了末班车，数据仓库采用的是2台IBM P595+DB2软件，OLAP采用的是Hyperion Essbase（现在被Oracle收购了），BI报表是Brio，数据挖掘软件采用的是IBM Intelligence Minner8.1 。