ExamFinch.com My Study

Study guide

10.3 Data Sharing and Analytics Hub

Practice this exam

Google Cloud Professional Data Engineer Exam

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

0.1 About the Google Cloud Professional Data Engineer Exam 0.2 Study Strategy & Cloud Data Engineering Methodology

2 Chapter 1: Designing for Security and Compliance

1.1 IAM Roles, Service Accounts, and Least Privilege for Data 1.2 Data Encryption, Key Management, and Privacy with Cloud DLP 1.3 Compliance, Data Sovereignty, and Geographic Placement 1.4 Multi-Environment Architecture: Development, Staging, and Production

3 Chapter 2: Designing for Reliability and Resilience

2.1 High Availability, Disaster Recovery, and Failover Patterns 2.2 Fault Tolerance and ACID Guarantees in Distributed Systems 2.3 Data Validation, Cleansing, and Quality Assurance with Dataform 2.4 AI-Assisted Data Preparation and LLM Query Generation

4 Chapter 3: Architecture Patterns and Flexibility

3.1 Modern Data Architectures: Data Lake, Warehouse, Lakehouse, and Mesh 3.2 Data Migration Strategies and Hybrid/Multi-Cloud Integration 3.3 Database Migration Service and Heterogeneous Database Migrations

5 Chapter 4: Ingestion Architectures: Pub/Sub and Streaming Sources

4.1 Cloud Pub/Sub Core Architecture and Ingestion 4.2 Pub/Sub Advanced Patterns: Dead-Lettering, Ordering, and Schemas 4.3 Change Data Capture (CDC) with Datastream and Batch Ingestion

6 Chapter 5: Stream and Batch Processing with Apache Beam and Cloud Dataflow

5.1 Apache Beam Core Concepts and Pipeline Design 5.2 Advanced Windowing, Watermarks, and Triggers 5.3 Dataflow Pipeline Optimization, Scaling, and Templates

7 Chapter 6: Data Transformation with Dataproc, Data Fusion, and Workflow Orchestration

6.1 Apache Spark and Hadoop with Cloud Dataproc 6.2 Visual Data Pipelines with Cloud Data Fusion 6.3 Workflow Orchestration with Cloud Composer 6.4 AI Data Enrichment inside Data Pipelines

8 Chapter 7: Storage Service Selection and Cloud Storage Architecture

7.1 Google Cloud Storage Service Selection Decision Matrix 7.2 Cloud Storage Architecture, Classes, and Lifecycle Management

9 Chapter 8: Deep Dive into Google BigQuery Storage

8.1 BigQuery Storage Architecture and Data Organization 8.2 Partitioning and Clustering for Performance and Cost 8.3 BigLake and Hybrid Querying across Clouds 8.4 Data Warehouse Modeling: Star Schemas, Denormalization, and Slowly Changing Dimensions

10 Chapter 9: Operational and NoSQL Databases: Bigtable and Cloud Spanner

9.1 Cloud Bigtable Architecture and Row Key Design 9.2 Cloud Bigtable Schema Management and Performance Tuning 9.3 Cloud Spanner: Globally Scalable Relational Database

11 Chapter 10: BigQuery Query Performance and Optimization

10.1 BigQuery SQL Tuning and Performance Best Practices 10.2 BigQuery BI Engine and Materialized Views 10.3 Data Sharing and Analytics Hub 10.4 Preparing Data for Visualization and BI Tool Connectivity

12 Chapter 11: Machine Learning Readiness and Data Governance

11.1 Machine Learning with BigQuery ML 11.2 Feature Engineering and Data Preparation for AI/ML 11.3 Data Governance, Cataloging, and Discovery with Dataplex 11.4 Unstructured Data, Embeddings, and Retrieval-Augmented Generation

13 Chapter 12: Site Reliability Engineering and Monitoring for Data Systems

12.1 SRE Principles for Data: SLIs, SLOs, and SLAs 12.2 Observability: Cloud Monitoring, Cloud Logging, and Alerting 12.3 Troubleshooting Data Pipelines and Workload Failures

14 Chapter 13: Workload Automation, CI/CD, and Cost Optimization

13.1 CI/CD and Version Control for Data Pipelines 13.2 BigQuery Cost Management and Capacity Planning 13.3 Holistic Cost Optimization across GCP Data Services 13.4 Query Workload Management: Interactive vs. Batch Jobs, Queues, and Quotas

10.3 Data Sharing and Analytics Hub

Key Takeaways Explain This Topic AI

BigQuery Analytics Hub is a fully managed data exchange service that enables secure, governed cross-organizational data sharing without physical data replication or brittle ETL pipelines.

The core structural abstractions of Analytics Hub are Data Exchanges (private or public containers), Listings (published data assets), Publishers (data providers), and Subscribers (data consumers).

Subscribers access shared assets via Linked Datasets, which are read-only logical pointers referencing the publisher's live storage blocks in Colossus, providing zero-copy architecture and 0 ms replication lag.

The economic boundary is strictly decoupled: publishers pay 100% of Colossus storage costs for the primary dataset, while subscribers pay for their own query compute slots or on-demand scanned bytes.

Publisher security controls—including Row-Level Security (RLS) and Column-Level Policy Tags with data masking—remain fully active across the listing, enabling privacy-preserving Data Clean Rooms for multi-party collaboration.

Last updated: September 2026

10.3 Data Sharing and Analytics Hub

Note

Cross-organizational data collaboration is a core pillar of modern enterprise data mesh architectures. On the Google Cloud Professional Data Engineer exam, understand how Analytics Hub replaces legacy file exports with zero-copy linked datasets, and how fine-grained security policies and Data Clean Rooms protect sensitive data during multi-party analytics.

In traditional enterprise architectures, sharing data across distinct departments, subsidiary companies, or external corporate partners required fragile, expensive data movement workflows. Data engineers typically authored scheduled batch pipelines that extracted table dumps into Cloud Storage buckets as CSV or Parquet files, transferred files via SFTP or cross-project transfer jobs, and re-ingested the records into the destination warehouse.

This legacy paradigm introduced severe operational challenges: duplicate storage costs, stale data copies, synchronization delays, fragile pipeline maintenance, and severe security risks once sensitive customer data left the perimeter of the primary enterprise warehouse.

To solve these challenges, Google Cloud introduced BigQuery Analytics Hub , a fully managed data exchange platform built natively into BigQuery that enables secure, zero-copy data sharing across organizational boundaries.

Analytics Hub Architecture and Core Abstractions

Analytics Hub establishes a centralized governance framework that enables organizations to publish, discover, and subscribe to shared datasets while keeping the underlying data securely anchored in place. +-------------------------------------------------------------------------+

  • | Publisher Project: finance-prod |
  • | |
  • | +-------------------------------------------------------------------+ |
  • | | Colossus Storage: fact_market_ticks (Encrypted, Governed) | |
  • | | • Publisher pays 100% of Storage Costs | |
  • | | • Row-Level Security & Column Masking Enforced | |
  • | +-------------------------------------------------------------------+ |
  • | | |
  • | v |
  • | +-------------------------------------------------------------------+ |
  • | | Analytics Hub Data Exchange | |
  • | | • Listing: "Global Market Ticks 2026" (Private / Shared) | |
  • | +-------------------------------------------------------------------+ |
  • +-------------------------------------------------------------------------+
  • |
  • +--------------------------+--------------------------+
  • | Zero-Copy Reference | Zero-Copy Reference
  • | (No physical data duplication) | (No physical data duplication)
  • v v
  • +------------------------------------+ +------------------------------------+
  • | Subscriber Project A: risk-analytics| | Subscriber Project B: external-corp|
  • | | | |
  • | +--------------------------------+ | | +--------------------------------+ |
  • | | Linked Dataset: market_ticks_ro| | | | Linked Dataset: market_ticks_ro| |
  • | | • Read-Only Reference Pointer | | | | • Read-Only Reference Pointer | |
  • | | • Subscriber Slot Compute | | | | • Subscriber Slot Compute | |
  • | +--------------------------------+ | | +--------------------------------+ |
  • | | | | | |
  • | v | | v |
  • | SELECT * FROM market_ticks_ro | | SELECT * FROM market_ticks_ro |
  • | [Billed to: risk-analytics] | | [Billed to: external-corp] |
  • +------------------------------------+ +------------------------------------+

Analytics Hub is built around four fundamental concepts:

1. Data Exchange

A Data Exchange is a secured, centrally managed container created by an organization to curate and group related data listings. Data Exchanges can be scoped to different trust boundaries:

Private Exchanges: Restricted to specific internal Google Cloud projects, corporate teams, or authorized external partner organizations. Private exchanges are common in enterprise data mesh implementations to facilitate cross-domain data product consumption.

Public Exchanges: Globally accessible marketplaces (such as Google Cloud Marketplace datasets) containing public data assets, economic benchmarks, geospatial repositories, and commercial third-party datasets.

2. Listing

A Listing is a discoverable package published inside a Data Exchange that references a specific BigQuery dataset. A listing contains rich operational metadata, including title, descriptive documentation, category tags, terms of service, and access controls. Listings can be marked as free, commercial (subscription-based), or restricted.

3. Publisher

The Publisher is the organization or project that owns the original BigQuery dataset and controls its distribution. Publishers define Data Exchanges, create listings, review subscription requests, and manage access permissions via Cloud IAM roles (such as roles/analyticshub.publisher and roles/analyticshub.admin ).

4. Subscriber

The Subscriber is an internal or external consumer who browses a Data Exchange, discovers a listing, and requests access. Once authorized, the subscriber creates a Linked Dataset inside their own Google Cloud project (requiring roles/analyticshub.subscriber ).

Linked Datasets: Zero-Copy Sharing Mechanics

The foundational technical breakthrough of Analytics Hub is the Linked Dataset .

When a subscriber subscribes to an Analytics Hub listing, BigQuery does not copy, duplicate, or export any physical storage blocks from the publisher's project. Instead, BigQuery provisions a read-only, logical reference pointer inside the subscriber's project that links directly to the publisher's underlying dataset in Colossus.

Key Architectural Properties of Linked Datasets

Zero-Copy Architecture: The physical data resides solely in the publisher's Colossus storage blocks. A publisher sharing a 500-terabyte table with fifty separate subscriber organizations consumes exactly 500 terabytes of total physical storage across Google Cloud, completely eliminating storage replication overhead.

Real-Time Data Synchronization: Because the linked dataset points directly to the live publisher storage blocks, any updates, inserts, deletions, or streaming appends committed by the publisher are immediately visible to subscribers the instant the write commits. There is zero replication latency, zero batch synchronization lag, and zero ETL failure points.

Read-Only Enforcement: Linked datasets are strictly read-only for subscribers. Subscribers cannot perform DML modifications ( INSERT , UPDATE , DELETE ), alter table schemas, or drop tables within the linked dataset.

Regionality Constraints: To query a linked dataset, the subscriber's Google Cloud project and the linked dataset must reside in the same geographic region or multi-region as the publisher's source dataset. A dataset hosted in europe-west1 cannot be queried directly from a linked dataset provisioned in us-central1 without cross-region replication.

Decoupled Billing Model

One of the most appealing features of Analytics Hub for enterprise governance is its strict, unambiguous separation of billing responsibilities. +-----------------------------------------------------------------------------+

  • | Analytics Hub Cost Allocation Model |
  • +-----------------------------------------------------------------------------+
  • | Cost Dimension | Responsible Party | Billing Mechanism |
  • +------------------------+-------------------+--------------------------------+
  • | Colossus Storage | Publisher | Billed for Active/Long-Term |
  • | (Physical Table Data) | | Storage in Publisher Project |
  • +------------------------+-------------------+--------------------------------+
  • | Query Compute | Subscriber | Billed to Subscriber Project |
  • | (Analysis & Slots) | | (On-demand TB or Slot Reserva) |
  • +------------------------+-------------------+--------------------------------+
  • | Network Egress | None / Subscriber | $0.00 within same region; |
  • | | | Egress billed if data exported |
  • +-----------------------------------------------------------------------------+
  • 1. Storage Billing (Publisher Responsibility)

The publisher incurs 100% of the storage costs for the primary dataset hosted in their Google Cloud project. Storage is billed according to standard BigQuery active and long-term storage rates. Even if a thousand subscribers query the listing, the publisher never pays an extra penny for storage.

2. Compute Billing (Subscriber Responsibility)

When a subscriber executes a query against a linked dataset:

The compute processing is powered entirely by the subscriber's compute resources .

Under on-demand analysis billing, the subscriber's billing account is charged for the bytes scanned by their query.

Under capacity-based commitments (BigQuery Editions), the query consumes slots from the subscriber's assigned slot reservations.

The publisher incurs zero compute charges when subscribers run heavy analytical queries against the shared data.

Security, Governance, and Data Clean Rooms

Sharing enterprise data externally requires strict governance to ensure regulatory compliance (e.g., GDPR, HIPAA, CCPA) and prevent unauthorized access.

1. Preserving Fine-Grained Security Controls

When a publisher shares a dataset via Analytics Hub, BigQuery preserves all underlying security and access policies:

Row-Level Security (RLS): If the publisher defines row-level security filters based on user identity or corporate domain, these filtering predicates apply dynamically when the subscriber executes queries against the linked dataset.

Column-Level Security and Data Masking: If the publisher applies policy tags with data masking rules (e.g., masking PII fields like Social Security Numbers, phone numbers, or credit cards using SHA-256 hashes or null masking), the subscriber sees only the masked representations. The raw plaintext values are never exposed across the listing.

Authorized Datasets and Views: Publishers can share an authorized view via a listing. The subscriber queries the view without ever gaining access to the underlying raw tables from which the view is derived.

2. Data Clean Rooms: Multi-Party Privacy-Preserving Collaboration

A critical frontier in enterprise data collaboration is the Data Clean Room . A Data Clean Room enables multiple organizations—such as a retail merchant and a media publisher, or two financial institutions combating fraud—to join sensitive datasets on common identifiers (such as hashed email addresses) to perform aggregate analysis without either party exposing raw data to the other . +----------------------------+ +----------------------------+

  • | Organization A (Retailer) | | Organization B (Media Pub) |
  • | Customer Purchase Logs | | Ad Impressions & Clicks |
  • +----------------------------+ +----------------------------+
  • \ /
  • \ Analytics Hub Clean Room Listing /
  • v v
  • +-----------------------------------------------------------------------+
  • | Privacy-Preserving Clean Room Perimeter |
  • | |
  • | • Join Condition: SHA256(a.email) = SHA256(b.email) |
  • | • Privacy Policy: Aggregation-Only (Minimum Threshold = 100 users) |
  • | • Prohibited: SELECT * or raw row-level export |
  • +-----------------------------------------------------------------------+
  • |
  • v
  • +-----------------------------------------------------------------------+
  • | Clean Room Output: Campaign Conversion Rate (Aggregated KPI Only) |
  • | Result: 12.4% conversion across overlapping cohort |
  • | [Zero PII or individual customer transactions exposed] |
  • +-----------------------------------------------------------------------+
  • Clean Room Governance Features in Analytics Hub

Analysis Rules (Aggregation Constraints): Publishers can enforce analysis rules on clean room listings requiring that all queries include GROUP BY aggregations and return a minimum threshold of rows (e.g., a query must aggregate across at least 100 distinct individuals). Queries attempting to inspect individual rows are rejected by the query engine.

Join Constraints: Clean room policies restrict queries to join solely on specific encrypted or hashed join keys (e.g., hashed_customer_id ), preventing unapproved joins with external data.

Differential Privacy Integration: By applying BigQuery's native differential privacy functions, noise is calibrated and added to query results, mathematically guaranteeing that an attacker cannot infer the presence or absence of any single individual in the underlying dataset.

Traditional Data Copying vs Analytics Hub Linked Datasets

Architectural Dimension Traditional Data Copying (ETL / SFTP / GCS) Analytics Hub Linked Datasets

Data Movement & Redundancy Physical data export, network transfer, and storage duplication in destination project. Zero-Copy Architecture ; logical pointer referencing publisher Colossus storage blocks.

Data Freshness Stale batch extracts; synchronization delay of hours or days. Instantaneous (Real-Time) ; streaming writes and DML immediately visible to subscribers.

Storage Expenditure Multiplied storage costs; both publisher and subscriber pay for full table storage. Single storage fee; paid solely by the publisher at standard Colossus rates.

Compute Cost Allocation Complex attribution; publisher pays for extraction ETL, subscriber pays for ingestion and queries. Cleanly decoupled; publisher pays storage, subscriber pays 100% of query compute.

Access Revocation & Control Impossible to revoke data once files are exported and ingested by subscriber. Instant Revocation ; publisher drops listing access, immediately cutting off subscriber queries.

Fine-Grained Governance Lost during export; flat CSV/Parquet files strip RLS and column-level masking. Fully preserved; Row-Level Security, policy tags, and data masking remain actively enforced.

Privacy-Preserving Sharing Requires heavy custom anonymization pipelines prior to file export. Native Data Clean Rooms with mandatory aggregation rules and differential privacy.

Summary of Key Exam Takeaways

Linked Datasets are Zero-Copy: No storage is replicated; queries run against publisher Colossus storage blocks.

Zero-Latency Freshness: Streaming appends and DML modifications are visible immediately to subscribers.

Decoupled Billing Boundary: Publisher pays storage; subscriber pays query compute slots or scanned bytes.

Strict Regional Isolation: Publisher and subscriber datasets must be located in the exact same region or multi-region.

Governance Propagation: Row-Level Security and Column-Level Policy Tags remain active on shared listings.

Data Clean Rooms: Enforce aggregation rules and privacy budgets to allow multi-party analysis without PII exposure.

Loading diagram... Analytics Hub Architecture: Data Exchanges, Listings, Linked Datasets, and Security Governance