Why architecture matters here

BigQuery hides most complexity but not cost. Users write SELECT * and pay for a full scan. Poorly designed schemas explode shuffle. Materialized views + BI Engine give order-of-magnitude speedups when used correctly. Slot reservations vs on-demand shape the bill.

The architecture matters because tuning happens at multiple layers: schema (partitioning + clustering), query (avoid SELECT *), acceleration (BI Engine, MVs), and slots (reservation + autoscaling).

Understanding the pieces means you can tune each independently and get real leverage.

Advertisement

The architecture: every piece explained

The top strip is the compute plane. Client SQL arrives declaratively. Query engine (Dremel) plans an aggregation tree — leaves scan storage, mixers combine partial results. Slot allocator picks slots from a reservation (dedicated capacity) or on-demand pool. Shuffle service handles data exchange between stages over a petabit fabric.

The middle row is storage + acceleration. Capacitor is the columnar format — dictionary encoding, RLE, and adaptive schemes. Colossus is the distributed file system underneath. BI Engine caches hot columns in memory for millisecond response. Streaming ingest uses the Storage Write API for exactly-once inserts with schema evolution.

The lower rows are optimization + governance. Materialized views maintain precomputed aggregates that BigQuery uses automatically. Governance combines IAM + column-level security + data catalog for classification. Ops plans slots, controls cost with quotas and query size limits, optimizes queries, and audits access.

BigQuery — Dremel + Capacitor + Colossus + slot pool + BI Engine cachepetabytes scanned, seconds returnedClient SQLdeclarative queryQuery engine (Dremel)aggregation treeSlot allocatorreservation + on-demandShuffle servicepetabit fabricCapacitorcolumnar formatColossusdistributed storageBI Enginein-memory cacheStreaming ingeststorage write APIMaterialized viewsauto-refreshGovernanceIAM + column-level + data catalogOps — slot planning + cost control + query optimization + auditreadreadcacheingestaccelerategoverngovernplanplan
BigQuery architecture from SQL to storage with acceleration layers.
Advertisement

End-to-end flow

End-to-end: analyst runs a query on a 10 TB table partitioned by day and clustered by user_id. Query engine reads only the relevant partitions (30 days = 300 GB). Slot allocator picks 200 slots from the reservation. Columnar scan reads only requested columns (20 GB). Aggregation tree combines partials. BI Engine caches the hot day. Result returns in 3.4 seconds. Cost: 20 GB scanned. Materialized views for common aggregates would drop this further. Access control: analyst only sees non-PII columns via column-level ACLs.