Bigquery architecture
GOOGLE BIGQUERY ARCHITECTURE
============================
USER / APPLICATION
│
│ SQL Query
▼
┌──────────────────────────────────────┐
│ DREMEL │
│ Distributed Query Engine │
│ │
│ ROOT NODE │
│ ▲ │
│ │ │
│ Final Aggregation │
│ │ │
│ ┌────────┴────────┐ │
│ │ │ │
│ MIXER MIXER │
│ ▲ ▲ │
│ │ │ │
│ Intermediate / Partial │
│ Aggregation │
│ ▲ ▲ │
│ │ │ │
│ ┌────┴────┐ ┌────┴────┐ │
│ │ │ │ │ │
│ SLOT SLOT SLOT SLOT │
│ (LEAF) (LEAF) (LEAF) (LEAF) │
│ │ │ │ │ │
│ └─────────┴───┬───┴─────────┘ │
│ │ │
│ Read Data + Compute │
└──────────────────┼───────────────────┘
│
│ Request Required Data
│
▼
═══════════════════════
JUPITER
High-Speed Network Fabric
═══════════════════════
│
│
▼
┌──────────────────────────────────────┐
│ COLOSSUS │
│ Distributed Storage Layer │
│ │
│ CAPACITOR │
│ Columnar Data Format │
│ │
│ ┌──────┐ ┌──────┐ ┌──────┐ │
│ │ Col A│ │ Col B│ │ Col C│ │
│ └──────┘ └──────┘ └──────┘ │
└──────────────────┬───────────────────┘
│
│ Required Columnar Data
▼
═══════════════════════
JUPITER
Network Fabric
═══════════════════════
│
▼
LEAF / SLOTS
Data Processing
│
│ Partial Results
▼
MIXERS
Aggregation Levels
│
▼
ROOT NODE
│
│ Final Result
▼
USER / APPLICATION
┌─────────────────────────────────────────────┐
│ BORG │
│ │
│ Infrastructure / Resource Management │
│ │
│ Supports underlying execution resources │
│ rather than being part of the data path │
└─────────────────────────────────────────────┘
QUERY / DATA FLOW
=================
SQL
│
▼
Dremel
│
▼
Leaf / Slots ───── Request Data ─────┐
│
▼
Jupiter
│
▼
Colossus
│
Capacitor
│
Required Columnar Data
│
▼
Jupiter
│
▼
Leaf / Slots
│
Computation
│
▼
Mixers
│
Partial Aggregation
│
▼
Root Node
│
▼
Final Result
│
▼
UserBigQuery is Google Cloud’s serverless, highly scalable cloud data warehouse. Its key architectural principle is the separation of compute and storage, which allows both layers to scale independently. Dremel provides the distributed compute/query execution layer, Colossus provides distributed storage, Jupiter provides the high-speed network connecting compute and storage, and Borg manages the underlying compute resources. BigQuery also uses a columnar storage format optimized for analytical workloads
The central idea behind Google BigQuery architecture is the separation of compute and storage. Dremel handles distributed query execution, Colossus provides distributed storage, and Google’s Jupiter network connects the two layers. [cloud.google.com]
You can understand the complete architecture by following a query through it.
1. SQL query enters Dremel
When a user or application submits a SQL query, Dremel handles the distributed query execution.
For example:
SELECT country, SUM(sales_amount)
FROM sales
GROUP BY country;
Dremel represents the query as an execution tree so the work can be distributed rather than executed by one machine. [cloud.google.com]
Conceptually:
ROOT NODE
▲
│
MIXERS
▲
│
LEAF / SLOTS
2. Leaf Nodes / Slots read the data
At the bottom of Dremel’s execution tree are the leaves, called slots in Google’s architecture explanation.
This is where much of the actual work happens. The slots read data from storage and perform computation. [cloud.google.com]
The important architectural relationship is:
Leaf / Slots
▲
│ Required Data
│
Jupiter
▲
│
Colossus
The compute layer and storage layer are separate, so leaf-level execution accesses the required stored data through the networking infrastructure. [cloud.google.com]
3. Colossus stores the data
Colossus is Google’s distributed storage system used in the BigQuery architecture. [cloud.google.com]
This gives us the fundamental separation:
COMPUTE
Dremel
│
│
Jupiter
│
▼
STORAGE
Colossus
In other words, storage does not need to be physically coupled with the query-processing resources.
4. Capacitor provides the columnar format
Within the storage architecture, Capacitor refers to BigQuery’s column-oriented storage format.
This distinction is useful:
Colossus
↓
Distributed Storage
Capacitor
↓
Columnar Data FormatFor example, suppose a table has:
customer_id
customer_name
country
product
quantity
sales_amount
order_date
Get Swapnil Surushe’s stories in your inbox
Join Medium for free to get updates from this writer.
and the query needs:
SELECT country, SUM(sales_amount)
FROM sales
GROUP BY country;The analytical operation is primarily interested in:
country
sales_amount
This illustrates why column-oriented organization is well suited to analytical processing.
5. Jupiter connects Colossus and Dremel
Since BigQuery separates compute from storage, it needs networking between those two layers.
That role is provided by Jupiter. Google’s architecture explanation identifies Jupiter as the network connecting the distributed compute and storage systems. [cloud.google.com]
DREMEL
Compute
▲
│
═══════════════
JUPITER
Network Fabric
═══════════════
▲
│
COLOSSUS
StorageTherefore, when the leaf-level slots need data, you can visualize the path as:
Colossus
│
│ Required data
▼
Jupiter
│
▼
Leaf / Slots
6. Leaf / Slots perform computation
Once the required data is available to the execution layer, leaf-level slots perform their portion of the computation. Google explicitly describes the leaves as doing the heavy lifting of reading data from storage and performing computation. [cloud.google.com]
For our aggregation query, conceptually imagine distributed work producing partial results:
SLOT 1 SLOT 2 SLOT 3
IN → 100 IN → 300 IN → 250
US → 200 UK → 150 US → 400
The results now need to be progressively combined.
7. Mixers aggregate intermediate results
Above the leaf level are mixers.
Google describes mixers as branches in Dremel’s execution tree that perform aggregation. [cloud.google.com]
Conceptually:
LEAF LEAF
\ /
\ /
▼ ▼
MIXER
│
▼
Intermediate ResultAs processing progresses, intermediate results move upward through the tree:
Leaf / Slots
│
▼
Mixers
│
▼
Root8. Root produces the final result
The root sits at the top of the Dremel execution tree.
After lower-level computation and intermediate aggregation, results reach the root and the final query result can be returned to the user.
Leaf / Slots
│
▼
Mixers
│
▼
Root
│
▼
Final Result
│
▼
User / ClientSo there are effectively two directions to remember:
Data retrieval
Colossus
↓
Jupiter
↓
Leaf / SlotsResult processing
Leaf / Slots
↓
Mixers
↓
Root
↓
Final Result9. Borg manages underlying resources
Borg belongs to Google’s infrastructure/resource-management layer.
The important point for an architecture diagram is that Borg should not appear as though query data passes through it.
Don’t represent the flow as:
Dremel↓Borg ↓Jupiter ↓Colossus
Instead, represent Borg separately as underlying infrastructure management:
BORG
Resource Management
│
▼
Dremel │
Jupiter
│
ColossusComplete Architecture Flow
Putting everything together:
SQL Query
│
▼
Dremel
│
▼
Execution Tree
│
▼
Leaf / Slots
│
│ Request Required Data
▼
Jupiter
│
▼
Colossus
│
▼
Capacitor / Columnar Data
│
│ Required Data
▼
Jupiter
│
▼
Leaf / Slots
│
│ Parallel Computation
▼
Mixers
│
│ Intermediate Aggregation
▼
Root Node
│
▼
Final Result
│
▼
User / Application
Borg
└── Underlying Resource ManagementIn one paragraph
BigQuery separates query computation from data storage. When a SQL query is submitted, Dremel organizes its distributed execution as a tree. At the bottom of this tree, leaf-level slots read the required data from the Colossus storage layer and perform computation. Because compute and storage are decoupled, communication between them occurs through Google’s Jupiter network. The intermediate results generated by leaf-level execution move upward through mixer nodes, which perform aggregation, before reaching the root of the execution tree and ultimately producing the final result. Colossus provides distributed storage, while BigQuery uses a column-oriented storage format for analytical data. Borg belongs to the underlying resource-management infrastructure rather than the query’s data path. [cloud.google.com]
