商业智能（BI）学习笔记

近期的一个项目需求方提出了congons产品的应用。虽然从业务需求中大概明白这是个数据分析和统计的工具平台，但具体的应用则一概不知。以前对于数据仓库和数据挖掘技术，只觉得是比较深奥和偏远的东西，避之而唯恐不及。现在突然接触到，有一种莫名的迷茫。

 

在google和百度中搜索了好一阵，获得了一些关于BI（商业智能）的知识，对数据仓库和数据挖掘有了新的认识。以往的迷茫和技术开发中的困惑，似乎一下子迎刃而解。

 

• OLAP教程
• 九大数据仓库技术比较
• BLOG: what is BI and OLAP？

在上面的这篇blog中，作者由浅入深的讲解了BI的有关概念，并逐渐的引入了：OLAP、多维Cube、数据挖掘、数据仓库的概念，并在具体应用中提及了congnos的用法，有一种顿悟的感觉。这是一个全新的概念和领域。

 

1）BI是什么？

我们平时所接触到的数据库，即面向记录型的数据库，存储的都是明细式的业务数据，零碎而又抽象，所以又称为“操作型”数据库。

 

对于企业的决策者来说，对于历史沉积的数据，如鸡肋般食之无味弃之可惜。如何在数据和决策者之间建立一个桥梁，于是“商业智能（BI）”的概念由此而生。

 

BI(Business Intelligence) 是一种运用了数据仓库、在线分析和数据挖掘等技术来处理和分析数据的崭新技术，目的是为企业决策者提供 决策支持。

 

BI 是一个工厂：

>> BI 的原材料是海量的数据；
>> BI 的产品是由数据加工而来的信息和知识；
>> BI 将这些产品推送给企业决策者；
>> 企业决策者利用 BI 工厂的产品做出正确的决策，促进企业的发展；

2）数据查询

相比较于传统的基于sql语句的查询，BI工具一般都提供了基于界面的查询手段，用户只需要通过鼠标的拖拽，就可以简单的完成数据的查询工作。

 

 

3）数据报表

报表就是将查询出来的数据按照指定的格式展现，是sql查询的直观展示。

 

 

 

4）联机分析处理（OLAP）

联机分析处理，是 BI 带来的一种全新的数据观察方式，是 BI 的核心技术之一。

 

在传统的二维表中，数据以记录的形式存储在数据库中。如果我们想要获得某一特定条件的数据的汇总和统计信息，例如不同类别、不同时期数据的比较和占比，就必须手工编写复杂而又容易出错的SQL SUM语句。

 

写到这里，不由得再次回想起上一个“大额现金管理”的项目。在这个项目中，就有一个这样的数据统计模块，要求对不同时期、跨年、跨月对数据进行比对和统计比例。当时为了写这样的SQL语句，动用了大量的SQL统计函数和联合union。写成的语句为了在java和db2环境中进行调试，还不得不在每个sql语句的换行处加上/r/n换行符，真是丑陋无比。

OLAP系统按照其存储器的数据存储格式可以分为关系OLAP（RelationalOLAP，简称ROLAP）、多维OLAP（MultidimensionalOLAP，简称MOLAP）和混合型OLAP（HybridOLAP，简称HOLAP）三种类型。

1.ROLAP

ROLAP将分析用的多维数据存储在关系数据库中并根据应用的需要有选择的定义一批实视图作为表也存储在关系数据库中。不必要将每一个SQL查询都作为实视图保存，只定义那些应用频率比较高、计算工作量比较大的查询作为实视图。对每个针对OLAP服务器的查询，优先利用已经计算好的实视图来生成查询结果以提高查询效率。同时用作ROLAP存储器的RDBMS也针对OLAP作相应的优化，比如并行存储、并行查询、并行数据管理、基于成本的查询优化、位图索引、SQL的OLAP扩展(cube,rollup)等等。

2.MOLAP

MOLAP将OLAP分析所用到的多维数据物理上存储为多维数组的形式，形成“立方体”的结构。维的属性值被映射成多维数组的下标值或下标的范围，而总结数据作为多维数组的值存储在数组的单元中。由于MOLAP采用了新的存储结构，从物理层实现起，因此又称为物理OLAP（PhysicalOLAP）；而ROLAP主要通过一些软件工具或中间软件实现，物理层仍采用关系数据库的存储结构，因此称为虚拟OLAP（VirtualOLAP）。

3.HOLAP

由于MOLAP和ROLAP有着各自的优点和缺点（如下表所示）,且它们的结构迥然不同，这给分析人员设计OLAP结构提出了难题。为此一个新的OLAP结构——混合型OLAP（HOLAP）被提出，它能把MOLAP和ROLAP两种结构的优点结合起来。迄今为止，对HOLAP还没有一个正式的定义。但很明显，HOLAP结构不应该是MOLAP与ROLAP结构的简单组合，而是这两种结构技术优点的有机结合，能满足用户各种复杂的分析请求。

OLAP提出了ＣＵＢＥ（立方体）的概念，把数据抽象成“维度”和“度量”。维度可以想象成多维坐标的坐标轴，多个坐标的交汇点对应的值就是“度量”。

维度还可以进一步进行分类和汇总，例如按日分类为月，按月分类为年，按地点分类为地区……，无论如何归类，总是可以在坐标中找到一个交汇点，这个点就是我们关注的值。

 

这是一个非常直观的概念。通过对ＣＵＢＥ进行向下钻取(Drill Down)和向上汇总(Roll Up)，我们就可以得到任何我们想得到的数据。

 

ＣＵＢＥ同样可以通过丰富的图表进行展示。用户只需要选择了维度和度量所对应的字段，就可以立即从BI平台中获得生动的图表展示：

 

 

5）数据挖掘

相比于上面的技术，数据挖掘集中体现了BI中I，即智能。数据挖掘的目的是通过计算机对大量数据进行分析，找出数据之间潜藏的规律和知识，并以可理解的方式展现给用户。

 

数据挖掘的三大要素是：

>> 技术和算法：目前常用的数据挖掘技术包括——
        自动类别侦测(Auto Cluster Detection)
        决策树(Decision Trees)
        神经网络(Neural Networks)

>> 数据：由于数据挖掘是一个在已知中挖掘未知的过程，因此需要大量数据的积累作为数据源，数据积累量越大，数据挖掘工具就会有更多的参考点。

>> 预测模型：也就是将需要进行数据挖掘的业务逻辑由计算机模拟出来，这也是数据挖掘的主要任务。

6）数据仓库
在前面已经提到了“操作型数据库”，数据仓库则是对操作型数据库概念的扩展。

“数据仓库”用于决策支持，面向分析型数据处理，不同于操作型数据库；另外，数据仓库是对多个异构的数据源有效集成，集成后按照主题进行了重组，并包含历史数据，而且存放在数据仓库中的数据一般不再修改。

操作型数据库 、数据仓库与数据库之间的关系，就像 C:、D: 与硬盘之间的关系一样，数据库是硬盘，操作型数据库是 C:，数据仓库是 D:，操作型数据库与数据仓库都存储在数据库里，只不过表结构的设计模式和用途不同。

7）为什么有数据仓库
那么为什么要在操作型数据库和 BI 之间加这么一层“数据仓库”呢？

一是因为操作型数据库日夜奔忙，以快速响应业务为主要目标，根本没精力伺候 BI 这边的数据需求，而且 BI 这边的数据需求通常是汇总型的，一个 select sum(xx) group by xx 就能让操作型数据库耗费大量资源，业务处理跟不上趟，麻烦就大了，比如你存了 5000 元钱，发现十分钟后钱还没到账，作何感想？一定是该银行的领导在看饼图？

二是因为企业中一般存在有多个应用，对应着多个操作型数据库，比如人力资源库、财务库、销售单据库、库存货品库等等，BI 为了提供全景的数据视图，就必须将这些分散的数据综合起来，例如为了实现一个融合销售和库存信息的 OLAP 分析，BI 工具必须能够高效的取得两个数据库中的数据，这时最高效的方法就是将数据先整合到数据仓库中，而 BI 应用统一从数据仓库里取数。

 

将分散的操作型数据库中的数据整合到数据仓库中是一门大学问，催生了数据整合软件的市场。这种整合并不是简单的将表叠加在一起，而是必须提取出每个操作型数据库的维度，将共同的维度设定为共用维度，然后将包含具体度量值的数据库表按照主题统一成若干张大表（术语“事实表”，Fact Tables），按照维度-度量模型建立数据仓库表结构，然后进行数据抽取转换。后续的抽取一般是在操作性数据库负载比较小的时候（如凌晨），对新数据进行增量抽取，这样数据仓库中的数据就会形成积累。

 

 

大多数 BI 应用并不要求获取实时的数据，比如决策者，只需要在每周一看到上周的周报就可以了，95% 的 BI 应用都 不要 求实时性，允许数据有 1 小时至 1 个月不等的滞后，这是决策支持系统的应用特点，这个滞后区间就是数据抽取工具工作的时间。当然，BI 应用中通常还将包含极少的对实时数据的要求，这时仅需针对这些特殊需求，将 BI Querying 软件直接连接在业务数据库上就可以了，但是必须限制负载，禁止做复杂查询。

目前的数据库产品都对数据仓库提供有专门优化，例如在安装 MySQL 的高版本时，安装成序会询问你是想让数据库实例作为 Transaction-Oriented ，还是 Decision Support ，前者就是操作型数据库，后者就是数据仓库（决策支持么，再振臂高呼一遍），针对这两种形式，数据库将提供针对性的优化。