BI构架及相关技术介绍
BI构架及相关技术介绍
我是一名软件开发人员，目前的主要经验是商业信息管理系统的架构设计和开发。最早了解到的BI 实例，是2000 年和惠普(HP)某家经销商经理的一次聊天中。当时，该经理极力向我
推荐HP 美国总部销售管理系统的一个功能，当然，中国本土的经销商也可以通过网络来使用
该系统。该系统要求经销商在每销售一台HP 的打印机后，必须把客户的信息、联系方式及购
机日期录入到系统中去。当然，一开始的劳动是有回报的。一段时间后，销售系统会主动提醒
该经销商，您该联系一下之前购机的客户某某，询问其是否需要购买相应的打印耗材。经销商
按系统提示主动和客户联系时，大部分客户非常惊讶，因为他们之前购买打印耗材差不多正要
用完，正准备再次购买。于是，第二笔交易很快就达成了，经销商扩大了销售额，客户也对经
销商的适时服务非常满意。
我在大学期间参加过数学建模方面的专业培训，知道该功能是运用了数理统计，数据分析
等方面的知识建立了一个预测模型，然后通过该模型来处理实际商业客户数据，预测客户的需
求，从而发掘出潜在的商机。我对此非常感兴趣，开始留意这方面的资料。当时这方面的新闻，
报道都不多，不过，我在有限的几篇报道中都发现一个共有的专业术语——BI。2002 年之后，
国外关于BI 方面的报道陆续多了起来，也出现了这方面的专业BI 软件。2004 年至今，国内也
陆续引进了一些BI 方面的技术资料，我也开始系统的了解、学习这方面的知识。
本文将我所了解、学习到的BI 知识做一个总结，目的是把相关的专业书籍和技术文档浓缩
成一个整体拼图，方便新人对BI 有一个大致的理解，希望对有志于从事这方面发展的朋友有所
助益。文中引用不少前辈专家的已达成共识的行业定义和结论，我会在最后的参考文献中一一
列出，强烈推荐有兴趣深钻的朋友阅读原稿。
BI 是什么？BI(Business Intelligence)的中文译名是商务智能，关于这个名词的定义很多，
比较严谨的定义如下：
“商务智能是企业利用现代信息技术收集、管理和分析结构化和非结构化的商务数据和信
息，创造和累计商务知识和见解，改善商务决策水平，采取有效的商务行动，完善各种商务流
程，提升各方面商务绩效，增强综合竞争力的智慧和能力。”（作者：王茁）
BI 是如何产生的？这需要从传统的商务交易系统讲起。
最初在商务交易中引入计算机辅助管理时，开发人员是根据企业已规定好的业务规则来编
写交易系统。此时的商务系统，其主要目的是让“商务流程自动化”，从而缩短业务周期，提
高效率，增强企业的竞争力，最终为企业创造更大的利润。现今，绝大部分大、中型商业公司
都已在内部或多或少的引入的计算机辅助商务管理系统。
随着计算机在商业管理中的普及，公司的高层管理人员有了更近一步的需求，即其企业的
部门框架和业务规则随着社会分工的日益细化，而不断的发生变动。而且，其中蕴含了不少的
新的商机，精明的经理们当然不希望错过这些能让企业更上层楼的机会了，而原有的商务管理
系统面对日益变化的业务规则逐渐变得力不从心。
因此，软件厂商针对新出现的商业部门和业务规则，推出了一系列的自成体系的，专门针
对某块商业数据管理的管理软件，如财务管理软件，客户关系管理软件，产品数据管理软件，
人力资源管理软件等。但是，这些自成体系的的管理软件之间，数据很难共享，从而在企业各
个部门之间形成了“信息孤立”的局面。
于是，软件厂商又推出了更大块集成的企业资源规划(ERP)系统，把之前推出的各块独立的
管理系统整合起来。但是，单单把各个商务部门的管理软件集成起来，是否真的就是企业真正
需要的“能适应商务变化”的整体解决方案呢？
我认为：如果仅仅针对目前的商务活动和业务规则打包，答案一定是NO! 这个答案也早就
被相关方面的专家所确定。那么，如何才能真正把各个商业部门之间的商务数据集成起来，从
中预测商务变化，找到潜在商机，为商业决策提供数据支持呢？答案就是BI。
不过，BI 的范围太广太大，在实际商务中我们往往只需运用其中的某个部分就可以暂时满
足企业的需求，如数据仓库，联机事务分析(OLAP)，数据挖掘，决策支持系统(DDS)等。其实，
整个BI 的框架结构可以用下面的图中间的三部分(数据预处理、数据仓库、数据分析)来表示：
现在决大多数企业已在其一个或多个部门内采用了计算机商务管理系统，也累积了相当的
商业数据。然而，正如业内的那句老话“rich data, poor information”，以前累积的数据，并没
有很好的得到利用。Why?并不是企业高层管理人员没有想到，而是这些数据来源太广，格式不
统一，并且其中极少量的数据记录格式不正确；同时，累计的数据量相当庞大，上百万条记录
才刚起步，某些大型公司每天所产生的商业记录已过千万；而且，某些细节对高层管理人员来
说并不重要。他们需要的是一份站在战略层角度统观全局，及时的，在短时间内可以读完，为
企业决策服务的统计报表。
为了实现这一艰巨的目标，BI 专家把任务分解成了三个子任务：
1)为了整合各种格式的数据，清除原有数据中的错误记录，专家们提出了数据预处理的要
求——STL(数据抽娶转换、装载)；
2)对预处理过数据，应该统一集中起来，由此产生了元数据(Meta data)、数据仓库(Data W
arehouse)；
3)最后，对于集中起来的庞大的数据集，还应进行相应的专业统计，从中发掘出对企业决
策有价值的新的机会，这就是OLAP(联机事务分析)和数据挖掘(Data Mining)。
下面具体介绍一下每个子任务所需要用到的专业技术和辅助工具。
1)数据预处理(STL：Extraction，Transformation，Load)
当早期大型的在线事务处理系统(OLTP)问世后不久，就出现了一种用于“抽取”处理的简单
程序，其作用是搜索整个文件和数据库，使用某些标准选择合乎要求的数据，将其复制拷贝出
来，用于总体分析。因为这样做不会影响正在使用的在线事务处理系统，降低其性能，同时，
用户可以自行控制抽取出来的数据。但是，现在情况发生了巨大的变化，企业同时采用了多个
在线事务处理系统，而这些系统之间的数据定义格式不尽相同，即使采用同一软件厂商提供的
不同软件产品，或者仅仅是产品版本不同，之间的数据定义格式也有少许差距。由此，我们必
须先定义一个统一的数据格式，然后把各个来源的数据按新的统一的格式进行转换，然后集中
装载入数据仓库中。
其中，尤其要注意的一点时，并不是各个来源的不同格式的所有数据都能被新的统一格式
包容，我们也不应强求非要把所有数据源的数据全部集中起来。Why?原因很多。有可能原来录
入的数据中，少量的记录使用了错误的数据，这类数据如果无法校正，应该被舍去。某些数据
记录是非结构化的，很难将其转化成新定义的统一格式，而且从中抽取信息必须读取整个文件，
效率极低，如大容量的二进制数据文件，多媒体文件等，这类数据如果对企业决策不大，可以
舍去。
目前已有一部分软件厂商开发出专门的ETL 工具，其中包括：
·Ardent DataStage
·Evolutionary Technologies,Inc. (ETI) Extract
·Information Powermart
·Sagent Solution
·SAS Institute
·Oracle Warehouse Builder
·MSSQL Server2000 DTS
2)数据仓库
上面提到，在进行STL 之前，需要先定义一个统一的数据格式。那么，定义出来的统一的
数据格式是否需要保存起来，以便在数据仓库日后的演化中使用呢？Yes!随着企业不断变化的
商业模式和业务规则，肯定需要对系统进行修改和功能升级。如果弄不清楚之前定义的数据格
式的具体含义，我们将无从下手。所以，我们需要一种用来描述数据的数据。早期我们使用的
是数据字典(Data Dictionary)，数据字典一般包括数据的定义、关系、来源、作用域、格式和用
法。但是，随着时间的推移，专家们发现，越来越多的已搭建好的数据仓库希望方便的包容最
新的各种格式的结构化和非结构化数据，而传统的基于关系型数据库的数据字典并不能达成这
一目标。
xml 出世之后，这种自描述，可无限嵌套扩展，平台独立性的文本数据格式为数据字典的
进化提供了相当重要的技术支持，由此产生了基于xml 的元数据的概念。并且，目前已有不少
的软件系统和数据仓库都采用了xml 格的元数据。如微软的.Net，P2P 的EMule 等。由此可见，
元数据并不单单局限运用在数据仓库中。
由于基于xml 的元数据相当灵活，我们可以用元数据来描述复杂的商业业务定义。所以，
现在数据仓库中的元数据分为两种：技术元数据和业务元数据。技术元数据(technical meta dat
a)是为企业技术用户和IT 部门的员工提供支持的元数据，对于维护和改进系统来所至关重要。
而业务元数据(business meta data)是为企业业务用户提供支持的元数据，使业务用户更容易理解
统计报表中的信息。
元数据工具分为两类：一类是将各种元数据集成到集中式仓储的集成工具，另一类是在仓
储上执行查询访问的访问工具。一般来说，大多数软件厂商所提供的数据仓库、BI 系统中都捆
绑了相应的工具。其中包括：
·Ardent MetaStage (Infomix)
·IBM information Catalog
·Brio Enterprise
·Business Objects
·Cognos Impromptu 及Powerplau
·Information Advantage Business Intelligence
·Microsoft OLAP Services ("Plato")
·Microstrategy DSS Web and Server
数据仓库是BI 的基础，就好比厨师的食材。各个数据源的数据经ETL 的预处理后，就被
送进了数据仓库中。数据仓库有如下４个重要特性：
①面向主题的：不同类型的公司，其主题集合是不相同的。
②集成的：数据仓库的数据来源很广，数据仓库最重要的目的就是为了集成这些不同数据
源的数据。
③非易失的：和传统的操作型数据库系统相比，数据仓库通常是以批量方式载入和访问。
而且，对于数据仓库中的记录，并不进行一般意义上的数据更新，删除。所有的历史数据都会
被保留，通常我们只是不停的批量导入新的数据。
④随时间变化的：操作型数据库系统出于性能上的考虑，并不保存系统投入运行后所产生
的所有数据，一般只保留最新的60~90 天内所产生的数据记录。而且，通常情况下，操作型数
据库中一项业务活动只占用一条记录。当业务状况发生变化后，我们只需更新相应的记录。而
为了按时间变化发掘业务活动的时序规律，数据仓库中，该业务活动可能同时存在多条记录，
除了相应字段的内容不同外，其业务活动的时间记录也不相同。数据仓库中的数据是一系列在
某时某刻生成的复杂的快照，由此可见，数据仓库的数据是高度冗余且必须的。
而且，由于数据仓库的使用对象不尽相同，数据仓库的设计需要考虑其数据单元的细节程
度，即粒度。细节程度越高，粒度级就越低，反之亦然。例如：一个简单的交易处于低粒度级，
而每个月所有交易的汇总则处于一个高粒度级。通常，数据分析人员使用的数据粒度较低，而
高层管理人员所使用的数据粒度较高。粒度同时决定了数据仓库所占用的物理空间的大小，尽
管一条交易记录可能只占用200 个字节，但是一个月所累积的10 万条交易记录就占用了20M
个字节。如果按月对每月的所有交易记录进行综合，所得到的记录可能只占用500 个字节。
数据仓库通常的活动是批量载入和查询访问，并不进行一般意义的数据更新，而且其数据
冗余程度较高。为了提高查询效率，我们可以采用一些非常规的方法来进行数据分区存储。而
且，我们需要对数据仓库中的数据进行方便且有效的监控。
提供数据仓库技术服务的软件厂商大多是从操作型数据库系统发展起来，其推出的数据仓
库都是基于其自身研发的大型数据库产品上，且捆绑了相应的ETL，元数据，OLAP，报表等
工具，如IBM 的DM2，SAS，Sybase，Oracle，Informix，MSSQL Server 等。
在本节末要说明一下数据集市(Data Mark)。如果说数据仓库是建立在企业级的数据模型之
上的话。那么数据集市就是企业级数据仓库的一个子集，他主要面向部门级业务，并且只面向
某个特定的主题。数据集市可以在一定程度上缓解访问数据仓库的瓶颈。然而，由于各个数据
集市之间彼此独立，从而形成新的“信息孤岛”，也造成了重复投资。所以，目前越来越多的数
据仓库厂商开始提供帮助企业用户整合原有数据集市，构建集中数据仓库的技术服务。在实际
项目中，到底是选择数据仓库，还是选择数据集市，应取决于该项目的主要商业驱动。如果企
业正忍受糟糕的数据管理和不一致的数据，希望为今后打下良好的基础，则数据仓库的方案比
较好。如果该企业迫切需要给用户提供信息，那么可以先构建一个数据集市。而一旦满足了迫
切的信息需求后，就应该考虑包含独立数据仓库的数据体系结构的转换计划。
3)数据分析：OLAP 和数据挖掘OLAP 与数据挖掘是一个有机的整体，在OLAP 中必定要针对不同的主题数据仓库采用相
应的数据挖掘算法来进行数据分析。如果把数据仓库对BI 系统的作用比作厨师的食材，那么，
OLAP 和数据挖掘则是厨具。
联机分析处理(OLAP)的概念最早是由关系数据库之父E.F.Codd 于1993 年提出的，其目的
是为了让管理者灵活地对海量数据进行浏览分析。当时,Codd 认为联机事务处理(OLTP)已不能
满足终端用户对数据库查询分析的需要,SQL 对大数据库进行的简单查询也不能满足用户分析
的需求。用户的决策分析需要对关系数据库进行大量计算才能得到结果,而查询的结果并不能满
足决策者提出的需求。因此Codd 提出了多维数据库和多维分析的概念,即OLAP。Codd 提出O
LAP 的12 条准则来描述OLAP 系统：
准则1 OLAP 模型必须提供多维概念视图
准则2 透明性准则
准则3 存取能力推测
准则4 稳定的报表能力
准则5 客户/服务器体系结构
准则6 维的等同性准则
准则7 动态的稀疏矩阵处理准则
准则8 多用户支持能力准则
准则9 非受限的跨维操作
准则10 直观的数据操纵
准则11 灵活的报表生成
准则12 不受限的维与聚集层次
和传统的联机事务处理(OLTP)相比，两者的区别很大，具体情况如下表：
OLTP OLAP
用户 操作人员,低层管理人员 决策人员,高级管理人员
功能 日常操作处理 分析决策
DB 设计 面向应用 面向主题
数据
当前的, 最新的细节的，二维的分立
的
历史的, 聚集的, 多维的集成的, 统
一的
存取 读/写数十条记录 读上百万条记录
工作单
位
简单的事务 复杂的查询
用户数 上千个 上百个
DB 大小 100MB ~ GB 100GB ~ TB
利用多维的概念，OLAP 提供了切片、切块、下钻、上卷和旋转等多维度分析与跨维度分
析功能。相对于普通的静态报表，OLAP 更能满足决策者和分析人员对数据仓库数据的分析。O
LAP 系统架构主要分为基于关系数据库的ROLAP（Relational OLAP）、基于多维数据库的M
OLAP（Multidimensional OLAP）、基于混合数据组织的HOLAP（Hybrid OLAP）三种。前两
种方式比较常见。ROLAP 表示基于关系数据库的OLAP 实现。它以关系数据库为核心，以关系
型结构进行多维数据的表示和存储。ROLAP 将多维数据库的多维结构划分为两类表:一类是事
实表，用来存储数据和维关键字；另一类是维表，即对每个维至少使用一个表来存放维的层次、
成员类别等维的描述信息。MOLAP 表示基于多维数据组织的OLAP 实现。它以多维数据组织
方式为核心，使用多维数组存储数据。MOLAP 查询方式采用索引搜索与直接寻址相结合的方
式，比ROLAP 的表索引搜索和表连接方式速度要快得多。
数据挖掘（Data Mining，DM）是指从大量不完全的、有噪声的、模糊的、随机的数据中，
提取隐含在其中的、有用的信息和知识的过程。其表现形式为概念（Concepts）、规则(Rules)、
模式(Patterns)等形式。
从商业层来看，我个人认为，在商业智能系统中进行数据挖掘的目标大致可分为两类：
①从累积的业务数据中发掘出管理层事先不知道的、但又是潜在有用的信息，为其创造新
的商业机会。商业销售已有大量这方面的运用实例，BI 业内流传已久的“啤酒和尿布”，以及我
在本文开头所举的例子就属此类。
②从累积的业务数据中寻求最优的资源规划方案，降低成本，从而提高利润。让我们先从
大家可能都想过一个例子谈起——邮递员送信，假设我是某个城市的邮递员，一次要送出多封
信件，收信人的住址分布在城市的各个街道上。那么该如何设计线路，来尽可能的减少行程呢？
商业活动中出现大量类似的例子，当可供分析的数据不多时，我们可以用纸笔来手工计算，找
到最优解。但是，如果原始数据量极为庞大的话，我们将不得不求助于计算机了。
目前业内已有很多成熟的数据挖掘方法论，为实际应用提供了理想的指导模型。CRISP-D
M（Cross-Industry Standard Process for Data Mining）就是公认的、较有影响的方法论之一。C
RISP-DM 强调，DM 不单是数据的组织或者呈现，也不仅是数据分析和统计建模，而是一个从
理解业务需求、寻求解决方案到接受实践检验的完整过程。CRISP-DM 将整个挖掘过程分为以
下六个阶段：商业理解（Business Understanding），数据理解(Data Understanding)，数据准备(D
ata Preparation)，建模(Modeling)，评估(Evaluation)和发布(Deployment)。其框架图如下：
商业理解就是对企业运作、业务流程和行业背景的了解；数据理解是对现有企业应用系统
的了解；数据准备就是从企业大量数据中取出一个与要探索问题相关的样板数据子集。建模是
根据对业务问题的理解，在数据准备的基础上，选择一种更为实用的挖掘模型，形成挖掘的结
论。评估就是在实际中检验挖掘的结论，如果达到了预期的效果，就可将结论发布。
在实际项目中，一般的事务处理系统甚至一些只提供报表分析功能的简单商业智能系统，
建成以后只需要少量的工程维护工作，而采用数据挖掘技术的商业智能系统往往有很大不同。
因为数据挖掘是一个商业理解、数据理解、建模、评估等一系列多次反复、多次调整、不断修
订完善的过程，并且模型的应用也不是一成不变的，在适当的时候需要更新和重建。所以一般
的商业智能项目并不追求一次性工程建设，更倡导的是一种与企业业务紧密联系能够提升企业
竞争力的咨询服务，而且熟悉业务和分析方法的分析人员在商业智能系统的应用中起着至关重
要的作用。
从技术层来看，数据挖掘技术可分为描述型数据挖掘和预测型数据挖掘两种。描述型数据
挖掘包括数据总结、聚类及关联分析等。预测型数据挖掘包括分类、回归及时间序列分析等。
1、数据总结：继承于数据分析中的统计分析。数据总结目的是对数据进行浓缩,给出它的
紧凑描述。传统统计方法如求和值、平均值、方差值等都是有效方法。另外还可以用直方图、
饼状图等图形方式表示这些值。广义上讲，多维分析也可以归入这一类。
2、聚类：是把整个数据库分成不同的群组。它的目的是使群与群之间差别很明显，而同一
个群之间的数据尽量相似。这种方法通常用于客户细分。在开始细分之前不知道要把用户分成
几类，因此通过聚类分析可以找出客户特性相似的群体，如客户消费特性相似或年龄特性相似
等。在此基础上可以制定一些针对不同客户群体的营销方案。
3、关联分析：是寻找数据库中值的相关性。两种常用的技术是关联规则和序列模式。关联
规则是寻找在同一个事件中出现的不同项的相关性；序列模式与此类似，寻找的是事件之间时
间上的相关性，如对股票涨跌的分析等。
4、分类：目的是构造一个分类函数或分类模型(也常常称作分类器)，该模型能把数据库中
的数据项映射到给定类别中的某一个。要构造分类器，需要有一个训练样本数据集作为输入。
训练集由一组数据库记录或元组构成,每个元组是一个由有关字段(又称属性或特征)值组成的特
征向量,此外,训练样本还有一个类别标记。一个具体样本的形式可表示为:( v1, v2, ...，vn；c )，
其中vi 表示字段值，c 表示类别。
5、回归：是通过具有已知值的变量来预测其它变量的值。一般情况下，回归采用的是线性
回归、非线性回归这样的标准统计技术。一般同一个模型既可用于回归也可用于分类。常见的
算法有逻辑回归、决策树、神经网络等。
6、时间序列：时间序列是用变量过去的值来预测未来的值。
早期由于数据挖掘的理论和相关技术尚不成熟，软件厂商并未为其数据库产品开发相应的
数据挖掘工具，但当时已有少部分大型企业有这方面的技术需求。所以，市场上出现了一些独
立的数据挖掘工具，如SAS 公司的Enterprise Miner、IBM 公司的Intelligent Miner 和SPSS 公
司的Clementine。现在，随着相关技术的日益成熟，越来越多的企业提出这样的技术需求，软
件厂商也意识到其中的潜力，估计在未来的3~5 年内，将会出现集成在数据仓库中完备的数据
挖掘工具。
最后要提醒大家的是，尽管商业智能应用的前景光明，但是BI 业内还没有形成一个统一的
标准。而且，由于BI 系统的实施是一个长期的、迭代的过程，企业在这个过程中肯定会出现短
期利润倒退的情况，这也在很大程度上打击了企业的信心和实践热情。所以，目前绝大多数企
业都对此持观望态度，或只在有限的部门内局部实施BI。我个人认为，企业这样做也是相当明
智的。但尽管是局部实施，机会还是有的。作为技术人员，可以争取在相关技术的研发上取得
突破；作为软件厂商的话，则应从现有老客户和现有产品的技术升级中寻求机会。
［参考资料］
一、参考书目
1、W.H. Inmon, 《Building the Data Warehouse：Third Edition》(数据仓库)
2、David Marco, 《Building and managing the Meta Data Repository A Full lifecycle Guide》
(元数据仓储的构建于管理)
3、David Hand,Heikki Mannila,Padhraic Smyth, 《Rrinciples of Data Mining》(数据挖掘原理)
4、Olivia Parr Rud, 《Data Mining Cookbook：Modeling Data for marketing,Risk,and Custor
mer Relationship Management》(数据挖掘实践)
二、参考文献
1、王茁, “商务智能是什么、不是什么？”
2、杨林, “正确理解商业智能”
3、吴斌博士, “商业智能的技术与实践”
4、Unknown, many smart technical articles searched by google
三、资料来源
1、Bookshop
2、Technical Magazine
3、http://www.google.com/
4、http://www.dmresearch.net/
5、http://www.amteam.org/