7項(xiàng)基本數(shù)據(jù)質(zhì)量測試
數(shù)據(jù)質(zhì)量測試是在使用數(shù)據(jù)集之前驗(yàn)證數(shù)據(jù)集的關(guān)鍵特征是否符合預(yù)期的過程。
根據(jù)Gartner的數(shù)據(jù)，不良數(shù)據(jù)平均每年給企業(yè)造成1290萬美元的損失。事實(shí)上，Monte Carlo自己的研究發(fā)現(xiàn)，數(shù)據(jù)工程師每天要花費(fèi)多達(dá)40%的時間來處理不良數(shù)據(jù)。
這些都是很大的數(shù)字。數(shù)據(jù)質(zhì)量問題是現(xiàn)代數(shù)據(jù)團(tuán)隊(duì)面臨的一些最嚴(yán)峻的挑戰(zhàn)，而測試是數(shù)據(jù)團(tuán)隊(duì)在獲得可靠數(shù)據(jù)的過程中所采取的第一步。
不管是錯誤還是熵，當(dāng)數(shù)據(jù)在生產(chǎn)管道中移動時必然會出現(xiàn)異常。在這篇文章中，我們將介紹你現(xiàn)在驗(yàn)證數(shù)據(jù)所需的 7 項(xiàng)基本數(shù)據(jù)質(zhì)量測試；另外，你現(xiàn)在可以應(yīng)用數(shù)據(jù)質(zhì)量測試的一些方法開始構(gòu)建你的數(shù)據(jù)質(zhì)量行動。
一、那么，什么是數(shù)據(jù)質(zhì)量測試？
當(dāng)談到數(shù)據(jù)工程時，質(zhì)量問題是一個不可避免的事實(shí)。與所有的軟件和數(shù)據(jù)應(yīng)用程序一樣，ETL/ELT系統(tǒng)有時容易出現(xiàn)故障。
除其他因素外，如果滿足以下條件，數(shù)據(jù)管道是可靠的：
? 數(shù)據(jù)是最新的、準(zhǔn)確的和完整的。
? 數(shù)據(jù)是唯一的，沒有重復(fù)的。
? 這個模型是合理的，代表了現(xiàn)實(shí)。
? 轉(zhuǎn)換后的數(shù)據(jù)沒有異常。
雖然沒有解決數(shù)據(jù)質(zhì)量問題的有效方法，但數(shù)據(jù)質(zhì)量測試使工程師能夠預(yù)測特定的已知問題，并編寫邏輯來主動檢測質(zhì)量問題，以免影響下游用戶。
現(xiàn)在，我們已經(jīng)對什么是數(shù)據(jù)質(zhì)量測試有了一個共同的理解，讓我們看看你現(xiàn)在可以運(yùn)行的一些最常見的數(shù)據(jù)質(zhì)量測試，以及如何使用它們來檢測數(shù)據(jù)中的質(zhì)量問題。
二、NULL值測試
最常見的數(shù)據(jù)質(zhì)量問題之一是數(shù)據(jù)丟失，也稱為NULL值。
當(dāng)字段留空時，無論是有意還是由于管道錯誤（例如API中斷導(dǎo)致的錯誤），都會出現(xiàn)NULL值。假設(shè)你正在按區(qū)域查詢營銷計(jì)劃對銷售額提升的影響，但多條記錄中的“區(qū)域”字段留空。任何缺少“區(qū)域”的行都必然會從報(bào)告中排除，從而導(dǎo)致未來在區(qū)域營銷計(jì)劃上的支出效率低下。
顧名思義，NULL值測試將在模型運(yùn)行后驗(yàn)證特定模型的指定列中的值是否缺失。dbt的通用not_null測試是一種很好的用于發(fā)現(xiàn)NULL值的開箱即用測試。
演示：tests/test_not_null.sql
{% test not_null(model, column_name) %}
select *
from {{ model }}
where {{ column_name }} is null
{% endtest %}
三、容量測試
數(shù)據(jù)是否傳入？數(shù)據(jù)是太少了還是太多了？這些都是與進(jìn)入數(shù)據(jù)庫的數(shù)據(jù)量相關(guān)的數(shù)據(jù)質(zhì)量問題。
容量測試是一項(xiàng)必備的質(zhì)量檢查，可用于驗(yàn)證關(guān)鍵表中包含的行數(shù)。
1.缺失的數(shù)據(jù)
假設(shè)你的數(shù)據(jù)平臺處理來自溫度傳感器的數(shù)據(jù)，其中一個傳感器出現(xiàn)故障，會發(fā)生什么呢？你可能會得到一堆瘋狂的溫度值，或者你可能什么都得不到。
缺失數(shù)據(jù)會很快使數(shù)據(jù)模型或儀表盤出現(xiàn)偏差，因此數(shù)據(jù)質(zhì)量測試程序必須快速識別數(shù)據(jù)量是否因缺失數(shù)據(jù)而發(fā)生變化。數(shù)據(jù)量測試將使您能夠識別數(shù)據(jù)量何時發(fā)生變化，從而發(fā)現(xiàn)故障點(diǎn)并驗(yàn)證數(shù)據(jù)的準(zhǔn)確性。
2.數(shù)據(jù)過多
過多的數(shù)據(jù)聽起來可能不是問題(畢竟它被稱為大數(shù)據(jù))，但當(dāng)行按比例填充時，它會降低模型性能并增加計(jì)算成本。監(jiān)控?cái)?shù)據(jù)量的增加可以通過利用干凈的高質(zhì)量數(shù)據(jù)來幫助降低成本并保持模型的完整性，從而對下游用戶產(chǎn)生影響。
3.容量SLIs
SLAs(服務(wù)水平協(xié)議)對現(xiàn)代數(shù)據(jù)可靠性運(yùn)動至關(guān)重要，而容量SLIs是衡量指定SLA性能的指標(biāo)。
容量測試可用于通過監(jiān)控表大小或表增長(相對于以前的測量)來測量SLIs。例如，如果你正在測量絕對表大小，則會在以下情況下觸發(fā)事件：
? 當(dāng)前總大小(字節(jié)或行)減少到特定的量
? 當(dāng)前總大小在特定時間內(nèi)保持不變
四、數(shù)字分布測試
我的數(shù)據(jù)是否在可接受范圍內(nèi)？我的值是否在給定列的范圍內(nèi)？
這些問題都可以用分布檢驗(yàn)來回答。用學(xué)術(shù)術(shù)語來說，分布檢驗(yàn)就是驗(yàn)證給定表格中的數(shù)據(jù)是否代表正態(tài)分布的群體。從本質(zhì)上講，這些數(shù)據(jù)是否反映了現(xiàn)實(shí)？
通過定義給定列的最小值和最大值，可以很容易地在SQL中創(chuàng)建這些規(guī)則。
開箱即用分布測試的一個很好的例子是dbt的accepted_values測試，它允許創(chuàng)建者為給定的列定義一系列可接受的分布值。
Great Expectations還提供了一個通用的“單元測試”庫，可適用于你的發(fā)行版數(shù)據(jù)質(zhì)量測試。例如，如何使用Great Expectations單元測試來確?！皕ip_code列”表示有效的郵政編碼：
演示：
expect_column_values_to_be_between(
? ?column="zip_code",
? ?min_value=1,
? ?max_value=99999
)
1.不準(zhǔn)確的數(shù)據(jù)
就像缺失的數(shù)據(jù)可能會描繪出一幅虛假的現(xiàn)實(shí)畫面一樣，不準(zhǔn)確的數(shù)據(jù)同樣會對數(shù)據(jù)模型造成損害。不準(zhǔn)確的數(shù)據(jù)是指由于數(shù)據(jù)集的不正確表示而產(chǎn)生的分布問題。不準(zhǔn)確的數(shù)據(jù)可能很簡單，比如醫(yī)生錯誤地輸入了病人的體重，或者SDR在收入數(shù)字上多加了一個零。
對于醫(yī)療保健和金融機(jī)構(gòu)等需要嚴(yán)格監(jiān)管的行業(yè)來說，創(chuàng)建分布式監(jiān)控來識別不準(zhǔn)確的數(shù)據(jù)尤為重要。
2.數(shù)據(jù)多樣性
有時，進(jìn)入表中的新值不符合典型分布。這些值不一定是異常的，但也可能是異常的。當(dāng)涉及到數(shù)據(jù)質(zhì)量時，“可能”通常是我們想要關(guān)注的。
將分布測試作為數(shù)據(jù)質(zhì)量測試工作的一部分，有助于主動監(jiān)控新的和唯一的值，從而發(fā)現(xiàn)潛在的異常數(shù)據(jù)，這些數(shù)據(jù)可能表明未來存在更大的問題。
五、唯一性測試
困擾數(shù)據(jù)工程師和下游用戶的另一個常見質(zhì)量問題是重復(fù)數(shù)據(jù)。重復(fù)數(shù)據(jù)是指被復(fù)制并共享到數(shù)據(jù)庫中另一個數(shù)據(jù)記錄中的任何數(shù)據(jù)記錄。
如果沒有適當(dāng)?shù)臄?shù)據(jù)質(zhì)量測試，重復(fù)數(shù)據(jù)可能會造成各種各樣的破壞，如從垃圾郵件和降低個性化程序到不必要地增加數(shù)據(jù)庫成本和造成聲譽(yù)損害(例如，重復(fù)的社會安全號碼或其他用戶id)。
出現(xiàn)重復(fù)數(shù)據(jù)的原因多種多樣，從松散的數(shù)據(jù)聚合過程到人工輸入錯誤，但最常見的情況是在系統(tǒng)之間傳輸數(shù)據(jù)。
唯一性測試使數(shù)據(jù)團(tuán)隊(duì)能夠以編程方式識別重復(fù)記錄，以便在進(jìn)入生產(chǎn)倉庫之前對原始數(shù)據(jù)進(jìn)行清理和規(guī)范化。
如果你使用dbt，則可以使用唯一性測試來驗(yàn)證數(shù)據(jù)是否存在重復(fù)記錄，但根據(jù)你與數(shù)據(jù)堆棧集成的內(nèi)容，可以輕松地為各種工具提供開箱即用的唯一性測試。
六、參照完整性測試
參照完整性是指數(shù)據(jù)庫中表之間的父子關(guān)系。主鍵也稱為主鍵和外鍵，它是跨表連接的根數(shù)據(jù)，用于創(chuàng)建模型和獲得見解。
但是，如果用于主鍵的數(shù)據(jù)被更改或刪除，會發(fā)生什么情況呢？這就是參照完整性測試的用武之地。參照完整性測試在dbt中稱為關(guān)系測試，它確保子表中反映的任何數(shù)據(jù)都有相應(yīng)的父表。
假設(shè)你的營銷團(tuán)隊(duì)正在提取客戶ID列表，以便為假期創(chuàng)建個性化活動。你的營銷團(tuán)隊(duì)如何知道這些客戶ID映射到有姓名和地址的真人？參照完整性數(shù)據(jù)質(zhì)量測試確保在不跨依賴表共享相同更改的情況下，無法對父鍵或主鍵進(jìn)行任何更改。
七、字符串模式
在當(dāng)今的分布式世界中，發(fā)現(xiàn)各種人因錯誤導(dǎo)致的數(shù)據(jù)差異并不罕見。也許潛在客戶忘記了電子郵件地址中的某個字符，或者分析師無意中更改了一行而沒有意識到。誰知道呢！
由于數(shù)據(jù)不一致相當(dāng)常見，因此通過數(shù)據(jù)質(zhì)量測試定期對這些記錄進(jìn)行核對非常重要，以確保你的數(shù)據(jù)保持干凈和準(zhǔn)確。
使用像RegEx這樣的字符串搜索算法是驗(yàn)證列中的字符串是否匹配特定模式的絕佳方法。字符串模式可用于驗(yàn)證各種常見模式，如UUID、電話號碼、電子郵件、數(shù)字、轉(zhuǎn)義字符、日期等。
八、新鮮度檢查
所有的數(shù)據(jù)都有保質(zhì)期。當(dāng)數(shù)據(jù)定期刷新時，數(shù)據(jù)會準(zhǔn)確描繪數(shù)據(jù)源。當(dāng)數(shù)據(jù)變得陳舊或過時時，它就不再可靠，因此對下游消費(fèi)者也不再有用。
而且，當(dāng)你的下游消費(fèi)者的儀表盤沒有被刷新時，你可以隨時通知他們。
新鮮度檢查通過根據(jù)預(yù)定義的延遲規(guī)則監(jiān)視數(shù)據(jù)更新的頻率來驗(yàn)證表中數(shù)據(jù)的質(zhì)量，例如你期望在任何給定日期加載攝取作業(yè)的時間。
可以使用SQL規(guī)則手動創(chuàng)建新鮮度測試，也可以在某些ETL工具(如 dbt source freshness 命令)中本地創(chuàng)建。
1.新鮮度SLIs
與編寫SQL規(guī)則來驗(yàn)證容量SLIs的方式相同，你可以創(chuàng)建SQL規(guī)則來驗(yàn)證數(shù)據(jù)的新鮮度。在本例中，SLI類似于“數(shù)據(jù)集刷新后的小時數(shù)”。
與你的SLI一樣，為SQL規(guī)則選擇的閾值將取決于批量(或流式)數(shù)據(jù)的正常節(jié)奏以及你在新鮮度SLA中達(dá)成的協(xié)議。
九、測試是耗時的
現(xiàn)在，你的數(shù)據(jù)質(zhì)量測試庫中已經(jīng)有了一些基本的數(shù)據(jù)質(zhì)量測試，那么是時候開始了!但請記住，數(shù)據(jù)可靠性是一段旅程。數(shù)據(jù)質(zhì)量測試只是你前進(jìn)道路上的第一步。
隨著公司數(shù)據(jù)需求的增長，你的手動數(shù)據(jù)質(zhì)量測試程序可能難以跟上。即使是最全面的數(shù)據(jù)質(zhì)量測試程序也無法解決所有可能的問題。如果數(shù)據(jù)質(zhì)量測試可以覆蓋你所知道的數(shù)據(jù)可能發(fā)生的情況，我們就需要一種方法來監(jiān)控和警告我們不知道的可能發(fā)生在你的數(shù)據(jù)上的情況(我們未知的未知數(shù))。
?容易預(yù)測的數(shù)據(jù)質(zhì)量問題：對于這些已知的未知問題，自動化數(shù)據(jù)質(zhì)量測試和手動閾值設(shè)置應(yīng)該涵蓋你的基礎(chǔ)。
?不容易預(yù)測的數(shù)據(jù)質(zhì)量問題：這些是你未知的未知數(shù)。隨著數(shù)據(jù)管道變得越來越復(fù)雜，這個數(shù)字只會越來越大。
盡管如此，即使有了自動化的數(shù)據(jù)質(zhì)量測試，隨著數(shù)據(jù)生態(tài)系統(tǒng)的發(fā)展和數(shù)據(jù)的演變，繼續(xù)更新現(xiàn)有測試和閾值、編寫新測試和棄用舊測試和閾值仍然需要很大的提升。隨著時間的推移，這個過程變得乏味、耗時，并導(dǎo)致你以后需要償還更多的技術(shù)債務(wù)。
這就是利用機(jī)器學(xué)習(xí)來檢測數(shù)據(jù)異常如此強(qiáng)大的原因。它解釋了未知的未知因素，并且可以根據(jù)你的數(shù)據(jù)環(huán)境進(jìn)行擴(kuò)展。
如果數(shù)據(jù)可靠性已列入你明年的路線圖，請考慮超越數(shù)據(jù)質(zhì)量測試，采用更加自動化、規(guī)?；臄?shù)據(jù)質(zhì)量方法。
關(guān)注微信公眾號【賽希咨詢】，提前了解更多精彩內(nèi)容！
