如上文所說，一個基本的數據倉庫分為貼源層，歷史層，數據模型層

本文主要來講一下歷史層(his），重點是如下三個方面

1.歷史層的數據清洗

2.歷史層的數據存儲

3.歷史層的數據校驗

歷史層，顧名思義，就是保存所有的歷史數據，我們知道數據倉庫的一個原則就是數據是不變的，就是說進來了的數據就不做更改，不做刪除，那這個不做更改，不做刪除，主要體現在的就是歷史層。

數據倉庫體系是一個OLAP體系，主要用來分析歷史數據的，那么歷史層數據的保存就顯得異常的重要。

一.歷史層的數據清洗

到了歷史層，其實對清洗的要求也不會很高，如果在ODS層做了基本的清洗，那么在歷史層要做的清洗就更少了。歷史層因為是保存歷史的數據，簡單的理解就是把ODS的數據全部都存一遍，歷史層的粒度最好還是保持最細的粒度，在歷史層來說，相對更為重要的應該是存儲了。本文也主要講述歷史層的存儲

二.歷史層的數據存儲

歷史層的數據存儲主要有4種，1.全量，2.增量切片，3.全量切片，4.拉鏈

1.全量

如前面ODS講到的，如果我們是全量把數據導入到ODS的，我們會根據業務需要，如果是緩慢變化的，或者確認這種變化后對我們的業務作用基本可以忽略不計的，我們通常就采取全量的方式存儲，這樣的存儲方式其實是和ODS里面一樣的。

2.全量切片

如前面ODS講到的，如果我們是全量把數據導入到ODS的，如果數據量不是很大的話，我們通常考慮全量切片的方式。就是把每一次全量抽取過來的數據都保存下來，然后在后面加一個操作時間字段

這里要講一下選擇全量存儲，還是全量切片存儲的問題

? ? ? ?對于數據倉庫來說，因為要保存歷史的數據，歷史的變化，那么在這種原則下，我們肯定優先選擇全量切片存儲了。但是，我們還需要考慮其他的存儲和實際的業務情況。

(1)個就是存儲空間的問題，假設一張很大的表從源體系全量抽取的，每天1個T，一年下來就365T，hive中再乘以3，那對存儲空間的要求實在太多了。可能這張表變化的字段就是一個一年就用一次的字段。從存儲和使用比來說，劃不來。

(2)個就是使用問題，在hive這種有分區的數倉體系中還好，如果是oracle，TD等數據倉庫，如果這張表存儲了1年的數據，我要查一個某一天的數據的某一部分，可能怎么樣都沒法查出來了

所以通常的原則，1.是小表，變化比較頻繁的表，變化的字段比較重要，并且經常要進行歷史對比的表，考慮全量切片

如果是變化比較慢，并且變化的字段基本不用的，就全量存儲就好，比如，一張地區維度表，把北京市統一改為北京存儲了，其實就沒有必要每天都存一遍了。

(3).就是數據量大，變化的字段比較緩慢的，這樣也考慮用全量表

那么這里問題就來了，如果數據量大，又變化的字段比較重要呢？

也許這真的就是數據存儲中的一個難題了，現在大數據量，又變化快的情況，可能主要使用的還是增量切片的方式，

3.增量切片，就是把新增的數據存儲下來，或者說變化的數據存儲下來，一般來說，這是當前一種主要的存儲形態

主要優點有2個：

? ? ? ? ? ?1> 增量數據相對全量數據來說，量級會少好多，會節省很多存儲空間

? ? ? ? ? ?2>每天存儲變化的值，在我們做相關使用時，效率會更高，總體的數據量級會少

4.拉鏈表

? ? 拉鏈表對于很多人來說可能比較陌生，一般做數據倉庫沒做個一年，可能都不會接觸到這種類型的表，并且目前考慮用這種表存儲的情況，實際來說比較少，這里就說兩點：1.拉鏈表本質上適合與緩慢變化的大量數據集，2.拉鏈表的使用不方便。

三.歷史層的數據校驗

歷史數據的準確性，是數據倉庫分析的基礎，對于歷史數據的校驗，其他也遵循通用的校驗方法，因為多了歷史數據緣故，還可以加一些趨勢性的校驗方法，比如同比，環比的數據總量，某一類指標的變化閾值，都可以根據歷史數據做一定的預警