微軟BI 之SSIS 系列 - 使用 SQL Profilling Task (數據探測) 檢測數據源數據

開篇介紹

SQL Profilling Task 可能咱們不少人都沒有在 SSIS 中真正使用過，因此對於這個控件的用法可能也不太瞭解。那咱們換一個講法，假設咱們有這樣的一個需求 - 須要對數據庫表中的一些數據作一些數據分析，好比統計一下數據表中各列中實際數據的長度，各長度區間範圍；好比統計一下各數據列中非空字段的比例，表的行數，重複字段等等。那麼若是不是專門作過這種數據源數據分析的話，可能不知道用什麼方式可以很是快的獲得這些信息。寫 SQL 語句？我想這個過程也是很是耗費時間和精力的。

實際上，在 SSIS 2012 中有這麼一個控件 SQL Profilling Task 能夠幫助咱們作到這些事情，對數據源的數據快速的作出分析。可以很是快速的弄清楚咱們面對的數據源是什麼樣的一種特徵，這些將在實際 ETL 處理過程當中對咱們 BI 開發人員是很是有幫助的。而且，還有一種狀況，咱們能夠將這種數據分析的結果直接在 SSIS 中經過郵件發送給相關的數據庫管理員，或者數據分析和管理人員，那麼他們對這種數據的瞭解會更加清晰，更早的判斷出數據源中的數據異常等問題。

SQL Profilling Task 的初步體驗

新建一個包，並新建一個 ADO.NET 連接管理器，此次咱們的測試源對象能夠換成任意一個數據庫，那我這裏把數據源換成 AdventureWorkLT2012 數據庫。

注意：在這裏必須使用 ADO.NET 連接管理器，這是一個特別的限制，而且只支持 SQL Server 版本。另一個就是必須對 tempdb 數據庫有讀寫權限，由於這裏面有大量的計算，聚合彙總等過程。

拖放一個 SQL Profilling Task到控制流中。

雙擊編輯，第一件要作的事情就是建立一個 XML 文件來保存 SQL Profilling Task 對指定數據源，表的分析結果的文件。OverwriteDestination 能夠每次指定讓它覆蓋掉之前的舊文件，可是另一種方式就是根據執行日期去生成不一樣的文件，關於這一點在前面不少例子中就已經提到了。

選擇 Quick Profile 

在這裏選擇好以前建立好的 ADO.NET 連接管理器，並選擇表或者視圖； 咱們在這裏首先配置的是表 Product，配置完成以後對於後面全部的表是均可以看的到的。

上面配置完成後，將跳轉到 Profile Requests 處，在這裏須要選中每一種 Profile，而後根據須要對每一張表的所有字段 (*) 或者某一個字段作 NULL 值檢查。裏面的每一項 Profile Type 都是進行差別化配置的，即不一樣的表，不一樣的列能夠配置或者不配置，默認狀況下都是 Product 表的配置。

這一點體驗是不太好的，就是若是我須要從新添加一張新的表的話，咱們須要建立新的 Profile Type - 在 Profile Type 下面點擊空白的地方新建立一個 Profile Request。

咱們繼續爲 SalesOrderHeader 表的 AccountNumber 作出空值統計處理。

保存以後運行包，並打開生成以後的 XML 文件。

很明顯，這個 XML 文件即便拿到手也是看不出來什麼的，正確的打開方式應該是經過 SQL Server 2012 自帶的 Data Profile Viewer 工具來查看。

打開 Data Profile Viewer 以後加載包產出的 XML 文件，能夠看到圖形化的分析結果。

以 Product 表中 Color 爲例，NULL 值的條數有50條，佔了總行數的 16.94 %。

咱們來驗證一下結果，發現和上面的分析結果是一致的。

下面就對這幾種 Profile Type 作一個詳細的解釋。

單列統計類型

Null Ratio Profile (NULL 比率統計)

通常用來檢查在數據列中 NULL 值的所佔比例，好比說經過分析的結果發現某一列的 NULL 值所佔比較太高，可能超過了預期，那麼這種狀況下是否是數據不太正常，丟值太多。好比在客戶關係管理系統中，做爲很是重要的聯繫方式 - 手機號碼，電子郵件，地址等。對於這三者來講 NULL 值所佔的比例應該手機號碼最小，地址和電子郵件其次，而且手機號碼的 NULL 值比例應該很是很是小纔是正常的。若是做爲重要分析因素的手機號碼的 NULL 值比例很是高，這時就說明咱們的數據源數據存在一些問題，那麼就須要引發注意。有多是業務操做不規範，也有多是數據源準備數據的時候出現問題。

好比在下面的幾個列中， Color, Size, Weight 就能夠經過 SQL Profilling Task 獲取到具體的 NULL Ratio 比例。

能夠看出數據源中的 Weight, Size, Color NULL 值比較從高到低，Weight 列種有97條空值，所佔比例 32.88%。至於這個數據是否合理就須要和業務人員來肯定了，也就是說咱們在設計咱們的數據倉庫時，作爲數據分析的依據時這些信息是事先就應該要了解的。

 

Column Length Distribution Profiles ( 列長度分佈統計數據 )

對於列中的數據長度去重並進行統計各長度所佔所有數據行的個數與比例。這個 Profile 有助於幫助咱們瞭解，第一是業務數據源中的數據長度定義是不是合理的，好比說業務數據源中的這一列在歷史 5 - 10 年中的數據長度最長就是 35，可是定義了255 的長度。那麼咱們在數據抽取的時候，來定義咱們表列的長度時這個就是依據，由於咱們發現歷史上全部的數據長度都沒有超過 35。第二是能夠查看到異常數據，好比身份證號碼通常默認大概是 18 位，那麼在這個圖中就能夠很是容易的看出來是否存在異常數據，好比說有大量的超過 18 位，或者小於 18 位的數據。

好比下圖中，Name 列中最小長度是5，最大是 32，長度爲 23 的數據佔據比例最高。

固然在設計長度檢測時候，對於空格的處理也是很是方便的。IgnoreLeadingSpaces - 是否忽略開通的空格，IgnoreTrailingSpaces - 是否忽略結尾的空格。

Statistics Profiles (列統計信息)

這種統計是很是有意義的，特別是對於數字，日期類型的字段，能夠很是直觀的看到它們的最大，最小，平均值，以及標準差值（時間只有最大，最小）。經過這些統計能夠看到數據是否存在異常狀況，好比價格的最大和最小值會不會出現負值，最大值是否偏離的離譜等等。

關於這裏面的平均值 Mean 還有 Standard Deviation 請參考統計學中的平均值和標準差等計算方式。

Value Distribution (列值分佈統計)

去重以後列的值分佈狀況，那麼這種統計一方面能夠幫助瞭解源數據中有哪些數據能夠做爲分類出現，哪些數據基數很大不適合作這種分類。另一個，這種統計也能夠幫助咱們鑑別列中數據的質量。好比說中國的省份經值分佈統計以後發現多達上百個，那麼這種數據是有問題的，會很是容易的看出來。

如下圖爲例，能夠很是明顯的看到各個列中值的分配狀況，像 Color 這種列是很是適合做爲維度的一個屬性用來分析事實表中的數據的，可是像 ProductNumber 這種基數太大不適用用來分析事實數據。而且在 Color 列中也能夠很是直觀的看到哪種顏色的產品目前最多，所佔的比例是多少都很是清楚。

Pattern Profiles(列模式，正則表達式分配統計)

爲字符串類型的數據提供正則統計，好比郵件地址的正則通常只有有一種正則表達式，若是看到的是其它的表達式有可能說明之前的驗證是錯誤的。還有就是經過對統計數據的分析能夠看到哪種表達式所佔據的比例多，高，越多越高的說明這種比例應該是正常的，能夠考慮之後全部的驗證按照這一種走。至於其它的能夠考慮若是是業應用中修改，或者在抽取數據的時候認爲這種數據是異常的，是須要處理的。

例以下圖中產品 Size 大小的表達式正則爲 \d\d，佔據了 84% 的數據比，說明大多數 Size 的內容都是數字類型的，可是也有一些填寫的值是 M, L 這種字符類型的；那麼像這種數據再抽取到數據倉庫以前就能夠發現，因此纔有時間來考慮這種少許的非規則的數據應該如何來處理了。

多列或表級別探測類型

Candidate Key Profile (候選主鍵探查)

對於選擇要探測統計的列進行統計，看看它是否符合主鍵的特徵，或者近似主鍵。好比說，咱們可能以爲某一列應該做爲主鍵，可是最終統計下來發現由於存在重複值只能做爲近似主鍵存在，那麼在選擇時候就要注意了。

好比在下圖中的這三列都是非重複列，100%的符合了主鍵的特徵，所以這幾列能夠做爲主鍵候選列來考慮。固然最終如何選擇，這個分析只能是一個參考，好比咱們還須要考慮字段的類型，長度等因素，儘可能選擇整型數據；即便是字符串的話，也應該選擇長度更短的列。

可是這個值是否是 100% 徹底與實際相符的，不必定，這裏的顯示和配置 Candidate Key Profile 時有關。

好比在選擇 Specified 的時候就能夠列出全部的列 (*)，當非重複率達到 95%以上的時候就應該認爲是 100%了。

而在選擇 None 的時候這時須要選擇到固定的列，或者一個列兩個列組合造成。

Functional Dependency Strength Profile (函數依賴關係統計)

能夠這麼來理解這個統計所作的事情，好比說在一個銷售統計裏，有國家，省份和城市，一個城市一定屬於一個省份，而一個省份也一定屬於一個國家。若是在數據中好比說咱們發現了城市，例如杭州屬於浙江的同時，它在另外的一條記錄中也屬於了省份江蘇，那麼很明顯這個數據是有問題的。

函數依賴關係就能夠檢測這種依賴關係，好比在 1000 條帶有杭州的數據中，有 999個杭州的數據對應的省份是浙江，有1個不是，那麼杭州對浙江的依賴比率應該達到 90%以上了。

好比下面這幅圖中，SalesPerson 對 CompanyName 的「依賴」，CompanyName 對 SalesPerson 的"決定性"達到了 99.76%。換句話說，只要知道了 Company Name 就有 99.76% 的可能可以肯定它的 Sales Person 是誰? 只要知道了城市是杭州，那麼就有百分之多少的可能知道省份是誰，固然城市與省份之間的決定應該達到 100%。

在 Friendly Bike Shop 中有 4 條數據，其中兩條是可以決定 Sales Person 是  adventure-works\david8，另外兩條不是的，所以這種依賴率是 50%，可是總體上全部的數據這種依賴率是 99.76%。

Value Inclusion Profile 值包含統計

主要用來計算兩個列之間或者多個組合列之間列值的重合狀況，經過 Value Inclusion 值統計能夠大概決定好比兩個表之間的列是否適合創建外鍵的引用關係。或者，從另外的一個角度來講，若是這一張表的某列引用了另一張表，造成了理論上的這種外鍵關聯；那麼經過值包含統計就能夠看出來這種關聯是否正確，好比 B 表的某列的值都是來源於 A 表的某列，可是經過探測發現 B 表某列的值在  A 表中是找不到的。

由於在這裏沒有特別好的例子，在已經創建好外鍵關係的表中這種探測確定是沒有任何問題的，因此咱們在這裏只是來理解一下 Value Inclusion 的用法便可。

咱們來看看 Product 表中的 ProductCategoryID 對 ProductCategory 表中的 ProductCategoryID 的引用狀況（值包含狀況）。

最後的結果不出意料基本上就是 100%的關聯率。

總結

在 BI 系統中，最重要的一個環節莫過於 ETL 了，而數據源又與 ETL 的設計與開發息息相關。特別對於一些沒有良好維護的數據源，其質量的好壞將在很大程度上影響 ETL 的設計。所以理解好數據源，分析好數據源的數據對後期的 ETL ，表的設計起着很是重要的做用。 咱們能夠經過 SQL Profilling Task 對咱們的數據源有一個大體的瞭解，經過以上的這幾種方式的分析，基本上能夠知足絕大部分數據探測的須要。特別對於那種應用系統邊升級，BI 系統邊升級的的項目，應用系統自己並不健全的狀況下，其數據的質量上也多是存在很大問題的，這樣就給咱們的 BI 設計帶來了不少不很差的影響。因此在一些 ETL 設計中，咱們甚至能夠採用在 SSIS 中經過郵件週期性的發送這種探測報告給 BI 系統維護人員，儘可能地作到週期性的對源數據的預防性檢查工做，提早避免一些不規範的數據帶來的意外後果。

 

最後提一下，還有一件事情要作! 若是總是去分析這個 XML 是不該該的，由於這種數據都不能集中呈現歷史數據的。所以最好的方式是解析 XML 文件，將數據解析的結果保存到數據庫中，本身用報表的形式來呈現。這樣不光能夠看到當前的結果，並且還能夠對比以前全部的歷史結果，作到對數據源的探測管理 - 數據源的監控管理也是屬於 BI 監控管理的一部分，關於這一部分就不詳細展開了！

更多 BI 文章請參看 BI 系列隨筆列表 (SSIS, SSRS, SSAS, MDX, SQL Server)  若是以爲這篇文章看了對您有幫助，請幫助推薦，以方便他人在 BIWORK 博客推薦欄中快速看到這些文章。