Junior to Middle Data Engineer (Kỹ sư dữ liệu thực chiến)

Ở cấp Junior, bạn chứng minh mình viết được pipeline. Ở cấp Middle, bạn chứng minh pipeline đó có thể sống trong production: chạy đúng lịch, chạy lại được, có test, có cảnh báo, có tài liệu, và không làm downstream mất niềm tin.

Chặng này nên học bằng cách xây một pipeline ELT hoàn chỉnh, không học từng công cụ rời rạc.

Checkpoint cần đạt

• Thiết kế bảng fact/dimension ở mức cơ bản, biết khai báo grain.
• Dùng Airflow hoặc công cụ tương đương để điều phối DAG.
• Hiểu partitioning, clustering và incremental load.
• Biết xử lý dữ liệu đến muộn, backfill và retry an toàn.
• Viết data tests: uniqueness, not null, accepted values, freshness.
• Tạo dashboard hoặc bảng mart có người dùng thực sự đọc được.

1. Mô hình hóa dữ liệu

Trước khi viết pipeline, hãy trả lời: mỗi dòng trong bảng đại diện cho điều gì? Kimball Group gọi đây là grain của fact table; nếu grain mơ hồ, số liệu downstream rất dễ sai dù SQL vẫn chạy thành công: Fact Tables and Dimension Tables.

Ví dụ bảng fact_orders có grain là “một dòng cho một order item”. Nếu sau đó bạn join với bảng payment ở grain “một dòng cho một payment attempt”, số tiền có thể bị nhân lên. Đây là lỗi rất phổ biến và rất khó phát hiện nếu chỉ nhìn tổng doanh thu.

Nhìn bằng số cụ thể: order #123 có 3 items và 2 payment attempts (1 fail, 1 thành công). Join thẳng hai bảng theo order_id cho ra 3 × 2 = 6 dòng — doanh thu nhân đôi, số item nhân đôi, và tổng vẫn “trông hợp lý” nếu bạn không có số đối chứng. Phòng thủ chuẩn: aggregate payment về grain order trước khi join:

WITH payments_per_order AS (
  SELECT order_id, SUM(amount) AS paid_amount     -- đưa về grain order
  FROM raw_payments WHERE status = 'success'
  GROUP BY order_id
)
SELECT o.*, p.paid_amount
FROM fact_order_items o
LEFT JOIN payments_per_order p USING (order_id);  -- join 1-1, không fan-out

Học theo thứ tự:

1. Grain, fact, dimension.
2. Star schema và slowly changing dimension.
3. Snapshot, incremental model, audit columns.
4. Data mart cho một nghiệp vụ cụ thể.

Đọc trong site: Grain, Fact Table, Dimension Table, Dimensional Modeling, Star Schema, Slowly Changing Dimension.

2. Orchestration và DAG

Airflow/Dagster/Prefect không làm dữ liệu đúng thay bạn. Chúng giúp biểu diễn phụ thuộc, lịch chạy, retry và quan sát trạng thái. Airflow định nghĩa DAG là mô hình các task và dependency, nên phần thiết kế dependency phải rõ trước khi viết operator: Airflow DAGs.

Một DAG production tối thiểu cần:

• Task nhỏ, tên rõ, không nhồi toàn bộ logic vào một file.
• Retry có giới hạn và hiểu được task có idempotent không.
• Backfill chạy được theo khoảng ngày.
• Alert gửi đúng người, có link đến log và runbook.
• SLA hoặc freshness expectation cho bảng đầu ra.

flowchart TD
    A["extract_orders"] --> B["load_raw_orders"]
    B --> C["validate_raw"]
    C --> D["build_staging"]
    D --> E["build_marts"]
    E --> F["run_data_tests"]

Đọc trong site: Orchestration, DAG, Task Dependency, Retries SLA, Apache Airflow.

3. Warehouse và incremental processing

Cloud warehouse như BigQuery, Snowflake, Redshift hoặc Fabric Warehouse đều có cách tối ưu riêng, nhưng nguyên tắc chung giống nhau:

Chủ đề	Cần nắm
Partition	Cắt dữ liệu theo ngày/tháng hoặc khóa lọc chính.
Clustering/sort key	Sắp xếp dữ liệu theo cột hay filter/join.
Incremental load	Chỉ xử lý phần thay đổi, nhưng phải có chiến lược late-arriving data.
Cost	Query ít cột, lọc partition sớm, tránh rebuild toàn bảng khi không cần.

Đọc trong site: Incremental Load, Partitioning, Clustering, Google BigQuery, Snowflake.

4. CDC và dữ liệu thay đổi

Change Data Capture giúp lấy thay đổi từ hệ thống nguồn mà không phải scan toàn bộ. Nhưng CDC đi kèm nhiều tình huống khó: update nhiều lần, delete, event đến trễ, schema đổi, transaction bị chia nhỏ.

Khi làm CDC, hãy lưu raw event trước. Đừng vội overwrite bảng đích nếu chưa có audit trail.

Đọc trong site: Change Data Capture, Log-based CDC Internals, Schema Evolution.

5. Testing và data quality

Test tốt không chỉ kiểm tra null. Test tốt phản ánh hợp đồng với người dùng dữ liệu:

• order_id không được trùng trong mart order-level.
• paid_amount không âm.
• event_time không được lớn hơn thời gian hiện tại quá xa.
• Bảng dashboard phải fresh trước 8 giờ sáng.
• Tổng doanh thu mart phải reconcile được với raw/payment source trong ngưỡng chấp nhận.

Đọc trong site: Data Quality, Data Testing, dbt Testing, Freshness Monitoring, Data Reconciliation.

Checklist đọc concept

Mốc học	Concept nội bộ cần đọc
Thiết kế mart	Grain, Fact Table, Dimension Table
Điều phối pipeline	DAG, Orchestration, Retries SLA
Load tăng dần	Incremental Load, Backfill, Idempotency
Kiểm tra dữ liệu	Data Testing, Freshness Monitoring, Data Reconciliation

Dự án thực hành

Dự án: E-commerce ELT pipeline

1. Tạo dữ liệu giả lập: customers, products, orders, payments, events.
2. Load raw vào PostgreSQL hoặc DuckDB/BigQuery.
3. Dùng dbt hoặc SQL thuần để tạo staging, dimension, fact.
4. Điều phối bằng Airflow.
5. Thêm data tests và freshness check.
6. Viết một runbook: pipeline fail ở task nào thì kiểm tra gì.

Kết quả tốt không phải là dashboard đẹp. Kết quả tốt là người khác có thể nhìn vào repo và hiểu pipeline đang đảm bảo điều gì.

Góc phỏng vấn

• Grain là gì? Cho ví dụ lỗi do join khác grain.
• Retry khác backfill như thế nào?
• Pipeline chạy lại vì task fail thì làm sao tránh duplicate?
• Partition theo created_at hay event_date, chọn thế nào?
• CDC xử lý delete và late event ra sao?

Khi nào nên đi tiếp?

Bạn sẵn sàng sang Middle to Senior khi có thể vận hành một pipeline production nhỏ trong vài tuần, xử lý được sự cố thường gặp, và biết diễn giải trade-off giữa độ đúng, độ trễ, chi phí và độ phức tạp.

References

• Fact Tables and Dimension Tables - Kimball Group.
• DAGs - Apache Airflow.
• What is dbt? - dbt Labs.
• Data contracts - dbt Labs.
• PostgreSQL Indexes - PostgreSQL Global Development Group.