Giải thích Apache Airflow: Hướng dẫn thân thiện cho người mới bắt đầu

Giới thiệu

Các công ty hiện đại dựa trên dữ liệu đều phụ thuộc vào các dòng dữ liệu (data pipeline) để truy xuất, chuyển đổi, làm giàu và di chuyển thông tin từ nơi này sang nơi khác. Các dòng dữ liệu này có thể bao gồm nhiều bước (trích xuất dữ liệu thô, làm sạch dữ liệu, huấn luyện các mô hình học máy, xây dựng bảng điều khiển, v.v.). Ngoài ra, chúng phải chạy theo một thứ tự rất cụ thể. Các công cụ điều phối luồng công việc như Apache Airflow giúp đảm bảo tất cả các bước này chạy đúng thời điểm và theo đúng thứ tự. Chúng cũng giúp việc giám sát và quản lý các dòng dữ liệu trở nên dễ dàng hơn.

Airflow được phát triển tại Airbnb vào năm 2014 và đã trở thành một trong những nền tảng điều phối luồng công việc mã nguồn mở phổ biến nhất. Nó được sử dụng bởi hàng nghìn tổ chức để tự động hóa và giám sát các pipeline theo lô. Trong bài viết này, chúng tôi sẽ giải thích Apache Airflow từ cơ bản. Các chủ đề chúng tôi sẽ đề cập bao gồm:

• Airflow là gì, nó làm gì và tại sao các nhóm dữ liệu sử dụng nó.
• Các khái niệm và thành phần cốt lõi của Airflow, và cách chúng kết hợp với nhau.
• Cách các pipeline được định nghĩa dưới dạng Đồ thị Mũi tên Vô hướng (DAG) và hướng dẫn sử dụng một DAG đơn giản trong thực tế.
• Các trường hợp sử dụng phổ biến như ETL/ELT, MLOps và hơn thế nữa.

Chúng tôi hy vọng đây sẽ là một hướng dẫn thực tiễn, dựa trên các ví dụ về Apache Airflow dành cho các kỹ sư, sinh viên và các nhóm đang bắt đầu với việc điều phối quy trình làm việc.

Điểm chính

• Apache Airflow là một nền tảng điều phối luồng công việc dựa trên Python giúp quản lý, lên lịch và giám sát các pipeline dữ liệu phức tạp bằng cách sử dụng DAG (Biểu đồ vòng có hướng bất tuần hoàn).
• DAGs xác định các tác vụ và mối quan hệ phụ thuộc của chúng, cho phép Airflow thực hiện từng bước theo đúng thứ tự với khả năng thử lại, ghi nhật ký và quan sát tích hợp sẵn.
• Kiến trúc của Airflow (Scheduler, Executor, Worker, Metadata DB, Web UI) cho phép thực thi có khả năng mở rộng, phân tán và giám sát thời gian thực các pipeline.
• Airflow nổi trội trong các quy trình làm việc theo lô như các công việc ETL/ELT, pipeline huấn luyện ML, kiểm tra chất lượng dữ liệu và phân tích theo lịch trình — nhưng không lý tưởng cho các khối lượng công việc thời gian thực hoặc tần suất cực cao.
• Các lựa chọn thay thế như Prefect, Dagster, Luigi, Argo Workflows và Mage AI có thể phù hợp hơn tùy thuộc vào các nhu cầu như luồng công việc dựa trên sự kiện, thực thi trên Kubernetes, hoặc giao diện thân thiện với nhà phát triển hiện đại.

Apache Airflow là gì?

Apache Airflow là một hệ thống mã nguồn mở dùng để tạo, lập lịch và giám sát các quy trình công việc. Một quy trình công việc trong Airflow là một DAG (đồ thị có hướng vô chu kỳ), là một chuỗi các tác vụ với các mối quan hệ (sự phụ thuộc) được xác định rõ ràng và không có vòng lặp (một tác vụ không thể lặp lại chính nó ở trên). Triết lý cốt lõi của Airflow là "cấu hình như mã", vì vậy thay vì sử dụng giao diện kéo-thả, bạn viết các script bằng Python để biểu diễn các quy trình công việc. Cách tiếp cận này mang lại sự linh hoạt đáng kể cho các kỹ sư: bạn có thể kết nối với hầu hết mọi công nghệ thông qua các operator của Airflow và các thư viện Python. Bạn cũng có thể áp dụng các thực hành tốt nhất trong kỹ thuật phần mềm (quản lý phiên bản, kiểm thử, v.v.) cho các định nghĩa pipeline của mình.

Tại sao việc điều phối quy trình làm việc lại quan trọng?

Điểm chính là thường thì bạn có nhiều bước trong bất kỳ quy trình dữ liệu nào phải được thực hiện theo trình tự. Một ví dụ đơn giản là pipeline ETL (Trích xuất/Chuyển đổi/Tải dữ liệu). Các pipeline có thể nhanh chóng trở nên phức tạp hơn khi bạn thêm nhiều tác vụ, sự phụ thuộc, phân nhánh, v.v., và cũng cần chạy theo chu kỳ đều đặn. Việc can thiệp thủ công hoặc các công cụ lập lịch đơn giản thường trở nên không đủ trong những trường hợp này. Airflow giải quyết vấn đề này bằng cách đóng vai trò là bộ điều phối trung tâm. Nó có một đồ thị có hướng vô chu trình (DAG) của các tác vụ (node) với các sự phụ thuộc (cạnh). Nó biết khi nào thực hiện tác vụ nào (chờ các sự phụ thuộc phía trên hoàn thành trước khi chạy), bao gồm việc lập lịch (thực hiện theo khoảng thời gian định kỳ), xử lý lỗi (tự động thử lại, cảnh báo), và ghi nhật ký.

Nếu chúng ta coi toàn bộ quy trình dữ liệu như một công thức nấu ăn, thì mỗi nhiệm vụ riêng lẻ chính là một bước phụ (thái, luộc, trình bày, v.v.). Airflow giống như người quản lý bếp, người biết các công thức và theo dõi tất cả các bước phụ khác nhau đang diễn ra trong mỗi bếp, đảm bảo mọi thứ diễn ra theo đúng thứ tự và đúng thời điểm.

Nếu không có sự điều phối quy trình làm việc, bạn có thể có tất cả các đầu bếp và nguyên liệu, nhưng chúng sẽ không được phối hợp. Airflow cung cấp sự phối hợp đó, cho phép sản xuất ra "món ăn" mong muốn (chạy quy trình làm việc).

Tại sao các nhóm dữ liệu sử dụng Airflow?

Airflow đã trở nên phổ biến trong số các kỹ sư dữ liệu, kỹ sư ML và các nhóm DevOps vì nó đáp ứng nhiều nhu cầu của các pipeline dữ liệu phức tạp. Dưới đây là một vài lý do lớn khiến các nhóm chọn Airflow:

• Điều phối Các Quy trình Làm việc & Phụ thuộc Phức tạp: Airflow được thiết kế cho các quy trình làm việc với nhiều bước phụ thuộc lẫn nhau. Airflow giúp dễ dàng khai báo các yêu cầu tiến lên và xuống, đảm bảo các tác vụ thực thi theo đúng thứ tự. Nếu tác vụ C phụ thuộc vào các tác vụ A và B, bộ lập lịch Airflow sẽ nhận biết các mối quan hệ này và đảm bảo rằng A và B chạy (có thể song song) trước khi chạy C. Airflow có thể xử lý các phụ thuộc phức tạp, logic phân nhánh, v.v.
• Lập lịch tập trung (Cron nâng cấp): Nó cung cấp một trình lập lịch cho phép bạn thực thi các tác vụ theo một lịch trình nhất định. Bạn có thể định nghĩa hàng chục hoặc hàng trăm pipeline để kích hoạt các tác vụ vào những thời điểm khác nhau (theo giờ, theo ngày, theo tháng) bằng trình lập lịch của Airflow. Airflow hiểu các mối quan hệ giữa các tác vụ. Nó có thể lập lịch một cách thông minh và kích hoạt các tác vụ để chạy. Trình lập lịch trung tâm giúp bạn không phải viết các script khác nhau trên các máy chủ khác nhau.

• Khả năng mở rộng và Thực thi phân tán: Airflow cũng có thể mở rộng theo các workflow của bạn. Nó có thể được cấu hình để thực thi các tác vụ song song trên nhiều tiến trình hoặc máy chủ. Nó cũng cung cấp nhiều executor (sẽ được thảo luận sau trong bài viết này) có thể chạy các tác vụ trên các hệ thống phân tán như Celery hoặc Kubernetes trên một cụm các nút. Điều này có nghĩa là bạn có thể thực hiện song song các tác vụ nặng (xử lý dữ liệu lớn) và có nhiều pipeline chạy đồng thời.
• Giám sát, Ghi nhật ký và Cảnh báo: Nó đi kèm với một giao diện web phong phú cung cấp khả năng hiển thị thời gian thực vào các luồng công việc của bạn. Bạn có thể thấy các tác vụ nào đã thành công và tác vụ nào đã thất bại, cũng như xem nhật ký đầu ra cho từng tác vụ. Bạn thậm chí có thể kích hoạt và/hoặc thử lại các tác vụ thông qua giao diện web.

Các Thành Phần Chính của Airflow

Dưới đây là tổng quan ngắn gọn về các thành phần chính của Apache Airflow. Sử dụng bảng này như một tài liệu tham khảo nhanh để hiểu mỗi thành phần là gì và chức năng của chúng.

Cách Hoạt Động của Airflow (Kiến Trúc)

Dưới đây là tổng quan từng bước về cách Airflow xử lý một luồng công việc (DAG):

• Soạn thảo DAG: Tác giả DAG viết một tập lệnh Python định nghĩa một DAG. Tập lệnh này bao gồm các thông tin như lịch trình (ví dụ: “chạy hàng ngày lúc 9 giờ sáng”) hoặc các thiết lập kích hoạt thủ công. Nó cũng chứa định nghĩa của các tác vụ (thông qua các toán tử hoặc hàm @task), cũng như các phụ thuộc giữa các tác vụ (ví dụ: task1 >> task2 (task2 chờ task1 hoàn thành)). Tệp Python này được lưu trong thư mục DAGs của Airflow để Airflow có thể tìm thấy. Airflow sẽ đọc (phân tích) tệp này định kỳ để tải định nghĩa DAG.
• Lập lịch và Phân tích DAG: Airflow Scheduler là một tiến trình chạy liên tục trong nền. Nó kiểm tra xem mỗi DAG có nên được thực hiện dựa trên lịch trình hoặc các kích hoạt của nó hay không. Ví dụ, một DAG với lịch trình “hàng ngày” có thể được scheduler chọn, và nhận thấy rằng một lần chạy mới phải được lên lịch vào nửa đêm. Airflow Scheduler cũng kiểm tra xem các tác vụ trong DAG đã sẵn sàng để chạy chưa – nghĩa là tất cả các phụ thuộc trước của chúng đã hoàn thành và thời gian được lên lịch (ngày logic) đã đến.
• Thực thi các tác vụ: Mỗi tác vụ cần được thực thi sẽ được Scheduler chuyển giao cho Executor. Executor sẽ quyết định nơi và cách thực hiện tác vụ. Nó có thể được thực hiện tại chỗ hoặc gửi đến hàng đợi công việc. Đối với kiến trúc phân tán, tác vụ sẽ được thêm vào hàng đợi và sau đó được các tiến trình Worker chọn và thực thi.
• Cập nhật trạng thái & Xử lý lỗi: Mỗi phiên bản tác vụ báo cáo trạng thái của nó (thành công, thất bại, v.v.) về bộ lập lịch khi hoàn thành, và bộ lập lịch cập nhật cơ sở dữ liệu metadata của nó với trạng thái của tác vụ.
  Việc theo dõi trạng thái là điều cho phép bộ lập lịch biết phải làm gì tiếp theo – ví dụ, nếu Task A đã hoàn thành thành công, nó biết rằng có thể lập lịch Task B ngay bây giờ, hoặc nếu Task A thất bại nhưng còn lượt thử lại, nó sẽ lập lịch thử lại, hoặc nếu thất bại mà không còn lượt thử lại, nó đánh dấu chạy DAG là thất bại. Nếu một tác vụ thất bại, Airflow có logic để tự động thử lại tác vụ nếu được cấu hình cho thử lại. Nếu nó tiếp tục thất bại sau các lượt thử lại, Airflow có thể cảnh báo về thất bại (gửi email hoặc tin nhắn Slack, v.v.). Tất cả những điều này đều có thể cấu hình như một phần của tham số DAG hoặc tác vụ (ví dụ, số lần thử lại, thời gian chờ giữa các lần thử, email nhận thông báo cảnh báo).
• Giám sát và Can thiệp: Giao diện Web Airflow cung cấp một giao diện trực tiếp của quá trình trên. Bạn có thể thấy một lần chạy DAG xuất hiện (ví dụ, một dòng mới trong chế độ xem Cây cho lần chạy hôm nay), và theo dõi trạng thái các tác vụ thay đổi khi chúng tiến triển. Chế độ xem Đồ thị trực quan hóa các tác vụ của DAG và hiển thị tác vụ nào đã hoàn thành hoặc gặp lỗi.
• Dọn dẹp và Chạy tiếp theo: Khi một lần chạy DAG hoàn tất (tất cả các tác vụ đã thành công hoặc bị bỏ qua/thất bại), Airflow sẽ tiến hành lần chạy theo lịch tiếp theo. Tất cả dữ liệu về các lần chạy trước vẫn được lưu trong cơ sở dữ liệu, và bạn luôn có thể kiểm tra lịch sử. Bộ lập lịch sẽ tiếp tục kích hoạt các lần chạy mới theo lịch hoặc khi được kích hoạt thủ công. Quá trình này sẽ được lặp lại cho đến khi tiến trình Airflow bị dừng.

Hiểu về DAG trong Airflow

Một DAG trong Airflow xác định lịch trình, các tác vụ và các phụ thuộc cần thiết để thực thi một quy trình công việc. Một DAG không cần phải biết bên trong mỗi tác vụ có gì; nó chỉ cần xác định khi nào và theo thứ tự nào các tác vụ đó nên chạy.

Nhiệm vụ, bộ điều khiển và cảm biến

Các tác vụ là đơn vị cơ bản của công việc trong Airflow. Trong Airflow, các tác vụ là các thể hiện của các operator, là các mẫu cho các hành động được định nghĩa trước. Airflow đi kèm với nhiều operator cốt lõi khác nhau. BashOperator cho phép bạn chạy các lệnh shell, còn PythonOperator cho phép bạn gọi các hàm Python. Airflow cũng cung cấp một decorator @task, cho phép bạn biến một hàm Python thông thường thành một tác vụ.

Ngoài các toán tử, Airflow còn cung cấp các cảm biến. Cảm biến là các tác vụ chờ một điều kiện hoặc sự kiện được đáp ứng trước khi chúng thành công. Chúng có thể được sử dụng cho các việc như chờ một tệp xuất hiện hoặc một bảng được điền dữ liệu.

Phụ thuộc công việc

Để khai báo các phụ thuộc giữa các tác vụ, bạn sử dụng các toán tử >> và << (được khuyến nghị) hoặc các phương thức như set_upstream và set_downstream. Ngoài ra, cũng có thể liên kết các tác vụ, tạo các phụ thuộc chéo xuống, và thậm chí xây dựng động danh sách các tác vụ. Một DAG không có bất kỳ phụ thuộc nào sẽ chỉ là một tập hợp các tác vụ độc lập.

Thực hành tốt nhất cho thiết kế DAG

Bảng dưới đây đưa ra một số hướng dẫn cần lưu ý khi thiết kế DAG.

Ví dụ: Một DAG Airflow đơn giản

Không gì giúp củng cố các khái niệm tốt hơn một ví dụ. Hãy cùng xem qua một đoạn mã DAG đơn giản trong Airflow và giải thích các phần của nó. Ví dụ này sẽ tạo một quy trình làm việc nhỏ với hai nhiệm vụ theo tuần tự:

from datetime import datetime
from airflow import DAG
from airflow.operators.bash import BashOperator

# Define the DAG and its schedule
with DAG(
    dag_id="example_dag",
    description="A simple example DAG",
    start_date=datetime(2025, 1, 1),
    schedule_interval="@daily",  # runs daily
    catchup=False
) as dag:
    # Task 1: Print current date
    task1 = BashOperator(
        task_id="print_date",
        bash_command="date"
    )
    # Task 2: Echo a message
    task2 = BashOperator(
        task_id="echo_hello",
        bash_command="echo 'Hello, Airflow!'"
    )
    # Define dependency: task1 must run before task2
    task1 >> task2

Hãy phân tích những gì đang xảy ra ở đây:

• nhập các lớp cần thiết DAG (để định nghĩa DAG), và BashOperator (để chạy các lệnh shell/bash trong các tác vụ). Chúng ta cũng nhập datetime để chỉ định ngày bắt đầu của DAG.
• Chúng tôi tạo một đối tượng DAG với trình quản lý ngữ cảnh (with DAG(…) as dag:). Cung cấp cho DAG một ID duy nhất “example_dag” (phải là duy nhất trong một môi trường Airflow), một mô tả (tùy chọn, để giúp con người đọc), một start_date, và một schedule_interval. Ở đây, chúng tôi đặt một schedule_interval preset (@daily) có sẵn, và start_date=datetime(2025,1,1). Chúng tôi cũng đã đặt catchup=False để ngăn việc lấp đầy các lần chạy bị bỏ lỡ giữa start_date và hôm nay (chúng tôi chỉ muốn nó chạy từ bây giờ trở đi hàng ngày). Toàn bộ khối này tạo ra một DAG mà Airflow sẽ nhận biết để chạy hàng ngày vào đầu ngày.
• Chúng ta sau đó định nghĩa hai tác vụ trong bối cảnh DAG:
• task1 được định nghĩa bằng cách sử dụng BashOperator để thực thi một lệnh bash (date). task_id là “print_date” và sẽ được sử dụng để nhận diện task này trong giao diện người dùng và trong nhật ký. Khi chạy, task này sẽ chỉ đơn giản in ngày/giờ hiện tại (vào nhật ký của task).
• task2 cũng sử dụng BashOperator với task_id=“echo_hello”, và command=echo ‘Hello, Airflow!’. Điều này sẽ in ra một thông điệp đẹp. Những tác vụ này hiện tại chỉ mới được định nghĩa, chưa được liên kết.
• Dòng cuối cùng (task1 >> task2) chỉ định một phụ thuộc (luồng): task1 chảy vào task2. Điều này có nghĩa là task 1 sẽ chạy và hoàn thành thành công trước khi task 2 có thể được xem xét để lập lịch chạy. Về mặt đồ họa, trong đồ thị DAG, sẽ có một mũi tên chỉ từ task1 đến task2.

Một vài điều cần lưu ý trong ví dụ này:

• Chúng tôi chỉ sử dụng BashOperator cho đơn giản, nhưng chúng tôi có thể đã sử dụng một DAG với các loại operator khác nhau. Chúng tôi có thể có một PythonOperator để gọi một hàm Python, hoặc một SimpleHttpOperator để truy cập API, v.v.
• Cú pháp with DAG(…) as dag: là một cách diễn đạt phổ biến để tạo một thể hiện DAG. Tất cả các tác vụ được tạo bên trong nó sẽ tự động được liên kết với DAG đó.
• catchup=False là một tham số được sử dụng trong nhiều DAG với start_date ở quá khứ, khi bạn không muốn nó chạy cho tất cả các ngày trước đó. Nếu chúng ta để catchup=True (mặc định) và hôm nay là ngày 10 tháng 1 năm 2025, Airflow sẽ cố gắng chạy DAG cho các ngày 1, 2, 3, … cho đến ngày 10 tháng 1, bù đắp cho những ngày đã bỏ lỡ trong backlog. Chúng tôi tắt nó ở đây để đơn giản.
• Ví dụ này sử dụng đường dẫn nhập tương đối cho BashOperator. Trong Airflow 2, nhiều operator đã được di chuyển dưới airflow.providers. Ví dụ này được viết với giả định rằng những provider đó đã được cài đặt (BashOperator nằm trong lõi của Airflow).

Ví dụ đơn giản này có thể dễ dàng mở rộng – bạn có thể thêm các nhiệm vụ bổ sung (có thể thực hiện một cuộc gọi API, sau đó tải kết quả vào cơ sở dữ liệu, rồi gửi thông báo). Bạn cũng có thể thêm logic phức tạp hơn (như phân nhánh – Airflow hỗ trợ phân nhánh kiểu if/else bằng cách sử dụng BranchOperator, ví dụ).

Khi các DAG của bạn trở nên lớn hơn, giao diện người dùng và nhật ký của Airflow trở nên vô giá trong việc tìm hiểu những gì đang diễn ra. Trong ví dụ này, nhật ký cho print_date sẽ chứa ngày hệ thống đã được in, và nhật ký cho echo_hello sẽ chứa “Hello, Airflow!”. Nếu print_date thất bại (có thể nó không tìm thấy lệnh date, trong một kịch bản giả định), thì echo_hello sẽ không bao giờ được thực thi (do phụ thuộc), và phiên chạy DAG sẽ được đánh dấu là thất bại. Bạn có thể kiểm tra nhật ký, khắc phục sự cố và chạy lại nhiệm vụ đó hoặc toàn bộ DAG.

Các Trường Hợp Sử Dụng Thông Thường cho Airflow

Dưới đây là bản tóm tắt có cấu trúc về các trường hợp sử dụng phổ biến của Apache Airflow. Bảng này nêu rõ từng trường hợp sử dụng bao gồm những gì và Airflow mang lại giá trị như thế nào trong bối cảnh đó.

Khi KHÔNG nên sử dụng Airflow

Mặc dù Airflow rất mạnh mẽ, nhưng nó không phải là công cụ phù hợp cho mọi tình huống. Hiểu được những hạn chế của nó giúp bạn chọn được phương pháp điều phối phù hợp:

• Khối lượng công việc theo thời gian thực hoặc phát trực tiếp: Airflow hướng tới xử lý theo lô với điểm bắt đầu và kết thúc rõ ràng. Nó không phù hợp cho các khối lượng công việc chạy lâu, kích hoạt theo sự kiện hoặc phát trực tiếp. Nếu bạn đang nhập một luồng sự kiện liên tục (như nhấp chuột của người dùng, cảm biến IoT, v.v.) và cần xử lý chúng với độ trễ rất thấp trong thời gian thực, Airflow không phải là lựa chọn tốt nhất.
• Các nhiệm vụ tần suất cao hoặc nhiều nhiệm vụ ngắn: Đây là một trường hợp khác mà Airflow có thể không hoạt động, hoặc ít nhất là không hiệu quả. Các nhiệm vụ của Airflow có một số chi phí phụ (như theo dõi trong cơ sở dữ liệu, v.v.), vì vậy nếu bạn cần kích hoạt một tác vụ mỗi vài giây hoặc có hàng nghìn tác vụ nhỏ, Airflow có thể không mở rộng tốt.
• Luồng công việc hoàn toàn dựa trên sự kiện: Điều này tương tự như trường hợp sử dụng streaming, nhưng dành cho những việc cần được kích hoạt bởi một sự kiện. “Bất cứ khi nào sự kiện X xảy ra, thực hiện Y” là một trường hợp sử dụng hoàn toàn hợp lệ cho Airflow, nhưng nếu điều duy nhất kích hoạt việc này là một sự kiện (ví dụ: “bất cứ khi nào một tệp đến trong một bucket S3, thực hiện X”), thì Airflow không phải là giải pháp nhẹ nhất ở đây. Airflow thường sử dụng các cảm biến (ví dụ S3KeySensor) để “nhận biết” sự tồn tại của tệp/sự kiện. Các cảm biến có nhược điểm vì chúng dựa vào việc truy vấn định kỳ. Các vấn đề với cảm biến bao gồm kích hoạt trên các tệp đã tồn tại và không nhất thiết phản ứng kịp thời với sự kiện (ví dụ: chúng chỉ truy vấn theo từng khoảng thời gian).

Tóm lại, Airflow phù hợp cho các luồng công việc có tính định kỳ, theo lô hoặc phức tạp để định nghĩa và quản lý. Nó có thể không thích hợp nếu trường hợp của bạn đòi hỏi xử lý thời gian thực hoặc liên tục, các công việc cực kỳ tần suất cao, hoặc các luồng công việc rất đơn giản mà không cần đến gánh nặng của Airflow. Trong trường hợp đó, bạn có thể muốn khám phá các tùy chọn khác hoặc đơn giản hóa giải pháp của mình.

Các lựa chọn thay thế cho Airflow

Lĩnh vực điều phối quy trình làm việc đã bùng nổ trong những năm gần đây, và mặc dù Airflow là một trong những dẫn đầu, vẫn có một số Công cụ thay thế đáng để biết đến:

Airflow không phải là lựa chọn duy nhất, và lựa chọn tốt nhất phụ thuộc vào trường hợp sử dụng của bạn. Luigi, Prefect và Dagster thường được liệt kê là những lựa chọn mã nguồn mở chính khác trong cùng lĩnh vực (các bộ điều phối workflow dựa trên Python). Nếu bạn cảm thấy giao diện cũ kỹ của Airflow hoặc các hạn chế khác gây phiền toái, bạn nên xem xét đánh giá các công cụ này. Prefect cố gắng trở thành một phiên bản Airflow “tốt hơn” hoặc “đơn giản hơn”, Dagster cố gắng trở thành một bộ điều phối “có cấu trúc” hơn với trọng tâm trên các tài sản dữ liệu, và Luigi là phiên bản tiền nhiệm đơn giản hơn của Airflow. Mặt khác, nếu trường hợp sử dụng của bạn khác biệt đáng kể (ví dụ như streaming thời gian thực hoặc hoàn toàn trên đám mây), bạn có thể sẽ không dùng Airflow và có thể cân nhắc trực tiếp các nền tảng streaming hoặc dịch vụ điều phối được quản lý.

Suy Nghĩ Cuối Cùng

Apache Airflow là một nền tảng mã nguồn mở để điều phối các quy trình tính toán phức tạp và các pipeline xử lý dữ liệu. Ban đầu được phát triển tại Airbnb, nó đã trở nên phổ biến đáng kể trong cộng đồng kỹ sư dữ liệu và học máy. Các thành phần của Airflow bao gồm bộ lập lịch, executor, các worker, cơ sở dữ liệu metadata và giao diện người dùng dựa trên web. Điều này cho phép các nhóm một cách dễ dàng chạy và duy trì các pipeline ETL, MLOps và hạ tầng sẵn sàng cho sản xuất. Trừu tượng DAG (Directed Acyclic Graph) của Airflow cho phép giữ các workflow rõ ràng, dễ kiểm thử và dễ bảo trì theo thời gian. Hệ sinh thái của nền tảng với các operator và provider do cộng đồng xây dựng cũng đơn giản hóa việc điều phối workflow phụ thuộc vào bất kỳ công nghệ hoặc công cụ nào.

Tuy nhiên, đây không phải là một giải pháp phù hợp cho tất cả. Nó hoạt động tốt nhất với các pipeline theo lô hoặc lô nhỏ, và người dùng phải thành thạo Python. Đối với các luồng công việc theo dạng streaming hoặc tần suất cao, có những giải pháp khác phù hợp hơn Airflow. Đối với các nhà khoa học dữ liệu hoặc các đội ngũ thích viết pipeline theo kiểu khai báo, các công cụ thay thế Airflow có thể đáng để cân nhắc.

Airflow vẫn đang được phát triển tích cực, và các tính năng mới liên tục được thêm vào theo thời gian, chẳng hạn như lập lịch theo sự kiện, bộ dữ liệu và tài sản. Các khái niệm và thực tiễn tốt nhất được giới thiệu trong hướng dẫn này sẽ giúp bạn, bất kể xuất phát điểm của bạn, hiểu cách thức điều phối quy trình làm việc hoạt động và khi nào nên (hoặc không nên) sử dụng Airflow. Hy vọng rằng điều này sẽ trở thành bước đệm để bạn khám phá sâu hơn về vũ trụ phong phú này.

Tài liệu tham khảo

• Apache Airflow
• Airflow là gì?
• Apache Airflow: Các trường hợp sử dụng, kiến trúc và 6 mẹo để thành công
• Giới thiệu dành cho người mới về Airflow với Docker — Các Pipeline Dữ liệu trên Mây (Phần I)
• 8 lựa chọn thay thế Airflow - Các trường hợp sử dụng
• Tổng quan kiến trúc
• Trình lập lịch

Cảm ơn bạn đã học cùng cộng đồng Linux-Console.net.