Meilleures pratiques pour les pipelines déclaratifs Spark Lakeflow

Cette page décrit les modèles recommandés pour la conception, la création et l’exploitation de pipelines avec des pipelines déclaratifs Spark Lakeflow. Appliquez ces instructions lors du démarrage d’un nouveau pipeline ou de l’amélioration d’un pipeline existant.

Choisir le type de jeu de données approprié

Lakeflow Spark Declarative Pipelines offre trois types de jeux de données : les tables de streaming, les vues matérialisées et les vues temporaires. Le choix du type approprié pour chaque couche de votre pipeline évite les coûts de calcul inutiles et rend votre code plus facile à comprendre.

Les tables de streaming sont le bon choix pour l’ingestion des données et les transformations de streaming à faible latence. Chaque ligne d’entrée est lue et traitée une seule fois, ce qui les rend idéales pour les charges de travail d’ajout uniquement, les données à volume élevé et le traitement piloté par les événements à partir du stockage cloud ou des bus de messages.

Les vues matérialisées sont le bon choix pour les transformations complexes et les requêtes analytiques. Leurs résultats sont pré-calculés et maintenus à jour à l’aide de l’actualisation incrémentielle, de sorte que les requêtes sur celles-ci sont rapides. Vous ne pouvez pas modifier directement les données dans une vue matérialisée : la définition de requête contrôle la sortie.

Les vues temporaires sont des vues portées au sein du pipeline qui organisent votre logique de transformation sans enregistrer les données dans le stockage. Utilisez-les pour les étapes intermédiaires qui n’ont pas besoin de leur propre table.

Le tableau suivant récapitule quand utiliser chaque type :

Cas d’utilisation	Type recommandé	Reason
Ingestion à partir du stockage cloud ou d’un bus de messages	Table de diffusion en continu	Traite chaque enregistrement une seule fois ; gère un volume élevé et des charges de travail d’ajout uniquement.
Flux CDC (insertions, mises à jour, suppressions)	Table de diffusion en continu	Utilisé comme cible de l’ingestion CDC ordonnée et dédupliquée.
Agrégations et jointures complexes	Vue matérialisée	Actualisation incrémentielle ; évite la recomputation complète sur chaque mise à jour.
Accélération des requêtes de tableau de bord	Vue matérialisée	Les résultats pré-calculés accélèrent les requêtes par rapport aux tables brutes.
Transformations intermédiaires (aucun lecteur en aval)	Vue temporaire	Organise la logique de pipeline sans entraîner de coût de stockage.

Pour plus d’informations, consultez les tables de streaming, les vues matérialisées et les concepts de pipelines déclaratifs Spark Lakeflow.

Utilisez CDC déclaratif plutôt que MERGE impératif

L’implémentation de capture de données modifiées (CDC) avec des instructions SQL MERGE impératives nécessite un code personnalisé important pour gérer correctement l’ordre des événements, la déduplication, les mises à jour partielles et l’évolution du schéma. Chacune de ces préoccupations doit être résolue indépendamment, et le code résultant est difficile à gérer et à tester.

Lakeflow Spark Declarative Pipelines fournit l’instruction APPLY CHANGES INTO (SQL) et la fonction apply_changes() (Python), qui gèrent l’ordre, la déduplication, les événements hors ordre et l’évolution de schéma déclarativement. Vous décrivez la forme du flux de modification et de la table cible : le pipeline gère le reste. APPLY CHANGES INTO prend en charge SCD Type 1 (remplacement) et SCD Type 2 (conservation de l’historique).

Pour plus d’informations, consultez Capture de données modifiées et captures instantanées et API AUTO de capture de données modifiées : simplifiez la capture de données modifiées avec des pipelines.

Assurer la qualité des données avec des exigences

Les attentes sont des expressions SQL vraies/false appliquées à chaque ligne passant par un jeu de données. Lorsque qu'une ligne échoue à satisfaire la condition, le pipeline réagit conformément à la politique de violation que vous avez configurée. Les attentes émettent des métriques dans le journal des événements du pipeline, quelle que soit la stratégie, afin de suivre les tendances de qualité des données au fil du temps.

Choisir une stratégie de violation

Trois stratégies de violation sont disponibles. Choisissez celui qui correspond à votre tolérance pour les données incorrectes :

• avertissement (valeur par défaut) : les enregistrements non valides sont écrits dans la table cible et marqués dans les métriques. Utilisez cette stratégie lorsque vous devez capturer toutes les données, mais que vous souhaitez obtenir une visibilité sur les problèmes de qualité.
• drop : les enregistrements qui ne sont pas valides sont éliminés avant d'être écrits. Utilisez cette option lorsque des lignes incorrectes sont attendues et ne doivent pas se propager en aval.
• échec : la mise à jour du pipeline s’arrête sur le premier enregistrement non valide. Utilisez-le pour les données critiques où tout enregistrement incorrect indique un problème en amont grave.

Les exemples suivants montrent chaque stratégie appliquée à une table de diffusion en continu :

SQL

-- Warn: write invalid records but track them in metrics
CREATE OR REFRESH STREAMING TABLE orders_raw (
  CONSTRAINT valid_order_id EXPECT (order_id IS NOT NULL)
) AS SELECT * FROM STREAM read_files("/volumes/raw/orders", format => "json");

-- Drop: discard invalid records before writing
CREATE OR REFRESH STREAMING TABLE orders_clean (
  CONSTRAINT non_negative_amount EXPECT (amount >= 0) ON VIOLATION DROP ROW
) AS SELECT * FROM STREAM(orders_raw);

-- Fail: stop the pipeline on any invalid record
CREATE OR REFRESH STREAMING TABLE orders_critical (
  CONSTRAINT required_customer_id EXPECT (customer_id IS NOT NULL) ON VIOLATION FAIL UPDATE
) AS SELECT * FROM STREAM(orders_clean);

Python

from pyspark import pipelines as dp

# Warn: write invalid records but track them in metrics
@dp.table
@dp.expect("valid_order_id", "order_id IS NOT NULL")
def orders_raw():
    return spark.readStream.format("cloudFiles") \
        .option("cloudFiles.format", "json") \
        .load("/volumes/raw/orders")

# Drop: discard invalid records before writing
@dp.table
@dp.expect_or_drop("non_negative_amount", "amount >= 0")
def orders_clean():
    return spark.readStream.table("orders_raw")

# Fail: stop the pipeline on any invalid record
@dp.table
@dp.expect_or_fail("required_customer_id", "customer_id IS NOT NULL")
def orders_critical():
    return spark.readStream.table("orders_clean")

Mettre en quarantaine les enregistrements non valides

Lorsque vous souhaitez conserver les enregistrements supprimés à des fins d’investigation plutôt que de les ignorer silencieusement, utilisez un modèle de quarantaine. Acheminer les lignes qui échouent à la validation vers une table de diffusion en continu distincte à l’aide de deux flux : une qui supprime les lignes non valides de la table principale et une seconde qui écrit uniquement les lignes non valides dans une table de quarantaine. Cela vous permet d’examiner, de corriger et de retraiter les données incorrectes sans contaminer votre jeu de données propre.

Pour obtenir un exemple détaillé du modèle de quarantaine, consultez recommandations d’attente et modèles avancés.

Pour plus d’informations sur les attentes, consultez Gérer la qualité des données avec les attentes de pipeline.

Paramétrer vos pipelines

Les pipelines ont des paramètres de catalogue et de schéma par défaut, de sorte que le code qui lit et écrit dans le même catalogue et le même schéma fonctionne dans les environnements sans aucun paramètre. Toutefois, si votre pipeline doit référencer un deuxième catalogue ou schéma ( par exemple, lire à partir d’un catalogue source partagé qui diffère entre le développement et la production) évitez de coder en dur ces noms directement dans votre code source. Au lieu de cela, définissez-les en tant que paramètres de configuration de pipeline (paires clé-valeur définies dans les paramètres du pipeline) et référencez-les dans votre code. Cela permet à une base de code unique de s’exécuter correctement entre les environnements en échangeant les valeurs des paramètres.

SQL

CREATE OR REFRESH MATERIALIZED VIEW transaction_summary AS
SELECT account_id, COUNT(txn_id) AS txn_count, SUM(amount) AS total_amount
FROM ${source_catalog}.sales.transactions
GROUP BY account_id;

Python

from pyspark import pipelines as dp
from pyspark.sql.functions import count, sum

@dp.materialized_view
def transaction_summary():
    source_catalog = spark.conf.get("source_catalog")
    return spark.read.table(f"{source_catalog}.sales.transactions") \
        .groupBy("account_id") \
        .agg(
            count("txn_id").alias("txn_count"),
            sum("amount").alias("total_amount")
        )

Pour plus d’informations, consultez Utiliser des paramètres avec des pipelines.

Choisir le mode de pipeline approprié pour chaque environnement

Modes de mise à jour de développement et de production

Les pipelines s’exécutent en mode de mise à jour de développement ou de production . Choisissez le mode correspondant à votre objectif.

En mode développement, le pipeline réutilise un cluster persistant entre les mises à jour et ne réessaie pas en cas d'erreurs. Cela accélère le cycle d’itération lorsque vous créez et testez du code de pipeline, car vous obtenez immédiatement des détails d’erreur sans attendre les redémarrages du cluster.

En mode de production, le cluster s’arrête rapidement une fois chaque mise à jour terminée, ce qui réduit les coûts de calcul. Le pipeline applique également des tentatives de répétition progressives, incluant les redémarrages de cluster, pour gérer automatiquement les défaillances d’infrastructure temporaires. Utilisez le mode de production pour toutes les exécutions de pipeline planifiées.

Mode de pipeline déclenché vs continu

Le mode déclenché traite toutes les données disponibles, puis s’arrête. C'est le bon choix pour la grande majorité des pipelines : ceux qui fonctionnent selon un calendrier (horaire, quotidiennement ou à la demande) et qui ne nécessitent pas une actualisation des données à la minute près.

Le mode continu maintient l’exécution du cluster et traite les nouvelles données à mesure qu’il arrive. Il est approprié uniquement lorsque votre cas d’usage nécessite une latence dans la plage de secondes à minutes. Étant donné que le mode continu nécessite un cluster toujours actif, il est beaucoup plus coûteux que le mode déclenché.

Pour plus d’informations, consultez Le mode de pipeline déclenché et le mode de pipeline continu et Configurez les Pipelines.

Utiliser le clustering liquide pour la disposition des données

Le clustering liquide remplace le partitionnement statique pour l'optimisation de la disposition des données dans les tables Delta. Contrairement au partitionnement, ce qui vous oblige à choisir une colonne de partition avant et peut entraîner une asymétrie des données lorsque les valeurs sont inégalement distribuées, le clustering liquide est auto-paramétrable, résistant à l’asymétrie et incrémentiel , seules les données qui nécessitent une réorganisation sont réécrites sur chaque exécution.

Modifiez les colonnes de clustering à tout moment sans réécrire la table complète à mesure que les modèles de requête évoluent.

Définissez les colonnes de regroupement dans votre définition de table de streaming :

SQL

CREATE OR REFRESH STREAMING TABLE events
CLUSTER BY (event_date, region)
AS SELECT * FROM STREAM read_files("/volumes/raw/events", format => "parquet");

Python

from pyspark import pipelines as dp

@dp.table(cluster_by=["event_date", "region"])
def events():
    return spark.readStream.format("cloudFiles") \
        .option("cloudFiles.format", "parquet") \
        .load("/volumes/raw/events")

Si vous n’êtes pas sûr des colonnes à cluster, utilisez cette option CLUSTER BY AUTO pour permettre à Databricks de sélectionner automatiquement les colonnes de clustering optimales en fonction de votre charge de travail de requête.

Pour plus d’informations, consultez Tables de streaming et Utiliser le clustering liquide pour les tables.

Gérer les pipelines avec des bundles CI/CD et d'Automatisation Déclarative

Gérez la version de votre code source de pipeline et utilisez des bundles d'automatisation déclarative pour gérer les déploiements dans les environnements.

Pour plus d’informations, consultez Créer un pipeline contrôlé par la source, convertir un pipeline en projet groupé et utiliser des paramètres avec des pipelines.

Stocker le code de pipeline dans le contrôle de version

Stockez tous les fichiers sources de pipeline (Python et SQL) en même temps que votre configuration de bundle dans un dépôt Git. Le contrôle de version du projet complet vous donne un historique complet des modifications, facilite la collaboration et vous permet de valider les modifications dans un environnement de développement avant de les promouvoir en production.

Databricks recommande des bundles déclaratifs d'Automation pour la gestion de ce flux de travail. Un bundle définit votre configuration de pipeline dans YAML en même temps que votre code source, et l’interface databricks bundle CLI vous permet de valider, déployer et exécuter des pipelines à partir de votre terminal ou d’un système CI/CD.

Utiliser des cibles groupées pour l’isolation de l’environnement

Les bundles permettent plusieurs cibles (par exemple, dev, staging, prod), chacune avec son propre ensemble de remplacements des noms de catalogue, des stratégies de cluster, des adresses de notification et d’autres paramètres. Combinez des cibles groupées avec des paramètres de pipeline pour injecter les valeurs appropriées propres à l’environnement au moment du déploiement, en conservant votre code source sans constantes d’environnement.

Un flux de travail classique ressemble à ceci :

1. Un développeur travaille sur une branche de fonctionnalités, en déployant sur un pipeline de développement personnel dans un catalogue de développement.
2. Lors de la fusion vers la branche principale, le système CI exécute databricks bundle validate, puis databricks bundle deploy --target staging pour valider et déployer le pipeline dans un environnement intermédiaire.
3. Une fois les tests réussis, le système CI se déploie en production avec databricks bundle deploy --target prod.

Meilleures pratiques en matière de diffusion en continu

Utilisez ces modèles pour gérer l’état, contrôler les données tardives et maintenir les pipelines de diffusion en continu fiables.

Pour plus d’informations, consultez Optimiser le traitement stateful avec des filigranes, Récupérer un pipeline à partir d’une défaillance d’un point de contrôle de flux et Remplir des données historiques avec des pipelines.

Utilisez des filigranes pour les opérations stateful

Les filigranes délimitent l’état que le pipeline conserve en mémoire pendant les opérations de diffusion en continu à état, telles que les agrégations fenêtrées et la déduplication. Sans filigrane, l’état croît sans limite à mesure que le pipeline accumule des données pour chaque clé possible, ce qui entraîne éventuellement des erreurs de mémoire insuffisante au fil du temps sur des pipelines de longue durée.

Un filigrane spécifie une colonne d’horodatage et un seuil de tolérance pour les données tardives. Les enregistrements qui arrivent une fois le seuil dépassé sont supprimés. Choisissez un seuil qui équilibre votre tolérance pour les données tardives par rapport au coût de mémoire de la conservation de cet état ouvert.

L’exemple suivant calcule une agrégation de fenêtre de type tumbling d’une minute avec un jalon temporel de trois minutes :

SQL

CREATE OR REFRESH STREAMING TABLE event_counts AS
SELECT window(event_time, '1 minute') AS time_window, region, COUNT(*) AS cnt
FROM STREAM(events_raw)
  WATERMARK event_time DELAY OF INTERVAL 3 MINUTES
GROUP BY time_window, region;

Python

from pyspark import pipelines as dp
from pyspark.sql.functions import window

@dp.table
def event_counts():
    return (
        spark.readStream.table("events_raw")
            .withWatermark("event_time", "3 minutes")
            .groupBy(window("event_time", "1 minute"), "region")
            .count()
    )

Note

Pour vous assurer que les agrégations sont traitées de manière incrémentielle plutôt que entièrement recomputées sur chaque mise à jour, vous devez définir un filigrane.

Comprendre l’état du streaming et l’actualisation complète

L’état de streaming est incrémentiel : le pipeline génère et gère l’état entre les mises à jour plutôt que de recomputer à partir de zéro chaque fois. C’est ce qui rend la diffusion en continu avec état efficace, mais cela signifie également que si vous modifiez la logique d’une requête avec état (par exemple, en modifiant un seuil de filigrane ou en modifiant des colonnes d’agrégation), l’état existant n’est plus compatible avec la nouvelle logique. Dans ce cas, vous devez effectuer une actualisation complète pour retraiter toutes les données historiques avec la nouvelle logique et reconstruire l’état à partir de zéro.

Une actualisation complète peut également entraîner une perte de données si la source ne conserve pas les données historiques. Par exemple, une source Kafka avec une courte période de rétention peut avoir uniquement les dernières minutes de données disponibles au moment de l’actualisation, ce qui entraîne une table qui contient beaucoup moins de données qu’auparavant. Planifiez soigneusement les modifications de logique de requête avec état, en particulier pour les flux à volume élevé où une actualisation complète est coûteuse ou où la source a une conservation limitée des données. L'utilisation de l'architecture de médaillon permet de créer des tables en bronze avec une transformation minimale et permet aux tables d'argent ou d'or de recalculer à partir des tables de bronze avec un historique complet.

Jointures de flux

Les jointures de flux nécessitent un filigrane sur chaque côté de la jointure et une condition de jointure avec limite de temps. L’intervalle de temps dans la condition de jointure indique au moteur de traitement des flux quand aucune correspondance supplémentaire n’est possible, ce qui lui permet d’évincer l’état qui ne peut plus correspondre. Si vous omettez les filigranes ou la condition limitée dans le temps, l’état augmente sans limite.

L’exemple suivant joint les événements d’impression publicitaire avec des événements de clic, ce qui nécessite que le clic se produise dans un délai de trois minutes après l’impression.

SQL

CREATE OR REFRESH STREAMING TABLE impression_clicks AS
SELECT imp.ad_id, imp.impression_time, clk.click_time
FROM STREAM(ad_impressions)
    WATERMARK impression_time DELAY OF INTERVAL 3 MINUTES AS imp
JOIN STREAM(user_clicks)
    WATERMARK click_time DELAY OF INTERVAL 3 MINUTES AS clk
ON imp.ad_id = clk.ad_id
  AND clk.click_time BETWEEN imp.impression_time
    AND imp.impression_time + INTERVAL 3 MINUTES;

Python

from pyspark import pipelines as dp
from pyspark.sql.functions import expr

dp.create_streaming_table("impression_clicks")

@dp.append_flow(target="impression_clicks")
def join_impressions_and_clicks():
    impressions = spark.readStream.table("ad_impressions") \
        .withWatermark("impression_time", "3 minutes")
    clicks = spark.readStream.table("user_clicks") \
        .withWatermark("click_time", "3 minutes")
    return impressions.alias("imp").join(
        clicks.alias("clk"),
        expr("""
            imp.ad_id = clk.ad_id AND
            clk.click_time BETWEEN imp.impression_time AND imp.impression_time + INTERVAL 3 MINUTES
        """),
        "leftOuter"
    )

Lorsque vous joignez un flux à une table statique (jointure instantanée), l’instantané de la table statique est actualisé au début de chaque microbatch. Cela signifie que les enregistrements de dimension arrivant en retard ne sont pas appliqués rétroactivement aux faits déjà traités. Si l’application rétroactive est requise, utilisez une vue matérialisée ou restructurez le pipeline.

Optimiser les performances du pipeline

Appliquez ces techniques pour réduire les coûts de calcul et accélérer les mises à jour du pipeline.

Pour plus d’informations, consultez Vues matérialisées et Optimiser le traitement à états avec des filigranes.

Éviter les petits fichiers

Le déclenchement d’un pipeline trop fréquemment sur une source à faible débit génère de nombreux petits fichiers dans le stockage cloud. Les petits fichiers dégradent les performances de lecture, car chaque fichier nécessite une recherche de métadonnées et un aller-retour d’E/S distincts, et les API de stockage cloud limitent les opérations de référencement à grande échelle. Pour éviter cela, choisissez un intervalle de déclencheur qui correspond à votre volume de données : exécutez des pipelines déclenchés selon une planification qui permet à une quantité significative de données de s’accumuler entre les mises à jour, plutôt qu’en continu.

Gérer l’asymétrie des données

L’asymétrie des données se produit lorsque les valeurs d’une opération de jointure ou d’une clé groupBy sont réparties de manière inégale entre les partitions, ce qui conduit à ce qu'un petit nombre de tâches traite la majorité des données. Cela crée des points d’accès qui augmentent le temps de mise à jour de bout en bout. Utilisez le clustering liquide pour traiter l’asymétrie dans les tables stockées. Pour les asymétries qui se produisent pendant le calcul en vol, sel des clés fortement asymétriques en ajoutant un suffixe de compartiment aléatoire avant de regrouper et d’agréger en deux étapes.

Pour plus d’informations, consultez Utiliser le clustering liquide pour la disposition des données.

Utiliser l’actualisation incrémentielle pour les vues matérialisées

Lorsque vous utilisez une vue matérialisée pour une agrégation volumineuse, Lakeflow Spark Declarative Pipelines tente de l’actualiser de manière incrémentielle , en traitant uniquement les modifications en amont depuis la dernière mise à jour plutôt que de recomputer le jeu de résultats complet. L’actualisation incrémentielle est beaucoup moins coûteuse que la réexécution de la requête à partir de zéro sur chaque déclencheur de pipeline. Pour optimiser la probabilité qu’une vue matérialisée puisse être actualisée de manière incrémentielle, écrivez des requêtes d’agrégation simples et déterministes et évitez les constructions qui empêchent le traitement incrémentiel, comme les fonctions non déterministes.

Consultez Actualisation incrémentielle pour les vues matérialisées.

Optimiser les jointures

Pour les jointures où un côté est une petite table de dimension, ajoutez un indicateur de diffusion pour indiquer à Spark de diffuser la table plus petite à tous les exécuteurs au lieu d’effectuer une jointure aléatoire :

SQL

CREATE OR REFRESH MATERIALIZED VIEW enriched_orders AS
SELECT o.*, /*+ BROADCAST(p) */ p.product_name, p.category
FROM orders o
JOIN products p ON o.product_id = p.product_id;

Python

from pyspark import pipelines as dp
from pyspark.sql.functions import broadcast

@dp.materialized_view
def enriched_orders():
    orders = spark.read.table("orders")
    products = spark.read.table("products")
    return orders.join(broadcast(products), "product_id")

Pour les jointures de proximité de séries chronologiques (par exemple, trouver l’événement le plus proche dans un intervalle de temps), utilisez une condition de jointure par intervalle et assurez-vous que les deux côtés ont un filigrane si vous joignez des flux, ou envisagez de pré-trier les événements dans des compartiments temporels avant de joindre.

Surveiller vos pipelines

Le journal des événements de pipeline est la primitive d’observabilité principale dans les pipelines déclaratifs Spark Lakeflow. Chaque exécution de pipeline écrit des enregistrements structurés dans le journal des événements, couvrant la progression de l’exécution, les résultats des attentes de qualité des données, la traçabilité des données et les détails des erreurs. Le journal des événements est une table Delta que vous pouvez interroger directement.

Pour interroger le journal des événements sans connaître le chemin de stockage sous-jacent, utilisez la fonction de type table event_log() sur un cluster partagé ou un entrepôt SQL.

SELECT * FROM event_log('<pipeline-id>')
WHERE event_type = 'flow_progress'
ORDER BY timestamp DESC
LIMIT 100;

Générez des tableaux de bord de qualité des données en interrogeant le journal des événements pour obtenir les métriques attendues. La details colonne contient une structure JSON imbriquée avec des nombres pass/fail pour chaque contrainte, que vous pouvez utiliser pour suivre les tendances de qualité au fil du temps et alerter sur les régressions.

Pour les alertes pilotées par les événements, utilisez des hooks d’événements pour déclencher des webhooks personnalisés ou des services de notification (tels que Slack ou PagerDuty) lorsqu’un pipeline échoue ou lorsqu’un seuil de qualité des données est enfreint. Les hooks d’événements sont des fonctions Python qui s’exécutent en réponse aux événements de pipeline.

Pour plus d’informations, consultez Surveiller les pipelines, Journal des événements des pipelines, et Définir une surveillance personnalisée des pipelines avec des crochets d'événements.

Utiliser le calcul sans serveur

Databricks recommande le calcul serverless pour les nouveaux pipelines. Avec serverless, il n’existe aucune configuration manuelle du cluster : Databricks gère automatiquement l’infrastructure. Les pipelines serverless utilisent une mise à l’échelle automatique améliorée qui peut être mise à l’échelle horizontalement (plus d’exécuteurs) et verticalement (plus grande taille d’exécuteur) en réponse aux demandes de charge de travail. Les pipelines serverless utilisent toujours le Unity Catalog, ce qui fait que le suivi de la gouvernance et de la traçabilité sont intégrés par défaut.

Pour plus d’informations, consultez Configurer un pipeline serverless.

Organiser des pipelines avec l’architecture de médaillon

L’architecture de médaillon organise les données en trois couches logiques ( bronze, argent et or), chacune ayant un but distinct. Le mappage des types de jeux de données des pipelines déclaratifs Spark Lakeflow à la couche appropriée maintient la clarté des responsabilités de chaque couche et facilite l'entretien des pipelines.

• Bronze : utilisez des tables de streaming pour ingérer des données brutes à partir de sources de stockage cloud, de bus de messages ou de sources CDC. Les tables bronze conservent les données sources brutes avec une transformation minimale, ce qui permet aux couches d’argent ou d’or d'être retraitées depuis la source dans la couche bronze si les exigences changent.
• Silver : Utilisez des tables de diffusion en continu pour les transformations incrémentielles au niveau des lignes (filtrage, nettoyage et analyse). Utilisez des vues matérialisées lorsque la logique de la couche Silver implique des jointures d'enrichissement sur des tables de dimension ou que des agrégations complexes bénéficient d’une actualisation incrémentielle.
• Gold : utilisez des vues matérialisées pour pré-calculer des agrégations, des métriques et des résumés servis aux tableaux de bord, aux outils de création de rapports et aux consommateurs en aval.

Séparez l’ingestion (bronze) et la transformation (argent et or) en daGs de pipeline distincts dans la mesure du possible. Le découplage des couches vous permet de planifier, de surveiller et de résoudre les problèmes de chaque couche indépendamment, et une défaillance dans un pipeline de transformation ne empêche pas les nouvelles données d’atterrir en bronze.

Pour plus d’informations, consultez les tables de diffusion en continu et les vues matérialisées.