2. Kimball的DW/BI架构解析

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

Kimball的DW/BI架构

  基于Kimball架构的DW/BI环境一般由业务系统（数据源系统）、ETL系统、数据展现、和商业智能应用四部分组成，如下图：

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应用可以是简单的，仅作为专用的查询工具，也可以是复杂的，实现复杂的数据挖掘和数据分析的能力。