Đã đăng vào khoảng 5 giờ trước 9 phút đọc

Google BigQuery - Bài học 24: Time Travel & Fail-safe – Cách "quay ngược thời gian" cứu dữ liệu bị xóa nh릅 hoặc UPDATE sai trong vòng 7 ngày

Chào anh em! Qua Bài học 23, chúng ta đã biết cách xử lý tọa độ không gian địa lý siêu tốc bằng BigQuery GIS. Hôm nay, chúng ta sẽ bước sang một tính năng cứu sinh cực kỳ quan trọng mà bất kỳ quản trị viên cơ sở dữ liệu (DBA) hay Backend Lead nào cũng phải thầm cảm ơn Google khi đối mặt với sự cố: Time Travel & Fail-safe (Quay ngược thời gian).

Hãy tưởng tượng kịch bản ác mộng này:

Vào lúc 23:55 đêm, một lập trình viên mới vào công ty gõ nhầm câu lệnh: UPDATE orders SET status = 'CANCELLED'; mà quên mất mệnh đề WHERE.
Toàn bộ trạng thái của hàng triệu đơn hàng trong bảng Production bị chuyển thành "Đã hủy" ngay lập tức.
Tim bạn đập thình thịch, mồ hôi lạnh túa ra. Bạn chưa kịp gọi đội DevOps kiểm tra bản backup gần nhất thì chợt nhớ ra BigQuery có cơ chế Time Travel. Bạn chỉ cần gõ một câu lệnh đơn giản, kéo dữ liệu về trạng thái của 10 phút trước đó và cứu nguy toàn bộ hệ thống trong tích tắc!

Hãy cùng mổ xẻ cơ chế hoạt động đằng sau phép thuật "quay ngược thời gian" này nhé!

1. Bản chất của Time Travel: Tại sao BigQuery lại cho phép "sửa sai"?

Trong các hệ quản trị cơ sở dữ liệu truyền thống (như MySQL InnoDB), khi bạn thực hiện câu lệnh UPDATE hoặc DELETE, dữ liệu cũ trên ổ đĩa sẽ bị ghi đè hoặc đánh dấu xóa để giải phóng không gian (thông qua cơ chế Undo Log/Redo Log có thời gian lưu giữ rất ngắn). Nếu bạn muốn khôi phục, bạn buộc phải dùng bản backup từ tệp định kỳ (Snapshot backup) – vừa lâu, vừa mất dữ liệu phát sinh sau thời điểm backup đó.

Còn trong BigQuery, nguyên lý cốt lõi của tầng lưu trữ Colossus là Tính bất biến (Immutability):

Các tệp dữ liệu lưu trên Colossus không bao giờ bị ghi đè trực tiếp.
Khi bạn thực hiện UPDATE, DELETE hoặc DROP TABLE, BigQuery không xóa dữ liệu ngay lập tức. Nó chỉ tạo ra các tệp thay đổi mới (Delta files) và ghi nhận rằng các tệp cũ không còn hiệu lực từ thời điểm hiện tại trở đi.
Toàn bộ các phiên bản dữ liệu cũ của bạn vẫn được lưu giữ an toàn trên hệ thống trong một khoảng thời gian mặc định là 7 ngày (168 giờ).

2. Cú pháp thực chiến: Truy vấn dữ liệu ở quá khứ bằng mệnh đề `FOR SYSTEM_TIME AS OF`

BigQuery cung cấp cho bạn cú pháp mở rộng FOR SYSTEM_TIME AS OF trực tiếp ngay trong mệnh đề FROM để nhìn xuyên thấu quá khứ.

2.1. Quay ngược thời gian bằng mốc thời gian tuyệt đối (`TIMESTAMP`)

Giả sử thảm họa lỡ tay UPDATE nhầm xảy ra lúc 23:50:00 ngày 18/10/2026. Bạn muốn xem lại trạng thái của bảng ngay trước thời điểm thảm họa xảy ra (ví dụ lúc 23:45:00):

SQL

-- Xem lại dữ liệu của bảng orders tại một thời điểm chính xác trong quá khứ
SELECT * 
FROM `my-project.core_dwh.fact_orders` 
FOR SYSTEM_TIME AS OF TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 15 MINUTE);

Hoặc chỉ định cụ thể một mốc TIMESTAMP tường minh:

SQL

SELECT * 
FROM `my-project.core_dwh.fact_orders` 
FOR SYSTEM_TIME AS OF TIMESTAMP('2026-10-18 23:45:00', 'Asia/Ho_Chi_Minh');

2.2. Khôi phục lại bảng bị sửa sai / xóa nhầm vào một bảng mới

Khi đã "soi" thấy dữ liệu sạch ở quá khứ, việc tiếp theo bạn cần làm là tạo lại bảng chính thức từ dữ liệu quá khứ đó:

SQL

-- Khôi phục bảng orders về trạng thái an toàn trước khi bị update nhầm
CREATE OR REPLACE TABLE `my-project.core_dwh.fact_orders` AS
SELECT * 
FROM `my-project.core_dwh.fact_orders` 
FOR SYSTEM_TIME AS OF TIMESTAMP('2026-10-18 23:45:00', 'Asia/Ho_Chi_Minh');

Chỉ trong 3 giây, bảng fact_orders đã được khôi phục nguyên vẹn trạng thái trước đó. Không cần restore tệp backup phức tạp!

2.3. Cứu bảng bị lỡ tay xóa mất (`DROP TABLE`)

Điều gì xảy ra nếu ai đó lỡ tay chạy lệnh DROP TABLE fact_orders; xóa văng cả bảng khỏi Dataset? Đừng hoảng loạn! Miễn là bảng đó bị xóa trong vòng 7 ngày qua, bạn vẫn có thể khôi phục nó bằng cách copy dữ liệu từ mốc thời gian ngay trước khi bảng bị xóa:

SQL

-- Khôi phục bảng đã bị DROP bằng cách tạo bảng mới từ thời điểm 10 phút trước
CREATE TABLE `my-project.core_dwh.fact_orders` AS
SELECT * 
FROM `my-project.core_dwh.fact_orders` 
FOR SYSTEM_TIME AS OF TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 10 MINUTE);

3. Cấu hình và Tùy chỉnh thời gian Time Travel (Time Travel Window)

Mặc định, thời gian giữ lại lịch sử (Time Travel Window) của mọi Dataset trong BigQuery là 7 ngày. Tuy nhiên, bạn hoàn toàn có thể điều chỉnh thông số này tùy thuộc vào yêu cầu bảo mật hoặc chính sách tiết kiệm chi phí lưu trữ của công ty:

Bạn có thể cấu hình ngắn lại (ví dụ chỉ giữ 2 ngày) để giảm dung lượng lưu trữ phụ trợ, hoặc kéo dài lên tùy theo gói dịch vụ.
Cấu hình này được thực hiện ngay tại cấp độ Dataset bằng lệnh ALTER DATASET:

SQL
```
-- Thay đổi thời gian Time Travel của dataset thành 3 ngày (72 giờ)
ALTER DATASET `my-project.core_dwh`
SET OPTIONS (max_time_travel_hours = 72);
```
(Giá trị tối thiểu cho phép là 24 giờ, tối đa là 168 giờ tương đương 7 ngày).

4. Lớp bảo vệ cuối cùng: Fail-safe (3 ngày bổ sung)

Nhiều anh em sẽ đặt câu hỏi: "Nếu qua mốc 7 ngày của Time Travel, dữ liệu cũ có biến mất vĩnh viễn không?"

Google hiểu rằng có những sự cố nghiêm trọng (như lỗi hệ thống ngầm hoặc điều tra pháp lý) mà sau 7 ngày người ta mới phát hiện ra dữ liệu bị thay đổi. Do đó, BigQuery có thêm một lớp bảo vệ nền tảng gọi là Fail-safe:

Ngay sau khi hết thời hạn Time Travel (ví dụ sau ngày thứ 7), dữ liệu cũ sẽ bước vào vùng Fail-safe kéo dài thêm 3 ngày nữa.
Trong vùng Fail-safe, người dùng thông thường không thể tự ý gọi lệnh FOR SYSTEM_TIME AS OF để truy vấn nữa.
Tuy nhiên, nếu bạn gặp sự cố cực kỳ khẩn cấp cần khôi phục dữ liệu nằm trong giai đoạn Fail-safe này, bạn có thể liên hệ với đội ngũ hỗ trợ Google Cloud Support để họ can thiệp khôi phục thủ công giúp bạn.

5. Lưu ý quan trọng về chi phí lưu trữ của Time Travel

Như đã đề cập ở Bài 6 (Mô hình tính phí), dung lượng lưu trữ của các phiên bản quá khứ trong thời gian Time Travel (và phần dữ liệu thay đổi delta) sẽ tính vào chi phí Storage của Dataset.

Nếu bạn bật chế độ tính tiền ổ cứng theo Physical Storage Billing, dung lượng Time Travel được tính toán dựa trên thực tế các byte thay đổi.
Việc giữ lại lịch sử 7 ngày đồng nghĩa với việc bạn sẽ trả thêm một chút chi phí lưu trữ cho các bản ghi cũ bị thay đổi/xóa. Đây là một sự đánh đổi cực kỳ xứng đáng để đổi lấy sự an toàn tuyệt đối cho hệ thống dữ liệu doanh nghiệp!

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

Tính năng Time Travel & Fail-safe chính là chiếc "phao cứu sinh" tối thượng của Google BigQuery:

Bảo vệ tính bất biến: Nhờ cơ chế lưu trữ phân tán của Colossus, mọi thao tác UPDATE, DELETE, DROP đều có thể được phục hồi dễ dàng.
Cú pháp FOR SYSTEM_TIME AS OF: Cho phép "soi" lại trạng thái dữ liệu chính xác đến từng mili-giây trong vòng 7 ngày qua.
Khôi phục chớp nhoáng: Dùng CREATE TABLE ... AS SELECT ... FOR SYSTEM_TIME AS OF để tái tạo bảng bị xóa nhầm hoặc sửa sai chỉ trong vài giây.

Tuy nhiên, trong quá trình vận hành các hệ thống Data Lakehouse hoặc chia sẻ dữ liệu quy mô lớn giữa các phòng ban mà không muốn sao chép tệp vật lý gây tốn kém ổ cứng, làm thế nào để tạo ra các bản sao lưu tức thì (Zero-copy cloning) mà không tốn một byte dung lượng lưu trữ nào?

Hẹn gặp lại anh em ở Bài học 25: Table Clones & Table Snapshots – Sao lưu dữ liệu quy mô lớn với chi phí lưu trữ gần như bằng 0 (Zero-copy)!

bigquery

1. Bản chất của Time Travel: Tại sao BigQuery lại cho phép "sửa sai"?

2. Cú pháp thực chiến: Truy vấn dữ liệu ở quá khứ bằng mệnh đề FOR SYSTEM_TIME AS OF

2.1. Quay ngược thời gian bằng mốc thời gian tuyệt đối (TIMESTAMP)