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

**URL:** <https://discuss.dataengineercafe.io/t/airflow-framework/818>\
**Category:** Airflow\
**Tags:** airflow, data-pipeline, data-engineering\
**Created:** [November 7, 2025, 12:06pm UTC](https://discuss.dataengineercafe.io/t/airflow-framework/818 "2025-11-07T12:06:53Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![ChanAndKlee](https://yyz1.discourse-cdn.com/flex035/user_avatar/discuss.dataengineercafe.io/chanandklee/32/1231_2.png) [@ChanAndKlee](https://discuss.dataengineercafe.io/u/ChanAndKlee)\
**Post date:** [November 7, 2025, 12:06pm UTC](https://discuss.dataengineercafe.io/t/airflow-framework/818/1 "2025-11-07T12:06:53Z")

</div>

ตอนนี้ทางทีมกำลังออกแบบ **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 นั้น

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

[Framework Folder Structure.pdf](https://discuss.dataengineercafe.io/uploads/short-url/304OWbzuxCGPTda3E46KRAnyCWB.pdf) (300.1 KB)

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

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

---

<div class="post-metadata">

**Author:** ![kahnwong](https://yyz1.discourse-cdn.com/flex035/user_avatar/discuss.dataengineercafe.io/kahnwong/32/295_2.png) [@kahnwong](https://discuss.dataengineercafe.io/u/kahnwong)\
**Post date:** [November 8, 2025, 8:56am UTC](https://discuss.dataengineercafe.io/t/airflow-framework/818/2 "2025-11-08T08:56:18Z")

</div>

เป็น 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 เร็วเกินแล้วต้องมาผ่าตัดตอนหลัง อันนี้ก็จะไม่ค่อยสนุกเท่าไหร่

---

<div class="post-metadata">

**Author:** ![ChanAndKlee](https://yyz1.discourse-cdn.com/flex035/user_avatar/discuss.dataengineercafe.io/chanandklee/32/1231_2.png) [@ChanAndKlee](https://discuss.dataengineercafe.io/u/ChanAndKlee)\
**Post date:** [November 8, 2025, 3:01pm UTC](https://discuss.dataengineercafe.io/t/airflow-framework/818/3 "2025-11-08T15:01:20Z")

</div>

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

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

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

---

<div class="post-metadata">

**Author:** ![zkan](https://yyz1.discourse-cdn.com/flex035/user_avatar/discuss.dataengineercafe.io/zkan/32/2_2.png) [@zkan](https://discuss.dataengineercafe.io/u/zkan)\
**Post date:** [November 10, 2025, 1:46am UTC](https://discuss.dataengineercafe.io/t/airflow-framework/818/4 "2025-11-10T01:46:07Z")

</div>

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

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

> [@ChanAndKlee](#):
>
> \*\ ***Remark:** อย่างไรก็ตาม จากภาพนี้ได้ลองนำไปใช้แล้วเหมือนจะไม่มี error ขึ้นในหน้า Airflow UI , แต่ว่าไม่มี DAG ขึ้น เลยไม่แน่ใจว่าอาจมีข้อจำกัด หรือตกหล่นในส่วนไหนไปมั้ยคะ 🥲

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

```yaml
PYTHONPATH=/framework

```

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

> [@ChanAndKlee](#):
>
> PS. หากท่านใดมีข้อเสนอแนะเกี่ยวกับ design/concern หรือพูดคุยเพิ่มเติมในส่วนไหน ยินดีมากๆ เลยค่ะ 🥹

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

> **[Stop naming your python modules “utils”](https://breadcrumbscollector.tech/stop-naming-your-python-modules-utils/)**
>
> Imagine the following situation: there is a software developer that is either adding new code or refactoring existing one by extracting a class/function. They have to place code somewhere, but it does not seem to fit anywhere. So what does a...

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

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