La réponse courte
L'ancienne règle stipulait qu'« pour analyser une donnée, il faut d'abord la copier ». Le concept de « Zero Copy » remet en question cette prémisse dans de nombreux cas : il est désormais possible d'interroger une table résidant dans un entrepôt de données externe sans la déplacer. Cette capacité est réelle, mais elle substitue un type de coût par un autre : au lieu des coûts de stockage et de pipeline, on supporte des coûts de calcul et une dépendance à la disponibilité de la source.
La décision est judicieuse lorsqu'elle est traitée comme toute décision architecturale : selon les exigences d'utilisation, et non selon la mode.
Les quatre paramètres décisifs
| Paramètre | Favorise le Zero Copy | Favorise l'Ingestion |
|---|---|---|
| Fraîcheur des données | Nécessite toujours les données les plus récentes | Des cycles planifiés suffisent |
| Performance | Analyse et segmentation, tolérance de quelques secondes | Opérations en temps réel, temps de réponse constant |
| Volume et fréquence | Fort volume, peu de requêtes | Volume modéré, requêtes fréquentes |
| Gouvernance | La source maintient une politique stricte | Contrôle total de la copie requis |
Ce tableau explique également pourquoi la plupart des organisations adoptent un modèle hybride : les flux opérationnels sont ingérés, tandis que les flux analytiques lourds restent en place.
Ce qui reste sous la responsabilité de l'équipe même avec Zero Copy
L'accès virtuel supprime le pipeline, mais pas le travail. Les tâches suivantes sont toujours requises : le mappage du schéma au modèle commun, la décision des clés d'identification pour la fédération des profils, la gestion des changements de schéma à la source, et la surveillance de la disponibilité. Un changement de nom de colonne dans l'entrepôt externe brisera une vue virtuelle exactement comme il briserait un ETL.
Par conséquent, l'accord avec l'équipe de données qui gère la source fait partie de la mise en œuvre : notification préalable des changements de schéma, fenêtre de maintenance connue, et budget de requête convenu.
Modèles hybrides efficaces
Résumé interne, détails externes – Les valeurs agrégées pour chaque client sont ingérées dans la couche de fédération, tandis que les lignes de détail restent dans l'entrepôt pour un accès à la demande. C'est le modèle le plus courant et généralement le moins coûteux.
Fenêtre chaude et archive froide – Les 12 à 24 derniers mois sont copiés en interne pour des raisons de performance, et l'historique plus lointain reste accessible virtuellement.
Virtuel d'abord, copie selon l'usage – On commence par un accès virtuel, on mesure la fréquence d'utilisation réelle, et on ne copie que ce qui s'avère être fréquemment utilisé. C'est le moyen efficace d'éviter de copier des données qui ne seront jamais interrogées.
Le lien entre cette décision et la répartition des responsabilités entre les systèmes est détaillé dans les articles Data 360 vs Données CRM et Source de Vérité dans l'Organisation.
Cas d'étude : Une entreprise financière avec 400 millions de lignes
Une société de services financiers souhaitait réaliser une segmentation client basée sur sept ans d'historique de transactions, soit environ 400 millions de lignes stockées dans un entrepôt de données cloud. Le plan initial prévoyait une ingestion complète dans la couche de fédération.
Le pilote a modifié cette décision. Il a été constaté que les segmentations réelles reposaient sur seulement trois calculs : la moyenne mensuelle, la tendance sur 90 jours et la classification des activités, tous pouvant être calculés dans l'entrepôt lui-même. Au lieu de transférer 400 millions de lignes, seules trois colonnes agrégées par client, mises à jour quotidiennement, ont été transférées, tandis que les détails sont restés accessibles virtuellement pour une investigation ponctuelle.
Ce qui a été tranché ici n'était pas la question « virtuel contre copie », mais plutôt la granularité : la question pertinente était la résolution à laquelle la donnée était réellement nécessaire. Une fois cette question élucidée, la question de la copie est devenue secondaire.
Risques courants et actions préventives
| Risque | Manifestation concrète | Action préventive |
|---|---|---|
| Coût de calcul imprévu | Requêtes vastes à haute fréquence | Mesure en pilote et accord préalable |
| Dépendance à la disponibilité de la source | Une panne de l'entrepôt bloque la segmentation | Fallback ou fenêtre chaude copiée |
| Changements de schéma | Vues brisées sans préavis | Accord sur les changements et surveillance du schéma |
| Autorisations mal définies | Exposition plus large que la source | Identité de requête et politique d'exposition écrite |
| Granularité erronée | Transfert de détails non utilisés | Décider de la résolution avant la méthode |
Comment mesurer le succès
| Domaine | Ce qui est mesuré | Fréquence de vérification |
|---|---|---|
| Performance | Temps de réponse pour les requêtes de segmentation clés | Mensuel |
| Coût | Coût de calcul et de transfert par cas d'utilisation (Use Case) | Mensuel |
| Stabilité | Échecs de requêtes et disponibilité de la source | Hebdomadaire |
| Valeur | Segmentations et actions réellement générées | Trimestriel |
Le choix de l'équilibre entre l'accès virtuel et l'ingestion se fait dans le cadre des services d'intégrations et de données.
Liste de contrôle pour la décision Zero Copy
- ☐ Des cas d'utilisation (Use Cases) concrets ont été définis, et non une « capacité générale »
- ☐ L'exigence de fraîcheur des données a été établie pour chaque cas d'utilisation
- ☐ La résolution réelle des données nécessaires a été vérifiée
- ☐ La fréquence des requêtes et le volume de balayage ont été estimés
- ☐ Un accord sur les changements de schéma est en place avec le propriétaire de la source
- ☐ L'identité de la requête et la politique d'exposition ont été définies
- ☐ Un modèle hybride a été examiné avant toute décision binaire
- ☐ Un plan de secours (Fallback) existe en cas de défaillance de la source
- ☐ Un pilote mesuré précède une extension
- ☐ Un responsable de la surveillance des coûts et de l'examen périodique est désigné
Références professionnelles
- Salesforce Data 360 — https://www.salesforce.com/data/
- Salesforce Data 360 Architecture — https://architect.salesforce.com/docs/architect/fundamentals/guide/data-360-architecture.html
- HPI Pro – Intégrations et Données — https://hpi.pro/integrations-data