4 Introduction
4.1 Architecture in Computer Science
In Computer Science (CS) and Software Engineering, the term architecture does not refer to the aesthetic design of a physical building, but to the definition and structure of complex digital systems.
A solid data architecture ensures that information is available to those who need it, in the proper format, securely, and with predictable performance. Yet that definition conceals a more fundamental question: why is it not enough to simply “save data to disk and call it a day”? Why has the industry spent four decades designing and redesigning how analytical data is persisted?
The answer has little to do with aesthetics or technological trends, and much to do with three very concrete physical constraints:
- How information is laid out on disk/memory determines how fast (and how expensive) it is to answer a query.
- How rigid or flexible the persistence system is determines which data types it can store efficiently, and how far it can scale.
- How strict the consistency guarantees offered by the system are determines how costly it is to coordinate concurrent writes.
Every storage architecture—Data Warehouse, Data Lake, or Data Lakehouse, which we will study in subsequent chapters—is ultimately a distinct design choice along these three axes. Before defining them by name, it is worth understanding why they exist: their fundamental purpose from a technical perspective.
4.2 Axis 1: The Cost of Reading Data — Rows vs. Columns
When a database engine executes a query, the bottleneck is rarely CPU performance; it is the volume of data that must be read from disk to answer it. How records are physically organized on storage—row by row or column by column—radically alters how much data must be fetched.
4.2.1 Visualization: Same Data, Two Distinct Physical Layouts
INSERT, UPDATE, and fetching full records.[ 2, Luis, IT, 4100 ]
[ 3, Eva, Sales, 2900 ]
[ 4, Iván, IT, 4600 ]
AVG, SUM) across few columns and many rows.name: [Ana, Luis, Eva, Iván]
department: [Sales, IT, Sales, IT]
salary: [3200, 4100, 2900, 4600]
AVG(salary), the engine reads only the salary column block, skipping everything else.This structural distinction, which might seem like an implementation detail, has massive implications at scale:
- Reduced I/O: If a table has 50 columns and an analytical query only requires 3, a columnar engine reads, in theory, only 6% of the data a row-oriented engine would fetch.
- Superior Compression: A single column holds homogenous data types with lower cardinality (for example, repeating department names), allowing far more aggressive compression algorithms than heterogeneous rows permit.
- Vectorized Execution: Because values for a column sit contiguously in memory, CPUs can apply SIMD operations (summing, filtering, comparing) across entire vectors rather than evaluating record by record.
Consequently, transactional systems (operational databases for e-commerce, banking, or logistics) are row-oriented—they require fast writes and single-record lookups—while analytical systems (Data Warehouses, Data Lakehouses) are column-oriented, or use columnar file formats like Parquet or ORC, because their dominant workload involves aggregations over massive row counts.
4.2.2 OLTP vs. OLAP: Two Distinct Workloads
The choice between row-oriented and column-oriented storage is not arbitrary: it stems from the recognition, since the 1990s, that computing workloads fall into two fundamentally opposing paradigms.
| Criterion | OLTP | OLAP |
|---|---|---|
| Objective | Record daily business operations | Analyze historical business performance |
| Typical Operation | INSERT / UPDATE of single records |
SELECT ... GROUP BY across millions of rows |
| Operation Volume | Few rows, all columns fetched | Many rows, few columns fetched |
| Storage Pattern | Row-oriented | Column-oriented |
| Users | Operational applications (thousands of concurrent transactions) | Data Analysts / BI (fewer, heavier queries) |
| Example | Processing a sale at a Point of Sale | Computing average regional sales over the past year |
This comparison highlights why a Data Warehouse is never queried directly off an operational production database: they represent competing workloads vying for shared resources while requiring opposing physical storage layouts.
4.3 Axis 2: The Cost of Rigidity — Homogeneous vs. Heterogeneous Data
The second axis does not concern how data is laid out inside a table, but rather how willing the persistence system is to accept data that does not fit into a predefined tabular schema.
A traditional relational database requires data to match a rigid schema (defined columns, data types, and constraints) before ingestion. While exceptional for enforcing integrity, this creates a major barrier for non-tabular data: server logs, product images, nested JSON payloads with evolving structures, or audio transcripts.
For decades, organizations either discarded such unstructured data, forcibly transformed it into relational tables (losing context along the way), or stored it in isolated file servers detached from analytics pipelines.
Modern persistence systems solved this dilemma by combining two key concepts:
- Object Storage (such as Amazon S3 or Google Cloud Storage): Storage systems that accept files without imposing schema constraints, offer low storage costs per byte, and scale near-infinitely.
- Self-Describing Open File Formats (Parquet, Avro, JSON, ORC): Files that embed their own schema metadata, allowing structured, semi-structured, and unstructured data to coexist within the same repository without sacrificing query readability.
This pairing enables a Data Lake—and, subsequently, a Data Lakehouse—to house transactional tables, raw product images, and streaming web clickstreams side by side without requiring upfront schema enforcement. Schema resolution, when needed, occurs on read rather than on write.
4.3.1 Scaling Up vs. Scaling Out
The flexibility of a persistence system is also bound to its scaling strategy when data volumes surpass the limits of a single machine. Two primary strategies exist:
Vertical scaling hits a physical and economic ceiling: single servers have hard limits on CPU and RAM, and high-end enterprise servers scale exponentially in cost as they approach those limits. Traditional Data Warehouse relational engines inherited this constraint.
Horizontal scaling, conversely, expands by appending nodes built from commodity hardware. This makes it cost-effective to persist petabytes of heterogeneous data in a Data Lake: capacity scales by adding distributed storage across commodity disks rather than upgrading expensive single-node hardware.
4.4 Axis 3: The Cost of Consistency — ACID vs. BASE
The third axis focuses not on read speed or data flexibility, but on how strictly the system guarantees that stored data remains in a consistent state, even amidst concurrent write operations or system failures.
Enforcing ACID compliance incurs computational overhead: it demands synchronization primitives (locks, transaction logs, constraints) that become increasingly expensive across distributed nodes. Traditional relational databases (designed to scale vertically on single nodes or tightly coupled clusters) enforce ACID efficiently, whereas massively distributed object storage systems (designed to scale out across thousands of nodes) historically adopted BASE guarantees, accepting short consistency delays in exchange for infinite scale and high availability.
This challenge gave rise to the Data Lakehouse: introducing a transactional metadata layer that restores ACID guarantees on top of scalable, BASE-oriented object storage.
4.5 The Purpose of Data Storage Architectures
No single system simultaneously maximizes all three axes: query speed (rows vs. columns), schema flexibility (scale-up vs. scale-out), and consistency guarantees (ACID vs. BASE) exist in trade-off states, as each guarantee carries computational or architectural overhead.
This three-way trade-off defines the design choices behind modern data storage architectures:
- A system may prioritize Axis 1 and Axis 3 (columnar storage and strict ACID), restricting inputs to structured data in exchange for exceptional query performance and absolute consistency.
- A system may prioritize Axis 2 (horizontal scaling and BASE), ingesting any data format with near-unlimited scale, while relinquishing immediate transactional consistency.
- A system may combine all three, overlaying a transactional metadata layer (ACID) on top of scalable, flexible object storage.
In subsequent chapters, we will examine the Data Warehouse, Data Lake, and Data Lakehouse—concrete implementations of these architectural trade-offs. The key insight is that none of these patterns are mere trends; each exists to solve, through deliberate design trade-offs, the fundamental physical constraints of data engineering.