ทำไมต้อง Big Data?

1องค์กรที่ขับเคลื่อนด้วยข้อมูล (Data-Driven Organization)

คำว่า data-driven ถูกใช้บ่อยจนบางครั้งฟังเหมือนคำโฆษณา แต่ความหมายที่ควรยึดไว้ค่อนข้างตรงไปตรงมา: เมื่อมีข้อเสนอหลายทาง องค์กรพยายามใช้ข้อมูล การทดลอง และหลักฐานช่วยตัดสิน แทนที่จะอาศัยเพียงตำแหน่ง ประสบการณ์ส่วนตัว หรือความรู้สึกของคนในห้องประชุม

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

มีข้อมูลมาก ไม่ได้แปลว่าตัดสินใจด้วยข้อมูล

องค์กรบางแห่งเก็บ log ทุกอย่าง สร้าง dashboard หลายสิบหน้า และมีรายงานส่งทุกเช้า แต่การตัดสินใจสำคัญยังเกิดขึ้นก่อนเปิดรายงาน แบบนี้เรียกว่า data-rich ได้ แต่ยังไม่จำเป็นต้องเป็น data-driven เพราะข้อมูลมีอยู่ในระบบ แต่ไม่ได้อยู่ในวงจรการตัดสินใจ

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

ข้อมูลไม่ใช่คำตัดสินสุดท้าย

คำว่า data-driven อาจทำให้เข้าใจผิดว่าตัวเลขต้องชนะทุกอย่าง แต่ข้อมูลไม่ได้ลอยมาจากธรรมชาติอย่างเป็นกลาง เราเป็นคนเลือกว่าจะวัดอะไร วัดจากใคร เก็บเมื่อใด และตัดข้อมูลส่วนใดออก สิ่งที่ไม่ถูกวัดอาจหายออกจากการตัดสินใจ ทั้งที่สำคัญต่อคนบางกลุ่มมาก

วงจรที่ทำให้องค์กรเรียนรู้ได้จริง

1. ตั้งคำถาม: เริ่มจากการตัดสินใจที่ต้องการปรับปรุง ไม่ใช่เริ่มจากข้อมูลที่บังเอิญมี
2. เก็บหลักฐาน: เลือกข้อมูลที่ตอบคำถาม พร้อมบันทึกที่มา เวลา และข้อจำกัด
3. วิเคราะห์: หารูปแบบ เปรียบเทียบทางเลือก และตรวจสอบว่าผลลัพธ์ทนต่อสมมุติฐานต่าง ๆ หรือไม่
4. ลงมือ: เปลี่ยนนโยบาย ผลิตภัณฑ์ หรือกระบวนการในขนาดที่ควบคุมความเสี่ยงได้
5. วัดผล: ตรวจว่าผลที่เกิดขึ้นตรงกับที่คาดหรือไม่ และมีผลข้างเคียงกับใครบ้าง
6. เรียนรู้รอบใหม่: เก็บสิ่งที่พบกลับเข้าไปเป็นข้อมูลสำหรับคำถามถัดไป

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

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

2นิยาม Big Data: 4V (และทำไมตัวเลขอย่างเดียวไม่พอ)

คำถามว่า “ข้อมูลกี่กิกะไบต์จึงเรียกว่า Big Data” ไม่มีคำตอบตายตัว เพราะขีดจำกัดของเครื่องมือเปลี่ยนไปตลอด ข้อมูลขนาด 100 GB อาจใหญ่เกินเครื่องหนึ่งในบางองค์กร แต่เป็นเพียงงานเล็กสำหรับอีกองค์กรหนึ่ง ความใหญ่จึงควรถูกนิยามจาก ความสัมพันธ์ระหว่างข้อมูล งานที่ต้องทำ ทรัพยากร และเวลาที่มี

นิยามนี้ตั้งใจผูก Big Data เข้ากับปัญหา ไม่ใช่ติดป้ายให้ชุดข้อมูล ตัวอย่างเช่น ไฟล์วิดีโอ 500 GB อาจไม่ใช่ Big Data หากเพียงเก็บไว้และเปิดดูทีละไฟล์ แต่ข้อมูลธุรกรรม 20 GB อาจกลายเป็นปัญหาหนัก หากต้อง Join หลายตารางและตอบภายในหนึ่งวินาทีให้ผู้ใช้หลายหมื่นคนพร้อมกัน

Volume: ปริมาณไม่ได้แพงเฉพาะตอนเก็บ

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

Volume ยังเปลี่ยนวิธีทดสอบระบบ ชุดข้อมูลตัวอย่างหนึ่งล้านแถวอาจทำงานได้ดี แต่เมื่อขยายเป็นพันล้านแถว key บางค่าที่พบเพียง 0.1% ก็ยังมีหนึ่งล้าน record และอาจกองอยู่ partition เดียว ปัญหาแบบนี้เรียกว่า data skew ซึ่งมองไม่เห็นจากค่าเฉลี่ยเพียงอย่างเดียว

Velocity: เร็วแค่ไหนต้องดูเวลาที่ธุรกิจยอมรอ

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

Velocity จึงมีสองความเร็วที่ต้องแยกกัน: ความเร็วที่ข้อมูลมาถึง และ ความเร็วที่ต้องตอบ ระบบที่รับข้อมูลเร็วไม่จำเป็นต้องตอบเร็ว และระบบที่ข้อมูลมาไม่มากก็อาจมีข้อกำหนด latency เข้มงวดได้

Variety: ปัญหาไม่ได้อยู่ที่นามสกุลไฟล์ แต่อยู่ที่ความหมาย

การแปลง CSV เป็น JSON ไม่ได้แก้ปัญหา Variety หากสองแหล่งยังใช้คำว่า customer_id คนละความหมาย หรือบันทึกอุณหภูมิด้วยหน่วยต่างกัน ปัญหาหนักมักเกิดที่ semantic integration: คนเดียวกันมีหลายรหัส สินค้าชิ้นเดียวมีหลายชื่อ และเวลาจากหลายระบบใช้เขตเวลาไม่ตรงกัน

Variety จึงนำไปสู่เรื่อง schema-on-read, metadata, data catalog, lineage และ data contract ซึ่งจะกลับมาในบท Data Integration เป้าหมายไม่ใช่บังคับให้ข้อมูลทุกอย่างมีรูปเหมือนกัน แต่ทำให้ผู้ใช้รู้ว่าข้อมูลแต่ละชุดหมายถึงอะไรและเชื่อมกันได้อย่างไร

Veracity: ข้อมูลมากช่วยลด noise บางชนิด แต่ขยาย bias บางชนิด

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

ความน่าเชื่อถือมีหลายด้าน:

• Accuracy: ค่าที่บันทึกใกล้ความจริงเพียงใด
• Completeness: ข้อมูลสำคัญหายไปหรือไม่ และหายแบบสุ่มหรือเป็นระบบ
• Consistency: แหล่งข้อมูลต่างกันกล่าวถึงเหตุการณ์เดียวกันตรงกันหรือไม่
• Timeliness: ข้อมูลล่าสุดพอสำหรับการตัดสินใจหรือไม่
• Provenance: รู้หรือไม่ว่าข้อมูลมาจากไหน ผ่านการแปลงอะไร และใครรับผิดชอบ

Value: V ที่เพิ่มภายหลัง แต่ควรถามตั้งแต่ต้น

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

3ทำไมตอนนี้? สามแรงขับเคลื่อน

มนุษย์สร้างข้อมูลมานานแล้ว ธนาคารมีธุรกรรม โรงพยาบาลมีเวชระเบียน และนักวิทยาศาสตร์มีผลทดลองก่อนคำว่า Big Data จะเกิดขึ้นเสียอีก สิ่งที่เปลี่ยนไม่ใช่เพียงปริมาณ แต่เป็นการมาบรรจบกันของสามเรื่อง: การสร้างข้อมูลกลายเป็นผลพลอยได้ของกิจกรรมแทบทุกชนิด พื้นที่เก็บและพลังประมวลผลมีราคาถูกลง และเครือข่ายทำให้ข้อมูลจากหลายพื้นที่ถูกรวบรวมได้รวดเร็วขึ้น

Science: เครื่องมือวัดเริ่มผลิตข้อมูลเร็วกว่าที่คนจะอ่านเอง

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

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

ตรงนี้ทำให้ Big Data เป็นเรื่องของ reproducibility ด้วย หาก pipeline มีหลายร้อยขั้นและข้อมูลเปลี่ยนรุ่น การเก็บเฉพาะผลสุดท้ายไม่พอ เราต้องรู้ว่าใช้ข้อมูลรุ่นใด parameter ใด software เวอร์ชันใด และขั้นตอนใดสร้างผลลัพธ์นั้นขึ้นมา

Business: ทุกการคลิกกลายเป็นโอกาสวัดผล

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

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

Society: เราไม่ได้เพียงใช้ระบบ แต่ช่วยสร้างข้อมูลให้ระบบตลอดเวลา

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

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

แรงขับที่สี่ซึ่งซ่อนอยู่: Economics

หลายปัญหาเคยคำนวณได้ในทางทฤษฎี แต่ไม่คุ้มในทางเศรษฐศาสตร์ การใช้เครื่องราคาแพงหลายเดือนเพื่อวิเคราะห์ข้อมูลหนึ่งรอบอาจไม่มีองค์กรใดยอมทำ เมื่อ commodity hardware, cloud และซอฟต์แวร์แบบเปิดลดต้นทุนการเริ่มต้น ปัญหาเดิมจึงกลายเป็นสิ่งที่ทดลองได้

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

4รูปแบบการใช้ข้อมูลที่เปลี่ยนไป

ระบบฐานข้อมูลเดิมถูกออกแบบมาอย่างดีสำหรับการบันทึกธุรกรรม เช่น โอนเงิน ตัดสินค้า หรือจองที่นั่ง งานเหล่านี้ต้องแก้ข้อมูลจำนวนไม่มากต่อครั้ง ตอบเร็ว และรักษาความถูกต้องอย่างเข้มงวด แต่การวิเคราะห์มักถามคนละแบบ เช่น “อ่านธุรกรรมทั้งหมดของปีที่ผ่านมา แล้วหาพฤติกรรมที่เกิดร่วมกัน” ซึ่งแตะข้อมูลจำนวนมากและยอมรอได้นานกว่า

OLTP กับ Analytics ไม่ได้มีเพียงข้อมูลคนละขนาด แต่มีรูปแบบการเข้าถึงคนละแบบ

การใช้ระบบเดียวทำทุกอย่างอาจเกิดการแย่งทรัพยากร Query ที่สแกนทั้งตารางสามารถรบกวนธุรกรรมของผู้ใช้ และ schema ที่เหมาะกับการอัปเดตทีละรายการอาจทำให้การวิเคราะห์ต้อง Join หลายครั้ง จึงเกิดการแยกระบบ operational ออกจาก analytical และสร้าง pipeline เคลื่อนข้อมูลระหว่างกัน

จาก Batch ไปสู่ Interactive, Stream และ Graph

คำว่า Big Data ครอบคลุม workload หลายชนิด การเลือกเครื่องมือจากขนาดข้อมูลเพียงอย่างเดียวจึงไม่พอ ต้องดูรูปแบบคำถามด้วย

ระบบหนึ่งอาจรองรับได้หลาย workload แต่ trade-off ต่างกัน Engine ที่เก่งงาน SQL แบบโต้ตอบอาจไม่เหมาะกับ control loop ที่ต้องตอบในไม่กี่มิลลิวินาที และระบบ streaming ที่เก่งการอัปเดตสถานะต่อเนื่องอาจไม่ใช่เครื่องมือที่คุ้มที่สุดสำหรับรายงานเดือนละครั้ง

การเปลี่ยนจากผู้บริโภคเป็นผู้ผลิตข้อมูล

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

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

5จากข้อมูลดิบไปสู่คุณค่า: โซ่ไม่ได้แข็งแรงกว่าข้อต่อที่อ่อนที่สุด

ภาพของ Big Data มักเริ่มที่คลัสเตอร์และจบที่ dashboard แต่ระหว่างสองจุดมีขั้นตอนจำนวนมาก หากขั้นใดผิด ผลลัพธ์ปลายทางอาจดูสวยและคำนวณเร็ว แต่ไม่มีความหมาย

1. Generate: เหตุการณ์เกิดขึ้นจากธุรกรรม อุปกรณ์ ผู้ใช้ หรือการทดลอง
2. Collect: ระบบรับข้อมูล พร้อมเวลา แหล่งที่มา และรหัสที่ใช้เชื่อมโยง
3. Store: เลือกรูปแบบไฟล์ partition การทำสำเนา และนโยบายเก็บรักษา
4. Prepare: ตรวจ schema ลบข้อมูลซ้ำ จัดการค่าที่หาย และแปลงหน่วยให้ตรงกัน
5. Compute: กรอง Join รวมผล สร้าง feature หรือฝึกโมเดล
6. Interpret: เชื่อมผลลัพธ์กับบริบท ตรวจสมมุติฐาน และระบุข้อจำกัด
7. Act: นำไปเปลี่ยนผลิตภัณฑ์ กระบวนการ หรือนโยบาย
8. Observe: วัดผลที่เกิดขึ้น รวมทั้งผลข้างเคียง แล้วเริ่มวงจรรอบถัดไป

Data Engineering และ Data Science พบกันตรงไหน

Data Engineering เน้นทำให้ข้อมูลไหลและใช้งานซ้ำได้ ตั้งแต่ ingestion, storage, transformation, quality ไปจนถึง serving ส่วน Data Science เน้นตั้งคำถาม วิเคราะห์ สร้างโมเดล และประเมินผล ทั้งสองส่วนแยกกันไม่ขาด เพราะโมเดลที่ดีต้องพึ่งข้อมูลที่มีความหมาย และ pipeline ที่เสถียรก็ควรถูกออกแบบจากความต้องการของการวิเคราะห์

ปัญหาที่พบได้บ่อยคือทีมหนึ่งสร้างตารางโดยไม่รู้ว่าโมเดลต้องป้องกัน data leakage อย่างไร ขณะที่อีกทีมสร้าง notebook ที่ทำงานได้ครั้งเดียวแต่ไม่มี lineage หรือวิธีนำขึ้น production วิชานี้จึงเชื่อมการคำนวณเข้ากับวงจรข้อมูล ไม่แยก algorithm ออกจากระบบที่ทำให้ algorithm ได้รับข้อมูลจริง

คุณค่าต้องเดินทางกลับไปถึงการใช้งาน

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

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

6Big Data เกี่ยวข้องกับ Cloud, Data Science, AI และฐานข้อมูลอย่างไร

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

เมื่อใดไม่ควรใช้ Big Data stack

การเลือกเครื่องมือที่เล็กที่สุดซึ่งตอบโจทย์ได้มักทำให้ระบบเข้าใจง่าย ดูแลง่าย และราคาถูกกว่า หากข้อมูลพอดีกับเครื่องเดียว Query ตอบทัน และไม่มีข้อกำหนด availability พิเศษ การใช้ฐานข้อมูลทั่วไปหรือ analytical engine บนเครื่องเดียวอาจเหมาะกว่า cluster

7เมื่อยุคเปลี่ยน: จากการเก็บให้ได้ ไปสู่การใช้ให้คุ้มและรับผิดชอบ

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

อีกด้านหนึ่ง เครื่องเดี่ยวมีความสามารถสูงขึ้นมาก งานที่เคยต้องใช้ cluster อาจทำได้ด้วยเครื่องเดียวหากใช้ columnar format, vectorized execution และ NVMe ที่เร็วขึ้น ดังนั้นคำว่า Big Data ยังเป็นเป้าหมายที่เคลื่อนที่ การตัดสินใจใช้ระบบกระจายควรมาจากการวัด ไม่ใช่จากปีที่คู่มือเดิมเขียนไว้

8กรณีศึกษา: ใช้กรอบเดียวกันมองโจทย์ต่างชนิด

กรณีศึกษาต่อไปนี้ไม่ได้มีไว้ให้จำชื่อเทคโนโลยี แต่ใช้ฝึกแยกคำถาม ข้อมูล workload และข้อจำกัด ก่อนเลือกสถาปัตยกรรม

กรณีที่ 1: ร้านค้าต้องการลดสินค้าขาดชั้นวาง

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

ถ้าดูเพียงโมเดล เราอาจเลือกวิธีพยากรณ์ที่แม่นที่สุด แต่ระบบจริงยังต้องรับข้อมูลจากสาขา ตรวจคุณภาพ สร้าง feature ตามเวลา และส่งคำแนะนำกลับก่อนรอบสั่งของ ตัวชี้วัดจึงควรรวมทั้ง forecast error, stockout rate, inventory cost และเวลาตั้งแต่ข้อมูลเกิดจนคำแนะนำพร้อมใช้

กรณีที่ 2: ตรวจจับความผิดปกติจากเครื่องจักร

โรงงานมี sensor หลายชนิดส่งค่าทุกวินาที ต้องการเตือนก่อนเครื่องเสีย ข้อมูลมี Velocity สูง แต่เหตุการณ์เสียจริงมีน้อย ทำให้ label ไม่สมดุลและการประเมินจาก accuracy อาจหลอกตา

ระบบต้องแยกอย่างน้อยสองเส้นทาง:

• เส้นทางเร็ว: รับ stream คำนวณ feature ใน window ล่าสุด และแจ้งเตือนภายในเวลาที่กำหนด
• เส้นทางเรียนรู้: เก็บข้อมูลระยะยาว เชื่อมกับบันทึกซ่อม ฝึกโมเดลใหม่ และตรวจว่าพฤติกรรมเครื่องเปลี่ยนไปหรือไม่

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

กรณีที่ 3: วิเคราะห์ความสัมพันธ์ในเครือข่าย

แพลตฟอร์มต้องการค้นหาชุมชน บัญชีที่เชื่อมโยงผิดปกติ หรือเนื้อหาที่แพร่กระจายผ่านกลุ่มใด ข้อมูลไม่ได้มีความหมายจาก record แต่ละแถวเพียงอย่างเดียว ความหมายอยู่ที่ edge ระหว่างผู้ใช้ เหตุการณ์ และเนื้อหา

การแบ่งกราฟเป็น partition ยากกว่าการแบ่งตาราง เพราะ vertex ที่มี degree สูงเชื่อมไปหลายส่วน Algorithm อย่าง BFS หรือ PageRank ต้องทำซ้ำหลายรอบ และแต่ละรอบอาจส่งข้อมูลข้ามเครื่องจำนวนมาก ต่อให้ computation ต่อ edge เล็ก ต้นทุน communication และ synchronization ก็ครองเวลารวมได้

9จริยธรรม ความเป็นส่วนตัว และความรับผิดชอบเป็นส่วนหนึ่งของการออกแบบ

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

เก็บได้ ไม่ได้แปลว่าควรเก็บ

ต้นทุน storage ที่ลดลงทำให้เกิดแนวคิด “เก็บไว้ก่อน เผื่อได้ใช้” แต่ข้อมูลที่เก็บไว้นานเพิ่มทั้งความเสี่ยงเมื่อรั่วไหล ค่าใช้จ่ายในการกำกับดูแล และความยากในการตอบว่าข้อมูลมาจากไหน การกำหนด retention policy จึงควรผูกกับวัตถุประสงค์ ไม่ใช่เก็บตลอดไปเพราะพื้นที่ยังเหลือ

Anonymization ไม่ได้ทำให้ข้อมูลปลอดภัยเสมอไป

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

อคติอาจเกิดก่อนโมเดลเริ่มเรียน

Bias ไม่ได้อยู่เฉพาะใน algorithm แต่อาจเกิดจากคนที่ถูกเลือกเข้าระบบ เหตุการณ์ที่ถูกบันทึก label ที่มนุษย์กำหนด และตัวชี้วัดที่องค์กรเลือก ถ้าข้อมูลสะท้อนการปฏิบัติที่ไม่เท่าเทียมในอดีต โมเดลที่ทำนายอดีตได้แม่นอาจช่วยทำให้ความไม่เท่าเทียมนั้นดำเนินต่อไป

ความโปร่งใสต้องรวมถึงข้อจำกัด

การอธิบายว่าใช้ AI หรือ Big Data ไม่เพียงพอ ผู้ใช้ผลลัพธ์ควรรู้ว่าข้อมูลครอบคลุมช่วงใด กลุ่มใดถูกแทนน้อย ตัวชี้วัดมีความไม่แน่นอนเท่าใด และสถานการณ์ใดไม่ควรใช้ผลลัพธ์ การบอกข้อจำกัดไม่ได้ทำให้ระบบดูอ่อนแอ แต่ช่วยป้องกันการนำคำตอบไปใช้เกินขอบเขตที่หลักฐานรองรับ

10สรุปบท: Big Data คือการเปลี่ยนวิธีคิดเกี่ยวกับข้อมูลและการคำนวณ

Big Data ไม่ใช่เส้นแบ่งจำนวนไบต์ และไม่ใช่ชื่อเรียกรวมของ Hadoop, Spark หรือ Cloud แต่เป็นสถานการณ์ที่ขนาด ความเร็ว ความหลากหลาย หรือความน่าเชื่อถือของข้อมูลทำให้วิธีเดิมไม่ตอบโจทย์ภายใต้ข้อจำกัดที่มี เราจึงต้องเปลี่ยนทั้งสถาปัตยกรรม data model และ algorithm

แนวคิดสำคัญของบทนี้มีดังนี้:

• องค์กรที่มีข้อมูลมากยังไม่จำเป็นต้องเป็น data-driven หากข้อมูลไม่เข้าไปอยู่ในวงจรตั้งคำถาม ลงมือ และวัดผล
• 4V เป็นกรอบมองข้อจำกัด ไม่ใช่รายการสำหรับติดป้ายโครงการ และ Value ควรถูกถามตั้งแต่ก่อนเริ่มเก็บ
• Workload สำคัญพอ ๆ กับขนาดข้อมูล งาน batch, interactive, stream และ graph ต้องการการจัดระบบต่างกัน
• Data Engineering, Data Science, AI, Database และ Cloud เกี่ยวข้องกัน แต่ตอบคำถามคนละส่วน
• เครื่องมือขนาดใหญ่ไม่ควรถูกใช้เพียงเพราะดูทันสมัย หากเครื่องเดียวตอบโจทย์ได้ ระบบที่เล็กกว่าอาจเป็นการออกแบบที่ดีกว่า
• จริยธรรม ความเป็นส่วนตัว และการกำกับดูแลต้องถูกออกแบบพร้อม pipeline ไม่ใช่เติมภายหลัง