Published Sunday, 1:29 a.m. 14 min read

Google BigQuery - Bài học 2: Giải phẫu kiến trúc BigQuery – Tách biệt hoàn toàn Compute (Dremel) và Storage (Colossus)

Chào anh em! Ở Bài học 1, chúng ta đã hiểu tại sao các hệ quản trị cơ sở dữ liệu OLTP truyền thống như MySQL hay PostgreSQL lại "tắc thở" khi phải chạy các câu lệnh báo cáo quét qua hàng trăm triệu dòng. Đồng thời, chúng ta cũng đã biết Google BigQuery có thể nuốt trọn hàng Terabyte dữ liệu chỉ trong vài giây mà không cần bạn phải tạo bất kỳ một cái B-Tree Index nào.

Đến đây, chắc chắn máu kỹ sư trong người anh em sẽ đặt ra một câu hỏi lớn: "Bên dưới lớp vỏ Serverless đó, Google đã thiết kế kiến trúc của BigQuery như thế nào?" Làm sao nó có thể lưu trữ hàng Petabyte dữ liệu với chi phí rẻ như bèo, nhưng khi cần tính toán lại lập tức huy động được hàng ngàn nhân CPU chạy song song mà không hề bị nghẽn cổ chai?

Câu trả lời nằm ở triết lý thiết kế kinh điển của các Cloud Data Warehouse hiện đại: Sự tách biệt hoàn toàn giữa Tính toán (Compute) và Lưu trữ (Storage), được chống lưng bởi "Bộ tứ siêu đẳng" trong hạ tầng nội bộ của Google: Colossus, Dremel, Capacitor và Jupiter.

Hãy cùng cầm dao mổ và giải phẫu từng thành phần ngay bây giờ!

1. Nỗi đau của kiến trúc truyền thống: Khi Compute và Storage "dính chặt" vào nhau

Trước khi nhìn vào BigQuery, hãy nhìn lại cách chúng ta vẫn triển khai một cụm Database truyền thống (như MySQL/PostgreSQL trên EC2/Compute Engine hoặc cả các hệ thống Data Warehouse thế hệ cũ như Redshift/Hadoop đời đầu).

Trong kiến trúc Tightly-Coupled (Gắn kết chặt) hoặc Shared-Nothing Architecture:

Mỗi máy chủ (Node) đều chứa cả CPU + RAM (Compute) lẫn Ổ cứng SSD/HDD (Storage) gắn trực tiếp trên máy đó.
Kịch bản đau thương 1 (Thừa CPU, thiếu ổ cứng): Dữ liệu lịch sử của công ty bạn tăng lên 20 TB mỗi năm, nhưng số lượng người vào chạy báo cáo không tăng. Để có thêm chỗ chứa 20 TB đó, bạn bắt buộc phải nâng cấp lên gói Server to hơn (hoặc thêm Node mới), kéo theo việc phải trả tiền cho hàng chục nhân CPU và hàng trăm GB RAM hoàn toàn... ngồi chơi xơi nước!
Kịch bản đau thương 2 (Đủ ổ cứng, cháy CPU): Dữ liệu của bạn chỉ có 500 GB, nhưng cứ đúng 9h sáng thứ Hai đầu tuần, 50 nhân sự từ team Vận hành, Marketing, Kế toán cùng bấm làm mới Dashboard báo cáo. CPU vọt lên 100%, hệ thống treo cứng. Để giải quyết, bạn phải thuê một con Server cấu hình "khủng" chạy 24/7 chỉ để phục vụ cho đúng... 1 tiếng cao điểm sáng thứ Hai. 23 tiếng còn lại trong ngày là sự lãng phí tiền bạc khổng lồ.

2. Cuộc cách mạng của BigQuery: Tách rời Compute và Storage (Disaggregated Architecture)

Google giải quyết triệt để bài toán trên bằng cách đập vỡ mối liên kết vật lý giữa CPU/RAM và Ổ cứng. Trong BigQuery, nơi cất giữ dữ liệu và nơi xử lý câu lệnh SQL là hai thế giới hoàn toàn độc lập:

+-----------------------------------------------------------------------+
|                       CLIENT / BI DASHBOARD / API                     |
+-----------------------------------------------------------------------+
                                    | (Gửi câu lệnh SQL)
                                    v
+-----------------------------------------------------------------------+
|  TẦNG COMPUTE: DREMEL (Cụm hàng ngàn CPU/RAM - "Slots")               |
|  - Không lưu trữ dữ liệu lâu dài (Stateless).                         |
|  - Chỉ thức dậy khi có Query, tính xong trả kết quả rồi giải phóng.   |
+-----------------------------------------------------------------------+
          ^                         ^                         ^
          |                         |                         |
+-----------------------------------------------------------------------+
|            MẠNG LƯỚI JUPITER (Băng thông hàng Petabit/giây)           |
+-----------------------------------------------------------------------+
          |                         |                         |
          v                         v                         v
+-----------------------------------------------------------------------+
|  TẦNG STORAGE: COLOSSUS (Hệ thống lưu trữ phân tán toàn cầu)          |
|  - Dữ liệu được nén dạng cột (Capacitor).                             |
|  - Tự động nhân bản (Replication), tự phục hồi khi hỏng ổ cứng.       |
+-----------------------------------------------------------------------+

Lợi ích trực diện của kiến trúc này đối với anh em làm hệ thống là gì?

Scale độc lập 100%: Bạn có thể lưu trữ 500 Petabyte dữ liệu mà không tốn một đồng thuê CPU nào nếu không chạy query. Ngược lại, khi có một câu truy vấn siêu nặng, Google có thể điều động ngay lập tức 2.000 Slots (CPU ảo) vào xử lý trong 3 giây, sau đó thu hồi lại ngay.
Chi phí lưu trữ rẻ ngang Google Cloud Storage (GCS): Bạn chỉ trả khoảng $0.02 / GB / tháng cho dữ liệu đang hoạt động (Active Storage), và giảm một nửa xuống còn $0.01 / GB / tháng nếu bảng/partition đó không bị sửa đổi trong 90 ngày liên tiếp (Long-term Storage) mà hiệu năng truy vấn không hề giảm đi một chút nào!
Zero Downtime Scaling: Không còn khái niệm "nâng cấp ổ cứng phải chờ bảo trì hay Rebalance lại dữ liệu giữa các Node" mất hàng chục tiếng đồng hồ.

3. Giải phẫu 2 trái tim của BigQuery: Colossus và Dremel

Để kiến trúc tách biệt này hoạt động trơn tru mà không bị chậm do khoảng cách giữa CPU và ổ đĩa, Google sử dụng hai vũ khí hạng nặng bên dưới:

3.1. Tầng Lưu trữ: Hệ thống tệp phân tán Colossus

Colossus là thế hệ kế tiếp của Google File System (GFS) huyền thoại – nơi lưu trữ dữ liệu cho cả YouTube, Gmail và Google Search.

Chia nhỏ (Sharding) & Nhân bản (Replication): Khi bạn nạp (Insert/Load) một bảng lớn vào BigQuery, Colossus tự động băm nhỏ dữ liệu thành hàng ngàn mảnh (Partitions/Shards) và rải đều ra hàng ngàn ổ đĩa vật lý khác nhau.
An toàn tuyệt đối: Colossus sử dụng thuật toán mã hóa xóa (Reed-Solomon Erasure Coding) để nhân bản dữ liệu ra nhiều trung tâm dữ liệu (Zones). Nếu một ổ cứng hay cả một tủ rack bị cháy, dữ liệu của bạn vẫn nguyên vẹn và câu lệnh SELECT đang chạy thậm chí không nhận ra sự cố đó.
Định dạng lưu trữ Capacitor: Bên trong Colossus, dữ liệu không lưu dạng text thô mà được đóng gói theo chuẩn Capacitor – định dạng lưu trữ dạng cột (Columnar) độc quyền của Google (chúng ta sẽ mổ xẻ cực sâu về Capacitor ở Bài học 3).

3.2. Tầng Tính toán: Bộ máy thực thi phân tán Dremel

Nếu Colossus là kho hàng khổng lồ, thì Dremel chính là đội quân hàng vạn công nhân bốc xếp và tính toán siêu tốc. Dremel biến câu lệnh SQL của bạn thành một Cây thực thi phân tán (Execution Tree) gồm nhiều tầng:

                      [ Root Server ]  <-- Nhận câu lệnh SQL từ bạn & Trả kết quả cuối
                       /     |     \
                      /      |      \
          [ Mixer 1 ]   [ Mixer 2 ]  ... (Tầng trung gian: Gom và tổng hợp sơ bộ)
           /   |   \      /   |   \
      [Leaf] [Leaf] ... [Leaf] [Leaf]  <-- Hàng ngàn Leaf Nodes (Slots) đọc trực tiếp từ Colossus

Quá trình diễn ra trong vài giây ngắn ngủi khi bạn bấm Run Query:

Root Server: Nhận câu truy vấn SQL của bạn, đọc Metadata của bảng để biết dữ liệu đang nằm ở những mảnh nào trên Colossus, sau đó chia câu lệnh gốc thành hàng ngàn câu lệnh con (Sub-queries).
Leaf Nodes (Lá): Đây là nơi các Slots (đơn vị tính toán gồm CPU + RAM) trực tiếp làm việc. Hàng ngàn Leaf Nodes cùng lúc thò tay xuống Colossus, đọc song song từng mảnh dữ liệu dạng cột lên RAM, thực hiện lọc (WHERE) và tính toán cục bộ (COUNT, SUM, GROUP BY từng phần).
Mixers (Trạm trộn trung gian): Nhận kết quả đã được rút gọn từ hàng ngàn Leaf Nodes bên dưới, tiếp tục gộp (AGGREGATE / SORT) lại một lần nữa trước khi đẩy lên Root Server trả về màn hình cho bạn.

Điểm ăn tiền của kỹ thuật Chia để trị (Divide and Conquer): Giả sử bạn cần cộng tổng doanh thu của 1 tỷ dòng. Thay vì 1 con CPU phải làm 1 tỷ phép cộng mất 10 phút, Dremel chia cho 2.000 Leaf Nodes, mỗi Node chỉ phải đọc và cộng 500.000 dòng trên RAM (mất chưa tới 0.5 giây!), sau đó Mixer cộng 2.000 con số tổng đó lại với nhau. Đó là lý do vì sao dữ liệu lớn gấp 100 lần nhưng thời gian chạy trên BigQuery gần như không đổi!

4. Mảnh ghép sinh tử: Tại sao tách Compute và Storage ra xa nhau mà không bị nghẽn mạng?

Đến đây, những anh em có kinh nghiệm làm hệ thống phân tán hoặc Microservices sẽ lập tức phát hiện ra một điểm vô lý: "Ơ kìa! Trong máy tính thông thường, đọc dữ liệu từ ổ cứng NVMe gắn ngay trên Mainboard qua khe PCIe còn thấy chậm. Bây giờ ông tách cụm CPU (Dremel) ở một đằng, cụm ổ cứng (Colossus) ở một nẻo, rồi kéo hàng Terabyte dữ liệu qua dây mạng LAN (Network I/O) thì mạng nào chịu nổi?!"

Phát hiện cực kỳ chính xác! Nếu bạn tự dựng một hệ thống tách rời Compute và Storage trên hạ tầng mạng thông thường (1Gbps hay 10Gbps), hệ thống sẽ chết sặc vì nghẽn băng thông mạng (Network Bottleneck).

Nhưng Google có thứ mà các công ty thông thường không có: Mạng lưới Jupiter (Jupiter Network Fabric) và bộ điều phối Borg (tiền thân của Kubernetes):

Jupiter là hệ thống mạng nội bộ cáp quang tự thiết kế bên trong Data Center của Google, cung cấp tổng băng thông hai chiều (Bisection Bandwidth) lên tới hàng Petabit/giây (1 Petabit = 1.000.000 Gigabit).
Băng thông này lớn đến mức 100.000 máy chủ bên trong trung tâm dữ liệu của Google có thể trao đổi dữ liệu với nhau ở tốc độ 10 Gbps đến 100 Gbps mỗi máy cùng một lúc mà không hề bị nghẽn mạng.
Nhờ Jupiter, việc một cái Leaf Node của Dremel đọc dữ liệu từ ổ cứng của Colossus qua mạng nội bộ nhanh chẳng kém gì đọc từ ổ cứng gắn trực tiếp trên máy chủ đó!

Ngoài ra, khi các câu lệnh JOIN hoặc GROUP BY lớn cần tráo đổi dữ liệu giữa các Leaf Nodes (quá trình Shuffle), Dremel sử dụng một tầng In-Memory Shuffle siêu tốc nằm ngay giữa mạng Jupiter để trao đổi dữ liệu trên RAM mà không cần ghi tạm xuống ổ đĩa vật lý.

5. Góc nhìn thực chiến: Hiểu kiến trúc này giúp gì cho ví tiền và code của bạn?

Hiểu về Dremel và Colossus không phải để đi chém gió khi phỏng vấn, mà nó quyết định trực tiếp cách bạn viết SQL và thiết kế hệ thống trên BigQuery:

Đừng sợ lưu dữ liệu lịch sử (Storage siêu rẻ): Vì Colossus lưu trữ tách biệt và tự động giảm giá 50% sau 90 ngày không chỉnh sửa, bạn hoàn toàn có thể đẩy toàn bộ Log hệ thống, lịch sử thay đổi trạng thái đơn hàng 5-10 năm vào BigQuery mà chi phí lưu trữ mỗi tháng chỉ bằng vài ly cà phê.
Hãy sợ việc quét thừa dữ liệu (Compute + Network tốn tiền): Mỗi lần Dremel kéo dữ liệu từ Colossus qua mạng Jupiter lên để xử lý, Google sẽ tính tiền bạn theo dung lượng dữ liệu bị kéo lên (với mô hình On-Demand là $6.25 cho mỗi Terabyte dữ liệu quét). Vì vậy, thiết kế bảng có Partition và Clustering để Dremel biết chính xác cần đọc mảnh nào trên Colossus là kỹ năng sống còn.
Tại sao BigQuery ghét việc INSERT / UPDATE từng dòng nhỏ lẻ? Mỗi lần bạn ghi dữ liệu, Colossus phải tạo ra các mảnh file bất biến (Immutable files) và cập nhật Metadata. Nếu bạn dùng vòng lặp for trong code Backend để bắn 10.000 câu lệnh UPDATE từng dòng vào BigQuery như cách làm với MySQL, bạn đang bắt Dremel và Colossus khởi tạo 10.000 cây thực thi phân tán và ghi lại 10.000 file lớn – cực kỳ chậm và chạm giới hạn Quota ngay lập tức!

Tổng kết Bài học 2

Kiến trúc của Google BigQuery là một kiệt tác của kỹ thuật hệ thống phân tán, được xây dựng trên sự phân vai hoàn hảo:

Colossus: Kho lưu trữ phân tán bất biến, an toàn và cực rẻ.
Dremel: Động cơ tính toán MPP biến câu lệnh SQL thành cây thực thi với hàng ngàn Slots chạy song song.
Jupiter: Cao tốc mạng hàng Petabit/giây xóa nhòa khoảng cách giữa ổ cứng và CPU.

Nhưng vẫn còn một mảnh ghép thứ 4 cực kỳ thú vị mà chúng ta vừa nhắc tới: Định dạng lưu trữ Capacitor. Làm thế nào mà Capacitor có thể nén hàng trăm triệu dòng dữ liệu xuống chỉ còn vài chấm Megabyte, và làm sao nó có thể lọc dữ liệu (WHERE) ngay cả khi... chưa cần giải nén?

Hẹn gặp lại anh em ở Bài học 3: Lưu trữ dạng cột (Columnar Storage - Capacitor) – Bí mật giúp BigQuery quét hàng Terabyte dữ liệu chỉ trong vài giây!

bigquery