Study guide
5.3 Zero-Copy Data Federation & Snowflake/BigQuery/Databricks Sharing
Salesforce Certified Data 360 Consultant formerly Data Cloud Consultant
Track your progress as you read
Finished sections get a check mark.
1 Chapter 1: Solution Overview & Enterprise Value
1.1 Enterprise Customer 360 & Data Cloud Business Value 1.2 Architectural Foundation: Zero-Copy, Hyperforce, Lakehouse & Data Pipeline 1.3 Platform Terminology, Core Entities & Data Lifecycle Stages 1.4 Data 360's Foundational Role in Predictive & Generative AI
2 Chapter 2: Ethics, Privacy & Governance Fundamentals
2.1 Regulatory Compliance, Data Privacy & Ethics in Customer Data 2.2 Consent Management & Preference Enforcement in Data Cloud 2.3 Data Retention, Deletion, and Privacy Right-to-be-Forgotten (RTBF)
3 Chapter 3: Security, Permissions & Tenant Architecture
3.1 Standard Permission Sets, User Roles & Functional Access 3.2 Data Spaces Architecture, Resource Allocation & Tenant Isolation
4 Chapter 4: Administration, Monitoring & Lifecycle Management
4.1 Data Kits & Package Automation for Cross-Org Deployment 4.2 Auditing, Status Monitoring, Error Logs & Data Explorer 4.3 Sandboxes, Change Management & Metadata Deployment
5 Chapter 5: Ingestion Connectors & Source Integration
5.1 Standard Bundles & Salesforce CRM Connectors (Sales/Service/Marketing) 5.2 Cloud Storage (S3, GCS, Azure Blob) & Streaming Ingestion (Web/Mobile SDK, Ingestion API) 5.3 Zero-Copy Data Federation & Snowflake/BigQuery/Databricks Sharing
6 Chapter 6: Data Lake Objects (DLO) & Data Transformations
6.1 DLO Configuration, Primary Keys, Event Time & Data Stream Categories (Profile, Engagement, Other) 6.2 Streaming & Batch Data Transforms: Formula Fields, SQL Transforms & Data Prep Recipes
7 Chapter 7: Data Model Objects (DMO) & Canonical Harmonization
7.1 Customer 360 Canonical Data Model & Subject Areas 7.2 DLO-to-DMO Mapping Patterns, Cardinality & Custom DMO Design 7.3 Data Validation, Schema Maintenance & Field Mapping Best Practices
8 Chapter 8: Identity Resolution Architecture & Match Rules
8.1 Identity Resolution Concepts, Consolidation Rate & Graph Modeling 8.2 Match Rules & Match Criteria: Exact Match vs. Fuzzy Matching (Deterministic & Probabilistic) 8.3 Multi-Party Identification, Anonymous-to-Known Transitions & Contact Point Matching
9 Chapter 9: Reconciliation Rules & Unified Profile Governance
9.1 Reconciliation Rules: Most Frequent, Source Priority & Last Updated 9.2 Unified Profile Schema (Individual & Contact Points) & Resolution Troubleshooting
10 Chapter 10: Segment Architecture & Audience Design
10.1 Segmentation Canvas, Segment Types (Standard UI & Flow) & Query Processing 10.2 Direct vs. Related Attributes, Cardinality & 1:N Filtering Traps 10.3 Segment Schedule, Refresh Frequencies & Exclusion Logic 10.4 Segment Membership Analysis, Population Drift & Sizing Validation
11 Chapter 11: Calculated & Streaming Insights
11.1 Calculated Insights (CI) Architecture, SQL/Builder Syntax & Dimensions vs. Metrics 11.2 Streaming Insights (SI) Architecture, Windowing (Tumbling/Sliding) & Real-Time Signals 11.3 CI vs. SI Architectural Decision Matrix & Performance Optimization
12 Chapter 12: Data Enhancements, Sharing & Analysis
12.1 Referencing Data 360 Data from Other Systems: Enrichments, Related Lists, Data Graphs & APIs 12.2 Reports, Dashboards & Tableau Analysis on Data 360 Data 12.3 Applying Predictive & Generative AI Tooling to Customer Scenarios
13 Chapter 13: Activation Targets & Outbound Activation
13.1 Activation Targets: Marketing Cloud, External Platforms, Cloud Storage & Data Spaces 13.2 Activation Configuration: Audience Mapping, Related Attributes & Payload Optimization 13.3 Activation Schedules, Publishing Cadence & Incremental vs. Full Refresh 13.4 Activation Troubleshooting: Error Logs, Rejection Reasons & Delivery Failures
14 Chapter 14: Real-Time Data Actions & Flow Automation
14.1 Data Action Targets & Webhook/Platform Event Architecture 14.2 Data Cloud-Triggered Flows & Real-Time Business Orchestration 14.3 End-to-End Enterprise Scenario Walkthrough: Ingestion to Closed-Loop Action
5.3 Zero-Copy Data Federation & Snowflake/BigQuery/Databricks Sharing
Key Takeaways Explain This Topic AI
Zero-Copy architecture virtualizes external data platforms without physical data movement, eliminating traditional ETL/ELT pipelines, redundant storage costs, and synchronization latency.
Inbound Data Federation enables Data Cloud to register external tables from Snowflake, Google BigQuery, Databricks, and AWS Redshift as Virtual Data Lake Objects (vDLOs), which can be mapped directly to canonical DMOs for segmentation, insights, and identity resolution.
Outbound Data Sharing exposes Data Cloud harmonized DMOs, Calculated Insights, and Unified Profiles directly to external data platforms (via Snowflake Secure Data Sharing and Databricks Delta Sharing) using open Apache Iceberg metadata catalogs.
Bi-directional Zero-Copy integration establishes a closed-loop customer data lifecycle: external enterprise data warehouses run machine learning models joining real-time Data Cloud signals with historical ERP records and federate predictive scores back into Data Cloud without physical data transfer.
While Zero-Copy eliminates storage replication, cross-network query pushdown consumes compute resources on the external warehouse (e.g., Snowflake virtual warehouse credits) and introduces query latency compared to locally stored Parquet files.
Last updated: September 2026
Zero-Copy Data Federation & Snowflake/BigQuery/Databricks Sharing
For decades, enterprise data engineering has been trapped in the "Copy Problem" . When an organization needed enterprise data warehouse records inside a customer data platform, data teams built complex Extract, Transform, Load (ETL) or Reverse ETL pipelines: copying gigabytes or terabytes of data across cloud boundaries, duplicating storage costs, establishing brittle scheduled sync jobs, and introducing hours or days of synchronization lag.
Salesforce Data Cloud solves this fundamental architectural bottleneck through Zero-Copy Data Architecture . By leveraging open table formats like Apache Iceberg and Delta Lake , Data Cloud can federate queries directly against external cloud data platforms—including Snowflake , Google BigQuery , Databricks , and AWS Redshift —and share Data Cloud Customer 360 data back to those platforms with zero physical data movement .
Principles of Zero-Copy Architecture vs. Traditional ETL/ELT
To succeed on the Data Cloud Consultant exam, you must distinguish between physical data ingestion and virtual data federation. Traditional ETL/ELT Pipeline (Physical Copy):
[External Warehouse] --> [Nightly Batch Extract] --> [S3 / GCS Staging] --> [Data Cloud Ingest] --> [Duplicate Storage]
* High Latency (Hours/Days) * High Egress & Storage Costs * Brittle Pipeline Maintenance
Zero-Copy Inbound Federation (Virtual Access):
- [External Warehouse] <---------------- Query Pushdown ----------------- [Salesforce Data Cloud]
- (Snowflake/BigQuery) ----------------- Iceberg / Arrow Metadata -------> (Virtual DLO / Canonical DMO)
- * Zero Data Movement * Zero Duplicate Storage * Near-Real-Time Data Freshness
- The Core Pillars of Zero-Copy
Data Virtualization : Rather than copying raw bytes from an external table into Data Cloud's Hyperforce lakehouse storage, Data Cloud catalogs the external table's metadata and schema definition. It registers a Virtual Data Lake Object (vDLO) that behaves identically to a standard physical DLO within the platform.
Query Pushdown & Distributed Execution : When a user runs a segment, builds a Calculated Insight, or executes a query involving a vDLO, Data Cloud's query engine translates the operation into a native SQL query and pushes execution down into the external data platform's compute engine. Only the final aggregated or filtered result set is returned across the secure network link.
Open Table Formats (Apache Iceberg & Delta Sharing) : Zero-Copy relies on open table standards. By utilizing Apache Iceberg metadata specifications, Data Cloud and modern lakehouses speak a universal, language-agnostic data representation that decouples storage from compute.
Comparative Architectural Matrix: ETL Ingestion vs. Zero-Copy Federation
Architectural Vector Traditional ETL / Batch Ingestion Zero-Copy Data Federation
Physical Data Movement High. Data is extracted, serialized, moved over the network, and written to Data Cloud storage. Zero . Data remains strictly within the external warehouse/lakehouse storage tier.
Storage Costs Dual storage billing: paying for storage in both the source warehouse and Data Cloud. Single storage billing : storage is billed only once (at the external cloud provider).
Data Freshness Stale / Latent. Governed by batch extraction schedules (e.g., hourly or nightly). Live / On-Demand . Queries execute directly against the latest committed source records.
Compute Attribution Ingestion compute consumed on Data Cloud; transform compute consumed on ETL middleware. Query compute is consumed on the external data warehouse (e.g., Snowflake warehouse credits).
Network Overhead Continuous massive file transfers (gigabytes/terabytes of daily snapshots). Minimized. Only query execution predicates and filtered result sets traverse the network.
Schema Drift Impact Pipelines break catastrophically when source columns are renamed or dropped. Schema changes in source tables cause query pushdown validation errors until metadata is re-cataloged.
Inbound Data Federation: Snowflake, BigQuery, Databricks & Redshift
Inbound Data Federation allows Data Cloud to query external enterprise datasets in-place. The external tables appear directly within Data Cloud as Virtual Data Lake Objects (vDLOs), allowing consultants to map them to standard Customer 360 Data Model Objects (DMOs).
1. Snowflake Inbound Federation
Mechanics : Utilizes Snowflake's support for Apache Iceberg Tables and cross-cloud data sharing.
Connection : Established via a secure Snowflake Partner Integration using OAuth or key-pair authentication. Data Cloud reads Snowflake metadata catalogs and executes pushed-down SQL against a designated Snowflake Virtual Warehouse.
Use Case : Ingesting 10 years of historical Point-of-Sale (POS) transactions or financial ledger data directly into the Sales Order canonical DMO without duplicating 500 million historical rows into Data Cloud.
2. Google BigQuery Inbound Federation
Mechanics : Integrates with Google Cloud via the BigQuery Storage Read API and Google Cloud IAM service account federation.
Use Case : Quoting real-time ad campaign performance metrics, Google Analytics 4 (GA4) raw event tables, or enterprise data warehouse tables directly inside Data Cloud segmentation without building GCS export pipelines.
3. Databricks Inbound Federation
Mechanics : Leverages the open Delta Sharing protocol and Databricks Unity Catalog . Data Cloud securely connects to Databricks recipients, querying Delta Lake tables natively.
Use Case : Accessing machine learning feature stores, churn propensity scores, and product recommendation matrices generated by Databricks data science pipelines.
4. Amazon Redshift Inbound Federation
Mechanics : Connects to AWS Redshift clusters or Redshift Serverless via the Amazon Redshift Data API and AWS IAM cross-account authentication.
Outbound Data Sharing: Exposing Data Cloud Customer 360 Assets
Zero-Copy is truly bi-directional. While Inbound Federation brings warehouse data into Data Cloud, Outbound Data Sharing allows enterprise data scientists, business intelligence teams, and data engineers to access Data Cloud's harmonized Customer 360 assets directly from their external analytics platform without reverse-ETL tools or file exports . ┌────────────────────────────────────────────────────────────────────────┐
- │ Salesforce Data Cloud Tenant │
- │ - Unified Individual Profiles (Consolidated Identity Graph) │
- │ - Calculated Insights (Recency, Frequency, Monetary Scores) │
- │ - Harmonized DMOs (Contact Points, Cases, Orders, Products) │
- └───────────────────────────────────┬────────────────────────────────────┘
- │ Outbound Zero-Copy Share
- │ (Apache Iceberg Metadata Sharing)
- ▼
- ┌────────────────────────────────────────────────────────────────────────┐
- │ External Data Cloud Platforms │
- │ │
- │ Snowflake Data Share Databricks Delta Sharing │
- │ - Appears as a native read-only - Appears as an external Unity │
- │ database in Snowflake Catalog Delta Share │
- │ - Joined directly with ERP tables - Fed directly into PySpark and │
- │ using standard SQL MLflow model training pipelines │
- └────────────────────────────────────────────────────────────────────────┘
- How Outbound Data Sharing Operates
Data Share Creation : In Data Cloud Setup, an administrator creates a Data Share , selecting the specific Data Model Objects (DMOs), Unified Profiles, or Calculated Insights to expose.
Data Share Target : The administrator associates the Data Share with a Data Share Target (e.g., a specific Snowflake Account Identifier or Databricks recipient token).
Native Database Mount : In the external platform (such as Snowflake), the share appears instantly as a native, read-only database. Analysts can query Data Cloud tables using standard SQL: SELECT * FROM DATA_CLOUD_SHARE.CUSTOMER_360.UNIFIED_INDIVIDUAL__DMO; .
Bi-Directional Zero-Copy Integration: The Closed-Loop Enterprise Lifecycle
The full power of Zero-Copy manifests when an enterprise unites inbound federation and outbound data sharing into a continuous, closed-loop customer intelligence cycle :
Capture & Harmonize : Data Cloud captures real-time web/app interactions via the Web & Mobile SDK and streams CRM records via standard connectors.
Outbound Share to Snowflake : Data Cloud shares harmonized Unified Individual records and real-time behavioral signals to Snowflake via Zero-Copy Data Sharing.
Advanced Machine Learning Scoring : Within Snowflake or Databricks, enterprise data scientists run sophisticated predictive AI models (e.g., Customer Churn Probability, Next-Best-Action Propensity), combining Data Cloud's live Customer 360 profile with 15 years of on-premise ERP billing and supply chain history.
Write Predictions to Analytics Table : The data science model writes the generated scores to a Snowflake table ( CUSTOMER_ML_SCORES ).
Inbound Zero-Copy Federation : Data Cloud connects to CUSTOMER_ML_SCORES as an Inbound Virtual DLO (vDLO) and maps the churn score to the Individual DMO.
Real-Time Operational Activation : The churn score is immediately accessible in the Data Cloud Segmentation Canvas! Marketers build a segment: Churn_Risk_Score > 0.85 AND Recent_Service_Case_Count > 2 , activating the audience to Marketing Cloud for retention campaigns and triggering real-time Alerts for Service Cloud agents.
All of this occurs without a single byte of data being extracted to flat files, SFTP drops, or intermediate ETL storage.
Performance, Latency, Governance, and Cost Tradeoffs
While Zero-Copy architecture provides extraordinary strategic agility, consultants must evaluate critical architectural tradeoffs when deciding between Zero-Copy federation and physical batch ingestion:
1. External Warehouse Compute Consumption & Cost
Inbound federated queries execute in the remote system's compute layer. When Data Cloud evaluates a segment or calculates an insight involving an Inbound vDLO from Snowflake, it spins up the designated Snowflake Virtual Warehouse.
Cost Impact : If an enterprise configures 20 complex segments that refresh every hour against unindexed, multi-billion-row Snowflake tables, Snowflake virtual warehouse credits will burn continuously, resulting in unexpected compute invoices.
2. Query Latency & Interactive Personalization
Because federated queries traverse cloud networks and depend on remote query compilation, vDLO queries typically exhibit higher latency (seconds to minutes) than queries against locally cached lakehouse Parquet partitions. For millisecond real-time web personalization, physical ingestion or caching is superior to federated queries.
3. Data Governance, Data Spaces & Row-Level Security
When external tables are federated into Data Cloud, external row-level security (RLS) policies and dynamic masking applied in Snowflake or BigQuery may not automatically translate into Data Cloud. Consultants must enforce data segregation inside Data Cloud by provisioning dedicated Data Spaces and applying role-based permission sets.
Decision Framework: Zero-Copy vs. Physical Ingestion
Criteria Choose Zero-Copy Data Federation Choose Physical Data Ingestion
Data Volume Petabyte-scale, multi-billion row enterprise datasets. Low to moderate dataset volumes (megabytes to tens of gigabytes).
Primary Use Case Analytical segmentation, Calculated Insights, BI enrichment. Millisecond real-time edge personalization, continuous identity clustering.
Source System Nature Centralized, high-performance lakehouse (Snowflake, BigQuery, Databricks). Disparate legacy databases, operational POS systems, third-party SaaS tools.
Storage Budget Client strictly mandates avoiding dual storage costs. Client has ample storage capacity and prioritizes query execution speed.
Critical Exam Traps & Consultant Pitfalls
Warning
The Snowflake Virtual Warehouse "Bill Shock" Trap An architect implements Inbound Zero-Copy Federation to query a 1.5-billion-row order history table residing in Snowflake. The marketing team creates 10 segments referencing this virtual DLO and sets each segment schedule to refresh every 1 hour. At the end of the first billing cycle, the client is shocked by an astronomical Snowflake credit bill!
Exam Reality : Segment refreshes on virtual DLOs actively wake up and consume compute credits on the external Snowflake Virtual Warehouse. To prevent bill shock, certified consultants must:
Right-size and auto-suspend Snowflake virtual warehouses (e.g., auto-suspend after 60 seconds of inactivity).
Ensure Snowflake source tables are clustered on frequently filtered attributes (e.g., Customer_Id , Transaction_Date ).
Optimize segment schedules to daily or 12-hour cadences rather than rapid hourly polling.
Caution
The Direct Identity Resolution on High-Volume vDLOs Trap A consultant maps an Inbound Virtual DLO containing 200 million unindexed records directly to the Individual DMO and includes it in an Identity Resolution ruleset with multiple complex fuzzy match rules. During identity resolution runs, jobs fail consistently with cross-network query timeout errors.
Consultant Mandate : Identity resolution requires intensive, iterative graph traversal. Attempting to execute full-scale graph clustering across remote, un-materialized virtual tables creates massive network serialization bottlenecks. Best practice is to physically ingest core profile identifiers into native DLOs, reserving Zero-Copy federation for transactional and contextual analytical enrichment.