BI 底座——数据仓库技术(Data Warehouse)

在开始喷这个主题之前，让我们先看看数据仓库的官方定义：

    数据仓库(Data Warehouse)是一个面向主题的(Subject Oriented)、集成的(Integrate)、相对稳定的(Non-Volatile)、反映历史变化(Time Variant)的数据集合，用于支持管理决策。以上是数据仓库的官方定义。

   “操作型数据库”如银行里记账系统数据库，每一次业务操作（比如你存了5元钱），都会立刻记录到这个数据库中，长此以往，满肚子积累的都是零碎的数据，这种干脏活累活还不得闲的数据库就叫“操作型数据库”，面向的是业务操作。

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

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

 

    那么为什么要在操作型数据库和 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 ，前者就是操作型数据库，后者就是数据仓库（决策支持么，再振臂高呼一遍），针对这两种形式，数据库将提供针对性的优化。

 

转帖地址：http://www.powerbibbs.com/thread-131-1-1.html

转载于:https://www.cnblogs.com/chenjianhong/p/4144487.html