如何保障數倉資料質量？

園陌發表於2022-06-07

導讀

有贊資料包表中心為商家提供了豐富的資料指標，包括30+頁面，100+資料包表以及400+不同型別的資料指標，它們幫助商家更合理、科學地運營店鋪，同時也直接提供分析決策方法供商家使用。並且，每天在跑的底層任務和涉及的資料表已經達到千級別。

面對如此龐大的資料體系，作為測試如何制定質量保障策略呢？這篇文章將從：1.有贊資料鏈路、2.資料層測試、 3.應用層測試、 4.後續規劃這四個方面展開。

一、有贊資料鏈路

1、資料鏈路介紹

首先介紹有讚的資料總體架構圖：

自頂向下可以大致劃分為應用服務層、資料閘道器層、應用儲存層、資料倉儲，並且作業開發、後設資料管理等平臺為資料計算、任務排程以及資料查詢提供了基礎能力。

以上對整體架構做了初步的介紹，對於質量把控來說，最核心的兩個部分是：資料倉儲以及資料應用部分。因為這兩部分屬於資料鏈路中的核心環節，相對於其他層級而言，日常改動也更為頻繁，出現問題的風險也比較大。

二、資料層測試

1、整體概覽

首先，針對資料層的質量保障，可以分成三個方面：資料及時性、完整性、準確性。

2、資料及時性

資料及時性，顧名思義就是測試資料需要按時產出。及時性重點關注的三個要素是：定時排程時間、優先順序以及資料deadline。其中任務的優先順序決定了它獲取資料計算資源的多少，影響了任務執行時長。資料deadline則是資料最晚產出時間的統一標準，需要嚴格遵守。

這三要素中，屬於“普世規則”且在質量保障階段需要重點關注的是：資料deadline。那麼我們基於資料deadline，針對及時性的保障策略就可分為兩種：

監控離線資料任務是否執行結束。這種方式依賴於有贊作業開發平臺的監控告警，若資料任務在deadline時間點未執行完成，則會有郵件、企微、電話等告警形式，通知到相應人員。

檢查全表條數或者檢查分割槽條數。這種方式依賴介面自動化平臺，通過呼叫dubbo介面，判斷介面返回的資料指標是否為0，監控資料是否產出。

其次我們可以關注失敗、重試次數，當任務執行過程中出現多次失敗、重試的異常情況，可以丟擲告警讓相關人員感知。這部分的告警是對deadline告警的補充，目前在有贊作業開發平臺上也有功能整合。

3、資料完整性

資料完整性，顧名思義看資料是不是全，重點評估兩點：資料不多、資料不少。

資料不多：一般是檢查全表資料、重要列舉值，看資料有沒有多餘、重複或者資料主鍵是否唯一。
資料不少：一般是檢查全表資料、重要欄位（比如主鍵欄位、列舉值、日期等），看欄位的數值是否為空、為null等。

可見資料完整性和業務本身關聯度沒有那麼密切，更多的是數倉表的通用內容校驗。所以從一些基礎維度，我們可以將測試重點拆成表級別、欄位級別兩個方向。

表級別完整性：

全表維度，通過檢視全表的總行數/表大小，若出現表總行數/總大小不變或下降，說明表資料可能出現了問題。
分割槽維度，通過檢視當日分割槽表的資料行數/大小，若和之前分割槽相比差異太大（偏大或偏小），說明表資料可能出現了問題。

目前有贊後設資料管理平臺已整合相關資料檢視：

欄位級別完整性：

唯一性判斷：保證主鍵或某些欄位的唯一性，防止資料重複導致和其他表join之後資料翻倍，導致最終統計資料偏大。

比如判斷ods層訂單表中的訂單號是否唯一，編寫sql：

select 
count(order_no)
,count(distinct order_no) 
from ods.xx_order

若兩者相等，則說明order_no值是表內唯一的；否則說明order_no表內不唯一，表資料存在問題。

非空判斷：保證重要欄位非空，防止空資料造成和表join之後資料丟失，導致最終統計資料偏少。

比如判斷ods層訂單表中的訂單號是否出現null，編寫sql：

select 
count(*) 
from ods.xx_order 
where order_no is null

若結果等於0，則說明order_no不存在null；若結果大於0，則說明order_no存在null值，表資料存在問題。

列舉型別判斷：保證列舉欄位值都在預期範圍之內，防止業務髒資料，導致最終統計結果出現遺漏/多餘的資料型別。

比如判斷ods層訂單表中的shop_type欄位中所有列舉值是否符合預期，編寫sql：

select shop_type from ods.xx_order group by shop_type

分析查詢結果是否滿足預期，確保不會出現遺漏/多餘的列舉型別。

資料有效性判斷：判斷資料格式是否滿足預期，防止欄位的資料格式不正確導致資料統計的錯誤以及缺失。常見的有日期格式yyyymmdd。

一旦出現資料完整性問題，對資料質量的影響很大。所以完整性策略更適用於ods層，因為我們更期望從源頭發現並解決資料不合理問題，及時止損，避免髒資料進入下游之後，資料汙染擴大。

另外，我們看到完整性校驗內容邏輯簡單，且比較固定，稍微進行簡單的抽象就能將其模板化。那麼作為測試，我們更傾向於將資料完整性校驗做成工具。目前有贊“資料形態工具”已經落地，下面給出我的一些思路：

針對所有表來說，普世性的規則，比如表主鍵的唯一性。
針對不同型別比如數值、String、列舉、日期格式型別，列舉出常見的資料判斷規則。
給每項規則進行等級劃分，比如表的主鍵不唯一，記為critical。String型別欄位的空值比例大於70%，記為warning。
根據表資料是否滿足上述這些規則，最終落地一份視覺化報告，測試人員可根據報告內容評估資料質量。

4、資料準確性

資料準確性，顧名思義資料要“準確”。“準確”這個概念比較抽象，因為我們很難通過一個強邏輯性的判斷，來說明資料有多準，大部分都存在於感性的認知中。所以準確性測試也是在資料質量保障過程中思維相對發散的一個方向。

經過總結，我們可以從欄位自身檢查、資料橫向對比、縱向對比、code review等方面，去把控資料的準確性，這些測試點和業務的關聯也比較密切。

4.1 自身檢查

資料自身檢查，是指在不和其他資料比較的前提下，用自身資料來檢查準確的情況，屬於最基本的一種檢查。常見的自身檢查包括：檢查數值類指標大於0、比值類指標介於0-1範圍。這類基礎規則，同資料完整性，也可以結合“資料形態工具”輔助測試。

舉個例子，比如針對訂單表，支付金額必然是大於等於0，不會出現負數的情況，編寫sql：

select 
count(pay_price) 
from 
dw.dws_xx_order 
where par = 20211025 and pay_price<0

若結果為0，說明支付金額都是大於0，滿足預期；否則若count結果大於0，說明資料存在問題。

4.2 表內橫向資料對比

表內橫向對比可以理解為同一張表內，業務上相關聯的兩個或多個欄位，他們存在一定的邏輯性關係，那麼就可以用來做資料對比。

比如針對訂單表，根據實際業務分析易得：針對任何一家店鋪的任意一款商品，都滿足訂單數 >=下單人數，編寫sql：

select 
kdt_id
,goods_id
,count(order_no)
,count(distinct buyer_id) 
from dw.dws_xx_order
where par = '20211025'
group by kdt_id,goods_id
having count(order_no)<count(distinct buyer_id)

若查詢結果不存在記錄，則說明不存在訂單數<下單人數，反向說明訂單數>=下單人數，則符合預期；否則若查詢結果的記錄大於0，則不符合預期。

4.3 表間橫向資料對比

表間橫向對比可以理解為兩張表或多張表之間，其中具有業務關聯或者業務含義一致的欄位，可以用來做資料對比：

同型別表之間對比：針對hive裡的支付表A和支付表B，裡面都有支付金額欄位，那麼同樣維度下的表A.支付金額 = 表B.支付金額。
多套儲存之間對比：比如有贊資料包表中心針對支付表，應用層儲存分別用到了mysql和kylin，用作主備切換，那麼相同維度下的kylin-表A.支付金額 = mysql-表B.支付金額。
多個系統之間對比：跨系統之間，比如有讚的資料包表中心和crm系統，兩個系統都有客戶指標資料，那麼相同維度下的資料包表中心-表A.客戶指標 = crm-表B.客戶指標。

我們深度剖析資料橫向對比的底層邏輯，本質就是兩張表的不同欄位，進行邏輯運算子的比較，也比較容易抽象成工具。目前有贊“資料比對工具”已經落地，下面給出我的一些思路：

輸入兩張表，分別設定兩表的主鍵。
輸入兩張表中需要對比的欄位，且設定對比的運算子，比如>、=、<。
根據設定的規則，最終資料對比通過、不通過的記錄，落地一份視覺化報告，測試人員可根據報告內容評估資料質量。

4.4 縱向資料對比

縱向對比就是上下游的資料比較，目的是確保重要欄位在上下游的加工過程中沒有出現問題。

比如數倉dw層存在訂單的明細表，資料產品dm層存在訂單數的聚合表，那麼二者在相同維度下的資料統計結果，應該保持一致。

4.5 code review

首先，在進行code review之前的需求評審階段，我們先要明確資料統計的詳細口徑是什麼，下面舉兩個實際的需求例子。

需求1：（錯誤示例）統計時間內店鋪內所有使用者的支付金額。問題所在：需求描述太過於簡潔，沒有闡述清楚資料統計的時間維度以及過濾條件，導致統計口徑不清晰，要求產品明確口徑。
需求2：（正確示例）有贊全網商家域店鋪維度的離線支付金額。支援自然日、自然周、自然月。統計時間內，所有付款訂單金額之和（剔除抽獎拼團、剔除禮品卡、剔除分銷供貨訂單）。

明確需求之後，下面詳細介紹code review的一些常見關注點：

1）關聯關係 & 過濾條件