Lakehouse and medallion architecture

The lakehouse combines data-lake storage flexibility with table management and transaction capabilities used by analytics workloads. A medallion design separates data by increasing refinement: bronze preserves source-shaped records, silver applies cleaning and conformance, and gold presents trusted, business-oriented products. These are logical quality boundaries, not a requirement to create exactly three physical copies of every table. Keep bronze sufficiently faithful to the source to support replay and investigation. In silver, enforce types, deduplicate according to business keys, and standardize fields. In gold, model clear measures and dimensions for downstream consumers. Name ownership, refresh expectations, and quality rules for each layer. Practice task: trace one arriving order record through bronze, silver, and a daily sales aggregate. Applying the pattern: Land the source with provenance, validate and standardize it, then publish a consumer-focused result with an explicit freshness expectation. Checks and failure modes: Do not confuse a layer name with a quality guarantee. A gold table is only trustworthy when its transformations, tests, and ownership are defined. Before production, test both a representative input and a boundary case. Confirm the expected row grain, permissions, recovery behavior, and observable output for the task. Record the configuration needed to reproduce the run and compare its result with the agreed data contract. Practice task: What is a useful purpose for a bronze layer?