Micro-partition: หัวใจที่ทำให้ Snowflake หา data เจอเร็วโดยไม่มี index

ลองนึกภาพตารางข้อมูลที่มีอยู่ร้อยล้านแถว คุณรัน query กรองเอาเฉพาะข้อมูลของวันเดียว แล้วผลลัพธ์เด้งกลับมาภายในไม่กี่วินาที — ทั้งที่คุณไม่เคยสร้าง index (ดัชนีช่วยค้นหา) ให้มันเลยสักครั้ง ใน Snowflake เรื่องแบบนี้เป็นเรื่องปกติ และเบื้องหลังความเร็วนั้นมีพระเอกตัวจริงชื่อ micro-partition (ก้อนข้อมูลย่อยที่ Snowflake แบ่งให้เองโดยอัตโนมัติ) บทความนี้จะพาไปเข้าใจว่ามันทำงานยังไง ทำไมถึงไม่ต้องมี index และปี 2026 Snowflake พามันไปไกลถึงไหนแล้ว

Snowflake ไม่ให้คุณสร้าง partition เอง — แล้วมันแบ่งข้อมูลยังไง

ในฐานข้อมูลแบบดั้งเดิม การ “แบ่ง partition” (ซอยตารางใหญ่เป็นส่วนย่อย) เป็นงานที่ DBA ต้องนั่งออกแบบเอง ว่าจะซอยตามคอลัมน์ไหน ขนาดเท่าไร แต่ใน Snowflake แนวคิดนี้พลิกกลับด้าน — ไม่มีคำสั่ง CREATE PARTITION ให้ใช้ คุณแค่ insert หรือ load ข้อมูลเข้าตาราง แล้ว Snowflake จะหั่นข้อมูลก้อนนั้นออกเป็นชิ้นเล็ก ๆ ที่เรียกว่า micro-partition ให้เองทั้งหมด

micro-partition แต่ละก้อนเก็บข้อมูลราว 50–500 MB เมื่อยังไม่บีบอัด (ขนาดจริงบนดิสก์เล็กกว่านี้เพราะถูกบีบอัดเสมอ) และข้อมูลข้างในถูกจัดเก็บแบบ columnar (เรียงตามคอลัมน์ ไม่ใช่ตามแถว) ตัวไฟล์จริงไปวางอยู่บน object storage ของคลาวด์ที่คุณเลือก — S3 ของ AWS, Blob ของ Azure หรือ GCS ของ Google — แต่คุณมองไม่เห็นและไม่ต้องไปยุ่งกับมันเลย Snowflake ซ่อนและจัดการให้หมด

ความ “เก็บแบบบีบอัด” นี้ไม่ใช่แค่เรื่องเทคนิค มันมีผลกับบิลจริง ราคาเก็บข้อมูลแบบ on-demand อยู่ที่ราว 23 ดอลลาร์ต่อ TB ต่อเดือน (เรต AWS US East) และเพราะ Snowflake บีบอัดข้อมูลให้อัตโนมัติราว 3 ต่อ 1 ในงานทั่วไป ข้อมูลดิบ 30 TB จึงอาจเหลือที่คิดเงินจริงราว 10 TB เท่านั้น

จุดที่หลายคนสับสน: micro-partition ไม่ใช่ partition ที่คุณตั้งเอง และไม่ใช่ไฟล์ที่คุณเข้าไปแก้ได้ มันคือหน่วยที่ Snowflake ใช้ “จัดบ้าน” ข้อมูลของคุณเบื้องหลัง — งานของคุณคือใส่ข้อมูลเข้าไป ที่เหลือเป็นเรื่องของระบบ

ความฉลาดอยู่ที่ metadata ไม่ใช่ที่ตัวข้อมูล

ถ้าแค่หั่นข้อมูลเป็นก้อน ๆ ก็คงไม่มีอะไรพิเศษ ความฉลาดจริง ๆ อยู่ตรงที่ — สำหรับ micro-partition ทุกก้อน Snowflake จะจดบันทึก metadata (ข้อมูลกำกับ) เอาไว้โดยอัตโนมัติ ที่สำคัญที่สุดคือ ช่วงค่าต่ำสุด–สูงสุด (min/max) ของแต่ละคอลัมน์ ในก้อนนั้น รวมถึงจำนวนค่าที่ไม่ซ้ำกัน และคุณสมบัติอื่น ๆ ที่ช่วยวางแผน query

ลองเทียบกับการย้ายบ้านที่คุณติดป้ายหน้ากล่องว่าข้างในมีอะไร เวลาจะหา “จานชาม” คุณเดินผ่านกล่องที่เขียนว่า “หนังสือ” หรือ “เสื้อผ้า” ได้เลยโดยไม่ต้องเปิด เพราะป้ายบอกชัดว่าไม่มีของที่หา Snowflake ทำแบบเดียวกัน — ก่อนจะไปอ่านข้อมูลจริง มันเปิดดู metadata ของแต่ละ micro-partition ก่อน ก้อนไหนที่ช่วงค่าไม่ครอบคลุมเงื่อนไขใน WHERE ของคุณ ก็ถูก ข้ามทั้งก้อน ไม่ต้องอ่านเลย กลไกนี้เรียกว่า pruning (การตัดก้อนที่ไม่เกี่ยวทิ้ง)

ผลพลอยได้ของ columnar storage ก็เสริมเข้ามาอีกชั้น — ถ้า query ของคุณ SELECT มาแค่ 3 คอลัมน์จากตารางที่มี 50 คอลัมน์ Snowflake อ่านแค่ 3 คอลัมน์นั้น ข้ามอีก 47 คอลัมน์ได้เลย ไม่ต้องลากทั้งแถวขึ้นมา และในบางกรณี optimizer ตอบ query ได้จาก metadata ล้วน ๆ โดยไม่แตะข้อมูลจริงด้วยซ้ำ เช่น SELECT COUNT(*) หรือ SELECT MAX(order_date) เพราะคำตอบมีอยู่ในป้ายกำกับอยู่แล้ว

หัวใจสำคัญ: Snowflake ไม่อ่านข้อมูลให้น้อยลงด้วยการ “ค้นเก่งขึ้น” แต่ด้วยการ “รู้ว่าตรงไหนไม่ต้องอ่าน” — ยิ่ง prune ทิ้งได้มาก ยิ่งอ่านน้อย ยิ่งเร็วและถูกลง

ไม่มี index แล้วถ้าวันหนึ่ง pruning เริ่มแย่ล่ะ

นี่คือจุดที่คนสาย RDBMS ต้องปรับความคิด — Snowflake ไม่มี index แบบดั้งเดิม ไม่มี CREATE INDEX ไม่มี B-tree ให้สร้าง สิ่งที่ทำหน้าที่คล้าย index คือ metadata ของ micro-partition ที่เกิดขึ้นเองอัตโนมัติผ่านการ pruning นั่นแหละ

ตอนเริ่มต้นคุณแทบไม่ต้องทำอะไรเลย เพราะเวลา load ข้อมูลที่ไหลเข้ามาตามลำดับ (เช่น log ที่เข้ามาตามวันที่) ข้อมูลจะเรียงตัวตามวันที่ใน micro-partition โดยธรรมชาติ เรียกว่า natural clustering และ pruning ตามวันที่ก็ทำงานได้ดี ปัญหาเริ่มเมื่อตารางโตขึ้นเรื่อย ๆ และมีการแก้ไขข้อมูล (insert/update/delete) ปนเข้ามา ข้อมูลเริ่มกระจายปนกันข้ามก้อน ป้ายบนกล่องเริ่ม “กว้าง” จนข้ามไม่ได้ — กล่องเดียวมีทั้งข้อมูลเดือนมกราถึงธันวา pruning เลยแย่ลง

สัญญาณเตือนดูได้จาก Query Profile (เครื่องมือวิเคราะห์ query): ถ้า partitions_scanned (จำนวนก้อนที่สแกนจริง) เกือบเท่ากับ partitions_total (จำนวนก้อนทั้งหมด) แปลว่าแทบไม่ได้ prune อะไรเลย ทางแก้คือตั้ง clustering key เพื่อบอก Snowflake ว่า “ช่วยจัดเรียงข้อมูลตามคอลัมน์นี้ให้หน่อย” ป้ายบนกล่องจะได้แคบลงและ prune ได้ดีอีกครั้ง แต่ก่อนจะรีบเปิด มีจังหวะที่ควรรู้:

• ควรใช้เมื่อ — ตารางใหญ่ระดับหลาย TB, query ส่วนใหญ่กรองหรือ join บนคอลัมน์เดิม ๆ ซ้ำ ๆ และเป็นงานอ่านมากกว่าเขียน
• เลือกคอลัมน์ให้พอดี — อย่าใช้คอลัมน์ที่ค่าซ้ำเยอะเกิน (เช่น true/false ที่ prune ไม่ได้ผล) หรือละเอียดเกิน (เช่น timestamp ระดับวินาที ควรห่อด้วย TO_DATE() ลดความละเอียดก่อน) และไม่ควรเกิน 3–4 คอลัมน์ต่อ key
• ระวังค่าใช้จ่าย — Automatic Clustering ที่คอยจัดเรียงให้เบื้องหลังกิน credit ต่อเนื่อง Snowflake เองยังเตือนว่าตัวประเมินค่าใช้จ่ายอาจคลาดเคลื่อนได้ถึง 100% หรือมากกว่า ถ้าไม่อยากให้มันทำงานก็สั่ง SUSPEND RECLUSTER ได้

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

ปี 2026: Snowflake เริ่มจัด pruning ให้เองด้วย Optima

จุดที่น่าตื่นเต้นที่สุดของปีนี้คือ Snowflake กำลังทยอยเอาภาระการ tune ออกจากมือคน ปี 2026 บริษัทเปิดตัว Snowflake Optima ฟีเจอร์ที่ทำงานบน Gen2 warehouse (compute รุ่นใหม่) ซึ่ง สร้าง search index ที่ซ่อนอยู่ให้อัตโนมัติ สำหรับ query แบบค้นหาเฉพาะจุด โดยที่คุณไม่ต้องสั่ง ALTER TABLE อะไรเลยสักคำสั่ง

ตัวเลขที่ Snowflake รายงานน่าสนใจมาก ในเคสลูกค้าสายยานยนต์รายหนึ่ง Optima ดันอัตราการ prune ของ micro-partition จาก 30% ขึ้นไปเป็น 96% ทำให้ query ค้นหาเฉพาะจุดที่เคยใช้เวลา 17 วินาที เหลือเพียงราว 1 วินาที และโดยรวม Snowflake เคลมว่าเร่งงานบางประเภทได้ สูงสุดถึง 54 เท่า พร้อมกับ prune micro-partition รวมกันหลายพันล้านก้อนต่อวันให้ลูกค้าหลายร้อยราย

แปลเป็นภาษาคนคือ — สิ่งที่เมื่อก่อนคุณต้องคอยดู Query Profile แล้วตัดสินใจเปิด clustering key เองด้วยมือ ตอนนี้ระบบเริ่มมองออกและจัดการให้เองในเบื้องหลัง นี่ไม่ได้แปลว่าคุณไม่ต้องเข้าใจ micro-partition อีกต่อไป — ตรงกันข้าม มันแปลว่าคุณต้องเข้าใจกลไกพอที่จะ อ่านออกว่าระบบทำอะไรให้ และจุดไหนที่มันยังช่วยไม่ได้ เพราะ Optima เก่งเรื่อง point lookup แต่ query ที่กรองช่วงกว้างหรือ aggregate หนัก ๆ ก็ยังเป็นคนละเรื่องที่ต้องคิดเอง

micro-partition ปะทะ Iceberg: เก็บใน format เปิด แต่ยังได้ pruning

อีกแรงสั่นสะเทือนของปี 2026 คือ Iceberg tables ตารางอีกชนิดที่ Snowflake รองรับเต็มตัว ความต่างหลักอยู่ที่ “format ของไฟล์” — ตารางปกติของ Snowflake เก็บข้อมูลใน micro-partition รูปแบบเฉพาะของ Snowflake เอง ส่วน Iceberg เก็บข้อมูลเป็นไฟล์ Parquet ตามมาตรฐานเปิด Apache Iceberg วางไว้บน object storage ของคุณเองโดยตรง

ข้อแลกเปลี่ยนจึงชัดเจน:

• เปิดและใช้ร่วมกับเครื่องมืออื่นได้ — เครื่องมืออย่าง Spark หรือ Trino อ่านข้อมูลชุดเดียวกันได้ ไม่ถูกล็อกไว้ใน Snowflake และปี 2026 Snowflake ทำให้ประสบการณ์นี้เป็นแบบ managed เต็มรูปผ่าน Horizon Catalog
• ค่าเก็บข้อมูลจ่ายตรงให้คลาวด์ — storage ของ Iceberg ถูกคิดเงินโดย cloud provider ไม่ใช่ Snowflake ซึ่งทำให้การคุมต้นทุนซับซ้อนขึ้นเล็กน้อย
• ได้ฟีเจอร์สาย open table format — เช่น schema evolution (แก้โครงตารางได้ยืดหยุ่น), snapshot isolation และ time travel

ที่น่าสนใจคือแนวคิด pruning/clustering ไม่ได้หายไปไหน — Snowflake ออก Table Optimization Service ที่เอางาน compaction (รวมไฟล์เล็กให้ใหญ่ขึ้น) กับ Automatic Clustering มาดูแลตาราง Iceberg ด้วยมาตรฐานเดียวกับ storage ดั้งเดิม และรายงานว่าลดเวลารันบนเบนช์มาร์กภายใน TPC-DS ขนาด 10 TB บน Iceberg ลงได้ราว 35% พูดอีกแบบคือ ต่อให้คุณย้ายไปเก็บใน format เปิด ความเข้าใจเรื่อง micro-partition และการจัดเรียงข้อมูลก็ยังเป็น mental model เดียวกันที่ใช้ได้

สิ่งที่ micro-partition สอนเราจริง ๆ

ถ้าจะสรุปเป็นประโยคเดียว — ปรัชญา storage ของ Snowflake คือ “คุณไม่ต้องจัดการที่เก็บข้อมูล ปล่อยให้ metadata ทำงานแทน” คุณไม่ตั้ง partition ไม่สร้าง index ไม่แตะไฟล์ ระบบหั่นเป็น micro-partition จดป้ายกำกับ แล้วใช้ป้ายนั้นตัดงานที่ไม่จำเป็นทิ้งให้เอง

และทิศทางปี 2026 ก็ชัดว่าแม้แต่ขั้นตอน optimization ที่เคยต้องทำมือ (อย่าง clustering) ก็กำลังถูกทำให้อัตโนมัติมากขึ้นเรื่อย ๆ ผ่าน Optima และ Table Optimization Service แต่นั่นยิ่งทำให้การเข้าใจกลไกพื้นฐานสำคัญขึ้น ไม่ใช่ลดลง — เพราะคนที่รู้ว่า pruning ทำงานยังไง จะอ่านบิล อ่าน Query Profile และตัดสินใจได้ว่าเมื่อไรควรปล่อยให้ระบบจัดการ เมื่อไรต้องลงมือเอง ไม่ว่าข้อมูลจะอยู่ใน micro-partition ดั้งเดิมหรือใน Iceberg format เปิด หลักคิดเดียวกันนี้คือสิ่งที่แยกคนที่ “ใช้ Snowflake เป็น” ออกจากคนที่แค่ “รัน query ได้”