Aller au contenu principal
Dernière mise à jour le

Migrez votre data warehouse vers le lakehouse Databricks

Cet article décrit certaines des considérations et mises en garde à prendre en compte lorsque vous remplacez votre data warehouse d'entreprise par le lakehouse Databricks. La plupart des charges de travail, queries et tableaux de bord définis dans les data warehouse d'entreprise peuvent s'exécuter avec un minimum de refactoring de code une fois que les administrateurs ont terminé la migration initiale des données et la configuration de la gouvernance. La migration de vos charges de travail d'entreposage des données vers Databricks ne vise pas à éliminer l'entreposage des données, mais plutôt à unifier votre écosystème de données. Pour en savoir plus sur l'entreposage des données sur Databricks, consultez l'entreposage des données sur Databricks.

De nombreuses charges de travail Apache Spark extraient, transforment et chargent (ETL) des données des systèmes sources vers des data warehouse pour alimenter les analyses en aval. Le remplacement de votre data warehouse d'entreprise par un lakehouse permet aux analystes, aux data scientists et aux data engineers de travailler sur les mêmes tables au sein de la même plateforme, ce qui réduit la complexité globale, les exigences de maintenance et le coût total de possession. Voir Qu'est-ce qu'un data lakehouse ?. Pour un aperçu de la façon d'appliquer les modèles de conception de data warehouse dans un lakehouse, consultez Architecture d'entreposage des données.

Charger des données dans le lakehouse​

Databricks offre un certain nombre d'outils et de fonctionnalités pour faciliter la migration des données vers le lakehouse et la configuration des Jobs ETL pour charger des données à partir de diverses sources de données. Les articles suivants présentent ces outils et options :

En quoi la Databricks Data Intelligence Platform est-elle différente d'un data warehouse d'entreprise ?​

La Databricks Data Intelligence Platform est basée sur Apache Spark, Unity Catalog et Delta Lake, offrant un support natif pour les charges de travail Big Data pour l'analytique, le ML et le Data Engineering. Tous les systèmes de données d'entreprise ont des garanties transactionnelles, des modèles d'indexation et d'optimisation, et une syntaxe SQL légèrement différents. Certaines des plus grandes différences que vous pourriez découvrir incluent les suivantes :

  • Toutes les transactions sont au niveau de la table. Il n'y a pas de transactions, de verrous ou de garanties au niveau de la base de données.
  • Il n'y a pas de constructions BEGIN et END, ce qui signifie que chaque instruction ou requête s'exécute comme une transaction distincte.
  • L'espace de noms à trois niveaux utilise le modèle catalog.schema.table. Les termes database et schema sont synonymes en raison de l'ancienne syntaxe Apache Spark.
  • Les contraintes de clé primaire et de clé étrangère sont uniquement informatives. Les contraintes ne peuvent être appliquées qu'au niveau d'une table. Voir les Contraintes sur Databricks.
  • Les types de données natifs pris en charge par Databricks et Delta Lake peuvent différer légèrement des systèmes sources. La précision requise pour les types numériques doit être clairement indiquée avant que les types cibles ne soient choisis.

Les articles suivants fournissent un contexte supplémentaire sur les considérations importantes :

Sur cette page