BI是什么?BI(Business Intelligence)的中文译名是商务智能,关于这个名词的定义很多,比较严谨的定义如下: “商务智能是企业利用现代信息技术收集、管理和分析结构化和非结构化的商务数据和信息,创造和累计商务知识和见解,改善商务决策水平,采取有效的商务行动,完善各种商务流程,提升各方面商务绩效,增强综合竞争力的智慧和能力。”(作者:王茁) 也有比较简洁的定义:商务智能好比“数据炼油厂”,即把商业活动中累积的数据加工成可用于支持商业决策的信息。 资料来源:美国数据仓库研究院(www.) BI是如何产生的?这需要从传统的商务交易系统讲起。
下面具体介绍一下每个子任务所需要用到的专业技术和辅助工具。 当早期大型的在线事务处理系统(OLTP)问世后不久,就出现了一种用于“抽取”处理的简单程序,其作用是搜索整个文件和数据库,使用某些标准选择合乎要求的数据,将其复制拷贝出来,用于总体分析。因为这样做不会影响正在使用的在线事务处理系统,降低其性能,同时,用户可以自行控制抽取出来的数据。但是,现在情况发生了巨大的变化,企业同时采用了多个在线事务处理系统,而这些系统之间的数据定义格式不尽相同,即使采用同一软件厂商提供的不同软件产品,或者仅仅是产品版本不同,之间的数据定义格式也有少许差距。由此,我们必须先定义一个统一的数据格式,然后把各个来源的数据按新的统一的格式进行转换,然后集中装载入数据仓库中。 其中,尤其要注意的一点时,并不是各个来源的不同格式的所有数据都能被新的统一格式包容,我们也不应强求非要把所有数据源的数据全部集中起来。Why?原因很多。有可能原来录入的数据中,少量的记录使用了错误的数据,这类数据如果无法校正,应该被舍去。某些数据记录是非结构化的,很难将其转化成新定义的统一格式,而且从中抽取信息必须读取整个文件,效率极低,如大容量的二进制数据文件,多媒体文件等,这类数据如果对企业决策不大,可以舍去。 目前已有一部分软件厂商开发出专门的ETL工具,其中包括: 2)数据仓库 上面提到,在进行STL之前,需要先定义一个统一的数据格式。那么,定义出来的统一的数据格式是否需要保存起来,以便在数据仓库日后的演化中使用呢?Yes!随着企业不断变化的商业模式和业务规则,肯定需要对系统进行修改和功能升级。如果弄不清楚之前定义的数据格式的具体含义,我们将无从下手。所以,我们需要一种用来描述数据的数据。早期我们使用的是数据字典(Data Dictionary),数据字典一般包括数据的定义、关系、来源、作用域、格式和用法。但是,随着时间的推移,专家们发现,越来越多的已搭建好的数据仓库希望方便的包容最新的各种格式的结构化和非结构化数据,而传统的基于关系型数据库的数据字典并不能达成这一目标。 xml出世之后,这种自描述,可无限嵌套扩展,平台独立性的文本数据格式为数据字典的进化提供了相当重要的技术支持,由此产生了基于xml的元数据的概念。并且,目前已有不少的软件系统和数据仓库都采用了xml格的元数据。如微软的.Net,P2P的EMule等。由此可见,元数据并不单单局限运用在数据仓库中。 由于基于xml的元数据相当灵活,我们可以用元数据来描述复杂的商业业务定义。所以,现在数据仓库中的元数据分为两种:技术元数据和业务元数据。技术元数据(technical meta data)是为企业技术用户和IT部门的员工提供支持的元数据,对于维护和改进系统来所至关重要。而业务元数据(business meta data)是为企业业务用户提供支持的元数据,使业务用户更容易理解统计报表中的信息。 元数据工具分为两类:一类是将各种元数据集成到集中式仓储的集成工具,另一类是在仓储上执行查询访问的访问工具。一般来说,大多数软件厂商所提供的数据仓库、BI系统中都捆绑了相应的工具。其中包括: 数据仓库是BI的基础,就好比厨师的食材。各个数据源的数据经ETL的预处理后,就被送进了数据仓库中。数据仓库有如下4个重要特性: 而且,由于数据仓库的使用对象不尽相同,数据仓库的设计需要考虑其数据单元的细节程度,即粒度。细节程度越高,粒度级就越低,反之亦然。例如:一个简单的交易处于低粒度级,而每个月所有交易的汇总则处于一个高粒度级。通常,数据分析人员使用的数据粒度较低,而高层管理人员所使用的数据粒度较高。粒度同时决定了数据仓库所占用的物理空间的大小,尽管一条交易记录可能只占用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提出OLAP的12条准则来描述OLAP系统: 和传统的联机事务处理(OLTP)相比,两者的区别很大,具体情况如下表: OLTP OLAP 工作单位 用户数 DB大小 利用多维的概念,OLAP提供了切片、切块、下钻、上卷和旋转等多维度分析与跨维度分析功能。相对于普通的静态报表,OLAP更能满足决策者和分析人员对数据仓库数据的分析。OLAP系统架构主要分为基于关系数据库的ROLAP(Relational OLAP)、基于多维数据库的MOLAP(Multidimensional OLAP)、基于混合数据组织的HOLAP(Hybrid OLAP)三种。前两种方式比较常见。ROLAP表示基于关系数据库的OLAP实现。它以关系数据库为核心,以关系型结构进行多维数据的表示和存储。ROLAP将多维数据库的多维结构划分为两类表:一类是事实表,用来存储数据和维关键字;另一类是维表,即对每个维至少使用一个表来存放维的层次、成员类别等维的描述信息。MOLAP表示基于多维数据组织的OLAP实现。它以多维数据组织方式为核心,使用多维数组存储数据。MOLAP查询方式采用索引搜索与直接寻址相结合的方式,比ROLAP的表索引搜索和表连接方式速度要快得多。 从商业层来看,我个人认为,在商业智能系统中进行数据挖掘的目标大致可分为两类: 目前业内已有很多成熟的数据挖掘方法论,为实际应用提供了理想的指导模型。CRISP-DM(Cross-Industry Standard Process for Data Mining)就是公认的、较有影响的方法论之一。CRISP-DM强调,DM不单是数据的组织或者呈现,也不仅是数据分析和统计建模,而是一个从理解业务需求、寻求解决方案到接受实践检验的完整过程。CRISP-DM将整个挖掘过程分为以下六个阶段:商业理解(Business Understanding),数据理解(Data Understanding),数据准备(Data Preparation),建模(Modeling),评估(Evaluation)和发布(Deployment)。其框架图如下:
在实际项目中,一般的事务处理系统甚至一些只提供报表分析功能的简单商业智能系统,建成以后只需要少量的工程维护工作,而采用数据挖掘技术的商业智能系统往往有很大不同。因为数据挖掘是一个商业理解、数据理解、建模、评估等一系列多次反复、多次调整、不断修订完善的过程,并且模型的应用也不是一成不变的,在适当的时候需要更新和重建。所以一般的商业智能项目并不追求一次性工程建设,更倡导的是一种与企业业务紧密联系能够提升企业竞争力的咨询服务,而且熟悉业务和分析方法的分析人员在商业智能系统的应用中起着至关重要的作用。 从技术层来看,数据挖掘技术可分为描述型数据挖掘和预测型数据挖掘两种。描述型数据挖掘包括数据总结、聚类及关联分析等。预测型数据挖掘包括分类、回归及时间序列分析等。 早期由于数据挖掘的理论和相关技术尚不成熟,软件厂商并未为其数据库产品开发相应的数据挖掘工具,但当时已有少部分大型企业有这方面的技术需求。所以,市场上出现了一些独立的数据挖掘工具,如SAS公司的Enterprise Miner、IBM公司的Intelligent Miner和SPSS公司的Clementine。现在,随着相关技术的日益成熟,越来越多的企业提出这样的技术需求,软件厂商也意识到其中的潜力,估计在未来的3~5年内,将会出现集成在数据仓库中完备的数据挖掘工具。 最后要提醒大家的是,尽管商业智能应用的前景光明,但是BI业内还没有形成一个统一的标准。而且,由于BI系统的实施是一个长期的、迭代的过程,企业在这个过程中肯定会出现短期利润倒退的情况,这也在很大程度上打击了企业的信心和实践热情。所以,目前绝大多数企业都对此持观望态度,或只在有限的部门内局部实施BI。我个人认为,企业这样做也是相当明智的。但尽管是局部实施,机会还是有的。作为技术人员,可以争取在相关技术的研发上取得突破;作为软件厂商的话,则应从现有老客户和现有产品的技术升级中寻求机会。 |
|