Aller au contenu principal
Dernière mise à jour le

Bonnes pratiques pour la fiabilité

Ces bonnes pratiques vous aident à concevoir sur Databricks des systèmes qui se rétablissent après une défaillance et continuent de fonctionner, organisés selon les principes architecturaux présentés dans les sections suivantes.

1. Concevez pour la défaillance.​

Utilisez un format de données qui prend en charge les transactions ACID​

Les transactions ACID sont une fonctionnalité essentielle pour maintenir l'intégrité et la cohérence des données. Choisir un format de données qui prend en charge les Transactions ACID permet de créer des pipelines plus simples et beaucoup plus fiables.

Delta Lake est un framework de stockage open source qui fournit des transactions ACID ainsi que l'application des schémas, la gestion évolutive des métadonnées, et unifie le traitement des données en streaming et par batch. Delta Lake est entièrement compatible avec les APIs Apache Spark et est conçu pour une intégration étroite avec le streaming structuré, vous permettant d'utiliser facilement une seule copie de données pour les opérations batch et streaming, et de fournir un traitement incrémentiel à l'échelle.

Utilisez un moteur de données distribué résilient pour toutes les charges de travail​

Apache Spark, en tant que moteur de compute de Databricks, est basé sur un traitement distribué résilient des données. Si une tâche Spark interne ne renvoie pas de résultat comme prévu, Apache Spark replanifie automatiquement les tâches manquantes et continue à exécuter l'intégralité du Job. Ceci est utile pour les défaillances hors code, telles qu'un bref problème réseau ou une machine virtuelle Spot révoquée. En utilisant à la fois l'API SQL et l'API Spark DataFrame, cette résilience est intégrée au moteur.

Dans la plateforme Databricks, Photon, un moteur vectorisé natif entièrement écrit en C++, est un compute haute performance compatible avec les API Apache Spark.

Sauver automatiquement les données invalides ou non conformes​

Des données non valides ou non conformes peuvent entraîner le plantage des charges de travail qui reposent sur un format de données établi. Pour augmenter la résilience de bout en bout de l'ensemble du processus, il est recommandé de filtrer les données invalides et non conformes dès l'ingestion. La prise en charge des données récupérées garantit que vous ne perdez ni ne manquez jamais de données lors de l'ingestion ou de l'ETL. La colonne de données récupérées contient toutes les données qui n'ont pas été analysées, soit parce qu'elles étaient manquantes dans le schéma donné, soit parce qu'il y avait une incompatibilité de type, soit parce que le corps de la colonne dans l'enregistrement ou le fichier ne correspondait pas à celui du schéma.

  • Databricks Auto Loader : Auto Loader est l'outil idéal pour le streaming de l'ingestion de fichiers. Il prend en charge les données récupérées pour JSON et CSV. Par exemple, pour JSON, la colonne de données récupérées contient toutes les données qui n'ont pas été analysées, possiblement parce qu'elles étaient manquantes du schéma donné, parce qu'il y avait un décalage de type ou parce que la casse de la colonne ne correspondait pas. La colonne de données récupérées fait partie du schéma retourné par Auto Loader comme _rescued_data par default lorsque le schéma est inféré.

  • Pipelines : une autre option pour créer des workflows pour la résilience consiste à utiliser les Lakeflow pipelines avec des contraintes de qualité. Consultez Gérer la qualité des données avec les attentes de pipeline. Lakeflow pipelines support three modes by default: retain, drop, and fail on invalid records. Pour mettre en quarantaine les enregistrements non valides identifiés, les règles d’attente peuvent être définies d’une manière spécifique afin que les enregistrements non valides soient stockés (« mis en quarantaine ») dans une autre table. Voir Mettre en quarantaine les enregistrements non valides.

Configurez les Jobs pour les nouvelles tentatives automatiques et la terminaison.​

Les systèmes distribués sont complexes, et une défaillance à un moment donné peut potentiellement se propager dans tout le système.

D'autre part, une tâche bloquée peut empêcher l'achèvement de l'intégralité du Job, entraînant des coûts élevés. Lakeflow Jobs prend en charge la configuration de délai d'expiration pour arrêter les Jobs qui prennent plus de temps que prévu.

Utiliser une infrastructure évolutive de service de modèles de niveau production​

Pour l'inférence par batch et en streaming, utilisez Lakeflow Jobs et MLflow pour déployer des modèles en tant que fonctions UDF Apache Spark afin de tirer parti de la planification des Jobs, des nouvelles tentatives, de la mise à l'échelle automatique, etc. Consultez Déployer des modèles pour l'inférence et la prédiction par batch.

Le service de modèles fournit une infrastructure évolutive et de qualité production pour le service de modèles en temps réel. Il traite vos modèles de machine learning à l'aide de MLflow et les expose sous forme d'endpoints API REST. Cette fonctionnalité utilise le compute Serverless, ce qui signifie que les endpoints et les ressources de compute associés sont gérés et exécutés dans le compte cloud Databricks.

Utilisez les services gérés si possible​

Tirez parti des services gérés (serverless compute) de la Databricks Data Intelligence Platform, tels que :

Ces services sont exploités par Databricks de manière fiable et évolutive, rendant les charges de travail plus fiables.

2. Gérer la qualité des données​

Utiliser une architecture de stockage en couches​

Organiser les données en créant une architecture en couches et en garantissant que la qualité des données augmente à mesure que les données traversent les couches. Ce modèle est connu sous le nom d'architecture en médaillon. Une approche de superposition courante est :

  • Couche brute (bronze) : les données sources sont ingérées dans le lakehouse dans la première couche et doivent y être conservées. Lorsque toutes les données en aval sont créées à partir de la couche brute, il est possible de reconstruire les couches suivantes à partir de cette couche, si nécessaire. Utilisez des tables externes pour les données de la couche bronze afin de préserver les données brutes, même si les tables sont supprimées.
  • **Couche organisée (Silver) :** Le but de la deuxième couche est de contenir des données nettoyées, affinées, filtrées et agrégées. L'objectif de cette couche est de fournir une base solide et fiable pour l'analyse et la création de rapports dans tous les rôles et fonctions. Utilisez des tables gérées avec application des schémas et des contrôles de qualité des données.
  • Dernière couche (Gold) : la troisième couche est conçue en fonction des besoins de l'entreprise ou du projet. Il fournit une vue différente sous forme de produits de données à d'autres unités commerciales ou projets, en préparant les données en fonction des besoins de sécurité (tels que les données anonymisées) ou en les optimisant pour les performances (tels que les vues pré-agrégées). Les produits de données de cette couche sont considérés comme la source de vérité pour l'entreprise. Utiliser des tables gérées avec validation de la logique métier et garanties SLA.

La couche finale ne devrait contenir que des données de haute qualité et être entièrement fiable d'un point de vue commercial.

Considérations de mise en œuvre :

  • Utilisez les schémas Unity Catalog pour organiser les couches bronze, silver et Gold (par exemple, sales.bronze_transactions, sales.silver_transactions, sales.gold_metrics).
  • Configurez les propriétés des tables Delta Lake, telles que delta.enableChangeDataFeed, pour suivre les modifications entre les couches.
  • Activer l'optimisation automatique pour maintenir des tailles de fichier optimales à mesure que les données progressent à travers les couches
  • Implémentez le traitement incrémental à l'aide de Delta Live Tables ou de Structured Streaming pour des mises à jour efficaces des couches.
  • Établissez des attentes claires en matière de qualité des données à chaque limite de couche

Pour obtenir des conseils détaillés sur la mise en œuvre de l'architecture en médaillon, consultez Concevoir une architecture en médaillon.

Améliorer l'intégrité des données en réduisant la redondance des données​

La copie ou la duplication des données crée une redondance des données et entraîne une perte d'intégrité, une perte de data lineage et souvent des autorisations d'accès différentes. Cela réduit la qualité des données dans Databricks.

Une copie temporaire ou jetable de données n'est pas nocive en soi – elle est parfois nécessaire pour accroître l'agilité, l'expérimentation et l'innovation. Cependant, lorsque ces copies deviennent opérationnelles et sont régulièrement utilisées pour prendre des décisions commerciales, elles deviennent des silos de données. Lorsque ces silos de données sont désynchronisés, cela a un impact négatif significatif sur l'intégrité et la qualité des données, soulevant des questions telles que « Quel jeu de données est le maître ? » ou « Le jeu de données est-il actuel ? »

Gérez activement les schémas​

Des modifications de schéma non contrôlées peuvent entraîner des données non valides et des jobs en échec qui utilisent ces jeux de données. Databricks dispose de plusieurs méthodes pour valider et appliquer le schéma :

  • Delta Lake prend en charge la validation et l'application des schémas en gérant automatiquement les variations de schémas pour empêcher l'insertion d'enregistrements incorrects pendant l'ingestion. See application des schémas.
  • Auto Loader détecte l'ajout de nouvelles colonnes lorsqu'il traite vos données. Par default, l'ajout d'une nouvelle colonne entraîne l'arrêt de vos Stream avec un UnknownFieldException. Auto Loader prend en charge plusieurs modes pour l'évolution des schémas.

Utiliser les contraintes et les attentes en matière de données​

Les tables Delta prennent en charge les clauses de gestion des contraintes SQL standard qui garantissent que la qualité et l'intégrité des données ajoutées à une table sont automatiquement vérifiées. Lorsqu'une contrainte est violée, Delta Lake génère une erreur InvariantViolationException pour signaler que les nouvelles données ne peuvent pas être ajoutées. Consultez les contraintes sur Databricks.

Pour améliorer davantage cette gestion, Lakeflow pipelines prend en charge les attentes : les attentes définissent des contraintes de qualité des données sur le contenu d'un jeu de données. Une attente se compose d'une description, d'un invariant et d'une action à entreprendre si un enregistrement viole l'invariant. Les attentes concernant les requêtes utilisent des décorateurs Python ou des clauses de contrainte SQL. Consultez Gérer la qualité des données avec les attentes des pipelines.

Adoptez une approche centrée sur les données du Machine Learning​

Un principe directeur qui reste au cœur de la vision de l'IA pour la Databricks Data Intelligence Platform est une approche axée sur les données du Machine Learning. À mesure que l'IA générative se généralise, cette perspective reste tout aussi importante.

Les composants fondamentaux de tout projet ML peuvent simplement être considérés comme des pipelines de données : l'ingénierie des features, la formation, le déploiement de modèles, l'inférence et les pipelines de monitoring sont tous des pipelines de données. Ainsi, l'opérationnalisation d'une solution ML nécessite la fusion des données des tables de prédiction, de monitoring et de features avec d'autres données pertinentes. Fondamentalement, le moyen le plus simple d'y parvenir est de développer des solutions basées sur l'IA sur la même plateforme que celle utilisée pour gérer les données de production. Voir MLOps et LLMOps centrées sur les données

3. Concevoir le dimensionnement automatique​

Activer la mise à l'échelle automatique pour les charges de travail ETL​

Le dimensionnement automatique permet aux clusters de se redimensionner automatiquement en fonction des charges de travail. Le dimensionnement automatique peut bénéficier à de nombreux cas d'utilisation et scénarios, tant du point de vue des coûts que des performances. La documentation fournit des considérations pour déterminer s'il convient d'utiliser le dimensionnement automatique et comment en tirer le meilleur parti.

Pour les charges de travail de streaming, Databricks recommande d'utiliser les LakeFlow Pipelines avec autoscaling. L'autoscaling amélioré de Databricks optimise l'utilisation des clusters en allouant automatiquement des Ressources de cluster en fonction du volume de charge de travail, avec un impact minimal sur la latence de traitement des données de vos pipelines.

Activer le dimensionnement automatique pour le SQL Warehouse​

Le paramètre de mise à l'échelle d'un SQL Warehouse définit le nombre minimum et maximum de clusters sur lesquels les queries envoyées au warehouse sont distribuées. The default est un seul cluster sans mise à l'échelle automatique.

Pour gérer plus d'utilisateurs simultanés pour un given warehouse, augmentez le nombre de clusters. Pour savoir comment Databricks ajoute et supprime des clusters d'un warehouse, consultez Dimensionnement, mise à l'échelle et comportement de file d'attente du SQL Warehouse.

4. Testez les procédures de récupération​

Récupérer des défaillances de query Structured Streaming​

Structured Streaming offre une tolérance aux pannes et une cohérence des données pour les query de streaming. Avec Lakeflow Jobs, vous pouvez facilement configurer vos querys Structured Streaming pour qu’elles redémarrent automatiquement en cas de défaillance. En activant les points de contrôle pour une query de streaming, vous pouvez redémarrer la query après une défaillance. La query redémarrée reprend là où la query ayant échoué s’était arrêtée. Consultez les points de contrôle Structured Streaming et les considérations de production pour Structured Streaming.

Récupérez les jobs ETL à l'aide des capacités de data time travel​

Malgré des tests approfondis, un job peut échouer en production ou produire des données inattendues, voire invalides. Cela peut parfois être résolu par un Job supplémentaire après avoir compris l'origine du problème et corrigé le pipeline qui a initialement causé le problème. Cependant, ce n'est souvent pas simple et le job en question devrait être annulé. Grâce au time travel Delta, les utilisateurs peuvent facilement annuler les modifications vers une version ou un timestamp plus ancien, réparer le pipeline et redémarrer le pipeline corrigé.

Un moyen pratique de le faire est la commande RESTORE.

Tirez parti d'un framework d'automatisation de Jobs avec récupération intégrée​

Les Lakeflow Jobs sont conçus pour la récupération. Lorsqu’une tâche dans un job multi-tâches échoue (et, de ce fait, toutes les tâches dépendantes), les jobs fournissent une vue matricielle des exécutions qui vous permet d’examiner le problème à l’origine de l’échec. Consultez Afficher les exécutions pour un seul job. Qu'il s'agisse d'un court problème de réseau ou d'un problème réel dans les données, vous pouvez le corriger et start une exécution de réparation dans Lakeflow Jobs. Il exécutera uniquement les tâches échouées et dépendantes et conservera les résultats réussis de l’exécution précédente, ce qui permet d’économiser du temps et de l’argent. Consultez Dépanner et réparer les échecs de job.

Configurer la haute disponibilité et la reprise après sinistre​

Mettre en œuvre des stratégies de haute disponibilité​

Concevez votre déploiement Databricks pour une haute disponibilité afin de minimiser les temps d'arrêt et d'assurer la continuité des activités :

Haute disponibilité du plan de contrôle : Databricks fournit un SLA de 99,9 % pour le plan de contrôle sans nécessiter de configuration côté client. Le plan de contrôle est déployé automatiquement dans plusieurs zones de disponibilité.

Haute disponibilité du compute : Déployez les nœuds de cluster sur plusieurs zones de disponibilité en fournissant des sous-réseaux dans différentes zones. Databricks distribue automatiquement les nœuds pour la tolérance aux pannes. Configurez les tentatives de nouvelle exécution du Job pour récupérer automatiquement des défaillances transitoires.

Haute disponibilité du stockage : utilisez les options de redondance du fournisseur cloud (ZRS sur Azure, réplication multi-AZ sur AWS/GCP) pour vous protéger contre les défaillances zonales.

Haute disponibilité réseau : Déployez l'infrastructure réseau (sous-réseaux, passerelles NAT, connexions VPN) sur plusieurs zones de disponibilité pour éliminer les points de défaillance uniques.

Pour des conseils de déploiement sur la configuration HA, consultez Phase 10 : Concevoir la haute disponibilité et la reprise après sinistre.

Configurez un modèle de reprise après sinistre​

Pour une plateforme d'analytique de données cloud natif comme Databricks, un modèle clair de reprise après sinistre est essentiel. Il est essentiel que vos équipes de données puissent utiliser la plateforme Databricks même dans le cas rare d'une panne régionale à l'échelle du service d'un fournisseur de services cloud, qu'elle soit causée par une catastrophe régionale telle qu'un ouragan, un tremblement de terre ou une autre source.

Databricks est souvent un élément central d'un écosystème de données global qui inclut de nombreux services, notamment des services d'ingestion de données en amont (batch/streaming), un stockage cloud natif tel qu'Amazon S3, des outils et services en aval tels que les applications de Business Intelligence, et des outils d'orchestration. Certains de vos cas d’utilisation peuvent être particulièrement sensibles à une panne de service régionale.

La reprise après sinistre implique un ensemble de politiques, d'outils et de procédures qui permettent la récupération ou la continuation d'infrastructures et de systèmes vitaux de Technologie suite à une catastrophe naturelle ou d'origine humaine. Un service cloud étendu tel qu'AWS sert de nombreux clients et dispose de protections intégrées contre une défaillance unique. Par exemple, une région est un groupe de bâtiments connectés à différentes sources d'énergie pour s'assurer qu'une seule panne de courant ne fera pas tomber une région. Cependant, des défaillances de région cloud peuvent survenir, et la gravité de la défaillance et son impact sur votre entreprise peuvent varier.

**Implémentation de la reprise après sinistre** :

  • Définissez l'objectif de temps de récupération (RTO) et l'objectif de point de récupération (RPO) pour votre organisation.
  • Utilisez l'infrastructure en tant que code (Terraform, Bundles d'actifs) pour reconstruire rapidement les Workspaces dans une région de reprise d'activité.
  • Répliquer les métadonnées Unity Catalog à l'aide des procédures de sauvegarde et d'importation de métastores.
  • Implémentez la réplication de table Delta vers la région DR à l'aide de DEEP CLONE pour les datasets critiques.
  • Configurez la réplication du stockage du fournisseur de cloud pour la réplication automatique des données.
  • Testez régulièrement les procédures de reprise après sinistre pour garantir la préparation et affiner les processus de récupération.

Pour obtenir des conseils de configuration de DR étape par étape, consultez Phase 10 : conception de la haute disponibilité et de la reprise après sinistre.

5. Automatiser les déploiements et les charges de travail.​

Consulter Excellence opérationnelle - Automatiser les déploiements et les charges de travail.

6. Surveiller les systèmes et les charges de travail​

Consultez Excellence opérationnelle - Configurer le monitoring, les alertes et la journalisation.

Sur cette page