รวมข้อมูลแชท LINE จาก 6 แบรนด์ในเครือร้านอาหารเข้า Data Warehouse เดียว: ออกแบบ Schema ให้เทียบกันได้จริง

กลุ่มธุรกิจร้านอาหารแห่งหนึ่งที่มีแบรนด์ในเครือ 6 แบรนด์ แต่ละแบรนด์เปิด LINE OA รับออร์เดอร์และคำถามลูกค้าของตัวเอง ทีมข้อมูลกลางขององค์กรมี data warehouse อยู่แล้วสำหรับรวมยอดขายหน้าร้านและเดลิเวอรี แต่พอจะเพิ่มข้อมูลแชท LINE เข้าไป กลับพบว่าแต่ละแบรนด์ส่งออกข้อมูลมาคนละรูปแบบ บางแบรนด์มีคอลัมน์ 'ประเภทเมนู' บางแบรนด์ไม่มี บางแบรนด์นับ 'ออร์เดอร์' เป็นหนึ่งบทสนทนา บางแบรนด์นับเป็นหนึ่งรายการสินค้า

ทีมข้อมูลลองเขียนสคริปต์ดึงข้อมูลทั้ง 6 แบรนด์มายัดลงตารางเดียวโดยเร็ว ผลคือตัวเลขที่ได้เทียบกันไม่ได้เลย เพราะหน่วยนับไม่ตรงกัน พอผู้บริหารถามว่าแบรนด์ไหนขายดีกว่ากันจริง ทีมข้อมูลตอบไม่ได้อย่างมั่นใจ ทั้งที่ข้อมูลอยู่ใน warehouse เดียวกันแล้ว

บทความนี้ต่างจากการพูดถึงโครงสร้างองค์กรหรือธรรมาภิบาลข้อมูล แต่จะเจาะที่ปัญหาเชิงเทคนิคของการออกแบบ schema โดยตรง — ทำอย่างไรให้ 'แบรนด์' กลายเป็นมิติที่เทียบกันได้จริงในระดับตาราง ไม่ใช่แค่ระดับนโยบาย

หัวใจของปัญหา: ต้องมี 'conformed dimension' ของแบรนด์

ในภาษาการออกแบบ data warehouse มีแนวคิดที่เรียกว่า conformed dimension หมายถึงมิติข้อมูล (เช่น เวลา ลูกค้า สินค้า) ที่ถูกนิยามเหมือนกันทุกที่ในคลังข้อมูล ไม่ว่าจะดึงมาจากแหล่งไหน ปัญหาของกลุ่มร้านอาหารนี้คือ 'แบรนด์' และ 'ประเภทออร์เดอร์' ไม่ได้ถูกนิยามให้เป็น conformed dimension ตั้งแต่ต้น แต่ละแบรนด์นิยามเองตามความสะดวกของทีมตัวเอง

ทางแก้ไม่ใช่การไปบังคับให้แต่ละแบรนด์เปลี่ยนวิธีทำงานภายในของตัวเอง เพราะแต่ละแบรนด์มีเหตุผลของตัวเองที่นับข้อมูลแบบนั้น สิ่งที่ต้องทำคือสร้างชั้นแปลงข้อมูล (transformation layer) ที่แปลงนิยามของแต่ละแบรนด์ให้เข้ากับ conformed dimension กลางก่อนโหลดเข้า warehouse ไม่ใช่โหลดข้อมูลดิบเข้าไปตรง ๆ

โครงสร้างที่แนะนำ: แยก Fact กับ Dimension ให้ชัด

แนวทางคลาสสิกที่ใช้ได้ผลในเคสนี้คือออกแบบแบบ star schema โดยมีตาราง Fact หนึ่งตารางเก็บเหตุการณ์ 'ออร์เดอร์ที่ปิดจากแชท' ในหน่วยเดียวกันทุกแบรนด์ (เช่น หนึ่งแถวต่อหนึ่งออร์เดอร์ที่ชำระเงินแล้ว) แล้วเชื่อมกับตาราง Dimension แยกต่างหากสำหรับแบรนด์ เมนู และเวลา

วิธีนี้ต่างจากการออกแบบ pipeline สำหรับแบรนด์เดียวตรงที่ต้องเพิ่มมิติ 'แบรนด์' เข้าไปในทุก Fact Table และบังคับให้ทุกแหล่งข้อมูลแปลงหน่วยนับให้ตรงกันก่อนโหลด ไม่ใช่แค่ดึงข้อมูลจากแหล่งเดียวมาเก็บตรง ๆ แบบที่ทำได้ในกรณีแบรนด์เดียว

กระบวนการ mapping ที่ต้องทำก่อนเริ่มเขียนโค้ด

1. รวบรวมตัวอย่างข้อมูลดิบจากทั้ง 6 แบรนด์มาดูพร้อมกัน เพื่อเห็นว่าแต่ละแบรนด์นับหน่วยข้อมูลต่างกันตรงไหนบ้าง
2. จัดประชุมตัวแทนแต่ละแบรนด์ร่วมกับทีมข้อมูล เพื่อตกลงนิยามกลางของ 'ออร์เดอร์' และ 'หมวดเมนู' ที่ทุกแบรนด์ยอมรับได้ ไม่ใช่ให้ทีมข้อมูลตัดสินใจฝ่ายเดียว
3. เขียนตาราง mapping แยกสำหรับแต่ละแบรนด์ ที่แปลงค่าดั้งเดิมของแบรนด์นั้นให้เข้ากับ Dimension กลาง เก็บตาราง mapping นี้ไว้เป็นเอกสารอ้างอิง ไม่ใช่ฝังไว้ในโค้ดที่ไม่มีใครอ่านออกภายหลัง
4. ทดสอบด้วยข้อมูลย้อนหลังหนึ่งเดือนจากทุกแบรนด์ แล้วให้ตัวแทนแต่ละแบรนด์ยืนยันว่าตัวเลขที่แปลงแล้วตรงกับความเข้าใจของตัวเองหรือไม่ ก่อนเปิดใช้งานจริง

สิ่งที่ควรเลี่ยงเมื่อทำโปรเจกต์แบบนี้

• อย่าเริ่มเขียนโค้ดดึงข้อมูลก่อนตกลงนิยามกลาง เพราะจะต้องรื้อทำใหม่เมื่อพบว่าหน่วยนับไม่ตรงกันภายหลัง
• อย่าปล่อยให้แบรนด์ใดแบรนด์หนึ่งเป็นมาตรฐานโดยไม่ได้ตั้งใจ เช่น ใช้นิยามของแบรนด์ที่ใหญ่ที่สุดเป็นค่าเริ่มต้นโดยไม่ถามแบรนด์อื่น เพราะจะทำให้แบรนด์เล็กรู้สึกว่าข้อมูลของตัวเองถูกบิดเบือน
• อย่าลืมว่าการรวม schema สำเร็จทางเทคนิคไม่ได้แปลว่าปัญหาจบ ทีมที่ดูแลแดชบอร์ดผู้บริหารที่รวมหลายช่องทางยังต้องนำเสนอตัวเลขให้ตรงกับสิ่งที่ schema กลางนี้ยอมรับ ไม่ใช่หยิบตัวเลขดิบจากแบรนด์ใดแบรนด์หนึ่งมาใช้เฉพาะกิจ

สรุป

การรวมข้อมูลแชท LINE จากหลายแบรนด์เข้า warehouse เดียว ไม่ใช่แค่ปัญหาว่าจะดึงข้อมูลจากหลายที่มารวมกันได้อย่างไร แต่เป็นปัญหาการออกแบบ schema ที่ต้องมี conformed dimension อย่างแบรนด์และหมวดสินค้าที่ทุกแหล่งข้อมูลยอมรับร่วมกัน

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

• ต้องมี conformed dimension ของแบรนด์และหมวดสินค้าก่อนรวมข้อมูล ไม่ใช่ยัดข้อมูลดิบเข้าตารางเดียว
• ใช้โครงสร้าง star schema แยก Fact กับ Dimension ให้ชัด เพื่อให้เทียบข้ามแบรนด์ได้จริง
• ตกลงนิยามกลางร่วมกับตัวแทนทุกแบรนด์ก่อนเขียนโค้ด ไม่ใช่ให้ทีมข้อมูลตัดสินใจฝ่ายเดียว

คำถามที่พบบ่อย