ETL系列专题6——Load之FactLoad

ETL系列专题6——Load之FactLoad

Warren

zqw_qw@hotmail.com

事实表包含企业业务分析所需要的量度，通常表现为数值型数据。那么事实表和量度的关系怎样？可以这么理解，如果有一个量度，那么它会存在于事实表中的一行记录中。

事实表的基本结构

事实表的粒度，我们知道事实表的粒度可以通过维度外键来确定。但是确定事实表数据粒度的正确次序应该首先从量度实际发生的现实事件中定义，即从业务逻辑上确定事实粒度，然后将维度按业务逻辑“对号入座”。

所有的事实表都包括一组维度的外键，一个或多个量度字段，有些事实表可能还包括一个或多个退化维度（没有外键相关的维度表）。

实际应用中，事实表一般至少包含3个维度，通常会更多。维度的数量也会随着企业业务增长，数据分析需求的不断深入而随之增加，比如对于各销售事实表，起初可能只有时间，产品，促销，市场等维度。但是随着业务不断发展，维度可能会有：时间，产品，促销，市场，商店，POS机，交易类型，客户，雇员，区域等等。

参照完整性

在加载fact表时，需要考虑的一个非常重要的问题就是参照完整性，即事实表与维度表之间的外键关系。事实数据一点丧失参照性，该数据将成为脏数据，直接导致错误的数据分析结果。这里的参照完整性，不单单是指数据库理论中的参照完整性，还包括业务上的参照完整性，也就是说一条事实数据不但要满足数据库中的参照完整性，还要满足业务上正确的参照完整性，不能有业务上的错误参照。比如，产品1的事实数据在事实表的产品外键必须指向产品1维度中的主键，而不能参照其他产品。否则虽然符合数据库要求，但是业务上却是错误的。

参照完整性问题产生的途径：

1、事实数据中包含错误的外键；

2、维度数据被删除，造成事实数据丧失参照。

这里有些读者可能会困惑怎么可能呢？我们在DBMS里面设置的参照完整性约束，怎么还会发生这种情况呢！一般来说，如果DBMS中设置了参照完整性约束，即外键约束，数据的参照完整性可以有DBMS来管理。但是有个问题是：在DW环境中，为了提高数据加载性能，通常我们不会创建外键约束，或在加载数据时使约束失效。因此参照完整性的维护任务就由ETL过程来承担。

参照完整性控制方法：

1、在事实数据加载前仔细核对数据，在数据准备环节做到参照完整；在对维度数据进行删除操作时，要反复确认，并做好删除操作的文档跟踪。

2、在DBMS中使用参照完整性约束；上面提及这种方式的问题。

3、每次数据加载完成后进行参照完整性检验。

代理键

加载fact数据的数据准备的最后一个步骤就是把事实数据中的业务主键替换成相应的代理键，即通过业务键从维度表中查找代理键并作替换。这里特别提及对于Type2 SCD代理键的查找问题，即必须保证查找到的是最新的代理键，因为Type2维度中对于同一维度信息可能有多条记录，但是我们做实事数据加载时，应该保证获取到最新的那条。可以考虑维护一个专门用作lookup的表，每次维度有更新时，及时更新这个lookup表，这个表一般包含两种信息：业务键和代理键。

这里需要提示大家的是：没有必要因为实事表里没有参照维度表的某条记录，而去删除这条维度数据，在维度表中保留这样的数据对DW的工作没有影响。

迟到的数据处理

迟到数据可以归结为两类：维度数据迟到、事实数据迟到。

维度数据迟到处理方式

所谓维度数据迟到是指，在加载fact数据时，相应的维度信息还没有加载到维度表里面，即无法直接进行Lookup代理键。处理方法大致有2种方法：

1、 将该事实数据转存起来，待下次ETL运行处理，即：每次ETL处理的数据集都是新数据与上次没有处理的数据的并集；

2、 推断维度数据，即，在维度表中插入一条数据，该数据只包含业务键值（fact数据携带），其它属性信息皆为推测标识。并将产生代理键返回，替换业务键。推测的属性待下次维度处理时更新（维度数据到来时）。

两种方法各有利弊：方法1的弊端是，统计总数可能与实际发生的业务不匹配，因为维度迟到的记录没有被加载。方法2的弊端是，通过维度查看数据时迟到的维度属性丧失可读性，容易引起疑惑。

还有一种维度数据迟到是指Type2 SCD更新数据迟到，这样造成事实数据参照完整性问题。具体处理方法参考维度加载章节。

事实数据迟到

事实数据迟到是指事实数据在业务系统中产生之后，在没有进入DW之前，维度数据发生了变化，并且维度数据加载到了DW，这样如果常规加载事实数据，会出现事实数据与事实发生时场景不符的情况。比如维度是Type2的SCD，那么迟到的数据将根据最新的维度数据进行代理键替换，造成与事实不符（应该是SCD之前的某条记录）。这种情况发生时，通常需要对这类事实数据做特别的代理键查找与替代，需要根据事实数据发生的时间介于哪条维度数据有效期间来确定。

事实加载前的准备工作

索引的管理

索引的作用是提升查询性能，但是索引的存在却是数据加载性能的杀手。通常，在数据加载之前删除索引，待数据加载完毕后创建索引。如果数据加载过程中即包含更新操作也包含插入操作，那么应该将这两种操作分开处理。

1、更新操作与插入操作分开进行

2、删除索引（支持更新操作的索引除外）

3、加载更新数据

4、删除所有剩余索引（2种保留的索引）

5、插入处理（批量加载）

6、重建索引

管理分区

表分区可以在物理存储上将大表分散处理，不但利于管理而且可以提升查询性能。分区通常按照DateKey进行范围分区。分区表的加载要注意确保分区覆盖数据，以免造成数据找不到自己的分区。可以通过ETL动态扩展分区，或DBA事先准备足够多的分区。

表分区提供了另一种数据加载方式，即交换分区的方式。假设按天分区，那么每天加载新的数据到新的分区上，然后将该分区交换到fact表上。

关闭DBMS重做日志

重做日志对于OLTP系统来说非常重要，但是在DW环境中由于数据处理都有ETL来控制和管理，不需要DBMS的重做日志来辅助数据加载失败的rerun过程。原因：

1、所有数据都由管控机制完善的ETL过程处理

2、数据通常是批量加载

3、如果数据加载失败，ETL有完善的Reload机制

加载数据

update与insert数据分离处理

即先将需要update数据做update处理，然后使用批量加载方式加载Insert数据。

使用批量加载使用工具

加载数据量较大时，应使用批量加载使用工具代替Insert SQL.

并行加载策略

在DBMS外部做汇总操作

DBMS汇总操作通常是低效耗时的。

增量加载

ETL在首次历史加载完成后，应该执行增量加载，即，只加载更新的数据。

事实数据的更新与修改

事实数据的修改方法可归结为3种：

1、反向抵消

2、直接更新

3、删除并重新加载，这里的删除包括两种处理方式：逻辑删除和物理删除，请参阅相关操作方法。

推荐采用第一种方式进行fact数据的修改。