维度模型- 迟到的事实or被修改的历史事实

一. 问题

一个订单表，  小概率进行历史订单补录和订单金额修正。

怎么进行明细数据的处理和后面汇总数据的处理？

先说补录吧， 修改比补录还麻烦。

下面的讨论是基于hive， hive 的特征是只能全分区 insert overwrite。

虽然可以insert ，但是不具有幂等性，尽量不用。

二. 迟到的事实：全量事实表

1. 全量抽取事实表

2.根据时间戳增量抽取事实表，然后和之前数据合并最新的全量事实表快照。

优点： 简单， 根本不用考虑迟不迟到

缺点：数据很大时，性能不好。

三. 迟到的事实：按处理时间分区存储

按时间戳增量抽取数据，然后按处理时间分区存储明细数据。

优点： 简单， 但是要注意时间戳别重叠和出现空隙，导致数据重复和丢

缺点：   想通业务日期的订单， 不一定在相同的分区里。使用时得跨分区查询。

汇总处理：

1. 按处理时间分区，按业务日期分组进行汇总

优点： 数据准确

缺点： 相同的处理时间分区内， 可能有多个业务日期的数据。

2. 按业务日期进行分区分组进行汇总

优点：有了后面的缺点，就没有点了。

缺点：延迟的汇总结果， 会覆盖之前历史分区，导致数据不准。

结论： 不能这么搞。

3. 按业务日期进行增量计算，然后合并之前的数据再按业务日期分区。

优点：实现了按业务日期分区

缺点： 脆弱复杂， 出点问题，就得久远的日期之前开始重新计算。 可以结合下面的全量方式处理。

4. 全量计算，按业务日期存储

优点： 简单， 而且数据按业务日期存储

缺点： 数据大时，性能不好。 可以 全量初始化，然后增量计算 ， 并定时全量比对修正的方式。

四 . 迟到的事实： 按业务时间分区处理

优点： 相同业务日期的数据，都在一个分区

缺点： 很难很危险

1. 直接把增量数据按业务日期insert overwrite。

延迟数据会把以前的历史分区覆盖

2. 直接把增量数据按业务日期insert into

不具有幂等性， 不确定哪天要重跑调度，会出问题。

3. 增量数据，合并以前历史分区数据，然后insert overwrite

性能很差， 然后 依赖的汇总表也得刷。

五. 总结

各有优缺点