Data Lake vs Data Warehouse vs Data Lakehouse: Salesforce Data 360 & MDM Architecture

💬 In plain words:

• Data Lake: Ingests raw data in any native format quickly and affordably (schema on read).
• Data Warehouse: Cleans, structures, and indexes curated data for business intelligence and SQL reporting.
• Data Lakehouse: Combines the massive scale of a data lake with the governance, schema structure, and ACID speed of a data warehouse—the core engine of Salesforce Data 360.
• Master Data Management (MDM): Resolves duplicate identities across independent systems to create a single, authoritative Unified Individual profile.

📌 Real-World Architecture Analogy:

• Data Warehouse: The corporate finance data mart—curated star schemas, strict tables, and governed dashboards.
• Data Lake: The scalable cloud storage bucket (e.g., AWS S3)—storing raw JSON payloads, clickstream logs, and high-frequency IoT feeds.
• Data Lakehouse: The modern Data 360 architecture—storing raw lake files with warehouse-level governance and metadata indexing on top.
• MDM / Unified Record: The "golden customer record" sitting on this lakehouse layer, linking disparate IDs across Marketing Cloud, Service Cloud, and Commerce into a single entity.

Storage Architecture & The Lakehouse Pattern

To design scalable enterprise data architectures in Salesforce Data 360, understanding modern data storage paradigms is essential:

• Data Lake: Stores massive volumes of structured, semi-structured, and unstructured data in its native raw state. It delivers cost-effective storage for data engineers and data scientists handling massive raw feeds.
• Data Warehouse: Enforces predefined schemas, relational constraints, and high-performance SQL indexing for operational reporting and BI tools.
• Data Lakehouse: The unified architecture behind Data 360. It unifies low-cost, flexible object storage with enterprise schema governance, transactional integrity, and analytical acceleration. This enables raw ingestion payloads (Data Lake Objects / DLOs) and harmonized models (Data Model Objects / DMOs) to coexist seamlessly.

DATA STORAGE & MDM ARCHITECTURE
├── Data Lake ────────── Raw structured & unstructured storage in native format (Scale)
├── Data Warehouse ───── Curated, structured, schema-governed tables (BI & Analytics)
├── Data Lakehouse ───── Lake scalability + Warehouse performance (Data 360 Foundation)
└── MDM Engine ───────── Identity Resolution ──► Unified Individual (UUID Unified Key)
                         ├── Ingests Marketing Contact IDs, Service IDs, & Commerce IDs
                         └── Powers Segments, Calculated Insights, & Agentforce Grounding

Master Data Management & The Unified Individual

Raw storage and data harmonization alone do not solve the fragmented customer problem. Master Data Management (MDM) provides the logic required to build a single golden record:

• Identity Resolution as the MDM Core: Data 360 acts as an automated, continuous MDM engine by running deterministic and fuzzy match rules on customer identifiers (such as email addresses, hashed phone numbers, and loyalty IDs).
• The Unified Record Key (UUID): When match rules link separate records across systems, Data 360 creates a Unified Individual record assigned a persistent Universally Unique Identifier (UUID).
• Cross-System Linkage: The single Unified Record Id bridges a customer's separate source keys—including their Service Cloud Contact ID, Marketing Cloud Subscriber Key, ERP Customer Number, and E-commerce Profile ID.
• Downstream Consumption: Calculated Insights, audience segmentation, Flow triggers, and Agentforce contextual grounding all run on this unified UUID rather than querying disconnected source systems.

🧠 The Core Principle: A Data Lake holds raw data, a Data Warehouse stores curated tables, and a Lakehouse combines both. In Data 360, Identity Resolution acts as the MDM engine that unifies scattered source IDs under a single golden UUID.

🧭 360 Card: Storage Architecture & MDM

• Core Rule: Lakes are raw and cost-effective; warehouses are structured and curated. Lakehouses combine both, providing the architectural foundation for Salesforce Data 360.
• Key Architectural Gain: The lakehouse design enables continuous streaming ingestion of raw payloads alongside real-time querying, zero-copy federation, and standardized DMO mapping.
• Governance Risk: A data lake without strict modeling guidelines quickly becomes an unusable data swamp. A standalone warehouse cannot handle high-throughput, unstructured event streams efficiently.
• Identity Resolution Role: Resolves fragmented source records into a single Unified Individual with a permanent UUID.
• Downstream Impact: Dynamic segments, Calculated Insights, and Agentforce grounding rely entirely on the consolidated identity layer.
• Scale & Cost Trade-off: Storing raw data is inexpensive, but frequent ad-hoc querying across raw files is compute-intensive. The lakehouse model balances cost and query performance at enterprise scale.

Technical Deep Dive: Questions & Architectural Scenarios

Q: What is the technical difference between a Data Lake, a Data Warehouse, and a Data Lakehouse, and where does the "Unified Profile" originate?

🎯 Core Rule: A lake stores raw data; a warehouse stores clean, curated data; a lakehouse unites both. The Unified Profile is the Master Data Management (MDM) output produced by Data 360 Identity Resolution.

Detailed Architectural Breakdown:

• Data Lake: Stores massive unstructured or semi-structured data in raw formats (such as Parquet, CSV, or JSON) using low-cost cloud storage. Schema is applied at read time.
• Data Warehouse: Ingests cleaned and transformed data into rigid relational schemas optimized for high-performance SQL analytics and BI dashboards.
• Data Lakehouse: Bridges both models by implementing warehouse metadata management, indexing, and ACID transactional guarantees directly over scalable lake storage. Salesforce Data 360 uses this lakehouse architecture.
• Origin of the Unified Profile: The unified profile is generated by Data 360's Identity Resolution engine. Applying configurable match rules (such as exact email, fuzzy name, or phone match) consolidates disconnected source records into a single Unified Individual record keyed by a persistent UUID.

Scenario: Why can't an enterprise simply replace Identity Resolution with a scheduled nightly deduplication job on their core database?

Solution & Analysis:

⚠️ Scalability & Architecture Trap: Running nightly SQL deduplication inside a single CRM or database only cleans data within that specific system. It cannot resolve cross-system customer identities across disconnected enterprise applications.

• Cross-System Boundary Limits: A single CRM deduplication job never sees external records living in E-commerce platforms, Marketing Cloud subscriber tables, POS transaction databases, or cloud warehouses.
• Persistent Global Key (UUID): Data 360 maintains a continuous, persistent UUID across all data streams. As new records, transactions, and event streams ingest, they are linked to the existing unified identity graph in near real time.
• Downstream Activation Binding: Segment publishing, real-time trigger activations, and Agentforce prompt grounding link directly to the Unified Individual UUID. A standard nightly deduplication script cannot provide this real-time, cross-platform activation layer.