如何實施數據質量流程

數據倉庫系統中的數據質量 (DQ) 變得越來越重要。 不斷增加的監管要求，以及數據倉庫解決方案日益複雜的問題，迫使公司加強（或啟動）數據質量計劃。

本文主要關注“傳統”數據倉庫，但數據質量也是數據湖等更“現代”概念中的一個問題。 它將展示一些需要考慮的要點以及在實施數據質量策略時要避免的一些常見陷阱。 它不包括選擇正確的技術/工具來構建 DQ 框架的部分。

DQ 項目最難解決的問題之一是，乍一看，它為業務部門創造了大量工作，卻沒有提供任何額外的功能。 數據質量計劃通常只有在以下情況下才有強有力的支持者：

• 存在嚴重影響業務的數據質量問題。
• 監管機構執行數據質量標準（例如，金融行業的 BCBS 239）。

DQ 的處理類似於軟件開發中的測試——如果一個項目用完了時間和/或預算，這部分往往會首先減少。

當然，這並不是全部真相。 良好的數據質量系統有助於及早發現錯誤，從而加快向用戶提供“足夠好”質量的數據的過程。

術語定義

在討論這個話題之前，對所使用的術語有一個共同的理解是很重要的。

數據倉庫 (DWH)

數據倉庫（DWH）是一種非操作系統，主要用於決策支持。 它整合了操作系統的數據（全部或較小的子集），並為 DWH 系統的用戶提供查詢優化的數據。 數據倉庫應該在企業內部提供“單一版本的事實”。 數據倉庫通常由階段/層組成：

操作數據大部分未更改地存儲到暫存層中。 核心層包含合併和統一的數據。 下一個可選階段是派生區域，提供派生數據（例如，客戶的銷售分數）和聚合。 數據集市層包含針對給定用戶組優化的數據。 數據集市通常包含聚合和大量派生指標。 數據倉庫用戶通常只使用數據集市層。

在每個階段之間，都會發生某種數據轉換。 通常，數據倉庫會定期加載操作數據的增量提取，並包含保存歷史數據的算法。

數據質量

數據質量通常被定義為衡量產品滿足用戶要求的程度。 不同的用戶可能對產品有不同的要求，因此實施取決於用戶的觀點，識別這些需求很重要。

數據質量並不意味著數據必須完全或幾乎沒有錯誤——它取決於用戶的要求。 “足夠好”的方法是一個不錯的選擇。 如今，大公司有“數據（或信息）政府政策”，數據質量是其中的一部分。 數據政府政策應描述貴公司如何處理數據以及如何確保數據具有正確的質量以及不違反數據隱私規則。

數據質量是一個持續的話題。 必須實現 DQ 電路環路（見下一章）。 監管要求和合規性規則也會影響所需的數據質量，例如 TCPA（美國電話消費者保護法）或歐洲針對隱私問題的 GDPR，以及行業特定規則，例如歐盟保險業的 Solvency II，BCBS 239和其他用於銀行業務，等等。

數據質量電路迴路

與所有質量主題一樣，DQ 是一項旨在保持令人滿意的質量的持續活動。 作為 DQ 項目的結果，必須實現類似於以下的電路環路：

這個循環中的步驟將在接下來的章節中描述。

數據質量角色

要實施成功的 DQ 計劃，需要以下角色：

• 數據所有者。 數據所有者對數據質量負責，同時也對數據隱私保護負責。 數據所有者“擁有”一個數據域，控制訪問，並負責確保數據質量並採取行動修復發現。 在較大的組織中，通常會找到多個數據所有者。 例如，數據域可以是營銷數據、控制數據等。如果公司中存在多個數據所有者，則應該有一個人（數據所有者或其他人）負責整個數據質量流程。 數據所有者應具有強制執行數據質量和支持 DQ 流程的強大權限； 因此，數據所有者通常是高級利益相關者。 對業務領域的良好理解以及良好的溝通技巧很重要。
• 數據管家。 數據管家幫助在企業內實施數據質量，支持數據用戶解決有關如何解釋數據/數據模型、數據質量問題等問題。數據管家通常是數據所有者的員工，或者可以組織在數據質量能力中心或 DQ 團隊。 數據管理員可以有 IT 或業務背景，但應該了解雙方。 分析技能以及對他們所支持的業務領域的良好理解，再加上強大的溝通技巧，是成功數據管家的主要先決條件。
• 數據用戶。 這些是處理數據的數據倉庫用戶。 數據用戶通常使用數據集市層，並對數據的工作結果負責。 數據用戶確保對他們需要的質量水平進行充分的數據質量檢查。 數據用戶需要深入了解他們的數據、業務領域以及解釋數據所需的分析技能。 在每個業務部門的數據用戶中找幾個人負責數據質量問題是合理的。

為確保成功，重要的是在 DQ 項目的早期階段明確定義並在組織內廣泛接受這些角色。 為這些角色找到支持項目的有能力的數據專家同樣重要。

定義規則

查找並實施有用的 DQ 檢查/規則。 定義 DQ 規則需要對您的數據倉庫及其使用有充分的了解。

如何找到 DQ 規則？

如前所述，數據用戶（和數據所有者）負責數據使用，因此也負責所需的數據質量水平。 數據用戶應該對他們的數據有很好的理解，以便他們可以為有用的數據質量規則提供最佳輸入。

他們也是分析數據質量規則結果的人，所以讓他們定義自己的規則總是一個好主意。 這進一步提高了對分配給數據用戶單位的 DQ 規則結果的檢查和評級的接受度（參見“分析”一章）。

這種方法的缺點是數據用戶通常只知道數據集市層，而不知道數據倉庫的早期層。 如果數據在“較低”階段損壞，則僅通過檢查數據倉庫的“頂層”就無法檢測到。

處理錯誤

數據倉庫中可能會出現哪些已知錯誤？

• 數據倉庫中的錯誤轉換邏輯
  • 您的 IT 環境越複雜，轉換邏輯就越複雜。 這些是最常見的 DQ 問題，此類錯誤的影響可能是“丟失”數據、重複、不正確的值等。
• 負載過程不穩定或負載處理不當
  • 數據倉庫的負載可能是一個複雜的過程，其中可能包括作業編排定義中的錯誤（作業開始得太早或太晚、作業未執行等）。 由於手動干預（例如，某些作業被跳過，某些作業以錯誤的截止日期或昨天的數據文件啟動）導致的錯誤經常發生在加載過程由於某些中斷而超出頻帶時發生。
• 數據源的錯誤數據傳輸
  • 數據傳輸通常作為源系統的一項任務來實現。 作業流程中的異常或中斷可能會導致交付空的或不完整的數據。
• 錯誤的操作數據
  • 操作系統中的數據包含迄今為止無法識別的錯誤。 聽起來可能很奇怪，但數據倉庫項目中的陳詞濫調是，在數據包含在 DWH 中之前，通常看不到操作數據的質量。
• 對數據的誤解
  • 數據是正確的，但用戶不知道如何正確解釋。 這是一個非常常見的“錯誤”，嚴格來說不是數據質量問題，而是與數據治理有關，是數據管理員的任務。

這些問題通常是由於人們缺乏適當的知識和技能來定義、實施、運行和使用數據倉庫解決方案造成的。

數據質量維度

DQ 維度是識別和集群 DQ 檢查的常用方法。 有許多定義，並且維度的數量變化很大：您可能會發現 16 個，甚至更多的維度。 從實踐的角度來看，從幾個維度開始並在您的用戶中找到對它們的一般理解會不會令人困惑。

• 完整性：所需的所有數據是否可用且可訪問？ 是否所有需要的資源都可用並已加載？ 階段之間是否丟失了數據？
• 一致性：是否存在錯誤/衝突/不一致的數據？ 例如，處於“已終止”狀態的合同的終止日期必須包含早於或等於合同開始日期的有效日期。
• 唯一性：是否有重複？
• 完整性：所有數據是否正確鏈接？ 例如，是否有訂單鏈接到不存在的客戶 ID（典型的參照完整性問題）？
• 及時性：數據是最新的嗎？ 例如，在一個每天更新的數據倉庫中，我希望昨天的數據今天可用。

數據倉庫加載過程生成的數據也很有幫助。

• 丟棄數據的表。 您的數據倉庫可能具有跳過/延遲由於技術問題（例如，格式轉換、缺少強制值等）而無法加載的數據的過程。
• 記錄信息。 明顯的問題可能會寫入日誌表或日誌文件。
• 交貨單。 一些系統對操作系統提供的數據使用“交貨單”（例如，記錄數量、不同鍵的數量、值的總和）。 這些可用於數據倉庫和操作系統之間的協調檢查（見下文）。

請記住，每項數據質量檢查都必須由至少一名數據用戶進行分析（請參閱“分析”一章），以防發現錯誤，為此您需要有人負責並隨時負責執行每項檢查。

在復雜的數據倉庫中，您最終可能會擁有許多（有時是數千個）DQ 規則。 執行數據質量規則的過程應該足夠健壯和足夠快來處理這個問題。

不要檢查技術實現所保證的事實。 例如，如果數據存儲在關係 DBMS 中，則無需檢查是否：

• 定義為強制的列包含 NULL 值。
• 主鍵字段值在表中是唯一的。
• 啟用了關係完整性檢查的表中沒有現有的外鍵。

也就是說，請始終記住，數據倉庫是不斷變化的，字段和表的數據定義可能會隨著時間而變化。

家政服務非常重要。 不同數據用戶單位定義的規則可能重疊，應合併。 您的組織越複雜，需要的內務管理就越多。 數據所有者應該將規則整合過程作為一種“數據質量規則的數據質量”來實施。 此外，如果不再使用數據或其定義已更改，則數據質量檢查可能會變得無用。

數據質量規則的類別

數據質量規則可以根據測試的類型進行分類。

• 數據質量檢查。 “正常”情況，檢查一個數據倉庫層中的數據（參見圖 1），無論是在一個表中還是在一組表中。
• 和解。 檢查數據是否在數據倉庫層之間正確傳輸的規則（參見圖 1）。 這些規則主要用於檢查“完整性”的 DQ 維度。 對賬可以使用單行或匯總方法。 檢查單行更加精細，但您必須在比較層之間重現轉換步驟（數據過濾、字段值更改、非規範化、連接等）。 您跳過的層數越多，必須實現的轉換邏輯就越複雜。 因此，最好在每個層與其前任層之間進行協調，而不是將暫存層與數據集市層進行比較。 如果必須在協調規則中實現轉換，請使用規範，而不是數據倉庫代碼！ 對於匯總調節，找到有意義的字段（例如，匯總、不同值的計數等）。
• 監測。 數據倉庫通常包含歷史數據，並加載了操作數據的增量提取。 數據倉庫和運營數據之間存在差距逐漸擴大的危險。 構建匯總的數據時間序列有助於識別此類問題（例如，將上個月的數據與當月的數據進行比較）。 對數據有很好了解的數據用戶可以為監控規則提供有用的度量和閾值。

如何量化數據質量問題

一旦您定義了要檢查的內容，您就必須指定如何量化已識別的問題。 諸如“五個數據行違反了 ID 為 15 的 DQ 規則”之類的信息對數據質量沒有多大意義。

缺少以下部分：

• 如何量化/計算檢測到的錯誤。 您可以計算“行數”，但也可以使用貨幣規模（例如，曝光）。 請記住，貨幣價值可能有不同的符號，因此您必須研究如何有意義地總結它們。 您可以考慮對數據質量規則同時使用量化單位（行數和匯總）。
• 人口。 數據質量規則檢查的單元數是多少？ “五分之五的數據行”與“五百萬分之五”的質量不同。 應該使用與誤差相同的量化來測量總體。 通常將數據質量規則的結果顯示為百分比。 總體不得與表中的行數相同。 如果 DQ 規則僅檢查數據的子集（例如，僅在合同表中終止合同），則應應用相同的過濾器來衡量總體。
• 結果的定義。 即使數據質量檢查發現問題，也不一定總是會導致錯誤。 對於數據質量，使用閾值對結果進行評級的交通燈系統（紅、黃、綠）非常有用。 例如綠色：0-2%，黃色：2-5%，紅色：5%以上。 請記住，如果數據用戶單元共享相同的規則，它們對於給定規則的閾值可能會大不相同。 營銷業務部門可能不介意丟失幾筆訂單，而會計部門甚至可能介意幾美分。 應該可以根據百分比或絕對數字定義閾值。
• 收集樣本錯誤行。 如果數據質量規則提供檢測到的錯誤的樣本，這會有所幫助——通常，（業務！）鍵和檢查的數據值足以幫助檢查錯誤。 限制數據質量規則的寫入錯誤行數是個好主意。
• 有時，您可能會在數據中發現無法修復但通過有用的數據質量檢查發現的“已知錯誤”。 對於這些情況，建議使用白名單（數據質量檢查應跳過的記錄鍵）。

其他元數據

元數據對於路由“分析”和監控數據質量控制循環的各個階段非常重要。

• 檢查項目。 它有助於將檢查的表和字段分配給數據質量規則。 如果您有一個增強的元數據系統，這可能有助於自動為該規則分配數據用戶和數據所有者。 出於監管原因（例如 BCBS 239），還需要證明 DQ 如何檢查數據。 但是，通過數據沿襲 (*) 將規則自動分配給數據用戶/數據所有者可能是一把雙刃劍（見下文）。
• 數據用戶。 每個 DQ 規則必須至少分配一個數據用戶/數據用戶單元，以在“分析”階段檢查結果，並確定發現是否以及如何影響他們對數據的工作。
• 數據所有者。 每個 DQ 規則都必須分配一個數據所有者。

(*) 數據沿襲顯示兩點之間的數據流。 通過數據沿襲，您可以找到影響倉庫內給定目標字段的所有數據元素。

使用數據沿襲將用戶分配給規則可能會有問題。 如前所述，業務用戶通常只知道數據集市層（和操作系統），而不知道數據倉庫的較低級別。 通過數據沿襲映射，數據用戶將被分配他們不熟悉的規則。 對於較低級別，可能需要 IT 人員來評估數據質量發現。 在許多情況下，手動映射或混合方法（僅在數據集市內通過數據沿襲進行映射）會有所幫助。

測量數據質量

衡量數據質量意味著執行可用的數據質量規則，這些規則應該由數據倉庫的加載過程觸發自動完成。 正如我們之前所見，可能存在大量數據質量規則，因此檢查將非常耗時。

在一個完美的世界中，只有當所有數據都沒有錯誤時才會加載數據倉庫。 在現實世界中，這種情況很少發生（實際上，幾乎從未如此）。 根據數據倉庫的整體加載策略，數據質量過程應該或不應該（後者更有可能）支配加載過程。 將數據質量流程（作業網絡）並行並鏈接到“常規”數據倉庫加載流程是一個很好的設計。

如果有定義的服務級別協議，請確保不要通過數據質量檢查來阻止數據倉庫負載。 數據質量過程中的錯誤/異常不應該停止常規加載過程。 數據質量過程中的意外錯誤應報告並顯示在“分析”階段（見下一章）。

請記住，數據質量規則可能會因為意外錯誤而崩潰（可能是規則本身被錯誤地實現，或者底層數據結構隨著時間的推移而改變）。 如果您的數據質量系統提供了一種機制來停用此類規則，這將有所幫助，尤其是在您的公司每年發布的版本很少的情況下。

DQ 流程應儘早執行並報告——理想情況下，應在加載檢查的數據後立即執行。 這有助於在數據倉庫加載期間儘早發現錯誤（一些複雜的倉庫系統加載持續數天）。

分析

在這種情況下，“分析”意味著對數據質量發現做出反應。 這是分配給數據用戶和數據所有者的任務。

您的數據質量項目應明確定義反應方式。 數據用戶應該有義務對帶有發現的規則（至少是帶有紅燈的規則）發表評論，解釋正在採取哪些措施來處理髮現。 需要通知數據擁有人，並應與數據使用者一起決定。

可以執行以下操作：

• 嚴重問題：必須解決問題並重複數據加載。
• 問題是可以接受的：嘗試為將來的數據加載修復它並在數據倉庫或報告中處理問題。
• 有缺陷的 DQ 規則：修復有問題的 DQ 規則。

在一個完美的世界裡，每一個數據質量問題都會得到解決。 然而，缺乏資源和/或時間通常會導致變通方法。

為了能夠及時做出反應，DQ 系統必須將發現的“他們的”規則告知數據用戶。 使用數據質量儀表板（可能會發送出現問題的消息）是一個好主意。 用戶越早了解調查結果越好。

數據質量儀表板應包含：

• 分配給給定角色的所有規則
• 規則的結果（交通燈、度量和示例行）能夠按結果和數據域過濾規則
• 數據用戶必須為調查結果輸入的強制性評論
• 可選擇“否決”結果的功能（例如，如果數據質量規則報告由於有缺陷的實現而導致的錯誤）。 如果多個業務單位分配了相同的數據質量規則，則“否決”僅對數據用戶的業務單位有效（而非整個公司）。
• 顯示未執行或異常的規則

儀表板還應顯示最近數據倉庫加載過程的當前狀態，為用戶提供數據倉庫加載過程的 360 度視圖。

數據所有者有責任確保每個發現都得到評論，並且所有數據用戶的數據質量狀態（原始或否決）至少為黃色。

為了快速概覽，這將有助於為數據用戶/數據所有者構建一種簡單的 KPI（關鍵績效指標）。 如果每個規則都被賦予相同的權重，那麼為所有相關規則的結果創建一個整體交通燈是非常容易的。

就個人而言，我認為計算給定數據域的數據質量的總體值相當複雜，而且往往是陰謀論，但是您至少可以顯示按數據域的結果分組的總體規則的數量（例如，“100 條 DQ 規則90% 的綠色、5% 的黃色和 5% 的紅色結果”）。

數據所有者的任務是確保調查結果得到修復並提高數據質量。

改進流程

由於數據倉庫流程經常變化，數據質量機制也需要維護。

數據所有者應始終注意以下幾點：

• 保持最新。 數據倉庫中的變化需要被數據質量系統捕捉到。
• 提高。 針對數據質量規則尚未涵蓋的錯誤實施新規則。
• 精簡。 禁用不再需要的數據質量規則。 合併重疊的規則。

監控數據質量流程

監控整個數據質量過程有助於隨著時間的推移對其進行改進。

值得關注的是：

• 數據質量規則對數據的覆蓋範圍
• 隨著時間的推移，活動規則中數據質量發現的百分比
• 活動數據質量規則的數量（密切關注——我已經看到數據用戶通過簡單地禁用越來越多的數據質量規則來解決他們的發現。）
• 數據加載中對所有發現進行評級和修復所需的時間

結論

以下許多要點在任何類型的項目中都很重要。

預計阻力。 正如我們所看到的，如果沒有緊急的質量問題，數據質量通常被視為額外的負擔，而不提供新的功能。 請記住，它可能會給數據用戶帶來額外的工作量。 在許多情況下，合規性和監管要求可以幫助您說服用戶將其視為不可避免的要求。

尋找贊助商。 如上所述，DQ 不是一個快速銷售的項目，因此需要一個強大的讚助商/利益相關者——管理層越高越好。

尋找盟友。 與讚助商一樣，任何分享強大數據質量理念的人都會很有幫助。 DQ 電路循環是一個持續的過程，需要人們保持電路循環的活力。

從小處著手。 如果到目前為止還沒有 DQ 策略，請尋找需要更好數據質量的業務部門。 建立一個原型，向他們展示更好的數據的好處。 如果您的任務是改進甚至替換給定的數據質量策略，請查看組織中運行良好/被接受的事物，並保留它們。

不要忽視整個畫面。 儘管從小處著手，但請記住，某些要點，尤其是角色，是成功 DQ 戰略的先決條件。

一旦實施，就不要鬆手。 數據質量過程需要成為數據倉庫使用的一部分。 隨著時間的推移，對數據質量的關注往往會變得有點迷失，這取決於您來維護它。