07.12 Data Sharing, OpenSharing, Delta Sharing & Clean Rooms

Enterprise data platforms are valuable not only because they store and govern data, but because they can distribute trusted data products without losing control of the data.

Databricks provides several sharing patterns:

• OpenSharing for direct external sharing;
• Databricks-to-Databricks sharing for governed sharing between Unity Catalog environments;
• Marketplace for product-style distribution;
• Clean Rooms for privacy-preserving multi-party collaboration.

The architect's job is not to memorize these features. It is to decide what should be shared, with whom, under which trust model, and whether the recipient should receive the data or only a controlled computation result.

Official references:

• Secure data and AI sharing
• What is OpenSharing?
• Set up OpenSharing
• OpenSharing SQL reference
• What are Databricks Clean Rooms?
• Create Clean Rooms
• Manage Clean Rooms

1. The fundamental question: share data or share computation?

There are two fundamentally different collaboration models.

Model A — Data sharing

The recipient can consume the shared data.

Use this when:

• the recipient is trusted to analyze the data;
• the provider wants ongoing distribution;
• the recipient needs broad analytical flexibility;
• governance and contractual controls are sufficient.

Architecture:

Provider | Governed share | Recipient | Recipient analytics

Model B — Computation sharing

The participants contribute data, but the parties should not receive each other's raw data.

Use a Clean Room when:

• two organizations need joint analysis;
• raw data is commercially or legally sensitive;
• each party must retain control;
• only approved computation should run;
• output needs controlled disclosure.

Architecture:

Provider A data | +------+ | Clean Room | +------+ | Provider B data

Approved computation | Output

The most important architectural distinction is:

OpenSharing distributes governed data. Clean Rooms enable governed collaboration over data that participants should not directly see.

---

2. What is OpenSharing?

OpenSharing is Databricks' open protocol for secure data sharing with organizations regardless of their computing platform.

It can share:

• tables;
• views;
• filtered data;
• non-tabular assets;
• AI assets supported by the sharing model;
• notebooks in supported scenarios.

OpenSharing is also foundational to Databricks Marketplace and Clean Rooms.

This makes it more than a UI feature.

Think of it as a data-distribution protocol and trust boundary.

---

3. OpenSharing architecture

A useful mental model is:

Unity Catalog | Provider Metastore | Share | Recipient | Open protocol | Consumer platform

Three core concepts are:

Provider

The organization making assets available.

Share

A logical collection of assets intended for distribution.

Recipient

The organization or consumer identity receiving access.

One provider can create multiple shares.

One recipient can consume multiple shares.

---

4. Why sharing belongs in Unity Catalog

Without centralized governance, external sharing becomes:

S3 bucket | IAM user | copied files | email / transfer | consumer

This creates:

• uncontrolled copies;
• unclear ownership;
• weak lineage;
• manual revocation;
• inconsistent security;
• duplicate pipelines.

With Unity Catalog:

Governed asset | classification | access policy | share | recipient | audit / governance

The data product remains connected to the governance model.

---

5. Databricks-to-Databricks sharing

When both organizations use Unity Catalog, native Databricks sharing provides a tighter integration.

Conceptually:

Provider Metastore | Share | Recipient Metastore | Catalog / Shared Asset | Analytics

The recipient consumes the shared asset through its own governed environment.

The recipient does not become the owner of the provider's underlying table.

---

6. OpenSharing vs direct storage access

Do not confuse these models.

Direct S3 access

Consumer | v S3

The consumer gets cloud-storage access.

OpenSharing

Consumer | v Sharing layer | v Provider data

The provider controls the sharing contract.

For enterprise data products, the second model is usually easier to govern.

---

7. Real-time sharing does not mean copying everything

OpenSharing can expose shared data without requiring a traditional ETL copy into the recipient's platform.

This changes the architecture from:

Source ↓ Export ↓ Copy ↓ Transform ↓ Consumer

to:

Governed provider asset ↓ Share contract ↓ Consumer

The provider can therefore maintain a single governed source of truth for supported sharing scenarios.

---

8. What should be shared?

Good candidates:

• curated Gold tables;
• approved dimensional data;
• public or contractual data products;
• partner analytics datasets;
• supplier performance datasets;
• customer-facing analytical products;
• reference data;
• governed views.

Avoid sharing raw Bronze data unless there is a deliberate reason.

A strong pattern is:

Bronze ↓ Silver ↓ Gold ↓ Data Product ↓ Share

---

9. Sharing a view instead of a table

A view can reduce exposure.

Example:

CREATE VIEW analytics.partner_sales AS SELECT customer_region, product_group, month, revenue FROM gold.sales WHERE customer_region != 'INTERNAL';

The recipient gets the approved analytical surface rather than the complete base table.

This is especially useful when:

• columns should be hidden;
• rows should be filtered;
• business logic should remain provider-controlled;
• the provider wants a stable contract.

---

10. Sharing and fine-grained security

Sharing is not a replacement for internal access controls.

Use the layers together:

Unity Catalog | Object permissions | Row filters / masks / ABAC | Approved data product | Share | Recipient

Before sharing, ask:

1. Is the source asset correctly classified?
2. Are sensitive columns removed or protected?
3. Are business rules applied?
4. Is the output contract stable?
5. Is the recipient authorized?
6. Is the sharing action auditable?

---

11. Data product thinking

A share should not be treated as a random table export.

A mature organization publishes:

• product name;
• owner;
• business definition;
• schema;
• refresh expectation;
• quality rules;
• sensitivity;
• usage restrictions;
• support contact;
• version/change policy.

Example:

Supplier Performance Data Product

Owner: Procurement Data Domain Grain: supplier-month Refresh: daily Classification: Confidential SLA: 08:00 UTC Consumers: approved suppliers Contract: v2

The share becomes the distribution mechanism for the data product.

---

12. Marketplace vs direct sharing

Use direct sharing when the relationship is known.

Example:

Your company → strategic supplier

Use Marketplace when the objective is product-style discovery and distribution.

Example:

Data provider ↓ Marketplace product ↓ Multiple consumers

Marketplace is therefore a distribution channel, while OpenSharing is a sharing protocol.

Do not treat them as competing technologies.

---

13. What is a Clean Room?

A Databricks Clean Room provides an isolated environment where multiple parties can collaborate on sensitive data without direct access to each other's underlying data.

Clean Rooms use OpenSharing internally to make assets available to the central isolated environment.

The central environment is ephemeral and managed by Databricks.

A simplified architecture:

Provider A Unity Catalog | Share | +------+ | Central Clean Room | +------+ | Provider B Unity Catalog

Participants can see controlled metadata such as column names and types, but collaborators do not simply browse one another's raw tables.

---

14. Clean Room requirements

Current Databricks Clean Rooms require:

• Unity Catalog;
• serverless compute;
• OpenSharing enabled on the metastore.

Network architecture also matters.

If participant storage is protected by a firewall or private endpoint, the clean-room compute path must be designed accordingly. Databricks provides SecureConnect for supported scenarios.

This is an important enterprise architecture point:

Privacy controls are not sufficient if the network path cannot reach the protected data.

---

15. Clean Room collaboration model

A Clean Room can contain:

• tables;
• views;
• volumes;
• notebooks;
• approved computation.

The central clean-room environment acts as the controlled execution boundary.

The collaboration model can be visualized as:

Party A data ─────┐ | v +-----------+ | Clean Room| +-----------+ ^ | Party B data ─────┘ | Approved code | Output

The participants do not receive unrestricted access to each other's source assets.

---

16. Approval-based Clean Rooms

The approval-based model is useful when every analysis must be reviewed.

Flow:

Collaborator proposes analysis ↓ Review / approval ↓ Approved notebook ↓ Clean Room run ↓ Controlled output

This is appropriate for:

• financial collaboration;
• healthcare research;
• advertising measurement;
• supplier/customer overlap analysis;
• fraud analytics;
• joint market analysis.

---

17. Packaged Clean Rooms

A packaged Clean Room allows a provider to supply analysis logic for a consumer to run while keeping provider implementation details protected.

Think of it as:

Provider | Analysis package | Consumer data | Clean Room | Result

This is useful when the intellectual property is the analytical method itself.

---

18. Clean Room output

Clean Room output should be treated as a governed result, not an unrestricted extraction channel.

Current Databricks output-table patterns can produce temporary read-only tables in the runner's Unity Catalog environment.

This creates a useful boundary:

Sensitive inputs | Isolated computation | Approved output | Recipient governance

Architecturally, output controls are as important as input controls.

---

19. Example: supplier overlap analysis

Company A has:

supplier_id supplier_name spend bank_account

Company B has:

supplier_id supplier_name spend bank_account

Neither company should receive the other's raw supplier table.

The Clean Room can execute an approved analysis:

shared_supplier_count overlapping_supplier_groups aggregate_spend_comparison

The result can be exposed without distributing the underlying tables.

---

20. Example: customer overlap

Two organizations want to determine how many customers overlap.

Bad architecture:

Company A customer table ↓ exported CSV ↓ Company B customer table ↓ join externally

Better architecture:

Company A data + Company B data ↓ Clean Room ↓ approved overlap computation ↓ aggregate result

The architecture minimizes raw-data movement.

---

21. OpenSharing vs Clean Rooms

Requirement	OpenSharing	Clean Room
Recipient needs the data	Excellent	Usually not the primary goal
Known external consumer	Excellent	Good
Consumer can run arbitrary analytics	Supported sharing model	Restricted
Multiple parties contribute data	Possible through separate shares	Core use case
Raw data must remain hidden	Limited	Strong fit
Privacy-preserving collaboration	Not primary	Core purpose
Approved computation	Optional	Core pattern
Isolated execution	Not primary	Core pattern

Decision rule:

If the recipient needs to analyze the shared dataset, think OpenSharing.

If the parties need to analyze together without exposing raw data, think Clean Room.

---

22. OpenSharing vs cloud storage sharing

Dimension	S3/IAM sharing	OpenSharing
Storage-level access	Yes	Abstracted
Governance context	Cloud IAM	Unity Catalog
Data product contract	Manual	Stronger
Cross-platform	Depends on storage	Protocol-oriented
Revocation	IAM/policy based	Sharing object/recipient based
Catalog integration	External	Native governance
Lineage context	Custom	Integrated with platform governance

Cloud-native storage sharing still has valid use cases.

Use it when the consumer explicitly needs object-storage-level access.

Use OpenSharing when the requirement is governed analytical data distribution.

---

23. Security architecture

A mature sharing architecture has multiple layers:

Identity ↓ Unity Catalog authorization ↓ Data classification ↓ Row / column controls ↓ Data product ↓ Sharing policy ↓ Recipient / collaborator ↓ Audit ↓ Monitoring

No single feature should be treated as the entire security model.

---

24. Network architecture

Cross-organization sharing changes the network boundary.

Questions to answer:

• Is the source storage private?
• Is a firewall enabled?
• Does serverless compute need access?
• Is SecureConnect required?
• Which cloud and region contain the data?
• Are cross-region/cross-cloud reads required?
• What outbound destinations are permitted?
• Are compliance security profiles required?

For Clean Rooms, network policy is selected during creation and can be Full Access or Restricted Access in supported configurations.

---

25. Governance and audit

Sharing itself must be governed.

Track:

• provider;
• recipient;
• share;
• assets;
• classification;
• approvals;
• clean-room collaborators;
• notebook executions;
• output assets;
• revocations;
• ownership changes.

A useful governance mart:

sharing.share_inventory sharing.recipient_inventory sharing.asset_inventory sharing.clean_room_runs sharing.output_inventory sharing.access_events

This turns data sharing into an observable enterprise capability.

---

26. SAP/BW to Databricks sharing pattern

A realistic enterprise flow:

SAP S/4HANA ↓ BW / Datasphere / ingestion ↓ Databricks Bronze ↓ Silver ↓ Gold Procurement Data Product ↓ Unity Catalog governance ↓ +--------+ | | OpenSharing Clean Room | | Supplier Joint analysis analytics with partner

This is especially relevant when SAP remains the transactional source but Databricks becomes the enterprise analytical distribution layer.

---

27. Hands-on Lab 1 — Publish a governed data product

Create:

catalog: sharing_demo schema: procurement table: supplier_performance

Add:

• owner;
• business description;
• classification;
• refresh SLA;
• data-quality checks.

Create a consumer-facing view that removes sensitive columns.

Document the contract.

---

28. Hands-on Lab 2 — Design a share

Design:

Provider ↓ supplier_performance_share ↓ External recipient

Define:

• recipient identity;
• assets;
• columns exposed;
• expected refresh;
• revocation process;
• audit requirements.

Do not start by granting S3 access.

Start with the business sharing contract.

---

29. Hands-on Lab 3 — Compare sharing patterns

For the same dataset, design three architectures:

1. S3 bucket sharing;
2. OpenSharing;
3. Clean Room.

For each document:

• security;
• network;
• governance;
• recipient experience;
• cost;
• operational complexity;
• revocation;
• privacy.

Then choose one and justify the decision.

---

30. Hands-on Lab 4 — Clean Room scenario

Create a design for:

Two retailers want to measure overlapping customers without exchanging customer-level records.

Define:

• participants;
• assets;
• approved computation;
• output;
• network policy;
• permissions;
• monitoring;
• retention.

Your final architecture should explicitly show what each party can and cannot see.

---

31. Hands-on Lab 5 — Enterprise sharing operating model

Create a policy that defines:

Data product owner

Responsible for:

• quality;
• semantics;
• classification;
• lifecycle.

Platform team

Responsible for:

• Unity Catalog;
• sharing configuration;
• network;
• audit;
• controls.

Security

Responsible for:

• risk review;
• sensitive-data policies;
• incident response.

Consumer

Responsible for:

• permitted use;
• contractual obligations;
• downstream security.

This is how sharing becomes an enterprise capability rather than an ad-hoc feature.

---

32. Troubleshooting

Recipient cannot access shared data

Check:

• recipient configuration;
• share membership;
• permissions;
• provider state;
• recipient state;
• asset availability.

Clean Room cannot access source storage

Check:

• serverless compute;
• storage firewall;
• private endpoint;
• SecureConnect;
• cloud/region;
• network policy.

Consumer sees too much data

Check:

• source table vs curated view;
• row filters;
• column masks;
• ABAC;
• share contents;
• output design.

Output exposes sensitive information

Review the computation itself.

A Clean Room does not automatically make every possible output safe. The collaboration contract must define what outputs are permitted.

Sharing design became difficult to revoke

You probably implemented storage-level sharing instead of a governed sharing contract.

---

33. Common anti-patterns

1. Share Bronze data

Expose curated data products instead.

2. Share the entire table

Minimize columns and rows.

3. Give external users S3 credentials

Prefer governed sharing when analytical consumption is the requirement.

4. Treat Clean Room as a generic ETL platform

It is a controlled collaboration environment.

5. Ignore output leakage

A safe input boundary can still produce an unsafe output.

6. Ignore network controls

Private storage still needs a valid compute-to-storage path.

7. No owner

Every shared data product needs a business and technical owner.

8. No revocation plan

Define lifecycle before publishing the share.

---

34. Architect decision tree

Does the recipient need the dataset?

Yes → OpenSharing / governed data sharing.

No → continue.

Do multiple parties need joint computation?

Yes → Clean Room.

No → consider a derived data product or controlled API.

Does the recipient need cloud-storage-level access?

Yes → evaluate direct cloud sharing.

No → prefer governed analytical sharing.

Is the dataset intended for broad product discovery?

Yes → consider Marketplace.

Is the data highly sensitive?

Yes → add classification, fine-grained access, contractual controls and potentially Clean Rooms.

---

35. Enterprise reference architecture

┌─────────────────────────────────────────────┐ │ Enterprise Data Estate │ ├─────────────────────────────────────────────┤ │ SAP / CRM / APIs / Files / Streaming │ └──────────────────────┬──────────────────────┘ ↓ Databricks Lakehouse ↓ Unity Catalog Governance ↓ ┌────────────┴────────────┐ ↓ ↓ Data Products Privacy Collaboration ↓ ↓ OpenSharing Clean Rooms ↓ ↓ External Consumers Approved Outputs ↓ ↓ Marketplace Recipient UC └────────────┬────────────┘ ↓ Audit / Lineage / Risk

The architecture separates data publication from privacy-preserving computation.

---

36. Interview questions

What is OpenSharing?

An open protocol for secure data sharing across organizations and computing platforms.

What are provider, share and recipient?

Provider identifies the sharing organization, share groups assets, and recipient identifies the consuming organization or identity.

When would you use OpenSharing instead of S3 access?

When the requirement is governed analytical sharing rather than raw object-storage access.

What is a Clean Room?

An isolated environment for controlled collaboration over sensitive data without giving collaborators unrestricted access to each other's underlying data.

Why do Clean Rooms use OpenSharing?

OpenSharing provides the controlled mechanism for making participant assets available to the central clean-room environment.

What is the key difference between sharing and a Clean Room?

Sharing gives a recipient access to a governed data asset. A Clean Room primarily enables controlled computation across multiple parties' data.

Can Clean Rooms solve output leakage automatically?

No. Output policy and approved computation must be designed carefully.

How would you design SAP-to-partner data distribution?

Ingest SAP data into the governed lakehouse, create a curated data product, apply Unity Catalog controls, then use OpenSharing for normal consumption or a Clean Room when joint computation must keep source data private.

---

37. Production checklist

• Data product has a business owner.
• Technical owner is defined.
• Data classification is complete.
• Sensitive columns are minimized.
• Curated views are used where appropriate.
• Recipient identity is verified.
• Sharing purpose is documented.
• Revocation process exists.
• Audit coverage is tested.
• Lineage is understood.
• Network path is documented.
• Private-storage requirements are tested.
• Clean Room output policy is explicit.
• Consumer responsibilities are documented.
• Contract/SLA is defined.
• Retention and lifecycle are defined.
• Governance metrics include external sharing.
• Incident response covers shared assets.
• Cross-cloud/cross-region requirements are tested.

---

38. Final mental model

Remember:

GOVERN ↓ CLASSIFY ↓ CURATE ↓ PACKAGE ↓ ┌───────────────┐ │ │ ↓ ↓ SHARE COLLABORATE OpenSharing Clean Room ↓ ↓ CONSUME COMPUTE ↓ ↓ └───────┬───────┘ ↓ AUDIT / LINEAGE ↓ MEASURE / REVOKE

The enterprise architect's rule is:

Share trusted data when consumers need the data; use privacy-preserving computation when consumers need the insight but should not receive the underlying data.

That distinction prevents many insecure data-sharing architectures.