Accueil Databricks Zero-Copy Delta Share : la fin de la gestion des données

Partage delta sans copie : la fin de la gestion des flux de données

Wiki SAP Databricks

Ce wiki explique comment surmonter l'un des principaux obstacles dans le paysage moderne des données : l'échange de données, souvent complexe, lent et coûteux. De SAP à SAP Databricks.

La solution : Databricks Delta Sharing et le principe « zero-copy ». Andreas décrit dans le wiki comment cela permet de partager des données en direct de manière sécurisée et en temps réel, sans avoir à créer de copie physique.

Table des matières

Il fut un temps où l'intégration des données était avant tout une chose : fastidieuse. Quiconque souhaitait exploiter des données SAP sur une plateforme moderne telle que Databricks devait mettre en place des pipelines, programmer des extracteurs et assister à la perte de précieuses informations métier dans des fichiers CSV plats. Nous appelions cela le « Data Plumbing » – et c'était tout sauf une avancée.

Mais avec l'introduction de la SAP Business Data Cloud (BDC) et du principe du « Zero-Copy Delta Share », cette ère des copies redondantes touche définitivement à sa fin. Les derniers préparatifs sont terminés. Le compte à rebours a commencé.

2. La salle des machines : là où se trouvent réellement les données

Tout commence dans le FOS (File Object Store), la couche de stockage native du cloud de SAP. Ici, les données ne sont pas stockées dans des tables de base de données rigides, mais au format HDLF (High-performance Data Lake Format) – d'un point de vue technique, il s'agit d'une implémentation hautement optimisée d'Apache Parquet.

La particularité : ces fichiers sont immuables. Chaque modification génère de nouvelles versions accompagnées de métadonnées, ce qui permet de réaliser de véritables transactions ACID (atomicité, cohérence, isolation, durabilité) au niveau des fichiers. En bref : une base solide. Et ce n’est pas une mince affaire : c’est la condition préalable à tout ce qui va suivre.

3. Les avantages du partage différentiel sans copie en un coup d'œil

Pourquoi cette avancée technologique est-elle si déterminante ? La réponse réside dans la réduction considérable de la complexité : moins de poids, plus de poussée :

  • Pas de copies de données, pas de pipelines ETL : nous éliminons les coûts et les sources d'erreurs liés à la duplication et au déplacement des données.
  • Échange de données en temps réel : les équipes travaillent toujours avec les informations les plus récentes, provenant directement de la source, sans avoir à attendre de longs cycles de traitement par lots.
  • Sécurité et contrôle : SAP conserve la maîtrise des données. Les droits d'accès sont gérés de manière centralisée et peuvent être révoqués à tout moment.
  • Ouvert et flexible : en tant que norme ouverte, Delta Sharing fonctionne sur différentes plateformes et avec différents fournisseurs de services cloud.

4. La poignée de main numérique : les mécanismes cloud-native qui sous-tendent Delta Sharing

Mais comment cela fonctionne-t-il concrètement sur le plan technique ? Jetons un coup d'œil sous le capot. Imaginons que les systèmes Databricks et SAP BDC communiquent entre eux. Au lieu que SAP se charge laborieusement de conditionner et d'envoyer les données, un échange élégant basé sur REST a lieu : la séparation stricte entre le stockage (Storage) et la puissance de calcul (Compute) dans sa forme la plus pure.

Tout commence par une poignée de main: le client Databricks s'identifie à l'aide d'un jeton Bearer, une clé de sécurité numérique. Le serveur BDC renvoie un manifeste: une liste structurée des fichiers représentant l'état actuel des données. Vient ensuite l'étape décisive : le serveur génère pour chacun de ces fichiers une URL pré-signée – un lien temporaire doté de droits d'accès intégrés et d'une durée de vie limitée.

Le flux de données proprement dit ne transite jamais par le serveur d'applications SAP. Ce sont les nœuds de travail Databricks qui prennent le relais : via des requêtes par plage d'octets, ils chargent directement depuis la mémoire SAP uniquement les blocs de données réellement nécessaires (Columnar Pruning). Le traitement analytique s'effectue entièrement dans Databricks, tandis que le stockage reste en toute sécurité chez SAP.

5. Exemple pratique : la prévision intelligente de trésorerie

Concrètement, comment cela se passe-t-il ? Une équipe commerciale souhaite utiliser les chiffres de vente quotidiens issus de S/4HANA pour établir des prévisions à l'aide d'un modèle d'apprentissage automatique dans Databricks.

Sans Delta Sharing :
Un processus ETL complexe extrait les données quotidiennement. Lorsque le data scientist lance son analyse, les données datent déjà de 12 à 24 heures. Ce processus est coûteux, source d'erreurs – et rappelle cruellement une fusée qui doit d'abord transporter péniblement son propre carburant jusqu'à la rampe de lancement dans des bidons.

Avec Delta Sharing :
Les données de vente sont directement partagées depuis S/4HANA sous forme de produit de données. L'équipe de science des données y accède en temps réel. Les prévisions sont plus précises, car elles reposent sur la situation réelle. Les frais généraux liés à la construction du pipeline sont supprimés.

6. L'art de la traduction : pourquoi avons-nous besoin de métadonnées ?

Mais pour que les données soient comprises dans le système cible, il ne suffit pas d'y avoir simplement accès. Sans contexte, les données ne sont que du bruit. C'est pourquoi BDC Connect utilise deux protocoles comme « interprètes » :

  • ORD (Open Resource Discovery) : décrit, sous une forme lisible par machine, la provenance des données et leur versionnement.
  • CSN (Core Schema Notation) : permet de reconnaître automatiquement les clés primaires et les relations entre les tables lors du montage dans Unity Catalog.

7. Gouvernance universelle : qui peut monter à bord – et qui ne le peut pas ?

Mais le contexte ne suffit pas à lui seul : il faut également des règles claires pour déterminer qui est autorisé à accéder à ces données. La sécurité ne s'arrête pas aux limites du système. Nous mettons en place un pipeline d'identité sans faille : Microsoft Entra ID sert de point d'ancrage. Via l’IPS (Identity Provisioning System), nous répercutons les identités dans SAP IAS, tandis que Databricks utilise ces mêmes identités Entra. Lorsque Unity Catalog applique désormais des contrôles d’accès tels que la sécurité au niveau des lignes, cela se fait sur la base d’une identité synchrone et cohérente, quel que soit le système sur lequel l’utilisateur travaille.

Résultat : les modifications ou désactivations de rôles prennent effet immédiatement et de manière cohérente, de SAP Datasphere au notebook Databricks.

8. Le tournant de Dremio et les perspectives pour 2026

Il est également intéressant de se pencher sur ce qui se profile à l'horizon : en choisissant dès aujourd'hui la bonne architecture, vous préservez vos investissements pour demain. En mai 2026, SAP a ouvert la voie à Apache Iceberg en rachetant Dremio. Le catalogue devient décentralisé, le BDC indépendant du format. Cela signifie qu’une couche d’orchestration de catalogues (par exemple Atlan) prend de plus en plus d’importance pour garder une vue d’ensemble dans un environnement multi-catalogues (Unity, Polaris, Horizon).

Pour les scénarios d'IA, le protocole MCP (Model Context Protocol) entre également en jeu. Il fait abstraction du niveau technique, de sorte qu'un agent IA ne voit plus que le contrat de données stable, que Delta ou Iceberg soit en exécution en arrière-plan.

9. Conclusion : Prêts pour le décollage !

Le « zero-copy » n'est pas seulement un choix architectural. C'est le moment où nous cessons de poser des câbles pour devenir de véritables architectes de la réussite commerciale.

Le « Data Plumbing » a fait son temps. Et la question n'est plus de savoir si vous allez saisir cette opportunité, mais quand vous allez le faire.

La mission Lakehouse prend son envol. Êtes-vous à bord ? 🚀

Le guide Databricks d'Andreas & Yvonne

Vous voulez toutes les informations importantes en un coup d'œil ? 

Téléchargez dès maintenant le guide gratuit de SAP Databricks !

Votre stratégie de données est individuelle - votre conseil devrait l'être aussi

L'introduction du partage delta sans copie est plus qu'une simple implémentation technique : il s'agit d'une étape stratégique vers la modernisation de votre architecture de données. La décision d'utiliser cette technologie et la manière dont vous l'exploiterez dépendent de votre environnement système spécifique, de vos exigences en matière de sécurité et de vos objectifs à long terme en matière d'analyse et d'intelligence artificielle. Il n'existe pas de solution standard dans ce domaine.

Permettez-nous de discuter sans engagement de la manière dont Delta Sharing peut révolutionner l'échange de données dans votre entreprise et exploiter pleinement le potentiel de vos données SAP. Veuillez nous contacter pour un entretien personnalisé.

 
 
Christiane Maria Kallfass est spécialiste du recrutement et du marketing chez s-peers AG
Christiane Grimm
Ventes internes

Publié par :

Dr. Andreas Wagner

Responsable Customer Success

autor:IN

Cet article vous a-t-il plu ?

Cet article vous a-t-il été utile ?

Cliquez sur une étoile pour évaluer !

Note moyenne : 4,7 /5.
Nombre d'avis : 25

Aucun vote pour l'instant ! Soyez la première personne à noter ce post !

INFORMATIONS

Plus d'informations

SAP BDC Zero-Copy et ingénierie des données avec Databricks

Plateforme de données hybride associant SAP Business Data Cloud et Databricks : partage delta sans copie (Zero-Copy Delta Sharing) et architecture Medallion

Comment utiliser les produits de données SAP dans Databricks en dehors de SAP Business Data Cloud (BDC) ? Ce wiki vous explique...
Données S4 dans Databricks, y compris la sémantique

Connecter SAP S/4HANA et Databricks : intégrer conjointement les données et la sémantique

Comment les données SAP S/4HANA sont-elles transférées vers SAP Business Data Cloud (BDC) ? Ce wiki explique l'interaction entre les vues CDS, les données métier...
wiki-ai-readiness-1 (1)

Trois moteurs, une seule vérité : un modèle sémantique pour SAP Datasphere, Databricks et Power BI

Trois moteurs, un indicateur : comment SAP Datasphere, Databricks et Power BI parviennent-ils à trouver un dénominateur commun ? Ce wiki vous explique...

Glossaire SAP Sapphire 2026 : Joule, agents IA et « Autonomous Enterprise » expliqués simplement

Joule, agents IA, entreprise autonome, protocole A2A : tous les nouveaux termes SAP présentés lors du salon Sapphire 2026 en un coup d'œil. Consultez dès maintenant le glossaire s-peers.
Wiki Big Query SAP Warehousing

Google BigQuery vs SAP BW : comparaison de deux solutions d'entrepôt de données

Cet article Wiki présente deux solutions leaders pour la gestion et l'analyse des données dans le monde moderne axé sur les données : Google...
Transformation par l'IA et économie comportementale : pourquoi les gens ne veulent (souvent) pas changer

Transformation par l'IA et économie comportementale : pourquoi les gens ne veulent (souvent) pas changer

Dans ce wiki, Yvonne explique, sous l'angle de l'économie comportementale, pourquoi les changements sont si difficiles à mettre en œuvre dans les entreprises. Pourquoi les gens agissent-ils...
Facteurs de réussite de l'adoption de l'IA - gestion du changement

Quels sont les véritables moteurs de l'adoption de l'IA dans les entreprises ? 6 facteurs qui déterminent le succès ou l'échec.

Ce wiki explique pourquoi le changement échoue rarement à cause de la technologie, mais plutôt en raison de schémas psychologiques, et comment...