อธิบาย Apache Airflow: คู่มือสำหรับผู้เริ่มต้น

บทนำ

บริษัทสมัยใหม่ที่ขับเคลื่อนด้วยข้อมูลทั้งหมดต่างก็พึ่งพาท่อข้อมูลที่ดึงข้อมูล แปลงข้อมูล เติมเต็ม และย้ายข้อมูลจากที่หนึ่งไปยังอีกที่หนึ่ง ท่อข้อมูลเหล่านี้อาจประกอบด้วยหลายขั้นตอน (เช่น การดึงข้อมูลดิบ ทำความสะอาดข้อมูล ฝึกโมเดลแมชชีนเลิร์นนิง สร้างแดชบอร์ด เป็นต้น) นอกจากนี้ ขั้นตอนเหล่านี้ยังต้องทำงานตามลำดับที่เฉพาะเจาะจง เครื่องมือจัดการเวิร์กโฟลว์ เช่น Apache Airflow ช่วยให้มั่นใจว่าทุกขั้นตอนทำงานในเวลาที่เหมาะสมและตามลำดับที่ถูกต้อง และยังทำให้ท่อข้อมูลสามารถติดตามและจัดการได้ง่าย

Airflow ถูกสร้างขึ้นที่ Airbnb ในปี 2014 และได้กลายเป็นหนึ่งในแพลตฟอร์มการประสานงานเวิร์กโฟลว์แบบโอเพ่นซอร์สที่ได้รับความนิยมมากที่สุด ถูกใช้โดยองค์กรหลายพันแห่งเพื่อทำให้กระบวนการแบทช์อัตโนมัติและติดตามผล ในบทความนี้ เราจะอธิบาย Apache Airflow ตั้งแต่พื้นฐาน หัวข้อที่เราจะครอบคลุมได้แก่:

• Airflow คืออะไร ทำงานอย่างไร และทำไมทีมข้อมูลถึงใช้มัน
• แนวคิดและองค์ประกอบหลักของ Airflow และวิธีที่พวกมันทำงานร่วมกัน
• การกำหนดท่อส่งข้อมูลให้เป็นกราฟแบบไม่เป็นวงจรที่มีทิศทาง (DAG) และการสาธิตการทำงานของ DAG ง่าย ๆ
• กรณีการใช้งานทั่วไป เช่น ETL/ELT, MLOps และอื่น ๆ

เราหวังว่านี่จะเป็นบทนำที่เน้นตัวอย่างเชิงปฏิบัติของ Apache Airflow สำหรับวิศวกร นักเรียน และทีมงานที่เริ่มต้นกับการจัดการเวิร์กโฟลว์

ประเด็นสำคัญ

• Apache Airflow เป็นแพลตฟอร์มการจัดการเวิร์กโฟลว์ที่ใช้ภาษา Python ซึ่งจัดการ กำหนดเวลา และติดตามท่อข้อมูลที่ซับซ้อนโดยใช้ DAGs (Directed Acyclic Graphs)
• DAGs กำหนดงานและความสัมพันธ์ระหว่างงาน ทำให้ Airflow สามารถดำเนินแต่ละขั้นตอนตามลำดับที่ถูกต้อง พร้อมกับการลองซ้ำ การบันทึก และการสังเกตการณ์ในตัว
• สถาปัตยกรรมของ Airflow (Scheduler, Executor, Worker, Metadata DB, Web UI) ช่วยให้สามารถรันงานแบบกระจายและปรับขนาดได้ พร้อมทั้งติดตามการทำงานของ pipeline แบบเรียลไทม์
• Airflow มีความโดดเด่นในเวิร์กโฟลว์แบบแบทช์ เช่น งาน ETL/ELT, พายป์ไลน์การฝึก ML, การตรวจสอบคุณภาพข้อมูล และการวิเคราะห์ตามตารางเวลา — แต่ ไม่เหมาะสำหรับงานเรียลไทม์หรือความถี่สูงมาก
• ทางเลือกอย่าง Prefect, Dagster, Luigi, Argo Workflows, และ Mage AI อาจเหมาะสมมากกว่า ขึ้นอยู่กับความต้องการ เช่น เวิร์กโฟลว์แบบขับเคลื่อนด้วยเหตุการณ์ การทำงานใน Kubernetes โดยตรง หรืออินเทอร์เฟซที่เป็นมิตรต่อผู้พัฒนาสมัยใหม่

Apache Airflow คืออะไร?

Apache Airflow เป็นระบบโอเพ่นซอร์สสำหรับการสร้าง กำหนดเวลา และติดตามเวิร์กโฟลว์ เวิร์กโฟลว์ของ Airflow เป็น DAG (กราฟแบบไม่เป็นวงจรที่มีทิศทาง) ซึ่งเป็นชุดของงานที่มีความสัมพันธ์ที่ชัดเจน (การพึ่งพา) และไม่มีรอบ (งานไม่สามารถทำซ้ำตัวเองในทิศทางย้อนกลับได้) ปรัชญาหลักของ Airflow คือ “การกำหนดค่าผ่านโค้ด” ดังนั้นแทนที่จะใช้ UI พร้อมอินเทอร์เฟซลากและวาง คุณจะสร้างสคริปต์ Python เพื่อแทนเวิร์กโฟลว์ วิธีนี้ให้ความยืดหยุ่นมากสำหรับวิศวกร: คุณสามารถเชื่อมต่อกับเทคโนโลยีต่าง ๆ ผ่านตัวดำเนินการของ Airflow และไลบรารี Python คุณยังสามารถใช้แนวปฏิบัติที่ดีที่สุดของวิศวกรรมซอฟต์แวร์ (การควบคุมเวอร์ชัน การทดสอบ เป็นต้น) กับการกำหนดค่าสายงานของคุณได้อีกด้วย

ทำไมการประสานงานเวิร์กโฟลว์จึงสำคัญ?

ประเด็นสำคัญคือบ่อยครั้งคุณจะมีหลายขั้นตอนในกระบวนการทำงานของข้อมูลที่ต้องดำเนินการตามลำดับ ตัวอย่างง่าย ๆ คือสายงาน ETL (Extract/Transform/Load) สายงานสามารถซับซ้อนขึ้นได้อย่างรวดเร็วเมื่อคุณเพิ่มงาน ความสัมพันธ์ระหว่างงาน การแยกสาขา และอื่น ๆ และยังต้องทำงานตามรอบเวลา เครื่องมือการจัดการด้วยตนเองหรือเครื่องมือกำหนดเวลาง่าย ๆ มักไม่เพียงพอในกรณีเหล่านี้ Airflow จึงแก้ปัญหานี้โดยทำหน้าที่เป็นตัวประสานงานกลาง มันมีกราฟวงจรทวนทางเดียวแบบไม่มีทางวนซ้ำ (DAG) ของงาน (โหนด) พร้อมความสัมพันธ์ระหว่างงาน (เส้นเชื่อม) มันรู้ว่าเมื่อใดควรดำเนินการงานใด (รอให้ความสัมพันธ์ upstream เสร็จสิ้นก่อนเริ่มงาน) รวมถึงการกำหนดเวลา (การดำเนินการตามช่วงเวลาที่กำหนด) การจัดการข้อผิดพลาด (การลองใหม่อัตโนมัติ การแจ้งเตือน) และการบันทึกข้อมูล

ถ้าเราพิจารณาว่าทั้งชุดข้อมูลเป็นสูตรอาหาร งานแต่ละงานก็เหมือนขั้นตอนย่อย (เช่น การหั่น การต้ม การจัดจาน เป็นต้น) Airflow ก็เหมือนผู้จัดการห้องครัวที่รู้สูตรอาหารและคอยสอดส่องทุกขั้นตอนย่อยที่เกิดขึ้นในแต่ละครัว เพื่อให้แน่ใจว่าทุกอย่างเกิดขึ้นตามลำดับที่ถูกต้องและในเวลาที่เหมาะสม

หากปราศจากการจัดการเวิร์กโฟลว์ คุณอาจมีเชฟและส่วนผสมทั้งหมด แต่พวกเขาไม่ได้รับการประสานงาน Airflow ช่วยให้เกิดการประสานงานนั้น ทำให้สามารถสร้าง “เมนู” ที่ต้องการ (การทำงานของเวิร์กโฟลว์) ได้

ทำไมทีมข้อมูลจึงใช้ Airflow?

Airflow ได้รับความนิยมในหมู่นักวิศวกรข้อมูล, วิศวกร ML และทีม DevOps เนื่องจากมันตอบสนองความต้องการหลายประการของการสร้างท่อข้อมูลที่ซับซ้อน นี่คือเหตุผลใหญ่บางประการที่ทำให้ทีมเลือกใช้ Airflow:

• การประสานงานเวิร์กโฟลว์และความขึ้นต่อกันที่ซับซ้อน: Airflow ถูกออกแบบมาสำหรับเวิร์กโฟลว์ที่มีขั้นตอนที่ขึ้นต่อกันจำนวนมาก Airflow ทำให้การประกาศความต้องการระหว่างขั้นตอนต้นทางและปลายทางเป็นเรื่องง่าย เพื่อให้มั่นใจว่างานต่างๆ จะทำงานตามลำดับที่ถูกต้อง หากงาน C ขึ้นอยู่กับงาน A และ B ตัวจัดกำหนดการของ Airflow จะรับรู้ความสัมพันธ์เหล่านี้และจะทำให้แน่ใจว่า A และ B จะทำงาน (อาจทำงานพร้อมกัน) ก่อนที่จะทำงาน C Airflow สามารถจัดการกับความขึ้นต่อกันที่ซับซ้อน โลจิกการแยกสาขา เป็นต้น
• การกำหนดตารางแบบรวมศูนย์ (Cron แบบพิเศษ): มันให้ตัวจัดตารางที่ช่วยให้คุณสามารถเรียกใช้งานงานตามกำหนดเวลาที่กำหนดได้ คุณสามารถกำหนดท่อหรือโปรแกรมหลายสิบถึงหลายร้อยโปรแกรมที่เรียกใช้งานงานในเวลาที่ต่างกัน (รายชั่วโมง รายวัน รายเดือน) โดยใช้ตัวจัดตารางของ Airflow Airflow เข้าใจความสัมพันธ์ระหว่างงาน มันสามารถกำหนดตารางและเรียกใช้งานได้อย่างชาญฉลาด ตัวจัดตารางรวมศูนย์นี้ช่วยให้คุณไม่ต้องเขียนสคริปต์ต่าง ๆ บนเซิร์ฟเวอร์หลายเครื่อง

• ความสามารถในการปรับขนาดและการประมวลผลแบบกระจาย: Airflow สามารถปรับขนาดตามเวิร์กโฟลว์ของคุณได้เช่นกัน คุณสามารถกำหนดค่าให้ประมวลผลงานแบบคู่ขนานข้ามหลายกระบวนการหรือเครื่องงานได้ นอกจากนี้ยังมี executor หลายตัว (กล่าวถึงในภายหลังในบทความนี้) ที่สามารถรันงานบนระบบกระจาย เช่น Celery หรือ Kubernetes ข้ามคลัสเตอร์ของโหนด ซึ่งหมายความว่าคุณสามารถรันงานหนัก (การประมวลผลข้อมูลจำนวนมาก) แบบคู่ขนานและมีหลาย pipeline ทำงานพร้อมกันได้
• การตรวจสอบ การบันทึก และการแจ้งเตือน: มาพร้อมกับ UI เว็บที่มีความสามารถครบครัน ซึ่งให้คุณมองเห็นการทำงานของเวิร์กโฟลว์แบบเรียลไทม์ คุณสามารถดูว่า งานใดสำเร็จหรือล้มเหลว และดูผลลัพธ์จากบันทึกของแต่ละงานได้ คุณยังสามารถเรียกใช้งานหรือทำซ้ำงานผ่านอินเทอร์เฟซเว็บได้ด้วยตัวเอง

องค์ประกอบสำคัญของ Airflow

ด้านล่างนี้เป็นภาพรวมสั้น ๆ ขององค์ประกอบหลักของ Apache Airflow ใช้ตารางนี้เป็นการอ้างอิงอย่างรวดเร็วเพื่อทำความเข้าใจว่าแต่ละส่วนประกอบคืออะไรและทำหน้าที่อะไร

การทำงานของ Airflow (สถาปัตยกรรม)

นี่คือภาพรวมแบบทีละขั้นตอนของ วิธีที่ Airflow ประมวลผลเวิร์กโฟลว์ (DAG):

• การสร้าง DAG: ผู้เขียน DAG จะเขียนสคริปต์ Python ที่กำหนด DAG สคริปต์นี้รวมถึงสิ่งต่าง ๆ เช่น ตารางเวลา (เช่น “รันทุกวันเวลา 9 โมงเช้า”) หรือการตั้งค่าการทริกเกอร์ด้วยตนเอง นอกจากนี้ยังมีการกำหนดงานต่าง ๆ (ผ่านตัวดำเนินการหรือฟังก์ชัน @task) รวมถึงความสัมพันธ์ระหว่างงาน (เช่น task1 >> task2 (task2 จะรอให้ task1 เสร็จก่อน)) ไฟล์ Python นี้จะถูกบันทึกในโฟลเดอร์ DAGs ของ Airflow เพื่อให้ Airflow สามารถค้นหาได้ Airflow จะอ่าน (parse) ไฟล์นี้เป็นระยะเพื่อโหลดคำนิยามของ DAG
• การจัดตารางเวลาและการแยกวิเคราะห์ DAG: Airflow Scheduler เป็นกระบวนการที่ทำงานอย่างต่อเนื่องเบื้องหลัง มันตรวจสอบว่า DAG แต่ละตัวควรถูกดำเนินการตามตารางเวลาหรือทริกเกอร์หรือไม่ ตัวอย่างเช่น DAG ที่มีตารางเวลาเป็น “ทุกวัน” อาจถูกเลือกโดย scheduler และสังเกตว่าการรันใหม่ต้องถูกจัดตารางเวลาในเที่ยงคืน Airflow Scheduler ยังตรวจสอบด้วยว่างานภายใน DAG พร้อมที่จะรันหรือไม่ – หมายความว่าขึ้นอยู่กับงานก่อนหน้าเสร็จสมบูรณ์แล้วและเวลาที่กำหนด (วันที่เชิงตรรกะ) มาถึงแล้ว
• การดำเนินการงาน: งานแต่ละงานที่จะดำเนินการจะถูกส่งมอบให้กับตัวดำเนินการจากตัวจัดตาราง ตัวดำเนินการจะตัดสินใจว่าจะรันงานที่ไหนและอย่างไร ซึ่งอาจดำเนินการแบบท้องถิ่นหรือส่งไปยังคิวงานของผู้ทำงาน สำหรับสถาปัตยกรรมแบบกระจาย งานจะถูกเพิ่มลงในคิวแล้วถูกเลือกโดยกระบวนการ Worker ที่ดำเนินการงาน
• การอัปเดตสถานะ & การจัดการข้อผิดพลาด: แต่ละอินสแตนซ์ของงานจะรายงานสถานะของตนเอง (สำเร็จ, ล้มเหลว, ฯลฯ) กลับไปยังตัวกำหนดตารางเมื่อทำงานเสร็จ และตัวกำหนดตารางจะอัปเดตฐานข้อมูลเมตาดาต้าของมันด้วยสถานะของงาน
  การติดตามสถานะคือสิ่งที่ช่วยให้ตัวกำหนดตารางรู้ว่าต้องทำอะไรต่อไป – ตัวอย่างเช่น ถ้างาน A ทำงานสำเร็จแล้ว ระบบจะรู้ว่าสามารถกำหนดงาน B ได้ทันที หรือถ้างาน A ล้มเหลวแต่ยังมีจำนวนครั้งทดลองใหม่เหลืออยู่ ระบบจะกำหนดให้ลองทำใหม่ หรือถ้างานล้มเหลวแล้วไม่มีจำนวนครั้งทดลองใหม่เหลืออยู่ ระบบจะถือว่าการรัน DAG นั้นล้มเหลว หากงานล้มเหลว Airflow มีตรรกะในการลองทำงานนั้นอีกครั้งโดยอัตโนมัติหากได้ตั้งค่าการลองใหม่ไว้ หากงานยังคงล้มเหลวหลังจากการลองใหม่ Airflow สามารถเตือนความล้มเหลว (ส่งอีเมลหรือข้อความ Slack ฯลฯ) ทุกอย่างเหล่านี้สามารถตั้งค่าได้เป็นส่วนหนึ่งของพารามิเตอร์ DAG หรือพารามิเตอร์ของงาน (เช่น จำนวนครั้งในการลองใหม่, ระยะเวลาหน่วงก่อนลองใหม่, อีเมลที่ส่งเมื่อมีการเตือน).
• การติดตามและการแทรกแซง: Airflow Web UI ให้ส่วนต่อประสานแบบสดสำหรับกระบวนการข้างต้น คุณสามารถเห็นการทำงานของ DAG ปรากฏขึ้น (เช่น มีบรรทัดใหม่ในมุมมอง Tree สำหรับการทำงานในวันนี้) และดูสถานะของงานเปลี่ยนแปลงเมื่อมันดำเนินไป มุมมอง Graph จะแสดงภาพงานของ DAG และแสดงว่างานใดเสร็จสิ้นหรือเกิดข้อผิดพลาด
• การทำความสะอาดและรันครั้งถัดไป: เมื่อการรัน DAG เสร็จสิ้น (งานทั้งหมดสำเร็จหรือถูกข้าม/ล้มเหลว) Airflow จะดำเนินไปยังการรันตามกำหนดถัดไป ข้อมูลเมทาดาทาทั้งหมดเกี่ยวกับการรันที่ผ่านมา ยังคงถูกเก็บไว้ในฐานข้อมูล และคุณสามารถตรวจสอบประวัติได้เสมอ ตัวจัดการตารางเวลาจะยังคงกระตุ้นการรันใหม่ตามกำหนดหรือการกระตุ้นด้วยตนเอง กระบวนการนี้จะทำซ้ำไปจนกระทั่งกระบวนการ Airflow ถูกยกเลิก

ทำความเข้าใจ DAGs ใน Airflow

DAG ใน Airflow กำหนดตารางเวลา รวมถึงงานและความสัมพันธ์ที่จำเป็นในการดำเนินการ workflow DAG ไม่จำเป็นต้องทราบว่ามีอะไรอยู่ภายในแต่ละงาน เพียงแค่ต้องกำหนดว่าเมื่อใดและในลำดับใดที่งานเหล่านั้นควรถูกดำเนินการ

งาน ตัวดำเนินการ และเซ็นเซอร์

งาน (Tasks) เป็นหน่วยพื้นฐานของการทำงานใน Airflow ใน Airflow งานคืออินสแตนซ์ของตัวดำเนินการ (Operators) ซึ่งเป็นแม่แบบสำหรับการกระทำที่กำหนดไว้ล่วงหน้า Airflow มาพร้อมกับตัวดำเนินการหลักหลายแบบ BashOperator ช่วยให้คุณรันคำสั่งเชลล์ และ PythonOperator ช่วยให้คุณเรียกใช้ฟังก์ชัน Python นอกจากนี้ Airflow ยังมีตัวตกแต่ง @task ซึ่งช่วยให้คุณเปลี่ยนฟังก์ชัน Python ปกติให้เป็นงานได้

นอกจากตัวดำเนินการแล้ว Airflow ยังมีเซ็นเซอร์อีกด้วย เซ็นเซอร์คือภารกิจที่รอให้เงื่อนไขหรือเหตุการณ์สำเร็จก่อนที่มันจะสำเร็จ สามารถใช้สำหรับสิ่งต่าง ๆ เช่น การรอให้ไฟล์ปรากฏขึ้นหรือรอให้ตารางถูกเติมข้อมูล

ความขึ้นต่อกันของงาน

ในการประกาศความขึ้นต่อกันระหว่างงาน คุณสามารถใช้ตัวดำเนินการ >> และ << (แนะนำ) หรือวิธีการเช่น set_upstream และ set_downstream นอกจากนี้ยังสามารถเชื่อมโยงงาน สร้างความขึ้นต่อกันแบบข้ามลำดับ และแม้กระทั่งสร้างรายการงานแบบไดนามิก DAG ที่ไม่มีความขึ้นต่อกันใด ๆ จะเป็นเพียงชุดงานที่เป็นอิสระ

แนวทางปฏิบัติที่ดีที่สุดสำหรับการออกแบบ DAG

ตารางด้านล่างนำเสนอแนวทางบางประการที่ควรคำนึงถึงเมื่อออกแบบ DAG

ตัวอย่าง: DAG ของ Airflow ง่ายๆ

ไม่มีอะไรที่จะทำให้แนวคิดแน่นแฟ้นไปกว่าการยกตัวอย่าง มาเดินผ่านโค้ด Airflow DAG ง่าย ๆ และอธิบายส่วนต่าง ๆ ของมัน ตัวอย่างนี้จะสร้างเวิร์กโฟลว์ขนาดเล็กที่มีสองงานต่อกันเป็นลำดับ:

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

มาลองมาทำความเข้าใจกันว่าที่นี่เกิดอะไรขึ้น:

• นำเข้าคลาสที่จำเป็น DAG (เพื่อกำหนด DAG) และ BashOperator (เพื่อรันคำสั่งเชลล์/แบชในงาน) เรายังนำเข้า datetime สำหรับระบุวันที่เริ่มต้นของ DAG
• เราสร้างอ็อบเจ็กต์ DAG ด้วยตัวจัดการบริบท (with DAG(…) as dag:). กำหนด DAG ด้วย ID ที่ไม่ซ้ำกัน “example_dag” (ต้องไม่ซ้ำกันในสภาพแวดล้อม Airflow), คำอธิบาย (ไม่บังคับ, เพื่อช่วยให้คนอ่านเข้าใจ), start_date, และ schedule_interval. ที่นี่ เราได้ตั้ง schedule_interval preset (@daily) ที่มีมาให้แล้ว และ start_date=datetime(2025,1,1). เรายังได้ตั้งค่า catchup=False เพื่อป้องกันการเติมงานที่ขาดหายไประหว่าง start_date และวันนี้ (เราต้องการให้รันเพียงตั้งแต่ตอนนี้เป็นต้นไปทุกวัน). บล็อกทั้งหมดนี้สร้าง DAG ที่ Airflow จะรับรู้เพื่อให้รันทุกวันในช่วงต้นวัน.
• จากนั้นเราจะกำหนดงานสองงานในบริบทของ DAG:
• task1 ถูกกำหนดโดยใช้ BashOperator เพื่อรันคำสั่ง bash (date) task_id คือ “print_date” และจะถูกใช้เพื่อระบุงานนี้ใน UI และในบันทึก เมื่อรัน งานนี้ก็จะแสดงวันที่/เวลาปัจจุบัน (ลงในบันทึกของงาน)
• task2 ด้วย ใช้ BashOperator กับ task_id=“echo_hello ” และ command=echo ‘Hello, Airflow!’ ซึ่งจะพิมพ์ข้อความที่สวยงาม งานเหล่านี้ในตอนนี้ถูกกำหนดไว้แล้ว แต่ยังไม่ได้เชื่อมโยงกัน
• บรรทัดสุดท้าย (task1 >> task2) ระบุการขึ้นต่อกัน (flow) : task1 จะไหลไปยัง task2 ซึ่งหมายความว่า task1 จะทำงานและเสร็จสมบูรณ์ก่อนที่ task2 จะถูกพิจารณาเพื่อกำหนดเวลาการทำงาน ในเชิงกราฟิก ในกราฟ DAG จะมีลูกศรชี้จาก task1 ไปยัง task2

มีบางสิ่งที่ควรสังเกตในตัวอย่างนี้:

• เราใช้แค่ BashOperator เพื่อความง่าย แต่เราสามารถใช้ DAG ที่มีหลากหลายประเภทของ operators ก็ได้ เราสามารถมี PythonOperator เพื่อเรียกฟังก์ชัน Python หรือ SimpleHttpOperator เพื่อเรียก API เป็นต้น
• รูปแบบ context ของ with DAG(…) as dag: เป็นสำนวนที่นิยมใช้ในการสร้างอินสแตนซ์ DAG งานทั้งหมดที่สร้างขึ้นภายในนั้นจะถูกเชื่อมโยงกับ DAG นั้นโดยอัตโนมัติ
• catchup=False เป็นพารามิเตอร์ที่ใช้ใน DAG หลายตัวที่มี start_date ในอดีต เมื่อคุณไม่ต้องการให้มันรันสำหรับวันที่ผ่านมาแล้วทั้งหมด ถ้าเราเว้นค่า catchup=True (ค่าดีฟอลต์) และวันนี้คือ 10 มกราคม 2025 Airflow จะพยายามรัน DAG สำหรับวันที่ 1, 2, 3, … จนถึง 10 มกราคม เพื่อไล่รันวันที่พลาดไป เราปิดมันตรงนี้เพื่อความง่าย
• ตัวอย่างนี้ใช้เส้นทางการนำเข้าสัมพัทธ์สำหรับ BashOperator ใน Airflow 2 ตัวดำเนินการหลายตัวถูกย้ายไปอยู่ภายใต้ airflow.providers ตัวอย่างนี้เขียนโดยสมมติว่าผู้ให้บริการเหล่านั้นถูกติดตั้งแล้ว (BashOperator อยู่ใน Airflow แกนหลักเอง)

ตัวอย่างง่ายๆ นี้สามารถขยายเพิ่มเติมได้อย่างง่ายดาย – คุณอาจเพิ่มงานเพิ่มเติม (อาจจะทำการเรียก API จากนั้นโหลดผลลัพธ์ไปยังฐานข้อมูล แล้วส่งการแจ้งเตือน) คุณยังสามารถเพิ่มตรรกะที่ซับซ้อนมากขึ้นได้ (เช่น การแยกสาขา – Airflow รองรับการแยกสาขาสไตล์ if/else โดยใช้ BranchOperator ตัวอย่างเช่น)

เมื่อ DAG ของคุณมีขนาดใหญ่ขึ้น UI และการบันทึกของ Airflow จะมีค่าอย่างมากในการช่วยให้คุณเข้าใจสิ่งที่เกิดขึ้น ในตัวอย่างนี้ บันทึกของ print_date จะมีวันที่ของระบบที่ถูกพิมพ์ออกมา และบันทึกของ echo_hello จะมีข้อความ “Hello, Airflow!” หาก print_date ล้มเหลว (อาจเป็นเพราะไม่พบคำสั่ง date ในสถานการณ์สมมติ) echo_hello ก็จะไม่ถูกดำเนินการเลย (เนื่องจากมีการพึ่งพา) และการรัน DAG จะถูกระบุว่าล้มเหลว คุณจึงสามารถตรวจสอบบันทึก แก้ไขปัญหา และรันงานนั้นหรือ DAG ทั้งหมดใหม่ได้

กรณีการใช้งานทั่วไปของ Airflow

ด้านล่างนี้เป็นสรุปแบบมีโครงสร้างของกรณีการใช้งาน Apache Airflow ที่พบบ่อย ตารางนี้เน้นว่ากรณีการใช้งานแต่ละแบบเกี่ยวข้องกับอะไร และ Airflow เพิ่มคุณค่าในบริบทนั้นได้อย่างไร

เมื่อไม่ควรใช้ Airflow

แม้ว่า Airflow จะมีความสามารถสูง แต่ก็ไม่ใช่เครื่องมือที่เหมาะกับทุกสถานการณ์ การเข้าใจข้อจำกัดของมันจะช่วยให้คุณเลือกวิธีการจัดการงานที่ถูกต้องได้:

• งานเรียลไทม์หรือสตรีมมิ่ง: Airflow เป็นแบบการประมวลผลเป็นชุดที่มีจุดเริ่มต้นและสิ้นสุดชัดเจน ไม่เหมาะกับงานที่รันต่อเนื่อง ยาวนาน หรือขับเคลื่อนด้วยเหตุการณ์ หากคุณกำลังรับข้อมูลสตรีมต่อเนื่องของเหตุการณ์ (เช่น การคลิกของผู้ใช้ เซ็นเซอร์ IoT เป็นต้น) และต้องการประมวลผลด้วยความหน่วงต่ำในเวลาจริง Airflow จะไม่ใช่ตัวเลือกที่ดีที่สุด
• งานความถี่สูงหรือหลายงานสั้นๆ: นี่เป็นอีกกรณีหนึ่งที่ Airflow อาจไม่ทำงาน หรืออย่างน้อยก็ทำงานไม่ค่อยมีประสิทธิภาพ งานของ Airflow มีค่าใช้จ่ายบางส่วน (เช่น การติดตามในฐานข้อมูล ฯลฯ) ดังนั้นหากคุณต้องการเปิดใช้งานบางอย่างทุกไม่กี่วินาทีหรือมีงานเล็กๆ จำนวนมากหลายพันงาน Airflow อาจไม่สามารถปรับขนาดได้ดี
• เวิร์กโฟลว์ที่ขับเคลื่อนด้วยเหตุการณ์อย่างเดียว: นี่คล้ายกับกรณีการใช้งานสตรีมมิ่ง แต่สำหรับสิ่งที่ควรถูกกระตุ้นโดยเหตุการณ์ "ทุกครั้งที่เกิดเหตุการณ์ X ให้ทำ Y" เป็นกรณีการใช้งานที่เหมาะสมกับ Airflow อย่างสมบูรณ์ แต่ถ้าสิ่งเดียวที่ควรกระตุ้นนั้นคือเหตุการณ์ (เช่น "ทุกครั้งที่ไฟล์มาถึงใน S3 bucket ให้ทำ X") ดังนั้น Airflow อาจไม่ใช่โซลูชันที่เบาและเหมาะสมที่สุด Airflow โดยทั่วไปจะใช้เซ็นเซอร์ (เช่น S3KeySensor) เพื่อ "ตรวจสอบ" การมีอยู่ของไฟล์/เหตุการณ์ เซ็นเซอร์มีข้อเสียเพราะขึ้นอยู่กับการสืบค้น ปัญหากับเซ็นเซอร์รวมถึงการกระตุ้นจากไฟล์ที่มีอยู่แล้วและไม่จำเป็นต้องตอบสนองต่อเหตุการณ์ทันที (เช่น พวกมันสืบค้นในช่วงเวลาที่กำหนด)

โดยสรุปแล้ว Airflow เหมาะสำหรับเวิร์กโฟลว์ที่เป็นแบบเป็นระยะ ๆ, มุ่งเน้นการประมวลผลเป็นชุด, หรือซับซ้อนต่อการกำหนดและจัดการ ซึ่งอาจไม่เหมาะหากกรณีการใช้งานของคุณต้องการการประมวลผลแบบเรียลไทม์หรือต่อเนื่อง งานที่เกิดขึ้นบ่อยมาก ๆ หรือเวิร์กโฟลว์ที่เรียบง่ายมาก ๆ ที่ไม่ต้องการความซับซ้อนของ Airflow ในกรณีนั้น คุณอาจต้องพิจารณาตัวเลือกอื่น ๆ หรือทำให้โซลูชันของคุณเรียบง่ายขึ้น

ทางเลือกแทน Airflow

พื้นที่การจัดการกระบวนการทำงานได้เติบโตอย่างรวดเร็วในช่วงไม่กี่ปีที่ผ่านมา และแม้ว่า Airflow จะเป็นผู้นำ แต่ก็มี เครื่องมือทางเลือก หลายตัวที่ควรรู้จัก:

Airflow ไม่ใช่ตัวเลือกเดียวที่มีอยู่ และทางเลือกที่ดีที่สุดขึ้นอยู่กับกรณีการใช้งานของคุณ Luigi, Prefect และ Dagster มักถูกระบุว่าเป็นตัวเลือกโอเพนซอร์สหลักอื่น ๆ ในพื้นที่เดียวกัน (ตัวจัดการเวิร์กโฟลว์ที่ใช้ Python) หากคุณพบว่า UI ที่เก่าของ Airflow หรือข้อจำกัดอื่น ๆ เป็นเรื่องน่ารำคาญ คุณควรพิจารณาประเมินตัวเลือกเหล่านี้ Prefect พยายามเป็น Airflow ที่ “ดีกว่า” หรือ “เรียบง่ายกว่า”, Dagster พยายามเป็นตัวจัดการที่มีโครงสร้างมากขึ้นโดยเน้นที่ทรัพย์สินข้อมูล, และ Luigi เป็นรุ่นก่อนที่เรียบง่ายของ Airflow ในทางกลับกัน หากกรณีการใช้งานของคุณแตกต่างออกไปอย่างมาก (เช่น การสตรีมแบบเรียลไทม์หรือเป็นคลาวด์เนทีฟเต็มรูปแบบ) คุณอาจไม่ใช้ Airflow เลยและอาจพิจารณาแพลตฟอร์มสตรีมมิงหรือบริการจัดการเวิร์กโฟลว์โดยตรง

ข้อคิดสุดท้าย

Apache Airflow เป็นแพลตฟอร์มโอเพ่นซอร์สสำหรับจัดการเวิร์กโฟลว์การประมวลผลคอมพิวเตอร์ที่ซับซ้อนและสายงานการประมวลผลข้อมูล พัฒนาเดิมที่ Airbnb, มันได้รับความนิยมอย่างมากในชุมชนวิศวกรรมข้อมูลและการเรียนรู้ของเครื่อง ส่วนประกอบของ Airflow ประกอบด้วย ตัวจัดตารางงาน (scheduler), ตัวดำเนินการ (executor), ผู้ปฏิบัติงาน (workers), ฐานข้อมูลเมตาดาต้า และส่วนติดต่อผู้ใช้บนเว็บ (web-based UI) ซึ่งช่วยให้ทีมงานสามารถรันและดูแลสายงาน ETL, MLOps, และโครงสร้างพื้นฐานที่พร้อมใช้งานในสภาพการผลิตได้อย่างง่ายดาย การใช้นิยาม DAG (Directed Acyclic Graph) ของ Airflow ช่วยให้เวิร์กโฟลว์มีความชัดเจน สามารถทดสอบได้ และสามารถบำรุงรักษาได้ในระยะยาว ระบบนิเวศของแพลตฟอร์มที่ประกอบด้วยผู้ประกอบการและผู้ให้บริการที่สร้างโดยชุมชนยังช่วยทำให้งานการจัดการเวิร์กโฟลว์ที่ขึ้นอยู่กับเทคโนโลยีหรือเครื่องมือใด ๆ ทำได้ง่ายขึ้น

อย่างไรก็ตาม มันไม่ใช่วิธีแก้ปัญหาที่ใช้ได้กับทุกคน มันเหมาะที่สุดกับการประมวลผลแบบชุดหรือไมโครชุด และผู้ใช้ต้องมีความคุ้นเคยกับ Python สำหรับกระบวนการแบบสตรีมมิงหรือเวิร์กโฟลว์ที่มีความถี่สูง มีวิธีแก้ปัญหาอื่นที่เหมาะสมกว่า Airflow สำหรับนักวิทยาศาสตร์ข้อมูลหรือทีมที่ชอบเขียนพายป์ไลน์แบบประกาศ ควรพิจารณาเครื่องมืออื่น ๆ แทน Airflow

Airflow ยังคงได้รับการพัฒนาอย่างต่อเนื่อง และมีฟีเจอร์ใหม่ ๆ ถูกเพิ่มเข้ามาตลอดเวลา เช่น การจัดตารางงานตามเหตุการณ์, ชุดข้อมูล และทรัพย์สิน แนวคิดและแนวปฏิบัติที่ดีที่สุดที่นำเสนอในคู่มือนี้ควรช่วยให้คุณ เข้าใจการทำงานของการประสานงานเวิร์กโฟลว์ และเมื่อใดที่ควรใช้ (หรือไม่ควรใช้) Airflow หวังว่านี่จะเป็นขั้นตอนแรกเพื่อสำรวจจักรวาลอันหลากหลายนี้ต่อไป

เอกสารอ้างอิง

• อาปาเช่ แอร์ฟลโลว์
• Airflow คืออะไร?
• Apache Airflow: กรณีการใช้งาน สถาปัตยกรรม และ 6 เคล็ดลับสู่ความสำเร็จ
• คู่มือเริ่มต้นสำหรับ Airflow กับ Docker — การสร้าง Data Pipelines บนคลาวด์ (ตอนที่ 1)
• 8 ทางเลือกแทน Airflow - กรณีการใช้งาน
• ภาพรวมสถาปัตยกรรม
• ตัวจัดตารางเวลา

ขอบคุณที่เรียนรู้ร่วมกับชุมชน Linux-Console.net