Ces dernières années, les architectures data dans le cloud ont profondément évolué. Là où l’on trouvait historiquement une succession d’outils spécialisés — ETL, Data Warehouse, moteurs analytiques — les plateformes modernes cherchent à unifier les usages autour d’un socle commun.
Dans l’écosystème Azure, Databricks s’est imposé comme un composant central de nombreuses architectures data, en particulier pour les cas nécessitant scalabilité, traitements distribués et temps réel.
Pour un développeur ou architecte cloud déjà à l’aise avec Azure, Databricks peut toutefois sembler déroutant car c’est à l’origine une plateforme à part, qui est maintenant accessible avec Azure.
Cet article a pour objectif d’expliquer ce qu’est Databricks, comment il fonctionne techniquement, et comment il s’intègre dans une architecture Azure, en partant des principes de base jusqu’à l’organisation concrète des projets.
Databricks est une plateforme d’analytics conçue pour répondre aux problématiques modernes de la donnée : volumes importants, temps réel, diversité des usages (BI, data engineering, data science) et besoin de gouvernance.
Contrairement aux architectures historiques où chaque usage disposait de son propre outil (ETL, DWH, plateforme ML), Databricks propose une approche unifiée basée sur le concept de Lakehouse.
L’idée est simple : utiliser un Data Lake comme stockage unique, tout en apportant les garanties habituellement réservées aux Data Warehouses : transactions, performance et contrôle.
Cette approche permet de :
Databricks n’est donc ni un simple moteur Spark, ni un Data Warehouse : c’est une plateforme de calcul et de gouvernance positionnée au cœur de l’architecture data.
Pour un architecte Azure, la question se pose naturellement. Les deux plateformes partagent une vision similaire — centraliser les usages data — mais avec des philosophies différentes. Fabric est une solution 100 % Microsoft, pensée pour les organisations déjà investies dans l’écosystème Azure/Power BI, avec une approche plus accessible et no-code. Databricks est une plateforme ouverte et multi-cloud (Azure, AWS, GCP), taillée pour des besoins techniques avancés : traitements distribués massifs, MLOps, flexibilité des clusters.
En résumé : Fabric pour la simplicité et l’intégration Microsoft, Databricks pour la puissance et l’ouverture.
L’architecture Databricks repose sur une séparation claire entre :
Les données ne transitent jamais hors de ton environnement cloud. Databricks orchestre le calcul, mais le stockage et la sécurité restent sous ton contrôle (dans notre cas, au sein d’Azure).
Le moteur de calcul est distribué : un driver coordonne l’exécution et délègue le traitement à plusieurs executors, permettant de paralléliser massivement les workloads, qu’ils soient batch ou streaming.
Comme dit précédement, Databricks ne stocke pas les données : il s’appuie sur un Data Lake Object fourni par le cloud.
Dans Azure, il s’agit généralement d’Azure Data Lake Storage Gen2.
Databricks est agnostique des formats de fichiers et peut lire et écrire la majorité des types de fichiers existant.
Cela permet:
On notera que le format Delta Lake est à privilégier par les « best practicies » databricks. Il garanti les transactions ACID qui peuvent etre désirable pour un projet data.
L’un des points clés d’un projet Databricks réussi est l’organisation du workspace et du code.
Un workspace Databricks est généralement organisé par :
Chaque domaine contient:
Bronze / Silver / Gold,
Le workspace databricks n’est pas un dépôt Git, mais un espace d’exécution et de collaboration.
Même si Databricks est très orienté notebooks, les projets matures adoptent rapidement une séparation claire avec 3 grosses étapes.
Cette approche permet des revues de code classiques, des déploiements automatisés, une meilleure maintenabilité.
La séparation des environnements (dev, test, prod) est une bonne pratique classique, mais son implémentation concrète dans Databricks mérite d’être précisée. Le schéma le plus courant consiste à séparer les environnements par workspace Azure distinct, ce qui garantit un isolement complet des ressources, des droits et des configurations. Chaque workspace peut ensuite être organisé en catalogues Unity Catalog séparés, qui constituent une deuxième frontière logique au sein d’un même workspace si besoin.
Les paramètres (paths, secrets, configs) peuvent êtres externalisés, par exemple injectés via des variables d’environnement ou via un Azure Key Vault. Le code reste donc identique, seul le contexte d’exécution change.
Databricks intègre son propre moteur d’orchestration :
Chaque tâche peut:
Databricks devient ainsi un orchestrateur data spécialisé, complémentaire aux orchestrateurs globaux du cloud.
Dans Azure, Databricks est proposé sous forme de service managé : Azure Databricks, parfaitement intégré à l’écosystème de Microsoft Azure (et à son systeme de facturation :) ).
L’authentification repose sur Entra ID :
Les accès au Data Lake se font via Managed Identity, supprimant toute gestion de clés dans le code. Pour permettre à Databricks d’accèder aux autres ressources Azure en utilisant ce mécanisme, vous aurez besoin d’un module spécial : Access Connector for Azure Databricks
Unity Catalog est la couche de gouvernance centralisée de Databricks. Il permet de gérer finement les droits d’accès à tous les niveaux : catalogues, bases de données, tables, colonnes, voire lignes individuelles. Concrètement, il offre un point unique pour définir qui peut lire, modifier ou exécuter des requêtes sur quelle donnée — indépendamment du cluster ou du notebook utilisé.
Au-delà des permissions, Unity Catalog apporte également un lineage automatique des données (traçabilité des flux de transformation), un audit log des accès, et la possibilité de partager des données entre workspaces ou avec des partenaires externes via Delta Sharing. C’est donc le socle de confiance sur lequel repose toute la gouvernance data de la plateforme.
Databricks s’insère naturellement dans une architecture Azure. On peut lister :
Ingestion : Event Hub et API Databricks s’intègre nativement avec Azure Event Hub pour la consommation de flux de données en temps réel (logs applicatifs, données IoT, événements métier). Côté batch, il peut aussi appeler des API REST externes ou recevoir des fichiers déposés sur ADLS. Cette flexibilité permet de couvrir aussi bien les architectures orientées streaming que les pipelines d’ingestion classiques.
Orchestration globale : Azure Data Factory Databricks n’est pas toujours seul aux commandes. Dans une architecture Azure existante, Azure Data Factory joue souvent le rôle d’orchestrateur global : il déclenche les jobs Databricks, les chaîne avec d’autres services (SQL, Synapse, API), et gère les dépendances entre traitements. Databricks intègre ses propres Workflows pour l’orchestration interne, mais ADF reste pertinent pour coordonner des pipelines cross-services.
Exposition des données : Power BI Une fois les données transformées et stockées dans les couches Gold, elles peuvent être exposées directement à Power BI via un connecteur Databricks natif ou via des tables publiées dans Unity Catalog. Cette intégration permet aux équipes BI de requêter des données fraîches sans duplication vers un Data Warehouse intermédiaire.
CI/CD : Azure DevOps et Terraform L’industrialisation des projets Databricks passe par une chaîne CI/CD robuste. Azure DevOps permet de versionner les notebooks et packages Python, d’exécuter des tests automatisés et de déployer les jobs entre environnements. Terraform, de son côté, est utilisé pour provisionner l’infrastructure Databricks elle-même (workspaces, clusters, permissions Unity Catalog) de façon reproductible et auditée.
Databricks apporte une réponse moderne aux architectures data complexes en combinant: calcul distribué, stockage unifié, gouvernance avancée, intégration native avec Azure.
Bien utilisé, il peut devenir le socle central pour vos futurs projets data cloud ; mal structuré, il peut rapidement se transformer en jungle de notebooks.
La clé résidera donc autant dans la technologie que dans l’organisation des projets et du code.
