作者：DataWorks産品經理 陳振
一、DataWorks資料品質子產品的介紹
在正式介紹資料品質子產品之前，首先要了解我們為什麼要關注資料品質。
上圖是阿裡巴巴淘寶網早期遇到的一些資料品質問題，這些問題的共同點是，因為很小的資料品質問題導緻業務上很大的誤差。某些資料品質問題從資料工程師的角度來看很小，比如基礎表中的金額機關由元變成了分，但是對業務的影響卻是非常大的，會導緻下遊信貸模型口徑變大，會給業務帶來風險。
總而言之，資料品質問題雖然從資料工程師的角度來看是個簡單問題，但是從業務的角度來看是個很嚴重的問題。是以資料品質是資料開發和治理全生命周期中，非常重要的一個環節。在DataWorks産品版圖裡，資料品質也是非常重要的子產品之一。
資料品質問題産生的原因有很多，既有底層系統層面的問題，比如來自業務系統的髒資料，也有業務系統和數倉平台對接過程中系統層面不一緻導緻的資料傳輸和轉換産生的問題，更有可能是由于業務變化而産生的，前後端業務系統中某些資料字段定義不一緻造成的，比如日期格式、金額格式。業務不一緻不一定報錯，是以在技術層面就很難察覺了。
資料品質問題帶來的後果，如上圖所示是非常嚴重的。對于一些輕量級的問題，可能僅僅影響到資料加工鍊路的時間浪費，影響資料産出的時效性，也會造成資料計算和存儲成本的浪費。更嚴重的影響是，當有問題的資料流入上層應用，會影響業務決策。
資料品質在DataWorks業務版圖中是重要的一環，是資料治理版塊的核心部分。資料品質同時也依賴底層統一進制資料服務和任務排程服務。
DataWorks資料品質子產品的特色有三點：
第一點：與資料開發排程深度內建，這也是區分于市面上其他資料品質産品的不同點。
- 全面支援DataWorks底層離線資料存儲的引擎，比如MaxCompute、EMR Hive、MC-Hologres、ADB-PG等。
- DataWorks資料品質規則由排程系統觸發，好處是可以在最佳時間點排程資料品質監控規則去掃描表。在節省計算資源的同時可以及時發現問題。
- 如果是強規則，還能自動阻塞下遊任務運作，防止問題資料污染下遊。
第二點：便捷靈活的規則定義。
- DataWorks資料品質子產品，擁有37種内置模闆規則和自定義規則。應用内置模闆可以快速的配置資料監控，如果遇到内置模闆不能覆寫的場景，也可以通過自定義的方式來适配更多業務。
- 應用内置模闆規則，有動态門檻值模式，即不需要設定具體監控名額門檻值，背景算法會自動判斷異常值。
- 自定義規則可以沉澱為模闆，友善使用者或其他使用者下次使用，這就友善了組織内部資料品質的标準化。
第三點：支援實時資料監控。
- 除了離線的資料品質監控，也支援實時資料品質監控。基于阿裡雲大資料系列産品實時資料通道Datahub和實時計算Flink的組合，能夠支援實時資料流的監控。實時資料品質監控也支援Kafka。
- 目前支援斷流、延遲和自定義三種規則。
- 支援次元表。
下圖是資料品質子產品的功能架構，主要分為離線和實時兩部分。
離線資料品質監控支援MaxCompute、EMR-Hive、Hologres和ADB-PG四種不同引擎。同時支援内置模闆規則、自定義SQL規則和自定義模闆規則。所有規則都支援四種不同的監控方式，包含絕對值監控、同比/環比監控（與上一周期業務比較）、波動率監控和動态門檻值。資料品質問題報警都可以支援短信、郵件和釘釘群通知的方式實作，這些資料品質問題和名額都會彙總到一個自定義品質報表上，然後通過郵件周期性發出來，也可以通過網頁端實時檢視。
資料品質子產品也支援Open API。Open API有一整套包括規則、分區表達、訂閱人等對象的增删改查，都是可以通過Open API完成。
資料品質規則是綁定在排程任務上的。如何綁定呢？
首先每一條規則都有對應的表要去掃描， 另外規則是需要綁定到具體的任務節上點的，這個任務節點推薦是産出表的任務節點。比如有個任務是由某段SQL腳本寫入的，每天或每小時會通過這個任務節點把資料寫入到表内，這種情況就建議把監控的規則綁定到任務上，這樣每當任務執行完之後，就會自動的觸發規則并掃描表，這個時機是最佳的，如果有問題第一時間就能發現。如果問題很嚴重，還會有進一步措施，如下圖所示，當任務節點掃描出問題，會同時産出橙色或紅色門檻值，無論是哪一種門檻值都會觸發短信、郵件或釘釘的報警。如果是紅色門檻值并且是強規則，還會阻塞任務節點的下遊節點，防止資料品質問題擴散，也避免了計算資源的浪費。
這就是資料品質離線監控的特色功能，即把規則和任務節點綁定在一起，決定一個合适的品質監控時間點。
下圖是資料品質監控所支援的37種不同模闆規則，包含數值型和波動率型兩種。其中數值型是指對某個特定名額本身來進行監控，比如表行數、字段的最大值最小值等。波動率型規則是指與曆史趨勢進行對比。背景會有曆史名額的存儲，友善使用者根據曆史波動值來判斷新名額是否存在異常。
同時，資料品質監控也支援自定義SQL方式來定義資料品質規則。這個定義出來的規則也支援數值型和波動率型的校驗。
實時資料品質監控方面。由于業務對資料的時效性要求越來越高，實時數倉的理念越來越深入人心，實時資料一旦出現資料品質問題，相對離線資料品質問題它的排查和解決的困難度都大得多。
實時資料的吞吐量很大，一旦有問題就會被淹沒在海量的資料中，排查起來就很困難，是以需要一個自動化的系統來監控。另外，實時資料品質問題會直接影響線上業務。離線的資料可能有一定的緩沖時間去修複，而實時資料品質問題會直接展現到線上業務上，是以實時資料品質問題的敏感度要比離線資料品質要高。由于資料都會歸檔到離線的資料倉，是以實時資料品質問題最終也會影響離線資料的品質。
在DataWorks資料品質子產品裡，支援三種不同的方式來監控實時資料品質，包括斷流監控、延遲監控和用自定義SQL的方式來定義業務層資料品質規則來監控。
斷流和延遲監控。斷流是指資料通道在一段時間内沒有新資料進來，這個斷流的門檻值使用者可以自己設定。延遲是指資料流中的時間戳字段和系統時鐘的內插補點過大，就說明資料延遲了，并已經失去實時系統的時效性了。
自定義SQL規則更靈活，可以引用一張次元表與實時資料關聯，也可以引用兩條實時資料鍊路對它進行雙流或多流的Join。具體做法是和業務的實際場景有關聯的。
二、資料品質使用說明
離線品質校驗：離線品質校驗是在圖形化界面上的。
以MaxCompute表資料監控為例，首先選擇一張表，然後定義一個特殊對象值，叫分區表達式。在離線系統裡，資料都會分次寫到不同的分區中，大部分情況下分區與時間或業務日期有關聯，是以最新的資料一般隻會寫到最新的分區中，定義分區表達式的目的就是為了限定品質監控範圍，這樣每次隻掃描最新分區就可以了。不同的表最新的分區名稱的定義方式不一樣，是以需要分區表達式來定義最新的分區名稱。這個定義是很靈活的，擁有完整的變量體系。
最常用的是$[yyyymmdd-1]，因為通常是第二天去處理前一天的全量業務資料，是以最新的業務日期的分區名一般是前一天的日期。這就是為什麼要把日期減1了。小時任務則是$[hh24miss-1/24]的形式，表示前一小時。
建立完分區表達式後，就可以在對應的分區表達式下建立資料品質監控規則。
點選模闆規則下的添加監控規則，來添加一個内置模闆規則。如上圖所示，會有很詳細的配置項。其中“強規則”會阻塞下遊鍊路；“弱規則”僅僅會把報警發出，不阻塞下遊；“動态門檻值”是指是否由系統來判斷異常名額。“規則字段”選項裡，可以選擇表級或字段級，字段級是可以精确到某個字段的規則。
“模闆類型”包含采樣方式、校驗方式，可根據字段類型不同而不同。“比較方式1”和“比較方式2”是針對數值型模闆和波動型模闆的比較。
如果模闆規則不符合使用者要求，使用者也可以去設定自定義規則。自定義規則使用起來很簡單，在上述建立規則的視窗選擇自定義規則，然後寫下自己的SQL（符合一定規則的SQL可被納入），并補充規則描述即可。
這裡強調兩個離線品質校驗的功能：
一個是動态門檻值功能，在配置規則的界面如果把動态門檻值選項勾選“是”，意味着使用者需要配置動态門檻值方式的規則，下面的配置選項就會簡單很多，不需要門檻值設定，而隻需要做算法參考樣本量的設定，即系統需要關注多少天之内的樣本量，然後通過平滑的算法來判斷名額點是否在預期的區間範圍内。如果在預期範圍内，就是正常值，反之就是問題值。
另外一個是自定義模闆功能，是自定義規則的進階用法。上面已經講解了自定義規則，如果出現需要自定義規則去校驗的表比較多，配置起來工作量很大的情況，自定義規則SQL腳本維護也比較困難。這就可以用到自定義模闆庫的功能。它本質上是可以把自定義規則固化成模闆，這樣在使用這個規則的時候就可以像使用内置模闆一樣簡單了。
操作方法是在資料品質界面裡進入到規則模闆庫，找到模闆庫的目錄樹，然後可以像配置SQL規則一樣去配置一個模闆，唯一不同的是可以用${table_name}指代表名$[yyyymmdd-1]指代分區表達式。建好後，在使用這個模闆規則的時候，可以在規則來源中選擇規則模闆庫，然後選擇配置好的模闆。
無論是自制模闆規則還是自定義模闆規則，都需要有一個方法把掃描的結果通知給使用者，這就需要設定一個訂閱人。設定訂閱人的方法是在DataWorks界面的訂閱管理裡，配置不同的訂閱方式，如短信、郵件或是釘釘。
另外還有試跑功能，點選試跑後就可以立即運作剛剛設定的規則，以校驗配置是否正确。
在資料品質界面可以把規則綁定到一個排程任務上。綁定排程任務有兩個入口，一個是資料品質界面，另外一個是運維中心界面。綁定成功後就能讓兩側關聯起來，進而連通資料開發和治理的流程。
無論是手動運作（試跑）還是排程觸發的規則，任務的校驗結果都可以在任務查詢菜單中看到。
（一）實時品質校驗
實時品質校驗和離線品質校驗，無論是從界面上的操作還是概念的定義上，都很相似。
實時品質校驗隻需在配置規則界面上，選擇一個Datahub Topic，系統就會自動判斷使用者需要配置實時品質校驗，然後關聯一個Flink項目，把實時品質校驗任務運作到這個Flink項目上，然後再去配置一些規則，就完成了。
（二）自定義品質報告
在配置了實時和離線的規則後，使用者可以周期性的收到資料品質報告。設定這個品質報告隻需要在菜單中進入報告模闆管理，然後建立一個報告模闆，建立時可以設定報告中顯示的内容。
可顯示的内容如下圖所示，使用者可以自主選擇。
三、資料品質最佳實踐
首先來了解下數倉系統的資料品質規則該如何配置。因為品質規則類型很多，内置模闆多，同時也支援自定義配置規則，那麼該如何選擇呢？
通常來講，在數倉入口層，即資料引入層或基礎層，一般會檢測主外鍵是否缺失，周期性資料量波動是否過大，無周期性則判斷資料是否大于固定值，資料是否有重複導入問題。
在資料清洗層和加工層，一般會增加對清洗邏輯的監控，對資料的重複性和唯一性進行監控。比如在Join或者分組的時候出現重複資料的可能性。
在高度/輕度彙總層，對彙總邏輯進行平衡值監控，基于統計，比如求和、求平均、最大最小值等名額在彙總時是否産生了一些業務語義的變形（比如明細表某些數值列的求和值一定要和彙總表上對應列的求和值一緻），監控這些平衡值以確定加工過程中彙總值不會出現業務語義上的形變。
次元表和事實表，需要關注主外鍵的一緻性和次元值（離散值）數量監控。
在出口層、應用層和報表層，需要通過特殊的業務邏輯，監控多表之間的平衡關聯和特定業務的邏輯監控，可能就會用到自定義SQL規則。
總而言之，有些規則應用會更廣泛，在表級規則中，表行數和表大小用的比較多。監測某些分區是否為空，或者資料猛增的情況。
在字段型規則中，下圖中展示的是用得比較多的。
需要使用者合理的選擇規則的強弱性。針對比較關鍵的髒資料，需要控制不要流入到下遊表中，就需要強規則；其他情況基本上是設定成弱規則。波動率的趨勢有上升、下降和絕對值等，使用者可以根據業務需要設定。
橙色門檻值不會阻塞下遊任務，紅色門檻值的強規則才會觸發阻塞下遊鍊路任務。無論是橙色還是紅色門檻值，都要精确到百分比小數點後兩位。
最後是一些常見問題：
問：資料品質子產品是否收費？
答：對公共雲使用者，按照品質規則執行個體運作數量計費，其中部分功能僅在DataWorks企業版中開啟。詳見
https://help.aliyun.com/document_detail/118793.html問：自定義規則使用怎樣的SQL文法？
答：離線自定義規則使用MaxCompute SQL，實時自定義規則使用Flink SQL。目前隻接受查詢語句，并限制為單行單列輸出。
問：收到了資料品質報警，怎樣才能快速定位觸發的業務流程節點？
答：在資料品質-任務查詢界面，找到報警對應的節點ID，再去到運維中心查詢即可。
問：資料品質與智能監控一起使用，需要特别注意什麼？
答：對離線資料來說，強弱規則運作的時機不同：
- 弱規則優先級較低，且與下遊任務并發執行，基本不影響基線産出。
- 強規則優先級高，會在下遊任務運作前執行，計入基線運作時間。
- 強規則還可能阻塞下遊任務，如果下遊有基線，請為後面的同學負責。
動态門檻值和自定義資料品質報告以及規則模闆庫等功能需要企業版及以上才能使用。
離線自定義規則使用對應引擎的SQL文法，Hologres使用PostgreSQL，EMR使用Hive SQL，實時使用Flink SQL。
運維中心智能監控的基線功能是監控任務時效性的，而資料品質的強規則會在下遊任務運作前執行，觸發強規則報警還會阻塞下遊，都會影響任務時效性。如果下遊有基線，需慎用。
資料品質介紹及實踐請參考：
https://developer.aliyun.com/learning/course/81/detail/1233DataWorks官網：
https://www.aliyun.com/product/bigdata/ide大資料&AI體驗館：
https://workbench.data.aliyun.com/experience.htm