Modéliser des données semi-structurées
Cet article recommande des modèles pour stocker des données semi-structurées en fonction de la façon dont votre organisation utilise les données. Azure Databricks fournit des fonctions, des types de données natifs et une syntaxe de requête pour la compatibilité avec des données semi-structurées, imbriquées et complexes.
Les considérations suivantes ont un impact sur le modèle que vous devez utiliser :
- Les champs ou types de la source de données changent-ils fréquemment ?
- Combien de champs uniques totaux sont contenus dans la source de données ?
- Avez-vous besoin d’optimiser vos charges de travail pour les écritures ou les lectures ?
Databricks recommande de stocker des données en tant que tables Delta pour les requêtes en aval.
Utiliser une variante
Dans Databricks Runtime 15.3 et versions ultérieures, vous pouvez utiliser le type VARIANT
pour stocker des données JSON semi-structurées à l’aide d’un encodage optimisé qui surpasse les chaînes JSON pour les lectures et les écritures.
Le type VARIANT
a des applications similaires à celles des chaînes JSON. Certaines charges de travail bénéficient toujours de l’utilisation de structures, de cartes et de tableaux, en particulier pour les données avec des schémas connus qui bénéficieraient d’une disposition de données optimisée et d’une collecte de statistiques.
Pour plus de détails, consultez les articles suivants :
- Interroger des données de variante
- Comment la variante diffère-t-elle des chaînes JSON ?
- Ingérer des données en tant que type de variante semi-structurée
Utiliser des chaînes JSON
Vous pouvez stocker des données dans une seule colonne de chaîne à l’aide de la mise en forme JSON standard, puis interroger des champs dans le JSON à l’aide de la notation :
.
De nombreux systèmes génèrent des enregistrements sous forme d’enregistrements JSON codés en chaîne ou en octets. L’ingestion et le stockage de ces enregistrements en tant que chaînes ont une surcharge de traitement très faible. Vous pouvez également utiliser la fonction to_json
pour transformer n’importe quel struct de données en chaîne JSON.
Tenez compte des points forts et des faiblesses suivants lorsque vous choisissez de stocker des données sous forme de chaînes JSON :
- Toutes les valeurs sont stockées sous forme de chaînes sans informations de type.
- JSON prend en charge tous les types de données qui peuvent être représentés à l’aide de texte.
- JSON prend en charge les chaînes de longueur arbitraire.
- Il n’existe aucune limite quant au nombre de champs qui peuvent être représentés dans une seule colonne de données JSON.
- Les données ne nécessitent aucun prétraitement avant l’écriture dans la table.
- Vous pouvez résoudre les problèmes de type présents dans les données des charges de travail en aval.
- JSON fournit les pires performances en lecture, car vous devez analyser la chaîne entière pour chaque requête.
Les chaînes JSON offrent une grande flexibilité et une solution facile à implémenter pour obtenir des données brutes dans une table lakehouse. Vous pouvez choisir d’utiliser des chaînes JSON pour de nombreuses applications, mais elles sont particulièrement utiles lorsque le résultat le plus important d’une charge de travail stocke une représentation complète et précise d’une source de données pour le traitement en aval. Certains cas d’usage peuvent inclure :
- Ingestion de données de diffuser en continu à partir d’un service de file d’attente tel que Kafka.
- Enregistrement des réponses aux requêtes d’API REST.
- Le stockage d’enregistrements bruts à partir d’une source de données en amont n’est pas contrôlé par votre équipe.
En supposant que votre logique d’ingestion est flexible, le stockage de données en tant que chaîne JSON doit être résilient même si vous rencontrez de nouveaux champs, des modifications de la structure de données ou des modifications de type dans la source de données. Bien que les charges de travail en aval échouent en raison de ces modifications, votre table contient un historique complet des données sources, ce qui signifie que vous pouvez corriger les problèmes sans avoir à revenir à la source de données.
Utiliser des structs
Vous pouvez stocker des données semi-structurées avec des structs et activer toutes les fonctionnalités natives des colonnes tout en conservant la structure imbriquée de la source de données.
Delta Lake traite les données stockées comme des structs identiques à toutes les autres colonnes, ce qui signifie qu’il n’existe aucune différence fonctionnelle par rapport aux structs et aux colonnes. Les fichiers de données Parquet utilisés par Delta Lake créent une colonne pour chaque champ d’un struct. Vous pouvez utiliser des champs de struct comme colonnes de clustering ou colonne de partitionnement. Vous pouvez collecter des statistiques sur les structs pour les données ignorées.
Les structs fournissent généralement les meilleures performances en lecture, car ils prennent en charge toutes les optimisations de données qui ignorent et stockent des champs individuels sous forme de colonnes. Les performances peuvent commencer à diminuer lorsque le nombre de colonnes présentes atteint plusieurs centaines.
Chaque champ d’un struct a un type de données, qui est appliqué sur l’écriture identique aux colonnes. Par conséquent, les structs nécessitent un prétraitement complet des données. Ce prétraitement peut s'avérer utile lorsque vous souhaitez que seules les données validées soient validées dans une table. En revanche, il peut entraîner la perte de données ou l'échec d'un travail lors du traitement d'enregistrements malformés provenant de systèmes en amont.
Les structs sont moins flexibles que les flux JSON pour l’évolution du schéma, que ce soit pour l’évolution des types de données ou l’ajout de nouveaux champs.
Utiliser des cartes et des tableaux
Vous pouvez utiliser une combinaison de cartes et de tableaux pour répliquer des formats de données semi-structurés en mode natif dans Delta Lake. Les statistiques ne peuvent pas être collectées sur les champs définis avec ces types. Cependant, elles fournissent des performances équilibrées sur les jeux de données semi-structurés qui ont environ 500 champs.
La clé et la valeur des mappages sont saisies, de sorte que les données sont prétraitées et que le schéma est appliqué en écriture.
Pour accélérer les requêtes, Databricks recommande de stocker des champs souvent utilisés pour filtrer les données en tant que colonnes distinctes.
Dois-je aplatir mes données ?
Si vous stockez vos données à l’aide de JSON ou de cartes, envisagez de stocker les champs fréquemment utilisés pour filtrer les requêtes en tant que colonnes. La collection de statistiques, le partitionnement et le clustering ne sont pas disponibles pour les champs dans des chaînes ou des mappages JSON. Vous n’avez pas besoin de le faire pour les données stockées en tant que structs.
Syntaxe permettant d’utiliser des données imbriquées
Passez en revue les ressources suivantes pour plus d’informations sur l’utilisation des données imbriquées :