1、背景介紹

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

2、業(yè)務(wù)范圍

數(shù)倉交易域，數(shù)據(jù)測試范圍涵蓋了訂單、履約、商家、商品、出價(jià)、庫存、用戶、寄存、財(cái)務(wù)、流量等多個(gè)模塊，通常每個(gè)模塊數(shù)倉這邊都有維護(hù)一張或者多種對應(yīng)的模型表。比如訂單（ 子訂單明細(xì)表），里面記錄訂單號(hào)，類型，狀態(tài)，支付時(shí)間等基礎(chǔ)信息；再比如履約（訂單履約表），里面維護(hù)了訂單號(hào)，商家，履約狀態(tài)，未履約原因，未履約責(zé)任方等信息；

數(shù)倉這邊，會(huì)在現(xiàn)有模型口徑的基礎(chǔ)上，進(jìn)行日常迭代調(diào)整，同時(shí)根據(jù)prd需求不同，也會(huì)相應(yīng)的新增寬表、指標(biāo)，以滿足業(yè)務(wù)需求；比如我們近期做核心指標(biāo)寬表，需要基于商品spu維度，統(tǒng)計(jì)商品首次上架時(shí)間，動(dòng)銷商品數(shù)、出價(jià)商品數(shù)、曝光/點(diǎn)擊uv等，需要匯總商品，訂單，出價(jià)，流量等多個(gè)模塊組合數(shù)據(jù)；

3、數(shù)據(jù)鏈路

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

一般而言，標(biāo)準(zhǔn)數(shù)倉分為 ODS,DWD,DIM,DWS,ADS 等，且每層分工不同,每層具體有哪些功能，下面有詳細(xì)的描述，大家可以了解下，有個(gè)整體的認(rèn)知，已經(jīng)熟悉的同學(xué)這部分可以跳過；

ODS：存儲(chǔ)原始業(yè)務(wù)數(shù)據(jù),數(shù)據(jù)原封不動(dòng)同步到到ODS,不做任何修改，并且備份，備份時(shí)可以壓縮；

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

DIM:    DWD同級(jí)別維度,比如時(shí)間維度、用戶維度、權(quán)限維度、省份維度等；

DWS：又稱數(shù)據(jù)集市或?qū)挶?。按照業(yè)務(wù)劃分,比如訂單，用戶，商家，商品等，基于各個(gè)主題在加工和使用，進(jìn)行輕度匯總,如統(tǒng)計(jì)各個(gè)主題7天，30天，90天的行為，用戶購買行為，商品動(dòng)銷行為等，在DWD基礎(chǔ)上關(guān)聯(lián)DIM維度數(shù)據(jù)匯總，用于提供后續(xù)的業(yè)務(wù)查詢，OLAP分析等；

ADS：要是提供給數(shù)據(jù)產(chǎn)品和數(shù)據(jù)分析使用的數(shù)據(jù)，一般會(huì)存放在 ES、ClickHouse、Redis等系統(tǒng)中供線上系統(tǒng)使用，也可能會(huì)存在 Hive 或者 Druid 中供數(shù)據(jù)分析和數(shù)據(jù)挖掘使用,一般在DWS基礎(chǔ)上生成指標(biāo),主題寬表,主要用于具體的業(yè)務(wù)服務(wù)

TEMP：每一層的計(jì)算都會(huì)有很多臨時(shí)表，專設(shè)一個(gè)temp層來存儲(chǔ)我們數(shù)據(jù)倉庫的臨時(shí)表

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

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

大部分?jǐn)?shù)據(jù)加工、處理都是在dws層/ads層完成，而且相對于其他層級(jí)而言，日常改動(dòng)、迭代更為頻繁，同時(shí)出現(xiàn)問題的風(fēng)險(xiǎn)也比較大；

4、數(shù)據(jù)測試

4.1 數(shù)據(jù)質(zhì)量保障流程

正常項(xiàng)目常規(guī)的流程，分析業(yè)務(wù)和需求->制定測試方案和測試計(jì)劃->設(shè)計(jì)測試用例和準(zhǔn)備測試數(shù)據(jù)->測試執(zhí)行→生成測試報(bào)告→驗(yàn)收上線，數(shù)倉需求類似但又有所區(qū)別，如在需求評(píng)審階段，我們更關(guān)注指標(biāo)口徑對齊，在口徑明確的前提下，落到prd文檔，開發(fā)才可以依據(jù)進(jìn)行開發(fā)，測試作為標(biāo)準(zhǔn)進(jìn)行驗(yàn)證。

從版本時(shí)間上，分別從移交測試前、冒煙/測試階段、預(yù)發(fā)階段、生產(chǎn)階段，每個(gè)階段關(guān)注的點(diǎn)不同，具體如下：

（1）移交測試前

指標(biāo)口徑對齊，舉個(gè)非常簡單的例子，統(tǒng)計(jì)商家半年以內(nèi)全部品牌銷售數(shù)量，測試前，如下口徑點(diǎn)，都需要和產(chǎn)品/數(shù)分去溝通、明確；

• 口徑對齊后，需要根據(jù)平時(shí)測試積累的口徑，收集或開發(fā)對應(yīng)的指標(biāo)口徑；
• Codeview ,在閱讀開發(fā)代碼的過程中，可以快速清楚口徑的處理過程，相當(dāng)于自己也在腦中重構(gòu)了一次；

（2）冒煙/測試階段

• 不同的需求，數(shù)據(jù)驗(yàn)證可能采取不同的驗(yàn)證方案，具體的在后續(xù)‘?dāng)?shù)據(jù)測試方案’中會(huì)詳細(xì)描述；
• 數(shù)據(jù)完整性和準(zhǔn)確性驗(yàn)證；

（3）預(yù)發(fā)階段

• 回流需求，需要配合下游聯(lián)調(diào)測試，打通全流程；
• 在測試通過后，需要整理相關(guān)的測試文檔（含測試腳本，測試總結(jié)，結(jié)果，風(fēng)險(xiǎn)點(diǎn)等），供產(chǎn)品/數(shù)分/業(yè)務(wù)方驗(yàn)收參考；

（4）生產(chǎn)階段階段

• 上線前做，需要做一輪Codeview，確保發(fā)布的是最新腳本，check調(diào)度任務(wù)依賴沒有遺漏，或者配錯(cuò)情況；
• 對于生產(chǎn)上的指標(biāo)，特別是優(yōu)先級(jí)比較高的，使用頻繁的，需要在datawork里，配置DQC告警監(jiān)控；
• 特殊情況下，比如口徑不明確，業(yè)務(wù)方在驗(yàn)收過程中，也無法提供有效、合理的參考數(shù)據(jù)，需要和關(guān)聯(lián)方一起評(píng)估上線方案；比如商家自運(yùn)行項(xiàng)目，需要統(tǒng)計(jì)每個(gè)商家營收情況，業(yè)務(wù)方無法提供生產(chǎn)上真實(shí)的商戶做驗(yàn)證，或者最多只能提供的一兩個(gè)，也無法確?？趶綔?zhǔn)確，為了避免客訴，一般通過開通商戶白名單的方式，在數(shù)據(jù)穩(wěn)定運(yùn)行一段時(shí)間后，再全量放開；

4.2 數(shù)據(jù)測試方案

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

（1）數(shù)分需求

有數(shù)分介入，需明確業(yè)務(wù)口徑，對齊后，作為測試驗(yàn)數(shù)參考，走DQC驗(yàn)證；

如統(tǒng)計(jì)商家銷售成交明細(xì)，已提供了明確的業(yè)務(wù)/技術(shù)口徑，可以編寫DQC腳本，和對應(yīng)的數(shù)倉報(bào)表口徑進(jìn)行比對；

（2）回流需求

沒有數(shù)分介入，產(chǎn)品往往只能給到業(yè)務(wù)口徑，具體的技術(shù)口徑一般情況下是提供不了的，這時(shí)就要依賴平時(shí)積累的測試口徑，需要自己寫sql比對，和數(shù)倉報(bào)表數(shù)據(jù)進(jìn)行校驗(yàn)；

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

4.3 數(shù)據(jù)測試類型

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

（1） 黑盒測試

開發(fā)移交后，我們根據(jù)表名，就可以開始初步的測試，類似冒煙，這個(gè)環(huán)節(jié)對業(yè)務(wù)的口徑不需要非常清楚就可以進(jìn)行；

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

• 唯一性

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

• 為空判斷

--空值判斷，無異常空值數(shù)據(jù)
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兩種狀態(tài)
SELECT  distinct(枚舉類型字段)
FROM    表名
WHERE   pt = '${bizdate}' 
；

• 占比值判斷

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

• 負(fù)值判斷

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

• 有效判斷

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

（2）白盒測試

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

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

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

• 字段未做默認(rèn)處理，數(shù)值字段一般默認(rèn)為0，字符串默認(rèn)為‘’；

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

• 過濾條件遺漏

以下面為例，統(tǒng)計(jì)賣家任務(wù)發(fā)貨當(dāng)天的訂單量，需加上id_del判斷，剔除無效數(shù)據(jù)。

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

以下面為例，統(tǒng)計(jì)賣家歷史訂單量和gmv，因?yàn)閿?shù)倉目前統(tǒng)計(jì)的是T+1的數(shù)據(jù)，所以需要過濾掉當(dāng)天跨零點(diǎn)數(shù)據(jù)；

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

• 表關(guān)聯(lián)關(guān)系如果是1：1，關(guān)聯(lián)時(shí)，如果關(guān)聯(lián)健不唯一，那么關(guān)聯(lián)會(huì)產(chǎn)生笛卡爾，導(dǎo)致數(shù)據(jù)膨脹。

以下面為例，商家表同一個(gè)用戶號(hào)可能有多條數(shù)據(jù)，如果主表根據(jù)用戶號(hào)會(huì)導(dǎo)致結(jié)果數(shù)據(jù)膨脹；

--改動(dòng)前
  NVL(在線出價(jià)商品缺貨數(shù),0) / 在線商品出價(jià)數(shù) 
  --調(diào)整后
  CASE WHEN 在線商品出價(jià)數(shù) IS NULL OR 在線商品出價(jià)數(shù) = 0 THEN 0  ELSE NVL(在線出價(jià)商品缺貨數(shù),0) / 在線商品出價(jià)數(shù) end

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

以下面為例，在線出價(jià)商品缺貨率=在線出價(jià)商品缺貨數(shù)/在線商品出價(jià)數(shù)，需要加上分母為0/空的情況，給到默認(rèn)值0；

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

• 函數(shù)規(guī)則使用有誤

如統(tǒng)計(jì)近7天_實(shí)際支付金額GMV指標(biāo)，使用的是DATEADD函數(shù)，統(tǒng)計(jì)近7天數(shù)據(jù)，需往前推6天，對應(yīng)的前置條件應(yīng)調(diào)整為‘-6’

4.4 常用的測試方法

（1）DQC對比

• 通過現(xiàn)有的數(shù)據(jù)/口徑作為預(yù)期，通過一定的方式關(guān)聯(lián)，直接和開發(fā)新表/口徑做對比驗(yàn)證即可，可以大大的減少測試時(shí)間，測試效率非常高；

適用場景：

• 遷移、重構(gòu)類需求，同一張表每個(gè)字段對應(yīng)的口徑差異不大，甚至是完全相同的，我們一般采取的方式是，根據(jù)主鍵進(jìn)行關(guān)聯(lián)新老表，相同的指標(biāo)值預(yù)期應(yīng)該一致，進(jìn)行全量比對，如有差異數(shù)據(jù)記錄，需要逐條分析排查；

例：賣家履約數(shù)據(jù)遷移需求為例，根據(jù)賣家id+履約統(tǒng)計(jì)時(shí)間為組合維度，校驗(yàn)遷移前后賣家履約率是否一致；

--全量個(gè)人商家履約數(shù)據(jù)明細(xì)驗(yàn)證
SELECT  賣家id
        ,履約統(tǒng)計(jì)時(shí)間
        ,t1.履約率 AS 新邏輯履約率
        ,t2.履約率 AS 舊邏輯履約率
FROM    (
            SELECT  賣家id
                    ,履約統(tǒng)計(jì)時(shí)間
                    ,履約率
            FROM    test1
            WHERE   pt = '${bizdate}'
        ) t1
INNER JOIN  (
                SELECT  賣家id
                        ,履約統(tǒng)計(jì)時(shí)間
                        ,履約率
                FROM    test2
                WHERE   pt = '${bizdate}'
            ) t2
ON      t1.賣家id = t2.賣家id
AND     t1.履約統(tǒng)計(jì)時(shí)間 = t2.履約統(tǒng)計(jì)時(shí)間
WHERE   t1.履約率 <> t2.履約率
；

• 目前很多數(shù)倉迭代需求，往往都可以在數(shù)分報(bào)表平臺(tái)找到對應(yīng)的指標(biāo)數(shù)據(jù)，驗(yàn)證的時(shí)候可以直接復(fù)用具體的表具體的字段，或者沒有現(xiàn)成的，如果只要簡單的處理一下，也可以進(jìn)行dqc驗(yàn)證；

（2）多維度對比

• 為滿足業(yè)務(wù)需求，數(shù)倉這邊開發(fā)的報(bào)表，往往同一個(gè)指標(biāo)，有多重維度計(jì)算，且每層計(jì)算對應(yīng)的值不一樣，這種情況下，可以先驗(yàn)證一組維度數(shù)據(jù)準(zhǔn)確性；然后基于測試通過的維度組指標(biāo)作為參考組，可以快速的驗(yàn)證其他維度；

適用場景：新增報(bào)表需要聚合多維度指標(biāo)數(shù)據(jù)

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

（3）表間橫向數(shù)據(jù)對比

• 表間橫向?qū)Ρ瓤梢岳斫鉃閮蓮埍砘蚨鄰埍碇g，其中具有業(yè)務(wù)關(guān)聯(lián)或者業(yè)務(wù)含義一致的字段，可以用來做數(shù)據(jù)對比：

例：訂單費(fèi)率遷移項(xiàng)目，費(fèi)率遷移后，基于訂單維度，訂單側(cè)t1表、t2表、t3表這3張表的，每筆跨境訂單費(fèi)率數(shù)據(jù)應(yīng)該保持全部一致，如存在差異數(shù)據(jù)，需要拉出明細(xì)，和開發(fā)，關(guān)聯(lián)方一一確認(rèn)影響；

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

（4）表內(nèi)橫向數(shù)據(jù)對比

• 表內(nèi)橫向?qū)Ρ瓤梢岳斫鉃橥粡埍韮?nèi)，業(yè)務(wù)上相關(guān)聯(lián)的兩個(gè)或多個(gè)字段，他們存在一定的邏輯性關(guān)系，那么就可以用來做數(shù)據(jù)對比；

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

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

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

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

（5）execl對比

• 如果需要測試的報(bào)表字段個(gè)數(shù)太多，或者指標(biāo)處理邏輯比較復(fù)雜，通過sql不好處理，那么可以考慮常用的execl表格工具，在處理上面兩種情況下，見效非?？欤?/span>

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

例2：財(cái)務(wù)補(bǔ)貼需求，新增兩個(gè)指標(biāo)，平臺(tái)實(shí)收操作服務(wù)費(fèi)和平臺(tái)實(shí)收技術(shù)服務(wù)費(fèi)，看似非常簡單的一個(gè)需求，但實(shí)際處理起來，需要涉及到10多個(gè)原有的財(cái)務(wù)指標(biāo)關(guān)聯(lián)計(jì)算，且指標(biāo)之間又存在依賴關(guān)系，加上計(jì)算過程中涉及到乘除，在統(tǒng)計(jì)訂單數(shù)據(jù)較多的情況下，很容易因?yàn)榫葐栴}，導(dǎo)致最終結(jié)果存在失真情況。如果按照prd需求進(jìn)行口徑驗(yàn)證，測試要編寫上千行代碼，光腳本就要花費(fèi)1天（整個(gè)需求測試估時(shí)：1.5天），在和開發(fā)報(bào)表數(shù)據(jù)做對比，因?yàn)槎即嬖谏鲜龅氖д媲闆r，差異數(shù)據(jù)排查起來，需要把計(jì)算邏輯一層一層的比對，驗(yàn)證起來非常耗時(shí)；

但通過execl處理，只要將對應(yīng)的計(jì)算因子數(shù)據(jù)放到里面，通過工具本身自帶的函數(shù)，可以快速的得到預(yù)期結(jié)果；

5、生產(chǎn)數(shù)據(jù)質(zhì)量監(jiān)控

不同行業(yè)有不同的評(píng)估數(shù)據(jù)質(zhì)量的標(biāo)準(zhǔn)。一般來說，數(shù)據(jù)質(zhì)量可以從完整性、準(zhǔn)確性、一致性和及時(shí)性共四個(gè)角度進(jìn)行評(píng)估。

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

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

6、總結(jié)

數(shù)據(jù)校驗(yàn)的方式有多種多樣，以上只是匯總了數(shù)倉測試過程中常用到的一些方法，實(shí)際應(yīng)用中，還需要結(jié)合具體的需求，方法選取得當(dāng)，可以起到事半功倍的效果。個(gè)人覺得，數(shù)據(jù)類測試，非?？简?yàn)人的耐心，面對繁雜的指標(biāo)，需要花費(fèi)更多的時(shí)間，靜下心來，去不斷梳理、總結(jié)、沉淀，慢慢打磨形成一套可以作為自身驗(yàn)證標(biāo)準(zhǔn)的方法論，也只有在不斷的熟悉本身業(yè)務(wù)的過程中，才能提升測試人員本身對數(shù)據(jù)敏感性，從而降低數(shù)據(jù)質(zhì)量風(fēng)險(xiǎn)；

目前除了dqc生產(chǎn)配置，可以自動(dòng)監(jiān)控?cái)?shù)據(jù)質(zhì)量運(yùn)行情況，日常迭代數(shù)倉測試過程，大多數(shù)情況還是通過人工去核對數(shù)據(jù)，在后續(xù)工作里，希望可以結(jié)合公司現(xiàn)有的業(yè)務(wù)，探索出更多可以提效的數(shù)據(jù)驗(yàn)證方法，測試比對工具，降低數(shù)據(jù)對比的成本，不斷的完善現(xiàn)有的數(shù)據(jù)測試體系，持續(xù)保障數(shù)倉質(zhì)量。