Xây pipeline ELT với dbt và Airflow: lộ trình từ zero đến dashboard production

Phần lớn doanh nghiệp không thiếu dữ liệu — họ thiếu một con đường đáng tin cậy từ dữ liệu thô đến một con số mà người ra quyết định có thể nhìn vào và tin tưởng. Bài viết này mô tả lộ trình mà chúng tôi đề xuất khi xây dựng lớp Data Analytics trong một Pilot Build: từ dữ liệu rải rác trong CRM, hệ thống bán hàng, và file Excel, đến một warehouse có cấu trúc, có test, và có dashboard tự cập nhật.

Vì sao ELT, không phải ETL

ETL truyền thống (Extract-Transform-Load) biến đổi dữ liệu trước khi đưa vào warehouse — nghĩa là logic transform nằm trong một hệ thống trung gian, thường khó kiểm tra và khó thay đổi. ELT (Extract-Load-Transform) đưa dữ liệu thô vào warehouse trước, rồi transform bằng SQL ngay trong warehouse. Với các warehouse hiện đại (BigQuery, Snowflake, ClickHouse, hoặc Postgres cho quy mô nhỏ-vừa), compute đủ rẻ để làm điều này — và lợi ích là toàn bộ logic transform trở thành code có thể version, test, và review giống phần mềm thông thường.

Ba lớp trong warehouse — staging, intermediate, marts

dbt (data build tool) tổ chức transform thành các model SQL, thường chia theo ba lớp:

Staging: 1-1 với nguồn dữ liệu thô — chỉ đổi tên cột, ép kiểu dữ liệu, lọc bản ghi rác. Không có business logic ở đây
Intermediate: nơi các bảng từ nhiều nguồn được join, dedupe, hoặc tính toán trung gian — ví dụ gộp đơn hàng từ hệ thống POS và hệ thống online thành một bảng orders thống nhất
Marts: bảng cuối cùng, được thiết kế riêng cho một nhóm câu hỏi cụ thể (doanh thu theo cửa hàng, churn theo tháng...) — đây là những bảng mà BI tool kết nối vào

Quy tắc thực tế: nếu một con số xuất hiện trên 2 dashboard khác nhau, nó phải được tính ở đúng một chỗ — trong một mart model — không phải tính lại bằng công thức riêng trong mỗi dashboard.

Vai trò của Airflow — không phải để chạy SQL, mà để điều phối

Một nhầm lẫn phổ biến là nghĩ Airflow "chạy transform". Thực ra Airflow chỉ điều phối: gọi lệnh dbt run đúng thứ tự, đúng thời điểm, sau khi dữ liệu nguồn đã sẵn sàng — và xử lý khi một bước thất bại (retry, alert, backfill). Bản thân logic transform vẫn nằm trong dbt. Tách hai vai trò này rõ ràng giúp:

Đổi orchestrator (Airflow → Dagster, hoặc ngược lại) không cần viết lại transform
Chạy và test transform locally mà không cần Airflow đang chạy
Debug dễ hơn — "transform sai" và "job không chạy" là hai loại lỗi khác nhau, ở hai layer khác nhau

Data contract — hợp đồng giữa các team

Khi nhiều team cùng đóng góp vào một warehouse, điều dễ xảy ra nhất là một team đổi schema ở nguồn (đổi tên cột, đổi kiểu dữ liệu) và làm vỡ dashboard của team khác — thường được phát hiện vài ngày sau, khi ai đó thắc mắc tại sao số liệu sai. Data contract là một quy ước đơn giản: mỗi bảng nguồn quan trọng có một schema được khai báo rõ ràng (dbt sources.yml), kèm test tự động (not_null, unique, relationships) chạy mỗi lần pipeline thực thi. Nếu nguồn thay đổi và phá vỡ contract, pipeline fail ngay tại bước staging — trước khi dữ liệu sai lan đến dashboard.

Lộ trình triển khai thực tế — 4 giai đoạn

Giai đoạn 1 — Audit và data contract (1-2 tuần)

Liệt kê tất cả nguồn dữ liệu hiện có, đánh giá độ tin cậy, và định nghĩa schema mong đợi cho mỗi nguồn. Đây là giai đoạn rẻ nhất nhưng thường mang lại phát hiện lớn nhất — rất nhiều "sự thật" về dữ liệu mà team vận hành tin tưởng thực ra không đúng khi kiểm tra trực tiếp.

Giai đoạn 2 — Staging layer + pipeline tối thiểu (2-3 tuần)

Đưa 2-3 nguồn quan trọng nhất vào warehouse, xây staging models với test cơ bản, và một Airflow DAG đơn giản chạy hằng ngày. Mục tiêu là có một vòng end-to-end hoạt động — dù chỉ phục vụ một câu hỏi business duy nhất — trước khi mở rộng.

Giai đoạn 3 — Marts + dashboard đầu tiên (2-3 tuần)

Xây 1-2 mart model trả lời câu hỏi business cụ thể (ví dụ: doanh thu và tỷ lệ hủy đơn theo ngày/khu vực), kết nối với dashboard (Superset, Metabase, hoặc Looker Studio). Đây là điểm mà giá trị trở nên hữu hình với người dùng cuối — và thường là lúc xuất hiện yêu cầu mở rộng tiếp theo.

Giai đoạn 4 — Mở rộng + self-service (liên tục)

Thêm nguồn dữ liệu mới theo nhu cầu, training cho team business tự xây dashboard trên các mart đã có sẵn (không cần viết SQL phức tạp), và thiết lập alerting khi test dbt fail — đây chính là vòng lặp Optimization Loop áp dụng cho hạ tầng dữ liệu.

Một lưu ý về công cụ

dbt và Airflow là lựa chọn phổ biến và có ecosystem tốt, nhưng không phải lựa chọn duy nhất — với quy mô nhỏ hơn, một cron job đơn giản gọi script Python + dbt core, hoặc Dagster thay Airflow, có thể là lựa chọn hợp lý hơn và ít overhead vận hành hơn. Công cụ nên được chọn sau khi đã rõ khối lượng dữ liệu và số lượng pipeline cần quản lý — không phải trước.

Kết luận

Một pipeline ELT tốt không được đánh giá bằng việc nó dùng công cụ gì, mà bằng việc: khi dữ liệu sai, pipeline có báo ngay tại nguồn không, và khi cần thêm một câu hỏi business mới, có cần viết lại từ đầu không. Đây là tiêu chí chúng tôi dùng khi thiết kế lớp Data Analytics cho mỗi Pilot Build — bắt đầu nhỏ, nhưng với cấu trúc đủ chắc để mở rộng mà không cần đập đi xây lại, như trong pipeline ETL gộp dữ liệu telematics cho 600 xe tải mà chúng tôi đã xây dựng.