Under the Hood: What Data 360 Sits On

Chapter 2 of Data 360 Architect, Part 1: Bringing Data In. Previous: Data 360 in One Picture.

Chapter 1 showed what Data 360 is for and how data flows through it. This class is for architects and aspiring architects, and it goes deeper than what an admin or a developer usually needs. So before we build anything, let’s open the covers. A lot of what surprises people about Data 360 isn’t a Salesforce whim. It comes from what the platform sits on: open-source formats and engines your data engineers already know. Understand them, and the rules in the rest of this course stop being rules to memorize. They become things you can explain.

The positions in this chapter

• Data 360 sits on open formats. Its lake is Apache Parquet files organized as Apache Iceberg tables, in cloud storage on Hyperforce.
• Parquet stores data by column, and files are written once. Great for questions across many records; poor at changing or fetching one record now.
• Iceberg makes files a table. Every change is new files and a new snapshot, swapped in all at once.
• Change is a feed. Snapshots say exactly what changed, which is why Data 360 can work incrementally.
• Two layers, two jobs. The lakehouse, with Spark and Hyper, for volume and history; a separate real-time layer of memory and SSD for milliseconds.
• Bills mostly follow rows. Columnar storage makes queries faster; most credits count rows processed (a few usage types count megabytes or compute).

The path through this chapter

Six modules, each standing on its own.

1. What Data 360 Sits On. The stack from cloud storage to the screens in core, and why open formats matter.
2. Parquet: Data Stored by Column, Written Once. What it is, what it’s good and bad at, and the Data 360 behavior it explains.
3. Iceberg: A Table Over Files. Snapshots and the pointer, what the format allows, and what Data 360 chooses not to.
4. Change as a Feed. Change events and the change data feed: why Data 360 is incremental, and what forces a full rerun.
5. The Engines, and the Second Layer. Spark and Hyper over the lake; the real-time layer and the low latency store beside it.
6. What This Explains. The rules map: every “why can’t I…” in this course, traced to its foundation.

When you’ve finished, check yourself with the chapter study guide: what it covers for the Data 360 Consultant exam, what an architect knows beyond it, the words to know, and a few questions.

What an architect decides here

• Nothing to configure, everything to explain. The picture and the rules map are what you’ll use to explain every later decision, to your team, the business, and the data engineers on the other side of a zero copy connection.
• Which layer answers each use case: the lakehouse, across many records, or the real-time layer, one person now.

Explore

All checked 2026-11-14.

• Data 360 Architecture (opens in a new tab), Salesforce Architects.
• Apache Parquet documentation (opens in a new tab), the Apache Software Foundation.
• Apache Iceberg documentation (opens in a new tab), the Apache Software Foundation.

Next: Understanding Your Data Structures