BigQuery 1 — Tổng quan & định vị

BigQuery là gì

BigQuery là kho dữ liệu phân tích (analytical data warehouse) serverless, được quản lý hoàn toàn (fully managed) của Google Cloud. "Serverless" ở đây có nghĩa rất cụ thể: bạn không cấp phát cụm (cluster), không chọn số node, không bật/tắt máy chủ nào cả. Bạn nạp dữ liệu, viết SQL, nhấn chạy — Google tự động huy động tài nguyên tính toán cần thiết cho đúng câu truy vấn đó rồi thu hồi ngay khi xong.

Điều này khác hẳn ngay cả với các kho dữ liệu đám mây "managed" khác. Với Snowflake bạn vẫn phải tạo và chọn cỡ một virtual warehouse (xem snow-01-overview); với Redshift bạn quản lý một cluster. Với BigQuery, đơn vị tính toán — gọi là slot — được phân bổ tự động, ẩn khỏi tầm nhìn của bạn. Không có server để vá lỗi, không có ổ đĩa để lo đầy, không có "cụm đang ngủ" tốn tiền.

BigQuery ra đời từ Dremel — hệ thống truy vấn tương tác trên tập dữ liệu quy mô web mà Google công bố trong bài báo VLDB 2010. Dremel được thiết kế để quét hàng tỷ dòng trong vài giây bằng cách chia nhỏ truy vấn ra hàng nghìn worker chạy song song trên một cây thực thi (execution tree). BigQuery chính là Dremel được đóng gói thành dịch vụ công cộng, cộng thêm SQL chuẩn, quản lý bảng, và tích hợp hệ sinh thái Google Cloud.

Tách rời storage và compute

Nếu chỉ nhớ một ý từ bài này, hãy nhớ điều này: BigQuery tách hoàn toàn nơi cất dữ liệu (storage) khỏi nơi xử lý dữ liệu (compute), và hai bên co giãn, tính tiền độc lập.

Trong một RDBMS truyền thống (Oracle, PostgreSQL, MySQL) hay kho MPP cổ điển (Teradata), dữ liệu và CPU nằm chung trên cùng những node vật lý. Muốn tính nhanh hơn phải thêm node, mà thêm node lại phải phân phối lại dữ liệu. Storage và compute bị trói chặt vào nhau. BigQuery phá vỡ ràng buộc đó bằng bốn hạ tầng nền của Google:

• Colossus — hệ thống file phân tán thế hệ kế tiếp của Google, nơi dữ liệu bảng thực sự nằm, có nhân bản và tự phục hồi.
• Capacitor — định dạng lưu trữ cột (columnar) đã nén và mã hoá; nhờ lưu theo cột nên truy vấn chỉ đọc đúng những cột cần, không quét cả dòng (chi tiết ở bqp-03-storage-columnar).
• Dremel — engine thực thi, phân rã truy vấn thành cây các stage chạy song song trên các slot (chi tiết ở bqp-04-slots-execution-model).
• Jupiter — mạng nội bộ băng thông cực lớn (petabit/giây) cho phép compute đọc storage nhanh gần như thể chúng nằm cạnh nhau, dù thực tế tách rời.
• Borg — bộ điều phối (orchestration) cấp phát tài nguyên compute.

Hệ quả thực tế cho một ngân hàng:

1. Trả tiền storage và compute riêng. Lưu 50 TB lịch sử giao dịch tính tiền theo GB/tháng; nếu tháng đó không truy vấn gì thì gần như không tốn phí compute.
2. Không giới hạn concurrency cứng do phần cứng. Nhiều đội cùng quét chung một bảng mà không phải "tranh" CPU của một cụm cố định — Google phân bổ slot linh hoạt.
3. Không phải di chuyển dữ liệu khi cần tính nhiều hơn. Compute co giãn mà dữ liệu ở Colossus không nhúc nhích.

Kiến trúc chi tiết bốn hạ tầng này được mổ xẻ ở bqp-02-architecture.

Vị trí trong hệ Data Engineering

BigQuery không đứng một mình. Nó là lớp kho phân tích (analytical serving/warehouse layer) trong một pipeline dữ liệu điển hình — nơi dữ liệu đã được nạp về, biến đổi, và sẵn sàng cho phân tích/BI.

Vài điểm định vị đáng nhớ:

• BigQuery thiên về ELT hơn ETL: nạp dữ liệu thô vào trước (Extract-Load), rồi biến đổi bằng SQL ngay trong kho (Transform). Công cụ như dbt sinh SQL, BigQuery thực thi.
• Nó là đích đến (sink) phổ biến của các pipeline dàn dựng bằng Airflow (xem airflow-01-overview) và của luồng CDC từ Oracle.
• Nó cũng là một mắt xích trong kiến trúc lakehouse — có thể đọc trực tiếp file trên object storage qua external table, hoặc dùng bảng gốc trong Colossus.

Mô hình giá: on-demand vs capacity

Đây là quyết định vận hành quan trọng nhất khi dùng BigQuery, nên nắm ở mức khái quát ngay từ đầu (chi tiết tính tiền theo byte ở bqp-08-pricing-bytes).

BigQuery tính phí hai phần tách rời: storage (theo GB dữ liệu lưu, có phân biệt active vs long-term) và compute (theo lượng tính toán khi chạy truy vấn). Phần compute có hai mô hình:

• On-demand: bạn bị tính theo totalBytesBilled — tức lượng byte mà truy vấn thực sự đọc từ storage. Chọn ít cột hơn, lọc partition tốt hơn → quét ít byte hơn → rẻ hơn. Đây là lý do partitioning (bqp-09-partitioning) và clustering (bqp-10-clustering) tác động trực tiếp đến hoá đơn.
• Capacity (BigQuery Editions: Standard/Enterprise/Enterprise Plus): bạn mua slot dưới dạng reservation, trả theo slot-time, có thể bật autoscaling. Query dùng chung pool slot đã mua, không tính thêm theo byte. Chi tiết reservation/slot ở bqp-04-slots-execution-model.

Với ngân hàng, mẫu hình thường gặp: bắt đầu bằng on-demand khi tải còn nhỏ và khó đoán, rồi chuyển sang capacity khi khối lượng truy vấn đủ lớn và ổn định để phần cam kết rẻ hơn tổng chi phí per-byte.

Khác biệt cốt lõi với RDBMS / warehouse truyền thống

BigQuery nói SQL, nhưng bên trong nó không phải một cơ sở dữ liệu giao dịch (OLTP) như Oracle hay PostgreSQL. Hiểu sai điểm này là nguồn gốc của hầu hết sai lầm khi mới dùng.

Ba điều dễ vấp nhất khi chuyển từ Oracle sang BigQuery:

1. Không có index như bạn quen. Không tạo B-tree để tăng tốc WHERE. Thay vào đó, tốc độ và chi phí đến từ quét cột song song + cắt bỏ partition/cluster không liên quan (pruning). Lọc theo cột đã partition mới thực sự giảm byte quét.
2. Đừng dùng như OLTP. BigQuery tối ưu cho quét khối lớn, không cho sửa một dòng. Cập nhật lẻ tẻ hàng loạt (row-by-row UPDATE) là phản mẫu; hãy nạp theo lô hoặc dùng MERGE theo batch.
3. Khoá chính/ngoại không được cưỡng chế. Bạn có thể khai báo PRIMARY KEY ... NOT ENFORCED để optimizer tham khảo, nhưng BigQuery không chặn trùng lặp giúp bạn — chất lượng dữ liệu phải do pipeline đảm bảo.

Một câu GoogleSQL minh hoạ

BigQuery dùng phương ngữ GoogleSQL (chuẩn ANSI + phần mở rộng). Câu dưới đây là GoogleSQL hợp lệ chạy trên BigQuery — không chạy được trên sandbox PostgreSQL của Knowledge Base, chỉ để minh hoạ cách lọc theo partition ngày để giảm byte quét:

-- GoogleSQL (chạy trên BigQuery; KHÔNG chạy trên sandbox PostgreSQL — minh hoạ)
SELECT
  customer_id,
  COUNT(*)          AS so_giao_dich,
  SUM(amount)       AS tong_tien
FROM `ncb-analytics.core.transactions`
WHERE txn_date BETWEEN DATE '2026-06-01' AND DATE '2026-06-30'  -- lọc partition
  AND channel = 'MOBILE'
GROUP BY customer_id
ORDER BY tong_tien DESC
LIMIT 100;

Mẹo tiết kiệm ngay: chỉ chọn cột cần thiết, tránh SELECT *, và luôn lọc theo cột đã partition — cả ba đều giảm totalBytesBilled trên mô hình on-demand.

Bản đồ toàn series (16 bài)

Đây là bài mở màn. Toàn series đi từ nền tảng kiến trúc → cú pháp truy vấn → tối ưu chi phí/hiệu năng → đọc query plan để chẩn đoán.

Khi nào dùng BigQuery (và khi nào không)

Nên chọn BigQuery khi:

• Tổ chức đã hoặc sẽ đứng trên Google Cloud, muốn zero-ops thật sự — không quản lý cụm nào.
• Nhu cầu phân tích khối lớn (OLAP): quét hàng chục triệu đến hàng tỷ dòng cho báo cáo, dashboard, feature ML.
• Tải thất thường, khó đoán, muốn "chạy tới đâu trả tới đó" (bắt đầu on-demand).
• Muốn tận dụng tích hợp sẵn: BigQuery ML (huấn luyện mô hình bằng SQL), streaming ingestion, kết nối Looker.

Cân nhắc lựa chọn khác khi:

• Tải giao dịch (OLTP): ghi/sửa/xoá từng dòng độ trễ thấp → dùng Cloud SQL/AlloyDB/PostgreSQL, không phải BigQuery.
• Cần đa cloud hoặc trung lập nhà cung cấp → cân nhắc Snowflake (AWS/Azure/GCP).
• Đã "all-in" AWS với tích hợp sâu → Redshift có thể hợp lý hơn.
• Ràng buộc chủ quyền dữ liệu (data residency): phải kiểm tra region khả dụng và quy định NHNN/nghị định bảo vệ dữ liệu cá nhân trước khi đưa dữ liệu ngân hàng lên cloud.

Use case thực tế

Bối cảnh. Một ngân hàng cỡ vừa muốn xây kho phân tích cho ~40 TB dữ liệu giao dịch lịch sử (bảng transactions), phục vụ ba nhóm: báo cáo tuân thủ NHNN, dashboard giám đốc, và đội mô hình rủi ro tín dụng. Kho Oracle hiện tại nghẽn mỗi kỳ đóng sổ vì báo cáo nặng tranh CPU với hệ thống vận hành.

Dùng BigQuery.

• Dữ liệu 40 TB nạp vào bảng gốc trong Colossus, partition theo txn_date và cluster theo customer_id. Storage tính riêng theo GB/tháng.
• Bảng lớn nhưng báo cáo cuối tháng chỉ lọc một khoảng ngày → nhờ partition pruning, query chỉ quét phần dữ liệu của tháng đó thay vì full-scan 40 TB, giảm mạnh totalBytesBilled.
• Giai đoạn đầu chạy on-demand để đo tải thực; sau khi thấy khối lượng truy vấn ổn định và lớn, chuyển sang capacity (Enterprise Edition) mua reservation slot với autoscaling để trần chi phí cố định.
• Ba nhóm cùng đọc chung một bảng, không phải "tranh" cụm phần cứng cố định; đội rủi ro huấn luyện mô hình bằng BigQuery ML ngay trong kho, không cần bê dữ liệu ra ngoài.

Kết quả (minh hoạ định tính). Báo cáo cuối tháng không còn làm nghẽn hệ thống vận hành vì kho phân tích tách khỏi core banking. Nhờ lọc partition + chọn đúng cột, chi phí quét giảm rõ so với thói quen SELECT *. Đội data engineer thôi phải tuning ổ đĩa/vá server, dồn công vào modeling dữ liệu và chất lượng pipeline. Cách đo chi phí và giám sát job cụ thể ở bqp-16-monitoring-cost.

Ghi nhớ

• BigQuery là data warehouse phân tích (OLAP) serverless, fully managed của Google Cloud — không cấp phát cluster, đơn vị compute là slot phân bổ tự động.
• Nền móng từ Dremel (VLDB 2010): phân rã truy vấn thành cây stage chạy song song trên hàng nghìn worker.
• Tách rời storage và compute là đặc trưng cốt lõi: Colossus (file) + Capacitor (định dạng cột) cho storage, Dremel cho compute, nối bằng mạng Jupiter, điều phối bởi Borg — hai bên co giãn và tính tiền độc lập.
• Giá tính hai phần: storage (theo GB) và compute theo một trong hai mô hình — on-demand (theo totalBytesBilled, mỗi query) hoặc capacity/Editions (mua slot theo reservation).
• Trên on-demand, giảm byte quét = giảm tiền: chọn ít cột, tránh SELECT *, lọc theo cột đã partition/cluster.
• BigQuery không phải OLTP: không index B-tree truyền thống, UPDATE/DELETE lẻ đắt và không khuyến khích, PK/FK không được cưỡng chế — chất lượng dữ liệu do pipeline lo.
• Dùng GoogleSQL (chuẩn ANSI + mở rộng), thiết kế cho ELT — nạp thô rồi biến đổi bằng SQL ngay trong kho.
• Chọn BigQuery khi ở trên Google Cloud, cần phân tích khối lớn, tải thất thường; tránh cho OLTP; cân nhắc data residency với quy định NHNN.

Nguồn tham khảo

• BigQuery documentation — Overview
• BigQuery — Storage & compute architecture / Overview of BigQuery
• BigQuery pricing
• BigQuery — Introduction to reservations (slots/Editions)
• BigQuery — Best practices for performance overview
• Melnik et al. (2010), "Dremel: Interactive Analysis of Web-Scale Datasets", Proceedings of the VLDB Endowment
• Lakshmanan & Tigani, "Google BigQuery: The Definitive Guide", O'Reilly