Analytics Legends La plateforme de connaissance SAP Analytics
Guide

Architecture SAP Business Data Cloud, composant par composant

À jour au 2026-08-14

L'architecture SAP Business Data Cloud tient en cinq composants, et l'un d'eux explique pourquoi les quatre autres forment une pile plutôt qu'un lot. Datasphere porte la sémantique, un lakehouse géré par Databricks porte le stockage en format ouvert, Joule est la surface de consommation, le graphe de connaissances relie les entités métier, et le catalogue porte les types sémantiques, la traçabilité, les produits de données et les règles d'accès des deux côtés à la fois. Retirez le catalogue et il reste quatre produits gouvernés séparément sur une même facture.

Les cinq composants, et celui qui porte l'ensemble

Datasphere continue de faire ce qu'il faisait — modèles analytiques, hiérarchies, conversion de devises, exécution poussée vers HANA Cloud — à une différence près : il résout désormais son catalogue depuis le périmètre Business Data Cloud et non depuis un tenant autonome.

Le lakehouse géré fournit un stockage au format Delta gouverné par Unity Catalog, accessible depuis des carnets Spark, MLflow ou DBSQL, préprovisionné dans le périmètre de facturation SAP. Joule consomme les modèles analytiques pour le contexte métier et peut écrire en retour via des actions encadrées. Le graphe de connaissances relie Client, Article, Commande et les autres entités centrales, et les expose comme contexte interrogeable.

Le catalogue transforme ces quatre briques en architecture : la couche de métadonnées unifiée qui porte types sémantiques, traçabilité, produits de données et règles d'accès sur les deux plans de stockage. Une règle écrite une fois s'applique à ce que Joule expose comme à ce qu'un carnet Spark lit.

C'est aussi l'erreur de conception la plus fréquente : repousser catalogue et graphe à « plus tard, en configuration » reproduit la fragmentation d'avant à l'intérieur d'un contrat Business Data Cloud.

L'empilement des couches

Lue verticalement, l'architecture compte trois étages. En bas, le stockage de lac, qui couvre les données applicatives SAP, celles de l'entrepôt historique et les données tierces non SAP — ce dernier point est explicite, et cadrer le travail sémantique sur les seules sources SAP rend un agent aveugle à une part réelle du patrimoine.

Au milieu, la couche sémantique et de gouvernance, décrite en six capacités : sémantique, graphe de connaissances, modèles d'IA par domaine, analytique et simulations, produits de données, découverte et activation — entourées de la gestion des coûts et du cycle de vie, de la gouvernance des données, de la sécurité et de la confiance. Le cadrage est générationnel : l'entrepôt couplait calcul et stockage, le lakehouse les a séparés, cette couche ajoute le substrat typé et gouverné dont un agent a besoin.

En haut, les agents et les applications packagées. Dans l'étage de calcul, trois moteurs sont positionnés côte à côte et non par ordre de mérite : HANA Cloud pour la sous-seconde en mémoire, Databricks pour l'ingénierie à grande échelle et l'apprentissage gouverné, Snowflake pour l'entrepôt élastique et le partage inter-cloud.

Chaud et froid : où doit atterrir une requête

HANA Cloud, côté Datasphere, est le palier chaud : réponses à la sous-seconde pour tout ce que l'utilisateur attend devant son écran. La couche Delta gérée est le palier froid : profondeur historique, balayages volumineux, préparation des variables avant entraînement d'un modèle.

Les jointures inter-domaines appartiennent aux modèles analytiques Datasphere, parce que c'est là que vivent les types sémantiques, la conversion de devises et les règles d'accès — une jointure faite ailleurs redérive les trois. La préparation de variables appartient aux carnets Databricks, où sont l'outillage et l'échelle.

Se tromper de partition n'est pas d'abord un problème de performance mais de coût : un tableau de bord branché sur le palier froid fonctionnera, lentement, en consommant du calcul de lakehouse à chaque rafraîchissement.

Par où entrent les données non SAP

BDC Connect porte quatre patrons distincts plutôt qu'un connecteur. Le partage Delta entrant souscrit à des tables publiées par une organisation externe et les fait apparaître comme objets du catalogue. La fédération Iceberg lit des tables Apache Iceberg depuis un stockage objet, sur n'importe quelle implémentation de catalogue Iceberg, de sorte qu'un lac existant devient consommable sans migration. La fédération Snowflake pousse le SQL en direct, le coût de calcul restant côté Snowflake. Le quatrième fédère un espace de travail Databricks exploité par le client sur son propre compte cloud.

Ce qui rend ces patrons architecturaux, c'est que les objets fédérés sont des citoyens de première classe du catalogue : règles d'accès, traçabilité et structure de produit de données s'y appliquent comme aux objets natifs, et la règle d'accès se déclenche à la réécriture de la requête.

La latence n'est pas gratuite : une fédération Iceberg passant par un catalogue externe de type AWS Glue ajoute environ 100 à 300 millisecondes de consultation de métadonnées au-dessus du balayage. Invisible sur une table de démonstration, très visible en production.

Fédérer ou répliquer

Accès exploratoire, faible fréquence, ou besoin de gouvernance consistant simplement à rendre une source visible au catalogue. Fédérez : un agent qui s'ancre de temps à autre sur le partage d'un partenaire ne justifie pas une migration.

Tout ce qui est sensible à la latence et qu'un utilisateur attend — un tableau de bord opérationnel sous deux secondes. Répliquez : la fédération lie votre temps de réponse à la performance du système source, et un balayage de partition froide ajoute des secondes.

Données de fait volumineuses, ou nombreux utilisateurs décisionnels simultanés. Répliquez les faits, fédérez les dimensions et les référentiels à évolution lente ; le seuil retenu dans le corpus se situe autour de 100 gigaoctets de données de fait ou d'une cinquantaine d'utilisateurs simultanés.

Une source dont vous ne maîtrisez pas le calcul à chaque requête. Répliquez et chiffrez le stockage : la fédération déplace discrètement le coût sur la facture de la plateforme source.

Un seul plan de gouvernance, sinon aucun

La promesse est que le contrôle d'accès se définit une fois au niveau du catalogue et atteint tous les consommateurs — SAC, Joule, un carnet Spark, une table fédérée. Elle ne vaut que ce que vaut son point d'entrée le plus faible, et il y en a deux connus.

Le premier est la source fédérée : appliquer les règles dans Business Data Cloud sans toucher aux contrôles du système source laisse un utilisateur bloqué dans le catalogue interroger directement l'entrepôt Snowflake ou le lac Iceberg avec ses propres identifiants.

Le second est l'agent. Dès que des agents consomment la couche sémantique, celle-ci devient un objet de politique : nommage, sécurité au niveau ligne et logique de devises doivent être sûrs pour un agent, pas seulement corrects pour un humain qui lit un graphique. Câbler le catalogue séparément pour les agents et pour les humains est l'erreur d'ouverture classique, et elle est difficile à défaire.

D'où la vraie première question : le client dispose-t-il d'un modèle de propriété des données ? Le catalogue applique des règles, il ne les invente pas.

Ce que nous ne pouvons pas affirmer

Nous ne publions pas d'architecture de référence chiffrée par taille de client : SAP ne publie pas de guide de capacité par composant, donc la répartition du plancher de 128 unités entre les six charges concurrentes relève d'un exercice de dimensionnement, pas d'une règle documentée.

Questions fréquentes

Quels sont les composants de l'architecture SAP Business Data Cloud ?

Cinq : SAP Datasphere comme couche sémantique, un lakehouse géré par Databricks pour le stockage en format ouvert, Joule comme surface de consommation, le graphe de connaissances SAP comme couche d'entités, et le catalogue comme plan partagé de métadonnées et de contrôle d'accès. Le catalogue est la pièce fédératrice.

Business Data Cloud remplace-t-il SAP Datasphere ?

Non : Business Data Cloud contient Datasphere. À l'intérieur, Datasphere se comporte comme avant, à ceci près qu'il résout son catalogue depuis le périmètre de la plateforme. La vraie décision n'est pas quel produit acheter, mais si vous achetez le câblage entre les composants ou si vous le construisez.

Faut-il migrer les données Snowflake ou Iceberg dans la plateforme ?

Non. BDC Connect fédère les sources externes selon quatre patrons — partage Delta entrant, fédération Iceberg, fédération Snowflake, fédération vers un espace de travail Databricks externe — et les objets fédérés deviennent des citoyens de première classe du catalogue. Ne répliquez que là où la latence ou la fréquence rend la fédération coûteuse.

Combien de moteurs de calcul l'architecture comporte-t-elle ?

Trois, positionnés côte à côte plutôt que classés : HANA Cloud pour l'analytique en mémoire à la sous-seconde, Databricks pour l'ingénierie à l'échelle Spark et l'apprentissage automatique, Snowflake pour l'entrepôt élastique et le partage inter-cloud. Chacun ajoute sa supervision, ses coûts et ses compétences.

Sur quoi cette page s'appuie

À lire ensuite