Pinterest dùng watermark theo thời gian sự kiện để chốt phân vùng dữ liệu cỡ petabyte

Công nghệ19 tháng 10, 2026·3 phút đọc

Pinterest đã triển khai cơ chế chốt phân vùng dựa trên thời gian sự kiện cho khung thu nạp dữ liệu từ cơ sở dữ liệu. Hệ thống dùng Apache Flink để theo dõi thời gian sự kiện và metadata Apache Iceberg để công bố watermark không lùi, giúp các job phía sau biết khi nào dữ liệu CDC được nạp liên tục đã đủ đầy để xử lý.

Pinterest vừa công bố cơ chế chốt phân vùng theo thời gian sự kiện (event time-based partition finalization) cho khung thu nạp dữ liệu từ cơ sở dữ liệu của mình. Đây là bài toán quen thuộc với mọi hệ thống dữ liệu lớn: làm sao biết một phân vùng dữ liệu đã "đủ đầy" để các job phía sau có thể xử lý an toàn, trong khi dữ liệu vẫn liên tục đổ về từ các luồng CDC.

Vấn đề: dữ liệu CDC không bao giờ "dừng"

Pinterest vận hành khối lượng dữ liệu khổng lồ, trong đó phần lớn được thu nạp liên tục từ các cơ sở dữ liệu giao dịch thông qua CDC (Change Data Capture). Với mô hình này, dữ liệu không đến theo từng lô rồi kết thúc, mà chảy vào gần như không ngừng nghỉ.

Điều đó đặt ra một câu hỏi hóc búa cho các job hạ nguồn: khi nào thì một phân vùng có thể coi là hoàn tất? Nếu xử lý quá sớm, job sẽ bỏ sót bản ghi đến muộn. Nếu chờ quá lâu, độ trễ tăng và chi phí tính toán cũng tăng theo.

Cách Pinterest giải quyết

Giải pháp của Pinterest kết hợp hai mảnh ghép quen thuộc trong hệ sinh thái dữ liệu mở:

  • Apache Flink chịu trách nhiệm theo dõi thời gian sự kiện — tức thời điểm bản ghi thực sự phát sinh ở hệ nguồn, chứ không phải thời điểm nó được xử lý.
  • Metadata của Apache Iceberg được dùng để công bố một watermark không lùi (non-regressing watermark), tức một mốc thời gian chỉ tiến về phía trước và không bao giờ bị kéo ngược lại.

Nhờ watermark này, các job hạ nguồn có thể đọc metadata và tự quyết định: phân vùng nào đã đủ chín để xử lý, phân vùng nào vẫn cần chờ thêm dữ liệu đến muộn.

Điểm mấu chốt là watermark không lùi. Nếu mốc thời gian có thể bị kéo ngược, mọi logic "chốt phân vùng" phía sau sẽ mất tính ổn định và buộc phải xử lý lại dữ liệu.

Vì sao cách tiếp cận này đáng chú ý

Việc đặt cơ chế chốt phân vùng ngay trong metadata của bảng Iceberg mang lại vài lợi ích rõ rệt:

  • Tách rời việc ghi và việc đọc: job ghi dữ liệu không cần biết ai đang đọc, còn job đọc chỉ cần tra metadata.
  • Giảm phụ thuộc vào giờ đồng hồ hệ thống: dùng thời gian sự kiện thay vì thời gian xử lý giúp kết quả ổn định hơn khi có độ trễ hoặc xử lý lại.
  • Hạn chế xử lý lại không cần thiết: job hạ nguồn biết chính xác khi nào nên chạy, tránh cả việc chạy sớm lẫn chạy thừa.

Với các đội dữ liệu tại Việt Nam đang xây dựng data lakehouse trên Iceberg hoặc Hudi, bài học ở đây khá thực tế: vấn đề "khi nào dữ liệu đủ" thường bị xem nhẹ lúc thiết kế nhưng lại là nguồn gốc của rất nhiều sự cố số liệu sai lệch về sau. Đưa khái niệm watermark theo thời gian sự kiện vào ngay tầng lưu trữ là một hướng đi đáng tham khảo, đặc biệt khi luồng CDC ngày càng chiếm tỉ trọng lớn trong pipeline.

Chia sẻ:FacebookX
Nội dung tổng hợp bằng AI, mang tính tham khảo. Xem bài gốc ↗