吕品：作为 CIO，构建一个商业智能 BI 分析平台应该重点关注什么？( 二 ) 本文由36氪企服点评专家团吕品

【吕品：作为 CIO，构建一个商业智能 BI 分析平台应该重点关注什么？】某客户的业务分析模型梳理（二）数据仓库架构与开发层面
数据仓库的开发，可以理解为一种技术，也可以理解为一种方法论或解决方案。在商业智能 BI 中，数据仓库就是最核心的那一层，起到的就是一个承上启下的作用。往下承接各类数据源中的数据，往上支撑各类分析报表。再形象一点，数据仓库就如同人身体中的腰腹一样，腰腹力量是人的最核心的力量，所有的运动都离不开腰腹力量的支撑，重要性不可忽视。
但目前的现状是越来越多的企业为了追求所谓的 "敏捷" 基本上已经放弃了传统数据仓库的构建。敏捷快速开发是没有错的，但很多人错就错在没有分清楚什么时候应该敏捷，什么时候应该保留传统数据仓库的架构。关于这一点，会在以后的文章中专门讲到。杂谈：破解商业智能 BI 的谎言从“你能不能“说起

文章图片

文章图片
通用的数据仓库架构示例图
同时，数据仓库的构建水平将直接影响到商业智能 BI 项目的整体质量。潜在的问题也恰恰出在这里：数据仓库的架构设计对开发人员的能力要求相对较高，并且在同一个项目上，不同开发人员对数据仓库理解的不一致也可能会造成设计的缺陷。我们在一些项目上看到的普遍问题是：
1. 完全没有数据仓库的搭建，基本上使用大宽表、临时表组成临时的数据集市，没有统一的维度设计，逻辑基本不可复用。一旦业务逻辑或者维度层次结构发生调整，整个受依赖的所有分析报表基本上全都得改一遍。碰到极端的情况，基本上开发人员宁愿重做也不愿意去改报表，因为没有办法改。这种情况在新项目上线的第一年没有太大问题，但是随着业务需求的增加与调整，这种问题越来越明显。
2. 有数据仓库的架构，但缺少统一的开发标准和规范。一个数据仓库的设计与维护，不同的开发人员能力各不相同，对于数据仓库的理解程度高低不一。这就造成在设计和开发数据仓库的时候没有统一的标准，大家各自开发各自的，能省事就省事，造成数据仓库系统维度冗余、事实冗余，这对后期的开发维护造成极大的困难。造成这种问题的原因有很多，有几个点我可以在这里简单总结一下：
1. 现在很多的 BI 分析产品工具整体的设计思路就是在弱化数据仓库的作用，过度的追求前端可视化的效果，过度的追求快速敏捷开发。这类产品的定位实际上更加适用于个人或者部门级的数据分析场景，并不适合一个真正企业级的 BI 项目构建。对于真正注重企业级 BI 的项目开发，我们不应该削弱数据仓库的作用，反而更应该加强。
在这样的一种刻意营造的"行业趋势"推动下，新进入商业智能 BI 行业的开发人员至少有很大一部分很难有机会再深入数据仓库的学习和实践，大部分人的主要工作就是取数和做报表。
2. 大部分经历过传统数据仓库搭建的这批人员要么逐步退出一线开发，要么进入比较稳定的甲方企业或大型咨询机构继续大型的数据仓库设计与架构贡献自己的专业能力，因此仍然活跃在市场上且能够把控一个企业级数据仓库架构设计的乙方专家也越来越少。
目前在项目上比较常见的 BI 开发形式就是来一张报表写一组 SQL 语句，再来一张报表再写一组 SQL 语句。由于项目进度和工期，或者经验水平的缺乏，底层的数据仓库架构设计基本上是缺乏统一规划和深度考虑的。