摘要

本文主要介绍使用kettle 来建立一个Type 2的Slowly Changing Dimension 以及其中一些细节问题

Kettle 简介

Kettle 是一个强大的，元数据驱动的ETL工具被设计用来填补商业和IT之前的差距，将你公司的数据变成可增长的利润.
我们先来看看Kettle能做什么：
1. Data warehouse population with built-in support for slowly changing dimensions,junk dimensions and much,much more.
2. Export of database(s) to text-file(s) or other databases
3. Import of data into databases,ranging from text-files to excel sheets
4. Data migration between database applications
5. Exploration of data in existing databases. (tables,views,synonyms,)
6. Information enrichment by looking up data in various information stores (databases,text-files,excel sheets,)
7. Data cleaning by applying complex conditions in data transformations
8. Application integration

本系列文章主要介绍如下几点：
1. 数据仓库内建支持缓慢增长维SCD,
2. 在数据转换中使用复杂条件判断来清理数据
3. 如何使用kettle 来处理增量更形
4. 将Kettle 集成到你的应用程序里
5. 使用kettle中应该注意的一些地方

Kettle 文档

最好的kettle教程就在你身边，我们下载的kettle-version. zip 文件里其实已经包括了非常多的示例和文档，在你的kettle文件夹下，docs 文件夹下包含了所有的文档，samples文件夹下包含了一些示例，后面的介绍中一部分示例都来自kettle自带的这个示例文件夹下。docs里面最主要的是Spoon-version-User-Guide. zip,里面记录了kettle 的技术性文档，包括支持的操作系统，数据库平台，文本格式，图形化的界面，其中最重要的是所有的转换对象(Transformation Core Objects) 和Job对象(Job Core Objects) 的解释，包括截图和每一个参数的解释。

Kettle与Slowly Changing Dimension

我们使用kettle自带的samples文件下的示例，来看kettle如何支持SCD的。
打开samples / jobs / Slowly Changing Dimension 文件夹，发现里面有三个文件，
create - populate - update slowly changing dimension.kjb
DimensionLookup - update dimension table 2.ktr
DimensionLookup - update dimension table.ktr
其中后缀以 .kjb 结尾的是kettle 的job 文件导出的格式，而以ktr 结尾的是kettle 的transformation 导出的格式,打开其中的DimensionLookup - update dimension table.ktr,出现如下所示 ：

1. 最左边的是产生测试数据，如果是实际环境的话应该是连接真实的数据库，产生的真实数据格式打开如下：

2. 第二个步骤Dummy 就是把前面的数据合并起来，Dummy 步骤本身不做任何事情，不过由于前面有四个输入指向它，所以它在第二步的作用等同于数据合并。
3. 第三个步骤是取得系统参数(get system date),它取得当前系统时间的日期，并且格式是当天的 00:00:00,如图所示

4. 最后一步是真正的重点，执行Dimension Lookup / Update 步骤来更新和插入数据，以此来实现Type 1,2,3 的不同Slowly Changing Dimension

图4

图5
在开始介绍Dimension Lookup / Update 之前，先看看在执行这个步骤之前的输入和输出:
输入:

输出:

注意: 上图中所使用的是mysql 5 数据库做测试，所以数据类型一栏都是mysql 的数据类型，如果你使用其他数据库，可能数据类型会有所不同，其中的datetime 的格式yyyy/mon/day hh:mm:ss:sss
我们再来看看当我们第一次运行以后出现的数据输出:

注意上图中所有的 version 值都是 1
Date_from 都是 1900/01/01 00:00:00.000
Date_to 都是 2199/12/31 23:59:59.000 这两列都是根据图4下面部分定义的
Id,name,firstname 都是测试数据，从前面步骤来的.
然后我们修改图1中generate row 的部分数据（一共两条），并且只有测试数据变了的情况下，我们再次运行转换，查看数据输出:

注意到其中customer_tk 并没有什么变化，仍然在产生类似序列的输出
Version 的值中出现了 2,并且只有在我们改变的数据中
在出现了改变的行中的date_from 变成了2007/11/28/ 00:00:00.000
在出现了改变的行中原来数据的date_to 变成了 2007-11-28 00:00:00.000
Id 列没有变化，（变化了也没用，图5中的中间部分 Field 选项卡没有选id）
Name,firstname 有两个值变了（我们手工改变的）

Dimension Lookup / Update 参数解释

官方文档中提到的注意事项:

1. Stream date field : 如果你不想每次都改变时间的范围，你需要添加一个额外的这个字段，比如你打算每天的午夜来进行ETL过程，可以考虑加一个Join 步骤”Yesterday 23:59:59” 作为输入的时间字段.
2. 这必须是一个Date 字段(不能是转换后的字符串，即使他们有相同的格式也不行),我们（Kettle 的开发小组）把功能实现隔离出来，如果你需要的话自己要先转换.
3. 对于Date range start and end fields : 你只能指定一个表示年的数据，而不是时间戳，如果你输入YYYY(比如2100),这将会被当成一个时间戳来用: YYYY-01-01 00:00:00.000,（注意图6中的格式）

另外需要注意的地方:

1. Technical key field : 其他一些ETL工具（比如OWB）也许叫做代理主键，只是名字上不同而已.
2. SQL Button : 当你在目标数据库中还没有建立维表的时候，你点击SQL Button,Kettle 会弹出如下对话框帮你建立维表，你会发现它默认帮你在代理主键和业务主键上建立索引。
   

   

3. Creation of technical key ： 在这个选项的第二种实现方式上，Use sequence ，这个要视你数据库支持而定，mysql 就不支持，Oracle 支持sequence,但是你要自己创建和管理这个sequence,如果这个sequence 的值因某种外部因素改变了，你要自己确定sequence 产生的值处于何种状态，如果可以的话尽量不要用，尽量用第一种：table maximum + 1,这种方式永远不要担心数据库的不同和实现方式的不同，而且简单易懂。

4. Stream Datefield

   4.1 这个选项是用来控制时间的精度的，有的时候我们可能只是一个月进行一次ETL，这个时候Datefield 显然没有必要到秒的精度，而且这个选项严重影响你后面如果使用缓慢增长维的sql 的复杂度，因为你需要先把时间的精度调到你需要的精度，比如你使用的数据是到秒的精度，但是你实际需要的只是天的精度，你在sql 里面有大量的时间都浪费在toString( stream date field),然后把这个字符串substring(),执行效率会低一些.

   4.2 不要轻易改这个精度，一旦你确定了精度问题，不要尝试改变它，尤其是当精度变细的时候，你可能会损失掉已经存在与数据库中的数据的精度，如果你只是从 “Today 00:00:00.000” 改成 “Today 23.59.59.000” 的情况，需要手动处理好已经存在的数据格式问题.

   4.3 执行ETL的时间可能决定这个值，如果你一天可能存在5次执行ETL过程（包括自动执行或者手工执行）那么你显然不希望时间的精度是按天来计算的（比如Today 00.00.00这种格式）

   4.4 精度的损失并不可怕：考虑一下你的应用场景，比如我们要做表，列出2006年11月份和2006年12月份的所有销售总和，结合上图中的customer 的例子，假设是按客户聚合的,我们对于customer 的精度要求只要求到月，没有要求到天，如果我们执行ETL的过程是一个星期执行一次，可能一个客户在一个星期内改变了三次他的名字（虽然不是个好例子，完全是为了配合上面的图），而只有最后一次的改变被记录了下来，这完全跟你执行ETL的频度有关，但是考虑到用户需求，只要精度到月就够了，即使这种精度有数据损失也完全没关系，所以你如何指定你的Stream date field 的精度主要是看用户需求的精度。
   4.5 如果以上四点你觉得只是一堆让你头疼的字符串，那你完全可以把stream date field 设置成空（默认的到时间戳的精度）
   执行Type 2 SCD

   1. “Update the dimension?” 选中
   2. 在Field tabs 里面，对于每一个你想要保持全部记录的字段都要选择Insert 方式.

错误处理和依赖问题

如果你运行了这个转换，你会发现你的输出中有一条customer_tk为1，version为1的数据，你在图6和图7中没有看到这条数据是因为我不想一开始把这条数据跟SCD的实现混在一起，SCD的实现本身并不会告诉你要添加这条数据，这完全是跟数据建模有关系，为了理解这个问题，我们看一下如下情况该如何处理： 一个产品销售的记录是作为一个立方体的主要事实表，它包括一个客户维，现在因为某种原因客户维需要删除掉一部分数据，但是对映的产品销售记录却要保存起来，该如何处理外键约束的问题? SCD实现本身并不会考虑这个问题，因为它跟维表没有什么关系，你要处理的是事实表里面那些引用了维表的记录，如果你没有这个空行（它唯一的一个值就是 id,而且是为了满足主键约束，version那个字段有没有值不重要），事实表中的记录就不好处理这种情况，因为你把它赋予任何一个值都是不合适的。这种方法是为了处理像数据依赖（外键的关系）和错误处理比较常见的方法。