李昊：谈谈数据仓库建设心得（上）

分享记录：

数据仓库在业界的定义，是数据仓库之前BILL最早提出的。数据仓库的建设需要一个过程，是一个方法论。数据仓库建设是把企业中所有的数据整合，加工，分析的过程。用于解决数据经营，管理问题。他不像一个产品或者数据库一样，可直接购买。

OLTP就是我们通常说的所谓业务系统。它和数据仓库是有明显差异，业务系统重在当前数据，重在是插入，比如我们一个电商交易数据产生，插入，这些数据都是放到业务系统。但是一般的智能推荐查询系统来源都是通过数据仓库。可以简单总结为：一个是面向业务记录数据。一个是面向应用管理决策应用。

另外一张图中说明了数据仓库与数据集市、数据挖掘的区别，数据仓库基础来源是业务系统，业务系统通过ODS进入数据仓库，按主题存放； 放到数据集市的时候，一般是要面向具体的业务应用主题，具体业务分析主题，例如:商品或者库存分析集市.

不论是数据仓库还是数据集市，主要区别是存放不同粒度数据，但是数据挖掘和二者有很大差别，数据挖掘也可以认为是一个方法论。数据挖掘是为了验证假设，或者发现一些关系做的知识发现。例如:啤酒与尿布，数据挖掘是数据仓库典型的应用方向。建数据仓库是为了企业的分析主题，当然目的也可以是为了数据挖掘。

一般来说BI项目,有二个层面含义,广义来说BI包括数据仓库.传统的BI更偏向数据展示方面。这个图是BI项目各个功能与模块.

我们从上往下看，最上面提供数据来源。可以把数据集市，OLAP，CUBE，业务数据，WEB等都当作数据源，通过数据集成的方式再进行处理，会通过元数据管理。元数据为了打通BI和数据仓库之间，业务系统之间的关联关系。

这种元数据的应用，一般我们也是把它做成血缘分析，比如说统计口径里面这个数据来源是哪个数据集市的字段，而这个数据集市字段又来自于哪个数据仓库明细表的字段，而这个明细表又来自于哪个业务系统，这个是通过元数据描述进行追溯的，这个作为数据管理比较重要。

之后在这基础之上一般会建立一些可视化分析，建报表，开发仪表盘（dashbroad），门户(portal)。用户也会做些即席查询或者报表导出，用户也包括各种各样用户，业务用户，管理用户，IT伙伴。

在一个数据仓库项目过程中，有三个环节，有开发面，有安全面，有权限面，数据仓库是企业系统，安全与权限还是很重要。在开发面，一个项目会有元数据，报表，表单，仪表盘，门户的开发，以及工作流，或者定制化，这些都是基于数据仓库的。这是通常一个BI项目的开发。

安全性要求，哪些功能，哪些报表，哪些KPI，哪些角色可以看。另一部分数据层面的权限，例如北京大区不能看到华东大区，数据层面还有列控制，行控制，安全性在所有的BI项目或者数据仓库项目中都是比较花成本的。

再来谈管理权限，管理涉及到数据质量，元数据管理，使用量的管理，主要是指数据的使用量与报表的使用量，做数据仓库与数据项目中，花了大量时间整理数据，开发很多报表，但是没有人用或者很少人用，这是最可怕的事情。加载与资源计划管理主要是:硬件系统与负载管理。

这个图是一个典型的BI项目，或者说数据展现的项目，一般这样的系统都是来源于数据仓库或者建立了一个数据集市。

一般意义上数据仓库项目有几种类型建设，先从结果倒推呈现，看下我们是怎么做的。一般我们在需求分析和整个实施历程会经历4个阶段，需求理解、梳理与组织、方案设计、

实施与推广。在需求理解阶段，主要理解业务需求是什么样，有没有真实抓到痛点或者关键点是什么，是否可以通过技术手段解决，这个是在梳理过程中主要分析需求与数据基础所能提供支撑的，中间是否有差距，这样才能进行梳理。

数据仓库一般是在方案设计阶段牵扯到数据模型的建模设计以及整个数据安全设计，这些会牵扯到整个数据仓库项目的成与败。其他都是从具体需求出发，例如进行一些报表开发。也会涉及到数据仓库实施推广，在推广面其实比较重要【但往往是被很多人忽略】，因为我们都是做技术活的，大家很辛苦都理解，但在推广面做不好的话，实际上在企业内部很难应用起来【所以在做的时候一定要把项目的推广同步考虑起来】。

刚才是按流程看了下实施历程，我们换个角度看实施流程，实际上实施过程分三个层面的，一个是基础，当然是我们的数据模型面向数据模型管理，包括他的数据完整性、准确性、弹性怎么保持。一个顶层，用户看到的是界面，UI设计、报表发布方式，报表门户，这是用户可以看到的。用户进来门户看到的是各个业务主题，每个主题各项功能，以及我们是否要做KPI分析，常见业务型报表、操作型报表都是在这个层面，从整体来看一个实施历程会是这样。

A：对于需求分析的过程，需求分析细节点，今天不会讲太多，这边列出这几页主要想表达的内容。所有想把数据仓库好，所有这些需求分析工作需要做好，都是直接关系到数据仓库具体实施过程，需求分析的意义在于我们的功夫不能白花。

刚才发的这张图是经过需求分析以后我们整理出来的第一个设计稿。在一般的报表设计中会有表头、报表样式、图形样式、指标说明、支撑维度这几个方面进行设计。比如表头主要是报表名称、时间、以及各种筛选条件需要哪些排序、显示哪些，或者要不要清空按钮，确定按钮长什么样子。

报表样式的图实际是二维表，图表的命名各不一样，例如上面提到的报表很多公司叫销售目标，也有的叫预算，各家叫法不一样，按照自己的需要。

图形样式设计以及指标说明统计口径大家都很容易理解，我主要想说明的是支撑维度是什么，在这个图的最右下角，我们把指标所需要的支撑维度横向都列出来了，都是打钩的状态，打钩是说明这个指标需要这几个维度支撑，比如说需要部门维度、时间维度、销售人员、经销商或者产品维度这些打钩的，这些支撑维度决定了我们数据仓库的设计。

这里我们以客户价值分析来举例，数据架构设计和表结构设计的思路，最基本的是每一个客户的利润贡献度，他对公司产生的收入以及成本。在建表的时候要将字段分为两大类，一类是指标，比如是收入和成本，主要是数值型；另一类是维度，是分析的角度，比如地理位置、客户等级、客户忠诚度。

通过刚才的设计分析，我们基本将面向客户价值的明细表设计完成了，有基本明细表后可以做固定报表和自助查询报表，但是如果想要有更灵活的查询，一般需要再汇总一次，叫做面向DC（数据中心）或者面向数据集市的设计，即更高层级的汇总，可以用来做OLAP分析、CUBE，或者多维度的展现。

说一下数据仓库存在的价值，不管是面向客户价值的基本明细表还是高度汇总后的设计表，都不能从业务系统直接简单的查询，即使可用复杂的SQL实现，也会极大地影响业务系统本身的稳定性，因为业务系统的第一任务是满足日常业务处理，不能因为我们的查询影响到业务系统的订单录入等情况。