Datentypüberprüfungen implementieren
Jede Spalte in Ihrem Datensatz hat einen erwarteten Datentyp, und wenn die eingehenden Daten nicht mit dieser Erwartung übereinstimmen, entstehen kaskadenartig Probleme. Ein String-Wert, zu dem eine ganze Zahl gehört, kann Berechnungen unterbrechen, Aggregationen beschädigen oder Pipeline-Fehler verursachen. Datentypüberprüfungen stellen sicher, dass jedes Feld Werte des richtigen Typs enthält, bevor sie Ihre Tabellen eingeben.
In dieser Lektion erfahren Sie, wie Sie Datentypüberprüfungen mithilfe von Schemaerzwingung, expliziter Typzuwandlung und Validierungseinschränkungen in Azure Databricks implementieren.
Schemaerzwingung verstehen
Delta Lake überprüft Datentypen automatisch, wenn Sie Daten in eine Tabelle schreiben. Dieser integrierte Mechanismus, der als Schemaerzwingung bezeichnet wird, vergleicht die Datentypen eingehender Spalten mit dem Schema der Zieltabelle. Wenn eine Typ-Fehlanpassung auftritt, versucht Delta Lake, den Wert sicher umzuwandeln. Wenn die Umwandlung fehlschlägt, gibt der Schreibvorgang einen Fehler aus.
Die Schemaerzwingung wendet bei Einfügeoperationen die folgenden Regeln an:
- Alle eingefügten Spalten müssen in der Zieltabelle vorhanden sein.
- Alle Spaltendatentypen müssen mit den Zieltypen übereinstimmen oder sicher umwandelbar sein.
Betrachten Sie eine Tabelle mit einer ganzzahligen Spalte:
CREATE TABLE inventory (
product_id INT,
quantity INT,
last_updated DATE
);
Wenn Sie Daten einfügen, bei denen quantity es sich um eine Zeichenfolge handelt, die eine Zahl darstellt, wandelt Delta Lake sie in den Zieltyp um:
-- This succeeds because '100' can be cast to INT
INSERT INTO inventory VALUES (1, '100', '2026-01-15');
Das Einfügen einer Zeichenfolge, die nicht in eine ganze Zahl konvertiert werden kann, führt jedoch dazu, dass der Vorgang fehlschlägt:
-- This fails because 'fifty' cannot be cast to INT
INSERT INTO inventory VALUES (2, 'fifty', '2026-01-15');
Die Schemaerzwingung bietet eine erste Verteidigungslinie gegen Typinkongruenzen. Um mehr Kontrolle darüber zu erhalten, wie Nichtübereinstimmungen behandelt werden, können Sie explizites Casting verwenden.
Verwenden Sie explizites Type Casting
Die cast Funktion konvertiert Werte von einem Datentyp in einen anderen. Wenn die Konvertierung fehlschlägt, wird ein Fehler ausgelöst. Die try_cast Funktion funktioniert auf die gleiche Weise, gibt NULL aber zurück, anstatt einen Fehler zu auslösen, wenn die Konvertierung fehlschlägt.
Verwenden Sie cast, wenn Sie eine strenge Überprüfung wünschen, die die Verarbeitung bei ungültigen Daten stoppt.
SELECT
cast(raw_amount AS DECIMAL(10,2)) AS amount,
cast(raw_date AS DATE) AS transaction_date
FROM staging_data;
Verwenden Sie diese Vorgehensweise try_cast , wenn Sie ungültige Werte identifizieren möchten, ohne dass die Abfrage fehlschlägt:
SELECT
raw_amount,
try_cast(raw_amount AS DECIMAL(10,2)) AS validated_amount,
CASE
WHEN try_cast(raw_amount AS DECIMAL(10,2)) IS NULL
THEN 'Invalid amount format'
ELSE 'Valid'
END AS validation_status
FROM staging_data;
Mit try_cast geben Datensätze mit ungültigen Werten NULL für die Cast-Spalte zurück. Anschließend können Sie diese Datensätze basierend auf Ihren Datenqualitätsanforderungen filtern, kennzeichnen oder unter Quarantäne stellen.
Implementierung der Typüberprüfung mit Einschränkungen
MIT CHECK-Einschränkungen können Sie benutzerdefinierte Gültigkeitsprüfungsregeln definieren, die erzwungen werden, wenn Daten eingefügt oder aktualisiert werden. Während sie in der Regel für Wertebereiche und Muster verwendet werden, können Sie sie mit typfähigen Funktionen kombinieren, um komplexe Typüberprüfungen zu erstellen.
Sie können beispielsweise überprüfen, ob eine Zeichenfolgenspalte nur numerische Zeichen enthält:
CREATE TABLE orders (
order_id INT,
order_total STRING
);
ALTER TABLE orders
ADD CONSTRAINT valid_order_total CHECK (order_total REGEXP '^[0-9]+(\\.[0-9]+)?$')
Diese Einschränkung stellt sicher, dass die order_total Spalte Werte enthält, die wie gültige Zahlen aussehen und falsch formatierte Daten abfangen, bevor sie die Tabelle eingibt.
Für die Datumsüberprüfung können Sie die try_cast Funktion innerhalb einer Einschränkung verwenden:
ALTER TABLE events
ADD CONSTRAINT valid_event_date CHECK (try_cast(event_date_str AS DATE) IS NOT NULL);
Bei diesem Ansatz werden Datensätze abgelehnt, bei denen event_date_str kein gültiges Datumsformat enthalten ist.
Von Bedeutung
Bevor Sie einer vorhandenen Tabelle eine Einschränkung hinzufügen, überprüft Azure Databricks, ob alle vorhandenen Zeilen die Einschränkung erfüllen. Planen Sie diesen Überprüfungsschritt, insbesondere für große Tabellen.
Typkonflikte in Pipelines beheben
Bei der Verarbeitung von Daten aus externen Quellen sind Typenkonflikten üblich. Implementieren Sie ein Muster, das von ungültigen Datensätzen getrennt ist, sodass Sie gute Daten verarbeiten können, während problematische Datensätze zur Überprüfung unter quarantänet werden:
-- Insert valid records into the target table
INSERT INTO silver_transactions
SELECT
transaction_id,
cast(amount AS DECIMAL(10,2)) AS amount,
cast(transaction_date AS DATE) AS transaction_date
FROM bronze_transactions
WHERE try_cast(amount AS DECIMAL(10,2)) IS NOT NULL
AND try_cast(transaction_date AS DATE) IS NOT NULL;
-- Capture invalid records for investigation
INSERT INTO quarantine_transactions
SELECT
transaction_id,
amount AS raw_amount,
transaction_date AS raw_date,
current_timestamp() AS quarantined_at,
'Type validation failed' AS reason
FROM bronze_transactions
WHERE try_cast(amount AS DECIMAL(10,2)) IS NULL
OR try_cast(transaction_date AS DATE) IS NULL;
Mit diesem Muster wird sichergestellt, dass Ihre Pipeline gültige Daten weiter verarbeitet und gleichzeitig ungültige Datensätze für die spätere Analyse bewahrt.
Verwenden Sie Pipeline-Erwartungen für die Typüberprüfung
Lakeflow-Pipelines bieten Expectations, mit denen Sie Datenqualitätsregeln direkt in Ihren Pipelinedefinitionen definieren können. Sie können die Erwartungen verwenden, um zu überprüfen, ob Werte in erwartete Typen umgerechnet werden können:
from pyspark import pipelines as dp
@dp.table
@dp.expect_or_drop("valid_amount", "try_cast(amount AS DECIMAL(10,2)) IS NOT NULL")
@dp.expect_or_drop("valid_date", "try_cast(event_date AS DATE) IS NOT NULL")
def validated_transactions():
return spark.readStream.table("raw_transactions")
Wenn expect_or_drop verwendet wird, werden Datensätze, die die Typüberprüfung nicht bestehen, gelöscht, bevor sie die Zieltabelle erreichen. Verwenden Sie expect, um Verstöße zu protokollieren, ohne Datensätze zu verwerfen, oder expect_or_fail, um die Pipeline zu stoppen, wenn Verstöße auftreten.
Für SQL-basierte Pipelines:
CREATE OR REFRESH STREAMING TABLE validated_transactions (
CONSTRAINT valid_amount EXPECT (try_cast(amount AS DECIMAL(10,2)) IS NOT NULL) ON VIOLATION DROP ROW,
CONSTRAINT valid_date EXPECT (try_cast(event_date AS DATE) IS NOT NULL) ON VIOLATION DROP ROW
)
AS SELECT * FROM STREAM(raw_transactions);
Pipelineerwartungen integrieren die Datentypüberprüfung direkt in Ihre ETL-Logik und bieten Einblicke in Datenqualitätsmetriken über die Pipeline-Benutzeroberfläche.
Die Implementierung von Datentypprüfungen auf mehreren Ebenen - Schemaerzwingung, explizites Casting, Constraints und Pipeline-Erwartungen - schafft einen umfassenden Schutz. Jede Ebene fängt Probleme auf, die möglicherweise über andere hinausrutschen, was zu einer höheren Datenqualität in Ihren Unity-Katalogtabellen führt.