Google BigQuery - Bài học 30: Materialized Views – Tự động tính toán trước và làm mới dữ liệu tổng hợp không cần viết cronjob

Chào anh em! Ở Bài học 29, chúng ta đã khám phá BigQuery BI Engine – giải pháp dùng bộ nhớ đệm In-memory RAM để tăng tốc độ phản hồi truy vấn dưới 1 giây cho các công cụ Looker Studio hay Power BI.

Hôm nay, chúng ta tiếp tục đi đến một "vũ khí hạng nặng" khác nằm ở tầng lưu trữ giúp xử lý triệt để các bài toán báo cáo tổng hợp tốn kém: Materialized Views (Bảng ảo được vật lý hóa).

Hãy thử nghĩ xem: Mỗi sáng, sếp cần xem một bảng báo cáo tổng hợp doanh thu theo từng danh mục sản phẩm và khu vực của toàn hệ thống. Bảng gốc fact_orders có tới 1 tỷ dòng. Nếu mỗi lần sếp mở báo cáo, hệ thống lại phải quét toàn bộ 1 tỷ dòng, chạy phép GROUP BY và SUM từ đầu, thì dù có tối ưu cách mấy cũng sẽ tốn một lượng tài nguyên tính toán (Slot time) đáng kể.

• Giải pháp truyền thống: Bạn viết một script Python hoặc dùng Airflow lên lịch chạy cronjob mỗi đêm để tính toán trước rồi INSERT vào một bảng tổng hợp (summary_table).

• Vấn đề của cronjob: Code dễ bị lỗi, khi bảng gốc có dữ liệu mới phát sinh trong ngày thì bảng tổng hợp bị lệch số liệu (outdated), và bạn phải tự viết logic xử lý việc cập nhật rất cồng kềnh.

BigQuery giải quyết việc này cực kỳ tinh tế thông qua Materialized Views tự động làm mới ngầm mà không cần một dòng cronjob thủ công nào! Hãy cùng mổ xẻ ngay nhé.

1. Materialized View là gì? Khác gì với Logical View thông thường?

Trước khi đi sâu, chúng ta cần phân biệt rõ hai khái niệm View trong BigQuery:

1. Logical View (View thường - Đã học ở Bài 5):

   • Bản chất: Chỉ là một "câu lệnh SQL được lưu giữ tên". Nó không lưu trữ bất kỳ byte dữ liệu vật lý nào trên ổ đĩa Colossus.

   • Hệ quả: Mỗi lần bạn SELECT từ View thường, BigQuery sẽ mở câu lệnh SQL gốc bên dưới ra và chạy lại từ đầu trên bảng gốc. Nó hoàn toàn không giúp bạn tiết kiệm chi phí quét dữ liệu hay tăng tốc độ thực thi.

2. Materialized View (MV - Bảng ảo vật lý hóa):

   • Bản chất: Là một đối tượng lưu trữ thực tế trên ổ đĩa. BigQuery tự động tính toán trước kết quả của câu lệnh GROUP BY, JOIN... và lưu giữ chúng dưới định dạng Capacitor.

   • Hệ quả: Khi bạn truy vấn vào Materialized View, BigQuery đọc thẳng kết quả đã được tính sẵn mà không cần đụng đến bảng gốc hàng tỷ dòng, giúp tốc độ tăng vọt và chi phí quét dữ liệu giảm đi hàng ngàn lần!

2. Phép thuật độc quyền của BigQuery: Smart Query Rewrite (Tự động chuyển hướng truy vấn)

Ở các hệ quản trị cơ sở dữ liệu truyền thống (như PostgreSQL hay Oracle), khi bạn tạo một Materialized View tên là mv_daily_revenue, nếu người dùng viết câu lệnh truy vấn trực tiếp vào bảng gốc fact_orders, hệ thống sẽ không quan tâm đến MV và vẫn quét bảng gốc từ đầu. Bạn bắt buộc phải hướng dẫn mọi người đổi câu lệnh sang gọi thẳng bảng mv_daily_revenue.

Nhưng Google BigQuery thông minh hơn rất nhiều nhờ tính năng Smart Query Rewrite (Viết lại truy vấn thông minh):

• Ngay cả khi người dùng (hoặc công cụ BI) viết câu lệnh SQL truy vấn trực tiếp vào bảng gốc fact_orders, bộ tối ưu hóa của Dremel sẽ tự động phân tích: "À, câu lệnh này chỉ yêu cầu tổng doanh thu theo ngày, mà ta đã có sẵn Materialized View mv_daily_revenue đã tính trước việc đó rồi!"

• BigQuery tự động chuyển hướng câu lệnh (Rewrite) chạy ngầm sang đọc từ Materialized View mà không đòi hỏi bạn phải sửa bất kỳ dòng code nào ở phía ứng dụng!

3. Thực chiến: Tạo Materialized View với cơ chế tự động làm mới ngầm

Hãy xem cách chúng ta định nghĩa một Materialized View trong GoogleSQL có bật cơ chế tự động cập nhật nền (Background Refresh):

SQL

-- Tạo Materialized View tổng hợp doanh thu và số lượng đơn hàng theo ngày và danh mục sản phẩm
CREATE MATERIALIZED VIEW `my-project.mart_sales.mv_daily_category_revenue`
OPTIONS (
    enable_refresh = TRUE,                -- Bật cơ chế tự động làm mới ngầm
    refresh_interval_minutes = 60         -- Thời gian tối thiểu giữa các lần làm mới ngầm (phút)
) AS
SELECT 
    DATE(DATETIME(created_at, 'Asia/Ho_Chi_Minh')) AS summary_date,
    category,
    COUNT(order_id) AS total_orders,
    SUM(total_amount) AS total_revenue
FROM `my-project.core_dwh.fact_orders`
GROUP BY summary_date, category;

Cơ chế tự động làm mới hoạt động ra sao?

1. Khi bảng gốc fact_orders có các dòng dữ liệu mới được nạp vào, tiến trình nền của BigQuery sẽ tự động phát hiện phần thay đổi (Delta).

2. Dựa trên refresh_interval_minutes = 60, cứ mỗi tiếng (hoặc khi có lượng thay đổi đủ lớn), BigQuery sẽ chạy ngầm để cập nhật phần dữ liệu mới vào Materialized View.

3. Quá trình này diễn ra hoàn toàn tự động, không tốn một dòng cronjob nào từ phía Backend của bạn, và không làm khóa bảng hay ảnh hưởng đến hiệu năng đọc dữ liệu của người dùng.

4. Những giới hạn kỹ thuật cần ghi nhớ khi sử dụng Materialized Views

Dù cực kỳ mạnh mẽ, Materialized Views trong BigQuery không phải là vạn năng. Để tránh việc câu lệnh CREATE MATERIALIZED VIEW bị báo lỗi, bạn phải tuân thủ các quy tắc thiết kế sau:

1. Hạn chế về cú pháp SQL bên trong MV: Câu lệnh SQL định nghĩa Materialized View hiện tại hỗ trợ các phép toán tổng hợp cơ bản (SUM, COUNT, MIN, MAX, AVG, APPROX_COUNT_DISTINCT) và các phép JOIN giữa bảng Fact và các bảng Dimension. Nó chưa hỗ trợ các hàm không xác định (như CURRENT_TIMESTAMP(), RAND()), các hàm cửa sổ phức tạp (ROW_NUMBER, LAG, LEAD), hoặc phép FULL OUTER JOIN.

2. Quy tắc về Chi phí (Cost Trade-off): Mặc dù Materialized View giúp giảm chi phí khi đọc báo cáo, nhưng quá trình tự động cập nhật ngầm (Background Refresh) cũng tiêu tốn một phần tài nguyên tính toán để quét các phần dữ liệu thay đổi. Do đó, chỉ nên tạo Materialized View cho các bảng có tần suất truy vấn báo cáo rất cao nhưng tỷ lệ thay đổi dữ liệu nằm trong tầm kiểm soát.

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

Materialized Views là mảnh ghép hoàn hảo giúp tự động hóa tầng tổng hợp dữ liệu trong kiến trúc Data Warehouse:

1. Tính toán trước (Pre-computation): Lưu trữ sẵn kết quả các câu lệnh GROUP BY và JOIN phức tạp dưới định dạng Capacitor vật lý.

2. Smart Query Rewrite: Tự động chuyển hướng các truy vấn từ bảng gốc sang Materialized View một cách trong suốt mà không cần sửa code ứng dụng.

3. Tự động làm mới (Auto-refresh): Bật enable_refresh = TRUE để BigQuery tự động cập nhật ngầm dữ liệu mới mà không cần viết cronjob.

Trong các hệ thống thương mại điện tử hoặc tìm kiếm log quy mô lớn, ngoài việc tổng hợp dữ liệu theo báo cáo, một bài toán cực kỳ đau đầu khác là làm sao tìm kiếm chính xác một từ khóa hoặc một dòng log cụ thể nằm ẩn giấu giữa hàng trăm triệu dòng văn bản mà không làm sập hệ thống.

Công nghệ nào giúp đánh index và tìm kiếm văn bản tốc độ cao trên BigQuery? Hãy đón xem Bài học 31: Search Indexes – Tối ưu hóa việc tìm kiếm một dòng cụ thể (Point Lookup) hoặc phân tích Log!