Transformer les données
Cet article fournit une présentation et une vue d’ensemble de la transformation des données avec Azure Databricks. La transformation des données, ou la préparation des données, est l’étape clé de toutes les charges de travail d’engineering données, d’analytique et de Machine Learning.
Les exemples de modèles et les recommandations de cet article se concentrent sur l’utilisation des tables lakehouse, qui sont prises en charge par Delta Lake. Étant donné que Delta Lake fournit les garanties ACID d’un lakehouse Databricks, vous pouvez observer un comportement différent lors de l’utilisation de données dans d’autres formats ou systèmes de données.
Databricks recommande d’ingérer des données dans un lakehouse dans un état brut ou presque brut, puis d’appliquer des transformations et de l’enrichissement en tant qu’étape de traitement distincte. Ce modèle est appelé architecture de médaillon. Consultez Qu’est-ce que l’architecture de médaillon dans un lakehouse ?.
Si vous savez que les données que vous devez transformer n’ont pas encore été chargées dans un lakehouse, consultez Ingérer des données dans un lakehouse Databricks. Si vous essayez de rechercher des données lakehouse pour écrire des transformations, consultez Découvrir des données.
Toutes les transformations commencent par l’écriture d’une requête par lot ou de flux de données sur une source de données. Si vous n’êtes pas familiarisé avec l’interrogation des données, consultez Interroger des données.
Une fois que vous avez enregistré des données transformées dans une table Delta, vous pouvez utiliser cette table comme table de caractéristiques pour le Machine Learning. Consultez Ingénierie de caractéristiques et service.
Remarque
Ces articles traitent des transformations sur Azure Databricks. Azure Databricks prend également en charge les connexions à de nombreuses plateformes de préparation des données courantes. Consultez Se connecter à des partenaires de préparation des données à l’aide de Partner Connect.
Transformations Spark et transformations lakehouse
Cet article se concentre sur la définition des transformations en relation avec le T dans ETL ou ELT. Le modèle de traitement Apache Spark utilise également le mot transformation de manière similaire. En bref : dans Apache Spark, toutes les opérations sont définies comme des transformations ou des actions.
- Transformations : ajoutent une logique de traitement au plan. Les exemples incluent la lecture de données, les jointures, les agrégations et la conversion de type.
- Actions : déclenchent la logique de traitement pour évaluer et générer un résultat. Les exemples incluent les écritures, l’affichage ou l’aperçu des résultats, la mise en cache manuelle ou l’obtention du nombre de lignes.
Apache Spark utilise un modèle d’exécution différé, ce qui signifie qu’aucune logique définie par une collection d’opérations n’est évaluée tant qu’une action n’est pas déclenchée. Ce modèle a une conséquence importante lors de la définition de pipelines de traitement des données : utilisez uniquement des actions pour enregistrer les résultats dans une table cible.
Étant donné que les actions représentent un goulot d’étranglement de traitement pour optimiser la logique, Azure Databricks a ajouté de nombreuses optimisations en plus de celles déjà présentes dans Apache Spark pour garantir une exécution optimale de la logique. Ces optimisations prennent en compte toutes les transformations déclenchées par une action donnée à la fois et trouvent le plan optimal sur la base de la disposition physique des données. La mise en cache manuelle des données ou le renvoi des résultats dans les pipelines de production peut interrompre ces optimisations et entraîner une augmentation significative des coûts et de la latence.
Par conséquent, nous pouvons définir une transformation lakehouse comme tout ensemble d’opérations appliquées à une ou plusieurs tables lakehouse et aboutissant à une nouvelle table lakehouse. Bien que les transformations telles que les jointures et les agrégations soient abordées séparément, vous pouvez combiner plusieurs de ces modèles en une seule étape de traitement et faire confiance aux optimiseurs d’Azure Databricks pour trouver le plan le plus efficace.
Quelles sont les différences entre le traitement des flux de données et le traitement par lots ?
Bien que le traitement des flux de données et le traitement par lots utilisent en grande partie la même syntaxe sur Azure Databricks, ils ont chacun leur propre sémantique.
Le traitement par lots vous permet de définir des instructions explicites pour traiter en une seule opération une quantité fixe de données statiques et immuables.
Le traitement de flux de données vous permet de définir une requête sur un jeu de données non lié, en croissance continue, puis de traiter les données en petits lots incrémentiels.
Les opérations par lots sur Azure Databricks utilisent Spark SQL ou DataFrames, tandis que le traitement de flux de données tire parti de Structured Streaming.
Vous pouvez différencier les commandes Apache Spark par lots de Structured Streaming en examinant les opérations de lecture et d’écriture, comme indiqué dans le tableau suivant :
| Apache Spark | Structured Streaming | |
|---|---|---|
| Lire | spark.read.load() |
spark.readStream.load() |
| Écrire | spark.write.save() |
spark.writeStream.start() |
Les vues matérialisées sont généralement conformes aux garanties de traitement par lots, bien que Delta Live Tables est utilisé pour calculer les résultats de manière incrémentielle lorsque cela est possible. Les résultats retournés par une vue matérialisée sont toujours équivalents à l’évaluation par lots de la logique, mais Azure Databricks cherche à traiter ces résultats de manière incrémentielle lorsque cela est possible.
Les tables de diffusion en continu calculent toujours les résultats de manière incrémentielle. Étant donné que de nombreuses sources de données de diffusion en continu ne conservent les enregistrements que pendant quelques heures ou quelques jours, le modèle de traitement utilisé par les tables de diffusion en continu suppose que chaque lot d’enregistrements d’une source de données n’est traité qu’une seule fois.
Azure Databricks prend en charge l’utilisation de SQL pour écrire des requêtes de diffusion en continu dans les cas d’usage suivants :
- Définition de tables de diffusion en continu dans le catalogue Unity à l’aide de Databricks SQL.
- Définition du code source pour les pipelines Delta Live Tables.
Remarque
Vous pouvez également déclarer des tables de diffusion en continu dans Delta Live Tables à l’aide du code Python Structured Streaming.
Transformations par lots
Les transformations par lots fonctionnent sur un ensemble bien défini de ressources de données à un moment spécifique. Les transformations par lots peuvent être des opérations ponctuelles, mais font souvent partie de travaux planifiés ou de pipelines qui s’exécutent régulièrement pour maintenir les systèmes de production à jour.
Transformations incrémentielles
Les modèles incrémentiels supposent généralement que la source de données est en annexe uniquement et a un schéma stable. Les articles suivants fournissent des détails sur les nuances des transformations incrémentielles sur les tables qui connaissent des mises à jour, des suppressions ou des modifications de schéma :
- API APPLY CHANGES : Simplifier la capture des changements de données dans Delta Live Tables
- Utiliser le flux des changements de données Delta Lake sur Azure Databricks
- Mettre à jour un schéma de table Delta Lake
- Lectures et écritures en diffusion en continu sur des tables Delta
Transformations en temps réel
Delta Lake excelle à fournir un accès quasi en temps réel à de grandes quantités de données pour tous les utilisateurs et applications interrogeant votre lakehouse, mais en raison de la surcharge liée à l’écriture de fichiers et de métadonnées dans le stockage d’objets cloud, la latence en temps réel ne peut pas être atteinte pour de nombreuses charges de travail qui écrivent dans des récepteurs Delta Lake.
Pour les applications de diffusion en continu à latence extrêmement faible, Databricks recommande de choisir des systèmes source et récepteur conçus pour des charges de travail en temps réel telles que Kafka. Vous pouvez utiliser Azure Databricks pour enrichir les données, notamment les agrégations, les jointures entre les flux de données et la jointure des données en continu avec les données à dimension variable stockées dans le lakehouse.