Mirroring vs Shortcut

Après un petit (long) break, me revoilà pour aborder un article court avant de m’attaquer à une série de 4 articles consécutifs (oui oui, comme les shows hollywoodiens, je vous tease).

Aujourd’hui, nous allons faire une petite comparaison entre les shortcuts et le mirroring (mise en miroir).

Les shortcuts : le raccourci vers vos données

Qui n’a jamais mis un raccourci sur son bureau pour accéder à un dossier caché dans une forêt de sous-dossiers ? Eh bien, les raccourcis dans Fabric, c’est un peu la même chose.
Les raccourcis dans OneLake sont des pointeurs qui redirigent vers des données stockées ailleurs (en interne ou en externe). Ils fonctionnent comme des liens symboliques : les données ne sont ni copiées ni dupliquées, mais restent dans leur répertoire d’origine.

On peut distinguer deux types de raccourcis :

• Les raccourcis internes : qui pointent vers d’autres éléments Fabric tels que des lakehouses, des data warehouses, ou des bases de données KQL (promis, un jour je vous expliquerai ce que c’est), que ce soit dans le workspace ou à travers plusieurs workspaces.

• Les raccourcis externes : qui connectent Fabric à des systèmes de stockage externes comme Azure Data Lake Storage (ADLS) Gen2, Amazon S3, Google Cloud Storage (GCS) et Dataverse.

La caractéristique clé des raccourcis est leur transparence pour les services Fabric. Ils apparaissent simplement comme de simples dossiers dans OneLake. Cela permet à tout service qui peut accéder aux données dans OneLake (comme Apache Spark, SQL, Real-Time Intelligence ou Power BI) de les utiliser directement, sans configuration supplémentaire.

Le mirroring dans Fabric : la réplication en temps quasi réel

Le mirroring dans Fabric est une solution de réplication de données continue, à faible coût et à faible latence, conçue pour transférer des données de divers systèmes de bases de données directement dans OneLake.
Le processus crée une réplique physique des données sources au format Parquet et génère un point de terminaison SQL pour l’accès aux requêtes. Le mécanisme central du mirroring est la capture des données modifiées (CDC), qui permet de répliquer les changements en temps quasi réel.

Selon la source, le mécanisme de capture de données varie.
Pour les versions de SQL Server 2016 à 2022, le mirroring s’appuie sur la technologie CDC intégrée à SQL Server. Un agent de capture lit le journal des transactions pour détecter les modifications et les réplique via une data gateway vers OneLake.
Pour SQL Server 2025 et Azure SQL, la réplication utilise un « change feed » qui permet à la base de données source d’écrire directement les modifications dans une zone de destination OneLake, après quoi le moteur de mirroring de Fabric les traite.
Pour Azure Cosmos DB, la fonctionnalité de sauvegarde continue est un prérequis qui permet une réplication sans affecter la performance des charges transactionnelles.

Le mirroring n’est pas une fonctionnalité monolithique : il existe trois approches distinctes :

• Le database mirroring, approche « classique », réplique physiquement et en continu des bases de données ou des tables entières.

• Le metadata mirroring, qui ne synchronise que les métadonnées (noms de tables, schémas) de la source, en s’appuyant sur des raccourcis sous-jacents. Cette approche permet de rendre les données accessibles sans les déplacer, comme c’est le cas pour les catalogues Unity d’Azure Databricks.

• L’open mirroring, qui permet aux développeurs d’applications d’écrire directement des fichiers de modification dans une « landing zone » OneLake, ensuite répliqués dans un format analytique.

Le mirroring est spécifiquement conçu pour les sources de données transactionnelles et les entrepôts de données. Les sources supportées incluent Azure SQL Database, Azure SQL Managed Instance, SQL Server, Azure Cosmos DB, Snowflake et les catalogues Azure Databricks.

Cependant, chaque source a ses propres prérequis et limitations.
Par exemple, pour qu’une table soit « miroitable », elle doit posséder une clé primaire. La réplication est limitée à 500 tables par base de données miroir. De plus, certains types de données (comme json ou xml) ou certaines fonctionnalités de base de données (comme Temporal History Tables, Always Encrypted) ne sont pas prises en charge.

Parfait, maintenant que vous avez compris (enfin j’espère) la différence, la question qui doit venir est : c’est quoi le mieux ?

C’est simple, c’est le shortcut !!!!

Euh non, je voulais dire, cela dépend…

Quand privilégier les raccourcis ?

Les raccourcis sont la solution privilégiée lorsque l’objectif principal est la virtualisation et l’accès rapide aux données sans les déplacer. Cette approche est idéale pour :

• Les cas d’usage où la source est un data lake existant (ADLS, S3) et où la duplication des données est à éviter à tout prix.

• L’implémentation de modèles d’architecture de données modernes comme le « data mesh », où chaque domaine est responsable de ses propres données et les partage via des liens, plutôt qu’une réplication centralisée.

• La simplification des pipelines ETL, en permettant aux ingénieurs de construire des transformations directement sur la source.

• Les scénarios où les coûts de stockage doivent être minimisés en évitant la duplication de données, le stockage restant facturé à la source d’origine.

Quand choisir le mirroring ?

Le mirroring est la solution la plus appropriée pour la réplication de bases de données transactionnelles et de data warehouses, en particulier lorsque l’accès à des données en temps quasi réel est requis. Cette approche est idéale pour :

• Le déchargement des requêtes analytiques et de reporting gourmandes en ressources depuis une base de données OLTP vers OneLake, sans impacter la performance de la source.

• Les scénarios nécessitant de hautes performances de requête sur de grands volumes de données, les données répliquées localement bénéficiant d’une latence minimale.

• La simplification radicale des processus d’ingestion à partir de sources supportées, en éliminant le développement de pipelines ETL complexes.

• Les cas d’usage où le coût de calcul pour la réplication est moins une préoccupation que la performance des requêtes, le calcul pour la réplication étant gratuit.

Et côté coûts ?

Encore une fois, pas de réponse toute faite.

Pour les raccourcis, le calcul est facturé à la capacité de l’utilisateur qui consomme la donnée, dans un modèle « consommateur-paie ».
Le stockage est facturé à la source d’origine, sans coût de stockage supplémentaire dans OneLake. Il est cependant important de noter les risques de coûts de flux sortant pour les sources externes comme S3.

Pour le mirroring, le calcul pour la réplication des données dans OneLake est gratuit et ne consomme pas la capacité Fabric.
Le stockage des répliques est également gratuit jusqu’à une limite basée sur l’unité de capacité (CU) de la SKU Fabric (par exemple, 64 téraoctets gratuits pour une capacité F64). Ce n’est que lorsque la limite est dépassée que le stockage OneLake est facturé au tarif standard.
En revanche, tout calcul pour les requêtes exécutées sur les données miroir est facturé normalement selon le modèle de tarification de la capacité Fabric, et le mirroring entre régions peut entraîner des coûts de flux sortant inattendus.

Pour conclure

Pour conclure
Comme vos esprits brillants l’ont compris (je l’espère, sinon c’est que le blogueur est moins brillant que prévu), les shortcuts et le mirroring ne sont pas des solutions concurrentes, mais des outils complémentaires dans la boîte à outils de l’architecte de données. Les shortcuts excellent dans la virtualisation des data lakes, en évitant le mouvement de données, en minimisant les coûts de stockage et en favorisant les architectures décentralisées. Le mirroring, quant à lui, est une solution puissante et simple pour la réplication continue de bases de données transactionnelles, déchargeant les systèmes opérationnels et optimisant la performance des requêtes analytiques sur des données localisées.

L’existence d’une approche comme le « metadata mirroring », qui utilise des raccourcis sous-jacents pour synchroniser les données d’Azure Databricks, illustre parfaitement la synergie entre les deux concepts. Le mirroring gère la complexité de la réplication de la base de données, tandis que les raccourcis fournissent la flexibilité et la transparence de l’accès aux données.

Le choix de l’outil approprié dépend de la source des données et des objectifs métier. Cependant, une évaluation réaliste doit également prendre en compte le niveau de maturité des fonctionnalités. Les retours de la communauté soulignent que le mirroring, malgré sa promesse, souffre encore de problèmes de rigidité et de gestion qui pourraient rendre les raccourcis plus fiables pour les cas d’usage critiques, jusqu’à ce que ces problèmes soient résolus.

En fin de compte, l’architecture de données de l’entreprise moderne dans Microsoft Fabric ne reposera pas sur un seul de ces outils, mais sur une combinaison des deux, pour construire un écosystème de données à la fois flexible, performant et gouverné.

Et pour finir, un petit tableau comparatif — ou juste pour ceux qui ont la flemme de tout lire (oui, oui, j’ai les stats et tu as accecpté les cookies, donc je te vois TOI qui vient de scroller jusqu'ici)