Implémenter des vérifications de type de données

Chaque colonne de votre jeu de données a un type de données attendu et lorsque les données entrantes ne correspondent pas à cette attente, les problèmes se produisent en aval. Une valeur de chaîne là où un entier est attendu peut casser les calculs, corrompre les agrégations ou provoquer des échecs de pipeline. Les vérifications du type de données s'assurent que chaque champ contient des valeurs du type correct avant qu'elles n'entrent dans vos tables.

Dans cette unité, vous allez apprendre à implémenter des vérifications des types de données à l’aide de l’application du schéma, de la conversion de type explicite et des contraintes de validation dans Azure Databricks.

Comprendre l’application du schéma

Delta Lake valide automatiquement les types de données lorsque vous écrivez des données dans une table. Ce mécanisme intégré, appelé application de schéma, compare les types de données des colonnes entrantes par rapport au schéma de la table cible. Lorsqu’une incompatibilité de type se produit, Delta Lake tente de convertir la valeur en toute sécurité. Si le cast échoue, l’opération d’écriture génère une erreur.

Le respect du schéma impose les règles suivantes pendant les opérations d'insertion :

• Toutes les colonnes insérées doivent exister dans la table cible
• Tous les types de données de colonne doivent correspondre ou être convertibles en toute sécurité aux types cibles

Considérez une table avec une colonne entière :

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

Lorsque vous insérez des données où quantity se trouve une chaîne qui représente un nombre, Delta Lake le convertit en type cible :

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

Toutefois, l’insertion d’une chaîne qui ne peut pas être convertie en entier provoque l’échec de l’opération :

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

L’application du schéma fournit une première ligne de défense contre les incompatibilités de type. Pour mieux contrôler la façon dont les incompatibilités sont gérées, vous pouvez utiliser le casting explicite.

Utiliser le casting explicite de type

La cast fonction convertit les valeurs d’un type de données en un autre. Lorsque la conversion échoue, une erreur est générée. La try_cast fonction fonctionne de la même façon, mais retourne NULL au lieu de déclencher une erreur lorsque la conversion échoue.

Utilisez cast quand vous souhaitez une validation stricte qui arrête le traitement sur des données non valides :

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

Utilisez try_cast quand vous souhaitez identifier les valeurs non valides sans échec de la requête :

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;

Avec try_cast, les enregistrements avec des valeurs non valides retournent NULL pour la colonne cast. Vous pouvez ensuite filtrer, marquer ou mettre en quarantaine ces enregistrements en fonction de vos exigences de qualité des données.

Implémenter la validation de type avec des contraintes

Les contraintes CHECK vous permettent de définir des règles de validation personnalisées qui sont appliquées chaque fois que les données sont insérées ou mises à jour. Bien qu’ils soient généralement utilisés pour les plages de valeurs et les modèles, vous pouvez les combiner avec des fonctions prenant en charge le type pour créer des vérifications de type sophistiquées.

Par exemple, vous pouvez vérifier qu’une colonne de chaîne contient uniquement des caractères numériques :

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

Cette contrainte garantit que la order_total colonne contient des valeurs qui ressemblent à des nombres valides, interceptant des données incorrectes avant d’entrer dans la table.

Pour la validation de date, vous pouvez utiliser la try_cast fonction dans une contrainte :

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

Cette approche rejette les enregistrements qui event_date_str ne contiennent pas de format de date valide.

Gérer les incompatibilités de type dans les pipelines

Lors du traitement des données provenant de sources externes, les incompatibilités de type sont courantes. Implémentez un modèle qui sépare les enregistrements non valides, ce qui vous permet de traiter de bonnes données lors de la mise en quarantaine des enregistrements problématiques pour révision :

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

Ce modèle garantit que votre pipeline continue de traiter les données valides tout en préservant les enregistrements non valides pour une analyse ultérieure.

Utiliser les attentes de pipeline pour la vérification de type

Les pipelines Lakeflow fournissent des expectations qui vous permettent de définir des règles de qualité des données directement dans vos définitions de pipeline. Vous pouvez utiliser des attentes pour vérifier que les valeurs peuvent être converties en types attendus :

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

Avec expect_or_drop, les enregistrements qui échouent à la vérification de type sont supprimés avant d’atteindre la table cible. Permet expect de journaliser les violations sans supprimer d’enregistrements ou expect_or_fail d’arrêter le pipeline lorsque des violations se produisent.

Pour les pipelines 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);

Les attentes de pipeline intègrent la validation de type de données directement dans votre logique ETL, ce qui offre une visibilité sur les métriques de qualité des données via l’interface utilisateur du pipeline.

Mettre en œuvre des contrôles de type de données à plusieurs niveaux (application de schéma, casting explicite, contraintes et attentes de pipeline) crée une défense en profondeur. Chaque couche détecte des problèmes qui pourraient échapper aux autres, ce qui se traduit par une meilleure qualité des données dans vos tables Unity Catalog.