关于数据仓库的架构问题

原来曾经在国内某民族巨头通信企业(通过CMM5级认证)工作过一段时间，因厌倦了客户无休止的需求导致程序无休止的修改，也厌倦了某不懂编码博士项目经理无休止的加班要求(一个月只休息了一天)，便走上了BI这条路。

最初的BI知识，是由在公司接受了2周培训的哥们给我培训的，两个人两眼一抹黑便开始某某联通BI的开局工作，对BI知识懵懵懂懂的，还好对SQLServer2000和Oracle我还不陌生，毕竟也用了4、5年的时间做过开发。联通的数据仓库现在看起来并不太复杂，ETL工具是使用微软的DTS作了一层皮包，调用了SQLServer2000写的一堆存储过程，还有公司内部开发的一个数据迁移和处理二进制话单的工具，配置起来颇有些麻烦，虽然开发者有些功底，但以后也不会再使用了；数据库只有Oracle，还有些二进制文件；报表工具是国内一家厂商提供的，说实话开发效率挺高的，但土了点，稳定性也差了点；OLAP就是Analysis Service了。那时候不懂架构，只知道比葫芦画瓢，按照原来的样子进行代码编写。有一件比较搞笑的事，用户要求出一类报表，我和同事还不会OLAP，我就灵机一动写了数十张报表，满足不同维度和层次的要求，虽然效率很低。培训了两周后，就让我到某某移动开局去了，当然什么都没搞起来，很没面子。

现在已经离开了那家曾经累死过人的企业，该结的都结清了，谁也不再欠谁，我也失去了憎恨和爱戴的心情了。这些都成为历史了，还是写写数据仓库的所谓架构吧。

数据仓库的设计是这样的：

业务系统—>ETL—>原始数据库—>事实数据库—>OLAP—>前端报表。

业务系统就是用户的Oracle数据库了，还有一些话单二进制文件。

ETL过程就是一堆存储过程(维度的抽取、原始数据的抽取、事实数据的日结)，然后通过DTS任务包调度起来。

原始数据库就应该是ODS数据库了，负责把数据原封不动的从业务系统抽取过来；处于SQLServer2000性能的考虑，将每个业务数据表都分成历史表和当前表，当前表根据数据量的情况决定保留数据周期并定时转移到历史表中。

事实数据库保存着聚合的数据，完成系统指标的计算，以及维度的抽取工作；同时在进行聚合的同时完成数据清洗工作。其实清洗很简单的，就是对NULL的处理，连对主外键的判断都没有，也许是业务系统的数据质量还算不错吧，维度的处理仅作更新和插入处理，来保证外键数据的匹配。SQLServer2000的性能实在不敢恭维，>1000万的纪录处理的勉勉强强的，只好建了许多了分区表(就是每个月一张数据表，用视图Union起来，这也是微软推荐的方式)。

OLAP采用VBScript作为数据增量更新的处理方式，说实话到现在也买太看明白每条语句的意思，对于每个分析主题建立分区(按月)。

报表工具有一个应用服务器，定义知识库和报表权限之类的内容，报表的开发还是比较容易的，托托拽拽的就成了，二次开发的函数有点困难，还好用户要求不高，经过摸索作了一些自定义处理。对于应用服务器的不稳定，在我的长期摸索下也逐渐掌握了规律，写了一些案例；哎现在再也用不到了。

对于业务数据到原始数据的处理，完全采用增量抽取的原则；对于原始数据到事实数据的处理，则增加了一张log表，记录每次抽取的周期、跨度、与当前时间的差距和状态等等。对于OLAP的增量处理也是靠一张日志表决定处理的范围。

唯一比较独特的可能是部分业务数据用户可能会更新，需要重新抽取、聚集和OLAP处理，这个时候在处理之前首先删除这段时间的数据，重新抽取、聚集和OLAP处理，当然是靠脚本来完成的。

总体来讲这就是我一年多做BI的经验和所谓架构吧，当然也有许多问题，例如SQLServer2000的稳定性、性能考验等等问题，DTS处理过程中来时发生任务中断，需要察看日志，作进一步处理，对于源抽取、事实日结、OLAP处理的中断处理方式均不一致。对于SQLServer2000的死锁以及内存泄漏等问题也有了一定经验。对报表工具的理解也是我后来对各种报表工具学习的基础。

经过一年多7、8个局点的锻炼，脸皮也变厚了，学习也麻木了，现成的版本，统一的流程，自己以为这就是BI的全部了，总之自己就是搞过数据仓库的人了，加上做过那么点数据库优化和数据迁移，感觉自己算是小牛一个了，呵呵。

不幸的是今年年初又折腾到老路上去了，拼了老命干了1个月的java和WebService，搞得心神俱疲，才发现自己不年轻了，也不是做编码的料。

于是乎辞职了，好歹也是从大公司出来的，找个世界五百强还是没什么问题的，而且专业对口，属于那种天生就可以外出和客户交流的人，这可能是新公司对我的期望，要不然英语那么差劲，怎么可能轻易进来呢，待遇也还算不错，是原公司的1.5倍。其实我根本就不是那样的人，呵呵，不太喜欢和客户交流，不善于言辞，技术也是样样都知道样样不精通的那种。

既然进来了，又开始搞BI了，不过已经下班了，回去后再续写新公司的BI篇章，呵呵。

在新公司转眼已经呆了4个月，前三个月除了培训就是学习，向领导要了几次活干之后再也不要活了，因为大家都无活可干，于是每天上上itpub学习一下Oracle，或者交流一下数据仓库，积累一下人脉(刚学会的名词)，英语本来是一个很重要的目标，可惜我总是不开窍，而且连半个假洋鬼子英语也说不好，现在要做国内项目了，英语成了我永远的痛。

数据仓库知识没学到多少，Oracle知识却感觉长进了不少，每天培训不少，可有质量的培训却不多，当然即使有质量的培训也轮不到我等刚入公司的去学习。外企就是外企，每天总是拿着工资不干活，天天喝着咖啡、橙汁，总感觉像是被恩赐似的，很不爽，还是得找点事来做，不过三个月的懈怠确确实实把我从一个勤勤恳恳兢兢业业的老黄牛变成了一个彻头彻尾的懒虫了，每天早9晚6准时的很，也许这才是生活，名片也打印了，上面没有手机，就是八个小时之外不用来找我的意思吧。

国外项目谈了将近一年了没谈成，我就失业了；另外一个国内外企的项目因为领导感觉我不善言辞，把我换掉了；只好做一个彻头彻尾的国内项目了，做一个小小的工程师也很不错，不用担责任想事情，反正我就是一个懒惰的人。一个月就换了3个工作，虽然什么都还没做。

言归正传，国内企业就是国内企业，外表很光鲜，做起项目来尾巴就露出来了，大概是一个应景之作吧，客户要求一个数据仓库项目1个半月就要完成，半个月的需求，一个月的设计开发和测试；更要命的是现在需求丝毫没有些许的概念，客户要求用国际化的行业经验来帮助制定相应的KPI，理论联系实际，怎么招，我也不知道怎么招，反正有售前的有国外请的顾问，能忽悠就忽悠吧。不过说归说，前期的工作还是要开展的。

所谓的数据仓库架构，我也是第一次听说，改改一些概念，干脆一起来分享一下吧，没准还能成为行业标准，呵呵！该架构主要分为四层结构体系：

•       ODS层

主要负责采集业务系统并保存一定期限内的相关业务数据

•       数据仓库层

将ODS层经过质量检查、清洗、转换后，形成符合质量要求的公共数据中心。

•       明细数据集市层即事实层

按主题及KPI指标对数据仓库层数据进行进一步转换，将指标与维度组成数据集市。

•       聚合数据集市层即OLAP

在明细数据集市层的基础上，提供基于联机分析处理（OLAP）
引擎的多维分析能力，解决联机分析功能和决策支持要求。

•       数据展现层

按照用户报表要求，提供用户报表界面及预警分发机制。

其中前3层都是属于ETL层的，问题是层次出来了我的疑问也出来了，都是属于那种别人不操心我瞎操心的事。毕竟是搞数据库出身的，最关心的还是性能问题。数据仓库是企业级的数据中心，每天上G的数据的企业不在少数，那么多的层次，使用工具能抽的完数据吗？说实话我实在不信任ETL工具，总感觉他没我写的SQL语句效率高；即使抽的完数据，那么多的层次转换能处理的完吗；即使处理完，如果万一一个环节出现问题，能回退或重新处理吗；处理完后那OLAP该怎么调度啊；数据质量（清洗转换）到底在哪个环节处理；数据质量到底包括哪些东西(除了主外键缺失和NULL值)，兄弟比较愚笨，一直想不明白；不合质量要求的数据如何处理；入库的数据在业务库发生更改怎么办；业务数据没有时间戳怎么办；数据核对和校验工作如何进行；不管工具也好代码也好，到底有没有通用的处理流程(比如维度数据处理，原始业务数据抽取，事实表日结处理)；还有就是到现在也没搞到合适的需求设计文档的模板(如果哪位兄弟有可以帮忙提供一下)。这一系列问题我是横竖想不明白的，反正我的问题总是比别人多，学东西总比别人慢，还是人年龄大了真的退化了。

关于数据仓库随着项目的临近，发现不懂得越来越多了，希望大家多提点提点，数据挖掘我是一窍不通，高等数学没学好，算法自然也学不会，只怪我高中文科出身，信息管理系的文凭拿的还是文学学士，简直没脸见人了；业务建模和需求分析也不是我擅长的，因此我只能关心纯技术的东西，可是ETL工具把人写代码的权力也剥夺了，因此我只能关心一些大的方面了，这难道就是所谓的架构吗？不知道，哎，学吧！

完了，希望不要占用大家的时间,还是带一句E文吧，TKS

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友