Wavi Books · Data Engineering & Phân tích dữ liệu

ETL là gì? Phân biệt ETL, ELT và cách xây Data Pipeline

Nguyễn Minh Trí · Biên tập chuyên môn Wavi Books

ETL là gì, ETL khác ELT thế nào, các bước extract-transform-load và nguyên tắc xây data pipeline ổn định cho Data Engineer.

## ETL là gì

ETL là quy trình trích xuất dữ liệu từ nguồn, biến đổi theo quy tắc rồi nạp vào hệ thống đích. ELT nạp dữ liệu thô trước và biến đổi trong data warehouse hoặc lakehouse.

Lựa chọn ETL hay ELT phụ thuộc vào hạ tầng, yêu cầu bảo mật, khối lượng dữ liệu và nơi thực thi biến đổi. Điều quan trọng hơn tên gọi là khả năng theo dõi, chạy lại và kiểm soát chất lượng.

## Những khái niệm cốt lõi cần nắm

- Extract kết nối nguồn và ghi nhận mốc dữ liệu.

- Transform chuẩn hóa schema và quy tắc nghiệp vụ.

- Load đưa dữ liệu vào đích an toàn.

- Orchestration quản lý lịch chạy và phụ thuộc.

## Lộ trình thực hành từng bước

- Bước 1: Định nghĩa hợp đồng dữ liệu và tiêu chí chất lượng.

- Bước 2: Thiết kế incremental load cùng cơ chế idempotent.

- Bước 3: Thêm cảnh báo, lineage và quy trình xử lý dữ liệu lỗi.

## Những sai lầm thường gặp

- Full load mọi bảng mỗi ngày.

- Nhúng quy tắc nghiệp vụ không có kiểm thử.

- Không lưu thời điểm và nguồn gốc bản ghi.

## Góc nhìn dành cho người học và developer Việt Nam

Với doanh nghiệp Việt Nam có nhiều nguồn Excel, phần mềm bán hàng và API, bước chuẩn hóa mã, múi giờ, dấu tiếng Việt và khóa định danh thường quyết định chất lượng pipeline.

## Nên học tiếp như thế nào?

Sau khi nắm phần cốt lõi, bạn nên tự xây một dự án nhỏ, ghi lại giả định, tiêu chí đánh giá và giới hạn của giải pháp. Các sách liên quan được Wavi Books gợi ý trong bài giúp bạn đào sâu kiến thức theo lộ trình có hệ thống thay vì chỉ ghép các hướng dẫn rời rạc.

## Data pipeline đáng tin cậy khác script chạy được ở điểm nào?

Một script có thể copy dữ liệu hôm nay nhưng pipeline phải chạy lặp lại, phát hiện dữ liệu mới, xử lý retry, không tạo bản ghi trùng, kiểm tra chất lượng và cho phép truy vết. Độ tin cậy quan trọng hơn số công cụ xuất hiện trong kiến trúc.

## Thiết kế incremental load

Full load đơn giản nhưng nhanh chóng đắt và chậm. Incremental load dùng updated_at, sequence, log thay đổi hoặc CDC. Với timestamp, cần xử lý late-arriving data và clock lệch; thường đọc chồng một cửa sổ thời gian rồi upsert theo khóa nghiệp vụ.

Idempotency nghĩa là chạy lại cùng input không làm thay đổi kết quả ngoài mong đợi. Có thể đạt bằng staging table, merge/upsert, partition overwrite hoặc ghi output theo run ID rồi commit atomically.

```sql MERGE INTO dim_customer AS target USING staged_customer AS source ON target.customer_id = source.customer_id WHEN MATCHED AND target.row_hash <> source.row_hash THEN UPDATE SET name = source.name, updated_at = source.updated_at, row_hash = source.row_hash WHEN NOT MATCHED THEN INSERT (customer_id, name, updated_at, row_hash) VALUES (source.customer_id, source.name, source.updated_at, source.row_hash); ```

## Schema và hợp đồng dữ liệu

Schema drift xảy ra khi nguồn thêm, xóa hoặc đổi kiểu cột. Pipeline không nên âm thầm ép kiểu và tiếp tục. Data contract quy định trường, kiểu, semantics, owner, SLA và chính sách thay đổi. Thay đổi phá vỡ cần version hoặc giai đoạn tương thích.

Mô hình dữ liệu cũng quyết định khả năng phân tích. Fact table chứa sự kiện ở grain rõ ràng; dimension chứa ngữ cảnh. Slowly Changing Dimension Type 2 giữ lịch sử bằng effective_from, effective_to và current flag, nhưng chỉ cần khi nghiệp vụ cần truy vấn trạng thái trong quá khứ.

## Data quality ở nhiều lớp

- Freshness: dữ liệu có đến đúng hạn không.

- Completeness: có thiếu partition, bản ghi hoặc trường quan trọng không.

- Uniqueness: khóa có bị trùng không.

- Validity: kiểu và phạm vi có hợp lệ không.

- Consistency: tổng giữa các tầng có khớp không.

- Referential integrity: khóa ngoại có tìm được dimension không.

Test nên phân biệt warning và blocking. Một trường mô tả thiếu 1% có thể cảnh báo; thiếu 20% order_id phải dừng pipeline.

## Orchestration và backfill

DAG mô tả phụ thuộc dữ liệu, không chỉ thứ tự giờ chạy. Mỗi task nên nhỏ, retry độc lập và có input/output rõ. Backfill phải dùng cùng code production, nhận khoảng thời gian, kiểm soát tài nguyên và không ghi đè dữ liệu hiện tại ngoài ý muốn.

## Observability và lineage

Theo dõi run duration, records in/out, error, retry, freshness và chi phí. Lineage trả lời cột báo cáo đến từ đâu, qua biến đổi nào và dashboard nào bị ảnh hưởng khi nguồn đổi. Log chỉ ghi “task failed” không đủ; cần run ID, partition, source offset và rule chất lượng thất bại.

## Case study dữ liệu đơn hàng đa kênh

Doanh nghiệp có website, sàn và file Excel từ cửa hàng. Pipeline đầu tiên cần chuẩn hóa timezone, tiền tệ, mã sản phẩm và trạng thái đơn; tạo khóa nguồn để chống trùng; lưu raw bất biến; biến đổi sang staging; kiểm tra số đơn/doanh thu; rồi mới nạp mart. Việc mapping trạng thái nghiệp vụ thường khó hơn chọn Airflow hay dbt.

## Checklist vận hành

Pipeline phải chạy lại được, có owner, SLA, cảnh báo có hành động, tài liệu backfill, test dữ liệu và dashboard sức khỏe. Nếu không biết phải làm gì khi cảnh báo xuất hiện, cảnh báo đó chưa hữu ích.