ในบทความก่อนหน้าเรื่องเตรียม Infra รับ Odoo 20 เราพูดถึงว่า Odoo 20 อาจมี Native MCP Server ให้ในตัวสำหรับเชื่อมต่อกับ Agentic AI แต่สำหรับธุรกิจที่ต้องการวิเคราะห์ข้อมูลด้วย AI อยู่ตอนนี้ ไม่จำเป็นต้องรอ เพราะสามารถสร้าง data pipeline เชื่อม Odoo เข้ากับ AI ได้เองด้วยสถาปัตยกรรมที่ไม่กระทบ production เลย
บทความนี้เล่าจากประสบการณ์ตรงในการสร้างระบบ read-only data pipeline ให้ธุรกิจค้าปลีกมือถือรายใหญ่ที่มีหน้าร้านหลายร้อยสาขาทั่วประเทศ เพื่อให้ทีมธุรกิจและ AI analytics ดึงข้อมูลไปใช้ได้โดยไม่แตะฐานข้อมูล Odoo หลักที่ใช้งานจริงเลยแม้แต่ query เดียว
สรุปสั้น: สถาปัตยกรรมที่ใช้ได้จริงคือ 4 ชั้น — Odoo (source ข้อมูลจริง) → PostgreSQL Data Warehouse (ETL แยกต่างหาก) → API layer (FastAPI) → MCP Server (ให้ AI เรียกใช้งาน) แต่ละชั้นแยก workload ออกจากกันชัดเจน ทำให้ production Odoo ไม่ถูกกระทบไม่ว่า AI หรือ dashboard จะถูกเรียกใช้งานหนักแค่ไหน
ทำไมต้องแยก Pipeline ออกจาก Production Odoo
ข้อผิดพลาดที่พบบ่อยที่สุดคือการให้ AI หรือ BI tool ต่อ query ตรงเข้าฐานข้อมูล Odoo ที่ใช้งานจริง ซึ่งเสี่ยงสองเรื่อง คือ query วิเคราะห์ข้อมูลหนักๆ ไปแย่ง resource กับ transaction ของหน้าร้านที่ต้องการความเร็ว และการเปิดช่องให้ระบบภายนอกเข้าถึงข้อมูล production โดยตรงเป็นความเสี่ยงด้านความปลอดภัยที่ไม่จำเป็น การแยกเป็นสถาปัตยกรรมหลายชั้นแก้ปัญหาทั้งสองเรื่องพร้อมกัน
สถาปัตยกรรม 4 ชั้น
1. Odoo — แหล่งข้อมูลต้นทาง
ระบบ Odoo ทำหน้าที่เป็นแหล่งข้อมูลต้นทางเท่านั้น ไม่มีการเขียนกลับจากชั้นอื่นใดเข้ามาที่นี่เด็ดขาด (read-only โดยสมบูรณ์)
2. PostgreSQL Data Warehouse — ชั้น ETL
ข้อมูลจาก Odoo ถูกดึงมาเก็บใน PostgreSQL อีกตัวหนึ่งที่แยกออกมาเป็น Data Warehouse โดยเฉพาะ ทำให้ query วิเคราะห์หนักๆ ไม่กระทบ database การขายจริง ชั้นนี้คือจุดที่ควรเตรียมใจไว้ว่าจะเจอบั๊กแปลกๆ ที่ข้อมูลจริงเท่านั้นถึงจะเจอ (รายละเอียดในหัวข้อถัดไป)
3. API Layer (FastAPI)
วาง service กลางด้วย FastAPI ทำหน้าที่เป็นตัวกลางระหว่าง Data Warehouse กับผู้ใช้งานปลายทาง ควบคุมสิทธิ์การเข้าถึงข้อมูลและ rate limit ได้จากจุดเดียว
4. MCP Server — ชั้นที่ AI เรียกใช้งาน
ชั้นบนสุดคือ MCP Server ที่เปิด tool ให้ AI เรียกใช้งานข้อมูลได้แบบมีโครงสร้าง ในระบบที่เราสร้างมี tool แบบ read-only อยู่ราว 44 ตัว ครอบคลุมทั้งยอดขายหน้าร้าน การเปิดเบอร์/ซิม การจำแนกช่องทางชำระเงิน โปรโมชัน และเป้าหมายรายสาขา เป็นสถาปัตยกรรมเดียวกับแนวทางที่ Odoo 20 กำลังจะทำให้เป็นมาตรฐาน เพียงแต่เราสร้างเองตั้งแต่ก่อนที่ Odoo จะมีให้ในตัว
บทเรียนจากหน้างานจริง
บั๊ก Pagination ที่โผล่มาตอนข้อมูลมีหลักหมื่น Record
ช่วง ETL ข้อมูล POS order เกือบ 47,000 รายการ เราเจอปัญหาจำนวนแถวที่ดึงมาไม่ตรงกันทุกรอบ สาเหตุคือใช้ offset-based pagination ร่วมกับการเรียงตาม write_date ซึ่งมี record จำนวนมากที่ write_date เหมือนกันเป๊ะ (เพราะถูกประมวลผลเป็น batch เดียวกัน) ทำให้ตำแหน่งของ record ขยับไปมาระหว่างการดึงแต่ละหน้า วิธีแก้คือเปลี่ยนไปใช้ keyset pagination โดยเรียงตาม id แบบ ascending แทน ซึ่งรับประกันลำดับที่แน่นอนเสมอ บทเรียนนี้สำคัญมากสำหรับใครที่ทำ ETL จาก Odoo เพราะ pagination แบบ offset ดูเหมือนจะทำงานปกติตอนข้อมูลน้อย แต่จะพังแบบเงียบๆ เมื่อข้อมูลโตขึ้น
Tuning PostgreSQL สำหรับ Workload แบบผสม
เซิร์ฟเวอร์ที่ใช้รัน Data Warehouse มีสเปกไม่ได้ใหญ่มาก (4 vCPU / 8GB RAM) แต่ต้องรองรับทั้งงาน OLTP (รับข้อมูลเข้าต่อเนื่อง) และงาน analytical query (query หนักจาก dashboard และ AI) พร้อมกัน การ tune ที่ได้ผลคือรวม config ไว้ใน postgresql.conf ไฟล์เดียว ตั้ง shared_buffers ไว้ที่ 2GB, work_mem ที่ 20MB, ปรับ autovacuum ให้เหมาะกับ workload แบบ ETL ที่มีการเขียนข้อมูลเป็นรอบๆ และเปิด pg_stat_statements ไว้ตลอดเพื่อ monitor query ที่กินเวลานานผิดปกติ
คุณภาพข้อมูลสำคัญพอๆ กับความเร็ว
อีกบทเรียนหนึ่งคือ raw data จาก Odoo ไม่ได้พร้อมใช้วิเคราะห์เสมอไป ในเคสนี้ต้องกรอง partner บางประเภท (เช่นฝั่งการเงิน/สินเชื่อ) ออกจากตัวเลขยอดขายค้าปลีก ไม่เช่นนั้นตัวเลขจะเพี้ยน ขั้นตอนทำความสะอาดและจำแนกข้อมูลแบบนี้ควรทำที่ชั้น ETL ไม่ใช่ปล่อยให้ AI หรือ dashboard ต้องมาคิดเอง
เมื่อ Odoo 20 มี MCP Server ในตัว จะเปลี่ยนอะไร
ถ้า Odoo 20 มี Native MCP Server จริงตามที่ roadmap พูดถึง สิ่งที่เปลี่ยนไปน่าจะเป็นชั้นที่ 3-4 ของสถาปัตยกรรมนี้ (API layer และ MCP Server) ที่อาจไม่ต้องสร้างเองทั้งหมด แต่ชั้นที่ 2 (Data Warehouse แยกต่างหาก) ยังมีความจำเป็นอยู่ดีสำหรับองค์กรที่มีข้อมูลจำนวนมากและต้องการแยก workload วิเคราะห์ออกจาก production เพราะเป็นหลักการพื้นฐานด้าน database architecture ที่ไม่ได้ผูกกับ vendor ตัวไหนเป็นพิเศษ
เช็คลิสต์สำหรับองค์กรที่อยากเริ่มทำ
- อย่าให้ AI หรือ BI tool ต่อ query ตรงเข้า production database ของ Odoo เด็ดขาด
- ใช้ keyset pagination (เรียงตาม id) แทน offset pagination เมื่อทำ ETL ข้อมูลจำนวนมาก
- tune PostgreSQL ของ Data Warehouse แยกจาก Odoo database โดยเฉพาะ เพราะ workload ต่างกันโดยสิ้นเชิง
- ทำความสะอาดและจำแนกข้อมูลที่ชั้น ETL ไม่ใช่ปล่อยให้ AI ต้องตีความ raw data เอง
- ออกแบบ API layer ให้ควบคุมสิทธิ์การเข้าถึงข้อมูลได้จากจุดเดียว
คำถามที่พบบ่อย (FAQ)
ทำไมไม่ให้ AI ต่อเข้า Odoo database โดยตรงเลย ทำไมต้องมี Data Warehouse คั่น?
เพราะ query วิเคราะห์ข้อมูลหนักๆ จาก AI จะไปแย่ง resource กับ transaction การขายจริงที่ต้องการความเร็วสูง และการเปิดให้ระบบภายนอกเข้าถึง production database โดยตรงเป็นความเสี่ยงด้านความปลอดภัยที่ไม่จำเป็น การแยก Data Warehouse ออกมาช่วยแก้ทั้งสองปัญหา
Keyset Pagination กับ Offset Pagination ต่างกันอย่างไร?
Offset pagination ระบุตำแหน่งเริ่มดึงข้อมูลด้วยจำนวนแถวที่ข้าม ซึ่งจะผิดพลาดได้ถ้ามี record จำนวนมากที่ค่าที่ใช้เรียงลำดับเหมือนกัน ส่วน keyset pagination ใช้ค่าที่ไม่ซ้ำกันแน่นอนอย่าง id เป็นตัวอ้างอิง ทำให้ลำดับข้อมูลที่ดึงมาถูกต้องเสมอแม้ข้อมูลจะโตขึ้นแค่ไหน
ถ้า Odoo 20 มี MCP Server ในตัวแล้ว ยังต้องสร้าง Data Warehouse เองอยู่ไหม?
ยังจำเป็นอยู่สำหรับองค์กรที่มีข้อมูลจำนวนมากและต้องการแยก workload วิเคราะห์ออกจาก production เพราะเป็นหลักการพื้นฐานด้าน database architecture ที่ไม่ได้ขึ้นอยู่กับว่า Odoo จะมี MCP Server ในตัวหรือไม่ สิ่งที่ Odoo 20 อาจช่วยลดงานได้คือชั้น API และ MCP Server ด้านบน ไม่ใช่ชั้น Data Warehouse
องค์กรขนาดเล็กที่มีสาขาไม่กี่แห่ง จำเป็นต้องทำสถาปัตยกรรมนี้ไหม?
ถ้าข้อมูลยังไม่มาก อาจยังไม่จำเป็นต้องแยกครบทั้ง 4 ชั้น แต่ควรเริ่มจากหลักการพื้นฐานที่สุดก่อนคือไม่ให้ query วิเคราะห์ข้อมูลหนักๆ ไปกระทบ production database โดยตรง แล้วค่อยขยายสถาปัตยกรรมตามที่ข้อมูลและความต้องการเติบโตขึ้น