企业级模型规划和管理

老头子

大家好，我是老头子，今天和大家一起讨论关于模型规划和管理。

在做这件事之前，首先要搞清楚的是：我们是IT部门或数据管理部门，职能是服务业务，帮助业务快速发展，那么最先要搞清楚的是我们的sponsor最迫切的需求是什么，他们为什么会同意拿出这么一大堆钱来研发这么一套系统？

无论是业务驱动架构，还是架构驱动业务，BI要想在初期能够活下去，最先要做的就是获得sponsor的认可，为业务人员解决燃眉之急，所以一切规划和管理都是围绕业务当前最紧急的需求作为出发点，或者说业务当前最想要解决的痛点作为出发点去延伸。

首先来我们看两种搭建模式，业务驱动和架构驱动。如果我们把数据仓库比作房子、业务比作住户。那么业务驱动顾名思义就是我先告诉你我想要什么样的房子，你再按照我的思路搭建。

但是很多时候用户并不知道他们想要的是什么，有可能他只有个大概的思路，比如我要三室一厅，但我最迫切的是希望先有一个卫生间，解决我当前最着急的卫生问题（人有三急）。那么显而易见我们在搭建数据仓库的时候首先要把卫生间给做出来。然后再不断的完善这间房。

而架构驱动就是我们有一个资深建造师和设计师，我们知道当前最流行的样式，我先做个样图给你看看，OK没问题再开始搭建房屋。

很明显这两者都有不同程度的瑕疵，那么我们平时多是两者结合，首先业务驱动获取最紧急需求，解决业务燃眉之急，然后再根据行业专家、资深架构师与业务人员的磨合去尝试搭建数据仓库，引导用户告诉用户什么样的数据才是最应该关注的。

如果前期顺利那么我们面临的将是在初期搭建的树根的基础上如何开枝散叶，成为一个企业级的数据仓库。

首先要知道我们前期搭建的“卫生间”是否是EDW的主干，如果不是我们需要识别哪部分才是这间房的“承重墙”。

我所提倡的数据仓库搭建是业务和架构同步驱动。IT作为主导，引导业务用户。这里我要说下为什么要IT主导，因为很多时候大部分业务所理解的BI还停留在ERP、CRM的阶段，他们认为的东西有一部分是不适合放入BI系统的，比如搜索、实时监控，但随着BI用户的层级范围越来越广，越来越多的运维人员开始使用BI系统，这就另当别论了。

所谓规划、管理，都是为了平衡业务与IT之间的期望和矛盾：IT过于迁就业务，导致架构混乱；业务过于迁就IT，导致BI没有价值。

这里我贴个图吧，这张图是之前做的参考方案，其实BI的东西整体去看基本都是这些东西，那么我们的规划、管理，就是在这个图完成之前，如何让他健康的成长。

那么我不建议在BI初期就做的需求有：实时监控、搜索功能、过于复杂的实体关联，
大体说下原因：

实时监控：这个很容易打击业务对BI的信心。

搜索功能：容易引发后期性能问题，给自己挖坑。

过于复杂的实体关联：这种需求很容易为了实现需求而导致架构混乱。

在我们的架构/模型建设中，性能是我们在实现需求的同时，时时刻刻都要提醒自己的重点，和业务体验也是密不可分的，如何在满足业务要求的同时搭建一个性能优良的EDW不是一个人可以完成的，一个资深架构师，一个业务专家这是你必不可少的左膀右臂。

此外主题的划分、主数据、元数据的管理都是完善数据仓库的过程中需要思考的。
关于元数据管理，春宇老师会在第三部分和大家分享讨论，我们可以一起讨论，如果有不同观点希望能有一些碰撞，这样才能提高我们自身。这个话题的分享就到这里，谢谢大家。

逆光

其实建模工作偏业务性，要了解行业才能更好的建模所需要的模型，但是也有很多是根据客户实际需求，和系统情况来设计，但是总体来说，了解行业的业务知识，对于建模更有帮助。

所以其实一个建模工作者，一定是最行业有深入了解的，能够为客户提供所需要的，而不是由客户来提需求。

但是我们现在很多项目，都是根据一些建模规则+客户需求，随便建立一些模型，满足展现要求就算了。

因为一个行业的项目毕竟有限，这里面也有一些利益的驱使，所以我个人更推介业务知识丰富的建模，这样才能做出更好的模型，支持更专业的报表，所以建模我不多讲，就多一些简单概念性东西，建议每个从业者，懂得技术的同时，尽量也多学学业务。

从数据仓库的定义中可以发现，数据仓库的业务特点，这些特点不仅仅停留在概念，也对数据模型的设计产生了重要影响。

1、数据仓库的数据组织是面向主题的，而不是面向报表，操作型数据库的数据组织面向事物处理，业务系统之间各自分离，数据仓库按照一定主题域进行组织。

主题是一个抽象概念，是用户使用数据仓库进行决策时所关心的重点方面，典型主题域包括顾客消费行为，产品销售情况，生产事务，材料采购。

2、数据仓库要实现对数据的集成与数据的同构性

实现同构性是一个比较复杂的工作，涉及大量数据转换，在数据获取阶段要确保所有的数据来源是一致的，或者经过一定处理后数据是一致的。如果来源不一致，我们就要把数据来源信息也包含在数据仓库中，以便后续数据转换中对不同来源的数据进行分区。

3、数据仓库数据的相对稳定与为实现应用而进行的实时读写操作

操作型数据库数据一般是实时更新的数据仓库一般是会被长期保留的，但是也存在有变化的情况，例如绩效分析，评价，有时可能一年后才会有结果，所以也需要在建模时考虑好只读和可写入对象之间的关系。

关于设计原则，基本有过经验的基本也都了解，而且建模不是会使用一个建模工具就可以的，模型也涵盖了设计者的智慧：

1，  星型结构，实现简明的数据设计模式

2，  数据参照完整性，保证数据一致性

3，  利用索引，提高查询处理速度

4，  先去索引，后加索引，提高数据装载效率

5，  校验数据，保证数据的高质量

数据仓库最关键的是查询，最耗时的是数据加载，数据表结构简单，数据源质量高，数据参照完整性好，那么数据加载肯定快，另外就是索引，一般装载前把索引去掉，完成加载后重新创建，这样也有利于提高数据加载效率。

另外，也有一些工具，不知道大家是否有了解，包括永洪，帆软之类的，其实整体的趋势开始偏向于成熟套装软件。

为什么ERP系统里面有很多功能或者流程是定死的，因为很多时候他所提供的就是客户所需要的，当然对于中国来说，很多要定制化开发，但是看看我们的金蝶之类的软件，国内很多软件产品功能是可以满足客户的。

BI的产品也一样，以后逐渐的会淘汰全部DIY的时代，里面会自带很多客户本身需要的分析报表，当然也有保留一些可以定制化的东西，这就是我前面提到的，如何可以把握提供的分析就是客户想要的，甚至超出了客户的想象，这就需要业务知识，甚至要比客户更懂才行，更高级的服务就是，不需要客户动脑，动手，傻瓜式分析。

个人的一点看法，仅供参考，谢谢大家。