相伴十六载，讲讲我和数据仓库的故事（一）

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。

昂贵而牛逼的P595

1、数据仓库DB2

从实际使用情况看，如果说Oracle是个热情的小伙子，那么DB2肯定是个冷冰冰的小姑娘。
首先是性能，DB2跑汇总、关联分析的确快，但它的并发不行，因为资源独占太厉害，而且对错误的容忍度低，一不小心写错脚本就会跑挂机器，对于开发人员要求很高。
其次是ETL，自从引入了DB2，我们就开始体会ETL的繁琐和痛苦，源端的Oralce要转化成文本，再load进DB2，你得为他配备周边的工具，大多要量身定做。
再次是可用性，DB2的RAC其实没啥卵用，一个节点挂了切换到另外一个节点经常出现问题（记得不会自动切换），而且即使切换过去了性能下降起码一半，实用性差了。
但无论如何，DB2的确是很稳定的，几年都可以不出问题，但出了问题你就只能去烧香了。
从技术保障的角度来看，DB2 DBA属于稀缺人才，只能慢慢培养，有大问题就得从上海，广东调国内仅有的几个IBM db2专家过来解决问题，最怕的是他们也搞不定，只能层层打报告找美国实验室的专家来解决，协调成本很高，这个以后再讲。
最后是应用，DB2的技术特点决定了不大可能直接开放给一线人员使用，一来并发高了性能就大幅下降，二来代码要求太高，一不小心搞塌机器，这个谁也吃不消。
DB2也没有好用的开发管理工具，本身自带的就不说了，好不容易找到了一个叫Quest的第三方客户端工具，也是功能不全，然后我们重新开发了一个客户端。
用惯了Oracle SQL的人再转到DB2的一板一眼的SQL，那真是欲仙欲死，学习成本太高了，取数的效率直线下降，因此基于Oracle的数据集市就兴旺起来。
我们的数据仓库从一开始其实就处于DB2和ORACLE共存状态，核心仓库模型跑在DB2上，而大部分乱七八糟的应用数据全部跑在ORACLE上，所谓的数据集市，包括报表库、政企库、地市库、市场库等等。
DB2是娇贵的，Oralce是坚韧的。

2、BI工具Brio

我们长期使用Brio报表工具生成报表，围绕Brio做了大量定制化的服务。

以前Brio报表数据的刷新是定时的，定时在9点刷新，即使数据在6点生成好了也没用，有个合作伙伴的小伙子就把触发式的刷新功能做出来了，厉害得很，后来跳槽了，现在在腾讯做到很高的职位。
还有就是财务部门希望每月定时把一大批报表自动导成excel推送给他们，因为要的报表太多了，不希望登录到报表门户一张张点开处理，这个时候就要brio做批量生成excel的功能。
笔者以前在文章中说，BI近年来没多少长进，是指没有发生什么革命性的变化，诸如brio等早期的BI工具还有自身的特点，比如报表数据以bqy的文件方式存储，你可以随意下载和拷贝，不需要登录什么服务，在任何一台有brio客户端的电脑都能打开，然后做各种线下的拖拉钻取报表操作。
我们也引入过BO等水晶报表工具，由于不习惯放弃了，最后连Brio也不用了，完全自己定制开发，原因以后再说。

3、OLAP工具Hyperion Essbase

虽然那个时候企业购买了Hyperion Essbase，但对于Essbase的评价就是一句话：曲高和寡，主要体现在二个方面：
第一，多维分析不是企业使用的主要场景，有限维度的报表才是刚需，那个时候企业真正使用OLAP的人员不超过5个，这样引入的OLAP的性价比就很低了。
第二，OLAP的确会快很多，但OLAP发布和维护的工作量有点大，比如在发布前，要有专门人员去设计CUBE打CUBE，如果增加了新维度还要重新打过，比较繁琐。
OLAP在当时属于那种叫的很响亮，但实际用得不咋滴的先锋产品，生不逢时吧。

4、清晰的三层体系架构

第一代的数据仓库体系架构如下图所示，分为数据获取层、存储层和访问层。

数据获取层：将BOSS、MIS等外部数据源的数据进行清洗、转换和加载到数据仓库，关于ETL也有路线之争，其实我们真正做的是ELT，复杂的转换全部是在库内完成的。而且我们的ETL还有一个后门，就是数据集市Oracle直接通过DBLINK获取源端数据，隐患还是挺大的。

数据存储层：实现对数据仓库中数据和元数据的集中管理，即DB2，并根据需要建立面向部门的数据集市（老的报表库退化为数据集市），数据集市和元数据这么早提出来也是非常有先见之明的，当然也只是提出而已，并没有完全落地。
数据访问层：通过多样化的前端展现工具，实现数据的分析，形成市场经营和决策工作所需要的业务信息和知识，采用的就是前面所说的Brio工具。

5、业务为王的九大主题

数据仓库的第一个特点是面向主题(Subject Oriented)，中国移动经营分析系统业务规范1.0版本开篇所说的话很好的诠释了对主题的理解：
“为适应日趋激烈的市场竞争环境，提升中国移动的企业核心竞争力，应充分利用业务支撑系统产生的大量宝贵的数据资源，建立移动经营分析系统，实现对信息的智能化加工和处理，为市场经营工作提供及时、准确、科学的决策依据”
“本业务规范包含对中国移动经营分析系统过的总体说明、基本层次结构、系统功能、专题分析、系统管理、外部系统的接口、指标要求等方面的内容，从功能上涵盖了客户发展分析、业务发展分析、收益情况分析、市场竞争分析、服务质量分析、营销管理分析、大客户分析、新业务及数据业务发展分析、合作服务分析九大主题”
这九大主题对于移动业务的抽象和概括是相当的全面和精准，非常具有前瞻性，后面所有的领域模型、逻辑模型、物理模型都是围绕这九大主题展开的。

关于模型设计自己没机会参与，因为刚进公司，啥都不懂，记得参加过几次项目例会（亚信是当时的集成商），印象最深的就是亚信北京研发的数据模型专家在那边讨论模型的设计方案，还有跟局方的争论，一些新的名词不停的跳出来，什么erwin、概念模型、逻辑模型、物理模型、ER图，PDM等等，自己一头雾水。
下图是中国移动业务的概念模型。

下图是其中的事件主题的逻辑模型。

第一代数据仓库的建设持续了一年多，其实跟我没多大关系，只有使用上的一些体会，九大主题建设完成后最大的感受是可以用BI工具看报表了，但九大主题使用的人并不是很多。
现在很容易想明白原因，因为第一代数据仓库基本还是技术驱动，虽然经营分析系统规范有集团公司的顶层业务规划，但到了省公司业务人员参与度就低了，规范如何跟本地业务相结合一直是数据仓库的巨大挑战。
但无论如何，2005年是值得庆祝的一年，因为我们的数据仓库起航了，从0到1总是有很大的意义。

作者：傅一平 （微信号：frank61822702）