BI架构“双节棍”(转)

“架构师”的蹿红彰显了软件架构的重要性。同样，BI系统也需要架构。为了得到一个清晰而又合理的结构，架构师需要首先将BI系统分成若干模块，然后把系统用户进行细分，以明确架构的真正需求到底是什么。

         刚开始接触软件工程的时候，知道其中一个步骤叫做“总体设计”，做这项工作的人就叫“软件设计师”。当时觉得这个名称比软件开发工程师酷多了。到了现在，又开始流行“架构师”（Architect），这个名称听起来比软件设计师又酷了几分。

         如今，如果你偶尔遇到一个年轻人，也就是二十出头、三十不到的样子，却客客气气地给你递上一张注明“数据仓库资深架构师”的名片，这个时候，你千万不要诧异。说来也不奇怪， BI在国内刚发展起来没几年，在这个领域干个四五年就足以混个资深的名头了。

         不过，话说回来，拿着“资深架构师”的名头去忽悠是一回事，但架构师究竟该干什么，架构设计究竟怎么进行，如何架构一个BI系统？的确是需要认真研究一番的！

第一截：模块

         BI系统（或者说数据仓库系统）也同样需要架构，它作为一种软件系统，是符合一般架构原则的。首先，我们来看看架构设计中包括哪些内容。 

         架构的重点是描述系统的结构，以及它们之间的关联、交互接口。

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

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

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

         数据质量模块为衡量数据源质量、ETL过程处理质量提供支撑。接口平台是处于源系统和数据仓库系统之间的玩意儿，作用在于可以更方便地明确界定双方职责。当然，通常有很多系统似乎并不大愿意将职责搞得过于明确了，倒宁愿糊涂一些。糊涂一些的好处在于一开始省了好多事，但在以后扯皮的事情就多了。

         此外，报表集市为报表应用提供支持，指标库为绩效管理需求提供支持。其实，这两者还可以归入业务模型一类，因为它们都是服务于分析需求的。

第二截：需求

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

         显然，第二种角色的分析数据来源都将来自业务模型模块，而第一种角色将从剩余模块中满足自己的需要，而不直接和业务模型这个模块打交道。

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

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

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

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

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

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

架构设计四项原则

        1   架构设计主要以面向系统运营用户为主； 
        2   架构设计的内容主要包括：系统功能需求、分析需求分类；支持这两者的后台结构，对结构进行粗略划分，以让其内部能够保持简单的交互方式；
        3   架构设计中不要包含过于细致的业务术语（除非为了说明方便），要尽可能保持架构的复用；
        4   如果架构设计确实包含不能被其他项目复用的地方，将这部分独立出去。

BI架构“双截棍”简表
第一截	第二截
模块	需求（用户分类）
业务模型、元数据、数据质量、接口平台、报表集市、指标库等	系统运营用户			业务分析用户
	开发设计者	开发实施者	系统管理者	从一个需求到一类需求
	模型变更、系统调优	系统部署、质量稽核	监控系统、响应警报