Kettle之深度思考---Kettle构建数据仓库

  我在上两篇博客的随笔中，已经大概的介绍过Kettle的安装以及小的JOB设计。在这个学习过程中，有两个问题引起我想进一步学习ETL相关设计以及对于数据仓库设计的好奇。在这篇文章以及下篇将就如下两个问题引起的深思做出说明：

1. 事实表和维度表ETL都是通过什么顺序加载到数据仓库。
2. 什么叫做迟到的事实表以及如何处理迟到的事实表。

-------------------------------------------------------------------------------------------------------------------------

    首先先解释维度表，在数据仓库当中维度表有两种类型：

•       第一种维度表为业务系统（一般为OLTP系统）中已经包含所有的信息
•       另外一种维度信息来自事实表以及周围数据

以上图数据模型说明，其中user_dim为第一种维度，Time_dim以及page_dim为第二种维度。

 

 首先更新user_diim维度表， 由于这一类的维度表信息，均来自业务系统的一个表或者多个表，因此在加载这类维度表时只需要考虑到缓慢变化维度以及通过技术健来标识不同数据。  

   这类维度数据，会遇到两种操作。

•       新数据insert
•       旧数据更新

    新数据没啥好说的，主要是旧数据更新的缓慢变化维度设计。

1.      一种是直接覆盖
2. 一种是加上start_date以及end_date标志，先更新旧记录，再插入一条记录。（在数据仓库当中，此种情况用的多）

  前两个过程分别是从源数据库读取数据，并filter，不做说明。

第二步是user的缓慢变化维度设计过程，

     

     到这一步，第一种维度表的缓慢变化维度算是处理完毕。

-------------------------------------------------------------------------

  第二种维度表的处理会复杂很多，因为包含了事实表以及维度表的处理。

  这里有个思考，先有事实表的page_id(也就是维度主键，想请问是怎么得到其维度主键的？)

  答：维度表的id也是通过代理键实现的，先加载维度表。

由于在我们如上的例子中，包括了两种维度变化的处理。处理仓库数据加载分为了两个transformation:

1.    首先，chef执行第一种维度变化转换
2. 如果失败，发送邮件
3. 成功，则加载第二种维度变化转换并发送邮件。
4. job的实现如下图。

 

--------------------------------------------------------------

   装载日期在生效日期后的事实就是迟到的事实。晚于订单日期进入源数据的销售订单可以看做是一个迟到事实的例子。销售订单被装载进其事实表时，装载的日期晚于销售订单的订单日期，因此是一个迟到的事实。（因为定期装载的是前一天的数据，所以这里的晚于指的是晚2天及其以上。） 迟到事实影响周期快照事实表的装载。