Controles van gegevenstypen implementeren

Elke kolom in uw dataset heeft een verwacht gegevenstype, en wanneer nieuwe gegevens niet aan die verwachtingen voldoen, ontstaan problemen verderop in de flow. Een tekenreekswaarde op de plaats waar een geheel getal hoort, kan berekeningen verstoren, aggregaties corrupt maken of pijplijnstoringen veroorzaken. Gegevenstypecontroles zorgen ervoor dat elk veld waarden van het juiste type bevat voordat ze in uw tabellen worden ingevoerd.

In deze les leert u hoe u controles van gegevenstypen implementeert met behulp van schema-afdwinging, expliciete typecasting en validatiebeperkingen in Azure Databricks.

De handhaving van schema's begrijpen

Delta Lake valideert automatisch gegevenstypen wanneer u gegevens naar een tabel schrijft. Met dit ingebouwde mechanisme, dat schema afdwinging wordt genoemd, worden de gegevenstypen van binnenkomende kolommen vergeleken met het schema van de doeltabel. Wanneer een type niet overeenkomt, probeert Delta Lake de waarde veilig te casten. Als de cast mislukt, genereert de schrijfbewerking een fout.

Bij het afdwingen van schema's worden de volgende regels toegepast tijdens het invoegen van bewerkingen:

• Alle ingevoegde kolommen moeten aanwezig zijn in de doeltabel
• Alle kolomgegevenstypen moeten overeenkomen of veilig kunnen worden geconverteerd naar de doeltypen

Overweeg een tabel met een kolom met een geheel getal:

CREATE TABLE inventory (
    product_id INT,
    quantity INT,
    last_updated DATE
);

Wanneer u gegevens invoegt waarbij quantity een tekenreeks een getal vertegenwoordigt, wordt deze door Delta Lake omgezet in het doeltype:

-- This succeeds because '100' can be cast to INT
INSERT INTO inventory VALUES (1, '100', '2026-01-15');

Als u echter een tekenreeks invoegt die niet kan worden geconverteerd naar een geheel getal, mislukt de bewerking:

-- This fails because 'fifty' cannot be cast to INT
INSERT INTO inventory VALUES (2, 'fifty', '2026-01-15');

Schemahandhaving biedt een eerste verdedigingslinie tegen typeconflicten. Voor meer controle over hoe afwijkingen worden verwerkt, kunt u gebruik maken van expliciet casten.

Expliciete typecasting gebruiken

De cast functie converteert waarden van het ene gegevenstype naar het andere. Wanneer de conversie mislukt, wordt er een fout gegenereerd. De try_cast functie werkt op dezelfde manier, maar retourneert NULL in plaats van een fout op te geven wanneer de conversie mislukt.

Gebruik cast deze opdracht als u strikte validatie wilt die de verwerking van ongeldige gegevens stopt:

SELECT 
    cast(raw_amount AS DECIMAL(10,2)) AS amount,
    cast(raw_date AS DATE) AS transaction_date
FROM staging_data;

Gebruik try_cast dit als u ongeldige waarden wilt identificeren zonder dat de query mislukt:

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;

Met try_cast records met ongeldige waarden retourneren NULL voor de gecast kolom. U kunt deze records vervolgens filteren, markeren of in quarantaine plaatsen op basis van uw vereisten voor gegevenskwaliteit.

Typevalidatie implementeren met beperkingen

Met CHECK-beperkingen kunt u aangepaste validatieregels definiëren die worden afgedwongen wanneer gegevens worden ingevoegd of bijgewerkt. Hoewel u deze meestal gebruikt voor waardebereiken en patronen, kunt u deze combineren met typebewuste functies om geavanceerde typecontroles te maken.

U kunt bijvoorbeeld controleren of een tekenreekskolom alleen numerieke tekens bevat:

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]+)?$')

Deze beperking zorgt ervoor dat de order_total kolom waarden bevat die op geldige getallen lijken, waarbij incorrecte gegevens worden opgevangen voordat deze de tabel invoeren.

Voor datumvalidatie kunt u de try_cast functie binnen een beperking gebruiken:

ALTER TABLE events 
ADD CONSTRAINT valid_event_date CHECK (try_cast(event_date_str AS DATE) IS NOT NULL);

Deze benadering wijst records af waarvoor event_date_str geen geldige datumnotatie bevat.

Afhandelen van typemismatches in pijplijnen

Bij het verwerken van gegevens uit externe bronnen komen typefouten vaak voor. Implementeer een patroon dat geldige records van ongeldige scheidt, zodat u goede gegevens kunt verwerken terwijl u problematische records voor revisie apart zet.

-- 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;

Dit patroon zorgt ervoor dat uw pijplijn geldige gegevens blijft verwerken en ongeldige records behoudt voor latere analyse.

Pijplijnwachtingen gebruiken voor typecontrole

Lakeflow-pijplijnen bieden expectations waarmee u regels voor gegevenskwaliteit rechtstreeks in uw pijplijndefinities kunt definiëren. U kunt verwachtingen gebruiken om te controleren of waarden kunnen worden omgezet in verwachte typen:

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")

Records expect_or_dropdie niet voldoen aan de typecontrole, worden verwijderd voordat ze de doeltabel bereiken. Gebruik expect dit om schendingen te registreren zonder records te verwijderen of expect_or_fail om de pijplijn te stoppen wanneer er schendingen optreden.

Voor pijplijnen op basis van SQL:

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);

Pijplijnverwachtingen integreren validatie van gegevenstypen rechtstreeks in uw ETL-logica en bieden inzicht in metrische gegevens over gegevenskwaliteit via de pijplijngebruikersinterface.

Door controles van gegevenstypen op meerdere niveaus te implementeren, zoals het afdwingen van schema's, expliciete casting, beperkingen en verwachtingen in de pijplijn, wordt er een diepgaande verdediging opgebouwd. Elke laag onderschept problemen die mogelijk voorbij anderen gaan, wat resulteert in een hogere gegevenskwaliteit in uw Unity Catalog-tabellen.