Big Data Analytics · บทที่ 8 จาก 13

Variety และ Data Integration

ปริมาณข้อมูลแก้ได้ด้วยการกระจาย (บทที่ 4) ความเร็วแก้ได้ด้วย streaming (บทที่ 10) — แต่ความหลากหลายของข้อมูล (Variety) ต้องแก้ด้วยวิธีคิดที่ต่างออกไปโดยสิ้นเชิง: การออกแบบ pipeline ที่ยอมรับว่าไม่มี schema ตายตัวตั้งแต่ต้น

📚

สังเคราะห์จากเอกสาร "Taming Variety" ของ Emanuele Della Valle และ "Data Engineering & Data Science Pipeline" (Politecnico di Milano) ที่ใช้ประกอบวิชา

1Schema-on-Write vs. Schema-on-Read

Schema-on-Write (แนวคิดดั้งเดิม)

Collect Data
Apply Complex Schema
Write Data
Analyse (ซ้ำได้หลายครั้ง)

ปัญหา: ต้องถกกันนานว่า schema ควรเป็นอย่างไรถึงจะรองรับทุกความต้องการ — บาง analysis ทำไม่ได้อีกต่อไปเพราะข้อมูลที่ต้องการถูกทิ้งไปตอนเขียนแล้ว (schema ไม่ได้เก็บไว้) และถ้าความต้องการจริง ๆ มีอยู่ มักนำไปสู่การสร้าง data silo แยกต่างหาก

Schema-on-Read (แนวคิดที่ Big Data นำมาใช้)

Collect Data
Write Data (เก็บแบบดิบ ไม่มี schema ตายตัว)
Apply Simple Schema (ตอน query แต่ละครั้ง)
Analyse

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

2Logical Architecture ของ Data Engineering Pipeline

โครงสร้างแบบชั้น (จากล่างขึ้นบน)

ชั้น	หน้าที่
Data Ingestion	นำเข้าข้อมูลจากหลายแหล่ง (data source #1..n) ผ่าน integration service ที่จัดการ transportation, message routing, transaction management, security, transformation
Raw Big Data Landing Zone	เก็บข้อมูลดิบทุกรูปแบบ (csv, json, txt) แทบไม่มี schema — นี่คือขั้น "Write Data" ของ schema-on-read
Data Wrangling	ทำความสะอาดข้อมูลดิบ: Understand (ประเภทข้อมูล มี outlier/missing value ไหม) → Cleanse (ลบ outlier เติมค่าที่หาย แปลงประเภทข้อมูล) → Augment (รวมข้อมูลจากหลายแหล่ง) → Shape (จัดรูปแบบให้เหมาะกับการวิเคราะห์)
Big Data Long Term Storage	เก็บในรูปแบบที่เหมาะกับการ query เช่น ORC, Parquet (columnar format) แต่ยังไม่มี schema แบบบังคับรวมศูนย์
Data View / ETL	สร้าง "มุมมอง" ของข้อมูลตาม use case แต่ละแบบ (Data View #1, #2, ..., #n) แต่ละมุมมองมี ETL ของตัวเอง
BI Layer	Business Intelligence report/dashboard หรืออัลกอริทึมเฉพาะทาง (เช่น process optimization) ที่ใช้ Data View เป็น input

ทำไมต้องมีหลายชั้น ไม่ใช่ ETL ครั้งเดียวจบ

ข้อมูลดิบชุดเดียวกันอาจต้องถูกมองผ่านหลาย "มุมมอง" ที่ต่างกันสำหรับ use case ต่างกัน — เช่น log การใช้งานเว็บชุดเดียวกัน อาจถูกมองเป็น "Data View สำหรับวิเคราะห์พฤติกรรมผู้ใช้" และ "Data View สำหรับตรวจจับการโจมตี" พร้อมกัน การแยกชั้น Data View ออกจาก raw storage ทำให้เพิ่ม use case ใหม่ได้โดยไม่กระทบข้อมูลดิบต้นทาง

3Data Ingestion และ Data Wrangling ในรายละเอียด

ขั้นตอน	รายละเอียด
Data Ingestion	นำเข้าข้อมูลจากหลายแหล่งพร้อมกัน มักรวมไฟล์เล็กจำนวนมากให้เป็นไฟล์ขนาดร้อย MB (ตาม GFS design decision ในบทที่ 4) และแตกไฟล์ใหญ่เกินไปให้เล็กลงในระดับที่เหมาะสม
Understand	ระบุประเภทข้อมูล (quantitative/qualitative/categorical) หา outlier และข้อมูลที่ขาดหาย
Cleanse	ลบ outlier, เติมค่าที่ขาดหาย, แปลงค่าตัวเลขเป็น categorical ถ้าจำเป็นสำหรับการวิเคราะห์
Augment	รวมข้อมูลจากหลายแหล่งเข้าด้วยกัน หรือรวมภายในแหล่งเดียวกัน (aggregate)
Shape	จัดรูปแบบให้เหมาะกับการวิเคราะห์ที่ต้องการ (เช่น columnar สำหรับ analytics, row-based สำหรับ transaction)

4Variety ในเชิงข้อมูล: มิติที่มากกว่าแค่ "structured vs unstructured"

มิติของ Variety จากเอกสารต้นฉบับ

Content: ภาพ, สเปกตรัม, time series
Form: ข้อความ, ตัวเลข, เชิงสัมพันธ์, กราฟิก, geospatial
Format: plain-text, csv, fixed-width, Excel, HTML table
Structure: unstructured text, semi-structured email, semantically-marked-up document
Source: มนุษย์สร้างเอง, sensor log อัตโนมัติ, เครื่องมือวิทยาศาสตร์, การจำลอง
Meaning: "จานนี้ร้อน" — ความหมายที่ตีความได้หลายแบบขึ้นกับบริบท
Representation: "14 ม.ค. 2016" กับ "2016/01/14" คือข้อมูลเดียวกันแต่ representation ต่างกัน

Data Integration ไม่ใช่แค่เรื่องเทคนิค

การรวมข้อมูลจากหลายแหล่งให้เป็น "มุมมองเดียวของลูกค้า" (Single View to the Customer) เช่น รวมข้อมูลจาก social media, banking, gaming, purchase history เข้าด้วยกัน ต้องแก้ปัญหาที่ representation/meaning ไม่ตรงกันก่อนเสมอ ไม่ใช่แค่เชื่อมท่อข้อมูลเข้าด้วยกันทางเทคนิค

5เมื่อยุคเปลี่ยน: จาก Data Lake สู่ Data Lakehouse

แล้ว · Data Lake แบบดั้งเดิม (~2015-2020)

ตอนนี้ · 2026

Schema-on-read แก้ปัญหาความยืดหยุ่นได้ แต่แลกมาด้วยการเสีย ACID transaction — เขียนไฟล์ทับซ้อนกัน (concurrent write) อาจทำให้ query อ่านข้อมูลไม่สมบูรณ์ระหว่างที่กำลังเขียน

Data Lakehouse (Delta Lake, Apache Iceberg, Apache Hudi) นำ ACID transaction log กลับมาใส่ในสถาปัตยกรรม data lake — ได้ทั้งความยืดหยุ่นของ schema-on-read และความน่าเชื่อถือของ transaction แบบ data warehouse ไปพร้อมกัน (คล้ายกับที่ NewSQL พยายามทำในบทที่ 7 แต่สำหรับ analytical workload แทน transactional)

Data View/ETL ถูกเขียนแยกกันสำหรับแต่ละ use case โดยทีมต่างกัน มักเกิดความซ้ำซ้อนของ logic

แนวคิด Data Mesh เสนอให้แต่ละทีมเป็นเจ้าของ "data product" ของตัวเอง (คล้าย microservice แต่สำหรับข้อมูล) พร้อม contract ที่ชัดเจนว่าข้อมูลแต่ละชุดมีรูปแบบและคุณภาพอย่างไร ลดการพึ่งพาทีมกลางทีมเดียวที่ดูแล pipeline ทั้งหมด

Variety เน้นรูปแบบข้อมูลดั้งเดิม (text, image, JSON, geospatial)

เพิ่มมิติใหม่: ข้อมูลที่สร้างโดย AI (synthetic data, LLM-generated text) ปะปนกับข้อมูลจริง ทำให้การ "Understand" ในขั้น data wrangling ต้องเพิ่มคำถามใหม่ "ข้อมูลนี้มนุษย์สร้างหรือ AI สร้าง" เข้าไปด้วย

คำถามซ้อมสอบ

เปรียบเทียบ Schema-on-Write กับ Schema-on-Read พร้อมอธิบายข้อดี-ข้อเสียของแต่ละแบบ
อธิบาย logical architecture ของ data engineering pipeline ตั้งแต่ ingestion จนถึง BI layer
อธิบายขั้นตอน Data Wrangling ทั้ง 4 ขั้น (Understand, Cleanse, Augment, Shape) พร้อมยกตัวอย่าง
ยกตัวอย่างมิติของ Variety ที่ไม่ใช่แค่ "structured vs unstructured" อย่างน้อย 3 มิติ
อธิบายว่า Data Lakehouse แก้ปัญหาอะไรที่ Data Lake แบบดั้งเดิมทำไม่ได้