Zero Copy et BYOL : comprendre les architectures de partage de données

Beaucoup d'entreprises disposent déjà d'un entrepôt de données central (Snowflake, Databricks, Amazon Redshift, Google BigQuery) avant même d'adopter Data Cloud. Deux architectures permettent de connecter ces systèmes sans reconstruire tout le pipeline de données : le Zero Copy et le BYOL (Bring Your Own Lake). Elles répondent à des besoins différents et il est important, en avant-vente comme en conception technique, de bien distinguer les deux pour ne pas dupliquer inutilement de la donnée ni sous-dimensionner l'architecture.

Zero Copy : accéder sans dupliquer

Le Zero Copy (basé sur les partages Snowflake, Databricks Delta Sharing, ou les intégrations équivalentes chez les autres fournisseurs) permet à Data Cloud de lire directement des données stockées dans un entrepôt externe, sans les copier physiquement dans le lakehouse Data Cloud. Concrètement, la donnée reste hébergée et gouvernée dans l'entrepôt d'origine ; Data Cloud y accède à la demande pour l'utiliser dans un DMO, un Calculated Insight ou un segment.

• Avantage principal : pas de duplication de stockage, donc pas de crédits de stockage Data Cloud additionnels pour cette donnée, et une seule source de vérité à gouverner.
• Cas d'usage typique : une entreprise a déjà un entrepôt Snowflake consolidant des données produits, financières ou transactionnelles, et veut les exploiter dans Data Cloud pour de la segmentation sans dupliquer des téraoctets de données.
• Limite : les performances de lecture dépendent de la disponibilité et de la performance de l'entrepôt source ; un pic de charge côté Data Cloud peut aussi solliciter fortement l'entrepôt distant.

BYOL : votre propre lakehouse comme extension

Le BYOL (Bring Your Own Lake) permet à une organisation d'utiliser son propre espace de stockage cloud (souvent un bucket Amazon S3 dédié) comme extension du lakehouse Data Cloud, plutôt que de dépendre exclusivement de l'infrastructure de stockage gérée par Salesforce. C'est une option pertinente pour les organisations qui ont déjà investi dans une architecture de données cloud et veulent garder un contrôle plus direct sur l'emplacement physique et les coûts de stockage sous-jacents.

La configuration se fait via Data Cloud > Setup > Bring Your Own Lake, en connectant le bucket externe et en définissant les permissions d'accès nécessaires. Contrairement au Zero Copy, qui est un mécanisme de lecture à la demande, le BYOL modifie la couche de stockage physique elle-même utilisée par Data Cloud pour héberger ses propres objets.

Zero Copy Ingress et Egress

Data Cloud distingue deux directions de flux Zero Copy :

1. Zero Copy Ingress : Data Cloud lit des données depuis un entrepôt externe pour les exploiter dans ses propres DMO (cas décrit ci-dessus).
2. Zero Copy Egress (Bring Your Own Lake sharing, ou partage sortant) : à l'inverse, expose des données Data Cloud vers un entrepôt externe pour que les équipes data science ou BI y accèdent directement avec leurs outils habituels (notebooks, requêtes SQL natives), sans passer par les API Data Cloud.

Cette seconde direction est particulièrement utile quand une équipe data science veut entraîner des modèles de machine learning sur des Unified Individuals ou des Calculated Insights sans devoir extraire la donnée via des exports manuels.

Choisir entre Zero Copy, BYOL et ingestion classique

• Ingestion classique (Data Stream) : à privilégier pour des sources qui doivent être mappées finement au modèle DMO, avec Identity Resolution et Calculated Insights construits dessus — c'est le chemin standard pour la majorité des cas d'usage marketing et service.
• Zero Copy : à privilégier quand la donnée existe déjà dans un entrepôt gouverné, en gros volume, et que la dupliquer représenterait un coût de stockage ou une charge de gouvernance disproportionnée par rapport à l'usage.
• BYOL : à envisager surtout dans un contexte d'architecture data déjà mature côté client, avec des contraintes fortes de maîtrise des coûts de stockage ou de souveraineté des données.

Le Zero Copy n'élimine pas totalement la consommation de crédits : les requêtes exécutées sur la donnée partagée consomment des crédits de traitement Data Cloud au moment de l'exécution, même si le stockage lui-même n'est pas dupliqué. Ne présentez jamais le Zero Copy en avant-vente comme "gratuit", mais comme une optimisation du coût de stockage, pas de traitement.

Mise en œuvre pratique

Pour un premier partage Zero Copy avec Snowflake par exemple, la séquence type est : créer un partage de données côté Snowflake vers le compte Salesforce (Snowflake Data Sharing), accepter ce partage côté Data Cloud dans Data Cloud > Data Streams > New > Zero Copy Source, puis mapper les tables partagées vers des DMO comme n'importe quel autre Data Stream. La différence technique se joue essentiellement au niveau du stockage sous-jacent ; le reste du pipeline (mapping DMO, Identity Resolution, Calculated Insights) fonctionne identiquement, ce qui rend cette option transparente pour les équipes qui consomment la donnée en aval.