“架构师”的蹿红彰显了软件架构的重要性。同样,BI系统也需要架构。为了得到一个清晰而又合理的结构,架构师需要首先将BI系统分成若干模块,然后把系统用户进行细分,以明确架构的真正需求到底是什么。
刚开始接触软件工程的时候,知道其中一个步骤叫做“总体设计”,做这项工作的人就叫“软件设计师”。当时觉得这个名称比软件开发工程师酷多了。到了现在,又开始流行“架构师”(Architect),这个名称听起来比软件设计师又酷了几分。
如今,如果你偶尔遇到一个年轻人,也就是二十出头、三十不到的样子,却客客气气地给你递上一张注明“数据仓库资深架构师”的名片,这个时候,你千万不要诧异。说来也不奇怪, BI在国内刚发展起来没几年,在这个领域干个四五年就足以混个资深的名头了。
不过,话说回来,拿着“资深架构师”的名头去忽悠是一回事,但架构师究竟该干什么,架构设计究竟怎么进行,如何架构一个BI系统?的确是需要认真研究一番的!
第一截:模块
BI系统(或者说数据仓库系统)也同样需要架构,它作为一种软件系统,是符合一般架构原则的。首先,我们来看看架构设计中包括哪些内容。
架构的重点是描述系统的结构,以及它们之间的关联、交互接口。
BI系统可以划分成业务模型、元数据、数据质量、接口平台、报表集市、指标库等若干模块。可以看出,在这里,这些模块的命名都是静态的名词,而不是动词(例如业务建模、数据质量管理等)。之所以如此,是因为这是在描述系统的结构而非功能。
具体来讲,业务模型是存放业务数据的结构,可以再往下细分,并有不同的分层方法。例如可以分成ODS、EDW、DM等层,也有的会根据业务复杂度或数据量考虑,舍弃ODS层。业务模型是支撑业务分析需求的,例如报表、仪表盘、OLAP、专题应用等。
元数据为整个系统数据的形态和数据流动的过程起到支撑作用,也就是说,数据从源头开始,到最终用户眼前,其来龙去脉,每个环节的状态都需要掌握。还有人将它比喻成模块之间的黏合剂,但我更愿意将它称作是“数据”之间的黏合剂,因为模块之间自有它们的交互接口规格来黏合。
数据质量模块为衡量数据源质量、ETL过程处理质量提供支撑。接口平台是处于源系统和数据仓库系统之间的玩意儿,作用在于可以更方便地明确界定双方职责。当然,通常有很多系统似乎并不大愿意将职责搞得过于明确了,倒宁愿糊涂一些。糊涂一些的好处在于一开始省了好多事,但在以后扯皮的事情就多了。
此外,报表集市为报表应用提供支持,指标库为绩效管理需求提供支持。其实,这两者还可以归入业务模型一类,因为它们都是服务于分析需求的。
第二截:需求
之所以分成若干模块,是为了让架构清晰,降低这些模块之间的耦合,这符合“分离变化”的原则。那么,这一架构到底是否合理呢?还得看这个架构面临的需求到底是什么。做好这一步,就需要把系统的用户分为两大类角色:一是系统运营角色,他们对系统的正常运行、维护负责;二是业务分析角色,他们需要从这个系统得到数据分析的功能。
显然,第二种角色的分析数据来源都将来自业务模型模块,而第一种角色将从剩余模块中满足自己的需要,而不直接和业务模型这个模块打交道。
在架构设计中,重点应该放在如何满足系统管理用户的需求上面,而与具体业务关系不大,这种架构应该是半通用的。之所以是半通用,是因为在系统功能上面, BI项目大同小异,而在业务需求上面,架构只需要对客户的业务、分析需求分成几个大类,例如按行业为业务模型分类,按OLAP、报表来为分析应用分类,不需要太过细致。
下面,让我们来看看系统运营角色的需求。
首先,我们可以把这类角色再细分成两类:一是开发设计及实施者。之所以将开发者作为系统的用户,是因为数据仓库项目应该看作一个过程,而不是产品,因此在开发阶段,其架构最重要的用户就是开发者,当然要为之提供便利。 二是系统管理员。系统交付之后,如何监控系统运行、发现数据质量问题、应付新的分析需求等,当然都是系统管理员的分内之事。
那么,对于开发实施人员,他需要进行系统部署、ETL的开发调试、质量的稽核;对于设计人员,则需要进行模型的变更、系统调优、系统一致性分析等;而系统管理员则需要监控ETL过程、监控系统运行、响应系统警报、接口数据管理等。这些都可以看作是用例。
这些用例就是架构设计的“需求”,如何满足它们,并且保持良好的体系和清晰的结构,能够易于维护且能够满足日后肯定会增加的业务需求等等,这些都需要架构师们仔细斟酌。
最后,看一下分析人员的需求。举个例子来讲,某销售总监说:“我需要了解近半年来东区和西区的销售量、收入、成本对比”,这可以算是一个用例。对这个需求,架构师该如何做呢?正确做法是,在架构中不能考虑东区、西区这些业务概念,那样就太过于细致,而是应当将这种需求抽象成一种分析应用,例如 “即席查询”。如此,架构师所着重考虑的事情就是如何满足这一类需求,而非这一个需求。
架构设计四项原则
1 架构设计主要以面向系统运营用户为主;
2 架构设计的内容主要包括:系统功能需求、分析需求分类;支持这两者的后台结构,对结构进行粗略划分,以让其内部能够保持简单的交互方式;
3 架构设计中不要包含过于细致的业务术语(除非为了说明方便),要尽可能保持架构的复用;
4 如果架构设计确实包含不能被其他项目复用的地方,将这部分独立出去。
BI架构“双截棍”简表
| ||||
第一截
|
第二截
| |||
模块
|
需求(用户分类)
| |||
业务模型、元数据、数据质量、接口平台、报表集市、指标库等
|
系统运营用户
|
业务分析用户
| ||
开发设计者
|
开发实施者
|
系统管理者
|
从一个需求到一类需求
| |
模型变更、系统调优
|
系统部署、质量稽核
|
监控系统、响应警报
|