Implementera datatypskontroller

Varje kolumn i datamängden har en förväntad datatyp, och när inkommande data inte matchar den förväntan kan problem uppstå underströms. Strängvärde som används istället för ett heltal kan bryta beräkningar, förstöra aggregeringar eller orsaka pipelinefel. Datatypkontroller kontrollerar att varje fält innehåller värden av rätt typ innan de anger dina tabeller.

I den här lektionen får du lära dig hur du implementerar datatypkontroller med hjälp av schemaframtvingande, explicit typgjutning och valideringsbegränsningar i Azure Databricks.

Förstå schema-tillämpning

Delta Lake validerar datatyper automatiskt när du skriver data till en tabell. Den här inbyggda mekanismen, som kallas schemaframtvingande, jämför datatyperna för inkommande kolumner med måltabellens schema. När en typmatchning inträffar försöker Delta Lake att på ett säkert sätt omvandla värdet. Om gjutningen misslyckas genererar skrivåtgärden ett fel.

Schematillämpning tillämpar följande regler under infogningsåtgärder:

• Alla infogade kolumner måste finnas i måltabellen
• Alla kolumndatatyper måste matcha eller vara säkert konverterbara till måltyperna.

Överväg en tabell med en heltalskolumn:

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

När du infogar data där quantity är en sträng som representerar ett tal, omvandlar Delta Lake den till måltypen:

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

Om du infogar en sträng som inte kan konverteras till ett heltal misslyckas åtgärden:

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

Schematillämpning ger en första försvarslinje mot typmatchningar. Om du vill ha mer kontroll över hur matchningar hanteras kan du använda explicit gjutning.

Använda explicit typgjutning

Funktionen cast konverterar värden från en datatyp till en annan. När konverteringen misslyckas utlöses ett fel. Funktionen try_cast fungerar på samma sätt men returnerar NULL i stället för att skapa ett fel när konverteringen misslyckas.

Använd cast när du vill ha en strikt validering som slutar bearbeta ogiltiga data:

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

Använd try_cast när du vill identifiera ogiltiga värden utan att misslyckas med frågan:

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;

Med try_cast returnerar poster med ogiltiga värden NULL för den kastade kolumnen. Du kan sedan filtrera, flagga eller placera posterna i karantän baserat på dina datakvalitetskrav.

Implementera typverifiering med begränsningar

Med CHECK-begränsningar kan du definiera anpassade verifieringsregler som tillämpas när data infogas eller uppdateras. Även om de vanligtvis används för värdeintervall och mönster kan du kombinera dem med typmedvetna funktioner för att skapa avancerade typkontroller.

Du kan till exempel verifiera att en strängkolumn endast innehåller numeriska tecken:

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

Den här begränsningen order_total säkerställer att kolumnen innehåller värden som ser ut som giltiga tal och fångar felaktiga data innan den kommer in i tabellen.

För datumverifiering kan du använda try_cast funktionen inom en begränsning:

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

Den här metoden avvisar poster där event_date_str inte innehåller ett giltigt datumformat.

Hantera typavvikelser i pipelines

Vid bearbetning av data från externa källor är typmatchningar vanliga. Implementera ett mönster som separerar giltiga från ogiltiga poster, så att du kan bearbeta bra data samtidigt som problematiska poster kan granskas:

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

Det här mönstret säkerställer att pipelinen fortsätter att bearbeta giltiga data samtidigt som ogiltiga poster bevaras för senare analys.

Använd pipelineförväntningar för typkontroll

Lakeflow-pipelines ger expectations som gör att du kan definiera datakvalitetsregler direkt i dina pipelinedefinitioner. Du kan använda förväntningar för att kontrollera att värden kan omvandlas till förväntade typer:

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

Med expect_or_drop tas poster som inte uppfyller kontrollen bort innan de når måltabellen. Använd expect för att logga överträdelser utan att ta bort poster eller expect_or_fail för att stoppa pipelinen när överträdelser inträffar.

För SQL-baserade 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);

Pipelineförväntningar integrerar datatypsverifiering direkt i din ETL-logik, vilket ger insyn i datakvalitetsmått via pipelinegränssnittet.

Implementering av datatypskontroller på flera nivåer – schemaframtvingande, explicit gjutning, begränsningar och pipelineförväntningar – skapar skydd på djupet. Varje lager fångar upp problem som kan glida förbi andra, vilket resulterar i högre datakvalitet i dina Unity Catalog-tabeller.