How analytical data is served

ทำไมการขอเปลี่ยนชื่อกลุ่มสินค้า จึงกลายเป็นเรื่องยุ่งยากสำหรับข้อมูลใช้วิเคราะห์
บางครั้งการออกแบบก็ไม่มีสูตรสำเร็จ สามารถทำได้หลายวิธี ทุกวิธีต่างมีข้อดีและข้อเสียที่จะต้องแลกกัน ขึ้นอยู่กับเงื่อนไขและปัจจัยข้อจำกัดที่แตกต่างกัน วิธีที่เคยใช้ได้กับที่หนึ่ง อาจเอาไปใช้กับอีกที่หนึ่งไม่ได้
 
ผมอยู่ที่หน้าจอตรวจสอบการใช้งานดาต้าเบสของลูกค้ารายหนึ่ง มีเรื่องที่ตัดสินใจไม่ได้แต่อยากเอามาเล่าสู่กันฟัง
 
บริษัทแห่งนี้ใช้โปรแกรมของเรา ระยะหลังมีการเปลี่ยนชื่อกลุ่มสินค้าบ่อย ทำให้มีปัญหากับดาต้าเบสอีกตัวหนึ่งที่ซิงค์ข้อมูลรายการขายให้ฝ่ายการตลาดเอาไปใช้ เนื่องจากข้อมูลที่ซิงค์ไปก่อนหน้านั้น กับข้อมูลใหม่มีชื่อกลุ่มสินค้าไม่ตรงกัน
 
เรื่องราววิเคราะห์ข้อมูลเริ่มยุคแรก ใช้กลไกของรายงานสร้างตาราง ดึงข้อมูลตรงจากดาต้าเบส ออกมาเป็นไฟล์ส่งให้ฝ่ายการตลาด เมื่อมีการขายออนไลน์ โดยเฉพาะไลฟ์สด ความต้องการข้อมูลที่ทันเวลา ทำให้ต้องทำกลไกอัตโนมัติ เรียกรายงานถี่ๆ เพื่อให้ได้ข้อมูลล่าสุด แต่ผลที่เกิดขึ้นไม่ได้เป็นตามที่หวัง ยิ่งเรียกรายงานถี่ กลายเป็นหน่วงการทำงานด้านอื่นให้ช้าจนทำงานไม่ได้
 
วันนั้น เมื่อทราบรายละเอียดการใช้งานที่ทำให้ดาต้าเบสล่มบ่อยๆ ผมครุ่นคิดถึงทางเลือก ถามกับตัวเองว่าเอายังไงดี..
ความท้าทายอยู่ที่ ทำอย่างไรให้ฝ่ายการตลาดได้ข้อมูลไปวิเคราะห์ทันเวลา โดยไม่รบกวนดาต้าเบสจนไม่สามารถทำงานตามปกติได้
ปกติการทำข้อมูลสรุปหรือวิเคราะห์เพื่อใช้ในการประชุมหรือเสนอให้ผู้บริหาร จะใช้วิธีส่งออกมาไว้ในสเปรดชีต เพื่อเพิ่มสูตรคำนวณ หรือตกแต่งรูปแบบการนำเสนอให้สวยงามได้ง่าย การทำเช่นนี้มีการอ่านข้อมูลที่ต้องการจากดาต้าเบสครั้งเดียวตอนที่เอาไปใส่ชีต หลังจากนั้นเป็นการเล่นแร่แปรธาตุกับข้อมูลที่อยู่ในชีต ไม่ได้รบกวนดาต้าเบสอีก จึงไม่มีปัญหา แต่การวิเคราะห์แบบทันเวลานั้นต่างกัน ต้องอ่านข้อมูลจากดาต้าเบสบ่อยๆ เพื่อให้ได้ข้อมูลล่าสุดเช่น ทุกนาที กลับเกิดผลกระทบ ถ้าข้อมูลมีปริมาณมากยิ่งเป็นปัญหามาก ผสมกับความบ่อยทำให้การประมวลผลของดาต้าเบสถูกแบ่งมา จนต้องลดงานด้านอื่นลงไป
 
ทางแก้ที่ออกแบบไว้คือ แยกถังข้อมูลเป็นสองถัง ไม่ให้งานวิเคราะห์มาเอาข้อมูลจากถังที่ใช้ทำงาน แล้วหาทางสร้างกลไกที่ทำให้ถังที่สองมีข้อมูลตรงกับถังแรก ที่เรียกว่าการซิงค์ข้อมูล
 
ที่นี้โจทย์ยากก็มาอยู่ที่การคิดหาวิธีซิงค์ ทำอย่างไรจึงรบกวนดาต้าเบสในถังแรกน้อยที่สุด โดยเปลี่ยนวิธีอ่าน "เฉพาะข้อมูลที่เกิดขึ้นใหม่" เท่านั้น แตกต่างจากการเรียกรายงานแบบเดิม ที่ต้องย้อนอ่านข้อมูลตั้งแต่เริ่มต้นของวัน ดังนั้นหากซิงค์ถี่ เวลาสั้นลง ถึงแม้จะอ่านบ่อย แต่ปริมาณข้อมูลที่เกิดขึ้นใหม่ในช่วงเวลาสั้นๆ นั้นก็น้อยตามไปด้วย ในการใช้งานจริง ถึงแม้ว่าข้อมูลทั้งสองถังต้องตรงกัน แต่ไม่จำเป็นต้องอยู่ในรูปแบบเหมือนกัน เช่น ข้อมูลขายที่เก็บไว้ในดาต้าเบสหลัก มีเฉพาะชื่อสินค้า แต่งานวิเคราะห์ต้องการดูตามชื่อกลุ่มสินค้า ดังนั้นกลไกซิงค์จึงเอาชื่อกลุ่มที่แยกเก็บอยู่ในฐานข้อมูลสินค้า มาเพิ่มในข้อมูลที่ใช้วิเคราะห์ให้ด้วย
 

ตัวอย่าง ข้อมูลรายการขายที่เก็บในดาต้าเบสหลัก
 
นมรสหวาน | 2 | ขวด
ชาเขียว | 1 | ขวด
นมสดรสจืด | 4 | ขวด
 
เมื่อแปลงเป็นข้อมูลวิเคราะห์ โดยไปเอาชื่อกลุ่มสินค้ามาเติมให้
 
นมรสหวาน | 2 | ขวด | เครื่องดื่ม
ชาเขียว | 1 | ขวด | เครื่องดื่ม
นมสดรสจืด | 4 | ขวด | เครื่องดื่ม
 
สมมติว่า หลังจากนั้นมีการเปลี่ยนชื่อกลุ่ม ของนมทุกชนิด จาก "เครื่องดื่ม" เป็น "นมพร้อมดื่ม" หากเป็นข้อมูลที่ใช้ทำงาน ไม่ต้องทำอะไร เพียงแก้ชื่อกลุ่มในข้อมูลสินค้า ก็จะได้ชื่อกลุ่มที่เปลี่ยนใหม่อัตโนมัติ ทุกครั้งที่อ่านมาใหม่
 
แต่สำหรับข้อมูลวิเคราะห์ที่มีชื่อกลุ่มอยู่ในรายการขายตั้งแต่ตอนที่ซิงค์มาเก็บ หากต้องการเปลี่ยนต้องทำการซ่อมข้อมูลรายการขายทีละรายการ
 
นมรสหวาน | 2 | ขวด | นมพร้อมดื่ม
ชาเขียว | 1 | ขวด | เครื่องดื่ม
นมสดรสจืด | 4 | ขวด | นมพร้อมดื่ม
 
ในอนาคตหากมีการเปลี่ยนชื่อกลุ่มสินค้าบ่อยๆ จะต้องปรับปรุงกลไกซิงค์อย่างไร จึงเหมาะสมที่สุด
 
ระหว่างคงรูปแบบข้อมูลวิเคราะห์ไว้อย่างเดิม เปลี่ยนชื่อทีนึงก็ซ่อมทีนึง ในระยะยาวหากข้อมูลสะสมมีจำนวนมาก การซ่อมข้อมูลจะกลายเป็นงานที่กินแรงมากขึ้นเรื่อยๆ รวมทั้งการตรวจสอบความถูกต้องว่าการเปลี่ยนแก้นั้นครบถ้วนหรือไม่ก็ยาก หากเปลี่ยนรูปแบบให้แยกเก็บข้อมูลสินค้าไว้ต่างหาก แล้วค่อยดึงมาประกอบกันตอนที่ใช้วิเคราะห์ เหมือนการออกแบบดาต้าเบสหลัก วิธีนี้ถึงแม้ช่วยให้การเปลี่ยนชื่อทำได้ง่าย สะดวกรวดเร็ว แต่การอ่านข้อมูลเพื่อวิเคราะห์จะซับซ้อนกว่า
สุดท้ายยังตัดสินใจไม่ได้ เราเรียนรู้ไปด้วยกัน เผื่อจะช่วยกันคิด ข้อจำกัดของธุรกิจขนาดเล็กที่ไม่เหมือนองค์กรใหญ่ ไม่มีดาต้าเอนจิเนียร์จริงจัง ทีมพัฒนาพยายามเป็นทุกอย่างเท่าที่ทำได้
 


 
May 2022 / Sathit J.