บทที่ 8: Queries, Modeling, and Transformation
3 min readจุดประสงค์ของ Transformation
เปลี่ยน raw data → ข้อมูลที่ stakeholders ใช้ได้จริง ความแตกต่างระหว่าง query (แค่เรียกดู) กับ transformation (บันทึกผลลัพธ์ให้ downstream ใช้ต่อ)
Figure 8-1. Transformations allow us to create value from data
Life of a Query
ก่อนจะ optimize query ต้องเข้าใจก่อนว่า database ทำอะไรบ้างตอนรัน query หนึ่งครั้ง — 4 ขั้นตอนหลัก: (1) compile/parse SQL เพื่อเช็ค syntax และสิทธิ์การเข้าถึง (2) แปลงเป็น bytecode (3) query optimizer วิเคราะห์ bytecode เพื่อหาลำดับการทำงานที่ประหยัดที่สุด (4) execute แล้วคืนผลลัพธ์
Figure 8-2. The life of a SQL query in a database
Data Modeling Approaches
การ model ข้อมูลคือการค่อยๆ ทำให้แนวคิดเป็นรูปธรรมขึ้นเรื่อยๆ ผ่าน 3 ระดับ: Conceptual (business logic/entities ระดับสูง เช่น ER diagram), Logical (เพิ่ม data type, primary/foreign keys), Physical (implementation จริงใน database เฉพาะเจาะจง) — พร้อมกับแนวคิดเรื่อง grain (ระดับความละเอียดของข้อมูล ควร model ที่ grain ละเอียดที่สุดเท่าที่จะทำได้ เพราะ aggregate ทีหลังได้ง่ายกว่า reverse กลับ)
Figure 8-12. The continuum of data models: conceptual, logical, and physical
| Approach | แนวคิด | จุดเด่น | จุดอ่อน |
|---|---|---|---|
| Inmon | Top-down, normalized (3NF — Third Normal Form, ลดความซ้ำซ้อนของข้อมูล), enterprise-wide | Single source of truth ทั้งองค์กร | ช้า, ซับซ้อน |
| Kimball | Bottom-up, star schema (facts + dimensions) | Business users เข้าใจง่าย, query เร็ว | ข้อมูลซ้ำซ้อน, ไม่เหมาะกับ streaming |
| Data Vault | Hubs + Links + Satellites, insert-only | ยืดหยุ่น, audit-friendly | Business logic ต้อง interpret ตอน query |
| Wide Denormalized | ทุกอย่างใน table เดียว | ง่าย, cloud storage ถูก | สูญเสีย business logic |
Kimball star schema ประกอบด้วย fact table (ตัวเลข/เหตุการณ์ แคบ-ยาว, append-only) ล้อมรอบด้วย dimension tables (คุณลักษณะ กว้าง-สั้น) — dimension ที่ใช้ร่วมกันหลาย fact table เรียกว่า conformed dimension ส่วนการเปลี่ยนแปลงของ dimension ตามเวลาจัดการด้วย SCD (Slowly Changing Dimension): Type 1 (overwrite ทับของเดิม), Type 2 (insert record ใหม่ + เก็บ effective date — ใช้บ่อยที่สุด), Type 3 (เพิ่ม column ใหม่แทนที่จะเพิ่ม row)
Figure 8-14. A Kimball star schema, with facts and dimensions
Data Vault แยก 3 ส่วน: Hub (เก็บ business key ที่ unique, insert-only), Link (ความสัมพันธ์ many-to-many ระหว่าง hub), Satellite (attribute/context ที่ผูกกับ hub หรือ link) — query จะเริ่มจาก hub แล้ว join ไปหา satellite ที่มี attribute ที่ต้องการ
Figure 8-15. Data Vault tables: hubs, links, and satellites connected together
Query Optimization
- Prejoin data ถ้า analytics queries join เดิมซ้ำๆ
- Pruning: ใช้ partition + cluster key เพื่อลด data scan
- Columnar databases: select เฉพาะ columns ที่ต้องการ
- Materialized views: precompute ผลลัพธ์
- Explain plan: ใช้ EXPLAIN เพื่อดู query execution plan
- CTEs (Common Table Expressions): ใช้แทน nested subqueries — อ่านง่ายกว่า, performance มักดีกว่า
- Row explosion: ระวัง many-to-many join ที่ key ซ้ำกันมากๆ จะคูณจำนวน row ออกมามหาศาลจนกิน resource หรือ query fail
Transformation Patterns
- ETL vs ELT: ปัจจุบัน ELT กลายเป็น mainstream เพราะ cloud warehouses มีพลังสูง
- SQL vs Code-based: SQL = declarative, ใช้เมื่อ transformation ง่าย; Spark/PySpark = ใช้เมื่อซับซ้อน
- Streaming Transformations: micro-batch (Spark Streaming) vs true streaming (Flink/Beam)
dbt และ Modern Transformation Tools
- dbt (Data Build Tool): revolutionize การทำ transformation — ทำให้ analysts เขียน in-database transformations ด้วย SQL
- Data engineer เปลี่ยนบทบาทจากคนสร้าง transformations มาเป็นคนตั้ง code repository + CI/CD pipeline