I like structured data because it gives teams contracts they can test. I recommend landing raw tables, transforming with repeatable jobs, and publishing trusted tables that both BI and applications can use.
How a row becomes a business fact
Structured data earns trust when the same row can serve product lookup, finance reporting, support search, and planning without changing meaning.
From checkout row to company decisions
Structured data earns trust when the same row can serve product lookup, finance reporting, support search, and planning without changing meaning.
Where tables usually live
When I talk about "Where tables usually live", I am checking whether Structured Data Architecture can be traced back, trusted, and used by someone making a decision.
Amazon Redshift, BigQuery, Snowflake, Azure Synapse, Databricks SQL, Apache Iceberg tables, Apache Parquet, ClickHouse.
Cloud warehouse services
| Provider | Typical services |
|---|---|
| AWS | AWS Glue, S3, Lake Formation, Athena, Redshift, EMR. |
| Azure | Azure Data Factory, Data Lake Storage, Synapse, Fabric, Databricks. |
| Google Cloud | Dataflow, Dataproc, Cloud Storage, Dataplex, BigQuery. |
Table format pattern
My recommendation in "Table format pattern" is to keep the raw source close enough that the answer can be explained later.
A Netflix style analytics lakehouse is the public pattern to remember. Apache Iceberg grew out of the need to make very large analytic tables safer and easier to evolve, with engines reading consistent table snapshots instead of loose files.
Retail sales table example
I use "Retail sales table example" to keep Structured Data Architecture grounded in a real system, because abstract patterns are too easy to agree with and too hard to operate.
For a retailer, structured data is orders, payments, refunds, and inventory. The ETL job lands raw order tables hourly, transforms them into a daily sales fact table, and publishes a certified revenue dataset used by finance and demand planning.
Certified sales query
I use "Certified sales query" to connect the data type to the person, workflow, or system that will consume it.
with daily as (
select
cast(o.order_created_at as date) as sales_date,
o.store_id,
sum(o.order_total) as gross_sales,
sum(coalesce(r.refund_amount, 0)) as refunds,
count(*) as orders,
count(p.payment_id) as captured_payments
from raw.orders o
left join raw.payments p on p.order_id = o.order_id and p.status = 'CAPTURED'
left join raw.refunds r on r.order_id = o.order_id
where o.order_status = 'CAPTURED'
group by 1, 2
)
insert into analytics.daily_sales
select *,
case when orders = captured_payments then 'CERTIFIED' else 'HOLD' end as data_status
from daily;
The query publishes daily sales with a status flag. Finance gets certified numbers only when captured payments match the order count.
Structured data traps
- Treat schema changes as product changes.
- Keep raw, clean, and serving layers separate.
- Put metric definitions in code, not only dashboards.