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

本文主要來講一下貼源層(ODS），重點是如下三個方面

1.貼源層的數據清洗

2.貼源層的數據存儲

3.貼源層的數據校驗

一.數據清洗

貼源層，一般來說抽取的是源系統的數據，是一個數據緩沖區，和源系統保持一致，但并不是說貼源層的數據就可原來的一模一樣不變了

貼源層也要做基本的數據清洗，數據清洗時貫穿整個數據倉庫的全流程的。

貼源層的數據清洗主要包括兩方面

1.數據類型

我們一般搭建大型的數據倉庫，目前來說主要是搭建在hadoop 大數據集群上，當然以前可能也搭建oracle的數據倉庫，但我們的業務系統的數據則可能來自oracle，mysql，sql server 等不同類型的數據庫，雖然這些數據庫在大體上都遵從通用的數據類型，但也存在細微的差別，如果對數據類型不處理好，就可能導致進到數據倉庫的數據和源系統的不一樣。

? ? ? 舉一個簡單的例子，在mysql 中的double 類型，進入到hive 里面，可能有適合對double類型的支持不一定很好，這時候，可能就需要改變相關的數據類型，比如用decimal 來代替，舉一個我遇到的情況，0.0001 在hive里用double 類型，可能存儲的就是科學計數法的數據了，那這樣的數據類型如果不處理，到后面得到的就是錯誤的數據了。

2.明顯的差錯數據

明顯的差錯數據簡單講兩個方面的：

1>.是空數據，可能源系統因為是事務性的，在做某些操作時，存在誤操作在所難免，可能就導致空數據等明顯的臟數據進到數據庫中，其實空數據一般來說不影響我們的統計不清洗也可以，但有時候這樣的臟數據過多，我們也需要做一個基本的清洗

2>.是有特殊字符的錯誤數據，如果不清洗對數據導入數據倉庫會造成影響的，比如某些字段中有換行符號，如果不進行處理，可能導致數據進入數據倉庫錯位

當然另外一種觀點貼源層，數據不做任何清洗，錯也錯的一樣。當然也有他一定的道里。

二.數據存儲

數據存儲這里指以什么樣的方式導入數據倉庫存儲。

通常導入數據的方法無非兩種，1.增量切片，2.全量

這里介紹兩個選擇存儲的方法

1.數據量級，如果數據量都比較小，通常選擇全量導入，因為這樣導入是最安全，最簡單，最高效的，當然這樣的數據進ods容易，以后在歷史層的存儲可能能就會復雜點，這里以后再講

2.如果數據量級比較大，那這個時候我們就要考慮增量的方式了，一方面大量的數據需要耗費很多的存儲空間，另一方面在抽取數據的時候需要很多的時間。在這種情況下，對于按照時間等維度每天增量更新的數據，且歷史數據不再改變的或者變化的是近期數據的，我們可以選擇增量導入1天或者一段時間的數據，保證新增的數據都進入ODS，當然對于大數據量的有時候也會遇到比較坑的存儲數據，比如源庫只對源表進行update操作，并且update的時間字段無法使用的，這樣就只能全部導入了。

還有一種比較特殊的情況，這里舉一個我在工作中遇到的可能一個比較經典的情況吧：在我呆的上家公司，客戶表每天在源庫是update的，就是有新的客戶進來就會增一條記錄，客戶信息有變化就會改一條記錄，但是，也行是系統原因還是不知道什么原因，以源庫的updatetime 時間字段去增量導入新數據，總會漏部分數據，每天都這樣，開始以為updatetime 時間字段可能延遲了，就取前1個月更新的數據，最后發現還是會有部分更新的數據沒拿進來，導致報表出錯，后天想了一個辦法，客戶的客戶號是唯一的，用客戶號大于多少，小于多少去取源數據，這樣就能夠把所有的數據都拿進來了。

3.在系統空間允許的情況下，一般建議拿到ODS的數據保留3個月以上，如果存儲空間比較緊張的建議最少保存7天的，在oracle中如果空間不夠，可以考慮把7天之前拿過來的數據進行壓縮存儲。

三.數據校驗

一般來說數據貼源層的數據校驗不說說要保證貼源層的數據一定正確，而是要保證和源業務庫一致，錯也要錯得一樣。所以這一層的校驗主要在1.數據條目 2.數量類字段的求和值

數據條目，這個肯定是要核對的，但每天源系統一般抽取的數據表會非常多，建議最好寫出自動化的腳本自動比對。數量類的核對主要怕中間的數據導致錯誤，比如漏了一條新數據，但是某個數據插入了兩遍等，如果源表有金額字段，可以sum（金額）看下源庫和ODS庫是否相同。

這里有一點要注意的是，因為此步的核對涉及到對源庫的操作，可能不一定是所有的公司都會開發這種權限給數據倉庫，還有一點，自動化的腳本對源庫操作要適度，不能影響源庫的正常工作使用。

四 總結

其實關于ODS這一層我們感覺很簡單，就把數據拿過來吧，這個過程很容易出一些低級的錯誤，一定要保持數據敏感性，在源頭上把好數據這一關，不然后面都白搭。看似最無用，其實最關鍵，這就是貼源層