接觸數據倉庫也半年多了，一直都知道數據質量的重要性， 前面也看過幾篇數據質量的博文，但是沒有真正的在實踐中去做過。上週接觸了一下數據探查，發現數據探查對於數據質量是非常重要的一個環節，它是決定最後數據正確性的非常關鍵的一步。 數據探查階段爲ETL團隊提供了指導，告訴他們需要使用多少數據清洗機制，並且使他們不會因爲創建處理髒數據的系統分散了注意力而遺漏項目的主要環節。一定要預先進行數據探查工作！使用數據探查結果，可以設定業務發起人對於實際開發時間表、源數據的侷限性和對更好地源數據捕捉方法進行投資的需求等的期望。
在啓動主數據管理項目之前，需要了解數據的內容、質量和結構。在數據源進行的數據探查使數據管理員和數據倉庫管理員能夠在數據進入主數據管理項目之前，快速發現和分析跨所有數據源的所有數據異常，此流程可極大加快從主數據管理項目實施中獲取價值。
由於數據清洗增強了數據的準確度，帶來了數據完整性，並從源頭增進了數據的可信度，因此數據清洗改善了主數據管理項目系統中的數據一致性。
“數據探查、數據質量和數據集成是三個搭配使用的商業慣例，就像麪包、黃油和果醬⋯⋯。數據管理專業人士及其商業對手需要協調工作並設計有效結合所有這三個慣例的項目。”
從上圖可以發現，
數據探查在數據質量流程中的位置。我們從源系統中查詢到各種數據，然後對數據進行分析和探查，而數據清洗過程將利用數據探查的結果進行有效的清洗，最後達到數據集成，以提供正確的數據。
本次用到的具體的數據探查語句：
1.Null值統計
- selectcount(*)總記錄數
round(sum(decode(A,null,1,0)) /count(*) * 100,2) from t
2.主鍵ID長度的統計
selectdistinct (length(A))from t
3.碼錶或者狀態值的數量的統計
碼錶類型名稱及其每個類型下數據量的統計
項目中，我們需要給其他系統對抽表數據，對抽表的數據就是將源表中的數據，完全對抽到目標表中。這個過程本來覺得很簡單，直接將數據抽取過去就可以了，但是後來發現不是那麼回事，你要對你送出的數據負責。
這些數據到底是什麼數據？這些傳過去的數據是否正確，業務含義是什麼，表的用處是什麼？表中某個字段的字段結構是什麼，等等這些都要知道。
1.源表的數據量的統計
select count(*) as 總記錄數 from t
2.源表字段空值的統計
select round(sum(decode(A,null,1,0)) /count(*) * 100,2) from t
3.源表字段的業務含義是什麼
比如一個表中有inputdate，有datadate，那這時候你就要去探究了，這兩個字段到底都是什麼業務含義，他跟增量規則是否有關。
4.源表字段的數據格式
比如一個表中有Inputdate字段，這個字段就是增量時間戳字段，在做增量加載時，是採用 where inputdate =date '業務日期' 還是採用where inputdate=trunc('業務日期)，這時候就要看inputdate中存放的數據的格式了。如果有時分秒，則需要用後者，否則用前者。
還有金額字段，是否有小數位等等。
5.增量規則
我們一般採用的增量規則方式爲時間戳方式。這時，對於一個表，就要探查它是業務源表，還是SGA層表？如果爲sga層表，那麼這個表是日增量表還是日全量表，如果爲日增量表，那麼它的增量規則是什麼？
6.是否符合需求
這個大方向一定要把握好。源數據-->數據倉庫，數據倉庫提供接口數據--->A系統。不但要把表中的數據探查清楚，還要通過探查數據，看傳過去的數據是否符合A系統的需求。
數據探查使數據質量中關鍵的一步，要認真做好這一步，才能真正把控數據來源，減少返工。
只是意識到了對於表內數據的探查,即表內數據量、空值、關鍵字段、類型、數據格式等的探查，而沒有站在更高的角度去想數據探查。
數據探查，是在拿到需求後，首先從戰略上去探查確定候選數據源，即去探查會涉及到哪些源系統，涉及到源系統中的哪些表，對於系統中涉及到的表的表結構，表內數據，表與表之間的關係（一對一，多對一，一對多等），及其選定的數據源是否適合包含在數據倉庫中，而我所理解的數據探查只是在選定了數據源之後的更細的數據方面技術性的探查，具體見數據探查（一） 和數據探查（二）。
數據探查是對數據的技術性分析，對數據的內容、一致性和結構進行描述。
數據探查擔負着兩種不同的任務：戰略性的和戰術性的。
戰略性：一旦確定了某個候選數據源，就應當進行一次輕量級的探查評估來確定該數據源是否適合於包含到數據倉庫中，針對早期的採納/不採納問題提供決策。理想情況下，應當在業務需求分析過程中確定出一個候選數據源之後立即進行戰略性評估。較早地找出那些不合格的數據源是一個責任重大的步驟，即使帶來的是壞消息，也是必要的一步。如果很晚才發現數據源無法支持要做的工作，對DW/BI團隊的積極性將產生重大的打擊，特別是當項目已經展開數月之後才發現數據源存在問題時更是如此。
戰術性：一旦將某個數據源引入項目的基本戰略決策已經定下來，就需要進行一系列戰術性的數據探查工作來儘可能多地確定出各種問題。通常這一工作從數據建模過程就開始了，一直到ETL系統設計過程。有時ETL團隊也可能需要使用一個其內容沒有經過徹底評估的數據源。系統也可能支持產品過程的需求，但是卻存在ETL方面的難題，因爲對產品處理並不重要的字段用來進行分析也是不可靠和不完整的。該子系統中揭示出來的問題最終會產生兩種詳細說明：1)將數據送回原來的數據源中，請求改善數據質量；2)構成了數據質量子系統的需求。
總結：探查階段是建設DW模型的基礎，也是ETL設計的基礎，唯有做好數據探查纔可以使得DW的工作更加順暢。
探查階段爲ETL團隊提供了指導，告訴他們需要使用多少數據清洗機制，並且使他們不會因爲創建處理髒數據的系統分散了注意力而遺漏項目的主要環節。一定要預先進行數據探查工作！使用數據探查結果，可以設定業務發起人對於實際開發時間表、源數據的侷限性和對更好的源數據捕捉方法進行投資的需求等的期望。