Erstellen von Data Quality-Regeln

Die Datenqualität misst die Integrität von Daten in einem organization. Sie bewerten die Datenqualität mithilfe von Datenqualitätsbewertungen. Microsoft Purview Unified Catalog generiert Bewertungen basierend auf der Bewertung der Daten anhand der von Ihnen definierten Regeln.

Datenqualitätsregeln sind wichtige Richtlinien, die Organisationen festlegen, um die Genauigkeit, Konsistenz und Vollständigkeit ihrer Daten sicherzustellen. Diese Regeln tragen zur Aufrechterhaltung der Datenintegrität und -zuverlässigkeit bei.

Im Folgenden finden Sie einige wichtige Aspekte von Data Quality-Regeln:

• Genauigkeit: Daten sollten reale Entitäten genau darstellen. Kontext ist wichtig! Wenn Sie beispielsweise Kundenadressen speichern, stellen Sie sicher, dass diese mit den tatsächlichen Standorten übereinstimmen.

• Vollständigkeit: Diese Regel identifiziert leere, NULL- oder fehlende Daten. Es wird überprüft, ob alle Werte vorhanden sind, wenn auch nicht unbedingt korrekt.

• Konformität: Diese Regel stellt sicher, dass die Daten Standards für die Datenformatierung einhalten, z. B. die Darstellung von Datumsangaben, Adressen und zulässigen Werten.

• Konsistenz: Diese Regel überprüft, ob unterschiedliche Werte desselben Datensatzes einer bestimmten Regel entsprechen und dass keine Widersprüche vorliegen. Die Datenkonsistenz stellt sicher, dass die gleichen Informationen in verschiedenen Datensätzen einheitlich dargestellt werden. Wenn Sie über einen Produktkatalog verfügen, sind für instance konsistente Produktnamen und -beschreibungen von entscheidender Bedeutung.

• Aktualität: Mit dieser Regel soll sichergestellt werden, dass die Daten in so kurzer Zeit wie möglich zugänglich sind. Dadurch wird sichergestellt, dass die Daten auf dem neuesten Stand sind.

• Eindeutigkeit: Diese Regel überprüft, ob Werte nicht dupliziert werden. Wenn beispielsweise nur ein Datensatz pro Kunde vorhanden sein soll, gibt es nicht mehrere Datensätze für denselben Kunden. Jeder Kunde, jedes Produkt oder jede Transaktion sollte über einen eindeutigen Bezeichner verfügen.

Lebenszyklus der Datenqualität

Das Erstellen von Data Quality-Regeln ist der sechste Schritt im Data Quality-Lebenszyklus. Die vorherigen Schritte sind:

1. Weisen Sie Benutzern Data Quality Steward-Berechtigungen in Unified Catalog zu, um alle Data Quality-Features zu verwenden.
2. Registrieren und überprüfen Sie eine Datenquelle in Microsoft Purview Data Map.
3. Fügen Sie Ihre Datenressource einem Datenprodukt hinzu.
4. Richten Sie eine Datenquellenverbindung ein, um Ihre Quelle für die Bewertung der Datenqualität vorzubereiten.
5. Konfigurieren und Ausführen der Datenprofilerstellung für ein Medienobjekt in Ihrer Datenquelle.

Erforderliche Rollen

• Zum Erstellen und Verwalten von Datenqualitätsregeln benötigen Benutzer die Rolle Data Quality Steward.
• Um vorhandene Qualitätsregeln anzuzeigen, benötigen Benutzer die Rolle "Data Quality Reader".

Anzeigen vorhandener Datenqualitätsregeln

1. Wählen Sie Unified Catalog die Option Integritätsverwaltung und dann Datenqualität aus.

2. Wählen Sie eine Governancedomäne und dann ein Datenprodukt aus.

3. Wählen Sie eine Datenressource aus der Liste Datenressourcen aus.

4. Wählen Sie die Registerkarte Regeln aus, um die vorhandenen Regeln anzuzeigen, die auf das Medienobjekt angewendet werden.

5. Wählen Sie eine Regel aus, um den Leistungsverlauf der angewendeten Regel auf die ausgewählte Datenressource zu durchsuchen.

   

Verfügbare Data Quality-Regeln

Microsoft Purview Data Quality ermöglicht die Konfiguration der folgenden Regeln. Diese Regeln sind sofort verfügbar und bieten eine Möglichkeit, die Qualität Ihrer Daten zu messen.

Aktualität

Die Aktualitätsregel überprüft, ob das Medienobjekt innerhalb der erwarteten Zeit aktualisiert wird. Die Aktualität wird durch die Auswahl der Datumsangaben der letzten Änderung bestimmt.

Eindeutige Werte

Die Regel Eindeutige Werte gibt an, dass alle Werte in der angegebenen Spalte eindeutig sein müssen. Alle eindeutigen Werte werden als pass behandelt, und Werte, die nicht eindeutig sind, werden als fehler behandelt. Wenn die Regel Leere/leere Felder nicht für die Spalte definiert ist, werden null- oder leere Werte für die Zwecke dieser Regel ignoriert.

Übereinstimmung des Zeichenfolgenformats

Die Übereinstimmungsregel Format überprüft, ob alle Werte in der Spalte gültig sind. Wenn Sie die Regel Leere/leere Felder für eine Spalte nicht definieren, ignoriert die Regel NULL- oder leere Werte.

Diese Regel kann jeden Wert in der Spalte mit drei verschiedenen Ansätzen überprüfen:

1. Enumeration: Bei diesem Ansatz wird eine durch Trennzeichen getrennte Liste von Werten verwendet. Wenn der ausgewertete Wert nicht mit einem der aufgeführten Werte übereinstimmt, tritt bei der Überprüfung ein Fehler auf. Sie können Kommas und umgekehrte Schrägstriche mit escapen, indem Sie einen umgekehrten Schrägstrich (\) verwenden. a \, b, c Enthält also zwei Werte: der erste ist a , b und der zweite ist c.

1. Wie Muster: like(<i>&lt;string&gt;</i> : string, <i>&lt;pattern match&gt;</i> : string) => boolean Das Muster ist eine Zeichenfolge, mit der die Regel wörtlich übereinstimmt. Ausnahmen sind die folgenden Sondersymbole: _ entspricht einem beliebigen Zeichen in der Eingabe (ähnlich wie . in posix regulären Ausdrücken) % entspricht null oder mehr Zeichen in der Eingabe (ähnlich wie . in posix regulären Ausdrücken). Das Escapezeichen lautet . Wenn ein Escapezeichen vor einem Sondersymbol oder einem anderen Escapezeichen steht, wird das folgende Zeichen wörtlich abgeglichen. Es ist ungültig, ein anderes Zeichen mit Escapezeichen zu versehen.

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

   

2. Regulärer Ausdruck: regexMatch(<i>&lt;string&gt;</i> : string, <i>&lt;regex to match&gt;</i> : string) => boolean

   Überprüft, ob die Zeichenfolge mit dem angegebenen RegEx-Muster übereinstimmt. Verwenden Sie <regex>(Zurück-Anführungszeichen), um eine Zeichenfolge ohne Escapezeichen abzugleichen.

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

   

Übereinstimmung des Datentyps

Die Datentyp-Übereinstimmungsregel gibt den erwarteten Datentyp für die zugeordnete Spalte an. Da die Regel-Engine in vielen verschiedenen Datenquellen ausgeführt wird, kann sie keine nativen Typen wie BIGINT oder VARCHAR verwenden. Stattdessen verwendet es ein eigenes Typsystem und übersetzt native Typen in dieses System. Diese Regel teilt der Qualitätsscan-Engine mit, welche der integrierten Typen für den nativen Typ verwendet werden soll. Das Datentypsystem stammt aus dem microsoft Azure Datenfluss Typsystem, das in Azure Data Factory verwendet wird.

Während einer Qualitätsüberprüfung testet die Engine alle nativen Typen anhand des Datentyp-Übereinstimmungstyps. Wenn der native Typ nicht in den Datentypübereinstimmungstyp übersetzt werden kann, wird diese Zeile als Fehler behandelt.

Doppelte Zeilen

Die Regel Doppelte Zeilen überprüft, ob die Kombination der Werte in der Spalte für jede Zeile in der Tabelle eindeutig ist.

Im folgenden Beispiel wird erwartet, dass die Verkettung von CompanyName, CustomerID, EmailAddress, FirstName und LastName einen Wert erzeugt, der für alle Zeilen in der Tabelle eindeutig ist.

Jede Ressource kann null oder eine instance dieser Regel aufweisen.

Leere/leere Felder

Die Regel Leere/leere Felder bestätigt, dass die identifizierten Spalten keine NULL-Werte enthalten dürfen. Für Zeichenfolgen lässt die Regel auch leere Werte oder Nur-Leerzeichenwerte zu. Während einer Datenqualitätsüberprüfung behandelt die Engine jeden Wert in dieser Spalte, der nicht NULL ist, als richtig. Diese Regel wirkt sich auf andere Regeln aus, z. B . eindeutige Werte oder Format-Übereinstimmungsregeln . Wenn Sie diese Regel nicht für eine Spalte definieren, ignorieren diese Regeln automatisch alle NULL-Werte, wenn sie für diese Spalte ausgeführt werden. Wenn Sie diese Regel für eine Spalte definieren, untersuchen diese Regeln NULL- oder leere Werte für diese Spalte und berücksichtigen sie zu Bewertungszwecken.

Tabellensuche

Die Tabellen-Nachschlageregel untersucht jeden Wert in der Spalte, in der Sie die Regel definieren, und vergleicht ihn mit einer Verweistabelle. Beispielsweise enthält eine primäre Tabelle eine Spalte namens "location", die Städte, Bundesstaaten und Postleitzahlen im Format "city, state zip" enthält. Eine Referenztabelle namens "citystate" enthält alle rechtlichen Kombinationen von Städten, Bundesstaaten und Postleitzahlen, die im USA unterstützt werden. Das Ziel besteht darin, alle Speicherorte in der aktuellen Spalte mit dieser Verweisliste zu vergleichen, um sicherzustellen, dass nur rechtliche Kombinationen verwendet werden.

Um diese Regel einzurichten, geben Sie den Namen "citystatezip" in das Dialogfeld "Ressourcen suchen" ein. Wählen Sie dann die gewünschte Ressource und die Spalte aus, mit der Sie vergleichen möchten.

Benutzerdefinierte Regeln

Mit der benutzerdefinierten Regel können Sie Regeln angeben, die Zeilen basierend auf einem oder mehreren Werten in dieser Zeile überprüfen. Sie können reguläre Ausdrücke, Azure Data Factory Ausdruck und SQL-Ausdruckssprache verwenden, um benutzerdefinierte Regeln zu erstellen.

Eine benutzerdefinierte Regel umfasst drei Teile:

1. Zeilenausdruck: Dieser boolesche Ausdruck gilt für jede Zeile, die vom Filterausdruck genehmigt wird. Wenn dieser Ausdruck true zurückgibt, wird die Zeile übergeben. Wenn false zurückgegeben wird, schlägt die Zeile fehl.

2. Filterausdruck: Diese optionale Bedingung schränkt das Dataset ein, für das die Zeilenbedingung ausgewertet wird. Sie aktivieren es, indem Sie das Kontrollkästchen Filterausdruck verwenden aktivieren. Dieser Ausdruck gibt einen booleschen Wert zurück. Der Filterausdruck gilt für eine Zeile, und wenn er true zurückgibt, wird diese Zeile für die Regel berücksichtigt. Wenn der Filterausdruck false für diese Zeile zurückgibt, bedeutet dies, dass zeile für die Zwecke dieser Regel ignoriert wird. Das Standardverhalten des Filterausdrucks besteht darin, alle Zeilen zu übergeben. Wenn Sie also keinen Filterausdruck angeben, werden alle Zeilen berücksichtigt.

3. NULL-Ausdruck: Überprüft, wie NULL-Werte behandelt werden sollen. Dieser Ausdruck gibt einen Booleschen Wert zurück, der Fälle behandelt, in denen Daten fehlen. Wenn der Ausdruck true zurückgibt, wird der Zeilenausdruck nicht angewendet.

Jeder Teil der Regel funktioniert ähnlich wie vorhandene Microsoft Purview Data Quality Bedingungen. Eine Regel wird nur übergeben, wenn der Zeilenausdruck für das Dataset, das dem Filterausdruck entspricht, als TRUE ausgewertet wird und fehlende Werte wie im NULL-Ausdruck angegeben behandelt.

Beispiel: Eine Regel, um sicherzustellen, dass "fareAmount" positiv und "tripDistance" gültig ist:

• Zeilenausdruck: tripDistance > 0 AND fareAmount > 0
• Filterausdruck: paymentType = 'CRD'
• NULL-Ausdruck: tripDistance IS NULL

Erstellen einer benutzerdefinierten Regel

1. Wechseln Sie Unified Catalog zu Integritätsverwaltung>Datenqualität.
2. Wählen Sie eine Governancedomäne, ein Datenprodukt und dann eine Datenressource aus.
3. Wählen Sie auf der Registerkarte Regeln die Option Neue Regel aus.

Erstellen einer benutzerdefinierten Regel mit Azure Data Factory Ausdruck (ADF)

1. Um die Regel mithilfe eines regulären Ausdrucks oder eines ADF-Ausdrucks zu erstellen, wählen Sie in der Regelliste der Optionen die Option Benutzerdefiniert und dann Weiter aus.

2. Fügen Sie Regelnamen und Beschreibung hinzu, und wählen Sie dann Erstellen aus.

   

Beispiele für benutzerdefinierte Regeln

Sowohl der Filterausdruck als auch der Zeilenausdruck werden mithilfe der Azure Data Factory Ausdruckssprache definiert, wobei die hier definierte Sprache verwendet wird. Es sind jedoch nicht alle Für die generische ADF-Ausdruckssprache definierten Funktionen verfügbar. Die vollständige Liste der verfügbaren Funktionen finden Sie in der Liste Funktionen, die im Dialogfeld "Ausdruck" verfügbar ist. Die folgenden hier definierten Funktionen werden nicht unterstützt: isDelete, isError, isIgnore, isInsert, isMatch, isUpdate, isUpsert, partitionId, cached lookup und Window.

Erstellen einer benutzerdefinierten Regel mithilfe eines SQL-Ausdrucks

Benutzerdefinierte SQL-Regeln in Microsoft Purview Data Quality bieten eine flexible Möglichkeit zum Definieren von Datenqualitätsprüfungen mithilfe von Spark SQL-Prädikaten. Mit diesem Feature können Benutzer Regeln direkt in Spark SQL für erweiterte Validierungsszenarien erstellen. Es ist nur ein Zeilenausdruck erforderlich. Filter- und NULL-Ausdrücke sind für weitere Anpassungen optional. Verwenden Sie benutzerdefinierte SQL-Regeln, um komplexe Geschäftsanforderungen zu erfüllen und die Datenqualität zu verbessern, indem Sie die vollständigen Funktionen von Spark SQL nutzen. Benutzerdefinierte SQL-Regeln ermöglichen eine komplexe Datenüberprüfung, die mit ADF-Ausdrücken allein möglicherweise nicht möglich ist. Durch das Schreiben von Spark SQL-Prädikaten können Sie einzigartige Geschäftsanforderungen erfüllen und hohe Datenqualitätsstandards einhalten.

1. Um die Regel mithilfe der SQL-Ausdruckssprache zu erstellen, wählen Sie in der Regelliste der Optionen die Option Benutzerdefiniert (SQL) und dann Weiter aus.

2. Fügen Sie Regelnamen und Beschreibung hinzu, und wählen Sie dann Erstellen aus.

   Szenario	Ausdrücke
   Überprüft korrekte Zeichenfolgenmuster (z. B. rateCodeId ab "1" und numerisch) und filtert nach gültigen Zahlungstypen.	Row: rateCodeId RLIKE '^1[0-9]+$' Filter: paymentType IN ('CRD', 'CSH') Null: rateCodeId IS NULL
   Stellt einen korrekten Spaltenvergleich zwischen puLocationId und doLocationId und dem Fahrpreis im Vergleich zur Fahrtstrecke sicher.	Row: puLocationId > doLocationId AND fareAmount > tripDistance * 10' Filter: paymentType <> 'CSH'' Null: tripDistance IS NULL
   Überprüft, ob der paymentType in einer bestimmten Liste (Card, Cash) enthalten ist, und filtert Zeilen nach Tarifbeträgen.	Row: paymentType IN ('CRD', 'CSH')' Filter: fareAmount >= 50 Null: paymentType IS NULL
   Stellt sicher, dass die Entfernung innerhalb eines inklusiven Bereichs (5-10 Meilen) liegt, während NULL verarbeitet und nach gültigen Zahlungsmethoden gefiltert wird.	Row: tripDistance BETWEEN 5 AND 10 Filter: paymentType <> 'CRD' Null: tripDistance IS NULL
   Stellt sicher, dass das Dataset einen NULL-Wert von 20 % für fareAmount nicht überschreitet.	Row: (SELECT avg(CASE WHEN fareAmount IS NULL THEN 1 ELSE 0 END) FROM nycyellowtaxidelta1BillionPartitioned) < 0.20' Filter: vendorID IN ('VTS', 'CMT')
   Überprüft, ob das Dataset mindestens zwei unterschiedliche paymentType-Werte enthält.	Row: (SELECT count(DISTINCT paymentType) FROM nycyellowtaxidelta1BillionPartitioned) >= 2 Filter: vendorID IN ('1', '2')
   Stellt sicher, dass der durchschnittliche Fahrpreis des Datasets innerhalb eines angegebenen Bereichs liegt (80 <= durchschnittlich <= 140).	Row: (SELECT avg(fareAmount) FROM nycyellowtaxidelta1BillionPartitioned) BETWEEN 80 AND 140 ' Filter: paymentType IN ('CRD', 'CSH')
   Stellt sicher, dass die maximale tripDistance im Dataset = 10 Meilen beträgt <.	Row: (SELECT max(tripDistance) FROM nycyellowtaxidelta1BillionPartitioned) <= 10.0 Filter: vendorID IN ('VTS', 'CMT')
   Stellt sicher, dass die Standardabweichung von fareAmount unter einem bestimmten Schwellenwert (< 30) liegt.	Row: (SELECT stddev_samp(fareAmount) FROM nycyellowtaxidelta1BillionPartitioned) < 30.0 Filter: vendorID IN ('VTS', 'CMT')
   Stellt sicher, dass der Medianpreis des Datasets innerhalb des angegebenen Schwellenwerts (<= 15) liegt.	Row: (SELECT percentile_approx(fareAmount, 0.5) FROM nycyellowtaxidelta1BillionPartitioned) <= 15.0 Filter: vendorID IN ('VTS', 'CMT')
   Stellt sicher, dass vendorId im Dataset innerhalb eines bestimmten paymentType eindeutig ist.	Row: COUNT(1) OVER (PARTITION BY vendorID) = 1 Filter: paymentType IN ('CRD', 'CSH','1', '2') Null: vendorID IS NULL
   Stellt sicher, dass die Kombination aus puLocationId und doLocationId innerhalb des Datasets eindeutig ist.	Row: COUNT(1) OVER (PARTITION BY puLocationId, doLocationId) = 1 Filter: paymentType IN ('CRD', 'CSH') Null: puLocationId IS NULL OR doLocationId IS NULL
   Stellt sicher, dass vendorId pro paymentType eindeutig ist.	Row: COUNT(1) OVER (PARTITION BY paymentType, vendorID) = 1 ,Filter: rateCodeId < 25, Null: vendorID IS NULL
   Stellt sicher, dass der tpepPickupDateTime-Wert der Zeile größer als ein gegebener Cutoff-Zeitstempel ist.	Row: tpepPickupDateTime >= TIMESTAMP '2014-01-03 00:00:00' Filter: paymentType IN ('CRD', 'CSG', '1', '2') Null: tpepPickupDateTime IS NULL
   Jede Fahrt muss innerhalb von 1 Stunde abgeschlossen werden	Row: (unix_timestamp(tpepDropoffDateTime) - unix_timestamp(tpepPickupDateTime)) <= 3600 Filter: paymentType IN ('CRD', 'CSH', '1', '2') Null: tpepPickupDateTime IS NULL OR tpepDropoffDateTime IS NULL
   Behält nur den höchsten Fahrpreis pro Abholort bei.	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
   Alle gebundenen höchsten Tarife pro Abholort (nicht nur zuerst durch 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
   Der Fahrpreis darf sich nicht im Laufe der Zeit für jede Zahlungsmethode verringern.	Row: fareAmount >= lag(fareAmount) OVER (PARTITION BY paymentType ORDER BY tpepPickupDateTime) Null: tpepPickupDateTime IS NULL OR fareAmount IS NULL
   Der Tarif jeder Zeile liegt innerhalb von 10 des Gruppendurchschnitts nach Zahlungsmethode.	Row: abs(fareAmount - avg(fareAmount) OVER (PARTITION BY paymentType)) <= 10 Filter: paymentType IN ('CRD', 'CSH','1','2') Null: fareAmount IS NULL
   Die Gesamtanzahl der Fahrtstrecken darf 20 Meilen nicht überschreiten.	Row: sum(tripDistance) OVER (ORDER BY tpepPickupDateTime ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW) <= 20 Filter: paymentType = '1' Null: tripDistance IS NULL
   Überprüft, ob der Fahrpreis jeder Reise über dem globalen Durchschnitt für berechtigte Anbieter liegt.	Row: fareAmount > (SELECT avg(fareAmount) FROM nycyellowtaxidelta1BillionPartitioned) Filter: vendorID IN ('VTS', 'CMT') Null: fareAmount IS NULL
   Überprüft, ob die tripDistance jeder Zeile größer als der Mindestwert für ihren paymentType (Card/Cash) ist.	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
   Überprüft bei jeder Fahrt, ob der Fahrpreis über dem Durchschnitt für seine Zahlungsmethode liegt.	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
   Überprüft, ob die fareAmount-Spalte (numerisch) korrekt als Zeichenfolge dargestellt werden kann, die dem numerischen Muster entspricht (positive Zahlen mit optionaler Dezimalzahl). Dabei wird die Umwandlung verwendet, da fareAmount eine numerische Spalte ist.	Row: CAST(fareAmount AS STRING) RLIKE '^[0-9]+(\.[0-9]+)?$' Filter: paymentType IN ('CRD', 'CSH') Null: fareAmount IS NULL
   Stellt sicher, dass tpepPickupDateTime ein gültiger Zeitstempel im Format yyyy-MM-tt HH:mm:ss ist. Diese Spalte weist bereits das DATETIME-Format auf.	Row: to_timestamp(tpepPickupDateTime, 'yyyy-MM-dd HH:mm:ss') IS NOT NULL Filter: paymentType IN ('CRD', 'CSH') Null: tpepPickupDateTime IS NULL
   Stellt sicher, dass paymentType-Werte in Kleinbuchstaben normalisiert werden und keine führenden oder nachfolgenden Leerzeichen aufweisen.	Row: lower(trim(paymentType)) IN ('card','cash') AND length(trim(paymentType)) > 0 Null: paymentType IS NULL OR trim(paymentType) = ''
   Berechnet sicher das Verhältnis von fareAmount zu tripDistance und stellt sicher, dass die Division durch Null nicht erfolgt, indem zuerst überprüft wird, ob tripDistance > 0 ist.	Row: CASE WHEN tripDistance > 0 THEN fareAmount / tripDistance ELSE NULL END >= 10 Filter: tripDistance > 0 AND vendorID IN ('VTS', 'CMT')
   Veranschaulicht, wie Coalesce NULL-Werte durch Standardwerte ersetzen kann (z. B. 0,0), und stellt sicher, dass nur gültige Zeilen zurückgegeben werden.	Row: coalesce(fareAmount, 0.0) >= 5 Filter: paymentType IN ('CRD','CSH')

Bewährte Methoden zum Schreiben benutzerdefinierter SQL-Regeln

• Halten Sie Ausdrücke einfach. Ziel ist es, klare, unkomplizierte Ausdrücke zu schreiben, die einfach zu verwalten sind.
• Verwenden sie integrierte Spark SQL-Funktionen. Verwenden Sie die umfangreiche Bibliothek von Funktionen von Spark SQL für die Bearbeitung von Zeichenfolgen, die Datumsbehandlung und numerische Vorgänge, um Fehler zu minimieren und die Leistung zu verbessern.
• Testen Sie zuerst mit einem kleinen Dataset. Überprüfen Sie Regeln für ein kleines Dataset, bevor Sie sie im großen Stil anwenden, um potenzielle Probleme frühzeitig zu identifizieren.

Bekannte Einschränkungen und Überlegungen für SQL-Ausdrucksregeln

Mehrdeutige Spaltenverweise und Spaltenschattierung

• Problem: Wenn eine Spalte sowohl in der äußeren Abfrage als auch in der Unterabfrage (oder in verschiedenen Teilen der Abfrage) mit demselben Namen angezeigt wird, kann Spark SQL möglicherweise nicht auflösen, welche Spalte verwendet werden soll. Dieses Problem führt zu logischen Fehlern oder zu einer falschen Abfrageausführung. Dieses Problem kann bei geschachtelten Abfragen, Unterabfragen oder Joins auftreten, was zu Mehrdeutigkeiten oder Schatten führt.

• Mehrdeutigkeit: Tritt auf, wenn ein Spaltenname sowohl in der äußeren Abfrage als auch in der Unterabfrage ohne eindeutige Qualifizierung vorhanden ist, sodass Spark SQL unsicher ist, auf welche Spalte verwiesen werden soll.

• Shadowing: Bezieht sich auf, wenn eine Spalte in der äußeren Abfrage von derselben Spalte in der Unterabfrage "überschrieben" oder "abgeschatt" wird, wodurch der äußere Verweis ignoriert wird.

  Beispielausdruck:

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

• Problem: Nicht qualifizierte payment_type wird in den nächstgelegenen Bereich aufgelöst, der eine Spalte mit diesem Namen enthält, d. h. die innere t.payment_type , nicht die payment_type der äußeren Zeile. Dadurch wird das Prädikat in t.payment_type = t.payment_type (immer TRUE) umgewandelt, sodass Ihre Unterabfrage zu einem globalen min statt zu einer Gruppe min wird.

• Lösung: Um diese Mehrdeutigkeit aufzulösen und Spaltenschattierung zu vermeiden, benennen Sie die innere Spalte in der Unterabfrage um, und stellen Sie sicher, dass die payment_type der äußeren Abfrage eindeutig bleibt.

Korrigierter Ausdruck:

  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 
  )

• In der Unterabfrage wird die Spalte payment_type als pt (d. h. payment_type AS pt) bezeichnet, und you.pt wird in der Bedingung verwendet.
• In der äußeren Abfrage kann jetzt eindeutig auf den ursprünglichen payment_type verwiesen werden, und Spark SQL löst ihn ordnungsgemäß als äußere payment_type auf.

Fenstervorgänge (Leistungsüberlegung)

• Fenstervorgänge wie ROW_NUMBER() und RANK() können teuer sein, insbesondere bei großen Datasets. Verwenden Sie sie mit Bedacht, und testen Sie die Leistung für kleinere Datasets, bevor Sie sie im großen Stil anwenden. Erwägen Sie die Verwendung von PARTITION BY, um den Datenbereich zu reduzieren.

Escaping von Spaltennamen in Spark SQL

• Wenn Spaltennamen Sonderzeichen (z. B. Leerzeichen, Bindestriche oder andere nicht alphanumerische Zeichen) enthalten, müssen sie mit Escapezeichen versehen werden.
• Beispiel, wenn der Spaltenname order-id lautet und die Regel lauten muss, dass er größer als 10 sein sollte.
• Falscher Ausdruck: order-id > 10
• Richtiger Ausdruck: `order-id`> 10

Name der Datenressource, der in Ausdrücken verweist

Wenn Sie in SQL-Ausdrücken auf Ihre Datenressource verweisen, müssen Sie bestimmte Bereinigungsregeln befolgen. Der ursprüngliche Name der Datenressource muss nicht aktualisiert werden, aber der Name der Datenressource, auf den in SQL-Ausdrücken verwiesen wird, muss bereinigt werden, um die folgenden Kriterien zu erfüllen:

Wenn ihr Datenobjektname bereits diesen Richtlinien entspricht (d. h., er enthält keine Sonderzeichen, führende/nachfolgende Unterstriche und liegt innerhalb des 64-Zeichen-Grenzwerts), kann er unverändert in Ihren SQL-Ausdrücken verwendet werden.

Bereinigen eines Datasetnamens

Führen Sie die folgenden Schritte aus, um sicherzustellen, dass ihr Datasetname für SQL-Ausdrücke gültig ist:

1. Sonderzeichen entfernen: Entfernen Sie alle Zeichen außer Buchstaben, Zahlen und Unterstrichen.
2. Unterstriche kürzen: Entfernen Sie alle führenden oder nachfolgenden Unterstriche.
3. Abschneiden: Wenn der resultierende Name 64 Zeichen überschreitet, kürzen Sie ihn so ab, dass der Grenzwert von 64 Zeichen eingehalten wird.

Beispiel: Name der Datenressource f07d724d-82c9-4c75-97c4-c5baf2cd12a4.parquet

1. Sonderzeichen entfernen: f07d724d82c94c7597c4c5baf2cd12a4parquet
2. Unterstriche kürzen: (In diesem Fall nicht verfügbar, da keine führenden oder nachfolgenden Unterstriche vorhanden sind.)
3. Abschneiden: Der resultierende Name ist 54 Zeichen lang, was unter dem Grenzwert von 64 Zeichen liegt.

Endgültiger SQL-Referenzname: f07d724d82c94c7597c4c5baf2cd12a4parquet

Joins werden nicht unterstützt.

Benutzerdefinierte SQL-Regeln in Microsoft Purview Data Quality keine Joins unterstützen. Die Regeln müssen für ein einzelnes Dataset verwendet werden. Sie können beim Schreiben dieser benutzerdefinierten Regeln nicht mehrere Tabellen oder Datasets verknüpfen.

Nicht unterstützte SQL-Vorgänge (DML, DCL und schädliches SQL)

Benutzerdefinierte SQL-Regeln unterstützen keine DML-Vorgänge (Data Manipulation Language) oder DCL-Vorgänge (Data Control Language) wie INSERT, UPDATE, DELETE, GRANT und andere schädliche SQL-Vorgänge wie TRUNCATE, DROP und ALTER. Diese Vorgänge werden nicht unterstützt, da sie die Daten oder den Zustand der Datenbank ändern.

KI-gestützte automatisch generierte Regeln

Ki-gestützte automatisierte Regelgenerierung für die Datenqualitätsmessung verwendet KI-Techniken (Künstliche Intelligenz), um automatisch Regeln für die Bewertung und Verbesserung der Datenqualität zu erstellen. Automatisch generierte Regeln sind inhaltsspezifisch. Die meisten allgemeinen Regeln werden automatisch generiert, sodass Sie sich nicht viel mühen müssen, benutzerdefinierte Regeln zu erstellen.

So durchsuchen und wenden Sie automatisch generierte Regeln an:

1. Wählen Sie auf der Registerkarte Regeln einer Datenressource Regeln vorschlagen aus.

2. Durchsuchen Sie die Liste der vorgeschlagenen Regeln.

   

3. Wählen Sie regeln aus der Liste der vorgeschlagenen Regeln aus, die auf die Datenressource angewendet werden sollen.

   

Nächste Schritte

1. Konfigurieren und Ausführen einer Datenqualitätsüberprüfung für ein Datenprodukt, um die Qualität aller unterstützten Ressourcen im Datenprodukt zu bewerten.
2. Überprüfen Sie Ihre Scanergebnisse , um die aktuelle Datenqualität Ihres Datenprodukts zu bewerten.