zkan
1
เป็นภาพ quick start ที่พี่ Marc Lamberti (ตอนนี้เป็น Head of Customer Education ที่ Astronomer) ทำออกมาเอาไว้ดูแบบไวๆ
ผมดูแล้วชอบเพราะว่าเค้าอธิบายส่วนหลักๆ ของ DAG ไว้ และมีตัวอย่างการเขียน task แบบใช้ TaskFlow API กับแบบ Operator เทียบกัน
และที่สำคัญคือส่วน DAG Scheduling ที่ใช้ data_interval_start กับ data_interval_end ที่เป็นคอนเซปใหม่ที่เข้ามาในเวอร์ชั่น 2.2.0 
2 Likes
การเขียน task โดยใช้ TaskFlow API กับแบบ Operator มีข้อดีข้อเสีย หรือคนส่วนใหญ่นิยมใช้แบบไหนบ้างครับ
zkan
3
อันนี้ผมตอบตามประสบการณ์ + ความคิดเห็นส่วนตัวผมนะครับ 
ซึ่งถ้าใครแวะมาอ่าน สามารถมาร่วมวงพูดคุยกันได้นะๆ
TaskFlow API
ข้อดี
ถ้าเราเป็นสายเขียนโค้ด ตรงนี้จะทำให้เราเขียนโค้ดเป็นแบบ plain Python แล้วเราก็สามารถทำให้โค้ด DAG ของเราจะดู clean กว่าแบบ Operator ครับ เช่น เราสามารถเขียนโค้ดในลักษณะนี้ได้ครับ
raw_data = extract(data_source)
transformed_data = transform(raw_data)
load(transformed_data)
ข้อเสีย
- เนื่องจากว่าเราเขียนโค้ดเป็น plain Python เลย แน่นอนว่า engineering practices ต่างๆ ควรต้องนำเอามาใช้ครับ ไม่งั้นแทนที่เราจะได้ clean DAG เราอาจจะได้ messy DAG โดยไม่ได้ตั้งใจ ฮ่าๆ
- ฟังก์ชั่นต่างๆ เราเป็นคน implement ขึ้นมาเองครับ อาจจะเขียนเองใหม่หมดเลย หรือจะเรียกใช้ library ที่เราติดตั้งเพิ่มเติมอะไรแบบนี้ ตรงนี้ผมมองว่าเป็นข้อเสียนะ มันมีโอกาสที่เราจะไม่ได้ reuse ของที่ community ทำไว้ กลายเป็นว่าเรา reinvent the wheel ไป
Operator
ข้อดี
- Operator มีให้เลือกใช้เยอะมากครับ จาก Airflow community เวลาที่เราใช้เราก็มั่นใจได้ว่ามันสามารถใช้ได้จริงๆ เราไม่ต้องเขียนโค้ดเอง ติดตั้งแล้ว เรียกใช้ได้เลย และใน community เค้าจะบอกว่า พยายามใช้ Airflow Operator ที่มีอยู่แล้ว ก่อนที่จะเขียนเองขึ้นมาใหม่
- ผมมองว่าตรงนี้ user-friendly กว่าแบบ TaskFlow API ซึ่งคนส่วนใหญ่ในสายงาน data เค้าสามารถมาอ่านโค้ด DAG ของเรา แล้วพอเข้าใจว่าตรงไหนทำอะไร มี learning curve ที่ต่ำกว่า ตรงนี้เอาจริงๆ แบบ TaskFlow API ก็ทำให้โค้ดอ่านได้นะครับ แต่อย่างที่เกริ่นไว้ด้านบนคือ เราต้องมี engineering practices ที่ดีพอสมควรก่อน
ข้อเสีย
- Operator หลายๆ อันทำออกมาให้มีความ general ดังนั้น ถ้าเรามี use case ที่เจาะจงหน่อย ตัว Operator จะเริ่มไม่ตอบโจทย์แล้ว
- การใช้ Operator เราจะไม่เห็นโค้ดแบบที่เขียนไว้ในข้อดีของ TaskFlow API ครับ มันจะไม่ใช่แบบ output จาก task หนึ่ง ไปเป็น input ของอีก task หนึ่งอะไรแบบนั้น (pipeline) ถ้าเราอยากจะเห็นว่า task ไหนรับ input อะไร เราต้องดูว่า task นั้นๆ มีการดึงข้อมูลจาก XComs อะไรบ้าง ซึ่งตรงจุดนี้ TaskFlow API เค้า wrap ในส่วนนี้ไว้แล้ว ทำให้เราอ่านโค้ด เสมือนกับว่าเป็น pipeline จริงๆ
จากคำตอบด้านบน ผมยังเชื่อว่าคนส่วนใหญ่ใช้แบบ Operator ครับผม แล้วก็เราสามารถเขียน custom operator ขึ้นมาเพื่อ wrap ฟังก์ชั่นของเราได้ ซึ่งคนส่วนใหญ่ก็ทำแบบนี้ แต่ละทีมมี operator ของตัวเอง จะได้ reuse ได้
ตอนนี้นึกออกประมาณนี้ครับ เดี๋ยวถ้ามีอะไรเพิ่มเติม ผมมาพิมพ์เพิ่มให้ 
1 Like
