Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Cet article présente les considérations, les mises en garde et les recommandations relatives à la modélisation des données sur Azure Databricks. Il s'adresse aux utilisateurs qui configurent de nouvelles tables ou créent des charges de travail ETL, en mettant l'accent sur la compréhension des comportements d'Azure Databricks qui influencent la transformation des données brutes en un nouveau modèle de données. Les décisions en matière de modélisation des données dépendent de la manière dont votre organisation et vos charges de travail utilisent les tables. Le modèle de données que vous choisissez a une incidence sur les performances des requêtes, les coûts de calcul et les coûts de stockage. Il s'agit d'une introduction aux concepts fondamentaux de la conception de bases de données avec Azure Databricks.
Important
Cet article s'applique exclusivement aux tables soutenues par Delta Lake, ce qui inclut toutes les tables gérées par Unity Catalog.
Vous pouvez utiliser Azure Databricks pour interroger d'autres sources de données externes, y compris les tables enregistrées auprès de Lakehouse Federation. Chaque source de données externe présente des limitations, une sémantique et des garanties transactionnelles différentes. Voir Interroger des données.
Concepts de gestion de bases de données
Un lakehouse construit avec Azure Databricks partage de nombreux composants et concepts avec d'autres systèmes d'entreposage de données d'entreprise. Tenez compte des concepts et fonctionnalités suivants lors de la conception de votre modèle de données.
Transactions sur Azure Databricks
Azure Databricks limite les transactions à des tables individuelles. Cela signifie qu’Azure Databricks ne prend pas en charge les instructions multi-tables (également appelées transactions multi-instructions).
Pour les charges de travail de modélisation des données, cela se traduit par l’exécution de plusieurs transactions indépendantes lors de l’ingestion d’un enregistrement source nécessite l’insertion ou la mise à jour de lignes dans deux tables ou plus. Chacune de ces transactions peut réussir ou échouer indépendamment d’autres transactions, et les requêtes en aval doivent être tolérantes à l’incompatibilité de l’état en raison d’un échec ou d’un retard des transactions.
Clés primaires et étrangères sur Azure Databricks
Les clés primaires et étrangères sont informationnelles et non appliquées. Ce modèle est courant dans de nombreux systèmes de base de données basés sur le cloud d’entreprise, mais diffère de nombreux systèmes de base de données relationnelle traditionnels. Consultez Contraintes sur Azure Databricks.
Jointures sur Azure Databricks
Les jointures peuvent introduire des goulots d’étranglement de traitement dans n’importe quelle conception de base de données. Lors du traitement des données sur Azure Databricks, l’optimiseur de requête cherche à optimiser le plan des jointures, mais peut lutter quand une requête individuelle doit joindre des résultats à partir de nombreuses tables. L’optimiseur peut également ne pas ignorer les enregistrements d’une table lorsque les paramètres de filtre se trouvent sur un champ d’une autre table, ce qui peut entraîner une analyse complète de la table.
Consultez Travailler avec des jointures sur Azure Databricks.
Remarque
Vous pouvez utiliser des vues matérialisées pour calculer de manière incrémentielle les résultats de certaines opérations de jointure, mais d’autres jointures ne sont pas compatibles avec les vues matérialisées. Consultez Vues matérialisées.
Utilisation de types de données imbriqués et complexes
Azure Databricks prend en charge l’utilisation de sources de données semi-structurées, notamment JSON, Avro et ProtoBuff, et le stockage de données complexes sous forme de structs, de chaînes JSON et de mappages et de tableaux. Consultez Données semi-structurées de modèle.
Modèles de données normalisés
Azure Databricks peut fonctionner correctement avec n’importe quel modèle de données. Si vous disposez d’un modèle de données existant que vous devez interroger ou migrer vers Azure Databricks, vous devez évaluer les performances avant de réarchitecturer vos données.
Si vous concevez un nouveau lakehouse ou que vous ajoutez des jeux de données à un environnement existant, Azure Databricks recommande d’utiliser un modèle fortement normalisé tel que le troisième formulaire normal (3NF).
Les modèles tels que le schéma en étoile ou le schéma flocon fonctionnent bien sur Azure Databricks, car il existe moins de jointures présentes dans les requêtes standard et moins de clés à synchroniser. En outre, l’utilisation de champs de données supplémentaires dans une table unique permet à l’optimiseur de requête d’ignorer de grandes quantités de données à l’aide de statistiques au niveau du fichier. Pour plus d’informations sur ignorer les données, consultez Ignorer les données pour Delta Lake.