Partager via

Migrer votre entrepôt de données vers Databricks Lakehouse

  • Article

Cet article décrit certaines considérations et mises en garde à prendre en compte quand vous remplacez votre entrepôt de données d’entreprise par Databricks Lakehouse. La plupart des charges de travail, des requêtes et des tableaux de bord définis dans les entrepôts de données d’entreprise peuvent s’exécuter avec une refactorisation minimale du code, une fois que les administrateurs ont effectué la configuration initiale de la migration des données et de la gouvernance. La migration de vos charges de travail d’entrepôt de données vers Azure Databricks ne consiste pas à éliminer l’entrepôt de données, mais à unifier votre écosystème de données. Pour plus d’informations sur l’entrepôt de données sur Databricks, consultez Qu’est-ce que l’entrepôt de données sur Azure Databricks ?.

De nombreuses charges de travail Apache Spark extraient, transforment et chargent (processus ETL) les données des systèmes sources vers des entrepôts de données pour alimenter l’analytique en aval. Le remplacement de votre entrepôt de données d’entreprise par un lakehouse permet aux analystes, aux scientifiques et aux ingénieurs des données de travailler sur les mêmes tables dans la même plateforme, ce qui réduit la complexité générale, les besoins de maintenance et le coût total de possession. Consultez Qu’est-ce qu’un data lakehouse ?. Pour plus d’informations sur l’entrepôt de données sur Databricks, consultez Qu’est-ce que l’entrepôt de données sur Azure Databricks ?.

Charger des données dans le lakehouse

Azure Databricks fournit un certain nombre d’outils et de fonctionnalités qui facilitent la migration des données vers le lakehouse ainsi que la configuration des travaux ETL pour charger des données à partir de diverses sources de données. Les articles suivants présentent ces outils et options :

comment la plateforme Databricks Data Intelligence se distingue d'un entrepôt de données d'entreprise

La plateforme Databricks Data Intelligence est construite sur Apache Spark, Unity Catalog et Delta Lake, offrant une prise en charge native des charges de travail big data pour l'analyse, l'apprentissage automatique et l'ingénierie des données. Tous les systèmes de données d’entreprise ont des garanties transactionnelles, des modèles d’indexation et d’optimisation ainsi qu’une syntaxe SQL légèrement différents. Voici quelques-unes des différences les plus importantes que vous pouvez découvrir :

  • Toutes les transactions se situent au niveau de la table. Il n’existe aucune transaction, aucun verrou ni aucune garantie au niveau de la base de données.
  • Il n’existe aucune construction BEGIN et END, ce qui signifie que chaque instruction ou requête s’exécute en tant que 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 la syntaxe Apache Spark héritée.
  • Les contraintes de clé primaire et de clé étrangère sont fournies à titre d’information uniquement. Les contraintes peuvent uniquement être appliquées au niveau de la table. Consultez Contraintes sur Azure Databricks.
  • Les types de données natifs pris en charge dans Azure Databricks et Delta Lake peuvent différer légèrement de ceux des systèmes sources. La précision nécessaire pour les types numériques doit être clairement indiquée avant le choix des types cibles.

Les articles suivants fournissent un contexte supplémentaire par rapport à certaines considérations importantes :