Hiểu về Airflow Executor – Các cách thực thi task trong Airflow

Giới thiệu

Điều phối luồng xử lý dữ liệu (data pipeline) quan trọng không kém gì logic tác vụ và hiệu suất của nó. May mắn thay, chúng ta không cần phải làm mọi thứ từ đầu; có rất nhiều công cụ hỗ trợ sẵn có.
Trong số đó, Airflow nổi bật nhờ tính mở và cộng đồng phát triển năng động. Tuy nhiên, với vai trò kỹ sư dữ liệu, chỉ viết file DAG là chưa đủ; chúng ta cần hiểu các khái niệm nền tảng để vận hành công cụ một cách tự tin.
Bài viết này sẽ tìm hiểu sâu về một khía cạnh quan trọng nhất của Airflow: cơ chế thực thi các tác vụ – executor của Airflow.
Trước tiên, chúng ta sẽ điểm lại nhanh về Airflow, rồi tìm hiểu chi tiết về executor cùng các tùy chọn khác nhau của nó.

Lịch sử

Apache Airflow được tạo ra năm 2014 tại Airbnb khi công ty này phải xử lý khối lượng lớn các luồng dữ liệu ngày càng phức tạp. Khi đó, các công cụ điều phối sẵn có quá cứng nhắc, thiếu khả năng mở rộng hoặc không phù hợp với bản chất động của pipeline dữ liệu. Để giải quyết, Maxime Beauchemin – một kỹ sư dữ liệu tại Airbnb – đã dẫn đầu xây dựng Airflow.
Airflow nhanh chóng được đón nhận và năm 2016 gia nhập Quỹ phần mềm Apache, trở thành dự án mã nguồn mở với cộng đồng phát triển mạnh mẽ.
Ngày nay, nếu bạn gia nhập một công ty mới làm dữ liệu, rất có thể sẽ dùng Airflow.

Tổng quan

Điều phối một pipeline dữ liệu đầy đủ có nhiều thách thức:

• Khi nào nên lấy dữ liệu từ API bên thứ ba?
• Quản lý phụ thuộc giữa các bước gọi API và xử lý ra sao?
• Nếu gặp lỗi thì sao? Có thể theo dõi, tự động thử lại không?

Apache Airflow giúp đơn giản hóa vấn đề này bằng cách cho phép kỹ sư định nghĩa luồng công việc bằng code và tự động hóa quá trình thực thi.
Cốt lõi của Airflow dựa vào khái niệm DAG (Đồ thị có hướng không chu trình) để mô hình hóa workflow. DAG là sơ đồ tổng thể của workflow, gồm hai thành phần chính:

• Tasks (Nút): Các đơn vị công việc riêng lẻ như chạy truy vấn, copy dữ liệu, chạy script hoặc gọi API.
• Dependencies (Cạnh): Mối quan hệ phụ thuộc giữa các task, xác định thứ tự thực thi (ví dụ: tiền xử lý chỉ chạy sau khi lấy xong dữ liệu).

Airflow đảm bảo các task được chạy tuần tự/sóng song dựa trên phụ thuộc, tự quản lý thử lại khi lỗi (dựa config) và ghi log chi tiết để tiện theo dõi, debug.

Các thành phần bên trong

• Scheduler: Phụ trách đọc file DAG, lên lịch và đưa task vào hàng đợi dựa vào phụ thuộc & lịch chạy. Logic executor chạy bên trong scheduler.
• Web Server: Giao diện web để trực quan hóa workflow, theo dõi tiến trình, xem log, trigger DAG thủ công.
• Metadata Database: Lưu tất cả metadata: định nghĩa DAG, trạng thái task, log, lịch trình... Đây là trung tâm ghi nhận lịch sử thực thi.
• Thư mục DAG: Chứa các file DAG do người dùng định nghĩa.
• Worker: Thực thi các task mà executor phân công.

Executor là trọng tâm hôm nay, sẽ bàn sâu hơn phía dưới.

Quy trình làm việc giữa các thành phần

1. Định nghĩa DAG: Người dùng định nghĩa DAG với các task, logic, thời điểm bắt đầu và lịch chạy.
2. Phân tích DAG: Scheduler quét thư mục DAG, đọc và nạp file DAG vào Metadata Database.
3. Lên lịch: Dựa vào định nghĩa & lịch chạy, Scheduler xác định task nào sẵn sàng thực thi, đưa vào hàng đợi.
4. Thực thi task: Executor lấy các task đã xếp hàng, gán cho Worker thực hiện. Worker chạy task, trạng thái được cập nhật vào Metadata Database.
5. Theo dõi: Web Server truy vấn Metadata Database, hiển thị trạng thái DAG, task, log theo thời gian thực. Người dùng có thể giám sát, xem log, hoặc kích hoạt chạy DAG thủ công trên giao diện.
6. Thử lại & cập nhật trạng thái: Nếu một task lỗi, Scheduler sẽ quản lý việc thử lại theo cấu hình. Executor cập nhật trạng thái vào Database tới khi hoàn thành hoặc hết số lần thử.

Triển khai

Trên một máy tính

Airflow có thể chạy trên một máy riêng lẻ (“airflow standalone”) phục vụ cho kiểm thử/phát triển. Setup này sẽ khởi động đủ mọi thành phần (scheduler, webserver, database) trên cùng máy, mỗi thành phần là một process khác nhau.
Cách khác là dùng container riêng biệt cho từng process (Docker hoặc Minikube).
Tuy nhiên, cách này không phù hợp môi trường sản xuất đòi hỏi khả năng mở rộng, sẵn sàng cao và chống lỗi.

Triển khai phân tán

Airflow có thể triển khai kiến trúc phân tán, từng thành phần hoạt động độc lập trên các máy khác nhau (và có thể có nhiều instance/ thành phần tương ứng). Cách này hiệu quả hơn cho xử lý workflow quy mô lớn, đặc biệt phổ biến là triển khai trên Kubernetes.
Nếu bạn dùng Airflow do nhà cung cấp đám mây như AWS hoặc Google quản lý, môi trường Airflow được triển khai trên cụm Kubernetes. File DAG lưu trên storage đối tượng (S3 của AWS, GCS của Google).

Executor

Bây giờ là nội dung chính:
Executor quyết định nơi và cách các task được thực thi. Mỗi loại executor có ưu nhược điểm riêng về mở rộng, cách ly và độ phức tạp.

SequentialExecutor

(Loại Executor cục bộ, sẽ được thay LocalExecutor trong Airflow 3)
Chạy tuần tự từng task, sử dụng một process trên cùng máy với scheduler. Chủ yếu dành cho phát triển/ kiểm thử vì đơn giản, không hỗ trợ song song (parallelism) nên không phù hợp sản xuất.
Một đặc điểm cần lưu ý: executor này sẽ tạm dừng scheduler khi một task đang chạy, gây gián đoạn giám sát và xếp hàng task mới.
SequentialExecutor cũng là executor duy nhất tương thích với SQLite làm backend database.

Ưu điểm:

• Đơn giản, không phụ thuộc bên ngoài hoặc cấu hình phức tạp.

Nhược điểm:

• Không hỗ trợ song song.

LocalExecutor

(Loại Executor cục bộ)
Nâng cấp từ SequentialExecutor nhờ hỗ trợ song song trên một máy bằng nhiều process. Phù hợp workflow nhỏ/ trung bình, cần concurrency nhưng không cần phân tán. Để hỗ trợ song song, một backend database mạnh (MySQL/PostgreSQL) là bắt buộc. SQLite không dùng được.

Có hai chế độ:

• Song song không giới hạn (parallelism == 0): tạo process mới cho mỗi task; task xong thì process kết thúc.
• Song song giới hạn (parallelism > 0): thường dùng cho sản xuất. Số process cố định, chạy thường trực, liên tục xử lý task từ hàng đợi.

Ưu điểm:

• Đơn giản
• Sử dụng tối đa tài nguyên CPU máy chủ để tăng concurrency

Nhược điểm:

• Bị giới hạn bởi tài nguyên của máy scheduler. Muốn tăng sức mạnh -> thêm nhiều máy scheduler.

CeleryExecutor

(Loại Executor phân tán)
CeleryExecutor cho phép xây dựng hệ thống phân tán và mở rộng ngang. Tác vụ chạy tách biệt với scheduler trên các worker dùng Celery queue.
Cấu hình cần:

• Message broker (thường dùng RabbitMQ/Redis)
• Celery worker

Worker là các process chạy thường trực, nhận và thực hiện task khi được giao. Muốn mở rộng khả năng xử lý, chỉ cần tăng số lượng máy chạy worker. Yêu cầu database mạnh tương tự LocalExecutor.

Ưu điểm:

• Phân tách việc chạy task khỏi Scheduler.
• Dễ dàng mở rộng bằng việc thêm worker.

Nhược điểm:

• Cần nhiều thành phần hơn -> tốn công quản lý.
• "Noisy neighbor": task nặng có thể ảnh hưởng các task khác cùng máy worker.
• Sử dụng tài nguyên chưa tối ưu nếu worker phải chạy liên tục ngay cả khi task ít.
• Có độ trễ mở rộng do cần setup thêm worker.

KubernetesExecutor

(Loại Executor container hóa)
Dành cho môi trường đám mây/ container hóa. Executor này sẽ tạo pod Kubernetes riêng biệt cho mỗi task. Đây là lựa chọn tối ưu về cách ly, mở rộng và chịu lỗi.
Scheduler sẽ gọi Kubernetes API yêu cầu tạo pod khi có task sẵn sàng. Pod thực thi task, báo kết quả về metadata database rồi tự kết thúc (có thể cấu hình giữ lại pod để debug).

Ưu điểm:

• Tối ưu tài nguyên: chỉ tiêu tốn khi task thực thi, tiết kiệm khi nhàn rỗi.
• Cách ly cao: mỗi task là một pod riêng, tùy ý cấu hình tài nguyên, phụ thuộc Python...
• Phù hợp đa dạng workload.

Nhược điểm:

• "Cold start": cần thời gian khởi tạo pod, kéo image mới chạy được task.
• Đòi hỏi kiến thức sâu về container, Kubernetes, có thể phải đầu tư đội ngũ SRE.
• Khó thử nghiệm vì cần môi trường Kubernetes.

Multiple Executors

Từ Airflow 2.10 trở đi, có thể dùng nhiều executor trong cùng một môi trường. Thông thường một executor là đủ, nhưng với những workload đa dạng, nhiều executor đem lại sự linh hoạt hơn. Ví dụ:

• Task nhỏ, số lượng nhiều: Dùng CeleryExecutor với worker luôn bật sẵn để giảm độ trễ bắt đầu task.
• Task dài, nặng tài nguyên: Dùng KubernetesExecutor để mỗi task có pod cách ly, tùy chọn tài nguyên.

Kết

Bài viết đã điểm lại các kiến thức nền tảng về Airflow và các loại executor phổ biến, từ cục bộ đơn giản (Sequential/LocalExecutor), cho đến giải pháp phân tán (CeleryExecutor) và hiện đại hóa cách ly tối đa (KubernetesExecutor).
Tuy nhiên, càng mạnh thì càng yêu cầu kiến thức vận hành (đặc biệt với KubernetesExecutor).
Bạn cũng biết rằng Airflow đã hỗ trợ nhiều executor cùng lúc trong một môi trường.
Cảm ơn bạn đã đọc đến đây. Hẹn gặp lại ở các bài viết sau.

Tài liệu tham khảo

• Apache Airflow Official Documentation
• Airbnb Engineer, Airflow: a workflow management platform (2015)