Plongée au cœur de Delta Lake : application et évolution du schéma

Essayez cette série de notebooks dans Databricks

Les données, comme nos expériences, évoluent et s’accumulent sans cesse. Pour rester à niveau, nos modèles mentaux du monde doivent s’adapter aux nouvelles données, dont certaines contiennent de nouvelles dimensions : de nouvelles façons de voir des choses que nous n’avions jamais imaginées auparavant. Ces modèles mentaux ne sont pas sans rappeler le schéma d’une table, qui définit la façon dont nous catégorisons et traitons les nouvelles informations.

Cela nous amène à la gestion des schémas. Au fur et à mesure que les problèmes et les exigences de l’entreprise évoluent, la structure de vos données évolue également. Avec Delta Lake, il est facile d’intégrer de nouvelles dimensions à mesure que les données changent. Les utilisateurs ont accès à une sémantique simple pour contrôler le schéma de leurs tables. Ces outils comprennent l’application du schéma, qui empêche les utilisateurs de polluer accidentellement leurs tables avec des erreurs ou des données inutiles, ainsi que l’évolution du schéma, qui leur permet d’ajouter automatiquement de nouvelles colonnes de données enrichies lorsque ces colonnes sont pertinentes. Dans ce blog, nous allons nous pencher sur l’utilisation de ces outils.

Présentation des schémas de table

Chaque DataFrame dans Apache Spark™ contient un schéma, un plan qui définit la forme des données, comme les types de données et les colonnes, ainsi que les métadonnées. Avec Delta Lake, le schéma de la table est enregistré au format JSON dans le journal des transactions.

Qu’est-ce que l’application du schéma ?

L’application du schéma, également appelée validation du schéma, est une protection dans Delta Lake qui garantit la qualité des données en rejetant les écritures dans une table qui ne correspondent pas au schéma de la table. À l’instar du responsable de l’accueil d’un restaurant fréquenté qui n’accepte que les réservations, elle vérifie si chaque colonne des données insérées dans la table figure sur sa liste de colonnes attendues (en d’autres termes, si chacune a une « réservation ») et rejette toute écriture avec des colonnes qui ne figurent pas sur la liste.

Comment fonctionne l’application du schéma ?

Delta Lake utilise la validation du schéma à l’écriture, ce qui signifie que toutes les nouvelles écritures dans une table sont vérifiées pour s’assurer de leur compatibilité avec le schéma de la table cible au moment de l’écriture. Si le schéma n’est pas compatible, Delta Lake annule complètement la transaction (aucune donnée n’est écrite) et déclenche une exception pour informer l’utilisateur de l’incompatibilité.

Pour déterminer si une écriture dans une table est compatible, Delta Lake utilise les règles suivantes. Le DataFrame à écrire :

• Ne peut pas contenir de colonnes supplémentaires qui ne sont pas présentes dans le schéma de la table cible. Inversement, ce n’est pas grave si les données entrantes ne contiennent pas toutes les colonnes de la table : ces colonnes se verront simplement attribuer des valeurs null.
• Ne peut pas avoir de types de données de colonne différents des types de données de colonne dans la table cible. Si la colonne d’une table cible contient des données StringType, mais que la colonne correspondante dans le DataFrame contient des données IntegerType, l’application du schéma déclenchera une exception et empêchera l’opération d’écriture d’avoir lieu.
• Ne peut pas contenir de noms de colonnes qui ne diffèrent que par la casse. Cela signifie que vous ne pouvez pas avoir de colonnes telles que « Foo » et « foo » définies dans la même table. Bien que Spark puisse être utilisé en mode sensible à la casse ou insensible à la casse (par défaut), Delta Lake conserve la casse, mais est insensible à la casse lors du stockage du schéma. Parquet est sensible à la casse lors du stockage et du renvoi des informations de colonne. Pour éviter les erreurs potentielles, la corruption des données ou les problèmes de perte (que nous avons personnellement rencontrés chez Databricks), nous avons décidé d’ajouter cette restriction.

Pour illustrer cela, regardez ce qui se passe dans le code ci-dessous lorsqu’une tentative d’ajout de colonnes nouvellement calculées à une table Delta Lake qui n’est pas encore configurée pour les accepter est effectuée.

Plutôt que d’ajouter automatiquement les nouvelles colonnes, Delta Lake applique le schéma et empêche l’écriture de se produire. Pour aider à identifier la ou les colonnes qui ont causé l’incompatibilité, Spark imprime les deux schémas dans la trace de pile à des fins de comparaison.

En quoi l’application du schéma est-elle utile ?

Parce qu’il s’agit d’une vérification aussi rigoureuse, l’application du schéma est un excellent outil à utiliser comme gardien d’un ensemble de données propre et entièrement transformé qui est prêt pour la production ou la consommation. Elle est généralement appliquée aux tables qui alimentent directement :

• Les algorithmes de Machine Learning
• Les tableaux de bord décisionnels
• Les outils d’analyse et de visualisation des données
• Tout système de production nécessitant des schémas sémantiques hautement structurés, fortement typés

Afin de préparer leurs données pour cet obstacle final, de nombreux utilisateurs utilisent une architecture « multi-sauts » simple qui ajoute progressivement de la structure à leurs tables. Pour en savoir plus, consultez l’article intitulé Production de Machine Learning avec Delta Lake.

Bien sûr, l’application du schéma peut être utilisée n’importe où dans votre pipeline, mais sachez qu’il peut être un peu frustrant de voir votre écriture en continu dans une table échouer parce que vous avez oublié que vous avez ajouté une seule colonne aux données entrantes, par exemple.

Prévention de la dilution des données

À ce stade, vous vous demandez peut-être de quoi il s’agit ? Après tout, parfois, une erreur d’« incompatibilité de schéma » inattendue peut vous piéger dans votre flux de travail, surtout si vous êtes novice en matière de Delta Lake. Pourquoi ne pas simplement laisser le schéma changer comme il le faut afin que je puisse écrire mon DataFrame quoi qu’il arrive ?

Comme le dit le vieil adage, « mieux vaut prévenir que guérir ». À un moment donné, si vous n’appliquez pas votre schéma, les problèmes de compatibilité des types de données feront leur apparition : des sources de données brutes apparemment homogènes peuvent contenir des cas extrêmes, des colonnes corrompues, des mappages mal formés ou d’autres choses effrayantes qui se produisent la nuit. Une bien meilleure approche consiste à arrêter ces ennemis aux portes (en utilisant l’application du schéma) et à les traiter à la lumière du jour plutôt que plus tard, lorsqu’ils se cacheront dans les recoins sombres de votre code de production.

L’application du schéma vous assure que le schéma de votre table ne changera pas à moins que vous ne fassiez le choix affirmatif de le modifier. Elle empêche la « dilution » des données, qui peut se produire lorsque de nouvelles colonnes sont ajoutées si fréquemment que les tables autrefois riches et concises perdent leur signification et leur utilité en raison du déluge de données. En vous encourageant à être intentionnel, à fixer des normes élevées et à vous attendre à une qualité élevée, l’application du schéma fait exactement ce pour quoi elle a été conçue : vous garder honnête et vos tables propres.

Si, après un examen plus approfondi, vous décidez que vous vouliez vraiment ajouter cette nouvelle colonne, c’est une correction facile en une seule ligne, comme indiqué ci-dessous. La solution est l’évolution du schéma !

Qu’est-ce que l’évolution du schéma ?

L’évolution du schéma est une fonctionnalité qui permet aux utilisateurs de modifier facilement le schéma actuel d’une table pour tenir compte des données qui évoluent au fil du temps. Le plus souvent, elle est utilisée lors de l’exécution d’une opération d’ajout ou d’écrasement, afin d’adapter automatiquement le schéma pour inclure une ou plusieurs nouvelles colonnes.

Comment fonctionne l’évolution du schéma ?

Pour faire suite à l’exemple de la section précédente, les développeurs peuvent facilement utiliser l’évolution du schéma pour ajouter les nouvelles colonnes qui ont été précédemment rejetées en raison d’une incompatibilité de schéma. L’évolution du schéma est activée en ajoutant .option('mergeSchema', 'true') à votre commande Spark .write ou .writeStream.

Pour afficher le tracé, exécutez l’instruction Spark SQL suivante.

Vous pouvez également définir cette option pour l’ensemble de la session Spark en ajoutant spark.databricks.delta.schema.autoMerge = True à votre configuration Spark. Utilisez-la avec prudence, car l’application du schéma ne vous avertira plus des incompatibilités de schéma involontaires.

En incluant l’option mergeSchema dans votre requête, toutes les colonnes qui sont présentes dans le DataFrame, mais pas dans la table cible, sont automatiquement ajoutées à la fin du schéma dans le cadre d’une transaction d’écriture. Les champs imbriqués peuvent également être ajoutés, et ces champs seront également ajoutés à la fin de leurs colonnes struct respectives.

Les ingénieurs et les scientifiques des données peuvent utiliser cette option pour ajouter de nouvelles colonnes (peut-être une métrique nouvellement suivie ou une colonne des chiffres de vente de ce mois-ci) à leurs tables de production de Machine Learning existantes sans casser les modèles existants qui reposent sur les anciennes colonnes.

Les types de modifications de schéma suivants sont éligibles à l’évolution du schéma lors des ajouts ou des remplacements de table :

• Ajout de nouvelles colonnes (c’est le scénario le plus courant)
• Modification des types de données de NullType -> tout autre type, ou surclassements de ByteType -> ShortType -> IntegerType

Les autres modifications, qui ne sont pas éligibles à l’évolution du schéma, nécessitent que le schéma et les données soient remplacés en ajoutant .option("overwriteSchema", "true"). Par exemple, dans le cas où la colonne « Foo » était à l’origine un type de données integer et que le nouveau schéma serait un type de données string, tous les fichiers Parquet (données) devraient être réécrits. Ces modifications comprennent :

• Suppression d’une colonne
• Modification du type de données d’une colonne existante (sur place)
• Renommage des noms de colonnes qui ne diffèrent que par la casse (par exemple, « Foo » et « foo »)

Enfin, avec la prochaine version de Spark 3.0, DDL explicite (à l’aide de ALTER TABLE) sera entièrement pris en charge, ce qui permettra aux utilisateurs d’effectuer les actions suivantes sur les schémas de table :

• Ajout de colonnes
• Modification des commentaires de colonne
• Définition des propriétés de la table qui définissent le comportement de la table, comme la définition de la durée de conservation du journal des transactions

En quoi l’évolution du schéma est-elle utile ?

L’évolution du schéma peut être utilisée chaque fois que vous avez l’intention de modifier le schéma de votre table (par opposition au cas où vous avez accidentellement ajouté des colonnes à votre DataFrame qui ne devraient pas s’y trouver). C’est le moyen le plus simple de migrer votre schéma, car il ajoute automatiquement les noms de colonnes et les types de données corrects, sans avoir à les déclarer explicitement.

Résumé

L’application du schéma rejette toute nouvelle colonne ou autre modification de schéma qui n’est pas compatible avec votre table. En définissant et en respectant ces normes élevées, les analystes et les ingénieurs peuvent être sûrs que leurs données ont les plus hauts niveaux d’intégrité et les analyser avec clarté, ce qui leur permet de prendre de meilleures décisions commerciales.

De l’autre côté de la médaille, l’évolution du schéma complète l’application en facilitant la mise en œuvre automatique des modifications de schéma prévues. Après tout, il ne devrait pas être difficile d’ajouter une colonne.

L’application du schéma est le yin de l’évolution du schéma. Utilisées ensemble, ces fonctionnalités permettent plus que jamais de bloquer le bruit et de se concentrer sur le signal.

Nous tenons également à remercier Mukul Murthy et Pranav Anand pour leurs contributions à ce blog.

Articles connexes

Articles de cette série :
Plongée au cœur de Delta Lake n° 1 : Déballage du journal des transactions
Plongée au cœur de Delta Lake n° 2 : Application et évolution du schéma
Plongée au cœur de Delta Lake n° 3 : Internes DML (mise à jour, suppression, fusion)

Production de Machine Learning avec Delta Lake
Qu’est-ce qu’un lac de données ?

(Cet article de blog a été traduit à l'aide d'outils basés sur l'intelligence artificielle) Article original