ปรึกษาเรื่องการออกแบบ Airflow Framework

พูดคุยเกี่ยวกับ Data Tools ต่าง ๆ Airflow
, ,
1

ตอนนี้ทางทีมกำลังออกแบบ Airflow Framework เพื่อให้สามารถสร้าง pipeline ได้อย่างเป็นระบบและลดการเขียนโค้ดซ้ำ โดยแนวคิดหลักคือการใช้ template + config-driven design เพื่อรองรับ pattern ของงานที่คล้ายกัน เช่น

  • การดึงข้อมูลจาก SharePoint → BigQuery,

  • การดึงข้อมูลจาก PostgreSQL → BigQuery,

  • หรือ pipeline ที่มีรูปแบบซ้ำกันในหลาย table/files

แทนที่จะต้องสร้าง DAG หลายไฟล์ ทีมต้องการให้สามารถเพิ่มข้อมูลการตั้งค่า (config) เช่น file name, site URL, destination table ฯลฯ ไว้ในไฟล์ config เดียว แล้วให้ระบบสามารถ auto-generate DAGs ได้อัตโนมัติจาก config นั้น

:open_file_folder: มีแนบไฟล์ที่ร่างคร่าวๆ ของ Framework Folder Structure ค่ะ ว่าแต่ละส่วนจะมีการจัดวางไฟล์ยังไงค่ะ

Framework Folder Structure.pdf (300.1 KB)

**Remark: อย่างไรก็ตาม จากภาพนี้ได้ลองนำไปใช้แล้วเหมือนจะไม่มี error ขึ้นในหน้า Airflow UI , แต่ว่าไม่มี DAG ขึ้น เลยไม่แน่ใจว่าอาจมีข้อจำกัด หรือตกหล่นในส่วนไหนไปมั้ยคะ :smiling_face_with_tear:

PS. หากท่านใดมีข้อเสนอแนะเกี่ยวกับ design/concern หรือพูดคุยเพิ่มเติมในส่วนไหน ยินดีมากๆ เลยค่ะ :face_holding_back_tears: , ขอบคุณล่วงหน้ามา ณ ที่นี้ด้วยนะคะ :folded_hands:

2 Likes
2

เป็น initiative ที่ดี แต่จากประสบการณ์ที่เจอมา จะแนะนำแบบนี้

  • ไปทำ common utils / functions ที่เอาไว้ ingest/write จะเหมาะกว่า เพราะใช้งานได้คล่องตัวกว่า และสามารถเทสนอก airflow ได้ เพราะถ้ามัดทุกอย่างเข้ากับ airflow dag แปลว่า เวลาเทส มันจะติดกันเป็นก้อน ทำให้เจาะแต่ละส่วนยากเวลาต้อง debug
  • ไม่ค่อยแนะนำท่า dag generation เท่าไหร่ ยกเว้นจำเป็นจริงๆ เพราะเวลาแหวกไส้ออกมาดู จะวุ่นวายมาก เพราะต้องไปไล่รื้อแต่ละชั้น ว่าพันทับกันมาที่ตลบ ถ้าต้องทำจริงๆ ก็ทำได้ แต่ไม่แนะนำให้ nested ซ้อนกันเกินสองชั้น
  • มันจะมีเคสที่ บางทีตอนทำตอนแรก parameters ทุกอย่างก็ abstract ไว้แล้ว ก็ไม่มีปัญหา แต่ระหว่างทาง ต้องงอก parameters เพิ่ม แล้วเจอว่าบางอันต้อง custom ด้วย ถ้ามัดกับ dag generator ไว้แล้ว ก็ต้องไปรื้อเพราะหาทางเจาะเพื่อที่จะส่งค่าเข้าไปข้างในได้ อันนี้ก็จะวุ่นวายหน่อย

เพราะฉะนั้น สรุปสั้นๆ คือ จะแนะนำให้ทำเป็น custom libs/utils แล้วเอา dag ปกติมาครอบ แล้วใช้ไปซักปีนึง แล้วดูว่า อะไรที่มัน abstract ได้บ้าง ไม่งั้นจะกลายเป็น abstract เร็วเกินแล้วต้องมาผ่าตัดตอนหลัง อันนี้ก็จะไม่ค่อยสนุกเท่าไหร่

3 Likes
3

ขอบคุณมากๆ เลยค่ะสำหรับ feedback เห็นด้วยเลยค่ะว่าถ้าแยกเป็น common utils / functions จะช่วยให้เทสและ debug ได้ง่ายขึ้น (เคยเจอเคส SharePoint authentication แล้วต้องไล่แก้หลายที่เหมือนกัน :smiling_face_with_tear: )

ตอนแรกตั้งใจว่าจะลองใช้ DAG generation เพื่อจัดการ pipeline ที่มี pattern คล้ายกันหลายตัว แต่พออ่านที่แชร์มาก็เห็นภาพเลยค่ะ โดยเฉพาะเรื่อง parameter ที่อาจต้องขยายในอนาคต กับ ความซับซ้อนในการ identify เวลามีปัญหาเกิดขึ้น

เดี๋ยวยังไงจะลองแยกเป็น common functions ก่อน แล้วให้ DAG มาเรียกใช้ไปก่อนนะคะ แล้วค่อยดูอีกทีว่าพอมีส่วนไหนยังเพิ่มเติมหรือปรับปรุงได้อีกบ้าง ยังไงขอบคุณอีกครั้งมากๆ เลยนะคะสำหรับคำแนะนำ :heart_eyes: :folded_hands:

4

อันนี้เห็นด้วยเลยครับ เสริมว่ามีปัจจัยอื่น ๆ ที่ควรคิดเพิ่มเติมคือเรื่อง knowledge ของทีม / เวลามีคนใหม่เข้าทีมมา ท่า DAG generation (dynamically) จะต้องใช้เวลาทำความเข้าใจเยอะหน่อย ควรต้องมีเอกสารอธิบายไว้เพิ่มครับ แล้วก็จะเหมาะกับในส่วนที่ simple จริง ๆ (เช่น คนในทีม 80% อ่านโค้ดแล้วไม่ต้องคิด) ไม่ต้องมี configuration เยอะ (เช่น มีจำนวน parameters ไม่เกิน 5) แล้วก็มีงานแบบนี้เยอะ ต้องทำซ้ำ ๆ กันเป็น (เช่น ingest จากหลาย ๆ data sources แบบเดียวกัน เกิน 15+)

เดาเบื้องต้นนะครับ มีความเป็นไปได้ที่ Airflow จะไม่เห็นโฟลเดอร์ /framework อาจจะลองเพิ่ม path ของโฟลเดอร์นี้ไว้ใน environment variable ที่ชื่อ PYTHONPATH ครับ ประมาณนี้

PYTHONPATH=/framework

ถ้าใช้ Docker Compose ก็เพิ่มตรงคีย์ environment

เรื่อง design ที่ทำมา มีเป็น concern จุดหนึ่ง ที่อาจจะเป็นปัญหาได้ในอนาคตนะครับ หรืออาจจะไม่ได้มีปัญหาก็ได้ :laughing: เรื่องการจัดโฟลเดอร์ชื่อ common หรือ utils นะครับ ควรระวังว่าเวลาเราตั้งชื่อกว้าง ๆ แบบนี้ จะทำให้เรามีโอกาสเผลอได้ในตอนที่เราพัฒนาของใหม่ ๆ ขึ้นมาแล้วนึกไม่ออกว่าจะตั้งชื่อว่าอะไร ก็จะเอาไปใส่ไว้ใน common หรือ utils ก่อน แล้วจะทำให้โฟลเดอร์นี้บวมได้ ลองอ่านบทความด้านล่างนี้เพิ่มเติมครับ

วิธีปรับที่ผมใช้อยู่ตอนนี้คือแบ่งเป็น biz domain และตามการใช้งานตามจุดประสงค์นั้น ๆ จริง ๆ ซึ่งการแบ่งแบบนี้ ถ้าเรารีบแบ่งตั้งแต่ต้นก็อาจจะทำให้ design ที่เราวางไว้เละได้เช่นกัน

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