สถาปัตยกรรม Snowflake 3 ชั้น: storage / compute / services เข้าใจครบในบทเดียว

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

สรุปสั้น ๆ: Snowflake แบ่งงานเป็น 3 ชั้นที่ทำงานอิสระต่อกัน — Storage (เก็บ data ก้อนกลางก้อนเดียว), Compute (virtual warehouse ที่แยกพลังของใครของมัน), และ Cloud Services (ตัวประสานงานเบื้องหลัง auth/metadata/optimizer) หัวใจอยู่ที่การ แยก storage ออกจาก compute ทำให้ขยายแต่ละส่วนได้อิสระ หลายทีมใช้ data ชุดเดียวกันพร้อมกันได้ และจ่ายเฉพาะ compute ที่ใช้จริง ของใหม่ AI ปี 2026 ทั้งหมด “วางทับ” สามชั้นนี้ ไม่ได้แทนที่มัน

บทความนี้เป็นเสาหลักของชุดเรื่อง Snowflake บนเว็บเรา — อ่านจบแล้วจะเห็นภาพรวมทั้งระบบ และรู้ว่าควรเจาะลึกต่อตรงไหน

แยก storage ออกจาก compute — ไอเดียเดียวที่อธิบายทุกอย่าง

หัวใจของ Snowflake คือการแยก “ที่เก็บข้อมูล” (storage) ออกจาก “พลังประมวลผล” (compute) อย่างเด็ดขาด ศัพท์เรียกว่า decoupled storage and compute — ฟังดูเป็นเรื่องเทคนิคเล็ก ๆ แต่มันคือสาเหตุที่ Snowflake ทำหลายอย่างที่ฐานข้อมูลแบบเดิมทำไม่ได้

ลองเทียบกับ data warehouse ดั้งเดิม: compute กับ storage มัก ผูกติดกัน อยากได้พื้นที่เก็บมากขึ้นก็ต้องจ่ายค่าเครื่องแรงขึ้นไปด้วย อยากได้เครื่องแรงขึ้นก็ต้องเพิ่มพื้นที่เก็บตามไป — ขยายได้แบบ “เพิ่มทั้งคู่หรือไม่เพิ่มเลย” ทั้งเปลืองและไม่ยืดหยุ่น

Snowflake อธิบายตัวเองว่าเป็นลูกผสมระหว่างสถาปัตยกรรมแบบ shared-disk กับ shared-nothing — เอาข้อดีของทั้งสองมารวมกัน: storage เป็นก้อนกลางที่ทุกคนเห็นเหมือนกัน (แบบ shared-disk จึงไม่มีปัญหาข้อมูลไม่ตรงกัน) แต่ compute แยกอิสระเป็นก้อนของใครของมัน (แบบ shared-nothing จึงไม่แย่ง resource กัน) พอเข้าใจประโยคนี้ ที่เหลือจะร้อยกันเป็นเรื่องเดียว

คิดง่าย ๆ: โกดังกลางหนึ่งแห่ง แต่แต่ละทีมมีรถโฟล์คลิฟท์ของตัวเอง — ของอยู่ที่เดียว ทุกทีมเข้าไปหยิบพร้อมกันได้โดยไม่ต้องแย่งรถกัน

ทีนี้มาดูทีละชั้นจากล่างขึ้นบน

ชั้นล่าง: Storage — โกดังกลางที่ฉลาดเรื่องหยิบของ

ชั้น Storage คือที่เก็บ data จริงทั้งหมด แต่จุดที่หลายคนไม่รู้คือคุณไม่ได้เห็นไฟล์จริงและไม่ต้องจัดการมันเลย Snowflake รับหน้าที่จัด organize, บีบอัด, วางโครงสร้าง และเก็บ metadata ให้ทั้งหมด ตัว data จริงไปวางอยู่บน cloud object storage ของ provider ที่คุณเลือก — AWS ก็คือ S3, Azure ก็คือ Blob Storage, GCP ก็คือ Google Cloud Storage

data ในชั้นนี้ถูกเก็บแบบ columnar (เรียงตามคอลัมน์ ไม่ใช่ตามแถว) และ compressed (บีบอัด) โดยอัตโนมัติ ผลของ columnar คือ ถ้า query ของคุณ SELECT มาแค่ 3 คอลัมน์จากตารางที่มี 50 คอลัมน์ Snowflake อ่านแค่ 3 คอลัมน์นั้น ข้ามอีก 47 คอลัมน์ได้เลย ไม่ต้องลากทั้งแถวขึ้นมา

ความฉลาดจริง ๆ อยู่ที่วิธีที่ Snowflake หั่นเก็บ data เป็นก้อนเล็ก ๆ เรียกว่า micro-partition (ก้อนละ 50–500 MB ของข้อมูลก่อนบีบอัด สร้างให้อัตโนมัติตอน load ไม่มีคำสั่ง CREATE PARTITION ให้ตั้งเอง) แต่ละก้อนมี metadata เช่นช่วงค่า min/max ของแต่ละคอลัมน์กำกับไว้ พอคุณ query แบบมีเงื่อนไข Snowflake เปิดดู metadata ก่อน ก้อนไหนที่ช่วงค่าไม่ตรงเงื่อนไขก็ ข้ามทั้งก้อน ไม่ต้องไปอ่าน — กลไกนี้เรียกว่า pruning และมันคือเหตุผลที่ Snowflake หา data เจอเร็วทั้งที่ ไม่มี index แบบ RDBMS ดั้งเดิม ให้สร้าง

• columnar — อ่านเฉพาะคอลัมน์ที่ query ใช้ ข้ามที่เหลือ
• micro-partition + metadata — ข้ามก้อนที่ไม่เกี่ยวก่อนอ่านจริง (pruning)
• ไม่มี index ให้ดูแล — metadata ทำหน้าที่คล้าย index ให้อัตโนมัติ

รายละเอียดว่า micro-partition กับ pruning ทำงานลึก ๆ ยังไง ผมแยกเขียนไว้เต็ม ๆ ใน Micro-partition: หัวใจที่ทำให้ Snowflake หา data เจอเร็วโดยไม่มี index

ชั้นกลาง: Compute — virtual warehouse ที่แยกของใครของมัน

ชั้น Compute คือที่ที่ “งานจริง” เกิดขึ้น — รัน query, ทำ insert/update/delete, load ข้อมูล หน่วยของ compute เรียกว่า virtual warehouse ซึ่งก็คือ cluster ของทรัพยากรประมวลผลที่คุณเปิด/ปิด/ปรับขนาดได้ตามใจ

ประโยคที่สำคัญที่สุดของทั้งเรื่องอยู่ตรงนี้: แต่ละ virtual warehouse เป็น compute cluster อิสระ ไม่แชร์ resource กับ warehouse ตัวอื่น นี่คือคำตอบว่าทำไมเช้าวันจันทร์ ทีม data engineer จะ load ข้อมูลหนัก ๆ ด้วย warehouse ตัวหนึ่ง พร้อมกับทีม analyst รัน dashboard ส่งผู้บริหารด้วยอีกตัวหนึ่ง โดยไม่รบกวนกันเลย — ทั้งสองอ่าน data จากโกดังกลางก้อนเดียวกัน แต่ใช้พลัง compute คนละก้อน

จุดที่มักเข้าใจผิด: การแยกกันนี้อยู่ ระหว่าง warehouse ไม่ใช่ระหว่างคนที่ใช้ warehouse ตัวเดียวกัน ถ้าคุณกับเพื่อนรัน query บน warehouse ตัวเดียวกัน ก็ยังต้องแบ่ง compute ในตัวนั้นกันอยู่ดี และเพราะ compute คือส่วนที่ใช้ credit จริง ชั้นนี้จึงเป็นที่ที่คุณจ่ายเงินมากที่สุด — เปิดใช้เมื่อไรจ่ายเมื่อนั้น พอ suspend (พัก) ก็หยุดกิน credit

compute = ชั้นที่คุณควบคุมและจ่ายเงินมากที่สุด เรื่อง sizing, scale up vs scale out, auto-suspend และการคุมบิล คือทักษะที่แยกคนที่ “ใช้ Snowflake เป็น” ออกจากคนที่ “แค่รัน query ได้”

เรื่อง sizing, การคิด credit และวิธีตั้งค่าไม่ให้บิลพุ่ง ผมลงลึกไว้ใน Virtual Warehouse คืออะไร: หน่วย compute ของ Snowflake ที่มักเข้าใจผิด

ชั้นบน: Cloud Services — ผู้จัดการที่ไม่เคยลงไปยกของ

ชั้นบนสุดคือ Cloud Services — กลุ่มบริการที่คอยประสานงานทุกอย่างในระบบ ทำงานแบบมองไม่เห็นแต่ทุก request ผ่านชั้นนี้ก่อนเสมอ หน้าที่หลักคือ authentication (คุณเป็นใคร), access control (มีสิทธิ์แตะ table นี้ไหม), metadata management, query optimization (วางแผนว่าจะรัน SQL ยังไงให้เร็วสุด) และจัดการ virtual warehouse เบื้องหลัง

ตัวอย่างที่ทำให้เห็นภาพชัดที่สุด: เวลาคุณรัน SHOW TABLES หรือ DESCRIBE TABLE — ผลกลับมาทันที โดยไม่ต้องเปิด warehouse เลยด้วยซ้ำ เพราะคำสั่งพวกนี้เป็นการถาม metadata ล้วน ๆ ซึ่งอยู่ที่ cloud services อยู่แล้ว ไม่ต้องใช้ compute ไปอ่าน data จริง เช่นเดียวกับ DDL อย่าง CREATE TABLE ก็รันได้แม้ warehouse จะ suspend อยู่ ในทางกลับกัน SELECT, DML และ COPY INTO ต้องเปิด warehouse เพราะต้องไปอ่าน/เขียน data จริงในโกดัง

• งาน metadata (DDL, SHOW, DESCRIBE, auth, ตรวจสิทธิ์) — รันบน cloud services ไม่ต้องเปิด warehouse
• งานแตะ data จริง (SELECT, DML, COPY INTO) — ต้องมี warehouse ทำงาน
• result cache — query เดิมที่รันซ้ำได้ผลทันทีเพราะ cloud services จำผลไว้ให้ ไม่ใช่เพราะ warehouse เก่งขึ้น

ระวังกับดักคำศัพท์: คำว่า “cloud” ใน cloud services layer หมายถึงบริการที่ Snowflake สร้างขึ้นเอง ไม่ใช่ cloud provider อย่าง AWS/Azure/GCP — provider เป็นแค่ infrastructure ที่ Snowflake ไปรันอยู่บนนั้น คิดว่าชั้นนี้คือ “ผู้จัดการภายในของ Snowflake” จะตรงกว่า

multi-cloud และทำไมโครงนี้ถึงทำให้ scale กับ concurrency ดี

Snowflake ไม่ได้เป็นเจ้าของ hardware เอง — มันรันบน AWS, Azure หรือ GCP ที่คุณเลือกตอนสร้าง account ทั้งสามชั้นอยู่บน provider เดียวกันสำหรับแต่ละ account และแต่ละ provider มีหลาย region ให้เลือกตามเรื่อง data residency (ข้อมูลต้องอยู่ประเทศไหน), latency และ compliance โดยทั่วไปควรเลือก provider/region ให้ตรงกับ infrastructure ที่องค์กรมีอยู่แล้ว เพื่อลดค่า data transfer และความหน่วง

พอเอาการแยก storage/compute มาต่อกับ multi-cloud จะได้สองคุณสมบัติที่เป็นจุดขายจริงของ Snowflake:

• Scale แยกอิสระ — อยากเก็บ data มากขึ้น เพิ่ม storage โดยไม่แตะ compute; อยากให้ query เร็วขึ้น เพิ่มขนาด/จำนวน warehouse โดยไม่กระทบ storage และปรับได้แม้ warehouse กำลังทำงานอยู่
• Concurrency สูง — หลายทีมรัน parallel บน data ชุดเดียวกันได้ ไม่ต้องวาง “maintenance window” หลบกันแบบฐานข้อมูลเดิม ถ้าคนเยอะจนตัวเดียวรับไม่ไหว ยังมี multi-cluster warehouse ที่เพิ่ม cluster ภายใน warehouse เดียวมารองรับ

นี่คือเหตุผลที่ scenario แนว “ทีม A ทำงานแล้วกระทบทีม B ไหม” ตอบได้แทบทั้งหมดจากหลักเดียว: data ก้อนเดียวกัน แต่ compute แยกกัน

ปี 2026: Adaptive Compute และ AI Data Cloud — ของใหม่ที่วางทับโครงเดิม

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

ตัวที่กระทบชั้น compute โดยตรงคือ Adaptive Compute — บริการ compute ที่ Snowflake ประกาศที่ Summit เดือนมิถุนายน 2026 แนวคิดคือ แทนที่คุณจะต้องเลือกขนาด warehouse เอง (XS ไปจนถึง 4XL), ตั้ง multi-cluster policy เอง, ตั้ง auto-suspend เอง — ระบบเลือกขนาด cluster, จำนวน cluster และจังหวะ suspend/resume ให้เอง per query แบบเรียลไทม์ โดยส่งงานเข้า shared pool ของ compute ที่ใช้ร่วมกันทั้ง account ในบล็อกของ Snowflake มีคนถึงกับเรียกมันว่า “warehouse ตัวสุดท้ายที่คุณต้องตั้งค่า” และเคลมตัวเลขว่าเร็วขึ้นได้ถึงราว 1.6 เท่าสำหรับงาน analytical และราว 3.5 เท่าสำหรับงาน DML หนัก ๆ

แต่จุดที่ต้องเน้น: Adaptive Compute ไม่ได้ลบล้างแนวคิด virtual warehouse — มันยังคือชั้น compute ที่แยกจาก storage เหมือนเดิม แค่เปลี่ยน “หน้าปัด” ที่คุณต้องหมุนเองให้ระบบหมุนแทน หลักการแยก storage/compute ยังอยู่ครบ ถ้าคุณเข้าใจว่าทำไมต้องแยกสองอย่างนี้ คุณก็เข้าใจว่า Adaptive Compute ไปปรับปรุงตรงไหน

ฝั่ง AI ก็เป็นเรื่องเดียวกัน — Snowflake เปลี่ยนคำเรียกตัวเองจาก “Data Cloud” เป็น “AI Data Cloud” เพื่อสื่อว่า AI ทำงาน ข้าง ๆ data ของคุณ ไม่ต้องย้าย data ออกไปไหน และอยู่ใต้ security/governance เดียวกัน feature กลุ่มนี้รวมอยู่ใต้แบรนด์ Cortex เช่น Cortex Analyst (ถามเป็นภาษาคนแล้วแปลงเป็น SQL), Cortex Search (hybrid search เป็น backend ของ RAG), Cortex AI Functions (เรียก LLM ผ่าน SQL) และ Document AI (ดึงข้อมูลจาก PDF/เอกสาร) ปี 2026 ยังเห็นของใหม่อย่าง Deep Research ใน Snowflake CoWork ที่แตกคำถามซับซ้อนออกเป็นหลายการสืบค้นรันขนานกันบน data ของคุณ และ resource budget สำหรับคุมค่าใช้จ่ายบริการ Cortex Search แบบตั้งเพดานรายเดือนได้

Key idea: ไม่ว่า Snowflake จะออกของใหม่มาเร็วแค่ไหน คำถามแรกที่ควรถามเสมอคือ “มันวางอยู่บนชั้นไหน” — เกือบทั้งหมดคือบริการที่ประสานที่ cloud services แล้วประมวลผลจริงที่ compute โดยใช้ storage เดิม ไม่ใช่ระบบใหม่ที่ต้องเรียนใหม่หมด

เข้าใจโครง แล้วที่เหลือจะง่ายขึ้นทั้งหมด

ถ้าจะจำอะไรกลับไปแค่อย่างเดียวจากบทความนี้ ให้จำสามประโยคนี้: Storage คือก้อนกลางก้อนเดียว / Compute แยกของใครของมัน / Cloud Services คือผู้ประสานงานเบื้องหลัง ตอบสามประโยคนี้ได้ คุณเข้าใจแก่นที่แท้จริงของ Snowflake แล้ว — ที่เหลือเป็นแค่รายละเอียดที่ต่อยอดจากตรงนี้

และนี่ไม่ใช่แค่เรื่องน่ารู้เฉย ๆ — สำหรับคนที่เตรียมสอบ SnowPro Core สถาปัตยกรรมสามชั้นคือหัวใจของ Domain ที่มีน้ำหนักมากที่สุดในข้อสอบ และข้อสอบชอบถามแบบ scenario (เช่น “งานนี้ต้องเปิด warehouse ไหม”, “ทีมไหนกระทบใคร”) มากกว่าถามนิยามตรง ๆ ซึ่งจะตอบได้ก็ต่อเมื่อเข้าใจ หน้าที่ของแต่ละชั้น ไม่ใช่แค่ท่องชื่อ ถ้าอยากเห็นภาพรวมว่าข้อสอบแบ่งเป็นกี่ส่วนและควรทุ่มเวลาตรงไหน อ่านต่อได้ที่ เจาะโครงสร้างข้อสอบ SnowPro Core: 5 Domain ที่ต้องรู้ก่อนเริ่มอ่าน

ลองทำแบบฝึกที่ได้ผลที่สุด: ปิดหน้าจอ หยิบกระดาษเปล่ามาวาดสี่เหลี่ยมสามชั้น เขียนหน้าที่ของแต่ละชั้นอย่างน้อยชั้นละสามอย่าง แล้วลากลูกศร — cloud services สั่งการ compute, compute อ่าน/เขียน storage ถ้าคุณวาดได้ลื่นโดยไม่ต้องเปิดดู แปลว่าคุณไม่ได้แค่ “รู้จัก” Snowflake แล้ว แต่ “เข้าใจ” มันจริง ๆ