Modélisation des 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 workloads utilisent les tables, et le modèle que vous choisissez affecte les performances des queries, les coûts de compute et les coûts de stockage. Cette page décrit les comportements de Databricks qui influencent la modélisation des données, pour les utilisateurs qui configurent de nouvelles tables ou qui créent des workloads ETL.
Cet article s'applique exclusivement aux tables prises en charge par Delta Lake, ce qui inclut toutes les tables gérées par Unity Catalog.
Vous pouvez utiliser Databricks pour interroger d'autres sources de données externes, y compris les tables enregistrées avec Lakehouse Federation. Chaque source de données externe a des limites, une sémantique et des garanties transactionnelles différentes. Voir Interroger les données.
Concepts de gestion de base de données
Un lakehouse construit avec Databricks partage de nombreux composants et concepts avec d'autres systèmes d'entreposage des données d'entreprise. Considérez les concepts et fonctionnalités suivants lors de la conception de votre modèle de données.
Transactions sur Databricks
Databricks délimite les transactions aux tables individuelles. Cela signifie que Databricks ne prend pas en charge les instructions multi-tables (également appelées transactions multi-instructions).
Pour les charges de travail de modélisation de données, cela se traduit par la nécessité d'effectuer plusieurs transactions indépendantes lorsque l'ingestion d'un enregistrement source nécessite d'insérer ou de mettre à jour des lignes dans au moins deux tables. Chacune de ces transactions peut réussir ou échouer indépendamment des autres transactions, et les query en aval doivent être tolérantes aux incohérences d'état du fait de transactions échouées ou retardées.
Clés primaires et étrangères sur Databricks
Les clés primaires et étrangères sont informatives et ne sont pas appliquées. Ce modèle est courant dans de nombreux systèmes de base de données cloud d'entreprise, mais diffère de nombreux systèmes de base de données relationnelles traditionnels. Voir les Contraintes sur Databricks.
Jointures sur Databricks
Les jointures peuvent introduire des goulets d'étranglement de traitement dans toute conception de base de données. Lors du traitement des données sur Databricks, l'optimiseur de query cherche à optimiser le plan pour les jointures, mais peut avoir des difficultés lorsqu'une query individuelle doit joindre les résultats de plusieurs tables. L'optimiseur peut également ne pas ignorer les enregistrements d'une table lorsque les parameters 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 Databricks.
Vous pouvez utiliser des vues matérialisées pour compute 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 les vues matérialisées.
Utilisation des types de données imbriqués et complexes
Databricks prend en charge l'utilisation de sources de données semi-structurées, notamment JSON, Avro et Protobuf, et le stockage de données complexes sous forme de structures, de chaînes JSON, de maps et de tableaux. Consultez Modéliser les données semi-structurées.
Modèles de données normalisés
Databricks peut bien fonctionner avec n'importe quel modèle de données. Si vous avez un modèle de données existant que vous devez query ou migrer vers Databricks, vous devriez évaluer les performances avant de réarchitecturer vos données.
Si vous concevez un nouveau lakehouse ou ajoutez des datasets à un environnement existant, Databricks déconseille d'utiliser un modèle fortement normalisé tel que la troisième forme normale (3NF).
Les modèles comme le schéma en étoile ou le schéma en flocon de neige fonctionnent bien sur Databricks, car il y a moins de jointures présentes dans les queries standard et moins de clés à synchroniser. De plus, le fait d'avoir plus de champs de données dans une seule table permet à l'optimiseur de query de sauter de grandes quantités de données en utilisant les statistiques au niveau du fichier. Pour en savoir plus sur le saut de données, consultez Saut de données.