建立資料品質規則

資料品質衡量組織中資料的完整性。 你透過使用資料品質分數來評估資料品質。 Microsoft Purview 整合式目錄會根據您定義的規則評估資料產生分數。

資料品質規則是組織制定的重要指引，以確保資料的準確性、一致性與完整性。 這些規則有助於維持資料的完整性與可靠性。

以下是資料品質規則的一些關鍵面向：

• 準確性：資料應準確反映現實世界的實體。 情境很重要！ 例如，如果你儲存的是客戶地址，請確保地址與實際地點相符。

• 完整性：此規則用以識別空資料、空資料或遺失資料。 它證明所有價值觀都存在，雖然不一定正確。

• 符合性：此規則確保資料遵循資料格式標準，如日期、地址及允許值的表示。

• 一致性：此規則檢查同一記錄的不同值是否符合特定規則，且無矛盾。 資料一致性確保相同資訊在不同紀錄間能均勻呈現。 例如，如果您有產品目錄，統一的產品名稱與描述至關重要。

• 時效性：此規則旨在確保資料能在最短時間內被存取。 它確保資料是最新的。

• 唯一性：此規則檢查值是否重複。 舉例來說，如果每個客戶應該只有一個紀錄，那麼同一客戶就不會有多個紀錄。 每個客戶、產品或交易都應該擁有獨特的識別碼。

資料品質生命週期

建立資料品質規則是資料品質生命週期的 第六 步。 前述步驟如下：

1. 在整合式目錄中指派使用者資料品質管理員權限，以使用所有資料品質功能。
2. 在 Microsoft Purview 資料對應中註冊並掃描資料來源。
3. 將你的資料資產加入資料產品。
4. 建立資料來源連線，為資料品質評估做準備。
5. 在你的資料來源中設定並執行資產的資料剖析。

所需角色

• 要建立和管理資料品質規則，使用者需要資料 品質管理員的角色。
• 要查看現有品質規則，使用者需要資料 品質閱讀者角色。

查看現有的資料品質規則

1. 在整合式目錄中，選擇健康管理，再選擇資料品質。

2. 選擇 治理領域，再選擇資料產品。

3. 從 資料資產 清單中選擇一個資料資產。

4. 選擇 「規則 」標籤，查看套用在資產上的現有規則。

5. 選擇規則以瀏覽該規則套用到所選資料資產的效能歷史。

   

可用的資料品質規則

Microsoft Purview 資料品質可設定以下規則。 這些規則開箱即用，提供低程式碼到無程式碼的方式來衡量資料品質。

新鮮度

新鮮度規則檢查資產是否在預期時間內更新。 新鮮度由最後 修改日期的選擇決定。

唯一的值

唯一值規則規定，指定欄位中的所有值必須是唯一的。 所有唯一的數值都視為通過，而不唯一的數值則視為失敗。 如果欄位中沒有定義空 欄位 規則，則在此規則中忽略空值或空值。

弦樂格式比賽

格式匹配規則檢查欄位中所有值是否有效。 如果你沒有在欄位上定義空 欄位 規則，該規則會忽略空值或空值。

此規則可透過三種不同方法驗證欄位中的每個值：

1. 列舉法：此方法使用逗號分隔的數值列表。 如果你評估的值與列出的值不符，該檢查就會失敗。 你可以用反斜線 (\) 來避開逗號和反斜線。 因此，包含 a \, b, c 兩個值：第一個值為 a , b ，第二個為 c。

1. 像圖案： like(<i>&lt;string&gt;</i> : string, <i>&lt;pattern match&gt;</i> : string) => boolean 圖案是一條規則字面上匹配的串。 例外是以下特殊符號：_ 與輸入 (中的任一個字元匹配，類似.於posix正規表達式) % 匹配輸入 (中零個或多個字元，類似.posix於正則表達式) 。 轉義字元為 . ：如果一個跳脫字元在特殊符號或另一個跳脫字元之前，則後面的字元會字面上匹配。 逃離其他角色是無效的。

   • like('icecream', 'ice%') -> true

   

2. 正則表達式： regexMatch(<i>&lt;string&gt;</i> : string, <i>&lt;regex to match&gt;</i> : string) => boolean

   檢查字串是否符合給定的正則表達式模式。 使用 <regex> (反引號) 來匹配字串而不逃脫。

   • regexMatch('200.50', '(\\d+).(\\d+)') -> true
   • regexMatch('200.50', `(\d+).(\d+)`) -> true

   

資料型別匹配

資料型別匹配規則指定了相關欄位的預期資料型態。 由於規則引擎跨越多個不同資料來源，無法使用原生類型如 BIGINT 或 VARCHAR。 相反地，它使用自己的型別系統，並將原生型態轉換到這個系統中。 此規則告訴品質掃描引擎應使用內建類型中的哪一種來執行原生類型。 資料型別系統來自 Microsoft 的 Azure Data Flow 類型系統，用於 Azure Data Factory。

在品質掃描過程中，引擎會將所有原生類型與資料類型匹配的類型進行測試。 如果無法將原生型別轉換成資料型別匹配型別，它會將該列視為錯誤。

重複列

重複列規則檢查欄位中值的組合是否對表格中每一列都是唯一的。

以下範例中，預期公司 名稱、 CustomerID、 EmailAddress、 FirstName 和 LastName 的串接會產生一個對表格中所有列唯一的值。

每個資產可以有零或一個這條規則的實例。

空欄位/空白欄位

空 欄位 規則斷言所識別欄位不應包含任何空值。 對於字串，規則也禁止空值或僅留白的值。 在資料品質掃描過程中，引擎會將該欄位中非空值的值視為正確。 此規則影響其他規則，如 獨特值 或 格式配對 規則。 如果你沒有在某欄定義這條規則，這些規則在執行該欄時會自動忽略任何空值。 如果你在欄位上定義此規則，這些規則會檢查該欄位的空值，並考慮它們作為分數目的。

表格查找

表格查找規則會檢查你定義該規則欄位中的每個值，並將其與參考表比較。 例如，主表有一個稱為「location」的欄位，包含城市、州和郵遞區號，格式為「city， state zip」。 一個名為「城邦」的參考表，包含美國支持的所有城市、州和郵遞區號的法律組合。 目標是將當前欄位中的所有位置與該參考清單進行比較，以確保只使用合法組合。

要設定此規則，請在搜尋資產對話框中輸入「citystatezip」名稱。 然後選擇想要的資產和你想比較的欄位。

自訂規則

自訂規則允許你指定規則，根據該列中的一個或多個值來驗證該列。 你可以使用正規表達式語言、Azure Data Factory 表達式和 SQL 表達式來建立自訂規則。

自訂規則包含三個部分：

1. 列表達式：此布林運算式適用於過濾式核准的每一列。 若此表達式回傳為真，該列即通過。 若回傳為假，該列即失敗。

2. 篩選式：此可選條件縮小列條件評估資料集範圍。 你可以選擇 「使用篩選表達式 」的勾選框來啟用它。 此表達式回傳一個布林值。 濾鏡運算式套用在一列，如果回傳為真，則該列會被納入規則。 如果該列的濾波表達式回傳 false，表示該列在此規則中被忽略。 濾鏡運算式的預設行為是傳遞所有列，所以如果你沒有指定濾鏡表達式，所有列都會被考慮。

3. Null 表達式：檢查 NULL 值應如何處理。 此表達式回傳一個布林值，用於處理資料缺失的情況。 若表達式回傳為真，則未套用列表達式。

規則的每個部分運作方式與現有的 Microsoft Purview 資料品質條件相似。 只有當列運算式對與篩選式相符的資料集評估為 TRUE，且能處理空運算式中指定的遺失值時，規則才會通過。

範例：一條規則確保「車資金額」為正數且「行程距離」有效：

• 列式：trip 距離 > 0 與 fareAmount > 0
• 篩選表達式：paymentType = 'CRD'
• Null 表達式：tripDistance 是 NULL

建立自訂規則

1. 在整合式目錄中，請前往健康管理>資料品質。
2. 選擇治理領域，選擇資料產品，再選擇資料資產。
3. 在 規則 標籤中，選擇 新規則。

使用 Azure Data Factory (ADF) 表達式建立自訂規則

1. 若要使用正則表達式或 ADF 表達式建立規則，請從規則選項列表中選擇 「自訂 」，然後選擇 「下一步」。

2. 新增 規則名稱 和 描述，然後選擇 建立。

   

自訂規則範例

過濾表達式與列表達式皆使用 Azure Data Factory 表達式語言定義，語言定義如下。 然而，並非所有為通用 ADF 表達式語言定義的函式皆可用。 完整的可用功能清單可在表達式對話框中的函數清單中。 以下在此定義的函式不被支援：isDelete、isError、isIgnore、isInsert、isMatch、isUpdate、isUpsert、partitionId、快取查找，以及 Window 函式。

使用 SQL 表達式建立自訂規則

Microsoft Purview 資料品質中的自訂 SQL 規則，提供一種靈活的方式來定義使用 Spark SQL 條件來進行資料品質檢查。 此功能允許使用者直接在 Spark SQL 中撰寫規則，用於進階驗證情境。 只需一個列式;篩選與空運算式則可選，方便進一步自訂。 使用自訂 SQL 規則來解決複雜的業務需求並提升資料品質，充分利用 Spark SQL 的全部功能。 自訂 SQL 規則使得複雜的資料驗證成為可能僅靠 ADF 表達式無法實現的。 透過撰寫 Spark SQL 謂詞，您可以滿足獨特的業務需求並維持高資料品質標準。

1. 要使用 SQL 表達式語言建立規則，請從規則選項列表中選擇 「自訂 (SQL) 」，然後選擇 「下一步」。

2. 新增 規則名稱 和 描述，然後選擇 建立。

   案例	表達式
   驗證正確的字串模式， (例如以 '1' 開頭的 rateCodeId、數字) ，並依有效支付類型進行篩選。	Row: rateCodeId RLIKE '^1[0-9]+$' Filter: paymentType IN ('CRD', 'CSH') Null: rateCodeId IS NULL
   確保 puLocationId 與 doLocationID 之間的欄位正確比較，以及票價與行程距離的比較。	Row: puLocationId > doLocationId AND fareAmount > tripDistance * 10' Filter: paymentType <> 'CSH'' Null: tripDistance IS NULL
   檢查支付類型是否在指定清單中 (卡、現金) ，並根據票價金額篩選各行。	Row: paymentType IN ('CRD', 'CSH')' Filter: fareAmount >= 50 Null: paymentType IS NULL
   確保距離在包含 5-10 英里 () 範圍內，處理 NULL 並篩選有效付款方式。	Row: tripDistance BETWEEN 5 AND 10 Filter: paymentType <> 'CRD' Null: tripDistance IS NULL
   確保資料集的 fareAmount 不會超過 20% 的 NULL 值。	Row: (SELECT avg(CASE WHEN fareAmount IS NULL THEN 1 ELSE 0 END) FROM nycyellowtaxidelta1BillionPartitioned) < 0.20' Filter: vendorID IN ('VTS', 'CMT')
   驗證資料集中至少有兩個不同的 paymentType 值。	Row: (SELECT count(DISTINCT paymentType) FROM nycyellowtaxidelta1BillionPartitioned) >= 2 Filter: vendorID IN ('1', '2')
   確保資料集的平均票價金額落在指定範圍內 (80 <= 平均 <= 140) 。	Row: (SELECT avg(fareAmount) FROM nycyellowtaxidelta1BillionPartitioned) BETWEEN 80 AND 140 ' Filter: paymentType IN ('CRD', 'CSH')
   確保資料集中的最大 tripDistance = <10 英里。	Row: (SELECT max(tripDistance) FROM nycyellowtaxidelta1BillionPartitioned) <= 10.0 Filter: vendorID IN ('VTS', 'CMT')
   確保車資標準差低於某個門檻 (< 30) 。	Row: (SELECT stddev_samp(fareAmount) FROM nycyellowtaxidelta1BillionPartitioned) < 30.0 Filter: vendorID IN ('VTS', 'CMT')
   確保資料集的中位票價金額在指定門檻內 (<= 15) 。	Row: (SELECT percentile_approx(fareAmount, 0.5) FROM nycyellowtaxidelta1BillionPartitioned) <= 15.0 Filter: vendorID IN ('VTS', 'CMT')
   確保 vendorID 在特定支付類型內的資料集中是唯一的。	Row: COUNT(1) OVER (PARTITION BY vendorID) = 1 Filter: paymentType IN ('CRD', 'CSH','1', '2') Null: vendorID IS NULL
   確保 puLocationID 與 doLocationID 的組合在資料集中是唯一的。	Row: COUNT(1) OVER (PARTITION BY puLocationId, doLocationId) = 1 Filter: paymentType IN ('CRD', 'CSH') Null: puLocationId IS NULL OR doLocationId IS NULL
   確保每個支付類型 vendorID 都是唯一的。	Row: COUNT(1) OVER (PARTITION BY paymentType, vendorID) = 1 ,Filter: rateCodeId < 25, Null: vendorID IS NULL
   確保該列的 tpepPickupDateTime 大於給定的截止時間戳。	Row: tpepPickupDateTime >= TIMESTAMP '2014-01-03 00:00:00' Filter: paymentType IN ('CRD', 'CSG', '1', '2') Null: tpepPickupDateTime IS NULL
   每次行程必須在1小時內完成	Row: (unix_timestamp(tpepDropoffDateTime) - unix_timestamp(tpepPickupDateTime)) <= 3600 Filter: paymentType IN ('CRD', 'CSH', '1', '2') Null: tpepPickupDateTime IS NULL OR tpepDropoffDateTime IS NULL
   每個接送點只保留最高票價的行程。	Row: row_number() OVER (PARTITION BY puLocationId ORDER BY fareAmount DESC) = 1, Filter: paymentType IN ('CRD', 'CSH','1','2') AND tripDistance > 0, Null: fareAmount IS NULL OR puLocationId IS NULL
   所有並列的最高票價 (不只是先row_number) 。	Row: rank() OVER (PARTITION BY puLocationId ORDER BY fareAmount DESC) = 1 Filter: paymentType IN ('CRD', 'CSH','1','2') AND tripDistance > 0 Null: fareAmount IS NULL OR puLocationId IS NULL
   每種付款方式的票價不得隨時間下降。	Row: fareAmount >= lag(fareAmount) OVER (PARTITION BY paymentType ORDER BY tpepPickupDateTime) Null: tpepPickupDateTime IS NULL OR fareAmount IS NULL
   每排票價在團體平均分數的10分鐘內，依付款方式劃分。	Row: abs(fareAmount - avg(fareAmount) OVER (PARTITION BY paymentType)) <= 10 Filter: paymentType IN ('CRD', 'CSH','1','2') Null: fareAmount IS NULL
   跑步總距離不得超過20英里。	Row: sum(tripDistance) OVER (ORDER BY tpepPickupDateTime ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) <= 20 Filter: paymentType = '1' Null: tripDistance IS NULL
   檢查每次行程的票價是否高於符合資格供應商的全球平均值。	Row: fareAmount > (SELECT avg(fareAmount) FROM nycyellowtaxidelta1BillionPartitioned) Filter: vendorID IN ('VTS', 'CMT') Null: fareAmount IS NULL
   檢查每排的行程距離是否超過付款的最低標準。類型 (卡/現金) 。	Row: tripDistance > (SELECT min(u.tripDistance) FROM (SELECT tripDistance, paymentType AS pt FROM nycyellowtaxidelta1BillionPartitioned) u WHERE u.pt = paymentType) Filter: paymentType IN ('CRD', 'CSH') Null: tripDistance IS NULL
   每次行程都會檢查票價是否高於該支付類型的平均值	Row: fareAmount > (SELECT avg(u.fareAmount) FROM (SELECT fareAmount, paymentType AS pt FROM nycyellowtaxidelta1BillionPartitioned) u WHERE u.pt = paymentType) Filter: paymentType IN ('CRD','CSH','1','2') AND vendorID IN ('VTS','CMT') Null: fareAmount IS NULL
   驗證 fareAmount 欄位 (數值) 是否能正確表示為符合正 (數數字模式的字串，並可選小數) 。 此法使用鑄造作為票價金額為數字欄位。	Row: CAST(fareAmount AS STRING) RLIKE '^[0-9]+(\.[0-9]+)?$' Filter: paymentType IN ('CRD', 'CSH') Null: fareAmount IS NULL
   確保 tpepPickupDateTime 是有效的時間戳記，格式為 yyyy-MM-dd HH：mm：ss。 本專欄已採用 DATETIME 格式	Row: to_timestamp(tpepPickupDateTime, 'yyyy-MM-dd HH:mm:ss') IS NOT NULL Filter: paymentType IN ('CRD', 'CSH') Null: tpepPickupDateTime IS NULL
   確保 paymentType 值被正規化為小寫，且沒有前置或後置空格。	Row: lower(trim(paymentType)) IN ('card','cash') AND length(trim(paymentType)) > 0 Null: paymentType IS NULL OR trim(paymentType) = ''
   安全計算 fareAmount 與 tripDistance 的比率，確保不會因 tripDistance > 為 0 而除以零。	Row: CASE WHEN tripDistance > 0 THEN fareAmount / tripDistance ELSE NULL END >= 10 Filter: tripDistance > 0 AND vendorID IN ('VTS', 'CMT')
   示範 Coalesce 如何以預設值替換空值，例如 (0.0) ，並確保只回傳有效列。	Row: coalesce(fareAmount, 0.0) >= 5 Filter: paymentType IN ('CRD','CSH')

撰寫自訂 SQL 規則的最佳實務

• 保持表情簡單。 目標是寫出清晰、直白且易於維護的表達方式。
• 使用內建的 Spark SQL 函式。 使用 Spark SQL 豐富的函式庫，用於字串操作、日期處理及數值運算，以減少錯誤並提升效能。
• 先用一個小資料集測試。 在大規模應用前，先在小型資料集上驗證規則，以及早識別潛在問題。

SQL 表達式規則的已知限制與考量

模糊的欄位參考與欄位陰影

• 問題：當欄位同時出現在外部查詢與子查詢 (，或跨越查詢) 的不同部分且名稱相同時，Spark SQL 可能無法解析該使用哪一欄。 此問題會導致邏輯錯誤或查詢執行不正確。 此問題可能出現在巢狀查詢、子查詢或連接中，導致模糊性或影子現象。

• 歧義：當欄位名稱同時出現在外部查詢和子查詢中且沒有明確限定，導致 Spark SQL 不確定該參考哪一欄時。

• 遮蔽：指的是外部查詢中的某欄位被子查詢中同一欄位「覆蓋」或「遮蔽」，導致外部參考被忽略。

  範例表達式：

  distance_km > 
  ( 
  SELECT min(distance_km) 
  FROM Tripdata t  
  WHERE t.payment_type = payment_type -- ambiguous outer reference  
  )
  

• 問題：未限定payment_type解析為最近具有該名稱欄位的範圍，也就是內層t.payment_type，而非外列的payment_type。 這會將謂詞變成 t.payment_type = t.payment_type (永遠 TRUE) ，因此你的子查詢變成全域最小值，而非群組最小值。

• 解決方案：為解決此模糊性並避免欄位陰影，請重新命名子查詢中的內欄，確保外部查詢的payment_type保持無歧義。

修正表達：

  distance_km > 
  ( 
  SELECT min(u.distance_km) 
  FROM ( 
  SELECT distance_km, payment_type AS pt 
  FROM Tripdata 
  ) u 
   WHERE u.pt = payment_type   -- this `payment_type` now binds to OUTER row 
  )

• 在子查詢中，欄位 payment_type 被別名為 pt (，也就是payment_type AS pt) ，條件中使用 you.pt。
• 在外部查詢中，原始payment_type現在可以被清楚引用，Spark SQL 也能正確解析為外部payment_type。

視窗操作 (效能考量)

• 像 ROW_NUMBER () 和 RANK () 這類視窗操作可能成本較高，尤其是對大型資料集而言。 謹慎使用這些資料，並在大規模應用前先在較小的資料集上測試效能。 考慮使用 PARTITION BY 來縮小資料範圍。

Spark SQL 中的欄位名稱逃逸

• 若欄位名稱包含特殊字元 (，如空格、連字號或其他非字母數字字元) ，則必須使用回溯條符號逃逸。
• 例如欄位名稱為 order-id，且規則必須大於 10。
• 錯誤表達式：order-id > 10
• 正確表達： `order-id`> 10

資料資產名稱在表達式中的引用

在 SQL 表達式中引用資料資產時，你需要遵守特定的淨化規則。 原始資料資產名稱不需要更新，但 SQL 表達式中引用的資料資產名稱必須經過淨化，以符合以下條件：

如果你的資料資產名稱已經符合這些指引，也就是說， (它不包含特殊字元、前導/後尾底線，且在 64 個字元的限制內) ，就可以直接直接用在你的 SQL 表達式中，無需修改。

如何淨化資料集名稱

請依照以下步驟確認你的資料集名稱對 SQL 表達式有效：

1. 移除特殊字元：去除所有字元，僅保留字母、數字和底線。
2. 修剪底線：移除所有前置或後方的底線。
3. 截斷：若名稱超過 64 個字元，則截斷以符合 64 個字元的限制。

範例：資料資產名稱 f07d724d-82c9-4c75-97c4-c5baf2cd12a4.parquet

1. 移除特殊字元：f07d724d82c94c7597c4c5baf2cd12a4parquet
2. 修剪底線： (不適用，因為沒有前線或後方底線 )
3. 截斷：最終名稱長度為 54 個字元，低於 64 個字元的限制。

Final SQL 參考名稱：f07d724d82c94c7597c4c5baf2cd12a4parquet

不支援加入

Microsoft Purview 資料品質中的自訂 SQL 規則不支援連接。 規則必須針對單一資料集運作。 寫自訂規則時不能同時合併多個資料表或資料集。

不支援的 SQL 操作 (DML、DCL 及有害的 SQL)

自訂 SQL 規則不支援資料操作語言 (DML) 或資料控制語言 (DCL) 操作，如 INSERT、UPDATE、DELETE、GRANT，以及其他有害的 SQL 操作，如 TRUNCATE、DROP 和 ALTER。 這些操作不被支援，因為它們會修改資料或資料庫狀態。

AI 輔助自動生成規則

AI 輔助的自動規則生成用於資料品質衡量，利用人工智慧 (AI) 技術自動建立評估與提升資料品質的規則。 自動生成的規則是針對內容的。 大多數常見規則都是自動產生的，所以你不需要花太多心力去建立自訂規則。

瀏覽並套用自動生成規則：

1. 在資料資產的 規則 標籤中，選擇 建議規則。

2. 瀏覽建議規則清單。

   

3. 從建議規則清單中選擇規則，以套用到資料資產。

   

後續步驟

1. 設定並執行資料品質掃描 ，以評估資料產品中所有支援資產的品質。
2. 檢視您的掃描結果 ，以評估您資料產品的目前資料品質。