[[442615]]

一 概述

1 數(shù)據(jù)質(zhì)量問題無處不在

基本上每個用數(shù)據(jù)的同學(xué)，都遇到過以下類似的問題。

• 表沒有按時產(chǎn)出，影響下游，嚴(yán)重的甚至可能影響線上效果。
• 打點(diǎn)缺失，看了報表才發(fā)現(xiàn)數(shù)據(jù)對不上。
• 數(shù)據(jù)統(tǒng)計出來，uv大于pv，很尷尬。
• 數(shù)據(jù)產(chǎn)出暴增，本來1000萬的數(shù)據(jù)變成了3000萬。
• 字段里面的枚舉值和注釋里面的對不上，沒人能解釋。
• 某些維度缺失，沒法做進(jìn)一步的數(shù)據(jù)分析。
• 做了一通分析，發(fā)現(xiàn)結(jié)果很離譜，一點(diǎn)點(diǎn)向前分析，發(fā)現(xiàn)打點(diǎn)有問題。

• ……

以上都是數(shù)據(jù)質(zhì)量的問題。本文嘗試找到一種方法，能夠盡可能的發(fā)現(xiàn)數(shù)據(jù)質(zhì)量問題并解決之。

2 數(shù)據(jù)標(biāo)準(zhǔn)

談到數(shù)據(jù)質(zhì)量，就必須了解評價數(shù)據(jù)質(zhì)量的維度。DAMA UK 提出了數(shù)據(jù)質(zhì)量的六個核心維度，見圖1。

注：DAMA International (國際數(shù)據(jù)管理協(xié)會)成立于1980年，是一個由技術(shù)和業(yè)務(wù)專業(yè)人員組成的國際性數(shù)據(jù)管理專業(yè)協(xié)會，作為一個非營利的機(jī)構(gòu)，獨(dú)立于任何廠商，旨在世界范圍內(nèi)推廣并促進(jìn)數(shù)據(jù)管理領(lǐng)域的概念和最佳實踐，為數(shù)字經(jīng)濟(jì)打下理論和實踐基礎(chǔ)。全球會員近萬人，在世界48個國家成立有分會。

圖1 數(shù)據(jù)質(zhì)量維度

• 完整性Completeness：完整性是指數(shù)據(jù)信息信息是否存在缺失的狀況，常見數(shù)據(jù)表中行的缺失，字段的缺失，碼值的缺失。比如雖然整體pv是正確的，但在某個維度下，只有部分打點(diǎn)，這就是存在完整性的問題。不完整的數(shù)據(jù)所能借鑒的價值就會大大降低，也是數(shù)據(jù)質(zhì)量問題最為基礎(chǔ)和常見的問題。常見統(tǒng)計sql：count( not null) / count(*)
• 有效性Validity ：有效性一般指范圍有效性、日期有效性、形式有效性等主要體現(xiàn)在數(shù)據(jù)記錄的規(guī)范和數(shù)據(jù)是否符合邏輯。規(guī)范指的是，一項數(shù)據(jù)存在它特定的格式，如：手機(jī)號碼一定是11位的數(shù)字;邏輯指的是，多項數(shù)據(jù)間存在著固定的邏輯關(guān)系，如：PV一定是大于等于UV的。
• 準(zhǔn)確性Accuracy：準(zhǔn)確性是指數(shù)據(jù)記錄的信息是否存在異常或錯誤。最為常見的數(shù)據(jù)準(zhǔn)確性錯誤就如亂碼。其次，異常的大或者小的數(shù)據(jù)也是不符合條件的數(shù)據(jù)。準(zhǔn)確性可能存在于個別記錄，也可能存在于整個數(shù)據(jù)集，例如數(shù)量級記錄錯誤。這類錯誤則可以使用最大值和最小值的統(tǒng)計量去審核。
• 及時性Timeliness：及時性是指數(shù)據(jù)從開始處理到可以查看的時間間隔。及時性對于數(shù)據(jù)分析本身的影響并不大，但如果數(shù)據(jù)建立的時間過長，就無法及時進(jìn)行數(shù)據(jù)分析，可能導(dǎo)致分析得出的結(jié)論失去了借鑒意義。比如：實時業(yè)務(wù)大盤數(shù)據(jù)，及時反映業(yè)務(wù)關(guān)鍵指標(biāo)的情況，暴露業(yè)務(wù)指標(biāo)的異常波動，機(jī)動響應(yīng)特殊突發(fā)情況都需要數(shù)據(jù)的及時更新和產(chǎn)出。某些情況下，數(shù)據(jù)并不是單純?yōu)榱朔治鲇枚蔷€上策略用，數(shù)據(jù)沒有及時產(chǎn)出會影響線上效果。
• 一致性Consistency：一致性是指相同含義信息在多業(yè)務(wù)多場景是否具有一致性，一般情況下是指多源數(shù)據(jù)的數(shù)據(jù)模型不一致，例如：命名不一致、數(shù)據(jù)結(jié)構(gòu)不一致、約束規(guī)則不一致。數(shù)據(jù)實體不一致，例如：數(shù)據(jù)編碼不一致、命名及含義不一致、分類層次不一致、生命周期不一致等。
• 唯一性Uniqueness： 在數(shù)據(jù)集中數(shù)據(jù)不重復(fù)的程度。唯一數(shù)據(jù)條數(shù)，和總數(shù)據(jù)條數(shù)的百分比。比如 count(distinct business key) / count(*)，一般用來驗證主鍵唯一性。

3 數(shù)據(jù)的生命周期

圖2 數(shù)據(jù)生命周期

• 數(shù)據(jù)接入：接入上游表輸入或者其它數(shù)據(jù)源的數(shù)據(jù)。
• 數(shù)據(jù)加工：編寫sql生成目標(biāo)數(shù)據(jù)表。
• 數(shù)據(jù)產(chǎn)出：定時調(diào)度任務(wù)生成數(shù)據(jù)表。
• 數(shù)據(jù)應(yīng)用：下游數(shù)據(jù)分析、報表等應(yīng)用數(shù)據(jù)。

在上面任何一個環(huán)節(jié)中，都可能出現(xiàn)數(shù)據(jù)質(zhì)量的問題，提升數(shù)據(jù)質(zhì)量需要從數(shù)據(jù)接入、數(shù)據(jù)加工、數(shù)據(jù)產(chǎn)出、數(shù)據(jù)應(yīng)用、效果跟蹤等全流程進(jìn)行把控，全局觀很重要，不拘一點(diǎn)，才能看的更全面。

二 如何解決數(shù)據(jù)質(zhì)量問題

數(shù)據(jù)質(zhì)量是數(shù)據(jù)的生命線，沒有高質(zhì)量的數(shù)據(jù)，一切數(shù)據(jù)分析、數(shù)據(jù)挖掘、數(shù)據(jù)應(yīng)用的效果都會大打折扣，甚至出現(xiàn)完全錯誤的結(jié)論，或者導(dǎo)致資損。然而數(shù)據(jù)質(zhì)量問題卻是廣泛存在的，且治理的難度很大，因為數(shù)據(jù)的生產(chǎn)、加工、流轉(zhuǎn)、應(yīng)用涉及到業(yè)務(wù)運(yùn)營、生產(chǎn)系統(tǒng)、數(shù)據(jù)系統(tǒng)、數(shù)據(jù)產(chǎn)品等上下游鏈路幾十個環(huán)節(jié)，每個環(huán)節(jié)都可能引入數(shù)據(jù)質(zhì)量問題。

集團(tuán)很多BU都有成體系的解決數(shù)據(jù)質(zhì)量的方案，集團(tuán)也有很多工具來解決數(shù)據(jù)質(zhì)量問題。本文不詳細(xì)介紹此類工具的使用，主要聚焦在數(shù)據(jù)開發(fā)過程中因為數(shù)據(jù)研發(fā)同學(xué)經(jīng)驗不足而導(dǎo)致的數(shù)據(jù)質(zhì)量問題。

圖3 數(shù)據(jù)質(zhì)量解決方法

如圖3所示，我認(rèn)為有三種方法可以在一定程度上解決數(shù)據(jù)質(zhì)量的問題。

• 數(shù)據(jù)探查
  • 發(fā)現(xiàn)完整性、一致性、有效性、準(zhǔn)確性、關(guān)聯(lián)性等問題
  • 解決的數(shù)據(jù)接入和數(shù)據(jù)產(chǎn)出階段的問題
• 開發(fā)規(guī)范
  • 發(fā)現(xiàn)數(shù)據(jù)及時性、數(shù)據(jù)一致性、數(shù)據(jù)準(zhǔn)確性等問題
  • 解決數(shù)據(jù)產(chǎn)出階段的問題
• 數(shù)據(jù)監(jiān)控
  • 避免一致性、準(zhǔn)確性等問題
  • 解決數(shù)據(jù)生產(chǎn)階段的問題

1 數(shù)據(jù)探查

數(shù)據(jù)探查的定義一般為：數(shù)據(jù)探查是探索源數(shù)據(jù)的過程，用來理解數(shù)據(jù)結(jié)構(gòu)、數(shù)據(jù)內(nèi)容、數(shù)據(jù)關(guān)系以及為數(shù)據(jù)工程識別可能存在的問題。

數(shù)據(jù)探查不止用在數(shù)據(jù)質(zhì)量領(lǐng)域，數(shù)倉開發(fā)、數(shù)據(jù)遷移等都需要對源數(shù)據(jù)進(jìn)行數(shù)據(jù)探查。數(shù)據(jù)倉庫的所有數(shù)據(jù)基礎(chǔ)都是源數(shù)據(jù)(ODS)，在開發(fā)數(shù)倉之前，需要對源數(shù)據(jù)進(jìn)行探查，才能保證產(chǎn)出的數(shù)據(jù)倉庫的準(zhǔn)確性。

題庫業(yè)務(wù)的數(shù)據(jù)缺少打點(diǎn)，數(shù)據(jù)建設(shè)主要基于業(yè)務(wù)架構(gòu)的一些中間表和結(jié)果表，在開發(fā)前期，沒有意識到數(shù)據(jù)探查的重要性，導(dǎo)致數(shù)據(jù)的準(zhǔn)確性有嚴(yán)重問題，數(shù)據(jù)研發(fā)出現(xiàn)了大量的返工現(xiàn)象。

dataworks提供了數(shù)據(jù)探查的功能，可以統(tǒng)計基本信息、數(shù)據(jù)分布、topN、直方圖等。但我試了幾次一直是探查中，易用性還不是太好。

圖4 數(shù)據(jù)探查基本方法

上圖是數(shù)據(jù)探查的一些基本功能。

本部分介紹數(shù)據(jù)探查的一些常見方法，不成體系，只是開發(fā)過程中遇到的問題，供參考。

表探查

1)數(shù)據(jù)總量探查

數(shù)據(jù)總量探索是對ods的總體數(shù)據(jù)有初步認(rèn)知，可以通過數(shù)據(jù)地圖的分區(qū)信息確認(rèn)，也可以通過寫sql計算。

數(shù)據(jù)總量探查時要探查每日增量數(shù)據(jù)總量、全量數(shù)據(jù)總量(如有需要)。

一般情況下，數(shù)據(jù)總量探查結(jié)果要與業(yè)務(wù)方或者上游數(shù)據(jù)提供方確認(rèn)是否符合預(yù)期。

2)數(shù)據(jù)產(chǎn)出時間和生命周期探查

在做數(shù)據(jù)探查時，需要探查數(shù)據(jù)產(chǎn)出時間和生命周期，對后續(xù)的任務(wù)調(diào)度和補(bǔ)數(shù)據(jù)有一定的幫助。

列探查

1)數(shù)據(jù)分布探查

數(shù)據(jù)分布探查是數(shù)據(jù)探查中最重要的部分，可以探測不同維度下數(shù)據(jù)的分布情況。一般情況下，有如下寫法。

SELECT  result          
,COUNT(*) 
FROM    xxx.table_name 
WHERE dt = 'xxxxx' 
GROUP BY result ; 

2)枚舉值探查

枚舉值探查是上面數(shù)據(jù)分布探查的一種特例，探查某些維度的枚舉值是否合理。一般情況下sql如下。

SELECT  DISTINCT result 
FROM    xxx.table_name 
WHERE dt = 'xxxxx' ; 

這種探查，可以探查出很多問題，比如上游生成某枚舉值只有0和1，但探查的時候探查出為空等。

3)唯一值探查

某些情況下，上游生成某些字段唯一(不一定是主鍵)，也需要對此類情況探查，不然做join時容易出現(xiàn)數(shù)據(jù)膨脹問題。探查sql一般如下。

SELECT  COUNT(item_id)          
,COUNT(DISTINCT item_id) 
FROM    xxx.table_name 
WHERE   dt = 'xxxxx' ; 

4)極值&異常值探查

對于某些數(shù)值類的值，必要情況下可以做一下極值探查，比如求最大值、最小值、平均值。這樣可以盡快發(fā)現(xiàn)源數(shù)據(jù)中的臟數(shù)據(jù)。

對于異常值也要探查一下，比如0、null、空字符串等。

列間探查

1)關(guān)聯(lián)字段探查

通常情況下，一張表中不同字段直接有關(guān)聯(lián)關(guān)系。比如曝光字段和曝光時長之間有關(guān)聯(lián)關(guān)系，有曝光的一定有曝光時長，或者曝光時長大于0的情況下一定有曝光。

或者uv一定大于pv，這種方法可以對dws表進(jìn)行驗證。

表間探查

1)join條件探查

此種情況屬于跨表探查。不同的表在做join時，除了探查join條件是否成功，還需要探查join得到的數(shù)量是否符合預(yù)期。

在題庫業(yè)務(wù)中，出現(xiàn)過因為系統(tǒng)bug，下游表的join條件中，有3%左右的數(shù)據(jù)join不上，但因為前期沒有做此方面的數(shù)據(jù)探查，導(dǎo)致用了很久才發(fā)現(xiàn)此問題。

還有一種情況是業(yè)務(wù)上兩張表必須join上，比如消費(fèi)表所有的用戶都應(yīng)該出現(xiàn)在用戶表，或者所有內(nèi)容都應(yīng)該出現(xiàn)在內(nèi)容維表等。

一般sql如下：

SELECT  count(DISTINCT a.itemid) 
FROM    xxx.yyy_log a 
LEFT JOIN ( 
SELECT  itemid                
FROM    xxx.zzzz                
WHERE   ds = '20210916'            
 ) b 
ON a.itemid = b.itemid 
WHERE   a.dt = '20210916' 
AND     b.itemid IS NULL ; 

業(yè)務(wù)探查

1)過濾條件不對

在某些情況下，需要從海量數(shù)據(jù)中，通過某些過濾條件撈出所需數(shù)據(jù)。比如客戶端打點(diǎn)的規(guī)范是一致的，不同的端的用戶日志都在一張表中，如果只分析某種數(shù)據(jù)，需要對數(shù)據(jù)進(jìn)行過濾。

此過濾條件一般由業(yè)務(wù)方同學(xué)提供，在數(shù)據(jù)探查階段要先做條件過濾，與業(yè)務(wù)方同學(xué)溝通過濾之后的數(shù)據(jù)是否符合預(yù)期。

2)業(yè)務(wù)上數(shù)據(jù)重復(fù)問題

屬于表唯一性探查。此問題與唯一值的現(xiàn)象類似，都是數(shù)據(jù)有重復(fù)。

不同之后在于，某些情況下，雖然數(shù)據(jù)提供方稱了某些列唯一，但在某些業(yè)務(wù)場景下，數(shù)據(jù)就是不唯一的。比如題庫的某業(yè)務(wù)中，業(yè)務(wù)方開始說不同線索得到的q_id不一致，然而q_id來自url，在業(yè)務(wù)上url確實存在重復(fù)的情況，所以q_id有重復(fù)的情況。

但在另一種數(shù)據(jù)重復(fù)的問題往往不是業(yè)務(wù)如此，而是系統(tǒng)bug導(dǎo)致的。比如某種業(yè)務(wù)中，一本書理論上處理完之后不應(yīng)該再次處理，但系統(tǒng)的bug導(dǎo)致出現(xiàn)一本書被處理多次的情況。

對于第一種情況，我們在建模時要考慮業(yè)務(wù)復(fù)雜性;而第二種情況，我們要做的是找到有效的數(shù)據(jù)，去掉臟數(shù)據(jù)。

3)數(shù)據(jù)漏斗問題

數(shù)據(jù)鏈路中數(shù)據(jù)漏斗是很關(guān)鍵的數(shù)據(jù)，在做初步數(shù)據(jù)探查時，也需要關(guān)注數(shù)據(jù)漏斗。每一層數(shù)據(jù)丟棄的數(shù)量(比例)都要和業(yè)務(wù)方確認(rèn)。

比如某一個入庫流的處理數(shù)據(jù)數(shù)量和入庫數(shù)量對比，或者入庫數(shù)量和入索引數(shù)量等，如果比例出現(xiàn)了很大的問題，需要找上游業(yè)務(wù)方修正。

4)業(yè)務(wù)上數(shù)據(jù)分布不合理

“刷子用戶”的發(fā)現(xiàn)就是一種常見的數(shù)據(jù)分布不合理，比如某個user的一天的pv在5000以上，我們大概率懷疑是刷子用戶，要把這些用戶從統(tǒng)計中剔除，并要找到數(shù)據(jù)上游過濾掉類似用戶。

一般sql如下：

SELECT  userid          
,count(*) AS cnt 
FROM    xxx.yyyy_log 
WHERE   dt = '20210913' 
GROUP BY userid 
HAVING  cnt > 5000 ; 

2 數(shù)據(jù)開發(fā)規(guī)范

上面描述了很多數(shù)據(jù)探查問題，如果認(rèn)真的做了數(shù)據(jù)探查，可以避免很多數(shù)據(jù)質(zhì)量問題。本部分描述在數(shù)據(jù)開發(fā)環(huán)節(jié)中開發(fā)同學(xué)因為經(jīng)驗等原因?qū)е碌臄?shù)據(jù)質(zhì)量問題。

SQL編寫問題

1)笛卡爾積導(dǎo)致數(shù)據(jù)膨脹

此問題往往發(fā)生在沒有對join條件進(jìn)行唯一性檢查的情況下。因為右邊數(shù)據(jù)不唯一，發(fā)生笛卡爾積，導(dǎo)致數(shù)據(jù)膨脹。如果是某些超大表，除了數(shù)據(jù)結(jié)果不對之外，會產(chǎn)生計算和存儲的浪費(fèi)。

還有一種情況，在單一分區(qū)中數(shù)據(jù)是唯一的，但join時沒有寫分區(qū)條件，導(dǎo)致多個分區(qū)同時計算，出現(xiàn)數(shù)據(jù)爆炸。

這個問題很多同學(xué)在開發(fā)中遇到了多次，一定要注意。

2)join on where順序?qū)е陆Y(jié)果錯誤

此問題也是常見問題，因為寫錯了on和where的順序，導(dǎo)致結(jié)果不符合預(yù)期。錯誤case如下。

SELECT  COUNT(*) 
FROM    xxx a 
LEFT JOIN yyy b 
ON      a.id = b.item_id 
WHERE   a.dt = '${bizdate}' 
AND     b.dt = '${bizdate}' ; 

在上面的sql中，因為b.dt在where條件中，那么沒有join上的數(shù)據(jù)會被過濾掉。

3)inner join和outer join用錯問題

此問題偶發(fā)，往往是開發(fā)同學(xué)沒有理解業(yè)務(wù)或者typo，導(dǎo)致結(jié)果不符合預(yù)期。

寫完sql一定要檢查，如果有可能請別的同學(xué)review sql。

4)時間分區(qū)加引號

一般情況下，分區(qū)都是string數(shù)據(jù)類型，但在寫sql時，分區(qū)不寫引號也可以查詢出正確的數(shù)據(jù)，導(dǎo)致有些同學(xué)不習(xí)慣在分區(qū)上加引號。

但某些情況下，如果沒有加引號，查詢的數(shù)據(jù)是錯誤的。所以一定要在時間分區(qū)上加引號。

5)表循環(huán)依賴問題

在開發(fā)時，偶爾會出現(xiàn)三個表相互依賴的問題，這種情況比較少見，而且在數(shù)據(jù)開發(fā)階段不容易發(fā)現(xiàn)，只有再提交任務(wù)之后才會發(fā)現(xiàn)。

要避免這種情況，需要明確一些開發(fā)規(guī)范。比如維表和明細(xì)表都要從ods表中查得，不能維表和明細(xì)表直接互相依賴。對于某些復(fù)雜的邏輯，可以通過中間表的形式實現(xiàn)重用。

6)枚舉值問題

在做etl時，需要把某些枚舉值轉(zhuǎn)化成字符串，比如1轉(zhuǎn)成是、0轉(zhuǎn)成否等。

常見的寫法是在sql中寫case when。

但對于某種一直增長的枚舉值，這種方法不合適，否則增加一種編碼就要改一次sql，而且容易出現(xiàn)sql膨脹的問題。

推薦通過與碼表join的方法解決此問題。

性能問題

1)join on where順序的性能問題

上面提到過join的on和where執(zhí)行順序的問題，這也關(guān)系到j(luò)oin的性能問題。因為是先on后where，建議先把數(shù)據(jù)量縮小再做join，這也可以提升性能。

(1) 如果是對左表(a)字段過濾數(shù)據(jù)，則可以直接寫在where后面，此時執(zhí)行的順序是：先對a表的where條件過濾數(shù)據(jù)然后再join b 表;

(2) 如果是對右表(b)字段過濾數(shù)據(jù)，則應(yīng)該寫在on 條件后面或者單獨(dú)寫個子查詢嵌套進(jìn)去，這樣才能實現(xiàn)先過濾b表數(shù)據(jù)再進(jìn)行join 操作;

如果直接把b表過濾條件放在where后面，執(zhí)行順序是：先對a表數(shù)據(jù)過濾，然后和b表全部數(shù)據(jù)關(guān)聯(lián)之后，在reduce 階段才會對b表過濾條件進(jìn)行過濾數(shù)據(jù)，此時如果b表數(shù)據(jù)量很大的話，效率就會很低。因此對于應(yīng)該在map 階段盡可能對右表進(jìn)行數(shù)據(jù)過濾。

我一般對右表做一個子查詢。

2)小維表 map join

在Hive中

若所有表中只有一張小表，那可在最大的表通過Mapper的時候?qū)⑿”硗耆诺絻?nèi)存中，Hive可以在map端執(zhí)行連接過程，稱為map-side join，這是因為Hive可以和內(nèi)存的小表逐一匹配，從而省略掉常規(guī)連接所需的reduce過程。即使對于很小的數(shù)據(jù)集，這個優(yōu)化也明顯地要快于常規(guī)的連接操作。其不僅減少了reduce過程，而且有時還可以同時減少M(fèi)ap過程的執(zhí)行步驟。參考文末鏈接一。

在MaxCompute中

mapjoin在Map階段執(zhí)行表連接，而非等到Reduce階段才執(zhí)行表連接，可以縮短大量數(shù)據(jù)傳輸時間，提升系統(tǒng)資源利用率，從而起到優(yōu)化作業(yè)的作用。

在對大表和一個或多個小表執(zhí)行join操作時，mapjoin會將您指定的小表全部加載到執(zhí)行join操作的程序的內(nèi)存中，在Map階段完成表連接從而加快join的執(zhí)行速度。

文檔中給的例子如下：

select /*+ mapjoin(a) */ 
a.shop_name, 
a.total_price, 
b.total_price 
from sale_detail_sj a join sale_detail b 
on a.total_price < b.total_price or a.total_price + b.total_price < 500; 

參考文末鏈接二。

3)超大維表 hash clustering

在互聯(lián)網(wǎng)大數(shù)據(jù)場景中，一致性維表的數(shù)據(jù)量都比較大，有的甚至到幾億甚至十億的量級，在這個數(shù)據(jù)量級下做join，會這種任務(wù)往往耗時非常長，有些任務(wù)甚至需要耗費(fèi)一天的時間才能產(chǎn)出。

在這種情況下，為了縮短執(zhí)行時間，通?？梢哉{(diào)大join階段的instance數(shù)目，增加join階段的內(nèi)存減少spill等，但是instance的數(shù)目不能無限增長，否則會由于shuffle規(guī)模太大造成集群壓力過大，另外內(nèi)存的資源也是有限的，所以調(diào)整參數(shù)也只是犧牲資源換取時間，治標(biāo)不治本。

Hash clustering，簡而言之，就是將數(shù)據(jù)提前進(jìn)行shuffle和排序，在使用數(shù)據(jù)的過程中，讀取數(shù)據(jù)后直接參與計算。這種模式非常適合產(chǎn)出后后續(xù)節(jié)點(diǎn)多次按照相同key進(jìn)行join或者聚合的場景。

Hash clustering是內(nèi)置在MaxCompute中，不用顯示的指定，很方便。

參考文末鏈接三。

4) 數(shù)據(jù)傾斜問題

Hive/MaxCompute在執(zhí)行MapReduce任務(wù)時經(jīng)常會碰到數(shù)據(jù)傾斜的問題，表現(xiàn)為一個或者幾個reduce節(jié)點(diǎn)運(yùn)行很慢，延長了整個任務(wù)完成的時間，這是由于某些key的條數(shù)比其他key多很多，這些Key所在的reduce節(jié)點(diǎn)所處理的數(shù)據(jù)量比其他節(jié)點(diǎn)就大很多，從而導(dǎo)致某幾個節(jié)點(diǎn)遲遲運(yùn)行不完。

常見的情況比如join的分布不均勻，group by的時候不均勻等。

具體的解決方法可以參考文末鏈接四。

3 數(shù)據(jù)監(jiān)控

提交數(shù)據(jù)任務(wù)后，如何能正確及時的監(jiān)控任務(wù)也是非常重要的。在數(shù)據(jù)監(jiān)控方面，集團(tuán)提供了很多強(qiáng)大的產(chǎn)品來解決問題，簡單介紹如下。

數(shù)據(jù)及時性監(jiān)控(摩薩德)

摩薩德監(jiān)控是對任務(wù)運(yùn)行狀態(tài)的監(jiān)控，包括任務(wù)運(yùn)行出錯、未按規(guī)定時間運(yùn)行。摩薩德是對任務(wù)的監(jiān)控，因此特別適合監(jiān)控數(shù)據(jù)產(chǎn)出的實時性。比如某些表需要在幾點(diǎn)產(chǎn)出，如果沒有產(chǎn)出則報警等。當(dāng)前摩薩德只能在Dataworks使用。

數(shù)據(jù)產(chǎn)出監(jiān)控(DQC)

不同于摩薩德對任務(wù)的監(jiān)控，DQC監(jiān)控是對表和字段的監(jiān)控，是任務(wù)運(yùn)行后觸發(fā)監(jiān)控條件從而觸發(fā)報警。

數(shù)據(jù)質(zhì)量中心(DQC，Data Quality Center)是集團(tuán)推出的數(shù)據(jù)質(zhì)量解決方案，它可以提供整個數(shù)據(jù)的生命周期內(nèi)的全鏈路數(shù)據(jù)質(zhì)量保障服務(wù)。通過DQC，我們能夠在數(shù)據(jù)生產(chǎn)加工鏈路上監(jiān)控業(yè)務(wù)數(shù)據(jù)的異常性，如有問題第一時間發(fā)現(xiàn)，并自動阻斷異常數(shù)據(jù)對下游的影響，保障數(shù)據(jù)的準(zhǔn)確性。

DQC可以做以下監(jiān)控

• 數(shù)據(jù)產(chǎn)出行數(shù)波動監(jiān)控
• 業(yè)務(wù)主鍵唯一性監(jiān)控
• 關(guān)鍵字段空值監(jiān)控
• 匯總數(shù)據(jù)合理性監(jiān)控

DQC的流程如下：

• 用戶進(jìn)行規(guī)則配置
• 通過定時的調(diào)度任務(wù)觸發(fā)檢查任務(wù)執(zhí)行
• 基于任務(wù)配置，獲取樣本數(shù)據(jù)
• 基于計算返回檢驗結(jié)果
• 調(diào)度根據(jù)檢驗結(jié)果，決定是否阻斷干預(yù)(強(qiáng)依賴、弱依賴)

不過DQC雖然很強(qiáng)大，但其配置還是很繁瑣的，而且要設(shè)置波動規(guī)則，需要較長時間觀測，表和字段多的時候配置工作特別大。有團(tuán)隊研究了Auto-DQC，可以自動化監(jiān)控DQC配置。

其它數(shù)據(jù)質(zhì)量監(jiān)控平臺

其它值得關(guān)注的數(shù)據(jù)質(zhì)量監(jiān)控平臺包括

• Apache Griffin(Ebay開源數(shù)據(jù)質(zhì)量監(jiān)控平臺)
• Deequ(Amazon開源數(shù)據(jù)質(zhì)量監(jiān)控平臺)
• DataMan(美團(tuán)點(diǎn)評數(shù)據(jù)質(zhì)量監(jiān)控平臺)

三 后記

解決數(shù)據(jù)質(zhì)量問題沒有銀彈，數(shù)據(jù)質(zhì)量管理不單純是一個概念，也不單純是一項技術(shù)、也不單純是一個系統(tǒng)，更不單純是一套管理流程，數(shù)據(jù)質(zhì)量管理是一個集方法論、技術(shù)、業(yè)務(wù)和管理為一體的解決方案。本文簡單總結(jié)了我們當(dāng)前遇到的數(shù)據(jù)質(zhì)量問題和處理方法，也希望與對數(shù)據(jù)質(zhì)量敢興趣的同學(xué)多多交流。

文中部分技術(shù)和解決已經(jīng)在uc和夸克業(yè)務(wù)上踐行，大幅提升了業(yè)務(wù)的數(shù)據(jù)質(zhì)量，拿到較好結(jié)果。

鏈接一：https://developer.aliyun.com/article/67300

鏈接二：https://help.aliyun.com/document_detail/73785.html

鏈接三：

https://developer.aliyun.com/article/665154

https://developer.aliyun.com/article/665246

鏈接四：https://developer.aliyun.com/article/60908

【本文為51CTO專欄作者“阿里巴巴官方技術(shù)”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】

戳這里，看該作者更多好文