Airflow là gì: DAG, task, scheduler và các thành phần
Xem thửCho tới tuần trước, GDev Mart điều phối pipeline bằng một dòng crontab:
0 2 * * * ./extract.sh && ./load.sh && ./transform.sh && ./publish.sh
Một đêm bước load.sh lỗi vì mạng chập chờn. Vì có &&, hai bước sau không chạy; không ai được báo; sáng hôm sau dashboard hiện dữ liệu cũ một ngày. Khi sửa, bạn phải chạy tay từng script từ đầu vì không biết bước nào đã xong. Khi thêm một bước mới chạy song song với load.sh, bạn lại phải viết thêm logic chờ bằng sleep.
Hãy dự đoán trước khi đọc tiếp: một công cụ điều phối (orchestrator) phải làm được những việc gì mà dòng crontab này không làm được? Liệt kê ít nhất bốn việc.
Sau bài này, bạn có thể
- Giải thích vì sao một workflow nên là đồ thị task có phụ thuộc thay vì chuỗi lệnh nối bằng
&&. - Phân biệt vai trò của scheduler, executor, worker, metadata database và API server.
- Phân biệt DAG, DAG run và task instance, rồi chỉ ra "chạy lại một ngày" tác động lên đối tượng nào.
Cần biết trước: bài "ETL và ELT: biến đổi ở đâu và vì sao điều đó quan trọng" và bài "Idempotent và backfill: chạy lại mà không hỏng dữ liệu" của chương trước. Bài này chưa cần cài Airflow; phần thực hành nằm ở lab cuối chương.
Mô hình tư duy 1: workflow là một đồ thị các bước có phụ thuộc, viết bằng code
Apache Airflow mô tả workflow dưới dạng DAG (Directed Acyclic Graph, đồ thị có hướng không chu trình) viết bằng Python. Mỗi nút là một task, mỗi mũi tên là một phụ thuộc "task này chạy sau task kia". Chữ "không chu trình" nghĩa là không thể có vòng lặp, để luôn có một thứ tự chạy hợp lệ.
Đang tải sơ đồ…
Cách đọc hình: hai nhánh extract_orders và extract_stores chạy song song vì không phụ thuộc nhau; build_daily_revenue chỉ chạy khi cả hai nhánh xong. Airflow tự tính thứ tự này từ khai báo, bạn không viết sleep hay &&.
Đang tải Animation…
Giải đáp: một orchestrator làm được những gì
So với crontab, Airflow cung cấp:
- Phụ thuộc rõ ràng giữa các task và chạy song song khi có thể.
- Thử lại tự động khi task lỗi, với cấu hình số lần và độ trễ.
- Lịch sử và trạng thái từng task của từng lần chạy, hiển thị trên giao diện web.
- Cảnh báo khi lỗi, kèm log của từng lần thử.
- Chạy lại một khoảng quá khứ (backfill) mà không sửa mã.
- Điều kiện chờ (sensor): đợi tệp xuất hiện hoặc một DAG khác xong.
Mô hình tư duy 2: các thành phần của Airflow và ai làm gì
Airflow không chỉ là thư viện; nó là một hệ thống nhiều thành phần cùng chạy:
| Thành phần | Vai trò |
|---|---|
| Thư mục DAG | Chứa các tệp Python định nghĩa DAG |
| DAG processor | Đọc và phân tích tệp DAG, lưu cấu trúc đã tuần tự hóa vào metadata database (Airflow 3 luôn chạy tiến trình này riêng; Airflow 2 do scheduler làm) |
| Scheduler | Quyết định task nào đến hạn chạy và đưa vào hàng đợi |
| Executor | Quy định task chạy ở đâu và bằng cách nào (cục bộ, Celery, Kubernetes) |
| Worker | Tiến trình thực thi mã của task |
| Metadata database | Lưu trạng thái mọi DAG run và task instance (thường là PostgreSQL) |
| API server | Giao diện web và API để xem, kích hoạt, theo dõi; task báo trạng thái về đây qua Task SDK (Airflow 2 gọi là webserver) |
Đang tải sơ đồ…
Cách đọc hình: scheduler là "bộ não" quyết định thời điểm, worker là "đôi tay" làm việc, metadata database là "trí nhớ" mà mọi thành phần chia sẻ. Giao diện web chỉ đọc và ghi trạng thái trong cơ sở dữ liệu này; nếu bạn thấy giao diện lỗi, pipeline không nhất thiết hỏng, và ngược lại.
Hai điều hệ quả: nếu scheduler dừng, không có lần chạy mới nào được tạo dù các worker vẫn khỏe; và tệp DAG được đọc lại liên tục (bởi DAG processor ở Airflow 3, bởi scheduler ở Airflow 2), nên mã ở cấp cao nhất của tệp DAG (ngoài các hàm task) phải nhẹ; gọi API hay truy vấn cơ sở dữ liệu ở đó sẽ làm bước phân tích DAG chậm đi.
Ba khái niệm cần phân biệt: DAG, DAG run và task instance
- DAG: bản thiết kế (mã). Chỉ có một.
- DAG run: một lần chạy cụ thể của DAG cho một khoảng thời gian (ví dụ ngày 1/9).
- Task instance: một task trong một DAG run (ví dụ
load_orderscủa ngày 1/9). Mỗi task instance có trạng thái riêng:queued,running,success,failed,up_for_retry,skipped...
Vì vậy "chạy lại ngày 1/9" nghĩa là tạo hoặc xóa trạng thái của các task instance của một DAG run, không phải sửa DAG.
Những hiểu lầm thường gặp
- "Airflow là công cụ xử lý dữ liệu." Airflow điều phối: nó gọi công cụ khác (Python, SQL, Spark, dbt) làm việc nặng, chứ không nên tự xử lý hàng GB trong worker.
- "DAG là chương trình chạy từ trên xuống." DAG chỉ khai báo phụ thuộc; thứ tự thực tế do scheduler tính, và nhiều task chạy song song.
- "Tệp DAG chạy mỗi lần có DAG run." Tệp DAG được đọc lại thường xuyên chỉ để lấy cấu trúc; mã trong task mới chạy khi tới lượt.
- "Airflow thay thế cron vì nó mới hơn." Nó thêm khả năng phụ thuộc, thử lại, lịch sử và chạy lại; với một việc đơn lẻ không cần những điều đó, cron vẫn đủ.
Tự kiểm tra (có đáp án)
Câu 1. Nếu scheduler dừng nhưng các worker vẫn chạy bình thường, điều gì xảy ra? Đáp án: các task đang chạy tiếp tục hoàn thành, nhưng không có DAG run hay task instance mới nào được tạo hoặc đưa vào hàng đợi cho tới khi scheduler chạy lại.
Câu 2. Vì sao không nên gọi API hay truy vấn cơ sở dữ liệu ở cấp cao nhất của tệp DAG? Đáp án: vì scheduler đọc tệp liên tục; mã ở đó chạy mỗi lần đọc, làm scheduler chậm và có thể gây tải lên hệ thống bên ngoài.
Câu 3. "Chạy lại dữ liệu ngày 15/8" tương ứng với đối tượng nào của Airflow? Đáp án: các task instance của DAG run ngày 15/8 (xóa trạng thái hoặc kích hoạt lại), không phải chỉnh sửa DAG.
Nếu chỉ nhớ 3 điều
- DAG là đồ thị task có phụ thuộc, viết bằng Python; Airflow tính thứ tự và chạy song song.
- Scheduler quyết định, worker thực thi, metadata database ghi trạng thái; Airflow điều phối chứ không xử lý dữ liệu nặng.
- Phân biệt DAG (bản thiết kế), DAG run (một lần chạy) và task instance (một task trong một lần chạy).
Nguồn tham khảo
- Architecture Overview, kiểm tra ngày 2026-10-28
- Dags, kiểm tra ngày 2026-10-28
- Tasks, kiểm tra ngày 2026-10-28