# Airflow, Prefect hay Luigi: hãy chọn công cụ mà đội vận hành của khách đủ sức duy trì

> Chọn orchestrator thật ra là quyết định xem đội của khách phải vận hành những gì sau khi FDE rời đi, chứ không phải đi tìm công cụ nhiều tính năng nhất.

Bản gốc: https://fdetimes.net/vi/cong-cu/airflow-prefect-luigi-chon-orchestrator/

Ngay trong tài liệu của mình, Luigi viết thẳng rằng nó không có sẵn cơ chế kích hoạt. Muốn pipeline chạy hằng đêm thì bạn phải tự gắn cron hoặc một công cụ tương tự.

Mỗi lần FDE dựng pipeline dữ liệu ở chỗ khách, sẽ đến lúc phải chọn orchestrator. Nhiều kỹ sư chọn công cụ mình quen tay nhất. Cách đó bỏ sót một chuyện: bạn ở lại vài tuần, còn đội vận hành của khách sẽ sống chung với hệ thống ấy nhiều năm.

Vì vậy câu hỏi nên đặt ra là đội của khách có giữ cho công cụ này chạy ổn được không, chứ không phải công cụ nào mạnh nhất. Cả ba lựa chọn phổ biến đều là job scheduler theo nghĩa Wikipedia mô tả: phần mềm điều khiển các job chạy nền mà không cần người ngồi trông.

Điểm khác nhau nằm ở cái giá vận hành mà mỗi công cụ để lại cho khách.

## Airflow mạnh, nhưng khách phải gánh cả một hệ thống

Trang chủ Airflow giới thiệu đây là nền tảng do cộng đồng xây dựng để viết, lập lịch và giám sát workflow bằng code. Pipeline được định nghĩa bằng Python nên có thể sinh pipeline động. Airflow có kiến trúc module hóa và dùng message queue để điều phối số lượng worker tùy ý, tức là có đường để mở rộng khi tải tăng.

Cái giá phải trả nằm trong tài liệu kiến trúc. Một bản cài Airflow gồm scheduler (vừa kích hoạt workflow theo lịch vừa đẩy task sang executor), một metadata database thường là PostgreSQL hoặc MySQL để lưu trạng thái task, DAG và biến, một API server, cùng các worker tùy chọn. Mỗi thành phần đều cần người theo dõi, nâng cấp và sao lưu.

Nếu khách đã có đội platform quen vận hành PostgreSQL và hàng trăm pipeline, Airflow là lựa chọn hợp lý. Còn nếu bên vận hành chỉ có hai người kiêm nhiệm thì phải tính kỹ. Hãy hỏi ngay từ đầu: khi metadata database đầy ổ đĩa lúc 2 giờ sáng, ai sẽ là người xử lý?

## Prefect: viết bằng Python thuần, worker chạy ngay trong hạ tầng của khách

Prefect tự mô tả là engine điều phối mã nguồn mở, biến các hàm Python thành pipeline dữ liệu đạt chuẩn production. Tài liệu nhấn mạnh workflow viết bằng Python thuần, không cần DSL, YAML hay cú pháp riêng. Với đội khách vốn đã viết script Python, rào cản học gần như chỉ còn ở phần khái niệm.

Với FDE, Prefect có thêm hai điểm cần biết. Flow có thể được kích hoạt theo lịch, theo sự kiện bên ngoài hoặc qua API. Ngoài ra, ở mô hình hybrid, worker nằm trong hạ tầng của khách và gửi các lần chạy vào chính hạ tầng đó.

Đây là điểm cần đem ra trao đổi khi khách là ngân hàng hay bệnh viện, nơi dữ liệu không được rời khỏi hệ thống nội bộ. Nhưng worker chỉ là một phần: trước khi hứa với khách rằng Prefect nhẹ hơn Airflow, hãy liệt kê đủ những thành phần còn lại mà bản triển khai cụ thể cần chạy thường trực.

## Luigi tự nói rõ giới hạn của mình

Luigi là package Python, được kiểm thử trên các bản 3.10 đến 3.13, giúp xây các pipeline batch job phức tạp. Tài liệu ghi thẳng ba giới hạn: không có trigger sẵn, tập trung vào batch nên ít hữu ích cho pipeline gần real-time hay tiến trình chạy liên tục, và không được thiết kế để vượt quá vài chục nghìn job.

Một công cụ nói rõ giới hạn như vậy giúp FDE dễ loại trừ. Nếu bài toán của khách nằm gọn trong các giới hạn đó, Luigi đáng được đưa vào danh sách ứng viên.

Bước tiếp theo là đếm những gì một bản cài Luigi cộng cron cần chạy ở môi trường của khách, rồi đặt cạnh danh sách thành phần của Airflow, thay vì mặc định rằng nó nhẹ hơn.

## Thử áp vào một khách hàng cụ thể

Thử hình dung một chuỗi bán lẻ có 40 job batch chạy mỗi đêm để tổng hợp doanh số và tồn kho. Đội vận hành có hai người, và dữ liệu không được rời khỏi data center của công ty. Ta đi qua lần lượt năm câu hỏi trong sơ đồ.

Câu hỏi về kích hoạt: chỉ cần lịch hằng đêm, nên cron cộng Luigi đã đáp ứng. Câu hỏi về kiểu xử lý: thuần batch, vẫn trong vùng Luigi làm tốt. Câu hỏi về quy mô: 40 job còn rất xa mức vài chục nghìn.

Câu hỏi về năng lực vận hành là chỗ phải cẩn thận nhất. Với Airflow, danh sách đã rõ: metadata database, scheduler, API server và worker, hai người phải trông hết. Với Luigi và Prefect, bạn cần tự đếm thành phần thường trực của bản cài cụ thể rồi mới so sánh được.

Câu hỏi về dữ liệu nội bộ là ràng buộc cứng, cần giữ lại để soi tiếp mỗi khi yêu cầu thay đổi.

Sau đó khách nói thêm rằng quý sau họ muốn pipeline tự chạy ngay khi file từ nhà cung cấp đổ về. Đây là kích hoạt theo sự kiện bên ngoài, thứ Luigi không có sẵn còn Prefect thì hỗ trợ. Quay lại câu hỏi về dữ liệu nội bộ, worker hybrid của Prefect nằm ngay trong hạ tầng của khách, nên Prefect trở thành ứng viên đáng thử trước.

Airflow vẫn phải trả lời câu hỏi về năng lực vận hành: hai người có đủ sức trông bốn thành phần kia hay không. Câu trả lời đến từ việc ngồi cùng đội của khách, không đến từ trang so sánh tính năng.

**Điểm mấu chốt:** Hãy chọn orchestrator theo yêu cầu kích hoạt sáu tháng tới và theo số người sẽ trực khi hệ thống gặp sự cố, đừng chọn theo danh sách tính năng.

## Ba lỗi hay gặp khi chọn orchestrator

Lỗi đầu tiên là chọn theo thói quen của chính mình. Công cụ bạn quen tay chưa chắc là công cụ đội của khách trực được lúc nửa đêm.

Lỗi thứ hai là quên đọc phần giới hạn. Chọn Luigi rồi mới phát hiện nó không có trigger sẵn, hoặc đem nó vào một pipeline gần real-time trong khi tài liệu đã cảnh báo, là cái giá đắt cho một trang tài liệu bị bỏ qua.

Lỗi thứ ba là so sánh lệch: đếm kỹ thành phần của một công cụ nhưng bỏ qua phần tương ứng của công cụ kia. Cách khắc phục đơn giản là lập một bảng liệt kê mọi tiến trình phải chạy thường trực cho từng ứng viên trước khi kết luận.

## Nên học gì trước

Nếu chỉ có thời gian học sâu một công cụ, hãy bắt đầu từ Airflow, vì tài liệu kiến trúc của nó gọi tên rõ từng thành phần: scheduler, executor, metadata database, worker. Khi đã hình dung được các phần đó, bạn sẽ dễ nhận ra công cụ khác giao phần nào cho người dùng tự lo, chẳng hạn Luigi để chuyện kích hoạt cho cron.

Khi đọc JD của các vị trí FDE hay data engineer hướng khách hàng, hãy để ý xem họ chỉ ghi "Airflow" hay ghi "orchestration". Có thể đoán rằng chữ thứ hai mở ra khả năng họ cần người biết chọn công cụ chứ không chỉ người biết dùng, nhưng đó chỉ là suy đoán, nên hãy hỏi thẳng trong buổi phỏng vấn.

Trong CV, thay vì liệt kê tên công cụ, hãy viết một câu theo kiểu: chọn Prefect thay cho Airflow vì khách cần kích hoạt theo sự kiện và dữ liệu phải ở lại nội bộ.

Khi bạn đã rời dự án, đội của khách sẽ không nhớ bạn chọn công cụ nào. Họ chỉ nhớ hệ thống đó có làm họ phải thức dậy lúc 2 giờ sáng hay không.

**Thử ngay tuần này:**

- Viết cùng một pipeline gồm ba bước (lấy dữ liệu, biến đổi, ghi kết quả) bằng cả Airflow, Prefect và Luigi, rồi đếm xem mỗi công cụ cần bao nhiêu thành phần đang chạy
- Với Luigi, tự cấu hình cron để chạy pipeline hằng đêm, cho quen với việc công cụ này không có trigger sẵn
- Viết một đoạn ghi chú quyết định dài nửa trang cho một khách hàng giả định, theo năm câu hỏi trong bài

## Nguồn

- [Apache Airflow®](https://airflow.apache.org/)

- [Architecture Overview](https://airflow.apache.org/docs/apache-airflow/stable/core-concepts/overview.html)

- [Introduction (Prefect Docs)](https://docs.prefect.io/v3/get-started)

- [Work pools (Prefect Docs)](https://docs.prefect.io/v3/concepts/work-pools)

- [Getting Started — Luigi documentation](https://luigi.readthedocs.io/)

- [Design and limitations — Luigi documentation](https://luigi.readthedocs.io/en/stable/design_and_limitations.html)

- [Job scheduler](https://en.wikipedia.org/wiki/Job_scheduler)