2. Kimball的DW/BI架构解析

文章目录

      • Kimball的DW/BI架构
        • 1. 业务系统(数据源系统)
        • 2. 获取-转换-加载(ETL)系统
        • 3. 用于支持BI(商业智能)决策的展现区
        • 4. 商业智能应用

  引言:DW,即Data Warehouse,数据仓库;BI,即Business Intelligence,商业智能。数据仓库存在的目的即为商业智能服务,二者相伴相生,故在此讨论DW/BI系统架构。

Kimball的DW/BI架构

  基于Kimball架构的DW/BI环境一般由业务系统(数据源系统)、ETL系统、数据展现、和商业智能应用四部分组成,如下图:
2. Kimball的DW/BI架构解析_第1张图片

1. 业务系统(数据源系统)

  它们是操作型系统,用于处理企业的各种事务,如办公OA、采购管理系统、财务系统等。它们一般处于数据仓库之外,且存储的数据的格式和内容各不相同。
  这些业务系统的查询通常是浅显的,以一次一条或有限几条记录的查询方式构成常见的事务流,因而不能实现类似DW/BI系统那样广泛的、无法预料的查询功能。
  多数情况下,业务系统是一种独立的、针对特定业务的应用,它并不会与其他业务系统共享自身的业务数据和公共数据,业务系统之间是割裂的存在。

2. 获取-转换-加载(ETL)系统

  ETL,即Extract Transformation and Load,获取-转换-加载。
  “获取”(采集)是将源数据从业务系统导入数据仓库的第一步,一般情况下,出于性能的考虑,获取的过程中不会对源数据进行任何处理,而是保持数据原样。此步骤即数据仓库分层模型中的ODS(贴源层)。
  获取到数据后,需要进行多种“转换”操作,例如数据清洗、合并不同数据源的数据等。在数据仓库的分层模型中,此步骤大致可对应DWD(数据清洗)和DWS(数据轻度汇总)的操作。
  在常见的大数据平台架构中(如Lambda/Kappa架构),鉴于运行效率的差别,获取和转换两个步骤之间一般通过MQ进行解耦,以提高系统的性能和可扩展性。
  ETL最后的步骤是实际构建和“加载”数据到展现区域的目标维度模型中,它关注维度表的处理,例如代理键分配、查找代码(操作码)以提供适当的描述、拆分或组合列以提供适当的数据值等。相比之下,事实表往往比较庞大,其加载也会耗费大量的时间。
  当维度模型中的事实和维度表都得到了更新、索引、适当聚集,并确保质量良好后,业务用户就可以开始使用这些数据了。

3. 用于支持BI(商业智能)决策的展现区

  由于用户不被允许直接查询ETL区域的数据,展现区就成为了用户浏览和观察业务的唯一途径。目前,业界统一的观点是:展现区要采用星型模式,或者OLAP多维数据库。
  虽然为了提高性能,展现区也会存储一些聚集数据,但更重要的是,其中一定要包含最细粒度的数据(原子数据),以便用户能够获得最准确的查询结果。换句话说,在维度模型中仅有汇总数据,而查询原子数据时必须访问规范化模型(业务系统常见的表结构设计模型)是不被接受的。
  最后,展现区必须使用公共的,一致的维度来建模。否则,维度模型将成为一种孤立的应用。无法实现交互的、隔离的烟筒型数据集合将导致企业不同应用间互不兼容。
  一致的维度是实现企业数据仓库总线结构的基础,将总线结构作为基本框架,即可采用敏捷的、分散的、范围合适的、迭代的方式建立企业数据仓库。

4. 商业智能应用

  Kimball DW/BI架构的最后一个部件是商业智能(Business Intelligence)。在这里,BI指的是为用户提供利用展现区制定分析决策的能力。BI应用可以是简单的,仅作为专用的查询工具,也可以是复杂的,实现复杂的数据挖掘和数据分析的能力。

你可能感兴趣的:(数据仓库&维度建模,架构,数据仓库,维度建模)