一. ETL 过程概览

  本章将按照 ETL 系统规划与实现的流程组织讨论 。其中隐含地讨论上一章所讨论的 34 个 ETL 子系统 ，大致按照获取数据 、清洗与一致性、用于展现的发布 、ETL 环境的管理等分类 。

  在开始谈论针对维度模型 的 ETL 系统设计前 ，您应当已完成了逻辑设计 、勾画完成了高层结构规划井勾画出有关源到目标的所有数据的映射 。

  ETL 系统设计过程至关重要 。收集所有的相关信息 ，包括处理从操作型数据源中获取的代价，测试某些关键的替代品 。将转换过程驻留到源系统 、目标系统或其本身的平台上 是否有意义？在每种情况下，可以使用哪些工具 ？这些工具 的有效性如何？

二. ETL 开发规划

  ETL 开发从高层次的计划开始 ，该技术独立于所有特定技术或方法 。然而 ，在开始制 定详细 的规划前，决定采用某种 ETL 工具是一种好办法 ，这样做可以在后续过程中避免重新设计和返工。

2.1 第 1 步：设计高层规划

  设计过程始于规划的己知片段的简单示意图 ：源和目标 ，如下 所示 。该示意图表 示虚拟公用事业公司的数据仓库 ，其主要的数据源来自于己有 30 年历史的 COBOL 系统。 如果多数或所有数据来自于 一个现代关系型事务处理系统 ，那么图中的框通常 表示事务系 统模型中的表的逻辑分组 。

image.png

  在开发详细的 ETL 系统定义时 ，高层视图需要额外的细节 。上图详细强调了当前 的问题和尚未解决的问题 ，该规划将会被频繁地更新和发布 。有时需要保留该示例的两个 版本 ：一个与小组外人员交互的图以及 一个作为内部 DW/BI 小组文档的详细版本 。

2.2 第 2 步：选择 ETL 工具

  在数据仓库市场中存在多种可应用的 ETL 工具 。大多数主要的数据仓库提供商都提供
ETL 工具 ，通常需要额外的许可权开销 。第三方提供商也提供优异的 ETL 工具。

  ETL 工具从一系列数据源中读取数据 ，包括平面文件 、ODBC 、OLE DB 以及大多数 关系数据库本身自带的数据库驱动程序 。它们可以将数据写入到各种各样的目标文件格式 。 它们都包含一些功能用于管理 ETL 系统的整体逻辑流程 。

  如果源系统是关系型 的，那么转换需求就比较直接 ，在具有优秀员工的前提下 ，ETL工具的价值可能不会立即显现出来 。然而，使用 ETL 工具是行业标准的最佳实践 ，其原因 如下：
• 使用图形工具可自动构建文档 。硬代码系统通常是造成临时表 、SQL 脚本 、存储过程 、操作系统脚本混乱的主要原因 。
• ETL 过程的所有步骤的元数据基础 。
• 多人开发环境需要使用的版本控制 ，版本控制还可实现备份和恢复 一致性的版本。
• 高级转换逻辑 ，例如模糊匹配算法 、对名称和地址集 成访问的重复数据删除
(deduplication）实用程序 ，以及数据挖掘算法等 。
• 以最基本的经验改进系统性能 。真正能够成为使用关系数据库处理大数据且能具 备良好经验的专家型 SQL 开发人员相对较少 。
• 复杂的处理能力 ，包括自动实现任务并行化 ，以及当处理源不可用时具有自动容 错能力等 。
• 将图形化数据转换模块 一步转化为其物理等价物 。

  不要指望在 DW/BI 项目的第 1 阶段就能收回 ETL 工具的投资 。由于学习曲线非常陡 峭，导致开发者有时感觉通过编码的方式可能会使项目开发更快 。对ETL 工具投资的好处 在后续的过程中，特别是在未来对系统改进时才能逐渐显现出来 。

2.3 第 3 步：开发默认策略

  对什么可能会发生以及什么是 ETL 工具的基本需求进行总体考虑 ，应当针对 ETL 系 统中的公共活动开发默 认策略 。这些活动包括 ：
• 从每个主要的源系统获取数 据 。在设计过程的这一点上 ，您能决定从每个源系统 获取数据的默认方法 。您通常将来自源系统的数据放入平面文件中吗 ？是从数据 流获取的吗 ？是利用工具读取数据库日志吗 ？是采用其他方法吗 ？这一决定可以 逐表进行修改 。如果使用 SQL 访问源系统数据 ，则确保利用本地数据获取器而不 是使用 ODBC ，如果存在这样 的选项的话。
• 归档获取的数据或分级的数据 。获取的或分级的数据在被转换前 ，应该被归档至 少一个月。有些组织对获取的和分级的数据采取永久归档的策略 。
• 监管维度和特定事实 的数据质量 。应在 ETL 处理过程中监控数据质量 ，而不应当 在用户发现问题时才开始监控数据质 量。子系统 4 到子系统 8 描述了度 量和响应数据质量问题的完整结构。
• 维度属性变化的管理。我们在 ETL 子系统 9 中描述了管理维度属 性变化所需要 的逻辑。
• 确保数据仓库和 ETL 系统满足系统可用性需求 。满足可用性需求的第 l 步是将它 们文档化 。当每个数据源开始使用时以及在高层任务序列中被完成时 ，应当将它 们文档化 。
• 设计数据审计子系统 。数据仓库表中的每行应该用相关审计信息标记 ，用以描述 数据如何进入系统 。
• 组织 ETL 过渡区。多数 ETL 系统在 ETL 处理过程中至少有 1 次或 2 次将数据放入过渡区中 。通过过渡方式 ，数据将被写入磁盘中 ，用于后续的 ETL 步骤以及系 统恢复和归档工作 。

2.4 第 4 步：按照目标表钻取数据

  在开发完所有的公共ETL任务后 ，应当开始深入研究详细的转换工作 ，以填充数据仓 库中的目标表 。在完成源到目标的映射后 ，您将完成更多的数据概要描述工作 ，以完整理 解每个表和列所需要的数据转换 。

1. 确保层次的清楚性
     研究维度数据中存在的层次 关系是否被清楚 地描述是非常重要的工作 。考虑包含从 产品库存单元（SKU)到产品分类层次上卷的产品维度 。
     以我们的经验来看，最可靠的层次应当在源系统中管理 。最好的源系统规范化层 次， 将不同级别放入多个表中 ，两个级别间以外键关联 。在此情况下 ，可以相信层次级别是 清 楚的。如果源系统没有被规范化，特别是如果包含层次的源是业务用户的台式电脑的 Excel 电子报表时 ，则您必须要么对其进行清洗 ，要么承认没有层次存在 。

2. 开发详细的表示意图
     下图描述了可方便用于特定表下钻的细节 层次，该图描述了前述公用事业公司案例 的一个表。

   
   
   image.png

  在对事实表执行关键查询步骤 前，所有维度表必须经过处理 。维度表相互之间通常是 无关的 ，但有时它们也存在过程依赖 。分清这些依赖是非常重要的 ，因为它们是任务控制 流程的固定点。

2.5 开发 ETL 规范文档

  我们已经讨论了一些用于ETL系统的高层规划和物理设计的一般策略 。现在应该考虑 将所有情 况统一起来并为整个 ETL 系统开发详细规范 。
到目前为止，所有文档开发一 一源到目标的映射 、数据档案报表 、物理设计决策都应当进入 ETL 规范的第一部分 。然后文档化所有本章所讨论的相关决策 ，包括 ：
• 从每个主要的源系统获取的默认策略 。
• 归档策略 。
• 数据质量跟踪和元数据 。
• 管理维度属性变化的默认策略 。
• 系统可用性需求与策略 。
• 数据审计子系统的设计 。
• 过渡区的定位 。

  ETL 规范的下一个部分描述每个表的历史和增量加载策略 。好的规范其每个表都包括 几页细节 ，文档化下述信息和决策 ：
• 表设计（列名 、数据类型 、键和约束）。
• 历史数据加载参数（月数）和容量（行计数）。
• 增量数据容量 ，对每个加载周期涉及的新的和史新的行 。
• 处理事实表和维度表的迟到数据 。
• 加载频率 。
• 处理每个维度属性的缓慢变化维度（ SCD）变化。
• 表分区 ，例如按月 。
• 数据来源概述 ，包括讨论所 有不常见的源特征 ，例如不常见的简短存取窗口 。
• 详细的源到目标的映射 。
• 源数据概要 ，包括每个数字列的最小值和最大值 ，每个列中出现的不同值的计数 ， 包括空值的发生率 。
• 源数据获取策略 （例如 ，源系统的 API 、直接从数据库查询或转储到平面文件）。
• 依赖 ，包括某个表在处理前必须加载哪些其 他表。
• 文档化转换逻辑 。该部分最好用伪代码或图 表来撰写 ，而不是试图手工编制完整 的句子。
• 避免产生错误 的前提条件 。例如 ，在继续开展工作前 ，ETL 系统必须检查文件或 数据库空间。
• 清洗步骤，例如删除工作文件。
• 估计该部分 ETL 系统实现是容易、中等程度或难于实现。

注意：
  尽管多数人赞同 ETL 系统规范文档中描述的所有项都是必要的 ，但要将这些文档汇总 到一起需要花费大量的时间 ，当 变化发生时 ，要保持当前状态需要更多 的工作。实际上， 如果您将 “一份” 高层流程图 、数据模型和数据源到目标的映射 ，以及有关您计划做什么 的几页描述放在一起 ，您将会获得比其他大多 数小组史好的开始 。

开发一个沙箱源系统
  在ETL开发过程中 ，需要对源系统数据进行深入的调查 。如果源系统加载数量较大 ，且 不存在操作型查询的报表实例 ，DBA 可能愿意为 ETL 开发小组设置数据库静态快照 。在开发过程初期 ，浏览源系统的沙箱版本是比较方便的 ，不需要担心会推出一种致命的查询 。
  建立沙箱源系统比较容易 ，可简单地拷贝源系统 。只有当数据容量非常巨大时，才建 立一个包含数据子集的沙箱 。好处是，这种沙箱在系统投产后 ，可成为培训教材和教程的 基础。

三. 开发一次性的历史加载过程

  ETL 规范建立完成后 ，您通常会关注开发 一次性加载历史数据的 ETL 过程 。偶尔 ，同 样的 ETL 代码可用于完成初始历史数据加载和后续的增量加载 ，但通常会为初始历史数据 加载和后续加载建 立不同的 ETL 处理过程 。历史和增量加载过程有许多共同点 ，与 ETL 工具有关 ，主要的功能是可以重用的 。

3.1 第 5 步：用历史数据填充维度表

  一般来说，在开始建立 ETL 系统时 ，会采用最简单的维度表 。在这些简单 的维度表被 成功建立后 ，可以处理包含一个或多个其列具有 SCD类型 2 的维度表的历史数据加载工作 。

3.1.1 填充类型 1 维度表

  最简单的表填充类型是那些所有属性都包含类型1重写的维度表。在只包含类型1的维度中，直接从源系统获取每个维度属性的当前值 。

3.1.2 维度转换

  即使是最简单的维度表也可能需要大量的数据清洗工作并需要为其分配代理键 。

1. 简单数据转换
     最常见、最简单的数据转换形式是数据类型转换 。所有ETL 工具都具有丰富的数据类
   型转换功能 。执行该任务是非常乏味的工作 ，但几乎不会出现麻烦 。我们强烈建议以默认 值替换维度表中可能存在的空值 。正如前文所讨论的那样 ，在直接对其进行查询时 ，空值 可能会出问题 。

2. 不同源的数据合并
     通常维度来自几个源 。客户信息可能需要融合几个业务工 页 ，且这些业务项可能来自外 部源 。通常不同源很少具有通用的预先嵌入的键 ，这种情况会导致融合操作非常困难 。
   如果首先将名称和地址分解为组成部件 ，则多数整合和重复数据删除工具及过程用起 来非常方便 。然后可以使用多遍模糊逻辑发现拼写错误 、打字错误 ，并对拼写进行整合 ， 例如整合诸如 I.B.M. 、IBM 或 International Business Machines 这样的拼写 。多数组织中 ， 都具有大型的一次性项目用于整合现存客户 。对主数据库管理系统来说 ，这一工作具有巨 大的价值。

3. 产品码解码
     数据预处理中常见的融合工作是为 产品码查找文本等价解释 。有时，文本等价物是来 自非产品源 ，例如电子报表的非正式来源 。代码查找通常存储在过渡区的数据库表中 。确保ETL系统包含建立默认解码文本等价物的逻辑 ，不要出现产品码不在查找表中的情况 。

4. 验证多对一和一对一关系
     最主要的维度可能具有一个或多个上卷路径 ，例如产品上卷到产品模型 、子分类和分 类，如下图 所示 。针对这些层次的 上卷需要非常清楚的层次 。

   
   
   image.png

  属性间的多对一关系，例如产品到产品模型 ，可 以通过排序“多” 属性检验并验证“ 一” 属性具有唯一值 。例如，下列查询返回包含多个产 品模型的产品：

SELECT ProductSKU , count(*)   a s RowCount,
count(distinct ProductModel) as ModelCount FROM StagingDatabase.Product
GROUP BY  ProductSKU
HAVING count(distinct ProductModel)  > 1

  数据库管理 员有时希望通过将数据 加载到过渡 区数据库中的规范维度表雪花版本来 验证多对一关系，如下图所示 。注意规范版本需要在层次的每个级别上具有独立建 。如果源系统支持该键 ，则不会出现任何问题 ，但是 如果您将ETL环境中的维度表规范化，则需要建立这些键。

image.png

  雪花结构在过渡区中具有某种价值 ：它可以防止您加载那些违反多对一关系的数据。 然而 ，一般来说 ，正如刚刚讨论过的那样 ，关系应该预先被验证 ，这样就不会将坏数据加载到维度表中 。在数据已经经过预先验证的情况下 ，在加载表时是否需要数据库引擎重新 证实表之间的关系就显得不那么重要了 。

  如果维度层次的源系统是 一种规范化的数据库 ，通常在 ETL 过渡区不需要重建规范化 的结构。然而 ，如果层次信息来自非规范的数据源 ，例如市场部门管理的报表 ，则可能会从对 ETL 层次的规范化工作中受益。

5. 维度代理键分配
     在确信维度表中每一行都是真正唯一的维度成员后 ，可以开始分配代理键的工作 。应 当在 ETL 过渡区数据库中维护 一张匹配代理键与 生产键的表 ，这样可 以在后续的事实表处 理期间利用表中的键映射 。
     代理键通常以整数形式分配 ，对每个新键 ，其代理键进行加 l处理。如果过渡区包含 在 RDBMS 中，代理键分配可通过建 立序列方便地实现 。尽管不 同的关系引擎可能会有语 法上的差异 ，但过程都是首先建立序列 ，然后填充键映射表 。
   以下给出了一次性建立序列 的语法：

create   sequence   dim1_seq   cache= 1000 ；一  choose   appropr iate   cache   level

  后续填充键映射表的语法如下 ：

insert into dim1key_map ( production_key_id , diml_ key ) select  production_key_id, dim1_seq .NEXT from  dim1extracttable;

3.1.3 维度表加载

  维度数据准备完成后 ，加载到目标表的过程相当直接 。即使第 1个维度表相对较小 ， 也可利用数据库的批量或快速加载实用程序或接口 。对大多数表插入操作来说，可以使用快速加载技术 。有些数据库对SQL语法进行了扩展 ，包括 了 BULK INSERT 子句。而有些 数据库发布了 API 以通过数据流加载到数据表中。

  批量加载实用程序和 API 包含一系列参数 ，包括以下的转换能力：
• 关闭日志 。事务日志显著地增加了开销，在加载数据仓库表时几乎没有什么价值。 ETL 系统应该设计一个或多个具有可恢复性 的点，一旦 出现错误，您可在此重新 开始处理过程 。
• 快速模式批量加载 。然而，多数数据库引擎的批量加载实用程序或 API 需要 目标 表满足几个严格的条件 ，才能执行快速模式 的批量加载。如果这些条件 未被满足， 则加载将会失败 。不使用 “ 快速” 模式要简单得多。
• 文件预排序 。按照主索引顺序对文件进行排序将显著地加快索引操作 。
• 谨慎转换 。某些情况下 ，加载器支持数据转 换、计算 ，以及字符 串和日期／时间操 作。使用这些特性时要仔细并注意要 测试性能。某些情况下 ，这些转换操作会导 致加载器关闭高速模式 ，进入对加载文件按行 处理的模式 。
• 在开始完全刷新之前执行截断表操作 。TRUNCATE TABLE 是最有效 的删除表中 所有行的子句 。在开始一天的 ETL 处理前通常可使用该子句清除 过渡区数据库中 表的 内容。

3.1.4 加载类型 2 维度表历史

  维度表属性变化通常是按照类型 1（重写）或类型 2（通过在 维度表中增加新行以跟踪历史）管理的 。多数维度表包含类型 1 和类型 2 属性 。

  在历史加载期间 ，需要重建那些按照类型 2 来管理的维度属性的历史 。如果业务用户 确定某个属性对跟踪历史来说非常 重要 ，则他们希望能够及时获得历史情况 ，而不是仅仅 从数据仓库实现 的时间开始。通常重新建立维度属 性历史是非常困难的工作 ，有时甚至是 不可能实现的工作。

  该过程并不适合用标 准 SQL 处理 。最好利用数据库游标构件 ，甚至更好的 处理方法是， 使用过程语 言（例如 Visual Basic 、C 或 Java）来执行这一工作 。多数 ETL 工具使用脚本处理 流过 ETL 系统的数据。

  重构历史的 工作完成后 ，最后一启要浏览数据 以设置行结束 日期列。重要的是在此 序列中没有差异 。如果行的日期粒度为整天的话，我们宁愿将旧版本的维度成员的行结束日期设置为新行的行生效日期 。如果生效日期和结束日期包含准确的日期 ／时间戳，其精度到分或秒，则结束日期／时间必须被设置为下一行的开始日期／时间 ，这样就消除了行间的差异。

3.1.5 对日期和其他静态维度的填充

  几乎所有数据仓库都包含日期维度 ，通常其粒度为每天 一行。日期维度通常涉及数据 的历史范围 ，从数据仓库中最早的 事务事实开始。为历史数据设置日期维度是比较容易的， 因为您知道被加载的历史 事实数据的日期范围。多数项目通过手工建 立 日期维度，通常建 立在一个电子报表中 。

  大量其他维度可以以同样的方式建立 。例如 ，您可以建立包含实际和预算值的预算场 景维度 。业务数据管理代表应当对所有构建的维度表签字负责 。

3.2 第 6 步：完成事实表历史加载

  一次性事实表历史数据加载与后续的增量加载过程有比较大的差别。在加载历史数据 时最大的疑虑是数据量 ，有时其加载的数据量是 日常增量加载数据量的几千倍。另一方面， 您有幸将那些未在生产系统中的数据加载到表中 。如果历史数据的加载需要几天的时间才能完成，您就会感到难以忍受 。

1. 历史事实表获取
     当您确定了那些满足获取基本参数的记录后，要确认这些记录是否对数据仓库有用 。 多数事务系统在其源系统中所保存的操作型信息可能从业务角度来看没有什么意义 。
     在该步骤中 ，积累审计统计信息是一个好主意。当通过获取建立结果集后 ，通常可以 获得小记、总计和行计数信息 。

2. 审计统计信息
     在 ETL 系统的规划阶段 ，您会确定各种针对数据质量的度量 。这些度量通常是可计算的，例如计数和汇总，可以比较数据仓库和源系统的数据以交叉检查数据 的完整性 。这些数值可联系操作型报表及数据仓库加载过程的结果 。能够回朔到操作型系统是非常重要的， 因为它是建立可信任数据仓库的基础。

注意：
  在某些场景中，想要从数据仓库建立与源系统的反向联系是不大容易实现的 。多数情 况下，数据仓库获取包括未被应用到源系统的业务规则 。更令人苦恼的是源系统中的错误 。 另外，时间上的差异也使得交又检查变得异常困难 。如果无法实现数据的反向联系 ，则需要解释其中的差异 。

3. 事实表转换
     多数项目中 ，事实数据相对比较干净 。ETL系统开发者花费大量的时间改进维度表的 内容，但是事实通常需要适度的转换。多数情况下，当来自事务系统的事实被用于组织的执行时 ，这一工作非常有意义 ，
     针对事实表最常见的转换包括空值转换 、旋转或逆透视数据，以及预先计算导出计算 。 此后，所有事实行进入 ETL 系统代理键流水线 以将自然键转换为 ETL 系统管理需要的维度代理键。

1） 空事实值
  所有数据库引擎都支持空值 。然而 ，在大多数源系统中 ，空值都被表示为合法事实 的 一个特殊的值 。也许用特殊值1表示空值。对大多数事实表度量来说 ，其场景中的 “ 1” 应该被真正的 NULL 取代。空值用于数字度量在多数事实表中是合理的 、常见的 。在跨事实行计算汇总和平均时 ，空值能够执行 “ 正确的事情”。仅在维度表中您应当尽力将空值替 换为特殊的专 门制定的默认值 。最后 ，不应当允许以事实表列中的空值引用维度表键 。这 些外键列应当始终被定 义为非空(NOT NULL）。

2） 改进事实表内容
  正如我们所强调的那样 ，最终事实表行的所有事实必须以同 一粒度表示 。这意味着在 以天为粒度的事实表中不会存在表示年汇总情况的事实 ，也不会存在对某些 地理情况的汇 总比事实表粒度大的情况。如果获取包括不同粒度的交错的事实 ，则必须要消除这些聚集 ， 或者将它们移入适当 的聚集表中 。
  事实行包括导出的事实 ，尽管在多数情 况下 ，在视图中或联机分析处理（ OLAP）多维数据库中而不是在物理表中计算导出事实效率会更高 。例如 ，包含收入和成本的事实行可能希望表示净利润的事实 。重要的是尽量在用户需要获取净利润时通过计算得到 。如果数据仓库要求所有用户通过视图访问数据，则最好在视图中计算净利润 。如果允许用户直接访 问物理表 ，或者如果用户经常过滤净利润从而使您想要对它进行索 引时，则最好是预先计 算出净利润并物理地存储它 。
  类似地 ，如果一些事实需要同时表示多种度量单 位 ，可以采用同样的逻辑 。如果业务 用尸通过视图或 OLAP 多维数据库访问数据，最好在用户访问时计算各种不同版本的事实。

3） 维度代理键查询流水线
  在事实表与维度表之间保持参照完整性是非常重要的，事实行不会引用不存在的维度成员。因此，事实表中的所有外键不应存在空值 ，所有事实行对任何维度不会违反参照完整性 。
  代理键流水线是将数据 加载到目标事实表 的最终操作。此时所有清洗 、转换和处理都己经完成。输入数据看起来类 似维度模型中 的目标事实表 ，只是其仍然包含从数据源获得 的自然键而没有用数据仓库的代理键 替代。代理键流水线过程负 责交换自然键与代理键井 处理所有参照完整性错误 。
  在事实数据进入代理键流水线前 ，维度表必须处理完成 。任何新的维度成员或已经 存在的推度成员的类型 2 变化必须都处理完成 ，这样它们的键对代理键流 水线来说才是可用的。
  首先来讨论与参照完整性有关的问题 。确认维度表中每个历史数据事实包含自然键是非常简单的事情 。这一步骤是手工完成的步骤 。此时，历史加载暂停，以便您能够在处理前检查并修改任何的参照完整性问题 。要么修改维度表 ，要么重新设计事实表获取以过滤错误行 ，具体可视情况而定。
  现在己确信不存在参照完整性错误 ，您可以设计历史代理键流水线 。 在此场景中 ，在加载历史事实度量时，您可以针对所有受到影响的包含类型 2 变化的维度 使用 BETWEEN 逻辑以定位维度行 。
  可以采用几种方法设计历史加载的代理键流水线以提高其性能 ，其设计取决于所使用的 ETL 工具的特性、需要处理的数据容量以及维度设计。理论上说，您可以定义一个查询 ， 通过自然键实现事实过渡表与每个维度表的连接 ，该查询返回事实和来自所有维度表的代理键 。如果历史数据容量不是很大 ，假定您将过渡事实数据放在关系数据库中并且为支持 该大型查询对维度表建立了索引 ，则这种方法效果很好 。使用该方法的好处包括 ：
• 该方法利用了关系数据库的强大功能 。
• 使用并行技术完成代理键查找 。
• 该方法简化了获得正确的类型 2 维度的维度键存在的问题 。连接到类型 2 维度必 须包含定义为表中维度成员的事务日期分类在行有效日期和行失效日期之间的子句。
  如果历史事实数据容量大到几百GB或几TB时，没有人愿意采用上述方法 。与类型2 维度表的复杂连接对系统资源构成了巨大的威胁 。大多数维度设计包括数量巨大（但每个表本身不大）的类型 1 维度表 ，只有少量的维度包含类型 2 属性。您可以使用这一关系技术一 遍执行对所有的类型 1 维度的代理键查找 ，然后对类型 2 维度另行处理 。您应当确保对有 效日期和结束日期列建立了适当的索引 。
  如果不使用数据库连接技术 ，可以采用 ETL 工具的查找操作符 。 当所有事实源的键被用代理键替换后 ，就可以加载事实行了 。事实表行中的键被选为不同维度表的适当外键 ，事实表与维度表满足参照完整性要求 。

4） 分配审计维度键
  事实表的每个行通常都包含一个审计键 。审计键指向描述加载特征的审计维度 ，审计维度包括相对静态的环境以及数据质量度量 。审计维度可以很小 。最初设计的审计维度仅包含两个环境变量（主 ETL 版本号和利益分配的逻辑号）和一个质量标志 ，该标志的值是 Quality Checks Passed（质量检查通过）和 Quality Problems Encountered （发生质量问题）。随着时间的推移 ，这些变量和诊断指标可能会变得非常复杂和详细 。增加到事实表的维度审计键要么在代理键流水线之前立即增加 ，要么在之后立即增加。

4. 事实表加载
     加载事实表时主要关注的是加载性能 。一些数据库技术支持包含特定批量大小的快速加载 。可通过查阅有关快速加载技术的文档 学习如何设置这一参数 。您可以通过实验发现 理想的以行数量计的批量大小以及服务器内存配置 。多数人不愿意为实现准确执行而采取 一种简单地选择数量（例如 ，10 000 、100 000 或 l 000 000）的方式 。
     除了使用批量加载器以及合理的批量大小（适合数据库引擎的）外，改进加载历史数据性能 的最好方式是加载到分区表中 ，理想情况可以并行加载多个分区 。加载到分区表的步骤包括 ：
   (1） 在加载数据前 ，禁用事实表与每个维度表之间的外键 （参照完整性）约束
   (2） 删除或禁用事实表的索引
   (3） 使用快速加载技术加载数据
   (4） 建立或启用事实表索引
   (5） 如果有必要 ，将分区表合并到 一起
   (6） 确认每个维度表在代理键列具有唯 一索引
   (7） 启用事实表与维度表之间的外键约束

四. 开发增量式 ETL 过程

  增量 ETL 过程的最大挑战之一是区分新的 、发生变化的以及被删除的行 。在插入 、删除、更新流处理之后 ，ETL 系统可以按照几乎相同的历史数据加载业务规则执行转换工作 。
  维度和事实的历史加载包含大量的或整个的插入工作 。在增量处理过程中 ，主要执行 插入 ，但对维度表和某些事实表的更新是不可避免的 。更新和删除在数据仓库环境中是非常昂贵的操作，因此我们将描述改进这些任务执行性能的技术 。

4.1 第 7 步：维度表增量处理过程

  正如您所期望的 ，增量 ETL 系统开发是从维度表开始 。维度增量处理与前文描述的历史处理类似。

1. 维度表获取
     多数情况下，客户主文件或产品主文件都可以成为维度的单一来源 。另外也存在一些 情况，原始来源数据既涉及维度也涉及事实数据 。
     通常最简单的方法是将维度表当前快照组织为 一个整体并通过转换步骤确定什么发生了变化以及如何处理变化 。在大型维度表中查找每个条目需要花费大量的时间 ，即使变化发生在存在的条目上。
     如果可能，构建只获取那些发生变化的行 。如果源系统维护 一个变化类型的指示器的 话 ，这样做特 别方便且有价值 。

2. 识别新的和变化的维度行
     DW/BI小组将识别新的 、更新的、删除的行的责任推给源系统拥有者将带来巨大的问 题。在此情况下，ETL 过程需要执行昂贵的比较操作以发现新的和变化的行 。
     若输入数据是干净的 ，则非常容易发现新的维度行。原始数据具有操作型自然键 ，该键必须与当前维度行的同样的列匹配 。记住 ，维度表中的自然键就是一个普通的维度属性 ， 它不是维度的代理主键。
     通过针对主维度的输入流执行查询，比较自然键，可以发现新的维度成员 。不满足查询条件的所有行均为新的维度成员，应该将它们插入到维度表中。
     如果维度包含类型 2 属性 ，将行中有效日期列设 置为维度成员出现在系统中的日期 。 如果是在晚间处理该工作，那么这个时间通常是昨天。将行结束日期列设 置为 当前行的默 认值 。这个值通常 是系统能够支持的，指向遥远未来的最大的日期 。应当避免在结束日期 列使用空值，因为如果试图将某一特定值与空值进行比较 ，则关系数据库可能会产生错误 或返 问未知的特殊值 。
     一步是确定到来的维度行是否有变化。最简单的技术是一列一列地对输入数据与存储在主维度表巾的当前对应成员进行比较。
     如果维度比较大，包含 100 万行 ，采用简单的列问比较的技术可能 太慢，特别是如果维度表中的列还比较多的情况下。比较好的替换策略是使用哈希或校验功能加快比较处理的速度。可以在维度表中增加两个新的管理列 ：哈希类型 1 和哈希类型 2 。应当在哈希类型 1 列放置连接类型 1 属性的哈希值 ，同样道理应用于哈希类型 2。哈希算法将非常大的字符串转换为相对小得多的且几乎具有唯一性的值 。哈希值在维度表中计算及存储 。然后用完全相同的方法对输入行集合计算哈希值 ，并将它们与存储的值比较 。与单一的 、相对较短的字符串列比较比成对比较大量不同列的方法更有效 。另外，关系数据库引擎可能包含类似 EXCEPT 语法能够确保高性能地执行发现改变行的查询。
     作为一种一般性的原则 ，不应当删除己经在源系统中被删除的维度行 ，因为这些维度 成员仍然可能与数据仓库中的事实表数据存在关联 。

3. 处理维度属性的变化
     ETL 应用包含确定如何处理己经存储在数据仓库中的属性值变化的业务规则 。如果修 改的描述被认定是对先前信息的合法的且可靠的更新，则必须使用缓慢变化维度技术 。
     准备维度行的第 1 步是决定是否已经拥有该行 。如果所有的输入维度信息与维 度表中 的对应行匹配，则不需要采取进 一步的行动 。如果维度信息发生了变化 ，则可以将变化应 用到维度中 ，例如类型 1 或类型 2。

注意：
  类 型 3 需要改变维度表结构 ，建立新的列 集合以拥有该属性的 “先前” 与 “ 当前” 版本。此 类结构化改变很少应用到 ETL 系统中 ，更常见的是作为数据模型的 一次性变化来处理 。
处理获取阶段的变化维度记录的查询和键分配逻辑 。在此情况下 ，逻辑 流程并不能使输入数据流限制于仅仅针对新的或 变化的行 。

image.png

4.2 第 8 步：事实表增量处理过程

  多数数据仓库都非常巨大 ，因此要在一个单一时间窗口内完全替换事实表是很难实现的。相反 ，新的和更新的事实行都采用增量处理方式 。

注意：
  只加载那些在上一次加载完成后发生变化和新增的记录是非常有效的方法 。这种情况特别适合具有杂志风格的系统 ，其历史绝不会发生改变 ，仅允许对当前期进行调整 。

  事实表增量处理的 ETL 处理过程与历史加载不同，历史ETL处理不需要完全实现自动化，您可以暂停该过程以检查数据并为下一阶段做好准备 。作为比较 ，增量处理必须完全自动地完成。

1. 事实表获取与数据质量检查点
     一旦从源系统获得了发生变化的和被更新的事实行，就必须在过渡区中建立一个未转换数据的拷贝。同时，对有关原始获取数据 的数据质量度量开展计算工作 。数据过渡包含三种意图 ：
   • 为实现审计归档。
   • 为后续的数据质量验证提供开始点 。
   • 为重启过程提供开始点 。

2. 事实表转换与代理键流水线
     增量事实数据的代理键流水线与历史数据的代理键流水线类似 。主要的差别在于违反参照完整性的错误处理方面 ，增量事实处理必须自动化执行。处理违反参照完整性的方法 有以下几种：
   • 终止加载 。这不是 一个常用的方法 ，但在大多数 ETL 工具中，该方法常常是默认的配置方法。
   • 抛弃错误行。某些情况下 ，丢失维度值是一种信号，表明数据与底层数据仓库的 业务需求不相关。
   • 将错误行写入文件或表中以便后续分析 。设计一种机制将 需要改正的行移入挂起 文件中 。对财务系统来 说，该方法不是一个好的选择 ，在这样的系统中 ，所有的行都需要加载。
   • 通过建立虚拟维度行并返回其代理键到流水线中对错误行进行修改 。在增量代理键流水线中最有吸引力的处理违反参照完整性错误的方法是在执行过程中为未知 的自然键建立虚拟维度行 。自然键是有关维度成员的仅有的信息块 ，所有其他属 性必须被设置为默认值 。当有关维度成员的详细信息可用时 ，该虚拟维度行将 以 类型 1 进行更新 。
   • 通过映射到每个维度中单一的未知成员修改错误行 。该方法不是我们推荐的方法 。 问题是，对所有事实表获取中得到的未知自然键值 ，所有错误行被映射到同 一个 维度成员上。

  对大多数系统来说，针对查询 、视图或物理表（维度表的子集）来执行代理键查找。维度表行被过滤，以便能够仅针对当前版本的每个维度成员进行查找工作 。

3. 延迟到来的事实与代理键流水线
     在大多数数据仓库中 ，增量加载过程都是在午夜后不久开始 ，同时需要处理前一天发生的所有事务 。然而 ，也存在一些事实延迟到达的情况 。这种情况通常发生在数据源是分布式的 ，处于多台机器上甚至是全球范围内的，连接或延迟问题导致不能及时完成数据收集工作。
     如果所有维度都以类型 1重写模式被管理的话，延迟到达事实不会存在什么特别的挑战。但是多数系统都同时包含类型 1 和类型 2 属性 。延迟到达的事实必须与事实发生时有 效的维度成员版本关联 。要实现这一工作需要对维度表中的行开始和结束有效日期进行查询。

4. 增量事实表加载
     在历史事实加载时，重要的是采用快速加载技术 。在大多数数据仓库中，对增量加载来说，这些快速加载技术是无法执行的 。快速加载技术通常对目标 表有严格的条件要求（例如，空或未索引） 。对增量加载来说 ，使用非快速加载技术通常比完全插入或索引表更快 。 对小型到中型系统来说，插入操作的性能通常是比较适合的。
     若事实表非常大 ，出于管理方面的考虑 ，应当对事实表进行分区 。如果增量数据始终 被加载到空的分区中 ，则可以使用快速加载技术 。在每天加载的情况下 ，您可能会在每年 建立 365 个新的事实表分区 。这样做 ，对那些包含较长历史的事实表来说 ，可能会建立了 太多的分区 。因此考虑设计一个将日分区合并为按周或按月进行分区的处理方法 。

5. 加载快照事实 表
     最大的事实表通常是事务型的 。事务事实表通常仅通过插入进行加载 。周期快照事实 表通常在月末被加载 。当前月的数据有时会在当前月至今的每一天被更新 。在此情况下， 按月的事实表的分区使 重新加载当前月的工作具有极高的性 能。
     累积快照事实表监控相对较短的存活过程 ，例如订单填充 。累积快照事实表的每个事实行在其整个生命周期中会多次发生改变 。尽管累积快照几乎总是比 其他两类事实表小得多，但对该表维护需要较高的成本 。

6. 加速加载周期
     仅处理那些发生变化的数据是加速 ETL 周期的办法之 一。下面介绍几种其他技术 。

1）提高加载频率
  尽管从按月或按周加载处理转变到每晚加载是 一个巨大的飞跃 ，但缩短加载窗口的确 不失为一种有效的方法 。每天晚上处理与每月处理比较 ，仅需要处理后者 1/30 的数据量。 多数数据仓库都采用每晚加载一次的周期。
  如果晚间加载成本太高 ，可以考虑在白天执行 一些针对数据的预处理工作 。白天时间将数据移动到过渡数据库或操作型数据库并在此执行数据清洗任务。午夜后，将维度成员的多个变化合并，执行最后的数据质量检查，分配代理键，最后将数据移入数据仓库中 。

2） 并行处理
  另外一种缩短加载时间的方法是并行 化 ETL 过程。并行化可以以两种方式展开 ：多步 并行化运行和单步并行化运行 。
• 多步加载 。ETL 任务流被划分为几个同时提交的独立任务 。您需要仔细考虑每个 任务涉及何种工作 ：主要的目标是建立 独立的任务 。
• 并行执行 。数据库本身也可以识别特定 的能够并行执行的任务 。例如 ，建立索引 通常可以在机器上可用的多个处理器中并行 处理。

注意：
  将过程划分为 并行执行的步骤包含好的方法和不好的方法 。并行化的简羊方法是获取所有源数据 ，然后加载并转换维度，最后同时在事实表和维度表中检查参照完整性 。遗憾的是，该方法可能不够快 一一也许会比更简单的顺序方法慢得多 ，因为每个并行处理的步 骤都需要竞争系统资源 ，例如网络带宽 、IO 和内存 。要构建良好的并行任务 ，不仅需要考虑步骤的逻辑顺序 ，也需要考虑系统资源 。

3） 并行结构
  您可能设置一种三方镜像或两个服务器 的集群配置以维护对数据仓库的连续加载 ，一个服务器管理加载，另外一个处理查询 。维护窗口将缩减到每天几分钟 ，用于交换附加在每个服务器上的磁盘 。这种方式是提供系统高可用性的最佳方式。
  按照对需求和可用性预算的要求，可以采用几种类似的方式实现表、分区和数据库 。 例如，可以离线加载分区或表 ，并以最小的停机时间交换它 ，使其在线可用 。其他系统包 含数据仓库数据库的两个版本 ，一个版本用于加载 ，一个版本用于查询 。虽然这样的方式效率并不高 ，但成本低，想要的功能可以由集群服务器提供 。

4.3 第 9 步：聚集表与 OLAP 加载

  从逻辑上来看 ，聚集表易于建立 。聚集表是将大型聚集查询结果存储到一个表中 。从针对事实表的查询来建立聚集表的问题，当然发生在事实表太大以至于无法在加载窗口内处理的时候。
  如果聚集表包括对日期维度的聚集结果，也许以月为粒度 ，聚集维护过程将更加复杂 。 当前月数据必须被更新 ，或者删除及重建 ，以反映当前天的数据 。
  如果聚集表是按照作为类型 1 重写的维度属性定义的 ，类似问题将会发生 。维度属性 的所有类型 1 变化将会影响所有的事实表聚集 以及按照该属性定义的 OLAP 多维数据库 。 ETL 过程必须将原有聚集层次 的事实删除并以新值替代 。
  保持聚集与底层 的事实数据同步是聚集管理系统中极其重要的工作 。如果查询直接面对底层细节事实或来自预先计算的聚集，则不要指望建立一个返回不同结果集的系统。

4.4 第 10 步：ETL 系统操作与自动化

  理想的 ETL 操作以熄灯的方式运行定期加载过程 ，而不需要人为干预 。尽管这是一个 很难达到的目标 ，但我们可以尽力接近这一理想 。

1. 调度任务
     调度任务通常是比较明确的 。ETL 工具应当包含调度任务并在一定时间开始的功能 。 大多数 ETL 工具还包含在第 一个任务成功执行完成后 ，协调执行第二个任务的功能 。通常将 ETL 任务流设置为在一定时间发起 ，然后查询数据库或文件系统 ，观察某个事件是否已 经发生 。
     还可以编写脚本执行此类控制任务 。每个ETL 工具具有从操作系统命令行激活任务的 途径。多数组织非常愿意使用脚本语言 ，例如 Perl ，来管理任务调度工作 。

2. 自动处理预料之中的例外和错误
     尽管开始工作是比较容易的 ，但要保证这些任务能够顺利完成 ，优雅地处理数据错误 和例外 ，就比较困难了 。综合错误处理在 ETL 任务的一开始就需要加以考虑并建 立。

3. 优雅地处理未知的错误
     有些错误是可以预料到的 ，例如 ，接受早到的事实或列中存在空值都是比较常见的 。 对这些错误 ，一般可以设计ETL系统来修改数据并继续处理 。而有些错误是完全无法预测的，其范围包括在处理过程中 ，由于经历停电导致接受混乱的数据。
     我们希望得到 ETL 工具特性和系统设计实践来帮助克服这些例外 。一般建议在事实表上为被加载的新记录配备单 一的顺序分配的代理键列 。如果某个大型加载任务遭遇到意外的停机，事实表代理键允许重新从可靠点开始加载 ，或者通过对范围连续的代理键进行约束延后加载 。

五. 实时的影晌

  实时处理是数据仓库中日益增长的常见需求之 一。数据仓库系统可能会存在强烈的实 时性需求 。一些业务用户希望数据仓库能够连 续不断地按天更新 ，对过时数据 一点也不感兴趣。建立实时 DW/BI 系统需要收集对实时数据业务 需求的准确的理解并确认适当的 ETL 结构，包括与固定平台配搭的范围广泛的技术 。

5.1 实时分类

  询问业务用户他们是否希望 “ 实时” 发布数据对于 DW/BI 小组来说是一个令人沮丧的经历 。在没有任何约束的前提下，多数用户回答说，“听起来不错 ，放手去做吧 ！” 这样的 回答基本上没有什么价值 。
  为避免出现这种情况 ，我们建议将实时设计面临的挑战划分为 三个类别 ，分别称为即时、日内和每天。在与业务用户讨论他们的需求和之后在设计我们的数据发布流水线时，都采用不同的选项进行讨论，并使用这些术语 。下表总结了不同的发布速度环境下将 产生的问题。

image.png

  即时（instantaneous）意味着屏幕上所 见的数据表示的是源事务系统每个时刻的真实状 态。当源系统状态发生改变时 ，屏幕将实时且同步响应 。即时性的实时系统通常作为企业 信息集成(Enterprise Information Integration , Ell）解决方案被实现，其源系统本身负责 主持 远程用户的屏幕更新并对查询请求提供服务 。显然，该类系统必须限制查询请求的复杂性 ， 因为所有的处理都是在源系统完成的 。Ell 解决方案通常包括不需要在 ETL 流水线上缓存数据 ，因为按照定义，ETL 解决方案在源系统与用户屏幕之间没有延迟 。某些情况下 ，可能边择采用即时性的实时解决方案 。库存状态跟踪可能是一个好的例子 ，其决策人员具有为客户实时提交可用库存的权利。

  日内（intra-day）意味着屏幕上可见的数据每天被更新多次，但是不 能保证这些当前被显示的数据肯定是最新的真实数据 。我们中的多数人都熟悉股票市场报价数据是当前15分钟内的数据，但并不是即时数据 。以一定频率发布实时数据（以及更慢一些的每天数据）的技术与即时实时数据发布的技术具有较大的差别。以一定频率发布数据通常被作为传统 ETL 结构中的微批量处理 。这意味着数据将经历各种各样的变化数据的捕获 、获取，过渡到 ETL 后端数据仓库的文件存储 ，清洗并执行错误检查 ，遵守企业数据标准 ，分配代理键以及可 能的其他一些转换工作使数 据准备好可以加载到展现服务器中 。几乎所有这些步骤 ，在一 个 ETL解决方案中必须被忽略或基本不存在 。日内发布数据和每天发布数据的主要差别在于前两步 ：变化数据捕获和获取 。为每天从源系统中多次捕获数据 ，数据仓库通常必须利用高带宽通信通道 ，例如遗留应用的消息队列流量 ，累积事务日志文件，或每当有事情发 生时米自事务系统低级别的数据库触发器等。

  每日（daily）意味着屏幕上可见的数据被当作批文件而在前一个工作日结束后从源系统中下载或调整是合法的 。对每日数据我们提供一些建议 。更正原始数据的过程通常在工作日结束时在源系统运行。当该调整可实现时 ，也标志着 ETL 系统执行一个可靠和平稳的数据下载 。如果您处于这样的环境中，应当向业务用户解释如果他们要求即时或日内被更新的数据时 ，他们将经历何种妥协 。每日更新数据通常涉及获得由源系统准备的批文件或者当源系统的就绪标志被设置后 ，通过执行获取查询获得 。当然，这是一种最简单的获取场景 ，因为您只需要等待源系统准备好并可用 。

5.2 实时结构权衡

  对实时需求的响应意味着您需要改变 DW/BI 结构，加快数据到用户屏幕的速度 。结构性的选择涉及对影响数据质量和管理的问题的权衡 。
  您可能认为ETL 系统所有者的总体目标是不要发生变化或通过转移到实时系统进行折中。您可能一如既往地考虑数据质量、集成 、安全、兼容性 、备份、恢复和归档等问题， 这些问题在开始设计实时系统前已经在做 。如果您有同感 ，那么请仔细阅读后续部分 ！后 续部分讨论当需要构建具有更实时性的结构时需要考虑的典型权衡 。

1. 替换批处理文件
     考虑将批处理文件获取替换为从消息队列或事务日志文件中获取 。源系统发布的批处理文件可以表示一种被清洗且具有一致性的源数据 。批处理文件可包含那些完成的事务的结果的记录 。批处理文件中的外键可能被分解 ，例如当文件包含某个其完整的身份可能被 发布到批处理文件中的新客户的订单时 。另一方面，消息队列和日志文件数据是原始的即时数据，可能并不属于任何源系统中的更正过程或业 务规则执行 。最坏的情况下 ，这样的原始数据有三种可能 ：①因为额外的事务可能尚未到达而未被更正或完成 ：②包含 DW/BI 系统尚未处理的未分解的外键 ；③需要并行化的面向批处理的 ETL 数据流来更正甚至替换 每天 24 小时的最新的实时数据 。如果源系统随后对消息队列或日志文件中的输入事务应用复杂的业务规则，则您真的不希望在ETL 系统中重新执行这些业务规则 。

2. 限制数据质量检查
     考虑限制仅针对列检查的数据质量检查并简化解码查询。由于通过 ETL流水线的数据处理时间被缩减了 ，因此可能需要去掉一些高开销的数据质量检查 ，特别是结构方面的以及业务规则方面的检查 。记住列检查涉及单一字段测试与／或简单查询以替换或扩展己知值。即使在最为激进的实时应用中 ，也应当保留大多数的列检查 。但是按照定义 ，结构检查和业务规则检查需要多个字段 ，可能涉及多个表 。您可能没有时间传递字段的地址块到某个地址分析器中去 。您可能不需要检查表间的参照完整性。您可能无法通过 Web 服务执行远程信用检查 。所有这些可能都需要通知用户 ，他们使用的数据是临时的且存在不可靠状态的原始实时数据 ，可能需要您实现并行的面向批处理的 ETL 流水线 ，用于周期性地以检查后的数据重写实时数据 。

3. 连接事实与维度
     应当允许早先得到的事实与旧版本的维度共存 。在实时环境下 ，通常事务事件被接收到了 ，而其环境尚未更新（例如客户的身份） 。换句话说 ，事实在维度到达前就先到了 。如果实时系统不能等待维度 ，则如果维度可用的话 ，必须使用维度的旧拷贝 ，或者使用具有一般性的空的维度版本 。如果收到修改后的维度版本 ，则数据仓库可能会决定将它们放入热分区或延迟更新维度直到批处理过程接管为止 ，可能在一天的结束时 。无论如何，用户需要理解可能会存在短暂的时间窗口，其维度无法准确地描述事实 。

4. 消除数据过渡区
     某些实时结构 ，特别是 Ell 系统，流数据直接从生产源系统到用户的屏幕 ，并未将数 据写入ETL流水线中的持久性存储中 。如果此类系统是由 DW/Bl 小组负责的，则小组应当与高级主管就是否需要备份 、恢复、归档，以及兼容性是否能够满足或者这些责任现在 是否是生产源系统唯一的关注等进行严肃的讨论。

5.3 展现服务器上的实时分区

  为支持对实时性的需求，数据仓库必须无缝地扩展其己经存在的历史事件序列到当前时刻。如果客户在前一个小时发出订单 ，那么您需要在完整的客户关系环境中看到这一订单 。此外，您想要跟踪这些最新订单每小时的状态以及在一天中 的变化情况 ，即使生产事务处理系统与 DW/BI 系统之间存在的差别己缩减到 24 小时 ，业务用户的即时性 需求也仍 然需要数据仓库以实时数据填充其间存在的差异。

  响应这一处理的设计解决方案之一是建立实时分区 ，将其作为传统的静态数据仓库的一种扩展 。为实现实时报表 ，建立一种特殊的分区 ，其物理存在和管理与传统数据仓库表分开 。理想情况下，实时分区是一种真实的数据库分区 ，其中正在考虑的事实表按照活动日期分区。
无论发生何种情况 ，理想的实时分区应当满足下列难办的需求集合 ：
• 包括上一次更新静态数据仓库 以来发生的所有活动。
• 尽可能无缝连接静态数据仓库事实表的粒度和内容 ，作为理想的真正的事实表物 理分区 。
• 被轻巧地索引而到达的数据能够不断地 “ 滴入”。 理想情况下 ，实时分区应当完全不用索引 。然而 ，这在某些 RDBMS 中是不可能实现的，其建立的索引与分区 模式逻辑上是不同的 。
• 即使缺乏索引，通过将实时分区放入内存中，也可以支持高度敏感的查询 。 是在事务和周期快照事实表中 ，实时分区都可 以被有效地使用。我们还未发现需要将这种情况用累积快照事实表的情况。

1. 事务实时分区
     如果静态数据仓库事实表存在事务粒度 ，那么它对源系统中的每个独立事务从 “ 被记求的历史” 开始包含确切 的一行。这样的实时分区与其底层的静态事实表具有同样的维度结构 。它仅包含上一次您定期加载事务事实表直到午夜为止的事务 。实时分区可能完全未被索引，原因可能是囚为您想要维护 一个不断开放的加载窗口 ，也可能是因为没有时间序列（因为 ，表中仅保持今天的数据 ）。
     在相对比较大的售业环境中，大约每天会产生 1000 万事务 。静态事实表会很人 。假设句个中务粒皮行包含 40 个字节宽（7个维度加上 3个事实，都被包装到 4 个字节的列中）。 每天将会积累 400MB 的数据。一年后 ，这一数据会达到约 150GB 的原始数据。此类事实点包含大量的索引并支持聚集 。但是 400MB 的每日实时分片可以放到内存中。实时分区趋向非常快的加载性能 ，但是同时提供快捷的查询性能 。

2. 周期快照实时分区
     如果静态数据仓库事实表具有周期粒度（例如按月），则实时分区可被视为当前热滚动月。假设有一个包含 1500 万账户的大型零售银行 。账户的静态事实表粒度是以月为基础的。36 个月的时间序列将在事实表中产生 5.4 亿行事实 。另外，该表可能存在大量聚集索引以提供良好的查询性能。另一方面 ，实时分区仅仅是当前月的图像，随着月的变化 ，会不断被更新 。半可加的余额和完全可加的事实在报告期被频繁地调整 。在零售银行 ，涉及所有的账户类型的超类事实表可能非常窄 ，也许包括4个维度和4个事实 ，产生的实时分 区可能有 480MB 。实时分区仍然可以放入内存中 。
     在月末的那一天 ，周期实时分区可以比较幸运地仅仅融合大多数当前月中少 量的不稳 定的事实表 ，再次开始时可以将实时分区清空 。

参考:

1. 《数据仓库工具箱 维度建模权威指南》第三版