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

文章插图
昂贵而牛逼的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工具
笔者现在用的是FineReport和FineBI，这两个大数据分析平台对我们来说完全可以满足需求。
以前我们长期使用Brio报表工具生成报表，围绕Brio做了大量定制化的服务。

文章插图

以前Brio报表数据的刷新是定时的，定时在9点刷新，即使数据在6点生成好了也没用，有个合作伙伴的小伙子就把触发式的刷新功能做出来了，厉害得很，后来跳槽了，现在在腾讯做到很高的职位。
还有就是财务部门希望每月定时把一大批报表自动导成Excel推送给他们，因为要的报表太多了，不希望登录到报表门户一张张点开处理，这个时候就要brio做批量生成excel的功能。
我以前在文章中说，BI近年来没多少长进，是指没有发生什么革命性的变化，诸如brio等早期的BI工具还有自身的特点，比如报表数据以bqy的文件方式存储，你可以随意下载和拷贝，不需要登录什么服务，在任何一台有brio客户端的电脑都能打开，然后做各种线下的拖拉钻取报表操作。
但是现在被敏捷式BI如FineBI和Tableau取代了。
3、OLAP工具Hyperion Essbase
虽然那个时候企业购买了Hyperion Essbase，但对于Essbase的评价就是一句话：曲高和寡，主要体现在二个方面：
第一，多维分析不是企业使用的主要场景，有限维度的报表才是刚需，那个时候企业真正使用OLAP的人员不超过5个，这样引入的OLAP的性价比就很低了。
第二，OLAP的确会快很多，但OLAP发布和维护的工作量有点大，比如在发布前，要有专门人员去设计CUBE打CUBE，如果增加了新维度还要重新打过，比较繁琐。
OLAP在当时属于那种叫的很响亮，但实际用得不咋滴的先锋产品，生不逢时吧。
4、清晰的三层体系架构
第一代的数据仓库体系架构如下图所示，分为数据获取层、存储层和访问层。

文章插图

数据获取层：将BOSS、MIS等外部数据源的数据进行清洗、转换和加载到数据仓库，关于ETL也有路线之争，其实我们真正做的是ELT，复杂的转换全部是在库内完成的。而且我们的ETL还有一个后门，就是数据集市Oracle直接通过DBLINK获取源端数据，隐患还是挺大的。
【带你看透数据仓库的演变史】数据存储层：实现对数据仓库中数据和元数据的集中管理，即DB2，并根据需要建立面向部门的数据集市（老的报表库退化为数据集市），数据集市和元数据这么早提出来也是非常有先见之明的，当然也只是提出而已，并没有完全落地。