Airflow Là Gì

Một phiên bảo cron tab (chạy từng ngày, từng tuần, từng giờ từng tháng) cùng với UI xịn xò.Các tín đồ dùng data thường được sử dụng để viết ETL (Extract Transform Load) jobVí dụ như là select vào rows tự MySQLThêm ít các gia vị (Cooking)Load vào Datawarehouse

1 phút quảng cáo

các bạn đang ước muốn tìm kiếm thời cơ mới bạn muốn làm câu hỏi với những technology big data buổi tối tân nhất. Xài serveless tốn nhát quá với lờ đờ chạp, chúng ta cũng có thể tự build và publish mang lại hơn 500 bạn bè TIKI xài.Đến tức thì với team data nhé: JD phía trên nè (Hoặc gởi CV vào mail bản thân hien.pham2
tiki.vn ) mới vào nghề #

Team Data Platform của Tiki áp dụng Apache Airflow từ đa số ngày đầu lập team từ năm 2017. Mang đến tới bây giờ kiến trúc & cách thực hiện airflow cũng biến hóa khá đáng kể. Bài viết này sẽ chia sẽ biện pháp mà Team Data của dụng airflow, ưu nhược điểm của những cách dùng.

Bạn đang xem: Airflow là gì

Ngày xửa ngày xưa.

Khi bản thân vào TIKI vào T9/2018, một lần được đến vào con airflow chính, một giải pháp ngây thơ updates 1 packages.

# TLDR:# virtualenv python 2 & airflow 1.8pip install --upgrade pandas-gbqsupervisorctl restart allexitSau kia tắt sản phẩm công nghệ đi ngủ, tới chiều bạn bè ping nhau, Airflow ra đi rồi những bác ạ, Rì pọt ra đi hết rồi ông giáo ạ. Nghe ngừng tè ra quần luôn.

Mistakes:

Không backup virtualenv trước khi run pip install dân cày tập thành cloud #

1 năm tiếp theo (T9/2019)

Thời điểm đó TIKI migrate tự Data Center lên (GCP) Google Cloud Platform. Nỗ lực là phải sẵn sàng bưng khối hệ thống một lần nữa.

Ở thời điểm này có 3 con airflow đã chạy:

1 nhỏ chạy jobs ETL (Airflow 1.8)1 bé chạy sync snapshot trường đoản cú MySQL/Postgres lên BigQuery (Airflow 1.8)

Nghĩ, giờ đồng hồ lên cloud nhưng xài technology out date thì nông dân quá. Quyết trung ương chơi phệ cài airflow latest luôn. DAG thì chắc chỉ việc copy qua là xong, không tan vỡ gì âu.

Được cấp 1 nhỏ VM mới trên GCP và ssh vào pip install liền.

Đang chờ thì từ tát mẫu bếp. Học Infras As Code những thứ rồi và lại tay chân thế. Thế là ngồi viết ansible để tải airflow =)). Pip install thì vài ba phút, ngồi viết mất vài ba tiếng.

Copy dag nào thì dags kia vỡ

Phát chỉ ra là import path & params đã chuyển đổi khá những từ 1.8 lên 1.10. (Lúc này còn thơ ngây mà)Hành ngập phương diện rồi, vẻ bên ngoài này migrate vững chắc tới tết, vào khi bạn bè lúc này còn 15 ngày nhằm cutdown.

Ngồi nghĩ về nghĩ, mếu được, thay này sau này kiểu gì cũng sẽ gặp mặt case tương tự.

Lúc này sau 1 thời gian được tập luyện ansible với tập làm cho văn kubernetes manifests bước đầu có ý tưởng phát minh chế 1 yaml nhằm viết config & build nó thành dag.

Xem bài viết nà

TLDR:

Mình viết thêm 1 lớp nhằm set mặc định (giá trị khoác định của các field), thương hiệu Operator ngắn gọn logic thay vì phải import 1 path nhiều năm ngoằn.Tự rượu cồn phân quyền cho dag, alert callback vào slack/telegram khi dag failed.Mỗi team có 1 folder riêng rẽ trong git hoặc ưng ý thì đến hăn luôn 1 git repo riêng.

Tiếp theo là giờ sẽ deploy nơi đâu đây?

Tuy là nông dân nhưng lại vẫn cực kỳ thích đú trend Cờ lâu nây típ (Cloud Native) nỗ lực là bắt tay vào phân tích để điều khiển xe trên kubernetes luôn.

CeleryExecutor: có sẵn helm chart airflow để cài. Tuy vậy lại gặp vấn đề là chúng ta phải chế tạo trước workers & việc auto scale cũng không dễ ợt gì.KubernetesExecutor: bao gồm thể tự động tạo Pod nhằm run task mà không cần thiết phải tạo worker trước. Nếu như executor này kết cùng với với autoscaler & Preemtible Pool của gke thì tuyệt đối hoàn hảo ông mặt zời. Chốt cấp tốc chốt nhanh.

Nghiên cứu giúp vài này thì cũng bắt đầu vào kiến tạo & hợp tác vào viết k8s manifest.

Những tiêu chí khi deploy airflow bên trên k8s.

Phải máu kiệm: bằng phương pháp tự scale node khi phải (điều này thì autoscalercủa gke đã có tác dụng rất tốt.

Với gần như yêu mong như trên thì mình kiến thiết các deployment riêng rẽ như sau:

Scheduler: core của toàn khối hệ thống nên phải rất là stable, yêu cầu mình đưa ra quyết định chọn node standard. (Core bị tiêu diệt thì cậu vàng cũng phải phân phối đi mới mua bánh mì nạp năng lượng được).Pod được tạo thành từ airflow scheduler bản thân set mặc định chạy qua preemtible pool (tiết tìm tiền để mua bánh mì) & tất nhiên là bao gồm hidden option nhằm select node không giống khi cần.

Về docker image: Thời điểm đó airflow chưa xuất hiện official image cùng community docker vẫn còn đấy thiếu nhiều thứ. Mình đưa ra quyết định viết riêng rẽ 1 dockerfile và đưa vào những dependencies cần thiết đủ nhằm airflow chạy được.

Sau khi đủ các nguyên liệu thì ban đầu lên trang bị thôi.

Xem thêm: Tại Sao Bị Tê Chân ? Nguyên Nhân Và Triệu Chứng Thường Gặp

*

Ngoài phương pháp deploy airflow thì còn những việc sau đề xuất giải quyết

Cost Saving vs Stable

Để bảo đảm an toàn task chạy định hình trên Preemtible VM, rất cần phải bật tự động hóa retry đến toàn dag trên hệ thống (việc này cực kì đơn giản nhờ vào config engine).

Lưu tệp tin yaml ngơi nghỉ đâu?

Việc thực hiện 1 file config riêng, mình hoàn toàn có thể support một bối cảnh để viết config hoặc fancy rộng là kéo thả.Nhưng nghĩ về đi suy nghĩ lại thì build 1 UI như vậy khá tốn thời hạn & lại tạo ra thêm cần handle conflict khi nhiều người dân cùng sửa 1 dag.Vì vậy mình đã force mọi người dùng Git. Code yaml sẽ tiến hành sync vào deployment Dag Importer, tại chỗ này yaml sẽ được validate và convert thành python DAG file. Sau thời điểm có tệp tin DAG, tới vấn đề tiếp theo.

Lưu dag ngơi nghỉ đâu?

Lưu thẳng trong images: tất cả nhược điểm là phải build image liên tục khi có đổi khác → cực nhọc optimize được Pod startup time do phải kiểm tra Pull Image. Build docker có 1 nhược điểm là tương đối chậm.Lưu sống Shared Stores: hiện gại Persistent Disk của gke chưa support Read Write Many , vấn đề này dẫn cho phải sử dụng NFS. IOPS của NFS cực kì thấp đối với SSD.Việc lựa chọn storage nào nhờ vào rất những vào phong cách xây dựng của airflow: Sau khi phân tích 1 hồi thì mình phân biệt là airflow sẽ serialized dag vào database, webserver & những worker đều đọc trường đoản cú database này.

⇒ bởi vì vậy mình lựa chọn shared storages: không ảnh hưởng nhiều tới thời gian chạy task, 1 điểm mạnh nữa là nó dễ dàng hơn architect của hệ thống.

Logging như thế nào?

Khi lên kubernetes option đề nghị là phải lựa chọn một remote logging (cụ thể thì mình chọn gcs nhằm lưu)Nhưng remote logging gặp phải vụ việc là không xem được lúc task sẽ chạy.Dẫn đến mình đề xuất workaround bằng phương pháp sử dụng 1 file system tạm để lưu logs của task đang chạy. Còn đuờng nào ngoại trừ NFS nữa đâu.

Authentication và Authorization

Mình lý thuyết build Airflow biến hóa 1 open platform, mọi tín đồ đều hoàn toàn có thể viết config & chạy. Đối với lý thuyết như vậy, cần phải phân quyền thật kỹ càng & tốt nhất có thể là nghỉ ngơi DAG level.Cũng khá may là airflow support Oauth2 và cả access ngơi nghỉ DAG level.Việc này trở cần khá dễ dàng và đơn giản khi mà config system đã địa chỉ cửa hàng sẵn DAG vào mỗi role.

Monitor & Alerting

Với khối hệ thống config thì mình đã tự động hóa gắn sẵn task_failed_callback. mỗi team đang đuợc tạo thành 1 connection riêng biệt (có thể là slack/telegram) & lúc failed thì dag bên ai nấy nhận & tự đi check.

Backfill dags như thế nào?

Ngày trước loại trên VM thì giỏi ssh vào server nhằm chạy airflow backfill.Còn trên k8s thì ssh đâu mà vào. Vào pod để execute thì này lại bị limit sinh hoạt vài các bạn engineer.

Vài cảm nhận:

NFS everywhere.Nói là Preemtible VM tuy vậy mình cảm thấy là hơi là stable, sau 2 năm sử dụng thì bản thân chưa gặp vấn đề gì quá rộng (Có thể do kiến thiết system pro thừa nên không xẩy ra lỗi :">)Lâu lâu có vài task chạy hơn 5h bị down, so với những task này, mình question ngược lại tại sao nó lại chạy lâu vắt →optimize DAG.Đối cùng với Data Scientist Team: bản thân white menu cho viết hẵn Python code luôn, mang lại select node xịn để chạy. Chớ mã sản phẩm train cũng không còn nữa ngày.Khi chạy airflow trên K8S thì Airflow không thể đơn thuần là chỉ ETL nữa, mà hoàn toàn có thể chạy hầu hết thứ, thanks KubernetesPodOperator.Việc này vừa bảo vệ tính ổn định định, không nên phải add những trang bị không quan trọng vào base images sẽ tốn time nhằm pull → sút startup time. Airflow 2 #

Sau rộng 8h tháng delay thì quyết trung tâm làm 1 lần sau cuối.

Lên list những câu hỏi cần làm:

Coi ngày: chọn ngày tốt mới dám nâng cấp (check xemngay.com)Làm theo upgrade guides: https://airflow.apache.org/docs/apache-airflow/stable/upgrading-to-2.htmlLên airflow 1.10.15Install backport provider & update module_path vào cái operators (đơn giản là update vào config của operator alias).Generate pod_template_fileRun airflow upgrade_check và fix. Đa số lỗi mình chạm mặt đến từ những DAG viết bởi python của team Data Scientist. Không hề cách nào khác là cần đi fix tay từng dag, cũng khá may là khoảng không đến 20 dags.

Sau lúc lên bridges và chọn đuợc ngày lành mon tốt. Bắt đầu upgrade airflow 2. Ở tiki thì phần nhiều DAG được chạy vào đêm tối & buổi sáng. Riêng buổi chiều & tối thì vô cùng ít. Thời gian vàng là đây.

Backup Metadata DB: Viết vai trung phong thư gửi anh em system nhằm lỡ mà vấn đề không thành, vẫn còn đấy đừong quay về nhà.

Scale Down tất cả services: Scheduler, WebServer, ImportDags

Merge Pull Request nhằm Build & Deploy.

Start 1 replica WebServer, execute bash và run: airflow db tăng cấp vừa ngồi vừa nghe nhạc để tự trấn an mình =)), chớ lúc này cũng teo hết những thứ rồi.

Đợi khoàng nửa tiếng thì migrate run xong. Mình bắt đầu lên web ui để chất vấn xem tất cả bị vỡ vạc gì không. Thấy mọi thứ có vẻ như ổn.

Scale scheduler lên 1 replica. Thấy DAG mếu chạy, bước đầu xanh cmn mặt.

Không run được bởi vì entrypoint vào docker đang đuợc địa chỉ cửa hàng sẵn airflow command. Sau đó args lại địa chỉ thêm airflow nữa.

Sau lúc fix lỗi command thì thấy DAG bắt đầu chạy: đi kiểm tra một vòng thì phần nhiều DAG chạy ok, có một số lỗi vặt khá dị:

env_vars của KubernetesPodOperator tự động hóa nhận diện mẫu env bắt đầu bằng / thành template tệp tin → dẫn mang lại start pod lỗi.Bug nhọ tuyệt nhất là admin không được edit user permissions nữa. Buộc phải ngồi đợi bạn dạng fix tiếp theo sau thôi.Logging: không hề sử dụng connection_id để lấy logging credention đến gcs mà yêu cầu mount credential vào pod.Một vài lỗi bé dại khác do áp dụng internal function của airflow.

Vài cảm nhận về Airflow 2:

Performance tăng khủng khiếp: lúc số lựợng DAG tăng lên từ vài ba trăm lên nhanh đạt gần 2000, một vấn đề rất lớn gặp phải đối với airflow một là thời gian delay giữa những task trong dag khôn cùng lớn. Yêu cầu mất tự 5 - 15p giữa các task & thời hạn start DAG delay khoàng 5 phút so với giờ được set. Khi lên version 2 thì gần như là về 0. Điều này cực kì có ý nghĩa đối với các task chạy từng 1 hoặc 2 phút.UI mới nhìn đẹp hơn hẵn & thực tiễn là người nào cũng khen (chê xấu là disable tài khoản nhé).Việc nâng cấp lần này êm rộng hẵn đối với dự tính của chính mình là hoàn toàn có thể không lên đượcVì mình tìm tòi qua các lần tăng cấp trước, vỡ không hề ít chổ tóm lại #

Còn chờ đón gì nhưng không lên airflow 2 ngay và thôi.Mình vẫn upgrade thành công xuất sắc bạn cũng thế. Với nhớ coi ngày trước khi upgrade nha.

1 phút quảng cáo

bạn đang ước muốn tìm kiếm thời cơ mới bạn muốn làm việc với những công nghệ big data tối tân nhất. Xài serveless tốn nhát quá với chậm chạp chạp, bạn cũng có thể tự build & publish mang lại hơn 500 bằng hữu TIKI xài.Đến tức thì với team data nhé: JD trên đây nè (Hoặc giữ hộ CV vào mail bản thân hien.pham2