[DE Blog #04] Kiến Trúc Data Pipeline: Cuộc Cách Mạng ETL vs. ELT, Change Data Capture (CDC) & Nguyên Tắc Idempotency

1. Bối cảnh thực tế (Context & Problem Statement)

Trong các hệ thống dữ liệu truyền thống, dữ liệu từ các nguồn (CRM, Transaction DB, Logs) được kéo về một máy chủ trung gian (ETL Server như Informatica, Talend, SSIS), sau đó được làm sạch, biến đổi rồi mới ghi vào Data Warehouse.

Tuy nhiên, với sự bùng nổ của Cloud Data Warehouse (Snowflake, BigQuery, Redshift) và Data Lakehouse (Databricks) có năng lực tính toán cực lớn (Compute tách rời Storage), kiến trúc ELT đã trở thành tiêu chuẩn mới. Đồng thời, nhu cầu cập nhật dữ liệu với độ trễ thấp (Near Real-time) mà không làm quá tải cơ sở dữ liệu vận hành đã đưa kỹ thuật Change Data Capture (CDC) trở thành kỹ năng bắt buộc của Data Engineer.

2. Các Khái Niệm & Cơ Chế Cốt Lõi

2.1. ETL vs. ELT: Sự Chuyển Dịch Kiến Trúc

ETL (Extract - Transform - Load): Dữ liệu được trích xuất từ nguồn $\rightarrow$ Biến đổi trên bộ nhớ của ETL Server riêng biệt $\rightarrow$ Nạp dữ liệu sạch vào Data Warehouse.
ELT (Extract - Load - Transform): Dữ liệu thô được trích xuất $\rightarrow$ Nạp thẳng vào Data Warehouse / Data Lake (Raw Zone) $\rightarrow$ Sử dụng chính sức mạnh tính toán song song phân tán (MPP) của Data Warehouse (kết hợp với công cụ như dbt) để biến đổi dữ liệu theo nhu cầu.

2.2. Change Data Capture (CDC) - Thu Thập Dữ Liệu Biến Động

CDC là kỹ thuật xác định và bắt giữ các thay đổi (INSERT, UPDATE, DELETE) trong database nguồn và truyền tải đến hệ thống đích theo thời gian thực hoặc định kỳ:

Query-based CDC (Poller): Chạy câu lệnh SELECT * FROM table WHERE updated_at > :last_sync_time định kỳ.
Log-based CDC (Transaction Log): Trực tiếp đọc và phân tích file nhật ký giao dịch của Database (PostgreSQL WAL, MySQL Binlog, Oracle Redo Log) thông qua các công cụ như Debezium, Kafka Connect.

2.3. Nguyên Tắc Vàng: Idempotency (Tính Lũy Đẳng / Bất Biến)

Trong môi trường phân tán, lỗi mạng, crash server hoặc dữ liệu đến trễ là điều chắc chắn xảy ra. Pipeline bắt buộc phải có tính Idempotent: $\text{Pipeline}(X) = \text{Pipeline}(\text{Pipeline}(X))$

Ý nghĩa: Dù bạn chạy pipeline 1 lần hay chạy lại (rerun/backfill) 10 lần cho cùng một khoảng thời gian, dữ liệu kết quả cuối cùng trong bảng đích vẫn luôn đồng nhất và không bị trùng lặp (No Duplicates).
Các kỹ thuật tạo Idempotency:
- Partition Overwrite / Truncate-Insert: Xóa toàn bộ partition của ngày cần xử lý trước khi ghi lại (INSERT OVERWRITE partition(date='2026-08-15')).
- Upsert (MERGE Statement): Sử dụng câu lệnh MERGE INTO target USING source ON target.id = source.id WHEN MATCHED THEN UPDATE WHEN NOT MATCHED THEN INSERT.
- Staging & Deduplication: Đọc dữ liệu vào bảng Staging tạm thời, lọc trùng bằng ROW_NUMBER() OVER(PARTITION BY id ORDER BY updated_at DESC) rồi mới nạp vào bảng chính.

2.4. Kiến Trúc Phân Tầng Dữ Liệu (Medallion Architecture)

Chuẩn kiến trúc phổ biến nhất trong Modern Data Stack / Lakehouse:

Bronze Layer (Raw): Chứa dữ liệu thô nguyên bản từ nguồn (Append-only, chứa metadata ngày nạp).
Silver Layer (Cleaned & Conformed): Dữ liệu đã được chuẩn hóa kiểu dữ liệu, làm sạch (Deduplicated, Filtered nulls, Flattened JSON).
Gold Layer (Aggregated / Business-ready): Dữ liệu tổng hợp theo mô hình Star Schema / Data Marts phục vụ trực tiếp cho BI, Dashboard và ML.

3. Các Bảng Markdown So Sánh Chi Tiết

📊 Bảng 1: So Sánh Toàn Diện ETL vs. ELT

Tiêu chí	ETL (Extract - Transform - Load)	ELT (Extract - Load - Transform)
Nơi xử lý biến đổi	Máy chủ ETL riêng (Informatica, Talend, Airflow python workers)	Trực tiếp bên trong Data Warehouse/Lakehouse (BigQuery, Snowflake, Databricks)
Thời gian nạp dữ liệu	Chậm hơn (phải chờ biến đổi xong mới nạp)	Rất nhanh (đẩy dữ liệu thô vào trước rồi transform sau)
Lưu trữ dữ liệu thô	Không lưu dữ liệu thô (hoặc phải lưu thêm chỗ khác)	Lưu trữ toàn bộ dữ liệu thô ở Bronze/Raw Layer (dễ dàng sửa đổi/re-process)
Tính linh hoạt	Kém linh hoạt, mỗi lần đổi logic phải sửa toàn bộ pipeline	Rất cao, phân tách rõ ràng tầng Ingestion và tầng Modeling (dbt)
Bảo mật dữ liệu (Data Privacy)	Dễ dàng che dấu/mã hóa (Masking/Anonymize PII) trước khi vào DWH	Cần phân quyền chặt chẽ trên tầng Raw Zone trong DWH
Công nghệ tiêu biểu	Apache NiFi, Talend, AWS Glue (Spark jobs)	Fivetran, Airbyte, Stitch + dbt, Snowflake, BigQuery

📊 Bảng 2: So Sánh Log-based CDC vs. Query-based CDC

Tiêu chí	Log-based CDC (Debezium / Kafka Connect)	Query-based CDC (Timestamp Polling)
Cơ chế hoạt động	Đọc trực tiếp từ file Transaction Log (Binlog/WAL)	Chạy câu lệnh `SELECT ... WHERE updated_at > ...` định kỳ
Tác động lên Database nguồn	Gần như bằng 0 (chỉ đọc file log tuần tự)	Cao (chiếm dụng CPU, I/O và có thể gây lock bảng khi query)
Khả năng bắt sự kiện DELETE	Bắt được hoàn toàn (Log ghi nhận rõ thao tác Delete)	Không bắt được (trừ khi ứng dụng sử dụng Soft Delete `is_deleted=true`)
Bắt các biến động trung gian	Bắt được mọi trạng thái thay đổi giữa các chu kỳ	Bị mất dữ liệu nếu 1 bản ghi bị update nhiều lần giữa 2 lần query
Độ trễ (Latency)	Near Real-time (vài mili-giây đến vài giây)	Phụ thuộc vào chu kỳ quét (vài phút đến vài giờ)
Yêu cầu cài đặt	Cần quyền cấu hình replication/log trên database nguồn	Đơn giản, chỉ cần quyền `SELECT` và bảng có cột timestamp

📊 Bảng 3: So Sánh 3 Phân Tầng Trong Medallion Architecture

Phân tầng	Tên gọi	Mục đích chính	Định dạng lưu trữ	Đối tượng sử dụng
Bronze	Raw Zone	Lưu nguyên bản 100% dữ liệu gốc từ nguồn, lưu lịch sử đầy đủ	Parquet, JSON, Delta Lake (Append-only)	Data Engineers (phục vụ backup, reprocess)
Silver	Conformed / Enriched	Làm sạch, chuẩn hóa kiểu dữ liệu, khử trùng lặp (Deduplicated)	Parquet, Delta Lake, Snowflake Tables	Data Engineers, Data Scientists
Gold	Curated / Marts	Tổng hợp số liệu kinh doanh theo Dimensional Modeling (Star Schema)	Data Warehouse Tables, Aggregated Views	Business Analysts, BI Dashboard, C-Level

4. Best Practices & Cạm Bẫy Thực Chiến (Pro-Tips & Pitfalls)

💡 Cạm bẫy: Mất dữ liệu khi dùng Query-based CDC (Out-of-order Commits)

Vấn đề: Giao dịch $A$ bắt đầu lúc 10:00:00 nhưng commit lúc 10:00:05. Giao dịch $B$ bắt đầu lúc 10:00:02 và commit lúc 10:00:03. Nếu pipeline quét lúc 10:00:04 lấy mốc 10:00:03, ở lần quét tiếp theo nó sẽ bỏ sót hoàn toàn dữ liệu của giao dịch $A$ !
Giải pháp: Sử dụng Lookback Window (quét dôi ra thêm 5–10 phút) kết hợp với cơ chế Deduplication / Upsert ở tầng đích, hoặc chuyển hẳn sang Log-based CDC.

💡 Chiến lược Write-Audit-Publish (WAP) cho Data Pipeline

Write: Ghi dữ liệu mới vào một bảng tạm / phân vùng ẩn (Staging).
Audit: Chạy bộ kiểm tra chất lượng tự động (kiểm tra NULL, trùng khóa chính, schema, số lượng dòng bất thường).
Publish: Nếu tất cả test PASS, mới tiến hành Swap hoặc Publish dữ liệu vào bảng Production. Nếu FAIL, gửi cảnh báo và hủy bỏ mà không làm bẩn dữ liệu phục vụ báo cáo.

5. Góc Ôn Luyện Phỏng Vấn (Interview Corner)

❓ Câu hỏi 1: Tại sao Modern Data Stack lại chuyển dịch từ ETL sang ELT? Trường hợp nào bạn vẫn bắt buộc phải áp dụng ETL truyền thống?

Gợi ý trả lời:
- Lý do chuyển sang ELT:
  1. Tách rời Compute & Storage: Lưu trữ trên Cloud (S3, GCS) cực rẻ, trong khi các Cloud DWH (Snowflake, BigQuery) xử lý phép biến đổi dữ liệu song song cực mạnh, nhanh hơn nhiều so với ETL server đơn lẻ.
  2. Bảo tồn dữ liệu thô: ELT giữ lại toàn bộ dữ liệu ở Raw Layer, giúp Data Engineer dễ dàng viết lại logic biến đổi hoặc sửa lỗi (Backfill) mà không cần kéo lại dữ liệu từ nguồn.
  3. Phân tách trách nhiệm: Đội Data Engineer chỉ cần tập trung Ingestion (Extract & Load), còn Data Analyst / Analytics Engineer có thể tự viết SQL/dbt để Transform.
- Bắt buộc dùng ETL khi:
  - Tuân thủ quy định bảo mật nghiêm ngặt (Data Privacy / Compliance như GDPR, HIPAA, PCI-DSS): Cần mã hóa/xóa bỏ dữ liệu nhạy cảm (PII - CCCD, số thẻ tín dụng, mật khẩu) ngay trên luồng trung gian trước khi nạp vào kho dữ liệu tập trung.
  - Giới hạn băng thông hoặc chi phí lưu trữ: Nguồn dữ liệu IoT/Log quá lớn cần nén, lọc và tổng hợp sơ bộ trước khi gửi lên Cloud.

❓ Câu hỏi 2: Làm thế nào bạn thiết kế một Data Pipeline đảm bảo tính Idempotent từ đầu đến cuối?

Gợi ý trả lời theo cấu trúc 3 phần:
1. Tầng Ingestion (Bronze Layer): Lưu dữ liệu thô kèm metadata (ingestion_timestamp, source_file_name). Lưu theo từng phân vùng ngày/giờ (partition_date). Nếu nạp lại ngày nào, ghi đè toàn bộ phân vùng ngày đó (INSERT OVERWRITE).
2. Tầng Transformation (Silver Layer): Luôn áp dụng câu lệnh MERGE INTO (Upsert) dựa trên Primary Key/Business Key kết hợp điều kiện WHERE source.updated_at >= target.updated_at, hoặc chạy hàm lọc trùng ROW_NUMBER() trước khi ghi.
3. Tầng Aggregation (Gold Layer): Thiết kế các Data Marts theo dạng snapshot hoặc tính toán lại toàn bộ khoảng thời gian bị ảnh hưởng thay vì cộng dồn (accumulate) số liệu mù quáng.

❓ Câu hỏi 3: Khi sử dụng Debezium / Kafka Connect cho Log-based CDC, nếu hệ thống nguồn thực hiện một phép thay đổi cấu trúc bảng (Schema Migration như `ALTER TABLE ADD COLUMN`), pipeline sẽ xử lý như thế nào?

Gợi ý trả lời:
- Debezium có cơ chế Schema Tracking: Nó đọc file DDL log của database nguồn và cập nhật một bản sao cấu trúc bảng nội bộ (Database Schema History).
- Khi có cột mới, Debezium đóng gói payload kèm schema mới và gửi vào Kafka.
- Khi kết hợp với Schema Registry (Avro/Protobuf):
  - Cần cấu hình mức độ tương thích (Compatibility Level) phù hợp (thường là BACKWARD hoặc FULL).
  - Nếu cột mới có giá trị mặc định (DEFAULT value), downstream consumers vẫn đọc được bình thường mà không bị crash.
  - Downstream sink connector (ví dụ nạp vào Snowflake/BigQuery) có thể kích hoạt tính năng Schema Evolution / Auto-add column để tự động tạo thêm cột mới trên bảng đích.

6. Tóm Tắt Ghi Nhớ Nhanh (Key Takeaways)

ELT là tiêu chuẩn của Modern Data Stack nhờ sức mạnh tính toán vượt trội của Cloud Data Warehouse kết hợp dbt.
Log-based CDC (Debezium + Kafka) là phương pháp tối ưu nhất để bắt thay đổi dữ liệu mà không gây tải cho Database nguồn và bắt được sự kiện DELETE.
Idempotency là nguyên tắc cốt tử: Pipeline phải luôn cho ra cùng một kết quả dù bị chạy lại nhiều lần.
Medallion Architecture (Bronze $\rightarrow$ Silver $\rightarrow$ Gold) là kiến trúc chuẩn mực để tổ chức dữ liệu từ thô đến tinh chế.