Thu thập dữ liệu thay đổi (CDC, Change Data Capture)

1. Tổng quan

A. Định nghĩa

Thu thập dữ liệu thay đổi (CDC, Change Data Capture) là kỹ thuật tích hợp dữ liệu phát hiện và trích xuất gần như thời gian thực (near real-time) các sự kiện thay đổi chèn, sửa, xóa (INSERT/UPDATE/DELETE) phát sinh trong cơ sở dữ liệu nguồn, rồi lan truyền tới các hệ thống hạ nguồn (kho dữ liệu, hồ dữ liệu, công cụ tìm kiếm, bộ nhớ đệm, vi dịch vụ).

Ý tưởng cốt lõi của CDC là "thay vì định kỳ đọc lại toàn bộ dữ liệu (full reload), chỉ đẩy đi phần đã thay đổi (delta)". Nếu tái sử dụng dấu vết thay đổi mà nguồn vốn đã ghi lại — tiêu biểu là nhật ký giao dịch (WAL, redo log, binlog) — có thể nắm bắt chính xác, theo thứ tự, các sự thay đổi mà không cần sửa mã ứng dụng nguồn. Vì vậy, CDC ngày nay đã trở thành phương tiện tiêu chuẩn trên thực tế cho phân tích thời gian thực, đồng bộ dữ liệu giữa các vi dịch vụ và nạp dữ liệu (ingestion) vào data lakehouse.

B. Bối cảnh ra đời và sự cần thiết

Liên kết dữ liệu truyền thống được thực hiện bằng batch ban đêm (nightly batch). Cách trích xuất toàn bộ bảng nguồn vào mỗi rạng sáng rồi nạp lại vào DW tuy hiện thực đơn giản nhưng có ba giới hạn căn bản. Thứ nhất, dữ liệu cũ tới tối đa một ngày (staleness) nên không hỗ trợ được ra quyết định thời gian thực. Thứ hai, đọc nguyên bảng hàng trăm triệu bản ghi mỗi lần gây tải lớn cho CSDL nguồn và thời gian batch bùng nổ. Thứ ba, cách nạp lại toàn bộ chỉ giữ lại snapshot tại thời điểm đó nên đánh mất lịch sử thay đổi "cái gì đã thay đổi thế nào, khi nào".

Cùng với chuyển đổi số, người dùng, cơ quan quản lý và nghiệp vụ ngày càng đòi hỏi độ trễ (latency) thấp hơn. Phát hiện gian lận (FDS) phải phản ánh giao dịch mới nhất theo từng giây, công cụ gợi ý và tìm kiếm phải lập chỉ mục ngay khi thông tin sản phẩm thay đổi, và vi dịch vụ cần biết sự thay đổi của dữ liệu do dịch vụ khác sở hữu. Khi đó, nếu thăm dò (polling) nguồn lặp đi lặp lại thì tải và độ trễ cùng tăng. CDC đẩy đi "chỉ phần thay đổi, ngay khi thay đổi phát sinh", qua đó đồng thời giảm nhẹ ba vấn đề độ trễ, tải, mất lịch sử.

Ngoài ra, sự lan rộng của kiến trúc vi dịch vụ (MSA) càng làm tăng nhu cầu CDC. Trong cấu trúc mỗi dịch vụ sở hữu CSDL độc lập, thường xảy ra tình huống nhiều dịch vụ cần biết một thay đổi ở nguồn, và nếu ứng dụng thực hiện riêng rẽ việc ghi CSDL và phát thông điệp thì phát sinh vấn đề ghi kép (dual write) (thất bại cục bộ khi chỉ một bên thành công). CDC lấy một sự thật duy nhất là commit CSDL làm nguồn để phát thay đổi, nên trở thành nền tảng giải quyết về cấu trúc vấn đề nhất quán này (mẫu transactional outbox).

2. Cấu trúc tổng thể và luồng dữ liệu của CDC

Pipeline CDC gồm bốn giai đoạn lớn: nguồn (Source) → thu thập (Capture) → truyền tải (Transport) → áp dụng (Sink). Giai đoạn thu thập trích xuất sự kiện thay đổi qua nhật ký giao dịch hoặc trigger, chuyển ổn định tới message broker (ví dụ Kafka), rồi connector hạ nguồn phản ánh vào đích. Mỗi sự kiện thay đổi thường chứa ảnh trước thay đổi (before), sau thay đổi (after), loại thao tác, dấu thời gian, vị trí log (offset).

flowchart LR
    subgraph SRC["Hệ thống nguồn"]
      APP["Ứng dụng nghiệp vụ"] --> DB[("CSDL vận hành")]
      DB --> LOG["Nhật ký giao dịch (WAL/binlog/redo)"]
    end
    LOG --> CAP["Thu thập CDC (connector)"]
    CAP --> MQ["Message broker (Kafka, v.v.)"]
    MQ --> S1["Hồ dữ liệu/kho dữ liệu"]
    MQ --> S2["Công cụ tìm kiếm/bộ nhớ đệm"]
    MQ --> S3["Vi dịch vụ khác"]

Điểm thiết kế quan trọng nhất trong cấu trúc trên là giai đoạn thu thập can thiệp vào nguồn đến mức nào. Cách đọc log gần như không gây tải cho CSDL nguồn và tách biệt hoàn toàn với ứng dụng, nhưng phụ thuộc vào định dạng log, quyền, cấu hình của từng loại CSDL. Ngược lại, cách dùng trigger hoặc cột dấu thời gian ít nhạy cảm với loại CSDL hơn nhưng can thiệp vào lược đồ và đường ghi của nguồn nên tăng tải và độ ghép nối. Sự đánh đổi này là tiêu chí cốt lõi để chọn phương thức CDC.

Một khái niệm bắt buộc khác là snapshot ban đầu (initial snapshot). CDC chỉ bắt "thay đổi từ bây giờ", nên nếu hạ nguồn chưa có dữ liệu quá khứ thì trước hết phải đọc toàn bộ nguồn một lần để tạo trạng thái cơ sở, sau đó nối tiếp các thay đổi trong log kể từ thời điểm đó. Vì nguồn vẫn tiếp tục thay đổi trong khi chụp snapshot, việc xử lý nhất quán — ghi chính xác vị trí log tại điểm snapshot và chỉ phát lại (replay) các thay đổi sau đó — là rất quan trọng.

3. Các loại phương thức hiện thực CDC

Cách hiện thực CDC chia thành ba nhóm lớn tùy theo phát hiện thay đổi ở đâu và như thế nào. Mỗi phương thức có khác biệt rõ rệt về tải nguồn, tính thời gian thực, khả năng phát hiện xóa, mức can thiệp vào nguồn, và khác biệt này quyết định mức phù hợp khi áp dụng.

Thứ nhất, CDC dựa trên log (Log-based) phân tích cú pháp nhật ký giao dịch mà CSDL vốn đã ghi để phục hồi và nhân bản. Đối tượng là WAL của PostgreSQL (slot nhân bản logic), binlog của MySQL (định dạng row), redo log của Oracle. Vì không truy vấn trực tiếp bảng nguồn nên tải thấp nhất, giữ nguyên thứ tự commit, và nắm bắt không sót cả thao tác xóa và thay đổi trung gian. Tuy nhiên, nó phụ thuộc vào định dạng log và cấu hình quyền, độ khó hiện thực cao, nên thường được hiện thực bằng framework chuyên dụng như Debezium. Đây là phương thức tiêu chuẩn trên thực tế của CDC trong thực tiễn.

Thứ hai, CDC dựa trên trigger (Trigger-based) gắn trigger AFTER INSERT/UPDATE/DELETE lên bảng nguồn để ghi nội dung thay đổi vào bảng lịch sử riêng (shadow table). Hoạt động được bất kể loại CSDL và có thể lưu chính xác giá trị trước và sau thay đổi, nhưng việc thực thi trigger chồng lên mọi giao dịch ghi khiến hiệu năng nguồn giảm và gánh nặng quản lý lược đồ tăng.

Thứ ba, CDC dựa trên truy vấn/dấu thời gian (Query-based) đặt cột như last_modified và định kỳ thăm dò bằng SELECT "các hàng đã thay đổi kể từ lần truy vấn trước". Hiện thực đơn giản nhất nhưng phát sinh độ trễ bằng chu kỳ thăm dò, các hàng bị xóa vật lý không truy vấn được nên không thể phát hiện xóa (cần cột xóa mềm), và bản thân việc thăm dò gây tải cho nguồn.

flowchart TB
    START["Yêu cầu phát hiện thay đổi"] --> Q1{"Có truy cập được<br/>nhật ký giao dịch nguồn?"}
    Q1 -- "Có" --> LOG["CDC dựa trên log<br/>(tải tối thiểu·thời gian thực·bắt được xóa)"]
    Q1 -- "Không" --> Q2{"Nguồn dư hiệu năng và<br/>cần phát hiện xóa?"}
    Q2 -- "Có" --> TRG["CDC dựa trên trigger"]
    Q2 -- "Không" --> QRY["CDC dựa trên truy vấn/dấu thời gian"]

Tổng hợp khác biệt của ba phương thức như sau. Bảng là phương tiện hỗ trợ so sánh; lựa chọn thực tế phải cân nhắc đồng thời mức can thiệp vào nguồn đã giải thích ở trên và các ràng buộc vận hành.

4. Các yếu tố kỹ thuật cốt lõi và bảo đảm nhất quán

Để biến CDC thành pipeline đáng tin cậy, cần vượt qua việc đơn thuần bắt thay đổi mà thiết kế tính chính xác (xử lý tương đương exactly-once). Yếu tố quan trọng nhất là quản lý offset. Connector thu thập liên tục lưu lại đã đọc log tới đâu, để khi khởi động lại sau sự cố thì đọc tiếp từ điểm đó, tránh mất mát. Ngược lại, khi xử lý lại, cùng một sự kiện có thể được phát lại, nên hạ nguồn phải hấp thụ trùng lặp bằng upsert lũy đẳng (idempotent) dựa trên khóa chính. Tức là CDC thường đạt hiệu quả exactly-once trên thực tế bằng tổ hợp "truyền at-least-once + áp dụng lũy đẳng".

Bảo đảm thứ tự (ordering) cũng là cốt lõi. Các thay đổi trên cùng một khóa (row) nhất định phải được áp dụng theo thứ tự phát sinh, nếu không sẽ xảy ra lỗi giá trị cũ ghi đè giá trị mới. Khi dùng Kafka, chỉ định khóa chính làm khóa phân vùng để các sự kiện cùng khóa giữ thứ tự trong cùng một phân vùng.

Ứng phó với thay đổi lược đồ (schema evolution) cũng là bài toán khó trong thực tế. Khi nguồn thêm hoặc bớt cột, cấu trúc sự kiện thay đổi, nên quản lý phiên bản bằng schema registry và áp dụng quy tắc tương thích ngược (tiến hóa tương thích) để hạ nguồn không bị hỏng.

Đặc biệt trong MSA, CDC kết hợp với mẫu Transactional Outbox để giải quyết vấn đề ghi kép. Nếu ứng dụng ghi dữ liệu nghiệp vụ và sự kiện cần phát cùng nhau vào bảng outbox của cùng CSDL trong một giao dịch cục bộ duy nhất, CDC sẽ bắt thay đổi log của bảng outbox đó và phát thành thông điệp. Commit CSDL chính là căn cứ phát sự kiện, nên thất bại cục bộ kiểu "CSDL đã lưu nhưng thông điệp bị mất" biến mất tận gốc.

5. Trường hợp ứng dụng và so sánh với kỹ thuật tương tự

Trường hợp ứng dụng. Trong thực tế, CDC thứ nhất đẩy thay đổi của CSDL vận hành vào data lakehouse để hỗ trợ dashboard và phân tích thời gian thực (ví dụ trong thương mại điện tử, phản ánh thay đổi đơn hàng, tồn kho vào hệ phân tích trong vài giây). Thứ hai, đồng bộ công cụ tìm kiếm và bộ nhớ đệm — khi thông tin sản phẩm thay đổi thì cập nhật ngay chỉ mục Elasticsearch và bộ nhớ đệm Redis. Thứ ba, di chuyển dữ liệu không gián đoạn — chuyển snapshot ban đầu sang hệ thống mới rồi dùng CDC tiếp tục bám theo phần thay đổi, giữ hai hệ thống ở trạng thái đồng bộ và chuyển đổi (switchover) tại thời điểm chuyển giao. Trong một trường hợp của công ty công nghệ toàn cầu, việc thay batch ban đêm bằng CDC dựa trên log được báo cáo là đã giảm độ trễ dữ liệu từ vài giờ xuống vài giây và giảm đáng kể tải CSDL nguồn (con số có thể thay đổi tùy môi trường).

So sánh với kỹ thuật tương tự, liên quan. CDC dễ bị nhầm với toàn bộ ETL, nhưng chính xác hơn là xem CDC như công nghệ thời gian thực hóa giai đoạn trích xuất (Extract) của ETL/ELT. Nếu ETL theo lô là "định kỳ, toàn bộ, độ trễ cao" thì pipeline dựa trên CDC là "liên tục, tăng dần, độ trễ thấp". Ngoài ra, cần phân biệt CDC với Event Sourcing. Event sourcing là kiến trúc trong đó ứng dụng ngay từ đầu thiết kế và lưu thay đổi trạng thái dưới dạng sự kiện, còn CDC trích xuất thay đổi sau sự việc từ CSDL dựa trên trạng thái hiện có. Điểm đích là trạng thái (state) cũng khác.

6. Những điều cần cân nhắc và hàm ý

CDC là yếu tố cốt lõi của kiến trúc dữ liệu thời gian thực, nhưng việc áp dụng cần phán đoán chiến lược từ góc nhìn Kỹ sư chuyên nghiệp (Professional Engineer).

• Đánh đổi nhất quán vs độ trễ: CDC thường lấy nhất quán cuối cùng làm tiền đề. Tồn tại độ trễ nhỏ (replication lag) cho tới khi hạ nguồn bắt kịp nguồn, nên không phù hợp với nghiệp vụ cần nhất quán mạnh (ví dụ kiểm tra kép số dư). Phải định nghĩa trước mức yêu cầu nhất quán của nghiệp vụ rồi xác định phạm vi áp dụng CDC.
• Bảo vệ nguồn và nguyên tắc không xâm nhập: CSDL vận hành là đối tượng bảo vệ ưu tiên hàng đầu. Ưu tiên xem xét phương thức không xâm nhập (non-intrusive) dựa trên log, nhưng phải quản lý trước bằng hệ thống giám sát và cảnh báo các rủi ro vận hành phía nguồn như dung lượng đĩa tăng do slot log không được tiêu thụ, quản lý slot nhân bản.
• Độ phức tạp vận hành và năng lực tổ chức: CDC có nhiều thành phần như broker, connector, schema registry, kho offset nên gánh nặng vận hành lớn khi tự xây dựng. Phải cân nhắc đồng thời TCO và mức phụ thuộc (lock-in) giữa dịch vụ được quản lý (CDC/streaming đám mây) và tự xây dựng bằng mã nguồn mở, đồng thời chuẩn hóa sẵn quy trình xử lý lại sau sự cố và bổ sung dữ liệu (backfill).
• Quản trị, bảo mật, tuân thủ pháp quy: Sự kiện thay đổi có thể chứa thông tin cá nhân, nên cùng với mã hóa, che dữ liệu, kiểm soát truy cập trên toàn pipeline, phải thiết kế để sự kiện xóa chắc chắn được lan truyền tới hạ nguồn (hồ dữ liệu, bộ nhớ đệm), đáp ứng nghĩa vụ hủy thông tin cá nhân (quyền được lãng quên).
• Triển vọng: CDC đang mở rộng thành đường nạp tiêu chuẩn cho data mesh, lakehouse, feature store thời gian thực, và kết hợp với xử lý luồng để tiến hóa thành "nền tảng dữ liệu thời gian thực không cần batch (batch-less)". Trong tương lai, xu hướng hợp đồng hóa và chia sẻ chính luồng thay đổi qua CDC như một sản phẩm dữ liệu (data product) được dự báo sẽ được tăng cường.

Tóm tắt một câu: CDC là kỹ thuật trích xuất theo thời gian thực chỉ phần thay đổi từ nhật ký giao dịch của CSDL nguồn, v.v. và lan truyền xuống hạ nguồn, giúp giảm độ trễ, tải và mất lịch sử; phương thức dựa trên log (không xâm nhập) cùng upsert lũy đẳng, bảo đảm thứ tự và mẫu outbox là cốt lõi của độ tin cậy.