1、背景介紹

目前數倉測試，劃分成交易、增長、社區等多個模塊，不同的數倉測試域，都會有一名測試人員負責跟進，根據每個版本每個域資源實際投入情況，組內會適當的調整資源，以滿足日常迭代需要；單交易域這塊，版本迭代需求數，通常都要并行支持多個，且隨著公司業務的發展，從承接的需求復雜度，或驗證的指標量，都會有所提升，面對如此龐大的數據體量，在有限的時間/人力資源情況下，如何制定測試策略，保障數據質量按時上線，對我們測試人員而言，無疑挑戰性是非常大的。基于此，本篇主要介紹、梳理、總結了在數倉測試實踐過程中常用的一些方法，希望在以后相關的測試工作中，對大家有所幫助，可以避點坑；

2、業務范圍

數倉交易域，數據測試范圍涵蓋了訂單、履約、商家、商品、出價、庫存、用戶、寄存、財務、流量等多個模塊，通常每個模塊數倉這邊都有維護一張或者多種對應的模型表。比如訂單（ 子訂單明細表），里面記錄訂單號，類型，狀態，支付時間等基礎信息；再比如履約（訂單履約表），里面維護了訂單號，商家，履約狀態，未履約原因，未履約責任方等信息；

數倉這邊，會在現有模型口徑的基礎上，進行日常迭代調整，同時根據prd需求不同，也會相應的新增寬表、指標，以滿足業務需求；比如我們近期做核心指標寬表，需要基于商品spu維度，統計商品首次上架時間，動銷商品數、出價商品數、曝光/點擊uv等，需要匯總商品，訂單，出價，流量等多個模塊組合數據；

3、數據鏈路

在介入測試前，我們先簡單的梳理下，數倉數據鏈路層次，自下到上，大致分為ods(源數據層)->dwd（數據清洗層）->dws(輕度匯總層)->ads/dm(數據應用層)，在生成最終結果表的過程中，也可能會使用到temp(臨時層)和dim(維表層)，用于指標加工計算；

一般而言，標準數倉分為 ODS,DWD,DIM,DWS,ADS 等，且每層分工不同,每層具體有哪些功能，下面有詳細的描述，大家可以了解下，有個整體的認知，已經熟悉的同學這部分可以跳過；

ODS：存儲原始業務數據,數據原封不動同步到到ODS,不做任何修改，并且備份，備份時可以壓縮；

DWD：數據清洗，脫敏，規范化，一般保持和ODS層一樣的數據粒度，并且提供一定的數據質量保證。同時，為了提高數據明細層的易用性，該層會采用一些維度退化手法，將維度退化至事實表中，減少事實表和維表的關聯,代表業務最小粒度層。任何數據的記錄都可以從這一層獲取，為后續的DWS做準備。另外，在該層也會做一部分的數據聚合，將相同主題的數據匯集到一張表中，提高數據的可用性；

DIM:    DWD同級別維度,比如時間維度、用戶維度、權限維度、省份維度等；

DWS：又稱數據集市或寬表。按照業務劃分,比如訂單，用戶，商家，商品等，基于各個主題在加工和使用，進行輕度匯總,如統計各個主題7天，30天，90天的行為，用戶購買行為，商品動銷行為等，在DWD基礎上關聯DIM維度數據匯總，用于提供后續的業務查詢，OLAP分析等；

ADS：要是提供給數據產品和數據分析使用的數據，一般會存放在 ES、ClickHouse、Redis等系統中供線上系統使用，也可能會存在 Hive 或者 Druid 中供數據分析和數據挖掘使用,一般在DWS基礎上生成指標,主題寬表,主要用于具體的業務服務

TEMP：每一層的計算都會有很多臨時表，專設一個temp層來存儲我們數據倉庫的臨時表

對于質量把控來說，最核心的主要在于兩個部分，dws層和ads層，原因如下：

ods的源數據同步及dwd層的數據清洗，目前datawork已經有相對完善的工作機制，可以保證數據質量，測試幾乎可以不投入資源；

大部分數據加工、處理都是在dws層/ads層完成，而且相對于其他層級而言，日常改動、迭代更為頻繁，同時出現問題的風險也比較大；

4、數據測試

4.1 數據質量保障流程

正常項目常規的流程，分析業務和需求->制定測試方案和測試計劃->設計測試用例和準備測試數據->測試執行→生成測試報告→驗收上線，數倉需求類似但又有所區別，如在需求評審階段，我們更關注指標口徑對齊，在口徑明確的前提下，落到prd文檔，開發才可以依據進行開發，測試作為標準進行驗證。

從版本時間上，分別從移交測試前、冒煙/測試階段、預發階段、生產階段，每個階段關注的點不同，具體如下：

（1）移交測試前

指標口徑對齊，舉個非常簡單的例子，統計商家半年以內全部品牌銷售數量，測試前，如下口徑點，都需要和產品/數分去溝通、明確；

• 口徑對齊后，需要根據平時測試積累的口徑，收集或開發對應的指標口徑；
• Codeview ,在閱讀開發代碼的過程中，可以快速清楚口徑的處理過程，相當于自己也在腦中重構了一次；

（2）冒煙/測試階段

• 不同的需求，數據驗證可能采取不同的驗證方案，具體的在后續‘數據測試方案’中會詳細描述；
• 數據完整性和準確性驗證；

（3）預發階段

• 回流需求，需要配合下游聯調測試，打通全流程；
• 在測試通過后，需要整理相關的測試文檔（含測試腳本，測試總結，結果，風險點等），供產品/數分/業務方驗收參考；

（4）生產階段階段

• 上線前做，需要做一輪Codeview，確保發布的是最新腳本，check調度任務依賴沒有遺漏，或者配錯情況；
• 對于生產上的指標，特別是優先級比較高的，使用頻繁的，需要在datawork里，配置DQC告警監控；
• 特殊情況下，比如口徑不明確，業務方在驗收過程中，也無法提供有效、合理的參考數據，需要和關聯方一起評估上線方案；比如商家自運行項目，需要統計每個商家營收情況，業務方無法提供生產上真實的商戶做驗證，或者最多只能提供的一兩個，也無法確保口徑準確，為了避免客訴，一般通過開通商戶白名單的方式，在數據穩定運行一段時間后，再全量放開；

4.2 數據測試方案

• 數倉需求，一般分兩類，數分需求和回流需求，每類的測試方案都有所不同；

（1）數分需求

有數分介入，需明確業務口徑，對齊后，作為測試驗數參考，走DQC驗證；

如統計商家銷售成交明細，已提供了明確的業務/技術口徑，可以編寫DQC腳本，和對應的數倉報表口徑進行比對；

（2）回流需求

沒有數分介入，產品往往只能給到業務口徑，具體的技術口徑一般情況下是提供不了的，這時就要依賴平時積累的測試口徑，需要自己寫sql比對，和數倉報表數據進行校驗；

以交易域需求為例，數分，研發，測試都有梳理沉淀具體的口徑文檔，在口徑不明確的情況下，可以借鑒：

4.3 數據測試類型

• 大數據測試，簡單的理解可以分兩種類型，黑盒測試和白盒測試

（1） 黑盒測試

開發移交后，我們根據表名，就可以開始初步的測試，類似冒煙，這個環節對業務的口徑不需要非常清楚就可以進行；

1. 檢查目標表的表結構是否與設計文檔一致
2. 主鍵是否唯一
3. 字段非空非null判斷
4. 極值是否超出正常范圍，如年齡類字段歲數大于200
5. 枚舉值檢查數據是否合理分布
6. 對應字段和字段內容是否一致，防止數據落表存在亂序情況
7. 占比類型字段值是否大于100%
8. 金額類字段是否存在負數情況
9. 數據是否有效合理，比如同分區下，賣家近7天成交訂單量比近30天成交量還多的情況

• 唯一性

--主鍵，無重復記錄
SELECT  主鍵ID
        ,count(1)
FROM    表名
WHERE   pt = '${bizdate}'
GROUP BY 主鍵ID
HAVING  count(1) > 1
;

• 為空判斷

--空值判斷，無異常空值數據
SELECT  字段1,字段2 
FROM    表名
WHERE   pt = '${bizdate}'
and     (字段1='' OR  字段2='')
;

• 為null判斷

--空值判斷
SELECT  字段1,字段2 
FROM    表名
WHERE   pt = '${bizdate}'
and     ((字段1 IS NULL OR  字段2 IS NULL)
;

• 枚舉值判斷

--枚舉類型字段，比如只有0，1兩種狀態
SELECT  distinct(枚舉類型字段)
FROM    表名
WHERE   pt = '${bizdate}' 
；

• 占比值判斷

--占比值類型字段，比如轉化率字段，無大于1的異常數據
SELECT  轉化率字段
FROM    表名
WHERE   pt = '${bizdate}'
and    轉化率字段>1
;

• 負值判斷

--比如價格類型字段值，無負值情況
SELECT  價格
FROM    表名
WHERE   pt = '${bizdate}'
and    價格 <0
;

• 有效判斷

--比如同一商品近7天的銷售量是否存在大于商品近14天的銷售量的異常數據
SELECT  近7天的銷售量，近14天的銷售量
FROM    表名
WHERE   pt = '${bizdate}'
and    近7天的銷售量>近14天的銷售量
;

（2）白盒測試

需要對開發的代碼走讀，check指標處理邏輯。同時測試也需要準備驗證腳本，或者查找到可以作為驗證參考的數據，便于口徑核對，這個環節，對測試人員的指標口徑沉淀有一定的要求。在發現指標數據存在差異的情況，需要協助開發人員一起定位差異原因，時常需要在現有的口徑基礎上，在數倉空間往上翻多層，或者一個指標定義不夠清晰，需要自行去數分空間查找口徑定義。另外，在測試通過后，需要編寫相應的DQC腳本，及時監控生產數據質量。這些對測試來說，需要有一定的sql功底；

• check字段長度，最大最小值，異常值，邊界值等
• 指標邏輯處理口徑，需要驗證關聯約束條件和where條件約束是否和prd一致，是否滿足業務需求
• 指標默認值設置是否合理；
• 涉及到占比類型字段時，開發腳本是否有考慮分母為0為null的情況；
• 計算單位是否統一；.常用的函數，特別是datediff、dateadd等時間函數，往往會導致時間范圍存在偏差，導致指標值對不上的情況；
• 數倉上線表任務調度check，主要關注是否缺少依賴；
• DQC腳本編寫，配置；

白盒測試階段，常見的開發問題匯總

• 字段未做默認處理，數值字段一般默認為0，字符串默認為‘’；

,nvl(spu_inv_num_7day,0)              as  近七天_在售商品數        -- 近七天_在售商品數
    ,spu_inv_num_30day                  as  近30天_在售商品數       -- 近30天_在售商品數 
    ,spu_cnt_30day                         as  近30天_動銷商品數       -- 近30天_動銷商品數

• 過濾條件遺漏

以下面為例，統計賣家任務發貨當天的訂單量，需加上id_del判斷，剔除無效數據。

SELECT  t1.賣家號
        ,TO_CHAR(t1.訂單時間,'yyyyMMdd') AS 訂單時間
        ,COUNT(t1.訂單號) OVER (PARTITION BY t1.賣家號,t1.任務號,TO_CHAR(t1.訂單時間,'yyyyMMdd') ) AS 賣家_任務_發貨當天的訂單 -- 賣家+任務+發貨當天的訂單                           
FROM    test1 t1 --過濾沒有刪除的訂單
WHERE   t1.is_del = 0
;

以下面為例，統計賣家歷史訂單量和gmv，因為數倉目前統計的是T+1的數據，所以需要過濾掉當天跨零點數據；

--改動前
SELECT  用戶號
        ,用戶信息
FROM    test
WHERE   pt = '${bizdate}'
；
  --需調整為：
SELECT  *
FROM    (
            SELECT  用戶號
                    ,用戶信息
                    ,ROW_NUMBER() OVER (PARTITION BY 用戶號 ORDER BY 用戶創建時間 DESC ) AS rn
            FROM    test
            WHERE   pt = '${bizdate}'
        ) 
WHERE   rn = 1
；

• 表關聯關系如果是1：1，關聯時，如果關聯健不唯一，那么關聯會產生笛卡爾，導致數據膨脹。

以下面為例，商家表同一個用戶號可能有多條數據，如果主表根據用戶號會導致結果數據膨脹；

--改動前
  NVL(在線出價商品缺貨數,0) / 在線商品出價數 
  --調整后
  CASE WHEN 在線商品出價數 IS NULL OR 在線商品出價數 = 0 THEN 0  ELSE NVL(在線出價商品缺貨數,0) / 在線商品出價數 end

• 未考慮分母為0/空的情況

以下面為例，在線出價商品缺貨率=在線出價商品缺貨數/在線商品出價數，需要加上分母為0/空的情況，給到默認值0；

-- 近7天_實際支付金額GMV
sum(case when to_char(支付時間,'yyyymmdd') BETWEEN TO_CHAR(DATEADD(TO_DATE('${bizdate}','yyyyMMdd'), -7,'dd'),'yyyyMMdd') AND '${bizdate}' then coalesce(支付金額 ,0) end ) / 100     as 近7天_實際支付金額

• 函數規則使用有誤

如統計近7天_實際支付金額GMV指標，使用的是DATEADD函數，統計近7天數據，需往前推6天，對應的前置條件應調整為‘-6’

4.4 常用的測試方法

（1）DQC對比

• 通過現有的數據/口徑作為預期，通過一定的方式關聯，直接和開發新表/口徑做對比驗證即可，可以大大的減少測試時間，測試效率非常高；

適用場景：

• 遷移、重構類需求，同一張表每個字段對應的口徑差異不大，甚至是完全相同的，我們一般采取的方式是，根據主鍵進行關聯新老表，相同的指標值預期應該一致，進行全量比對，如有差異數據記錄，需要逐條分析排查；

例：賣家履約數據遷移需求為例，根據賣家id+履約統計時間為組合維度，校驗遷移前后賣家履約率是否一致；

--全量個人商家履約數據明細驗證
SELECT  賣家id
        ,履約統計時間
        ,t1.履約率 AS 新邏輯履約率
        ,t2.履約率 AS 舊邏輯履約率
FROM    (
            SELECT  賣家id
                    ,履約統計時間
                    ,履約率
            FROM    test1
            WHERE   pt = '${bizdate}'
        ) t1
INNER JOIN  (
                SELECT  賣家id
                        ,履約統計時間
                        ,履約率
                FROM    test2
                WHERE   pt = '${bizdate}'
            ) t2
ON      t1.賣家id = t2.賣家id
AND     t1.履約統計時間 = t2.履約統計時間
WHERE   t1.履約率 <> t2.履約率
；

• 目前很多數倉迭代需求，往往都可以在數分報表平臺找到對應的指標數據，驗證的時候可以直接復用具體的表具體的字段，或者沒有現成的，如果只要簡單的處理一下，也可以進行dqc驗證；

（2）多維度對比

• 為滿足業務需求，數倉這邊開發的報表，往往同一個指標，有多重維度計算，且每層計算對應的值不一樣，這種情況下，可以先驗證一組維度數據準確性；然后基于測試通過的維度組指標作為參考組，可以快速的驗證其他維度；

適用場景：新增報表需要聚合多維度指標數據

例：賣家核心指標需求為例，需要統計在倉庫存數、出價賣家數、提交訂單量、履約訂單量、筆單價等100+個指標值，每個指標都要在不同統計維度下，如賣家類型+三級類目+品牌、賣家類型+一級類目+品牌、賣家類型+一級類目等情況下計算相應的數據，同時又分為日，周，月維度報表，單一個出價賣家數指標就有3（時間維度）*9（統計維度）=27種情況，如果在加上指標個數100+的話，需要驗證的指標條數就多達2700條，顯然沒有這么多資源去驗證，用這種方法，可以大大的提升我們測試驗證時效；

（3）表間橫向數據對比

• 表間橫向對比可以理解為兩張表或多張表之間，其中具有業務關聯或者業務含義一致的字段，可以用來做數據對比：

例：訂單費率遷移項目，費率遷移后，基于訂單維度，訂單側t1表、t2表、t3表這3張表的，每筆跨境訂單費率數據應該保持全部一致，如存在差異數據，需要拉出明細，和開發，關聯方一一確認影響；

--統計表1的訂單費率DROP TABLE IF EXISTS du_temp.t1;CREATE TABLE IF NOT EXISTS du_temp.t1 ASSELECT  訂單號        ,訂單跨境費率FROM    t1WHERE   pt = '${bizdate}';
--統計表2的訂單費率DROP TABLE IF EXISTS du_temp.t2;CREATE TABLE IF NOT EXISTS du_temp.t2 ASSELECT  訂單號        ,訂單跨境費率FROM    t2WHERE   pt = '${bizdate}';
--統計表3的訂單費率DROP TABLE IF EXISTS du_temp.t3;CREATE TABLE IF NOT EXISTS du_temp.t3 ASSELECT  訂單號        ,訂單跨境費率FROM    t3WHERE   pt = '${bizdate}';
--全量差異掃描，異常訂單告警數據SELECT  t1.訂單號        ,t1.訂單跨境費率 AS t1_訂單跨境費率        ,t2.訂單跨境費率 AS t2_訂單跨境費率        ,t3.訂單跨境費率 AS t3_訂單跨境費率FROM    du_temp.t1 t1INNER JOIN du_temp.t2 t2ON      t1.訂單號 = t2.訂單號INNER JOIN du_temp.t3 t3ON      t1.訂單號 = t3.訂單號WHERE   t1_訂單跨境費率 != t2_訂單跨境費率OR      t1_訂單跨境費率 != t3_訂單跨境費率;

（4）表內橫向數據對比

• 表內橫向對比可以理解為同一張表內，業務上相關聯的兩個或多個字段，他們存在一定的邏輯性關系，那么就可以用來做數據對比；

例1：同一個商品，正常來說，瀏覽量>=加入購物車>=生成訂單>=支付訂單>=完成交易，對于訂單部分，實際業務下單量肯定大于支付量，編寫sql如下：

select  提交訂單量,支付訂單量
FROM    test
WHERE   pt = '${bizdate}'
and 提交訂單量 < 支付訂單量;

例2:商家統計月內，應履約訂單量滿足以下條件，等于（實際履約量+超時未發貨量+虛假量+鑒定未通過量+其他賣家原因而關閉的訂單量）,這些字段都落履約表了，就可以直接對比，編寫sql如下

--統計差異商家履約數據
SELECT  商家id
        ,統計月份
        ,應履約訂單量
        ,實際履約量 + 超時未發貨量 + 虛假量 + 鑒定未通過量 + 其他賣家原因而關閉的訂單量 AS 預計應履約訂單量
FROM    test
WHERE   pt = '${bizdate}'
AND     統計月 IN ('202105','202106','202107')
AND     應履約訂單量 <> 實際履約量 + 超時未發貨量 + 虛假量 + 鑒定未通過量 + 其他賣家原因而關閉的訂單量
;

（5）execl對比

• 如果需要測試的報表字段個數太多，或者指標處理邏輯比較復雜，通過sql不好處理，那么可以考慮常用的execl表格工具，在處理上面兩種情況下，見效非?？?；

例1：核心報表需求，多個迭代版本需要驗證的新指標數有1000+，如果按照以前的方法，驗證起來會非常吃力，需要編寫的測試腳本，驗證數據工作量都非常巨大，如果使用execl，對于口徑明確的情況下，只需要一、兩個簡單的select腳本，就可以將數據指標數據放到表格里，通過自動的if函數做個判斷就行，可以快速核對指標，且后續也方面開發對齊修復，數分驗收起來，也可以大大的縮短時間；

例2：財務補貼需求，新增兩個指標，平臺實收操作服務費和平臺實收技術服務費，看似非常簡單的一個需求，但實際處理起來，需要涉及到10多個原有的財務指標關聯計算，且指標之間又存在依賴關系，加上計算過程中涉及到乘除，在統計訂單數據較多的情況下，很容易因為精度問題，導致最終結果存在失真情況。如果按照prd需求進行口徑驗證，測試要編寫上千行代碼，光腳本就要花費1天（整個需求測試估時：1.5天），在和開發報表數據做對比，因為都存在上述的失真情況，差異數據排查起來，需要把計算邏輯一層一層的比對，驗證起來非常耗時；

但通過execl處理，只要將對應的計算因子數據放到里面，通過工具本身自帶的函數，可以快速的得到預期結果；

5、生產數據質量監控

不同行業有不同的評估數據質量的標準。一般來說，數據質量可以從完整性、準確性、一致性和及時性共四個角度進行評估。

• 完整性是指數據的記錄和信息是否完整，是否存在數據缺失情況。數據缺失主要包括記錄的缺失和具體某個字段信息的缺失，兩者都會造成統計結果不準確。完整性是數據質量最基礎的保障.
• 準確性是指數據中記錄的信息和數據是否準確、是否存在異?；蛘咤e誤的信息。例如，訂單中出現錯誤的買家信息等，這些數據都是問題數據。確保記錄的準確性也是保證數據質量必不可少的一部分。
• 一致性通常體現在跨度很大的數據倉庫中。例如，某公司有很多業務數倉分支，對于同一份數據，在不同的數倉分支中必須保證一致性。例如，從在線業務庫加工到數據倉庫，再到各個數據應用節點，用戶ID必須保持同一種類型，且長度也要保持一致。
• 及時性保障數據的及時產出才能體現數據的價值。例如，決策分析師通常希望當天就可以看到前一天的數據。若等待時間過長，數據失去了及時性的價值，數據分析工作將失去意義。

目前線上數據質量監控，數倉測試這邊大多是通過DQC（Data Quality Center）數據質量中心配置進行，通過配置數據質量校驗規則，自動在數據處理任務過程中進行數據質量方面的監控，根據離線任務的運行情況實時決策是否告警、何時告警、告警方式、告警給誰；具體的配置，使用方式，數據部門已經有了非常詳細的操作文檔，我就不過多介紹，感興趣的可以直接拿來看看；

6、總結

數據校驗的方式有多種多樣，以上只是匯總了數倉測試過程中常用到的一些方法，實際應用中，還需要結合具體的需求，方法選取得當，可以起到事半功倍的效果。個人覺得，數據類測試，非?？简炄说哪托?，面對繁雜的指標，需要花費更多的時間，靜下心來，去不斷梳理、總結、沉淀，慢慢打磨形成一套可以作為自身驗證標準的方法論，也只有在不斷的熟悉本身業務的過程中，才能提升測試人員本身對數據敏感性，從而降低數據質量風險；

目前除了dqc生產配置，可以自動監控數據質量運行情況，日常迭代數倉測試過程，大多數情況還是通過人工去核對數據，在后續工作里，希望可以結合公司現有的業務，探索出更多可以提效的數據驗證方法，測試比對工具，降低數據對比的成本，不斷的完善現有的數據測試體系，持續保障數倉質量。