BigQuery 1 — Tổng quan & kiến trúc serverless

Nếu bạn quen với PostgreSQL hay Oracle, phản xạ đầu tiên khi nghe "database" là hình dung một máy chủ: có CPU, có RAM, có ổ đĩa, có tiến trình đang chạy, có DBA lo backup và tuning. BigQuery đập vỡ toàn bộ mô hình tinh thần đó. Ở đây không có máy chủ nào để bạn nhìn thấy, cấp phát hay quản lý. Bạn nạp dữ liệu vào, gõ một câu SQL quét hàng tỷ dòng, và vài giây sau có kết quả — mà không hề biết (và không cần biết) truy vấn đó vừa được thực thi song song trên bao nhiêu nghìn máy của Google.

Bài này là nền móng của cả series BigQuery. Mục tiêu không phải dạy bạn viết truy vấn nhanh ngay, mà dựng một mô hình tinh thần đúng về cách BigQuery tổ chức lưu trữ và tính toán. Có mô hình đó rồi, các bài sau — Storage & tables, SQL nâng cao, Partition & cluster, Chi phí & hiệu năng — sẽ ăn khớp thay vì rời rạc.

Lưu ý về sandbox: SQL sandbox của Knowledge Base chạy trên PostgreSQL, KHÔNG phải BigQuery. Vì vậy cú pháp và tính năng riêng của BigQuery trong bài này không chạy được ở đây — chúng chỉ mang tính minh hoạ. Mọi khối code BigQuery đều được ghi rõ "(minh hoạ — BigQuery, không chạy trong sandbox Postgres)".

BigQuery là gì

BigQuery là kho dữ liệu (data warehouse) phân tích serverless của Google Cloud. Ghép ba tính từ đó lại sẽ ra đúng bản chất:

• Kho dữ liệu phân tích (analytical / OLAP): BigQuery sinh ra để đọc và tổng hợp khối lượng dữ liệu khổng lồ — đếm, tính tổng, gom nhóm, tính trung bình, join nhiều bảng lớn — chứ không phải để phục vụ hàng chục nghìn giao dịch nhỏ mỗi giây như một database OLTP (đặt hàng, rút tiền, cập nhật một dòng). Đây là điểm phân định quan trọng nhất, ta sẽ quay lại ở phần so sánh.
• Cột (columnar): dữ liệu không lưu theo dòng như database truyền thống mà lưu theo cột. Khi bạn SELECT SUM(amount) trên bảng 500 cột, BigQuery chỉ đọc đúng cột amount, bỏ qua 499 cột còn lại. Đây là chìa khoá khiến các phép aggregate trên tỷ dòng chạy nhanh và rẻ.
• Serverless: bạn không cấp phát, không mở rộng, không vá lỗi, không backup máy chủ. Google lo toàn bộ hạ tầng. Theo tài liệu chính thức, "BigQuery storage là dịch vụ được quản lý hoàn toàn — bạn không cần cấp phát tài nguyên lưu trữ hay đặt trước đơn vị lưu trữ". Bạn chỉ tương tác với dữ liệu và câu SQL.

Ngôn ngữ truy vấn là GoogleSQL (trước đây gọi Standard SQL), tuân theo chuẩn ANSI SQL (ISO/IEC 9075). Người biết SQL sẽ thấy quen ngay: SELECT ... FROM ... WHERE ... GROUP BY ... giống hệt. Điểm khác nằm ở các phần mở rộng riêng (kiểu STRUCT, ARRAY, hàm phân tích, QUALIFY...) mà bài SQL nâng cao sẽ đào sâu.

Kiến trúc: tách lưu trữ khỏi tính toán

Đây là quyết định kiến trúc quan trọng nhất, và cũng là điều khác biệt nền tảng so với PostgreSQL/Oracle. Trong một database truyền thống, CPU, RAM và ổ đĩa gắn chặt trên cùng một máy: muốn nhiều sức tính toán hơn thì thường phải mua cả máy to hơn (cả đĩa lẫn CPU), và các truy vấn nặng giành giật tài nguyên với nhau.

BigQuery tách rời hai lớp này và cho chúng chạy độc lập nhờ mạng nội bộ tốc độ petabit của Google. Tài liệu chính thức mô tả: lớp lưu trữ và lớp tính toán "vận hành độc lập với nhau", nhờ đó tránh xung đột tài nguyên giữa việc đọc/ghi và việc xử lý phân tích. Hệ quả trực tiếp:

• Scale độc lập: lưu thêm petabyte dữ liệu không đòi hỏi thêm CPU; chạy truy vấn nặng hơn không đòi hỏi mua thêm đĩa.
• Không giành máy: hàng trăm truy vấn có thể chạy đồng thời trên cùng dữ liệu mà không chặn nhau, vì mỗi truy vấn được cấp compute riêng và dữ liệu nằm ở lớp lưu trữ chung.

Các thành phần bên trong

BigQuery là mặt ngoài (SQL, project, dataset) của một chồng công nghệ nội bộ của Google, ghép lại từ nhiều hệ thống trứ danh:

• Colossus — hệ thống file phân tán thế hệ mới của Google, kế nhiệm GFS. Đây là nơi dữ liệu bảng của bạn thực sự nằm. Colossus lo phân mảnh, sao chép (replication), và độ bền dữ liệu.
• Capacitor — định dạng lưu trữ cột của BigQuery. Dữ liệu được mã hoá và nén theo từng cột, tối ưu cho khối lượng phân tích. Nhờ Capacitor + Colossus, BigQuery đạt độ bền dữ liệu 99,999999999% (11 số 9) mỗi năm nhờ sao chép qua nhiều availability zone.
• Dremel — engine thực thi truy vấn phân tán, biến câu SQL thành cây thực thi gồm nhiều stage và step, rồi rải công việc song song ra hàng nghìn worker cùng quét dữ liệu. Chính Dremel là "phép thuật" đứng sau việc quét terabyte trong vài giây, petabyte trong vài phút.
• Jupiter — mạng trung tâm dữ liệu tốc độ petabit. Đây là mạch máu nối lớp lưu trữ với lớp tính toán; chính vì Jupiter cực nhanh nên việc "tách rời storage và compute" mới khả thi — worker đọc dữ liệu từ Colossus gần như thể đọc từ đĩa cục bộ.
• Borg — hệ điều phối cụm (cluster orchestration) của Google, cấp phát tài nguyên máy cho Dremel một cách động.

Bạn không thao tác trực tiếp với bất kỳ thành phần nào ở trên — chúng là hộp đen. Nhưng biết tên và vai trò giúp bạn hiểu tại sao BigQuery hành xử như vậy (ví dụ vì sao không có index kiểu B-tree, vì sao đọc cột lại rẻ).

Điểm cốt lõi cần khắc vào đầu: compute (Dremel + slots) và storage (Colossus + Capacitor) là hai lớp riêng, nối nhau qua mạng Jupiter, mỗi lớp scale riêng.

Slots — đơn vị tính toán

Nếu compute là hàng nghìn worker song song, thì làm sao đo lường và tính tiền sức tính toán đó? Câu trả lời là slot.

Theo định nghĩa chính thức, một slot là "đơn vị tính toán ảo (virtual compute unit) mà BigQuery dùng để thực thi truy vấn SQL, code Python, hoặc các loại job khác". Hãy hình dung slot như một "suất CPU ảo". BigQuery tự động quyết định cần bao nhiêu slot cho mỗi truy vấn, dựa trên khối lượng dữ liệu, độ phức tạp câu lệnh và lượng slot đang rảnh.

Có hai mô hình cấp slot:

• On-demand (mặc định): bạn không quản lý slot; BigQuery tự cấp và tính tiền theo lượng dữ liệu quét (mỗi TiB). Có giới hạn slot mềm theo project/tổ chức nhưng cho phép "bùng" (burst) khi cần. Đây là điểm khởi đầu hợp lý cho hầu hết mọi người.
• Capacity / reservation (BigQuery Editions): bạn mua trước dung lượng slot theo thời gian và trả tiền cho dung lượng đã cấp, thay vì theo dữ liệu quét. Có thể đặt baseline (luôn sẵn) và autoscaling (cấp thêm khi cần, theo bội số 50 slot). Phù hợp khi khối lượng lớn, đều đặn, cần chi phí dự đoán được.

Một chi tiết đẹp về công bằng tài nguyên: khi nhu cầu vượt quá slot đang có, BigQuery xếp hàng các đơn vị công việc và chạy dần khi slot rảnh — không tính thêm tiền cho phần bị xếp hàng. Trong một reservation, slot được chia đều giữa các project, rồi giữa các job trong project. Chuyện tiền nong và tối ưu slot sẽ được mổ xẻ ở bài Chi phí & hiệu năng.

So sánh với database truyền thống (OLTP)

Đây là hiểu lầm phổ biến nhất và cũng nguy hiểm nhất: coi BigQuery như "một Postgres to hơn". Hai thứ giải hai bài toán khác nhau về bản chất.

Điểm mấu chốt về hiệu năng: BigQuery không dùng index kiểu B-tree để nhảy tới một dòng cụ thể. Thay vào đó nó quét song song cực nhanh và giảm lượng dữ liệu phải đọc bằng partition (chia bảng theo ngày/khoảng giá trị) và clustering (sắp xếp vật lý theo cột) — hai kỹ thuật thay thế index, sẽ được trình bày kỹ ở bài Partition & cluster.

Vì vậy, đừng bao giờ dùng BigQuery làm database sau lưng một ứng dụng web cần đọc/ghi một bản ghi trong vài mili-giây. Đó là việc của Postgres/Cloud SQL/Spanner. BigQuery là nơi bạn đổ dữ liệu vào để phân tích.

Tổ chức tài nguyên: project → dataset → table

BigQuery tổ chức mọi thứ theo ba tầng, ánh xạ tự nhiên với cách Google Cloud vận hành:

• Project — ranh giới thanh toán và quyền (IAM) cao nhất. Mọi truy vấn tính tiền vào một project. Đây cũng là nơi áp quota và slot.
• Dataset — nhóm chứa các bảng/view, gắn với một location (region) cụ thể (ví dụ US, EU, asia-southeast1). Dataset là đơn vị bạn cấp quyền chia sẻ dữ liệu, và cũng là nơi chọn kiểu tính tiền lưu trữ (logical hay physical). Lưu ý location dán chặt vào dataset: bạn không thể join trực tiếp hai bảng ở hai region khác nhau.
• Table / View — nơi dữ liệu (hoặc định nghĩa truy vấn) thực sự nằm. Ngoài standard table còn có table clone (bản sao ghi được, nhẹ), table snapshot (bản chụp chỉ đọc tại một thời điểm), materialized view (kết quả tính sẵn được cache), external table... Bài Storage & tables sẽ đi sâu.

Tên bảng đầy đủ có dạng project.dataset.table (hoặc `project.dataset.table` khi cần backtick).

Giao diện và hệ sinh thái

Bạn nói chuyện với BigQuery qua nhiều cửa:

• Console web — giao diện đồ hoạ trong Google Cloud, gõ SQL, xem lược đồ, xem chi phí ước tính trước khi chạy.
• bq CLI — công cụ dòng lệnh, tiện cho tự động hoá và script.
• Client libraries — Python, Java, Go, Node.js... nhúng vào ứng dụng. Riêng Python còn có DataFrames API để xử lý theo phong cách pandas ngay trên compute của BigQuery.
• JDBC / ODBC — cho các công cụ BI và ETL truyền thống kết nối.

Về tích hợp, BigQuery ngồi ở trung tâm một hệ sinh thái dữ liệu: nạp dữ liệu từ Cloud Storage (GCS), xử lý luồng với Dataflow, dựng dashboard bằng Looker, và biến đổi dữ liệu theo phong cách ELT bằng dbt. Nếu bạn dùng BigQuery làm kho trung tâm, hai bài rất đáng đọc tiếp là dbt (transform/ELT) và Looker (BI).

Lakehouse: BigLake và Omni

Một điểm quan trọng của BigQuery hiện đại là nó không còn "đóng kín" với dữ liệu bên trong. Hai khái niệm cần biết (sẽ chỉ nhắc ngắn ở đây):

• BigLake — cho phép BigQuery truy vấn dữ liệu nằm ngoài (trên Cloud Storage, thậm chí ở cloud khác) và các định dạng bảng mở như Apache Iceberg, Delta Lake, Apache Hudi — mà vẫn giữ được quản trị quyền tập trung. Đây là bước tiến về mô hình lakehouse: gộp sự linh hoạt của data lake với khả năng quản trị của data warehouse.
• BigQuery Omni — chạy phân tích BigQuery trên dữ liệu nằm ở AWS và Azure, không cần chép dữ liệu về Google Cloud.

Ngoài ra BigQuery còn có federated queries để truy vấn trực tiếp Cloud SQL, Spanner, Bigtable, Google Drive. Ý tưởng chung: đưa compute tới nơi có dữ liệu, thay vì luôn phải gom dữ liệu về một chỗ.

Một truy vấn BigQuery trông thế nào

Ví dụ dưới dùng một public dataset của Google (dữ liệu thời tiết NOAA) — quét khối lớn nhưng chỉ đọc vài cột nhờ lưu trữ theo cột:

-- (minh hoạ — BigQuery, không chạy trong sandbox Postgres)
-- Nhiệt độ trung bình mỗi năm tại các trạm ở Việt Nam
SELECT
  year,
  ROUND(AVG(temp), 1) AS avg_temp_f,
  COUNT(*)            AS so_ban_ghi
FROM `bigquery-public-data.noaa_gsod.gsod2020`
WHERE stn BETWEEN '480000' AND '489999'   -- dải trạm khu vực
GROUP BY year
ORDER BY year;

Cú pháp thân thuộc với người biết SQL. Điểm BigQuery-riêng: tên bảng ba tầng trong backtick, và việc chỉ chọn year/temp/stn giúp engine bỏ qua mọi cột khác — đọc ít, trả tiền ít.

Và làm việc từ dòng lệnh với bq:

# (minh hoạ — BigQuery, không chạy trong sandbox Postgres)
# Chạy một truy vấn (dùng GoogleSQL) và in kết quả
bq query --use_legacy_sql=false \
  'SELECT name, SUM(number) AS total
   FROM `bigquery-public-data.usa_names.usa_1910_2013`
   WHERE state = "CA"
   GROUP BY name
   ORDER BY total DESC
   LIMIT 5'

# Xem thông tin một bảng
bq show bigquery-public-data:usa_names.usa_1910_2013

# Ước tính dung lượng quét trước khi chạy (dry run — không tốn tiền)
bq query --use_legacy_sql=false --dry_run \
  'SELECT COUNT(*) FROM `bigquery-public-data.usa_names.usa_1910_2013`'

Thói quen --dry_run để xem trước lượng dữ liệu quét là một thói quen tiết kiệm tiền rất đáng tập, ta sẽ nói kỹ ở bài chi phí.

Use case thực tế

Vài tình huống BigQuery toả sáng:

• Kho dữ liệu trung tâm cho BI: gom log giao dịch, sự kiện web, dữ liệu CRM về một chỗ; đội phân tích chạy dashboard Looker trên đó. Dữ liệu tăng lên hàng chục TB mà không ai phải lo "nâng cấp server".
• Phân tích log / sự kiện quy mô lớn: hàng tỷ dòng clickstream mỗi ngày. Câu hỏi "tỷ lệ chuyển đổi theo chiến dịch trong 90 ngày" chạy trong vài giây nhờ partition theo ngày.
• ELT hiện đại: đổ dữ liệu thô vào BigQuery rồi biến đổi ngay trong warehouse bằng dbt — tận dụng sức compute của BigQuery thay vì kéo dữ liệu ra ngoài.
• Nền tảng cho ML: BigQuery ML cho phép huấn luyện mô hình bằng SQL ngay trên dữ liệu, không cần chuyển ra hệ thống khác.
• Ad-hoc trên dữ liệu công khai / liên cloud: truy vấn public dataset, hoặc dùng Omni/BigLake để phân tích dữ liệu ở AWS/Azure mà không di chuyển.

Ngược lại, KHÔNG dùng BigQuery khi: cần giao dịch OLTP (đặt hàng, ví điện tử), cập nhật dòng lẻ liên tục với tần suất cao, hoặc cần độ trễ mili-giây cho từng lượt truy cập của ứng dụng người dùng cuối. Những việc đó dành cho Cloud SQL (Postgres/MySQL), Spanner hay Bigtable.

Ghi nhớ

• BigQuery là kho dữ liệu phân tích serverless, lưu theo cột, truy vấn bằng GoogleSQL — Google lo toàn bộ hạ tầng.
• Kiến trúc cốt lõi: tách lưu trữ khỏi tính toán. Storage = Colossus (file) + Capacitor (định dạng cột); compute = Dremel (engine song song) đo bằng slot; nối nhau qua mạng Jupiter; điều phối bởi Borg. Hai lớp scale độc lập, không giành máy.
• Slot = đơn vị CPU ảo. On-demand tính theo dữ liệu quét; capacity/reservation mua trước dung lượng.
• Đây là OLAP, không phải OLTP: mạnh ở aggregate trên tỷ dòng, không hợp cập nhật dòng lẻ tần suất cao hay độ trễ mili-giây. Không có index B-tree — thay bằng partition và clustering.
• Tổ chức: project → dataset (gắn region) → table/view. Giao diện: Console, bq CLI, client libs, JDBC/ODBC. Tích hợp GCS, Dataflow, Looker, dbt.
• BigLake / Omni / federated queries mở BigQuery ra định dạng bảng mở (Iceberg/Delta/Hudi) và dữ liệu liên cloud — hướng lakehouse.
• Sandbox KB chạy Postgres nên mọi ví dụ BigQuery trong bài chỉ là minh hoạ, không chạy được ở đây.

Bài tiếp theo — Storage & tables — sẽ đi sâu vào cách dữ liệu thực sự được lưu, các loại bảng (standard, clone, snapshot, materialized view, external), và cách nạp dữ liệu vào BigQuery.