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

你可能感兴趣的:(数据仓库)