Meilleures pratiques en matière de fiabilité

Cet article décrit les bonnes pratiques en matière de fiabilité, organisées selon les principes architecturaux listés dans les sections suivantes.

1. Concevoir en anticipation des défaillances potentielles

Utilisation d’un format de données qui prend en charge les transactions ACID

Les transactions ACID sont une fonctionnalité critique pour maintenir l’intégrité et la cohérence des données. Le choix d’un format de données prenant en charge les transactions ACID permet de créer des pipelines plus simples et beaucoup plus fiables.

Delta Lake est une infrastructure de stockage open source qui fournit des transactions ACID ainsi que l’application de schémas, la gestion évolutive des métadonnées et unifie le traitement des données de diffusion en continu et par lots. Delta Lake est entièrement compatible avec les API Apache Spark et est conçu dans une optique d’intégration étroite avec la diffusion structurée en continu : vous pouvez facilement utiliser une seule copie de données à la fois pour les opérations de traitement par lots et les opérations de diffusion en continu, avec les avantages d’un traitement incrémentiel à grande échelle.

Utilisation d’un moteur de données distribué résilient pour toutes les charges de travail

Apache Spark, en tant que moteur de calcul du lakehouse Azure Databricks, est basé sur un traitement de données distribué résilient. Si une tâche interne de Spark ne retourne pas de résultat comme prévu, Apache Spark replanifie automatiquement les tâches manquantes et continue d’exécuter l’intégralité du travail. Ceci est utile pour les défaillances hors code, telles qu’un bref problème de réseau ou une VM spot révoquée. En travaillant à la fois avec l’API SQL et l’API Spark DataFrame, cette résilience est intégrée dans le moteur.

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

Récupération automatique des données non valides ou non conformes

Des données non valides ou non conformes peuvent provoquer des incidents de charges de travail qui s’appuient 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 non valides et non conformes lors de l’ingestion. La prise en charge des données récupérées garantit de ne pas perdre ou de ne jamais manquer de données lors de l’ingestion ou de l’opération ETL. La colonne des données récupérées contient toutes les données qui n’ont pas été analysées, soit parce qu’elles étaient absentes du schéma donné, soit en raison d’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 diffuser en continu 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 sauvées contient toutes les données qui n’ont pas été analysées, probablement parce qu’elles étaient absentes du schéma donné, en raison d’une incompatibilité de type, ou parce que la casse de la colonne ne correspondait pas. La colonne de données sauvées fait partie du schéma qu’Auto Loader retourne par défaut en tant que _rescued_data lors de l’inférence du schéma.
• Delta Live Tables : une autre option pour créer des flux de travail pour la résilience consiste à utiliser Delta Live Tables avec des contraintes de qualité. Consultez Gérer la qualité des données avec Delta Live Tables. Delta Live Tables prend en charge trois modes intégrés : conserver, déposer et échouer sur les enregistrements non valides. 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. Consultez Mettre en quarantaine des données non valides.

Configurer des travaux pour des tentatives et un arrêt automatiques

Les systèmes distribués sont complexes et une défaillance peut potentiellement se répercuter dans tout le système.

• Les travaux Azure Databricks prennent en charge des stratégies de nouvelles tentatives pour les tâches qui déterminent quand et combien de fois les exécutions ayant échoué sont retentées. Consultez Définir une stratégie de nouvelles tentatives.
• Vous pouvez configurer des seuils de durée facultatifs pour une tâche, notamment une heure d'achèvement prévue pour la tâche et une durée d'exécution maximale pour la tâche.
• Delta Live Tables automatise également la récupération après défaillance à l’aide de tentatives croissantes pour équilibrer vitesse et fiabilité. Consultez Modes de développement et de production.

En revanche, une tâche en attente peut empêcher l’achèvement de l’ensemble du travail, entraînant des coûts élevés. Les travaux Databricks prennent en charge le configuration du délai d’expiration pour arrêter les tâches qui prennent plus de temps que prévu.

Utilisation d’une infrastructure de mise en service de modèles évolutive et de niveau production

Pour l’inférence par lots et en diffusion en continu, utilisez les travaux Azure Databricks et MLflow pour déployer des modèles en tant que fonctions définies par l’utilisateur Apache Spark afin de tirer parti de la planification des travaux, 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 lots.

La mise en service de modèles fournit une infrastructure évolutive et de niveau production pour la mise en service de modèles en temps réel. Il traite vos modèles Machine Learning à l’aide de MLflow et les expose sous forme de points de terminaison d’API REST. Cette fonctionnalité utilise le calcul serverless, ce qui signifie que les points de terminaison et les ressources de calcul associées sont gérés et exécutés dans le compte cloud Azure Databricks.

Utiliser des services managés lorsque cela est possible

Tirez parti des services managés (calcul serverless) à partir de la plateforme Databricks Data Intelligence, tels que :

• Entrepôts SQL serverless
• Mise en service de modèles
• travaux serverless
• Calcul serverless pour les notebooks
• Delta Live Tables

Ces services sont gérés par Databricks de manière fiable et évolutive sans coût supplémentaire pour le client, rendant les charges de travail plus fiables.

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

Utiliser une architecture de stockage multicouches

Organisez les données en créant une architecture multicouches et en veillant à ce que la qualité des données augmente à mesure qu’elles transitent par les couches. Il est courant d’utiliser une approche multicouches telle que décrite ci-dessous :

• 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 selon les besoins.
• Couche organisée (argent) : l’objectif 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 le reporting sur l’ensemble des rôles et fonctions.
• Couche finale (or) : la troisième couche est construite autour des besoins de l’entreprise ou du projet. Elle fournit une vue différente en tant que produits de données pour d’autres unités commerciales ou projets, en préparant les données autour des besoins de sécurité (comme les données anonymisées) ou en optimisant les performances (par exemple avec des vues pré-agrégées). Les produits de données de cette couche sont considérés comme la vérité pour l’entreprise.

La couche finale doit contenir uniquement des données de haute qualité et être entièrement approuvée du point de vue de l’entreprise.

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

La copie ou la duplication de données crée une redondance des données et entraîne une perte d’intégrité, une perte de traçabilité des données et souvent des autorisations d’accès différentes. Cela diminue la qualité des données dans le lakehouse.

Une copie temporaire ou jetable de données n’est pas dangereuse en soi : elle est parfois nécessaire pour augmenter 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 ne sont plus synchronisés, cela a un impact négatif significatif sur l’intégrité et la qualité des données, ce qui soulève des questions telles que « Quel est le jeu de données principal ? » ou « Le jeu de données est-il à jour ? ».

Gérer activement les schémas

Les modifications de schéma non contrôlées peuvent entraîner des données non valides et des travaux défaillants qui utilisent ces jeux de données. Azure Databricks dispose de plusieurs méthodes pour valider et appliquer le schéma :

• Delta Lake prend en charge la validation et l’application du schéma en gérant automatiquement les variations de schéma pour empêcher l’insertion d’enregistrements incorrects pendant l’ingestion. Consultez Application du schéma.
• Auto Loader détecte l’ajout de nouvelles colonnes lors du traitement de vos données. Par défaut, l’ajout d’une nouvelle colonne entraîne l’arrêt de vos streams avec une UnknownFieldException. Auto Loader prend en charge plusieurs modes pour l’évolution du schéma.

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 la vérification automatique de la qualité et de l’intégrité des données ajoutées à une table. En cas de violation d’une contrainte, Delta Lake envoie une erreur InvariantViolationException pour signaler que les nouvelles données ne peuvent pas être ajoutées. Consultez Contraintes sur Azure Databricks.

Pour améliorer davantage cette gestion, Delta Live Tables 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 sur les requêtes utilisent des décorateurs Python ou des clauses de contrainte SQL. Consultez Gérer la qualité des données avec Delta Live Tables.

Adopter une approche centrée sur les données de l’apprentissage automatique

Un principe directeur qui reste au cœur de la vision de l’IA pour la plateforme Databricks Data Intelligence est une approche centrée sur les données pour l’apprentissage automatique. À mesure que l’IA générative devient plus répandue, cette perspective reste tout aussi importante.

Les composants principaux de tout projet d’apprentissage automatique peuvent simplement être considérés comme des pipelines de données : l’ingénierie des caractéristiques, l’entraînement, le modèle de déploiement, l’inférence et les pipelines de surveillance sont tous les pipelines de données. Ainsi, l’opérationnalisation d’une solution d’apprentissage automatique nécessite la fusion de données à partir de tables de prédiction, de surveillance et de caractéristiques avec d’autres données pertinentes. Fondamentalement, le moyen le plus simple d’y parvenir consiste à développer des solutions basées sur l’intelligence artificielle sur la même plateforme utilisée pour gérer les données de production. Veuillez consulter MLOps et LLMOps centrés sur les données

3. Conception pour la mise à l’échelle automatique

Activation de la mise à l’échelle automatique pour les charges de travail ETL

La mise à l’échelle automatique permet aux clusters de se redimensionner automatiquement en fonction des charges de travail. La mise à l’échelle automatique peut être bénéfique à de nombreux cas d’usage et scénarios, tant du point de vue des coûts que des performances. La documentation fournit les éléments à prendre en considération pour déterminer s’il faut utiliser la mise à l’échelle automatique et comment en tirer le meilleur parti.

Pour les charges de travail, Databricks recommande d’utiliser Delta Live Tables avec mise à l’échelle. La mise à l’échelle automatique améliorée Databricks optimise l’utilisation du cluster 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 la mise à l’échelle automatique pour l’entrepôt SQL

Le paramètre de mise à l’échelle d’un entrepôt SQL définit le nombre minimal et maximal de clusters sur lesquels les requêtes envoyées à l’entrepôt sont distribuées. La valeur par défaut est un cluster unique sans mise à l’échelle automatique.

Pour gérer davantage d’utilisateurs simultanés pour un entrepôt donné, augmentez le nombre de clusters. Pour savoir comment Azure Databricks ajoute des clusters à un entrepôt et supprime des clusters, consultez Comportement de dimensionnement, de mise à l’échelle et de mise en file d’attente de l’entrepôt SQL.

4. Test des procédures de récupération

Récupération d’échecs de requête de Structured Streaming

Structured Streaming assure une tolérance de panne et la cohérence des données pour les requêtes de diffusion en continu. À l’aide de Databricks Jobs, vous pouvez facilement configurer vos requêtes Structured Streaming pour redémarrer automatiquement en cas d’échec. En activant la création de point de contrôle pour une requête de diffusion en continu, vous pouvez redémarrer la requête suite à un échec. La requête redémarrée reprendra là où la requête échouée s’est arrêtée. Consultez Points de contrôle Structured Streaming et Considérations relatives à la production pour Structured Streaming.

Récupération des travaux ETL en utilisant les capacités de voyage dans le temps des données

Malgré des tests approfondis, un travail en production peut échouer ou produire des données inattendues, voire non valides. Parfois, cela peut être résolu avec un travail supplémentaire après avoir compris la source du problème et corrigé le pipeline qui a causé le problème en premier lieu. Cependant, cela n’est souvent pas simple et le travail en question devrait être annulé. L’utilisation du voyage dans le temps Delta permet aux utilisateurs de restaurer facilement les modifications apportées à une version antérieure ou à un horodatage, de réparer le pipeline et de redémarrer le pipeline corrigé.

Une façon pratique de le faire est la commande RESTORE.

Tirer profit d’un cadre d’automatisation des tâches avec récupération intégrée

Les Travaux Databricks sont conçus pour la récupération. Lorsqu’une tâche dans un travail multitâches échoue (et, par conséquent, toutes les tâches dépendantes), les Travaux Azure Databricks fournissent une vue matricielle des exécutions qui vous permet d’enquêter sur le problème ayant causé l’échec. Veuillez consulter Afficher les exécutions d’un travail. Qu’il s’agisse d’un problème de réseau court ou d’un problème réel dans les données, vous pouvez le résoudre et démarrer une exécution de réparation dans Travaux Azure Databricks. Il exécutera uniquement les tâches échouée 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. Veuillez consulter Résoudre les problèmes et réparer les échecs de travaux

Configurer un modèle de récupération d’urgence

Pour une plateforme d’analyse de données native du cloud, comme Azure Databricks, un modèle de récupération d’urgence clair est essentiel. Il est crucial que vos équipes de données puissent utiliser la plateforme Azure Databricks même dans le cas rare d’une panne régionale et généralisée d’un fournisseur de service cloud, qu’elle soit causée par une catastrophe régionale telle qu’un ouragan, un tremblement de terre ou une autre source.

Azure Databricks est souvent un élément fondamental d’un écosystème de données global qui inclut de nombreux services, notamment les services d’ingestion de données en amont (traitement par lots/diffusion en continu), le stockage natif cloud tel que Azure Data Lake Storage Gen2, les outils et services en aval tels que des applications décisionnelles et les outils d’orchestration. Certains de vos utilisations peuvent être particulièrement sensibles à une panne de service régionale.

La récupération d’urgence implique un ensemble de stratégies, d’outils et de procédures qui permettent la récupération ou la poursuite de l’infrastructure et des systèmes de la technologie vitale suite à une catastrophe naturelle ou humaine. Un service cloud de grande taille, tel qu’Azure, est utilisé par de nombreux clients et intègre des protections contre une défaillance unique. Par exemple, une région est un groupe de bâtiments connectés à différentes sources d’alimentation pour garantir qu’une seule panne de courant ne mettra pas une région hors service. Cependant, les défaillances de région cloud peuvent se produire et la gravité de la défaillance ainsi que son impact sur votre entreprise peuvent varier.

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

Veuillez consulter Excellence opérationnelle : automatiser les déploiements et les charges de travail.

6. Surveillance des systèmes et des charges de travail

Veuillez consulter Excellence opérationnelle : configurer la surveillance, les alertes et la journalisation.