Các Nâng Cấp Trong Apache Airflow 3.0

Apache Airflow 3.0, được phát hành chính thức vào ngày 22-23 tháng 4 năm 2025 , đánh dấu một bước tiến quan trọng nhất trong lịch sử của dự án kể từ phiên bản 2.0 ra mắt năm 2020. Phiên bản này không chỉ là một bản cập nhật thông thường mà là kết quả của một quá trình tái thiết kế sâu rộng, được thúc đẩy bởi nhu cầu hỗ trợ các trường hợp sử dụng hiện đại như Trí tuệ Nhân tạo Tạo sinh (GenAI) và các luồng công việc dữ liệu thời gian thực. Airflow 3.0 tập trung vào bốn chủ đề cốt lõi: tái cấu trúc kiến trúc nền tảng, cải thiện đáng kể khả năng sử dụng và trải nghiệm người dùng, hiện đại hóa các mô hình lập lịch, và tăng cường bảo mật cũng như tính linh hoạt trong triển khai.

Kiến trúc của Airflow 3.0 đã được định hình lại một cách cơ bản, chuyển đổi sang mô hình hướng dịch vụ (service-oriented) với sự ra đời của Task Execution API và SDK. Thay đổi nền tảng này cho phép thực thi tác vụ (task) một cách tách biệt và linh hoạt hơn, mở đường cho việc thực thi từ xa (remote execution), thực thi tại biên (edge execution) và hỗ trợ đa ngôn ngữ trong tương lai. Đi kèm với đó là một API Server trung tâm, đóng vai trò là nền tảng cho giao diện người dùng mới và giao diện dòng lệnh (CLI) nâng cao.

Về mặt người dùng, Airflow 3.0 mang đến những cải tiến được mong đợi từ lâu. Tính năng DAG Versioning cho phép theo dõi lịch sử thay đổi của DAG, giải quyết một trong những điểm yếu lớn nhất của các phiên bản trước. Quá trình Backfill (chạy lại các tác vụ trong quá khứ) được quản lý bởi Scheduler, cung cấp khả năng kiểm soát, theo dõi và mở rộng tốt hơn thông qua giao diện người dùng (UI) và API. Giao diện người dùng cũng được viết lại hoàn toàn bằng React và FastAPI, mang lại trải nghiệm nhanh hơn, trực quan hơn và hiện đại hơn.

Các mô hình lập lịch cũng được nâng cấp đáng kể. Khái niệm "Datasets" từ Airflow 2.x đã phát triển thành "Data Assets", kết hợp với cơ chế "Watchers" để cho phép lập lịch dựa trên sự kiện (event-driven scheduling) một cách mạnh mẽ hơn. Airflow giờ đây có thể phản ứng với các sự kiện xảy ra bên ngoài hệ thống, ví dụ như dữ liệu mới xuất hiện trong hàng đợi tin nhắn. Hơn nữa, việc loại bỏ ràng buộc duy nhất về ngày logic (logical date) cho phép chạy các DAG song song cho các trường hợp sử dụng như suy luận mô hình ML/AI.

Cuối cùng, kiến trúc mới tăng cường bảo mật thông qua việc cô lập tác vụ tốt hơn và cho phép các mô hình triển khai linh hoạt hơn, bao gồm đa đám mây, đám mây lai và tại biên, đáp ứng các yêu cầu khắt khe về bảo mật và chủ quyền dữ liệu của doanh nghiệp.

Báo cáo này cung cấp một phân tích kỹ thuật chi tiết về những nâng cấp này, so sánh với Airflow 2.x, thảo luận về các thay đổi có thể gây gián đoạn (breaking changes), xem xét các yếu tố về hiệu năng và khả năng mở rộng, đồng thời cung cấp hướng dẫn cụ thể cho quá trình di chuyển lên phiên bản 3.0. Thông tin này rất quan trọng đối với các Kỹ sư Dữ liệu, Quản trị viên Airflow và các Trưởng nhóm Kỹ thuật đang xem xét việc nâng cấp và muốn hiểu rõ tác động của Airflow 3.0 đối với các hệ thống hiện có của họ.

Chuyển Đổi Kiến Trúc: Nền Tảng Của Airflow 3.0

Airflow 3.0 không chỉ đơn thuần là một bản cập nhật tính năng; nó đại diện cho một sự thay đổi kiến trúc nền tảng. So với kiến trúc tương đối nguyên khối và tập trung vào Scheduler của các phiên bản trước, Airflow 3.0 chuyển dịch mạnh mẽ sang một mô hình hướng dịch vụ, mô-đun hóa và có khả năng mở rộng cao hơn. Sự thay đổi này là cần thiết để đáp ứng các yêu cầu của các trường hợp sử dụng mới nổi như GenAI và xử lý dữ liệu thời gian thực, vốn đòi hỏi sự linh hoạt và khả năng tích hợp cao hơn.

Task Execution API và SDK (AIP-72)

Trọng tâm của sự thay đổi kiến trúc này là việc giới thiệu Task Execution API và Task SDK đi kèm. Đây là một đổi mới cốt lõi, có chức năng tách biệt quá trình thực thi tác vụ khỏi các thành phần cốt lõi của Airflow như Scheduler và Webserver (nay là API Server). Nó thiết lập một mô hình client-server rõ ràng , nơi API Server định nghĩa giao diện và các tác vụ (được đóng gói bởi SDK) hoạt động như các client thực thi.

Sự tách biệt này mang lại nhiều lợi ích đáng kể:

1. Thực thi Từ xa/Tại biên (Remote/Edge Execution): Cho phép các tác vụ chạy trên các môi trường vật lý tách biệt khỏi cụm Airflow trung tâm. Điều này có thể là trên các máy chủ gần nguồn dữ liệu, trên phần cứng chuyên dụng (như GPU), hoặc trong các vùng mạng có yêu cầu bảo mật khác nhau. Edge Executor (AIP-69) là một thành phần cụ thể tận dụng khả năng này để chạy tác vụ ở các địa điểm phân tán hoặc thiết bị biên.
2. Hỗ trợ Đa ngôn ngữ (Multi-Language Support): Bằng cách định nghĩa một giao diện thực thi chuẩn, Task Execution API đặt nền móng cho việc viết tác vụ bằng các ngôn ngữ khác ngoài Python. Airflow 3.0 bao gồm Python TaskSDK để đảm bảo khả năng tương thích ngược với các DAG hiện có , nhưng các SDK cho Go, Java và các ngôn ngữ khác được lên kế hoạch phát hành trong các phiên bản 3.x tiếp theo. Điều này mở rộng đáng kể phạm vi ứng dụng của Airflow cho các nhóm phát triển sử dụng nhiều công nghệ khác nhau.
3. Quản lý Phụ thuộc (Dependency Management) Cải thiện: Các tác vụ có thể chạy trong các môi trường cô lập (ví dụ: container) với các phụ thuộc riêng, tách biệt khỏi môi trường của Scheduler hay các tác vụ khác. Điều này giúp loại bỏ xung đột phụ thuộc, một vấn đề thường gặp trong các hệ thống phức tạp, và tăng tính nhất quán trong thực thi.

API Server

API Server là một thành phần trung tâm mới được giới thiệu cùng với kiến trúc mới. Nó đóng vai trò là điểm vào cho Task Execution API, tiếp nhận yêu cầu thực thi tác vụ từ Scheduler. Ngoài ra, API Server còn là nền tảng backend cho giao diện người dùng React/FastAPI hoàn toàn mới và cho phép giao diện dòng lệnh từ xa mới (airflowctl) tương tác với Airflow thông qua API. Do vai trò quan trọng này, việc khởi động API Server một cách tường minh bằng lệnh airflow api-server là bắt buộc trong Airflow 3.0.

Cô lập Tác vụ và Linh hoạt Triển khai

Kiến trúc mới tăng cường đáng kể khả năng cô lập tác vụ, mang lại lợi ích về cả bảo mật và hiệu năng. Việc chạy tác vụ trong các môi trường sandbox (như container) giúp giảm thiểu rủi ro rò rỉ dữ liệu hoặc xung đột tài nguyên giữa các tác vụ. Mỗi tác vụ hoặc DAG có thể hoạt động với phiên bản thư viện, môi trường Python hoặc công cụ runtime riêng, độc lập với các thành phần Airflow cốt lõi. Điều này cũng giúp việc nâng cấp Airflow trở nên mượt mà hơn mà không làm gián đoạn các tác vụ đang chạy hoặc phá vỡ tính tương thích.

Quan trọng hơn, kiến trúc này hỗ trợ một loạt các mô hình triển khai đa dạng, phù hợp với nhu cầu hạ tầng phức tạp của các tổ chức hiện đại. Airflow 3.0 có thể được triển khai trên các nền tảng đám mây công cộng (AWS, GCP, Azure), trong các môi trường đám mây riêng tư hoặc lai, và thậm chí hỗ trợ triển khai tại biên (edge deployment) cho các trường hợp sử dụng như suy luận ML hoặc phát hiện bất thường trực tiếp trên phần cứng công nghiệp hoặc di động. Khả năng này giúp các tổ chức tuân thủ các quy định về địa phương hóa dữ liệu (data locality), xây dựng lịch trình chịu lỗi tốt hơn và tận dụng các tài nguyên tính toán chuyên dụng như GPU.

Phân tách CLI (airflow vs airflowctl) (AIP-81)

Để phù hợp với backend mô-đun hóa, Airflow 3.0 giới thiệu giao diện dòng lệnh (CLI) được phân tách thành hai phần, phân biệt rõ ràng giữa các tác vụ phát triển cục bộ và các hoạt động vận hành từ xa.

• airflow: Lệnh này chủ yếu dành cho phát triển và kiểm thử cục bộ. Nó tương tác trực tiếp với các tệp DAG cục bộ, cơ sở dữ liệu metadata và các thành phần Airflow trên cùng một máy. Các trường hợp sử dụng bao gồm kiểm thử nhanh, phân tích cú pháp DAG và gỡ lỗi dựa trên CLI.
• airflowctl: Lệnh này được thiết kế cho môi trường sản xuất và điều phối từ xa. Nó tương tác với Airflow thông qua API Server, xử lý các tác vụ như quản lý môi trường, triển khai và thực thi trên đám mây. airflowctl rất hữu ích cho các đường ống CI/CD, khả năng quan sát (observability) và quản lý cụm phân tán. Lưu ý rằng airflowctl được lên kế hoạch phát hành dưới dạng một gói provider riêng biệt.

Sự phân chia này giúp đơn giản hóa quy trình làm việc cho cả nhà phát triển cá nhân và các nhóm vận hành nền tảng, làm cho việc tương tác với Airflow trở nên rõ ràng và phù hợp hơn với từng ngữ cảnh.

Việc xem xét tổng thể các thay đổi kiến trúc này cho thấy một xu hướng rõ ràng. Các yếu tố như Task Execution API, khả năng cô lập tác vụ, hỗ trợ triển khai linh hoạt và tương tác dựa trên API giải quyết trực tiếp nhiều điểm yếu và yêu cầu phổ biến trong các môi trường doanh nghiệp lớn, vốn thường gặp khó khăn với Airflow 1.x/2.x. Các doanh nghiệp thường có yêu cầu bảo mật nghiêm ngặt về môi trường thực thi tác vụ và quyền truy cập vào hạ tầng trung tâm. Kiến trúc mới cho phép các worker/tác vụ chạy trong môi trường hạn chế với đặc quyền tối thiểu, chỉ cần giao tiếp qua API , giúp cải thiện đáng kể tình hình bảo mật. Khả năng hỗ trợ các mô hình lai/đa đám mây và tuân thủ địa phương hóa dữ liệu cũng là những yếu tố then chốt. Việc quản lý phụ thuộc giữa nhiều nhóm và DAG cũng trở nên đơn giản hơn nhờ cô lập tác vụ. Do đó, việc tái thiết kế kiến trúc không chỉ là một cải tiến kỹ thuật đơn thuần mà còn là một động thái chiến lược, làm cho Airflow 3.0 trở nên hấp dẫn và khả thi hơn đáng kể đối với các môi trường doanh nghiệp phức tạp và yêu cầu bảo mật cao so với các phiên bản tiền nhiệm.

Phân Tích Sâu Các Tính Năng Chính

Airflow 3.0 giới thiệu một loạt các tính năng mới và cải tiến đáng kể, nhiều trong số đó được xây dựng dựa trên nền tảng kiến trúc mới.

DAG Versioning (AIP-65, AIP-66)

Đây là một trong những tính năng được yêu cầu nhiều nhất từ cộng đồng Airflow. Trước đây, việc thay đổi cấu trúc DAG (ví dụ: xóa một tác vụ) có thể làm mất lịch sử liên quan trong giao diện người dùng, gây khó khăn cho việc kiểm tra và gỡ lỗi.

Airflow 3.0 giải quyết vấn đề này bằng cách theo dõi các thay đổi cấu trúc của DAG theo thời gian. Mỗi lần chạy DAG (DAG Run) giờ đây được gắn với một phiên bản cụ thể của DAG (bao gồm mã nguồn, cấu trúc tác vụ, tham số) tại thời điểm nó bắt đầu chạy, ngay cả khi tệp DAG được cập nhật trong quá trình thực thi. Các phiên bản lịch sử này được lưu trữ hoặc tham chiếu trong cơ sở dữ liệu metadata.

Người dùng có thể truy cập các phiên bản DAG khác nhau thông qua giao diện người dùng. Menu thả xuống trong chế độ xem Graph và Grid cho phép chọn phiên bản, và chế độ xem Code hiển thị mã nguồn tương ứng với phiên bản đã chọn. Cơ chế DAG Bundles (AIP-66) chịu trách nhiệm lấy và phân tích cú pháp các phiên bản DAG này, ví dụ như từ một kho lưu trữ Git.

Lợi ích chính của DAG Versioning bao gồm khả năng kiểm toán (auditability) được cải thiện đáng kể, gỡ lỗi các lần chạy trong quá khứ dễ dàng hơn (vì có thể xem chính xác mã đã chạy), tăng cường tuân thủ quy định (compliance), và giảm sự nhầm lẫn khi DAG phát triển theo thời gian. Nó cũng hỗ trợ các quy trình như xem xét thay đổi DAG trực tiếp trong UI hoặc kiểm tra hành vi lịch sử mà không ảnh hưởng đến DAG sản xuất.

Scheduler-Managed Backfills (AIP-78)

Việc chạy lại các tác vụ cho các khoảng thời gian trong quá khứ (backfilling) là một nhu cầu phổ biến, nhưng trong Airflow 2.x, nó thường được thực hiện thông qua CLI, dễ bị lỗi (ví dụ: mất phiên kết nối), thiếu khả năng hiển thị trong UI và khó quản lý ở quy mô lớn.

Airflow 3.0 cải tiến hoàn toàn quy trình này bằng cách tích hợp việc quản lý backfill vào Scheduler. Các lần chạy backfill giờ đây được xử lý tương tự như các lần chạy DAG thông thường, tận dụng cùng một logic lập lịch và thực thi.

Người dùng có thể dễ dàng kích hoạt, theo dõi tiến trình, tạm dừng và hủy bỏ các backfill trực tiếp từ giao diện người dùng hoặc thông qua REST API. Điều này mang lại khả năng kiểm soát tốt hơn, độ tin cậy cao hơn (không còn lo lắng về việc mất phiên CLI), khả năng mở rộng tốt hơn cho các công việc tái xử lý quy mô lớn, và cung cấp thông tin chẩn đoán hữu ích. Đây là một cải tiến quan trọng, đặc biệt đối với các trường hợp sử dụng như huấn luyện lại mô hình ML hoặc kiểm tra tính toàn vẹn dữ liệu lịch sử.

Event-Driven Scheduling và Data Assets (AIP-74, AIP-75, AIP-82)

Airflow 3.0 phát triển khái niệm "Datasets" (được giới thiệu trong 2.x) thành một khái niệm mạnh mẽ hơn là "Data Assets". Data Assets đại diện cho các thực thể dữ liệu logic mà các DAG có thể sản xuất hoặc tiêu thụ.

Việc định nghĩa các asset và mối quan hệ của chúng với các tác vụ được đơn giản hóa đáng kể thông qua cú pháp decorator @asset mới. Decorator này cho phép khai báo một cách rõ ràng rằng một tác vụ tạo ra hoặc cập nhật một asset cụ thể.

Quan trọng hơn, Data Assets là nền tảng cho khả năng lập lịch dựa trên sự kiện (event-driven scheduling) nâng cao. Các DAG giờ đây có thể được kích hoạt không chỉ dựa trên lịch trình thời gian mà còn dựa trên các sự kiện xảy ra bên ngoài Airflow, chẳng hạn như việc một asset được cập nhật. Cơ chế "Watchers" được giới thiệu để Airflow có thể theo dõi các hệ thống bên ngoài này; phiên bản đầu tiên hỗ trợ AWS SQS.

Cách tiếp cận này cho phép xây dựng các đường ống dữ liệu phản ứng (reactive), xử lý dữ liệu gần thời gian thực, giảm độ trễ và loại bỏ chi phí của việc thăm dò (polling) liên tục để kiểm tra sự kiện. Giao diện người dùng cũng được cập nhật để hiển thị các asset, mối quan hệ phụ thuộc (lineage) giữa chúng và các DAG, cung cấp cái nhìn trực quan về luồng dữ liệu.

Giao diện Người dùng Hiện đại hóa (AIP-38, AIP-84)

Một trong những thay đổi dễ nhận thấy nhất trong Airflow 3.0 là giao diện người dùng được viết lại hoàn toàn. Frontend sử dụng React và backend được xây dựng trên FastAPI.

Việc viết lại này mang lại những cải thiện đáng kể về hiệu suất và khả năng phản hồi, đặc biệt trong các môi trường có số lượng lớn DAG. Trải nghiệm người dùng tổng thể trở nên mượt mà, trực quan và nhất quán hơn. Các cải tiến cụ thể bao gồm:

• Trang chủ mới: Cung cấp cái nhìn tổng quan về trạng thái hoạt động của môi trường Airflow.
• Điều hướng và Bố cục Cải thiện: Dễ dàng chuyển đổi giữa các chế độ xem tập trung vào asset và tác vụ. Danh sách DAG được làm mới, gọn gàng hơn.
• Chế độ xem Grid/Graph Nâng cao: Cải thiện điều hướng dòng thời gian, tìm kiếm, lọc, phóng to/thu nhỏ, khám phá metadata tương tác. Quan trọng là các chế độ xem này giờ đây nhận biết được phiên bản DAG (version-aware), hiển thị thông tin trong ngữ cảnh của phiên bản đã chạy. Khả năng hiển thị đồ thị phụ thuộc cũng được mở rộng.
• Chế độ xem Asset: Các chế độ xem chuyên dụng để trực quan hóa các asset và mối quan hệ lineage của chúng.
• Chế độ xem Backfill: Giao diện để quản lý và theo dõi các backfill.
• Chế độ xem Code: Hiển thị mã nguồn chính xác của phiên bản DAG đã được phân tích bởi scheduler.
• Truy cập Log Cải thiện: Truy cập log tác vụ được sắp xếp hợp lý hơn từ nhiều chế độ xem.
• Chế độ Tối (Dark Mode) Tích hợp: Hỗ trợ sẵn chế độ tối.

Kiến trúc UI mới này cũng tạo nền tảng cho việc phát triển các plugin React nâng cao trong tương lai. Đồng thời, một thay đổi quan trọng liên quan là việc loại bỏ Flask AppBuilder (FAB) khỏi thành phần cốt lõi (AIP-79) và chuyển nó thành một gói provider riêng biệt. Điều này nhằm cải thiện bảo mật và khả năng bảo trì, nhưng cũng có nghĩa là các plugin UI tùy chỉnh dựa trên FAB cần được điều chỉnh hoặc sử dụng lớp tương thích ngược.

Hỗ trợ Gốc cho Luồng công việc ML/AI (AIP-83)

Airflow 3.0 giải quyết một hạn chế lớn đối với các trường hợp sử dụng ML/AI bằng cách loại bỏ ràng buộc duy nhất về ngày logic (execution date) và cho phép các DAG chạy với logical_date=None.

Trước đây, mỗi lần chạy DAG phải được liên kết với một khoảng thời gian (data interval) duy nhất, điều này không phù hợp với các tác vụ như suy luận mô hình theo yêu cầu hoặc chạy nhiều thử nghiệm song song không gắn với lịch trình thời gian cố định.

Thay đổi này cho phép các trường hợp sử dụng như:

• Chạy nhiều phiên suy luận mô hình song song.
• Phục vụ dự đoán mô hình theo yêu cầu (on-demand).
• Thực thi các luồng công việc không gắn với một khoảng dữ liệu cụ thể.

Điều này định vị Airflow 3.0 tốt hơn để hỗ trợ các quy trình MLOps, GenAI và các ứng dụng AI hiện đại khác, vốn thường yêu cầu các mô hình thực thi linh hoạt hơn so với ETL/batch truyền thống.

Khả năng Thực thi Từ xa và Tại biên

Như đã đề cập trong phần kiến trúc, Task Execution API là yếu tố cho phép thực thi tác vụ ở các địa điểm khác nhau.

• Remote Execution: Cho phép triển khai các worker ở bất kỳ môi trường nào (ví dụ: trong một mạng riêng, trên đám mây khác) trong khi vẫn duy trì kiểm soát trung tâm và bảo mật. Các agent thực thi từ xa chỉ khởi tạo kết nối ra ngoài (outbound), loại bỏ nhu cầu mở cổng tường lửa vào (inbound), đáp ứng các yêu cầu bảo mật nghiêm ngặt.
• Edge Executor (AIP-69): Là một executor chuyên dụng được thiết kế để chạy tác vụ ở các địa điểm phân tán, gần nguồn dữ liệu hoặc trên các thiết bị biên. Nó được cung cấp dưới dạng một gói provider riêng (edge3). Các worker tại biên giao tiếp với API Server trung tâm qua HTTP để nhận tác vụ.

Các trường hợp sử dụng cho khả năng này rất đa dạng, bao gồm các ứng dụng IoT (nơi dữ liệu được xử lý gần cảm biến), nguồn cấp dữ liệu tài chính (yêu cầu độ trễ thấp), giám sát hoạt động, tuân thủ các quy định về địa phương hóa dữ liệu (chạy tác vụ trong khu vực địa lý cụ thể), và truy cập vào phần cứng chuyên dụng như GPU mà không cần đặt chúng trong cụm Airflow chính.

Sự kết nối chặt chẽ giữa các tính năng cốt lõi này là một điểm đáng chú ý. Task Execution API không chỉ cho phép thực thi từ xa/biên và đa ngôn ngữ trong tương lai, mà còn là nền tảng mà API Server dựa vào. API Server lại là trái tim cung cấp năng lượng cho UI mới và CLI từ xa. Giao diện người dùng React/FastAPI mới là cần thiết để trực quan hóa và tương tác hiệu quả với các khái niệm mới như DAG Versioning, Assets và Backfills được quản lý bởi Scheduler. Lập lịch dựa trên sự kiện thông qua Assets bổ sung cho Edge Executor, cho phép tạo ra các luồng công việc phân tán và phản ứng nhanh. Do đó, Airflow 3.0 không phải là một tập hợp các tính năng rời rạc, mà là một hệ thống được thiết kế lại một cách gắn kết, nơi những thay đổi kiến trúc cơ bản mở khóa các tiến bộ chức năng lớn, tạo ra hiệu ứng cộng hưởng.

Airflow 3.0 vs. Airflow 2.x: Phân Tích So Sánh

Việc nâng cấp từ Airflow 2.x lên 3.0 đòi hỏi sự hiểu biết về những khác biệt cơ bản giữa hai phiên bản. Airflow 3.0 đánh dấu một sự thay đổi đáng kể so với các bản phát hành 2.1 đến 2.10, vốn tập trung vào việc bổ sung tính năng và cải thiện sự ổn định trên nền tảng 2.0.

Thay Đổi Cơ Bản

Sự khác biệt cốt lõi nằm ở kiến trúc. Airflow 2.x, mặc dù đã giới thiệu Scheduler HA , vẫn giữ một kiến trúc tương đối tập trung vào Scheduler và Python. Airflow 3.0 chuyển sang mô hình tách biệt, hướng API, với tiềm năng độc lập ngôn ngữ. Điều này thể hiện một sự thay đổi chiến lược từ việc tối ưu hóa các quy trình hiện có sang việc tái cấu trúc để hỗ trợ các mô hình làm việc mới và linh hoạt hơn.

Tiến Hóa và Thay Thế Tính Năng

Nhiều khái niệm và tính năng trong Airflow 2.x đã được phát triển hoặc thay thế hoàn toàn trong Airflow 3.0:

• Datasets (2.x) -> Data Assets (3.0): Từ một cơ chế tương đối đơn giản để theo dõi lineage và kích hoạt DAG [ (2.10)], Data Assets trong 3.0 trở thành một khái niệm phong phú hơn với cú pháp @asset, watchers, và tích hợp sâu hơn vào lập lịch dựa trên sự kiện.
• CLI Backfills (2.x) -> Scheduler-Managed Backfills (3.0): Quy trình backfill chuyển từ một lệnh CLI dễ bị lỗi, không có giao diện sang một tính năng được quản lý hoàn toàn bởi Scheduler, có thể điều khiển và theo dõi qua UI/API.
• Không có Versioning (2.x) -> DAG Versioning (3.0): Airflow 3.0 giải quyết một trong những yêu cầu lớn nhất bằng cách giới thiệu khả năng theo dõi lịch sử thay đổi cấu trúc DAG.
• UI dựa trên FAB (2.x) -> UI React/FastAPI (3.0): Giao diện người dùng được viết lại hoàn toàn để cải thiện hiệu suất, trải nghiệm người dùng và khả năng mở rộng.
• SubDAGs (Không dùng nữa ở 2.x, Bị loại bỏ ở 3.0): SubDAGs chính thức bị loại bỏ. TaskGroups (được giới thiệu trong 2.x) là giải pháp thay thế được khuyến nghị, cùng với việc sử dụng Assets và các tác vụ động.
• SLAs (Không dùng nữa ở 2.x, Bị loại bỏ ở 3.0): Tính năng Service Level Agreements (SLAs) bị loại bỏ. "Deadline Alerts" được lên kế hoạch thay thế trong tương lai, nhưng hiện tại chưa có giải pháp tương đương trực tiếp.
• Pickling (Sử dụng ở 2.x, Bị loại bỏ ở 3.0): Việc sử dụng pickle để tuần tự hóa DAG và XComs bị loại bỏ, thay vào đó yêu cầu sử dụng tuần tự hóa dựa trên JSON.

Bảng: So Sánh Tính Năng: Airflow 2.x vs Airflow 3.0

Export to Sheets

Bảng so sánh này làm nổi bật những nâng cấp cốt lõi và sự thay đổi định hướng trong Airflow 3.0, giúp người dùng nhanh chóng nắm bắt được những điểm khác biệt chính so với các phiên bản 2.x.

Xem Xét Hiệu Năng và Khả Năng Mở Rộng

Đánh giá hiệu năng của Airflow 3.0 so với 2.x cần xem xét nhiều yếu tố, và điều quan trọng cần lưu ý là các tài liệu tham khảo hiện tại không cung cấp các benchmark định lượng trực tiếp, so sánh toàn diện giữa hai phiên bản. Tuy nhiên, dựa trên những thay đổi về kiến trúc và tính năng, có thể đưa ra những nhận định về các khía cạnh hiệu năng và khả năng mở rộng.

Tác Động Kiến Trúc

Kiến trúc tách biệt dựa trên Task Execution API có thể mang lại một sự đánh đổi tiềm năng: việc giao tiếp qua API có thể thêm một độ trễ nhỏ (latency) vào thời gian khởi động của mỗi tác vụ riêng lẻ so với việc thực thi trực tiếp trên worker như trong các mô hình cũ. Tuy nhiên, sự tách biệt này được kỳ vọng sẽ cải thiện đáng kể thông lượng (throughput) tổng thể của hệ thống, khả năng mở rộng và độ tin cậy. Bằng cách tách biệt các mối quan tâm (ví dụ: Scheduler không còn trực tiếp quản lý các quy trình worker phức tạp), các thành phần như UI, API Server, Scheduler và các cụm worker/tác vụ có thể được mở rộng quy mô một cách độc lập, cho phép tối ưu hóa tài nguyên tốt hơn.

Cải Tiến Scheduler

Airflow 3.0 giải quyết một số điểm nghẽn hiệu năng lịch sử liên quan đến Scheduler:

1. Standalone DAG Processor: Việc yêu cầu một quy trình xử lý DAG (DAG Processor) chạy độc lập là một thay đổi bắt buộc trong Airflow 3.0. Điều này giúp giảm tải công việc phân tích cú pháp DAG khỏi Scheduler chính. Trong Airflow 2.x, đặc biệt với số lượng lớn DAG, việc phân tích cú pháp có thể tiêu tốn tài nguyên đáng kể của Scheduler và ảnh hưởng đến khả năng lập lịch tác vụ kịp thời. Tách biệt quy trình này giúp Scheduler tập trung vào nhiệm vụ cốt lõi là lập lịch, dẫn đến hiệu suất và độ ổn định tốt hơn.
2. Khả năng chịu lỗi (Fault Tolerance) Cải thiện: Các thành phần Scheduler giờ đây sử dụng cơ chế run_with_db_retries để xử lý tốt hơn các sự cố cơ sở dữ liệu tạm thời , tăng cường khả năng phục hồi của hệ thống.

So với Scheduler HA được giới thiệu trong Airflow 2.0 , những cải tiến trong 3.0 tập trung nhiều hơn vào việc tối ưu hóa quy trình làm việc nội bộ của Scheduler và giảm bớt gánh nặng xử lý DAG.

Khả Năng Mở Rộng Của Backfill và Lập Lịch Sự Kiện

• Backfills: Việc quản lý backfill bởi Scheduler được thiết kế để có khả năng mở rộng tốt hơn đáng kể so với phương pháp dựa trên CLI trước đây, vốn dễ bị giới hạn bởi tài nguyên của máy khách hoặc sự ổn định của phiên kết nối.
• Event-Driven Scheduling: Lập lịch dựa trên sự kiện thông qua Assets và Watchers vốn dĩ hiệu quả hơn về mặt tài nguyên so với việc liên tục thăm dò (polling) các điều kiện kích hoạt. Điều này giúp giảm tải cho hệ thống và giảm độ trễ trong việc phản ứng với các sự kiện.

Khả Năng Phản Hồi Của Giao Diện Người Dùng

Việc viết lại hoàn toàn giao diện người dùng bằng React và FastAPI trực tiếp nhắm vào các vấn đề về hiệu suất và khả năng phản hồi thường thấy trong các phiên bản cũ, đặc biệt khi quản lý hàng trăm hoặc hàng nghìn DAG. Người dùng có thể mong đợi một trải nghiệm UI nhanh và mượt mà hơn đáng kể.

Tóm lại, mặc dù thiếu các benchmark định lượng, các thay đổi kiến trúc và tính năng trong Airflow 3.0 cho thấy tiềm năng cải thiện hiệu năng và khả năng mở rộng ở nhiều khía cạnh quan trọng. Hiệu suất tổng thể sẽ phụ thuộc vào ngữ cảnh cụ thể của từng hệ thống triển khai và loại workload. Các môi trường gặp phải tắc nghẽn về UI hoặc Scheduler trong Airflow 2.x có khả năng thấy được lợi ích rõ rệt nhất. Việc tách biệt thực thi tác vụ có thể thêm độ trễ nhỏ cho từng tác vụ nhưng bù lại bằng sự ổn định, khả năng mở rộng và thông lượng hệ thống tốt hơn, đặc biệt trong các môi trường phân tán quy mô lớn.

Điều Hướng Các Thay Đổi Gây Gián Đoạn và Tính Năng Không Còn Được Hỗ Trợ

Airflow 3.0 giới thiệu một số thay đổi đáng kể có thể gây gián đoạn (breaking changes) và loại bỏ các tính năng đã được đánh dấu là không còn được hỗ trợ (deprecated) trong các phiên bản 2.x. Việc hiểu rõ những thay đổi này là rất quan trọng để lập kế hoạch di chuyển thành công.

Các Loại Bỏ Chính

• SubDAGs / SubDagOperator: Tính năng này đã bị loại bỏ hoàn toàn. Người dùng cần chuyển sang sử dụng TaskGroups (đã có từ Airflow 2.x) làm cơ chế chính để nhóm các tác vụ một cách logic trong DAG. Assets và Data Aware Scheduling cũng có thể cung cấp các mẫu thay thế trong một số trường hợp.
• SLAs (Service Level Agreements): Tính năng SLAs để theo dõi thời gian hoàn thành tác vụ đã bị loại bỏ. Một tính năng thay thế có tên "Deadline Alerts" đang được lên kế hoạch cho tương lai, nhưng hiện tại không có sự thay thế trực tiếp. Các tổ chức dựa vào SLAs cần triển khai các cơ chế giám sát và cảnh báo tùy chỉnh.
• Pickling cho DAGs/XComs: Hỗ trợ tuần tự hóa đối tượng Python bằng pickle cho DAG và XCom đã bị loại bỏ do các vấn đề về bảo mật và khả năng tương thích. Tất cả dữ liệu được truyền qua XCom hoặc lưu trữ trong metadata liên quan đến DAG phải có thể tuần tự hóa bằng JSON. Điều này có thể yêu cầu thay đổi cách truyền dữ liệu giữa các tác vụ nếu đang sử dụng các đối tượng Python phức tạp.
• Các Biến Context Kế thừa: Một số biến context thường được sử dụng trong các phiên bản trước đã bị loại bỏ khỏi context của một task instance. Các biến bị loại bỏ đáng chú ý bao gồm execution_date, prev_ds, next_ds, tomorrow_ds, yesterday_ds, prev_execution_date, next_execution_date, v.v.. Người dùng cần cập nhật các template và mã tác vụ để sử dụng các biến thay thế như dag_run.logical_date, data_interval_start, data_interval_end, run_id, ts, ts_nodash, v.v.
• Phụ thuộc Cốt lõi vào Flask AppBuilder (FAB): FAB không còn là một phần của gói apache-airflow cốt lõi mà được chuyển sang một gói provider riêng (apache-airflow-providers-flask-appbuilder). Điều này ảnh hưởng đến các plugin UI tùy chỉnh và cơ chế xác thực dựa trên FAB. Trình quản lý xác thực mặc định đã thay đổi thành SimpleAuthManager. Để tiếp tục sử dụng xác thực FAB, cần cài đặt provider FAB và cấu hình auth_manager một cách tường minh.
• Các Import Cốt lõi Kế thừa: Các import trực tiếp từ các mô-đun cốt lõi như airflow.operators.bash, airflow.hooks.postgres đã bị loại bỏ hoàn toàn. Người dùng bắt buộc phải import từ các gói provider tương ứng (ví dụ: airflow.providers.apache.bash.operators.bash, airflow.providers.postgres.hooks.postgres). Gói apache-airflow-providers-standard chứa nhiều toán tử và hook phổ biến trước đây nằm trong core.
• Các Cờ/Lệnh/Đối số CLI Cụ thể: Một số cờ và lệnh CLI không còn được hỗ trợ hoặc đã bị loại bỏ, ví dụ như đối số --subdir (-S) đã bị thay thế bởi cơ chế DAG bundles. Tham khảo ghi chú phát hành để biết danh sách đầy đủ.
• Các Khóa Cấu hình: Một số khóa cấu hình trong airflow.cfg đã bị loại bỏ, ví dụ: [core] store_dag_code, [scheduler] allow_trigger_in_future, [scheduler] use_job_schedule.

Các Deprecation Chính (Vẫn tồn tại nhưng sẽ bị loại bỏ sau)

• Tham số DAG schedule_interval và timetable: Hai tham số này không còn được dùng nữa và được thay thế bằng một trường schedule thống nhất, có thể chấp nhận cron expression, timedelta, timetable object, hoặc danh sách các asset. Mặc dù vẫn hoạt động trong 3.0 với cảnh báo deprecation, người dùng nên chuyển sang sử dụng schedule.

Thay Đổi Hành Vi

• xcom_pull: Khi lấy XCom theo key, giờ đây bắt buộc phải cung cấp task_ids. (Lưu ý: Có một thay đổi tạm thời về kiểu trả về cho task_ids đơn lẻ trong 3.0.0, được hoàn nguyên trong 3.0.1 ).
• catchup_by_default: Giá trị mặc định cho tham số DAG này đã thay đổi thành False. Các DAG không chỉ định rõ ràng catchup=True sẽ không tự động chạy các lần chạy bị bỏ lỡ trong quá khứ.
• Kích hoạt DAG qua REST API: Điểm cuối POST /dags/{dag_id}/dagRuns giờ đây mặc định logical_date=None nếu không được cung cấp, thay vì tính toán ngày logic dựa trên lịch trình.
• Yêu cầu Standalone DAG Processor: Như đã đề cập, việc chạy một quy trình xử lý DAG riêng biệt là bắt buộc.
• Xử lý Teardown Task khi DAG bị dừng: Các tác vụ teardown giờ đây sẽ được thực thi ngay cả khi DAG run bị dừng sớm (ví dụ: do lỗi hoặc can thiệp thủ công).

Bảng: Tóm Tắt Các Thay Đổi Gây Gián Đoạn/Loại Bỏ Chính Trong Airflow 3.0

Export to Sheets

Việc xem xét kỹ lưỡng bảng này và các ghi chú phát hành chi tiết là bước đầu tiên cần thiết cho bất kỳ kế hoạch nâng cấp nào lên Airflow 3.0.

Hướng Dẫn Di Chuyển Từng Bước Lên Airflow 3.0

Quá trình nâng cấp từ Airflow 2.x lên 3.0 đòi hỏi sự chuẩn bị cẩn thận do có những thay đổi kiến trúc và các thay đổi gây gián đoạn. Hướng dẫn này dựa trên tài liệu chính thức và ghi chú phát hành , cung cấp các bước cần thiết. Luôn thực hiện và kiểm thử kỹ lưỡng trong môi trường staging trước khi áp dụng cho sản xuất.

Bước 1: Đảm bảo các Điều kiện Tiên quyết

• Phiên bản Airflow Hiện tại: Đảm bảo bạn đang chạy Airflow phiên bản 2.7 trở lên. Việc nâng cấp trực tiếp từ các phiên bản cũ hơn không được hỗ trợ.
• Phiên bản Python: Xác minh rằng môi trường Python của bạn nằm trong phạm vi được hỗ trợ cho Airflow 3.0.0, tức là Python 3.9, 3.10, 3.11, hoặc 3.12.
• Xử lý Các Loại bỏ/Deprecation: Xem lại danh sách các tính năng bị loại bỏ và không còn được hỗ trợ trong Phần VI. Giải quyết các vấn đề liên quan trong môi trường Airflow 2.x hiện tại của bạn trước khi bắt đầu nâng cấp (ví dụ: thay thế SubDAGs, cập nhật các biến context không dùng nữa).

Bước 2: Sao lưu và Dọn dẹp

• Sao lưu Cơ sở dữ liệu Metadata: Đây là bước bắt buộc. Tạo một bản sao lưu đầy đủ của cơ sở dữ liệu metadata Airflow trước khi thực hiện bất kỳ thay đổi nào.
  • Nếu không có khả năng sao lưu nóng (hot backup), hãy dừng tất cả các thành phần Airflow (Scheduler, Webserver, Workers) trước khi sao lưu để đảm bảo tính nhất quán dữ liệu.
  • Việc có bản sao lưu là rất quan trọng để có thể khôi phục lại trạng thái cũ nếu quá trình nâng cấp gặp sự cố.
• Dọn dẹp Cơ sở dữ liệu Metadata (Khuyến nghị): Chạy lệnh airflow db clean để loại bỏ các bản ghi cũ không cần thiết (ví dụ: dữ liệu XCom cũ, lịch sử chạy DAG). Việc này có thể giúp tăng tốc đáng kể quá trình di chuyển schema trong Bước 6 và làm cho quá trình nâng cấp an toàn hơn.
• Kiểm tra Lỗi Phân tích DAG: Đảm bảo không có lỗi nào trong quá trình xử lý DAG. Chạy lệnh airflow dags reserialize và xác nhận nó hoàn thành mà không có lỗi. Nếu có lỗi, hãy sửa chúng trong môi trường 2.x, triển khai thay đổi và đợi cho đến khi tất cả DAG được xử lý lại và không còn lỗi trước khi tiếp tục.

Bước 3: Kiểm tra Tính tương thích DAG (Dành cho Tác giả DAG)

• Sử dụng Công cụ Kiểm tra Ruff: Airflow cung cấp một công cụ dựa trên linter(https://docs.astral.sh/ruff/) để giúp xác định các mẫu mã không tương thích trong DAG của bạn.
• Cài đặt Ruff: Đảm bảo bạn đã cài đặt Ruff phiên bản 0.11.6 trở lên.
• Cập nhật Thủ công: Công cụ Ruff không thể phát hiện hoặc sửa tất cả các vấn đề. Tác giả DAG cần tự mình thực hiện các cập nhật sau:
  • Imports: Thay đổi các import cốt lõi để sử dụng airflow.sdk (cho @dag, @task, DAG) và các đường dẫn provider đầy đủ cho operators, hooks, sensors (ví dụ: airflow.providers.*).
  • Tham số schedule: Thay thế schedule_interval và timetable bằng tham số schedule thống nhất.
  • Biến Context: Thay thế các biến context đã bị loại bỏ bằng các biến mới tương đương.
  • SubDAGs: Loại bỏ hoàn toàn việc sử dụng SubDAGs và thay thế bằng TaskGroups.
  • XComs: Đảm bảo tất cả dữ liệu được truyền qua XComs là JSON-serializable.

Áp dụng Sửa lỗi Tự động: Ruff có thể tự động sửa một số vấn đề. Sử dụng lệnh:Bash

ruff check dag/ --select AIR301 --fix

Xem trước Sửa lỗi: Để xem các đề xuất sửa lỗi tự động từ Ruff:Bash

ruff check dag/ --select AIR301 --show-fixes

Chạy Kiểm tra: Thực thi lệnh sau trong terminal, thay thế dag/ bằng đường dẫn đến thư mục chứa các tệp DAG của bạn:Bash

ruff check dag/ --select AIR301

Lệnh này sẽ báo cáo các vấn đề tương thích liên quan đến Airflow 3 (quy tắc AIR301).

Bước 4: Cập nhật Cấu hình

Áp dụng Cập nhật Cấu hình: Để công cụ tự động cập nhật cấu hình cho tương thích với Airflow 3:Bash

airflow config update --fix

Luôn xem lại các thay đổi đã được áp dụng. Đặc biệt chú ý đến cấu hình auth_manager nếu bạn đang sử dụng xác thực tùy chỉnh hoặc muốn tiếp tục dùng FAB.

Chạy Công cụ Cập nhật Cấu hình: Sử dụng lệnh CLI để kiểm tra tệp airflow.cfg của bạn:Bash

airflow config update

Bước 5: Quản lý Phụ thuộc

Cài đặt Provider FAB (Nếu cần): Nếu bạn cần sử dụng xác thực FAB hoặc các plugin UI dựa trên FAB, hãy cài đặt provider FAB:Bash

pip install "apache-airflow[apache-airflow-providers-flask-appbuilder]==3.0.0" --constraint <constraints-file-url>

Đồng thời, đảm bảo cấu hình auth_manager trong airflow.cfg được đặt thành airflow.providers.fab.auth_manager.fab_auth_manager.FabAuthManager.

Cài đặt Airflow 3 và Providers Chuẩn: Nâng cấp gói Airflow lên phiên bản 3.0.0 và đảm bảo gói apache-airflow-providers-standard được cài đặt. Cách đơn giản là cài đặt bằng extras:Bash

pip install "apache-airflow[apache-airflow-providers-standard]==3.0.0" --constraint <constraints-file-url>

Thay thế <constraints-file-url> bằng URL tệp constraints phù hợp với phiên bản Airflow và Python của bạn.

Bước 6: Di chuyển Cơ sở dữ liệu

Chạy Lệnh Migrate: Sau khi cài đặt Airflow 3.0 và cập nhật cấu hình, chạy lệnh di chuyển schema cơ sở dữ liệu:Bash

airflow db migrate

Quá trình này có thể mất một khoảng thời gian tùy thuộc vào kích thước và lịch sử của cơ sở dữ liệu của bạn.

Bước 7: Cập nhật Quy trình Khởi động

• Kiến trúc mới yêu cầu khởi động các thành phần một cách tường minh. Cập nhật các script triển khai hoặc cấu hình dịch vụ của bạn để sử dụng các lệnh sau:
  • airflow api-server (Thay thế chức năng cốt lõi của airflow webserver cũ)
  • airflow scheduler
  • airflow dag-processor (Bắt buộc phải chạy riêng)
  • airflow worker hoặc airflow celery worker hoặc airflow kubernetes worker-run hoặc airflow edge worker (Tùy thuộc vào executor bạn sử dụng)

Bước 8: Kiểm thử (Testing)

• Đây là bước cực kỳ quan trọng. Sau khi hoàn thành các bước kỹ thuật, hãy thực hiện kiểm thử toàn diện trong môi trường staging:
  • Kiểm tra xem tất cả các DAG có được phân tích cú pháp và hiển thị đúng trong UI không.
  • Chạy thử các DAG quan trọng để đảm bảo chúng hoạt động như mong đợi.
  • Kiểm tra chức năng của UI mới, bao gồm DAG Versioning, Backfills, Assets.
  • Xác minh các kết nối (Connections) và tích hợp (Integrations) vẫn hoạt động.
  • Kiểm tra hiệu năng và mức tiêu thụ tài nguyên.
• Chỉ tiến hành nâng cấp môi trường sản xuất sau khi đã hoàn toàn hài lòng với kết quả kiểm thử trong staging.

Nhìn Về Phía Trước: Lộ Trình Airflow 3.x

Airflow 3.0 đặt nền móng vững chắc cho sự phát triển trong tương lai, với một lộ trình tập trung vào việc mở rộng khả năng và hoàn thiện các tính năng mới.

SDK Đa ngôn ngữ cho Tác vụ

Một trong những mục tiêu chiến lược quan trọng nhất của Airflow 3 là trở thành một nền tảng điều phối độc lập ngôn ngữ. Task Execution API trong 3.0 là bước đầu tiên. Lộ trình tiếp theo bao gồm việc phát hành các Task SDK cho các ngôn ngữ khác ngoài Python.

• Go: SDK cho Go được dự kiến là SDK đa ngôn ngữ đầu tiên được phát hành sau Python.
• Java và Ngôn ngữ khác: Java và các ngôn ngữ phổ biến khác cũng nằm trong kế hoạch mở rộng.
• Tác động: Điều này sẽ cho phép các nhóm phát triển sử dụng các stack công nghệ đa dạng (ví dụ: Java, Scala, Go, Typescript) tích hợp trực tiếp các quy trình công việc của họ vào Airflow mà không cần các lớp bao bọc (wrapper) bằng Python phức tạp. Nó hiện thực hóa lời hứa "chạy bằng bất kỳ ngôn ngữ nào".

Tiếp Tục Phát Triển và Hoàn Thiện

Airflow là một dự án mã nguồn mở sôi động, và phiên bản 3.x sẽ tiếp tục được phát triển dựa trên phản hồi từ cộng đồng. Các tính năng mới được giới thiệu trong 3.0 sẽ được tinh chỉnh và mở rộng.

• Phản hồi Cộng đồng: Các kênh như danh sách gửi thư dành cho nhà phát triển (dev mailing list), Slack và GitHub issues là nơi cộng đồng có thể đóng góp ý kiến và báo cáo vấn đề. GitHub issue theo dõi việc phát hành Airflow 3 là một điểm tập trung cho các thảo luận liên quan.
• Tính năng Tương lai: Các tính năng như "Deadline Alerts" để thay thế SLAs đã được đề cập. Các cải tiến khác về khả năng gỡ lỗi và trải nghiệm tác giả DAG cũng đang được xem xét.

Cải Tiến Edge Executor

Tài liệu của provider Edge Executor chỉ ra một số lĩnh vực cải tiến được lên kế hoạch :

• Bảo mật: Token API riêng cho từng worker thay vì token toàn cục.
• Giao tiếp: Sử dụng WebSockets thay vì HTTP calls để cải thiện hiệu quả.
• Giám sát và Telemetry: Tích hợp tốt hơn với hệ thống telemetry, gửi số liệu hệ thống (CPU, Disk, RAM) từ các worker tại biên.
• Khả năng mở rộng: Kiểm tra và xác định rõ hơn giới hạn về số lượng worker/job.
• Triển khai: Cung cấp thêm tài liệu, script và hỗ trợ Helm Chart/Docker Compose để cài đặt và quản lý worker tại biên dễ dàng hơn.

Sự phát triển liên tục này, đặc biệt là việc hỗ trợ đa ngôn ngữ và kiến trúc API-driven, đang định vị lại Airflow. Thay vì chỉ là một công cụ điều phối quy trình công việc tập trung vào Python, Airflow đang chuyển mình thành một nền tảng điều phối rộng lớn hơn. Task Execution API trừu tượng hóa môi trường thực thi, và các SDK đa ngôn ngữ cho phép các nhóm công nghệ khác nhau tích hợp liền mạch vào hệ sinh thái Airflow. Điều này mở rộng đáng kể phạm vi áp dụng của Airflow, từ các nhóm kỹ thuật dữ liệu truyền thống sang các nhóm phát triển phần mềm và MLOps rộng lớn hơn. Lộ trình 3.x cho thấy một định hướng chiến lược nhằm biến Airflow thành một trung tâm điều phối trung tâm, có khả năng quản lý các quy trình công việc đa dạng trên toàn bộ stack công nghệ của một tổ chức.

Nói tóm lại

Apache Airflow 3.0 thực sự là một bản cập nhật "sweetdream" của Data Engineer, đại diện cho bước nhảy vọt lớn nhất của dự án trong nhiều năm. Được thúc đẩy bởi sự tái thiết kế kiến trúc nền tảng, phiên bản này giới thiệu một loạt các khả năng mới và cải tiến đáng kể so với Airflow 2.x.

Các tiến bộ cốt lõi bao gồm Task Execution API và SDK, mở ra cánh cửa cho việc thực thi tác vụ linh hoạt, từ xa, tại biên và hỗ trợ đa ngôn ngữ trong tương lai. Các tính năng được cộng đồng mong đợi từ lâu như DAG Versioning và Scheduler-Managed Backfills đã được hiện thực hóa, giải quyết những điểm yếu cố hữu và cải thiện đáng kể khả năng kiểm toán, gỡ lỗi và quản lý quy trình công việc. Sự phát triển từ Datasets thành Data Assets, cùng với cú pháp @asset và cơ chế Watchers, đã nâng cao đáng kể khả năng lập lịch dựa trên sự kiện, cho phép xây dựng các đường ống dữ liệu phản ứng và hiệu quả hơn. Giao diện người dùng được viết lại hoàn toàn bằng React/FastAPI không chỉ mang lại trải nghiệm hiện đại, nhanh nhạy hơn mà còn tạo nền tảng cho khả năng mở rộng trong tương lai. Hơn nữa, việc hỗ trợ gốc cho các luồng công việc ML/AI thông qua việc loại bỏ ràng buộc ngày logic duy nhất cho thấy sự thích ứng của Airflow với các mô hình dữ liệu hiện đại.

Những nâng cấp này mang lại giá trị to lớn cho người dùng. Khả năng sử dụng được cải thiện rõ rệt, giúp giảm thời gian phát triển và gỡ lỗi. Khả năng mở rộng và độ tin cậy của hệ thống được tăng cường nhờ kiến trúc tách biệt và các cải tiến trong Scheduler. Bảo mật được nâng cao thông qua việc cô lập tác vụ tốt hơn và các mô hình triển khai linh hoạt. Nhìn chung, Airflow 3.0 cung cấp một nền tảng mạnh mẽ, linh hoạt và phù hợp hơn với các thực tiễn dữ liệu và AI hiện đại.

Tuy nhiên, việc nâng cấp lên Airflow 3.0 đòi hỏi sự chuẩn bị kỹ lưỡng do có những thay đổi gây gián đoạn đáng kể và việc loại bỏ một số tính năng cũ. Các tổ chức cần đánh giá cẩn thận các thay đổi này, sử dụng các công cụ kiểm tra tương thích được cung cấp và thực hiện kiểm thử đầy đủ trong môi trường staging trước khi triển khai vào sản xuất.

Tóm lại, Apache Airflow 3.0 củng cố vị thế của mình là một trong những công cụ điều phối quy trình công việc mã nguồn mở hàng đầu. Đây là một bản nâng cấp hấp dẫn cho các tổ chức đang tìm cách hiện đại hóa khả năng điều phối dữ liệu của mình, mang lại một nền tảng mạnh mẽ và linh hoạt hơn để đối mặt với những thách thức của kỷ nguyên dữ liệu và AI.