1. Introduction workflow of MLOps
Pipeline: là một chuỗi quy trình (workflow) nhằm điều phối (orchestrate) các tác vụ độc lập hoặc có mối quan hệ phụ thuộc lẫn nhau (task dependencies).
Workflow of MLOps
Quy trình workflow của MLOps:
→ Thu thập/tiền xử lý dữ liệu
→ lưu trữ
→ thử nghiệm & huấn luyện
→ đăng ký phiên bản model (MLflow)
→ CI/CD/GitOps đẩy model
→ phục vụ suy luận (serving)
→ giám sát (Prometheus/Grafana)
→ phản hồi để tái huấn luyện
Vòng đời của một dự án ML.
Data pipeline
Training pipeline
Serving pipeline
Monito pipeline
Các cách quản lý pipeline:
- Cron: https://viblo.asia/p/cron-job-la-gi-huong-dan-su-dung-cron-tab-E375zLo2ZGW Cơ bản là một lệnh cron job sẽ có 2 thành phần chính là: schedule và command.
* * * * * /bin/sh clear.sh
- Bash/Python scripts:
Nhược điểm
Khi pipeline trở nên phức tạp, nhiều bước, nhiều nhánh, và các tác vụ phụ thuộc lẫn nhau thì việc dùng Cron hoặc các script thủ công bộc lộ nhiều hạn chế:
- Lack of dependency management
- Lack of operational visibility
- Poor scalability and maintainability
Trước những hạn chế đó, Apache Airflow ra đời như một giải pháp điều phối (orchestration solution) mạnh mẽ, nhằm khắc phục các vấn đề tồn tại trong việc quản lý và vận hành data pipelines truyền thống.
2. Apache AirFlow
Todolist
Work Flow của một MLops (data pipeline, ML, monitor,…)
Quiz
Directed Acyclic Graph
Trong Airflow, DAG là tập hợp các task với quan hệ phụ thuộc có hướng và không chu trình, đảm bảo luồng thực thi không lặp vòng.
D. Scheduler
Scheduler quét thư mục DAG, phân tích DAG, xác định TaskInstance đến hạn và đẩy chúng vào hàng đợi (gửi cho Executor) để thực thi. Metadata database chỉ lưu trạng thái/siêu dữ liệu; Webserver cung cấp UI; Executor là thành phần thực thi task.
A. XComs
XComs cho phép các task push/pull các mẩu dữ liệu nhỏ (JSON-serializable) qua DB metadata. Variables dùng cho cấu hình toàn cục; Macros chỉ là hàm/biến Jinja khi render template; “Metadata” không phải cơ chế trao đổi trực tiếp.
B. task_A >> task_B.
Toán tử bitshift đặt phụ thuộc: A upstream của B. (task_B << task_A cũng đúng nhưng ít dùng hơn.)
B — Một datetime cố định trong quá khứ.
Không dùng now() /lambda hay chuỗi; start_date phải bất biến để lập lịch và catchup chính xác.
D — Cách thức và nơi task được thực thi.
Executor quyết định chạy cục bộ/hàng đợi/nhiều worker (Local/Celery/Kubernetes…).
A — Task hôm nay sẽ không được lên lịch cho tới khi task của hôm qua chạy thành công.
depends_on_past=True yêu cầu instance hôm trước phải success.
A — Khi tất cả upstream đã hoàn thành (bất kể success/failed).
all_done kích hoạt miễn là upstream kết thúc.
A — one_success.
Join vẫn chạy khi có ít nhất một upstream success (A success, B skipped), nhưng sẽ không chạy nếu không có upstream nào success (ví dụ decide_path failed làm A và B không chạy).
B — upstream_failed.
Vì B failed, C (mặc định all_success) không chạy và bị gán trạng thái upstream_failed.