数仓笔记 一

好久没写博客了，最近一直在忙数仓迁移的事，从SqlServer迁移到impala+kudu上，没使用hive。建立一套大数据的数仓，数据接入用的streamSets。

说实话之前好长一段时间都是在练手，不停的将原有SqlServer中的数据导入到kudu中。

1.其中有个缓慢变换维还挺有意思的。比如说以用户为栗。用户中有两个比较重要的属性，用户所在城市，用户类型。当着两个属性其中一个发生变化时就应该将原本这个用户的信息废弃，但是数据需要保留(方便追查历史)。那么这个时候在调度时就需要做几件事情：
1.判断dim中本条数据和ods中本条数据是否一致，如果关键字段改变则将本条记录废弃，新增记录结束时间,一般为now()。
2.判断dim中本条数据和ods中本条数据是否一致，如果非关键字段改变则直接更新，更新范围仅在dim有效的数据。
3.新增记录,此时将dim中的数据先开窗取到每条数据最新的数据(dim中一个用户有多条数据,这里包括废弃记录，因为需要和废弃记录对比才能新增记录)，比较dim中本条数据和ods中本条数据是否一致，如果不一致则新增。
4.新增记录，新增记录为ods中有，dm中没有。直接left join 然后判断dm is null 则完成新增
5.在lz层中有些用户被删除了，此时dm关联lz。判断用户在lz是否还存在，如果不存在则废弃本条记录,ods层记录是不会被删除的，只能新增修改。
问题:新增为何不能在删除前:
如果新增在删除前，那么dim中在同一个时间段内就会有两条数据。dim做缓慢变换维必须保证同一个时间段内只有一条数据。这样在ods数据关联dim数据时可以一对一。

2.重零开始构建dm层。

公司业务变更较大，所以在构建dm层时需要从最小维度考虑。如销售模块，从销售角度考虑，订单生成的城市和订单客户，以及订单购买的sku是一定的。所以可以分别从这三个角度去构建订单的dm表，采购其实和订单是一样的，也是分别从地点，人，商品三个角度去构建dm层数据。用户表在这里的用处很大，可以通过用户表来算不同需求的用户数(去重数据永远是最麻烦的)。

3.如果公司业务比较稳定，其实可以在最简单的三层上继续抽象出更多的表。