BI在国内刚发展起来没几年，架构设计究竟怎么进行，如何架构一个BI系统？的确需要认真研究一番！

第一：模块

BI系统（或者说数据仓库系统）也同样需要架构，它作为一种软件系统，是符合一般架构原则的。首先，我们来看看架构设计中包括那些内容。架构的重点是描述系统的结构，以及它们之间的关联、交互接口。

BI系统可以划分成业务模型、元数据、数据质量、接口平台、报表集市、指标库等若干模块。可以看出，在这里，这些模块的命名都是静态的名词，而不是动词（例如业务建模、数据质量管理等）。之所以如此，是因为这是在描述系统的结构而非功能。

具体来讲，业务模型是存放业务数据的结构，可以再往下细分，并有不同的分层方法。例如可以分成ODS、EDW、DM等层，也有的会根据业务复杂度或数据量考虑，舍弃ODS层。业务模型是支撑业务分析需求的，例如报表、仪表盘、OLAP、专题应用等。

元数据为整个系统数据的形态和数据流动的过程起到支撑作用，也就是说，数据从源头开始，到最终用户眼前，其来龙去脉，每个环节的状态都需要掌握。还有人将它比喻成模块之间的粘合剂，但更愿意将它称作是“数据”之间的粘合剂，因为模块之间自有它们的交互接口规格来粘合。数据质量模块为衡量数据源质量、ETL过程处理质量提供支撑。

接口平台是处于源系统和数据仓库系统之间的玩意儿，作用在于可以更方便地明确界定双方职责。当然，通常有很多系统似乎并不大愿意将职责搞得过于明确了倒宁愿糊涂一些。糊涂一些的好处在于一开始省了好多事，但在以后扯皮的事情就少不了了。此外，报表集市为报表应用提供支持，指标库为绩效管理需求提供支持。其实，这两者还可以归入业务模型一类，因为它们都是服务于分析需求的。

第二：需求

之所以分成若干模块，是为了让架构清晰，降低这些模块之间的耦合，这符合“分离变化”的原则。那么，这一结构到底是否合理呢？还得看这个架构面临的需求到底是什么。做好这一步，就需要把系统的用户分为两大类角色：一是系统运营角色，他们对系统的正常运行、维护负责；二是业务分析角色，他们需要从这个系统得到数据分析的功能。

显然，第二种角色的分析数据来源都将来自业务模型模块，而第一种角色将从剩余模块中满足自己的需要，而不直接和业务模型这个模块打交道。在架构设计中，重点应该放在如何满足系统管理用户的需求上面。当然，只是"重点"，而非舍弃业务分析角色，毕竟在业务模型模块中，还需要根据业务、数据量、分析应用等方面的特点，来进一步细化。

就个人经验认为，架构设计应该是与具体业务关系不大的，这种架构应该是半通用的。之所以是半通用，是因为在系统功能上面，BI项目大同小异，而在业务需求上面，架构只需要对客户的业务、分析需求分成几个大类，例如按行业为业务模型分类，按OLAP、报表来为分析应用分类，不需要太过细致。

下面，让我们来看看系统运营角色的需求。

首先，我们可以把这类角色再细分成两类：一是开发设计及实施者。之所以将开发者作为系统的用户，是因为数据仓库项目应该看作一个过程，而不是产品，因此在开发阶段，其实其架构最重要的用户就是开发者，当然要为之提供便利。二是系统管理员。系统交付之后，如何监控系统运行、发现数据质量问题、应付新的分析需求等，当然都是系统管理员的分内之事。

那么，对于开发实施人员，他需要进行系统部署、ETL的开发调试、质量的稽核；对于设计人员，则需要进行模型的变更、系统调优、系统一致性分析等；而系统管理员则需要监控ETL过程、监控系统运行、响应系统警报、接口数据管理等。这些都可以看作是用例。

这些用例就是架构设计的"需求"，如何满足他们，并且保持良好的体系和清晰的结构，能够易于维护且能够满足日后肯定会增加的业务需求等等，这些都是架构师们仔细斟酌的事情。

最后，看一下分析人员的需求。举个例子来讲，某销售总监说：“我需要了解近半年来东区和西区的销售量、收入、成本对比”，这可以算是一个用例。对这个需求，架构师该如何做呢？正确做法是，在架构中不能考虑东区、西区这些业务概念，那样就太过于细致，而是应当将这种需求抽象成一种分析应用，例如 “即席查询”。如此，架构师所着重考虑的事情就是如何满足这一类需求，而非这一个需求。

架构设计四项原则：

1、架构设计主要面向系统用户为主；

2、架构设计的内容主要包括：系统功能需求、分析需求分类；支持这两者的后台结构，对结构进行粗略划分，以让其内部能够保持简单的交互方式；

3、架构设计中不要包含过于细致的业务术语（除非为了说明方便），要尽可能保持架构的复用；

4、如果架构设计确实包含不能被其他项目复用的地方，将这部分独立出去。