Big Data Analytics · จากข้อมูลขนาดใหญ่ไปสู่การคำนวณที่คิดเป็น
Big Data Analytics
Warin Wattanapornprom, PhD.
ข้อมูลที่ใหญ่ขึ้นไม่ได้เรียกร้องเพียงเครื่องที่ใหญ่ขึ้น แต่บังคับให้เราเปลี่ยนวิธีคิด ตั้งแต่ตำแหน่งของข้อมูล วิธีแบ่งงาน วิธีรวมผล ไปจนถึงคำถามว่าเราจำเป็นต้องคำนวณคำตอบอย่างแม่นยำทุกครั้งจริงหรือไม่
13 บท จากรากฐานถึงการประยุกต์
7 แล็บ จาก Spark สู่กราฟและสตรีม
5 แกน จัดเก็บ คำนวณ สืบค้น สตรีม และเรียนรู้
1 คำถาม ทำอย่างไรให้ข้อมูลเคลื่อนย้ายน้อยที่สุด
ความตั้งใจ จุดเปลี่ยนของวิชา เส้นทางการเรียน
พื้นฐานที่ควรมี ภาคปฏิบัติ เมื่อยุคเปลี่ยน ที่มาของเนื้อหา
คำนำและความตั้งใจของผู้สอน
Big Data ไม่ได้เริ่มจากข้อมูลที่ใหญ่ แต่เริ่มจากวิธีเดิมที่ไปต่อไม่ไหว
หลายคนพบวิชา Big Data ครั้งแรกผ่านรายชื่อเครื่องมือ: Hadoop, HDFS, Spark, Kafka, HBase, Cassandra หรือ GraphX รายชื่อเหล่านี้ทำให้วิชาดูเหมือนวิชาที่ต้องจำผลิตภัณฑ์จำนวนมาก และเมื่อผลิตภัณฑ์เปลี่ยนรุ่น เนื้อหาก็ดูเหมือนเก่าตามไปด้วย
แต่ถ้ามองให้ลึกลงอีกชั้น เครื่องมือแต่ละตัวไม่ได้เกิดขึ้นเพราะวงการอยากมีชื่อใหม่เพิ่มขึ้น เครื่องมือเหล่านี้เกิดจากข้อจำกัดที่ระบบเดิมรับมือไม่ไหว บางครั้งข้อมูลใหญ่เกินหน่วยความจำ บางครั้งอ่านจากดิสก์ช้าเกินไป บางครั้งการส่งข้อมูลข้ามเครือข่ายแพงกว่าการคำนวณ และบางครั้งข้อมูลไหลเข้ามาไม่สิ้นสุดจนคำว่า “อ่านให้ครบก่อนแล้วค่อยเริ่ม” ไม่มีความหมายอีกต่อไป
ภาพเปรียบเทียบ: ห้องสมุดที่ใหญ่เกินกว่าจะยกหนังสือออกมา ถ้ามีหนังสือสิบเล่ม เราอาจขนทั้งหมดมาวางบนโต๊ะแล้วค้นด้วยตนเอง แต่ถ้ามีหนังสือสิบล้านเล่ม การขนหนังสือมาหาคนอ่านไม่ใช่แผนที่ฉลาดอีกต่อไป เราต้องส่งคำถามไปยังชั้นหนังสือ ให้หลายคนค้นพร้อมกัน แล้วส่งกลับมาเฉพาะคำตอบที่ย่อแล้ว Big Data เริ่มต้นจากการกลับทิศทางเช่นนี้
เว็บไซต์นี้จึงไม่ได้ตั้งใจเป็นคู่มือ Spark และไม่ได้ตั้งใจเป็นพิพิธภัณฑ์ Hadoop เป้าหมายคือพาผู้เรียนมองเห็นรูปแบบการคำนวณที่อยู่ข้างใต้ เมื่อพบระบบใหม่ ควรถามได้ว่ามันแบ่งข้อมูลอย่างไร ย้ายอะไรไปหาอะไร รวมผลตรงไหน รอพร้อมกันเมื่อใด และยอมแลกความแม่นยำหรือความสอดคล้องเพื่ออะไร
ถ้าเข้าใจเพียงชื่อเครื่องมือ ความรู้จะหมดอายุตามเวอร์ชัน แต่ถ้าเข้าใจเหตุผลที่เครื่องมือนั้นถือกำเนิด เราจะอ่านเครื่องมือรุ่นถัดไปได้ด้วยตนเอง
สิ่งที่ผมตั้งใจให้ผู้เรียนได้กลับไป
มองข้อมูลพร้อมต้นทุน ข้อมูลไม่ได้มีเพียงความหมาย แต่มีขนาด ตำแหน่ง รูปแบบการเข้าถึง และต้นทุนในการเคลื่อนย้าย การเลือก algorithm จึงแยกจากที่อยู่ของข้อมูลไม่ได้
มองเครื่องมือผ่าน Algebra Map, Reduce, Filter, Join และ Aggregate ไม่ใช่ API กระจัดกระจาย แต่เป็นตัวดำเนินการที่ประกอบ จัดรูป และกระจายงานใหม่ได้
อธิบายได้ว่าทำไมเร็วขึ้น ไม่หยุดที่คำว่า distributed หรือ in-memory แต่แยกให้ออกว่าความเร็วเกิดจาก locality, parallelism, caching, pruning หรือการยอมประมาณคำตอบ
จุดเปลี่ยนสำคัญของวิชา
แทนที่จะย้ายข้อมูลมาหาเครื่องเรา เราส่งการคำนวณไปหาข้อมูล
ในโลกของโปรแกรมขนาดเล็ก เราเคยชินกับการเปิดไฟล์ ดึงข้อมูลเข้าหน่วยความจำ แล้วเริ่มคำนวณ เครื่องที่รันโปรแกรมจึงดูเหมือนศูนย์กลาง ส่วนข้อมูลเป็นวัตถุดิบที่ถูกขนเข้ามา แต่เมื่อข้อมูลมีขนาดหลายเทราไบต์หรือหลายเพตะไบต์ สมมุติฐานนี้กลับกลายเป็นคอขวดทันที
โค้ดของ Mapper อาจมีขนาดเพียงไม่กี่กิโลไบต์ ขณะที่ block ข้อมูลหนึ่งก้อนมีขนาดหลายร้อยเมกะไบต์ ถ้าเราขน block ทุกก้อนผ่านเครือข่ายมาหาโปรแกรม เรากำลังเลือกย้ายสิ่งที่ใหญ่กว่าเป็นหมื่นหรือแสนเท่า ทั้งที่ย้ายโปรแกรมไปยังเครื่องซึ่งมีข้อมูลอยู่แล้วได้
หลักของ Data Locality HDFS รู้ว่า block อยู่บน DataNode ใด ส่วน scheduler รู้ว่า worker ใดพร้อมทำงาน ระบบจึงพยายามนำ task ไปเริ่มบนเครื่องที่มีข้อมูลนั้น ถ้าทำไม่ได้จึงค่อยเลือกเครื่องใน rack เดียวกัน และหลีกเลี่ยงการขนข้อมูลข้าม rack เท่าที่ทำได้
หลักเดียวกันปรากฏซ้ำในหลายชื่อ เช่น predicate pushdown ซึ่งส่งเงื่อนไขกรองลงไปใกล้ไฟล์, projection pruning ซึ่งอ่านเฉพาะคอลัมน์ที่ใช้, computation pushdown ในฐานข้อมูล และ edge computing ซึ่งประมวลผลใกล้อุปกรณ์ต้นทาง ชื่อเปลี่ยน แต่แก่นเหมือนเดิม: อย่าเคลื่อนย้ายข้อมูลก้อนใหญ่ ถ้าสามารถเคลื่อนย้ายคำสั่งหรือคำตอบก้อนเล็กแทนได้
การเดินทางอีกเส้นหนึ่ง: จาก MapReduce ไปสู่ SQL
MapReduce ทำให้เรากระจายงานได้ แต่ผู้เขียนโปรแกรมยังต้องบอกขั้นตอนค่อนข้างมาก ต้องเลือก key กำหนด Map รู้ว่า Shuffle จะเกิดที่ไหน และเขียน Reduce เพื่อรวมผล ต่อมา Pig และ Hive เริ่มให้ผู้ใช้บอกงานในระดับที่สูงขึ้น ระบบเป็นฝ่ายแปลงคำสั่งเหล่านั้นให้กลายเป็น MapReduce หลาย job
Spark SQL เดินต่อจากแนวคิดนี้ด้วย DataFrame และ Catalyst Optimizer เราไม่ได้เขียนเพียงโค้ดที่สั้นลง แต่เปลี่ยนจากการบอก วิธีเดินทาง เป็นการบอก ปลายทาง SQL ถูกแปลงเป็น Relational Algebra แล้ว optimizer จึงเลือก physical plan ที่เหมาะกับข้อมูลจริง
MapReduce เขียนขั้นตอนเอง
Pig / Hive บอก dataflow หรือ query
Algebra สร้าง logical plan
Optimizer จัดรูปและเลือกแผน
Execution กระจาย task จริง
SQL เหมือนการบอกปลายทางกับคนขับ เราไม่จำเป็นต้องสั่งว่าเลี้ยวซ้ายกี่ครั้งและใช้ถนนเส้นใด เพียงบอกว่าจะไปไหน คนขับเลือกเส้นทางจากสภาพถนน แต่ถ้าเราเข้าใจแผนที่ เราจะตรวจได้ว่าเส้นทางที่เลือกสมเหตุสมผลหรือไม่ Relational Algebra คือแผนที่ ส่วน optimizer คือคนวางเส้นทาง
Algebra ทำให้ระบบคิดแทนเราได้บางส่วน
สิ่งที่ต้องการ Operator สิ่งที่ระบบพยายามทำ เลือกเฉพาะแถวที่ต้องใช้ Selection / WHERE กรองใกล้แหล่งข้อมูลที่สุด เพื่อไม่ต้องขนแถวที่ทิ้งอยู่แล้ว เลือกเฉพาะคอลัมน์ Projection / SELECT อ่านและส่งเฉพาะคอลัมน์ที่จำเป็น รวมผลตามกลุ่ม Aggregation / GROUP BY รวมผลบางส่วนในเครื่องก่อน Shuffle แล้วค่อยรวมขั้นสุดท้าย เชื่อมข้อมูลสองชุด Join เลือก Broadcast, Hash หรือ Sort-Merge ตามขนาดและการกระจายของข้อมูล เรียงข้อมูล Sort / ORDER BY แบ่งช่วง ส่งข้อมูลไปยัง partition ที่ถูกต้อง แล้วเรียงภายในแต่ละส่วน
นี่คือเหตุผลที่ Algebra สำคัญต่อ Big Data ไม่ใช่เพราะต้องการเพิ่มสัญลักษณ์คณิตศาสตร์ แต่เพราะสมบัติของ operator เปิดทางให้ระบบสลับ รวม หรือดันการคำนวณลงไปใกล้ข้อมูล โดยยังได้คำตอบเดิม
ภาพรวมก่อนเริ่มเรียน
วิชานี้เดินผ่านการเปลี่ยนสมมุติฐานห้าครั้ง
จากความเคยชินเดิม ไปสู่แนวคิดใหม่ คำถามที่ควรถาม ข้อมูลมาหาโปรแกรม ส่ง code ไปหา data จะทำให้การคำนวณเกิดใกล้ข้อมูลได้เพียงใด เขียนขั้นตอนเองทุกอย่าง บอกผลลัพธ์ผ่าน Algebra/SQL optimizer ลดข้อมูลก่อน Shuffle ได้อย่างไร เก็บข้อมูลไว้เครื่องเดียว Partition และ Replication key ใดทำให้กระจายดี และต้องรอกี่สำเนา รอข้อมูลครบแล้วคำนวณ Window และ Incremental State เมื่อ stream ไม่จบ เราควรจำอะไรและลืมอะไร ต้องได้คำตอบแม่นยำเสมอ Approximation และ Sketch ยอมคลาดเคลื่อนเท่าใดจึงลดทรัพยากรได้คุ้มค่า
เมื่อมองผ่านการเปลี่ยนสมมุติฐานเหล่านี้ Hadoop, Spark, Cassandra, Structured Streaming และ GraphX จะไม่ใช่บทแยกกัน แต่เป็นคำตอบหลายรูปแบบต่อปัญหาเดียวกัน: ข้อมูลใหญ่เกินกว่าจะจัดการด้วยการเคลื่อนย้ายและการรอแบบเดิม
เส้นทางการเรียนรู้
อ่านสารบัญเป็นลำดับของปัญหา ไม่ใช่รายชื่อเทคโนโลยี
เนื้อหา 13 บทแบ่งเป็นห้าช่วง แต่ละช่วงเปลี่ยนคำถามทีละขั้น จากการทำความเข้าใจว่าทำไมข้อมูลจึงกลายเป็นปัญหา ไปสู่การจัดเก็บ การคำนวณ การสืบค้นข้อมูลที่ไหลไม่จบ และการเรียนรู้จากข้อมูลขนาดใหญ่
1 · รากฐาน: เมื่อข้อมูลเปลี่ยนขนาด วิธีคิดต้องเปลี่ยนตาม
เริ่มจากนิยามปัญหา พื้นฐานที่ต้องใช้ และเหตุผลที่ศูนย์ข้อมูลควรถูกมองเป็นคอมพิวเตอร์หนึ่งเครื่อง
2 · จัดเก็บและคำนวณ: นำงานไปหาข้อมูล แล้วรวมให้น้อยครั้ง
ทำความเข้าใจ distributed file system, MapReduce, Functional Programming และสิ่งที่ทำให้การขนานเร็วเกินจำนวนเครื่องได้ในบางกรณี
3 · กระจายข้อมูลและรักษาความหมาย
เมื่อข้อมูลมีหลายสำเนา ความถูกต้อง ความพร้อมใช้งาน ตำแหน่งของ key และรูปแบบข้อมูลกลายเป็นการตัดสินใจเดียวกัน
4 · จาก MapReduce สู่ข้อมูลสามรูปแบบ: ตาราง สตรีม และกราฟ
เรียนรู้ว่าการคำนวณเปลี่ยนอย่างไรเมื่อข้อมูลมี schema, ไหลเข้าตลอดเวลา หรือเชื่อมโยงกันเป็นเครือข่าย
5 · เรียนรู้จากข้อมูลขนาดใหญ่ และนำไปใช้กับปัญหาจริง
ปิดท้ายด้วยการปรับ Machine Learning ให้กระจายงานได้ และมองกรณีศึกษาผ่านข้อจำกัดของข้อมูล ไม่ใช่เริ่มจากชื่อผลิตภัณฑ์
พื้นฐานที่ควรมี
ไม่จำเป็นต้องรู้ทุกเครื่องมือ แต่ควรอ่านต้นทุนของการคำนวณให้ออก
วิชานี้เชื่อมความรู้หลายส่วนเข้าด้วยกัน ผู้เรียนไม่จำเป็นต้องเชี่ยวชาญทุกเรื่องก่อนเริ่ม แต่ถ้ามีพื้นฐานต่อไปนี้ จะเข้าใจเหตุผลของระบบได้มากกว่าการจำคำสั่ง
Programming เขียนโปรแกรมด้วยภาษาใดภาษาหนึ่งได้คล่อง เข้าใจ function, collection และการแยกข้อมูลออกจากขั้นตอนประมวลผล
Data Structures & Algorithms เข้าใจ complexity, hash table, tree, graph และความต่างระหว่างงานที่แบ่งได้กับ dependency ที่ต้องรอ
Database รู้จัก table, key, index, SQL, Join, transaction และมองเห็นว่าการ Join ตารางใหญ่มีต้นทุนด้านข้อมูลอย่างไร
Computer Architecture เข้าใจ CPU, cache, memory hierarchy, disk และเหตุผลที่การเข้าถึงข้อมูลแต่ละตำแหน่งไม่ได้มีราคาเท่ากัน
Operating Systems รู้จัก process, thread, file system, virtual memory และ I/O พอจะแยกเวลาคำนวณออกจากเวลารอได้
Computer Networks เข้าใจ latency, bandwidth และเหตุผลที่การส่งข้อมูลข้ามเครื่องแพงกว่าการเรียก function ภายในเครื่องมาก
ถ้ายังไม่มั่นใจบางเรื่อง สามารถเริ่มเรียนได้ แล้วค่อยย้อนกลับเมื่อเจอจุดที่ติดขัด โดยเฉพาะเรื่อง hash, graph, cache, SQL และ network cost เพราะห้าเรื่องนี้ปรากฏซ้ำในหลายบท
วิธีอ่านเนื้อหาชุดนี้
อ่านทุกระบบด้วยคำถามหกข้อ
ข้อมูลอยู่ที่ไหน: กระจายตาม block, partition, key หรือช่วงของ key และตำแหน่งนั้นเหมาะกับรูปแบบการอ่านหรือไม่การคำนวณเกิดที่ไหน: งานถูกส่งไปใกล้ข้อมูล หรือข้อมูลถูกขนกลับมาหางานโดยไม่จำเป็นอะไรทำพร้อมกันได้: record, partition, model หรือ vertex ใดเป็นอิสระ และส่วนใดต้องรอผลจากรอบก่อนข้อมูลเคลื่อนที่ตรงไหน: Shuffle, Join, replication หรือ synchronization ส่งข้อมูลมากเท่าใดรวมผลอย่างไร: รวมในเครื่องก่อนได้หรือไม่ operation เป็น associative หรือปรับให้อยู่ในรูป Monoid ได้หรือไม่คำตอบต้องแม่นแค่ไหน: ต้อง exact ทุกครั้ง หรือยอมใช้ window, sampling หรือ sketch เพื่อประหยัดทรัพยากรได้
แบบฝึกความคิดก่อนเปิดบทถัดไป ลองเลือก query หรืองานวิเคราะห์หนึ่งชิ้น แล้ววาดเพียงสามอย่าง: ข้อมูลเริ่มอยู่ตรงไหน ข้อมูลก้อนใดต้องเคลื่อนย้าย และคำตอบถูกย่อให้เล็กลงตรงไหน ถ้ายังวาดไม่ได้ แปลว่าเรารู้ชื่อ API แล้ว แต่อาจยังไม่เห็นการคำนวณจริงข้างใต้
ภาคปฏิบัติการ
แล็บมีไว้ทดสอบความเข้าใจ ไม่ใช่เพียงทำให้โค้ดรันผ่าน
การเห็นผลลัพธ์บนหน้าจอเป็นเพียงจุดเริ่มต้น ในแต่ละแล็บควรเปิดดู execution plan, จำนวน partition, stage, Shuffle และเวลาที่ใช้ แล้วตั้งใจเปลี่ยนเงื่อนไขบางอย่างเพื่อดูว่าระบบตอบสนองอย่างไร
ภาคปฏิบัติ · จากสภาพแวดล้อมไปสู่โครงงาน
เริ่มจากติดตั้งระบบให้ทำซ้ำได้ แล้วค่อยทดลอง batch, SQL, ML, stream และ graph ก่อนประกอบเป็นโครงงานเดียว
เมื่อยุคเปลี่ยน
เครื่องมือเปลี่ยนเร็ว แต่แก่นของการคำนวณเปลี่ยนช้ากว่าที่คิด
เอกสารต้นฉบับหลายส่วนเริ่มจากยุคที่ Hadoop MapReduce, HDFS และ Spark รุ่นแรกยังเป็นภาพหลักของ Big Data ปัจจุบันองค์กรจำนวนมากใช้ object storage, cloud data warehouse, lakehouse, managed streaming และเครื่องมือที่แยก storage ออกจาก compute มากขึ้น หากนำของเดิมกลับมาสอนตรง ๆ ผู้เรียนอาจจำรายละเอียดที่หมดอายุแล้ว
อย่างไรก็ตาม การแก้ปัญหาไม่ใช่การลบ MapReduce ทิ้ง เพราะ MapReduce ทำให้เราเห็น Map, Shuffle, Partition และ Reduce ได้ชัดที่สุด SQL engine สมัยใหม่ยังคงทำงานเหล่านี้ เพียงซ่อนไว้หลัง optimizer ส่วน HDFS อาจถูกแทนด้วย object storage แต่โจทย์เรื่อง locality, bandwidth, partition size และ small files ยังไม่หายไป
รากฐานเดิม เมื่อยุคเปลี่ยน สิ่งที่ยังต้องเข้าใจ HDFS เก็บข้อมูลร่วมกับ compute Object storage แยก storage ออกจาก compute Data locality เปลี่ยนรูปเป็น caching, pushdown และการลด network I/O เขียน MapReduce job ใช้ SQL, DataFrame และ optimizer Map, Shuffle, Join และ Aggregate ยังอยู่ใน physical plan Lambda Architecture Unified batch/stream และ lakehouse Event time, state, replay และความถูกต้องของผลลัพธ์ยังเป็นโจทย์เดิม NoSQL แบ่งจาก SQL ชัดเจน NewSQL, multimodel และ managed database Partitioning, replication, consistency และ access pattern ยังต้องเลือก MLlib สำหรับโมเดลคลาสสิก Distributed training และ AI pipeline ขนาดใหญ่ การแบ่งข้อมูล การรวม gradient การสื่อสาร และ fault tolerance ยังเป็นต้นทุนหลัก
เหมือนเรียนไวยากรณ์ผ่านภาษาหลายยุค คำบางคำเลิกใช้ รูปประโยคบางแบบเปลี่ยน แต่ถ้าเข้าใจหน้าที่ของประธาน กริยา และกรรม เราจะเรียนรูปแบบใหม่ได้เร็ว การเรียน MapReduce จึงไม่ใช่การย้อนยุค แต่เป็นการเปิดฝากระโปรงเพื่อดูเครื่องยนต์ที่ SQL engine รุ่นใหม่พยายามซ่อนไว้ให้เราใช้ง่ายขึ้น
ปรัชญาการเรียนรู้
อย่ารีบเพิ่มเครื่อง ก่อนรู้ว่ากำลังเสียเวลาอยู่ที่ไหน
คำตอบที่พบบ่อยเมื่อระบบช้าคือเพิ่ม executor เพิ่ม memory หรือขยาย cluster วิธีนี้อาจช่วย แต่ก็อาจเพียงทำให้เราจ่ายแพงขึ้นเพื่อรอ Shuffle เดิม หรือกระจาย skew เดิมไปยังเครื่องจำนวนมากขึ้น
ผมอยากให้ผู้เรียนแยกอย่างน้อยสี่ต้นทุนออกจากกัน:
Computation: เวลาที่ใช้คำนวณจริง เช่น hash, compare, aggregate หรือ update modelData movement: เวลาที่ใช้ส่งข้อมูลผ่าน network, อ่านจาก storage หรือเขียนผลระหว่าง stageCoordination: เวลาที่ใช้รอ barrier, metadata, scheduler หรือ worker ที่ช้าที่สุดRepresentation: ต้นทุนจากรูปแบบข้อมูล เช่น serialization, schema, compression และจำนวน object ขนาดเล็ก
การเพิ่มเครื่องช่วยเฉพาะบางต้นทุน ถ้าปัญหาอยู่ที่ network หรือ skew จำนวนเครื่องที่เพิ่มอาจทำให้การสื่อสารมากขึ้นเสียด้วยซ้ำ ระบบขนาดใหญ่จึงไม่ได้ชนะด้วยกำลังเพียงอย่างเดียว แต่ชนะด้วยการเลือก representation, placement และ aggregation ที่เหมาะกับคำถาม
ตัวเลขเร็วขึ้นยังไม่ใช่คำอธิบาย ก่อนสรุปว่า Spark, cache หรือ cluster ทำให้งานเร็วขึ้น ควรถามว่าเทียบกับ baseline ใด รวมเวลาอ่านข้อมูลและเตรียมระบบหรือยัง จำนวนข้อมูลเท่ากันหรือไม่ และงานที่เร็วขึ้นเกิดจาก parallelism จริง หรือเพียงอ่านข้อมูลน้อยลง
ที่มาของเนื้อหาและคำขอบคุณ
ความรู้ชุดนี้เติบโตจากตำรา เอกสารประกอบการสอน งานวิจัย และนักศึกษาที่นำแนวคิดไปใช้จริง
เนื้อหาในเว็บไซต์นี้สังเคราะห์จากเอกสารของ Jimmy Lin ซึ่งช่วยวางรากฐานการคิดแบบ MapReduce และ data-intensive text processing, เอกสารของ Emanuele Della Valle และทีมจาก Politecnico di Milano ซึ่งเชื่อม Big Data เข้ากับ Variety, Velocity, NoSQL และ Data Engineering ตลอดจนงานของ Chu และคณะเรื่อง Map-Reduce for Machine Learning on Multicore รวมถึงกรณีศึกษาและเอกสารที่ผมใช้ประกอบการสอนในหลายช่วงเวลา
ผมนำแหล่งเหล่านี้มาเรียงใหม่ตามคำถามของการคำนวณ ไม่ได้คงลำดับสไลด์เดิม เพราะสิ่งที่ผมอยากให้ผู้เรียนเห็นไม่ใช่ว่าใครพูดเรื่องใดในหน้าใด แต่คือแนวคิดเหล่านั้นเชื่อมกันอย่างไร จาก data locality ไปสู่ MapReduce จาก Functional Programming ไปสู่ Monoid จาก MapReduce ไปสู่ Relational Algebra และ SQL จาก batch ไปสู่ stream และจาก graph traversal ไปสู่ iterative analytics
ส่วนสำคัญอีกส่วนหนึ่งมาจากนักศึกษาที่ถามคำถาม ทดลองกับข้อมูลจริง และบางครั้งนำหลักการที่เรียนไปแก้ปัญหาได้ไกลกว่าตัวอย่างในห้องเรียน ผู้สอนอาจเป็นคนวางเมล็ดพันธุ์ แต่วันที่ความรู้เติบโตจริง มักเป็นวันที่ผู้เรียนหยิบมันไปใช้กับโจทย์ที่ผู้สอนไม่ได้เป็นคนกำหนด
หากเนื้อหาชุดนี้ช่วยให้มองระบบได้ชัดขึ้น เครดิตย่อมเป็นของครู นักวิจัย ผู้พัฒนาเครื่องมือ และผู้เรียนจำนวนมากที่ทำให้ความรู้ชุดนี้เดินทางต่อมาได้ ส่วนข้อผิดพลาดหรือการเชื่อมโยงที่คลาดเคลื่อนเป็นความรับผิดชอบของผู้เรียบเรียงเองครับ
เกี่ยวกับเว็บไซต์นี้
จากเอกสารหลายชุด สู่เส้นเรื่องเดียว
บทเรียนทั้ง 13 บทไม่ได้เรียงตามปีของเอกสารหรือชื่อผลิตภัณฑ์ แต่เรียงตามการเปลี่ยนรูปของปัญหา เริ่มจากข้อมูลใหญ่เกินเครื่องเดียว มองศูนย์ข้อมูลเป็นคอมพิวเตอร์หนึ่งเครื่อง จัดเก็บข้อมูลแบบกระจาย ส่งงานไปหา data รวมผลก่อนส่ง ใช้ Algebra เปิดทางให้ optimizer วางแผน จากนั้นจึงขยายไปสู่ consistency, variety, streaming, graph และ scalable learning
ทุกบทมีส่วน “เมื่อยุคเปลี่ยน” เพื่อแยกให้ชัดระหว่างแนวคิดที่ยังใช้ได้กับรายละเอียดที่เปลี่ยนไป การปรับปรุงเนื้อหาไม่ได้หมายความว่าของใหม่ถูกเสมอหรือของเก่าควรถูกลบ จุดประสงค์คือให้ผู้เรียนเห็นสายวิวัฒนาการ และเข้าใจว่าเครื่องมือใหม่กำลังแก้ข้อจำกัดใดของสิ่งที่มาก่อน
ภาคปฏิบัติใช้ Spark และเครื่องมือที่ติดตั้งผ่าน Docker เพื่อให้เริ่มทดลองได้ง่าย แต่ผู้เรียนควรมองผ่าน API ไปยัง execution plan, partition, Shuffle, state และ communication เพราะสิ่งเหล่านี้คือพฤติกรรมจริงที่กำหนดว่าระบบจะขยายต่อได้หรือไม่
สรุปและขั้นตอนถัดไป
เริ่มจากคำถามหนึ่งข้อ แล้วค่อยเปิดบทที่ 1
ก่อนเริ่มเรียน ลองเลือกชุดข้อมูลหนึ่งชุดที่เคยใช้งาน แล้วสมมุติว่าพรุ่งนี้ข้อมูลนั้นใหญ่ขึ้นหนึ่งพันเท่า อย่าเพิ่งตอบว่าจะใช้ Spark หรือ Cloud ให้เขียนก่อนว่าขั้นตอนไหนจะพังก่อน: หน่วยความจำ การอ่านไฟล์ การ Join การส่งข้อมูล การรอผล หรือการเก็บสำเนา
จากนั้นเดินผ่านบทที่ 1–3 เพื่อสร้างภาพของปัญหาและสถาปัตยกรรม บทที่ 4–6 จะทำให้เห็นว่าข้อมูลกับการคำนวณต้องถูกจัดวางร่วมกันอย่างไร บทที่ 7–8 เพิ่มโจทย์เรื่องความถูกต้องและความหลากหลาย บทที่ 9–11 เปลี่ยนรูปการคำนวณไปตามข้อมูลแบบตาราง สตรีม และกราฟ ส่วนบทที่ 12–13 นำหลักทั้งหมดไปสู่การเรียนรู้และการประยุกต์กับงานจริง
เมื่อจบแต่ละบท ให้ย้อนกลับมาที่ชุดข้อมูลเดิม แล้วแก้คำตอบของตนเอง หากเริ่มพูดถึง partition, locality, Shuffle, state, skew, consistency และ approximation ได้โดยไม่ต้องเริ่มจากชื่อผลิตภัณฑ์ แปลว่ากรอบคิดกำลังเปลี่ยนจาก “ใช้ Big Data tool” ไปสู่ “ออกแบบการคำนวณสำหรับข้อมูลขนาดใหญ่”
สิ่งที่อยากให้จำเมื่อเรียนจบ ระบบที่ขยายได้ดีไม่ใช่ระบบที่ขนข้อมูลได้เร็วที่สุดเสมอไป แต่อาจเป็นระบบที่รู้ว่าข้อมูลใดไม่ต้องขน งานใดควรทำใกล้ข้อมูล ผลใดควรรวมก่อนส่ง และคำตอบใดไม่จำเป็นต้องแม่นยำเกินกว่าที่โจทย์ต้องการ
Big Data จึงไม่ใช่วิชาว่าด้วยข้อมูลที่ใหญ่เพียงอย่างเดียว แต่เป็นวิชาว่าด้วยการตัดสินใจว่าอะไรควรเคลื่อนที่ อะไรควรอยู่กับที่ อะไรควรคำนวณพร้อมกัน และอะไรควรถูกย่อก่อนที่ระบบจะต้องแบกรับมันครับ
เริ่มอ่านบทที่ 1: ทำไมต้อง Big Data? →
Warin Wattanapornprom, PhD.
Big Data Analytics · Warin Wattanapornprom, PhD. · เรียบเรียงและปรับปรุงสำหรับการเรียนรู้ในปี 2026