What This Explains
Dieser Inhalt ist noch nicht in deiner Sprache verfügbar.
Module 6 in the chapter Under the Hood: What Data 360 Sits On, chapter 2 of the Data 360 Architect course. Each module stands on its own. Previous: The Engines, and the Second Layer
The question this module answers: Which Data 360 behavior comes from which foundation?
This is the page to come back to. Every time the course says “you can’t” or “it’s slow” or “it costs more”, there’s usually a reason down here. Here’s the map: the behavior you’ll meet, the foundation behind it, and the chapter where it’s taught.
The rules map
Section titled “The rules map”| What you’ll meet | Why: the foundation | Where it’s taught |
|---|---|---|
| A field’s type can’t change after its data lake object exists | Salesforce’s rule; underneath, every file carries the type and everything downstream is bound to the field (Iceberg itself could widen a type: module 3) | Chapter 3 |
| Names and API names are set once | Everything downstream finds the table and its columns by name | Chapters 3 and 6 |
| You change data by changing what you feed it | Files are written once; change is new files and a new snapshot (modules 2 and 3) | Chapters 1 and 4 |
| Refreshes, transforms and identity resolution can be incremental | Snapshots plus the change feed say exactly what changed (module 4) | Chapters 5, 7 and 9 |
| Some changes force a full rerun | The feed knows what changed in the data, not what a new rule would do to old data (module 4) | Chapters 7 and 9 |
| Every change, even a delete, comes through the stream; nothing is edited by hand in the lake | The lake is built for loads; downstream listens to the feed; the source stays the truth (module 4) | Chapters 1, 4 and 6 |
| Data 360 isn’t the system of record | A columnar lake is built for analysis, not for editing one record (module 2) | Chapter 1 |
| Most work runs in minutes or hours | The lakehouse and its engines are built for volume and history (modules 2 and 5) | Chapters 5 to 12 |
| Real time is a separate design, with stricter limits | Milliseconds come from memory and the low latency store, not files (module 5) | Chapter 13 |
| Data in Snowflake or Databricks can be read without copying | The same open formats (Parquet, Iceberg) on both sides (modules 1 and 3) | Chapter 15 |
| Credits mostly follow rows processed | The engines read rows; fewer rows, fewer runs, incremental work cost less. Fewer columns make queries faster but don’t cut the bill (modules 2 and 5) | Chapter 21 |
| Very frequent small loads aren’t free, even when ingestion is | Each load writes files and snapshots that later work reads (modules 2 and 4) | Chapters 5 and 21 |
| Years of loads don’t pile up, and old versions don’t last forever | Housekeeping merges small files and delete files into big ones, then expires old snapshots; Salesforce runs it, without publishing the schedule (module 3) | Chapters 6 and 21 |
| Long-term history is something you model | Snapshots are for safe writes and short-term recovery, and they expire (module 3) | Chapters 3 and 8 |
| A deletion can flow through, if every step reads the feed | A delete is a write and a snapshot too (module 4) | Chapters 15 and 17 |
| Disaster recovery is designed by you | Salesforce’s guide: beyond Hyperforce’s own resilience, DR “demands a broader architecture”: “replayable ingestion pipelines, replication, and metadata-driven rehydration” | Chapters 16 and 22 |
How to use it
Section titled “How to use it”When something in Data 360 surprises you, ask three questions before you open a support case:
- Is this a lake question or a real-time question? Across many records, or one record now?
- Is this a change to data, or a change to the shape? Data changes ride the feed; shape changes (types, rules, mappings) start over.
- Where are the rows? In Data 360’s lake, in someone else’s lake, or in the real-time layer?
Most of the time, the answer explains the behavior. And when you explain it that way to a team or a business owner, you’re not repeating a rule. You’re showing them how the platform works.
Where this goes next
Section titled “Where this goes next”Chapter 3 starts the practical work: know your data before it comes in. Now you know why that matters so much. The names, types and keys you choose there go into every file, snapshot and job built on top.
What an architect decides here
Section titled “What an architect decides here”- Nothing new to configure. You now have the “why” for the decisions in every later chapter, and three questions to ask when Data 360 surprises you.
Explore
Section titled “Explore”All checked 2026-11-14.
- Data 360 Architecture (opens in a new tab), Salesforce Architects.