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

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

1.貼源層的數(shù)據(jù)清洗

2.貼源層的數(shù)據(jù)存儲

3.貼源層的數(shù)據(jù)校驗(yàn)

一.數(shù)據(jù)清洗

貼源層，一般來說抽取的是源系統(tǒng)的數(shù)據(jù)，是一個數(shù)據(jù)緩沖區(qū)，和源系統(tǒng)保持一致，但并不是說貼源層的數(shù)據(jù)就可原來的一模一樣不變了

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

貼源層的數(shù)據(jù)清洗主要包括兩方面

1.數(shù)據(jù)類型

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

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

2.明顯的差錯數(shù)據(jù)

明顯的差錯數(shù)據(jù)簡單講兩個方面的：

1>.是空數(shù)據(jù)，可能源系統(tǒng)因?yàn)槭鞘聞?wù)性的，在做某些操作時，存在誤操作在所難免，可能就導(dǎo)致空數(shù)據(jù)等明顯的臟數(shù)據(jù)進(jìn)到數(shù)據(jù)庫中，其實(shí)空數(shù)據(jù)一般來說不影響我們的統(tǒng)計不清洗也可以，但有時候這樣的臟數(shù)據(jù)過多，我們也需要做一個基本的清洗

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

當(dāng)然另外一種觀點(diǎn)貼源層，數(shù)據(jù)不做任何清洗，錯也錯的一樣。當(dāng)然也有他一定的道里。

二.數(shù)據(jù)存儲

數(shù)據(jù)存儲這里指以什么樣的方式導(dǎo)入數(shù)據(jù)倉庫存儲。

通常導(dǎo)入數(shù)據(jù)的方法無非兩種，1.增量切片，2.全量

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

1.數(shù)據(jù)量級，如果數(shù)據(jù)量都比較小，通常選擇全量導(dǎo)入，因?yàn)檫@樣導(dǎo)入是最安全，最簡單，最高效的，當(dāng)然這樣的數(shù)據(jù)進(jìn)ods容易，以后在歷史層的存儲可能能就會復(fù)雜點(diǎn)，這里以后再講

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

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

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

三.數(shù)據(jù)校驗(yàn)

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

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

這里有一點(diǎn)要注意的是，因?yàn)榇瞬降暮藢ι婕暗綄υ磶斓牟僮?，可能不一定是所有的公司都會開發(fā)這種權(quán)限給數(shù)據(jù)倉庫，還有一點(diǎn)，自動化的腳本對源庫操作要適度，不能影響源庫的正常工作使用。

四 總結(jié)

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