关于数据仓库项目常见问题

这里主要介绍BI，产品、工具什么的就不多数了，只是看见ChinaBI网站对于绝大多数多数BI项目的基础---数据仓库提及很少，所以打算在此抛砖引玉，希望更多人关注数据仓库，加强“BI项目之根本”。

众多入门的朋友都会至少学习基本数据仓库概念，包括Inmon提出的基础概念，懂得要建设星型、雪花型，稍微深入研究的朋友，就会知道，数据仓库系统，特别是大中型系统，并不能直接将数据从各个数据源拿过来清洗、过滤、ETL就可以用了，而是各个步骤需要staging area去过渡，增加系统效率和可维护性。再深入研究Inmon或者Kimball数据仓库理论的朋友，就是知道，对于一个大中型数据仓库，你还需要对数据仓库根据不同客户实际需求设计不同的系统模式、开发模式、IT部署等，对于细节也会有更好的处理方法。

但是我从和不同业界人士交流中发现，更多的是通过了解比较基本的数据仓库理论和数据仓库相关技能（包括工具的使用，数据库的管理以及编程技能）就去做项目了。只是刚开始能满足客户的前期需求，中后期就会出现各种问题，甚至系统无法支撑的感觉，是基本技能不够么？其实很多不是。

由于精力有限以及本人接触案例有限，以下简单总结一些常见的项目案例，以及处理方向，如有异议，欢迎讨论，用常用的话讲，就是对事不对人。

1。由一群技术熟练的工程师组成的队伍，可能会造成数据仓库瘫痪。某公司一中型数据仓库，TB级数量，业务不是很复杂，参加人员：有数据库管理认证的数据库工程师（开发）；现象：数据仓库ETL过程效率太低；原因：准海量数据，只设计了寥寥几个事实表，然后就用ETL工具运行，效率很低，每天不能按时跑出前端报表需要的数据；解决方案：我的一位朋友提出，将事实表按照业务细分成多个事实分表，然后重新ETL，由于业务不复杂，restructure非常容易；结果：能按时并准确出客户要求的数据，并能保证一定扩展性。

2。数据集市的一些误解。可能有部分朋友对数据集市会有一点误解，就是数据集市是数据仓库的一些按照某种业务规范的简单聚合，或者数据集市里不需要过渡层，而是直接聚合。案例：某些著名电信运营商数据仓库系统（本人曾经参加过）。项目情况：业务比较复杂，数据量比较大，客户需要按时得到准确的报表和OLAP分析；实际情况：数据集市层中，前端数据准备的中间表数据直接由对应的数据集市聚合，特点是效率高，能快速得到客户要的数据；问题出现：客户报表的定义改变和增加指标后，数据集市层需要“随需应变地”改动，维护量非常大，可扩展性非常微弱； 解决方案：利用Kimball的数据集市建设理论，一步一步ETL出confirm fact/dimension table，最后一步到位聚合，这样就能增加项目的稳定性和可扩展性。

3。对于数据仓库各个部分的功能的误解。我了解到这么一个案例，实际情况不是很清楚，只是简单介绍下。项目人员认为ODS层和数据仓库层的区别，仅仅在于ODS层是近期的数据，而数据仓库含有大量历史的数据，于是很多前端应用直接访问ODS层。其实这个误会在于对于数据仓库的各个部分的功能不是是否深入了解，而是觉得哪部分方便用就用哪部分。

ODS层相当于接收器，把各个数据源有序地组合在一起，而且多余的不要，错误、不一致的，组合成一致，这一层并不能实现太多功能，比如用作前端查询什么的，如果一旦使用这部分查询，那么ODS层既要承受数据流向到数据仓库的压力，又要承受大量前端查询的压力，很难保证系统能稳定运行，而且由于后面还有大量ETL处理，有可能出现客户查询的结果和前端展示有微小差别的情况。

4。其他情况还很多，就不一一说明了，这里只算是抛砖引玉。我只是想说明，数据仓库/商业智能系统不要给客户或者入门者感觉，就是那么点星型、雪花型理论和各种花哨的工具使用以及编程，仅仅掌握这些只能说明你是合格的数据仓库工程师，而不能成为真正的项目咨询师、架构师或者建模师，我真佩服很多公司能启用没有相关经验的工程师去设计架构、咨询工作。而相关工具和数据库的选型并不是数据仓库的重点，我和很多朋友交流，一谈到数据仓库设计，他们首先想到的是数据库、工具的选择，其他的模糊。还有更有趣的是，有的架构师说，我们不需要研究数据仓库理论，说起来太深了，我们的客户和团队就没信心了，项目就别做了。

数据仓库项目肯定有BI应用，数据仓库本身是很复杂、多变的系统（同一个客户都能有N多种不同的设计与之对应），但并不是说难，我们就不去解决问题，就不能让系统能更准确、更高效、更有扩展性，也不能想象通过传统技术或者工具就能回避这些问题。