Migrer des applications de données vers Azure Databricks

  • Article

Cet article fournit une introduction à la migration d’applications de données existantes vers Azure Databricks. Azure Databricks fournit une approche unifiée qui vous permet d’utiliser des données provenant de nombreux systèmes sources sur une seule plateforme.

Pour obtenir une vue d’ensemble des fonctionnalités de la plateforme, consultez Qu’est-ce qu’Azure Databricks ?.

Pour plus d’informations sur la migration entre les versions de Databricks Runtime, consultez le guide de migration de Databricks Runtime.

Migrer des travaux ETL vers Azure Databricks

Vous pouvez migrer des travaux Apache Spark utilisés pour extraire, transformer et charger des données à partir d’implémentations locales ou natives cloud vers Azure Databricks en quelques étapes seulement. Consultez Adapter votre code Apache Spark pour Azure Databricks.

Azure Databricks étend les fonctionnalités de Spark SQL avec des intégrations open source préconfigurées, des intégrations de partenaires et des offres de produits d’entreprise. Si vos charges de travail ETL sont écrites en SQL ou Hive, vous pouvez migrer vers Azure Databricks avec une refactorisation minimale. En savoir plus sur les offres Azure Databricks SQL :

Pour obtenir des instructions spécifiques sur la migration de différents systèmes sources vers Azure Databricks, consultez Migrer des pipelines ETL vers Azure Databricks.

Remplacez votre entrepôt de données d’entreprise par un lakehouse

Azure Databricks offre une valeur et des performances optimales lorsque les charges de travail s’alignent autour des données stockées dans le lakehouse. De nombreuses piles de données d’entreprise incluent à la fois un lac de données et un entrepôt de données d’entreprise, et les organisations créent des workflows ETL complexes pour essayer de maintenir ces systèmes et données synchronisés. Le lakehouse vous permet d’utiliser les mêmes données, stockées dans le lac de données, entre des requêtes et des systèmes qui reposent généralement sur un entrepôt de données distinct. Pour plus d’informations sur le lakehouse, 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 ?.

La migration d’un entrepôt de données d’entreprise vers le lakehouse implique généralement de réduire la complexité de votre architecture de données et de vos workflows, mais il existe des mises en garde et des meilleures pratiques à garder à l’esprit lors de l’exécution de ce travail. Consultez Migrer votre entrepôt de données vers Databricks Lakehouse.

Unifier vos charges de travail ML, de science des données et d’analyse

Étant donné que lakehouse fournit un accès optimisé aux fichiers de données cloud par le biais de requêtes de table ou de chemins d’accès aux fichiers, vous pouvez effectuer le ML, la science des données et l’analyse sur une seule copie de vos données. Azure Databricks facilite le déplacement des charges de travail à partir d’outils open source et propriétaires, et gère les versions mises à jour de nombreuses bibliothèques open source utilisées par les analystes et les scientifiques des données.

Les charges de travail Pandas dans les notebooks Jupyter peuvent être synchronisées et exécutées à l’aide des dossiers Databricks Git. Azure Databricks fournit une prise en charge native de Pandas dans toutes les versions de Databricks Runtime, et configure de nombreuses bibliothèques ML et Deep Learning populaires dans Databricks Runtime. Si vous synchronisez vos charges de travail locales à l’aide de Git et de fichiers d’espace de travail dans les dossiers Git, vous pouvez utiliser les mêmes chemins d’accès relatifs pour les données et les bibliothèques personnalisées présentes dans votre environnement local.

Remarque

Par défaut, Azure Databricks gère les extensions .ipynb pour les notebooks Jupyter synchronisés avec les dossiers Databricks Git, mais convertit automatiquement les notebooks Jupyter en notebooks Databricks lorsqu’ils sont importés avec l’interface utilisateur. Les notebooks Databricks sont enregistrés avec une extension .py et peuvent donc exister côte à côte avec les notebooks Jupyter dans un dépôt référentiel Git.