Snowflake ปี 2026: สถาปัตยกรรม SQL และคำถามสัมภาษณ์ Data Engineer

คำถามสัมภาษณ์เกี่ยวกับ Snowflake มุ่งวัดว่า data engineer เข้าใจสถาปัตยกรรมแบบแยกส่วน (decoupled architecture) ของแพลตฟอร์มหรือไม่ ไม่ใช่แค่รู้ไวยากรณ์ SQL เท่านั้น ดีไซน์แบบ multi-cluster shared-data ที่ Snowflake เป็นผู้บุกเบิกได้แยกชั้น storage, compute และ services ออกเป็นสามชั้นที่ทำงานเป็นอิสระต่อกัน และการแยกส่วนนี้เองที่อธิบายแทบทุกการตัดสินใจเรื่องประสิทธิภาพและต้นทุนที่ทีมงานต้องเจอบนแพลตฟอร์มนี้ บทความนี้ครอบคลุมสถาปัตยกรรมของ Snowflake, รูปแบบการเขียน SQL ที่ทำให้คิวรีเร็วและประหยัดในปี 2026 รวมถึงคำถามสัมภาษณ์ที่เผยให้เห็นประสบการณ์การใช้งานจริงในระบบ production

สถาปัตยกรรม Snowflake: Storage, Compute และ Cloud Services

จุดเด่นที่นิยามสถาปัตยกรรมของ Snowflake คือ storage และ compute ถูกแยกออกจากกันในเชิงกายภาพ ข้อมูลถูกจัดเก็บเพียงชุดเดียวในชั้น storage ส่วนกลางที่รองรับด้วย cloud object store อย่าง Amazon S3 หรือ Azure Blob Storage คอมพิวต์คลัสเตอร์จำนวนเท่าใดก็ได้สามารถอ่านข้อมูลชุดเดียวกันนี้พร้อมกันโดยไม่ต้องคัดลอกข้อมูล ซึ่งเป็นแนวทางที่ทีมวิศวกรรมชุดแรกตั้งชื่อว่า multi-cluster shared data ในเปเปอร์ SIGMOD ปี 2016 ที่เปิดตัวดีไซน์นี้

ชั้น storage เก็บข้อมูลไว้ในไฟล์แบบ columnar ที่ไม่เปลี่ยนแปลง (immutable) และถูกบีบอัด เรียกว่า micro-partitions ผู้ใช้ไม่เคยต้องจัดการไฟล์เหล่านี้โดยตรง Snowflake เป็นผู้เขียนไฟล์ ติดตาม metadata และเรียกคืนพื้นที่เอง ชั้น compute ประกอบด้วย virtual warehouses ซึ่งแต่ละตัวคือคลัสเตอร์ของเซิร์ฟเวอร์ที่ Snowflake จัดสรรให้ตามความต้องการ ส่วน cloud services layer อยู่เหนือทั้งสองชั้นและทำหน้าที่ประสานงานทุกอย่าง ทั้งการ parse SQL, วางแผนคิวรี, บังคับใช้การควบคุมสิทธิ์การเข้าถึง, จัดการ transaction และเก็บ metadata ที่ทำให้ฟีเจอร์อย่าง Time Travel และ zero-copy cloning เป็นไปได้

เนื่องจากชั้นเหล่านี้เป็นอิสระต่อกัน warehouse จึงสามารถปรับขนาดหรือลบทิ้งได้โดยไม่แตะต้องข้อมูลแม้แต่ไบต์เดียว และ storage ก็ขยายได้ถึงระดับเพตะไบต์โดยไม่ต้องจัดสรร compute ใด ๆ

-- setup_warehouse.sql
-- Create an isolated compute cluster and a database.
CREATE WAREHOUSE analytics_wh
  WAREHOUSE_SIZE = 'MEDIUM'      -- 4 credits/hour, doubles each size step
  AUTO_SUSPEND = 60             -- suspend after 60s idle to stop billing
  AUTO_RESUME = TRUE            -- resume automatically on the next query
  INITIALLY_SUSPENDED = TRUE;

CREATE DATABASE sales_analytics;
USE WAREHOUSE analytics_wh;
USE DATABASE sales_analytics;

-- Storage and compute are independent: dropping the warehouse
-- leaves every table in sales_analytics untouched.

การลบ analytics_wh หลังจากสคริปต์นี้ทำงานเสร็จจะหยุดการเรียกเก็บเงินค่า compute ทั้งหมด ในขณะที่ทุกตารางยังคงคิวรีได้ทันทีที่มีการสร้าง warehouse ใหม่ การแยกส่วนแบบนี้คือแนวคิดที่สำคัญที่สุดเพียงข้อเดียวที่ต้องอธิบายให้ได้ในการสัมภาษณ์

Virtual Warehouses ขยายพลัง Compute ของ Snowflake อย่างไร

virtual warehouse คือคลัสเตอร์ compute ที่มีชื่อ และวัดขนาดเป็นหน่วยแบบไซซ์เสื้อยืด ตั้งแต่ X-Small, Small, Medium, Large ขึ้นไป การขยับขึ้นแต่ละขั้นจะเพิ่มทั้งจำนวนเซิร์ฟเวอร์และการบริโภค credit ต่อชั่วโมงเป็นสองเท่า ดังนั้น warehouse ขนาด Large จึงมีต้นทุนเป็นสี่เท่าของ Small แต่ก็ทำคิวรีที่ต้องสแกนข้อมูลหนักได้เสร็จเร็วขึ้นประมาณสี่เท่าเช่นกัน การแลกเปลี่ยนระหว่างราคากับประสิทธิภาพแบบเป็นเส้นตรงนี้หมายความว่าตัวเลือกที่ถูกที่สุดมักเป็น warehouse ที่ใหญ่กว่าแต่ทำงานในเวลาที่สั้นกว่า

มีมิติของการขยายขนาดอยู่สองแบบ และการสับสนระหว่างสองแบบนี้คือกับดักที่พบบ่อยในการสัมภาษณ์ การขยายแนวตั้ง (vertical scaling) คือการปรับขนาด warehouse เดียวให้คิวรีตัวหนึ่งทำงานเร็วขึ้น ส่วนการขยายแนวนอน (horizontal scaling) คือการเพิ่มคลัสเตอร์ให้กับ multi-cluster warehouse เพื่อรองรับคิวรีที่ทำงานพร้อมกันมากขึ้น แดชบอร์ดที่ถูกนักวิเคราะห์ 200 คนเข้าใช้พร้อมกันตอนเก้าโมงเช้าต้องการคลัสเตอร์ที่มากขึ้น ไม่ใช่คลัสเตอร์ที่ใหญ่ขึ้น ในขณะที่งาน backfill ข้อมูลนับล้านล้านแถวช่วงกลางคืนต้องการคลัสเตอร์ที่ใหญ่ขึ้น ไม่ใช่จำนวนคลัสเตอร์ที่มากขึ้น

-- scale_compute.sql
-- Multi-cluster warehouse: add clusters when concurrency rises and
-- remove them when demand falls. Each cluster is a separate MEDIUM engine.
ALTER WAREHOUSE analytics_wh SET
  MIN_CLUSTER_COUNT = 1
  MAX_CLUSTER_COUNT = 4          -- up to 4 clusters during peak load
  SCALING_POLICY = 'STANDARD';   -- favor performance over credit savings

-- Resize vertically for one heavy job, then shrink back afterward.
ALTER WAREHOUSE analytics_wh SET WAREHOUSE_SIZE = 'XLARGE';
-- ... run the heavy backfill ...
ALTER WAREHOUSE analytics_wh SET WAREHOUSE_SIZE = 'MEDIUM';

AUTO_SUSPEND และ AUTO_RESUME คือสิ่งที่ทำให้แนวทางนี้คุ้มค่าทางเศรษฐกิจ warehouse ที่ถูก suspend ไว้จะไม่มีค่าใช้จ่ายเลย และ Snowflake เรียกเก็บเงินเป็นรายวินาทีโดยมีขั้นต่ำ 60 วินาที การตั้งค่า auto-suspend ให้สั้นบน warehouse ที่ใช้แบบโต้ตอบ (interactive) ช่วยป้องกันไม่ให้คลัสเตอร์ที่ว่างงานเผาผลาญ credit ระหว่างคิวรี

Micro-Partitions และ Clustering Keys สำหรับ SQL ที่รวดเร็ว

Snowflake จัดเก็บทุกตารางเป็นชุดของ micro-partitions โดยแต่ละพาร์ทิชันบรรจุข้อมูลแบบ columnar ขนาด 50 ถึง 500 MB (ก่อนบีบอัด) สำหรับทุก micro-partition นั้น Snowflake จะบันทึกค่าต่ำสุดและค่าสูงสุดของแต่ละคอลัมน์ไว้ใน metadata เมื่อคิวรีทำการกรองบนคอลัมน์ใด optimizer จะอ่าน metadata นั้นและข้ามพาร์ทิชันใดก็ตามที่ช่วงค่าไม่มีทางตรงกับเงื่อนไข กระบวนการนี้เรียกว่า partition pruning นี่คือเหตุผลที่ Snowflake ไม่ต้องใช้ index แบบทำมือ เพราะการ pruning เกิดขึ้นโดยอัตโนมัติบนทุกคอลัมน์

การ pruning ทำงานได้ดีที่สุดเมื่อคอลัมน์ที่ใช้กรองมีความสัมพันธ์กับลำดับที่ข้อมูลถูกโหลดเข้ามา ตารางที่ถูกนำเข้าตามวันที่จะ prune คิวรีแบบช่วงวันที่ได้อย่างมีประสิทธิภาพ เมื่อตารางขนาดใหญ่ถูกกรองบ่อย ๆ บนคอลัมน์ที่ไม่เกี่ยวข้องกับลำดับการโหลด clustering key จะช่วยจัดวางแถวที่เกี่ยวข้องกันให้อยู่ด้วยกันข้าม micro-partitions เพื่อให้การ pruning ยังคงมีประสิทธิภาพเมื่อตารางเติบโตขึ้น

-- clustering.sql
-- Filters on naturally ordered columns prune partitions with no index.
SELECT order_date, SUM(amount_usd) AS revenue
FROM orders
WHERE order_date BETWEEN '2026-01-01' AND '2026-03-31'
GROUP BY order_date;

-- For a multi-terabyte table queried by a non-load-order column,
-- a clustering key co-locates related rows to keep pruning effective.
ALTER TABLE orders CLUSTER BY (customer_region, order_date);

-- Inspect clustering depth before committing to a key.
SELECT SYSTEM$CLUSTERING_INFORMATION('orders', '(customer_region, order_date)');

clustering key ไม่ได้มาฟรี ๆ Snowflake จะรัน background service แบบอัตโนมัติเพื่อดูแลรักษามัน และ service นั้นก็บริโภค credit หลักการทั่วไปคือควรเพิ่ม clustering key เฉพาะกับตารางระดับเทระไบต์ที่ query profile แสดงให้เห็นว่า pruning ทำงานได้ไม่ดีเท่านั้น ตารางที่เล็กกว่านั้น prune ได้ดีอยู่แล้วด้วยตัวเอง และ clustering key ที่ใส่เร็วเกินไปก็เป็นการสิ้นเปลืองเงิน การอธิบายการแลกเปลี่ยนนี้ได้มักเป็นเส้นแบ่งระหว่างคำตอบระดับ junior กับ senior

การโหลดและแปลงข้อมูล: Snowpipe, Streams และ Dynamic Tables

รูปแบบการนำเข้าข้อมูลสามแบบครอบคลุม workload ส่วนใหญ่ การโหลดแบบ bulk ด้วย COPY INTO จะโหลดไฟล์ที่ staged ไว้ในคำสั่งเดียว เหมาะกับงาน batch ตามตารางเวลา ส่วน Snowpipe จะโหลดไฟล์อย่างต่อเนื่องเป็น micro-batch แบบ serverless โดยถูกกระตุ้นจาก event ของ cloud storage เพื่อให้ข้อมูลมาถึงแบบใกล้เรียลไทม์ ส่วน Snowpipe Streaming จะดันข้อมูลทีละแถวผ่าน API ที่มี latency ต่ำเมื่อความสดใหม่ในระดับต่ำกว่าวินาทีมีความสำคัญ การเลือกใช้ในบรรดาสามแบบนี้ตามข้อกำหนดด้าน latency และขนาดไฟล์เป็นคำถามสัมภาษณ์ที่พบบ่อย และคำตอบที่ถูกต้องเริ่มต้นด้วย "มันขึ้นอยู่กับความสดใหม่ที่ผู้บริโภคปลายทางต้องการจริง ๆ"

การแปลงข้อมูลภายใน warehouse ในอดีตอาศัย Streams และ Tasks Stream จะจับการเปลี่ยนแปลงระดับแถวบนตาราง (change data capture) ในขณะที่ Task จะรัน SQL ตามตารางเวลาเพื่อบริโภคการเปลี่ยนแปลงเหล่านั้นและ merge ลงไปยังปลายทาง

-- incremental_pipeline.sql
-- A stream tracks row-level changes (CDC) on the raw landing table.
CREATE STREAM orders_stream ON TABLE raw_orders;

-- A task consumes the stream on a schedule and merges changes downstream.
CREATE TASK refresh_orders
  WAREHOUSE = analytics_wh
  SCHEDULE = '5 MINUTE'
  WHEN SYSTEM$STREAM_HAS_DATA('orders_stream')
AS
  MERGE INTO orders t
  USING orders_stream s ON t.order_id = s.order_id
  WHEN MATCHED THEN UPDATE SET t.amount_usd = s.amount_usd
  WHEN NOT MATCHED THEN INSERT (order_id, amount_usd)
    VALUES (s.order_id, s.amount_usd);

ในปี 2026 Dynamic Tables ได้กลายเป็นวิธีที่นิยมที่สุดในการแสดงการแปลงข้อมูลแบบ incremental แทนที่จะต้องเชื่อม Stream เข้ากับ Task และเขียน merge ด้วยมือ Dynamic Table เพียงประกาศค่า target lag และคิวรี แล้ว Snowflake จะคำนวณการ refresh แบบ incremental ให้โดยอัตโนมัติ มันช่วยกำจัดโค้ด orchestration ที่ซ้ำซากส่วนใหญ่ออกไปในขณะที่ยังคงรักษาผลลัพธ์ให้สดใหม่

-- dynamic_table.sql
-- Dynamic Tables replace the stream + task pattern with a declarative
-- target lag. Snowflake computes the incremental refresh automatically.
CREATE DYNAMIC TABLE daily_revenue
  TARGET_LAG = '5 minutes'
  WAREHOUSE = analytics_wh
AS
  SELECT order_date, SUM(amount_usd) AS revenue
  FROM orders
  GROUP BY order_date;

สำหรับทีมที่สร้างงานบนฟอร์แมตแบบเปิด ตาราง Iceberg ของ Snowflake ช่วยให้ warehouse อ่านและเขียนข้อมูล Apache Iceberg ที่จัดเก็บอยู่ใน cloud bucket ของลูกค้าเอง ซึ่งหลีกเลี่ยงการล็อกอินกับผู้ให้บริการรายเดียว (lock-in) ในขณะที่ยังคงใช้ query engine และระบบ governance ของ Snowflake ได้ หลายทีมจับคู่ Snowflake กับ dbt เพื่อการแปลงข้อมูลที่ควบคุมเวอร์ชันและทดสอบได้ ซึ่งเป็น workflow ที่อธิบายไว้ในคู่มือการแปลงข้อมูลและการทดสอบด้วย dbt

คำถามสัมภาษณ์ Snowflake สำหรับ Data Engineers

คำถามด้านล่างนี้ปรากฏซ้ำ ๆ ในการสัมภาษณ์งาน data engineering ที่เกี่ยวกับ Snowflake คำตอบที่แข็งแรงจะเชื่อมโยงฟีเจอร์กลับไปยังการแยกส่วนของ storage กับ compute แทนที่จะท่องจำไวยากรณ์

การแยก storage ออกจาก compute แก้ปัญหาอะไร? มันขจัดการแย่งชิงทรัพยากร (contention) นักวิเคราะห์ที่รันแดชบอร์ด, ทีม data science ที่เทรน feature และงาน ELT ที่โหลดข้อมูล ต่างสามารถรันบน warehouse ของตัวเองบนตารางชุดเดียวกันได้โดยไม่ต้องแย่งทรัพยากรกันหรือคัดลอกข้อมูล compute จะขยายขึ้นสำหรับงานหนักและ suspend เมื่อว่างงาน ในขณะที่ต้นทุน storage ยังคงคงที่ไม่ว่าจะมี compute เชื่อมต่ออยู่มากเท่าใด

Time Travel และ zero-copy cloning ทำงานอย่างไร? ทั้งสองอาศัยความ immutable ของ micro-partitions เนื่องจาก Snowflake ไม่เคยเขียนทับ micro-partition เวอร์ชันเก่าจึงยังคงอยู่บนดิสก์ตลอดช่วงเวลา retention (สูงสุด 90 วันบน Enterprise) Time Travel จะคิวรีตารางตามสภาพ ณ timestamp ในอดีตโดยชี้ไปยังพาร์ทิชันเก่าเหล่านั้น ส่วน CLONE จะสร้างตารางใหม่ที่อ้างอิงพาร์ทิชันชุดเดียวกันโดยไม่ทำสำเนา storage จนกว่าฝั่งใดฝั่งหนึ่งจะถูกแก้ไข กลไก copy-on-write คือสิ่งที่ทำให้การ clone ตารางขนาดเพตะไบต์เกิดขึ้นได้ทันทีและแทบไม่มีค่าใช้จ่าย

ควรกำหนด clustering key เมื่อใด? เฉพาะบนตารางขนาดใหญ่ (ประมาณหนึ่งเทระไบต์ขึ้นไป) ที่ถูกกรองหรือ join บ่อย ๆ บนคอลัมน์ที่ไม่เกี่ยวข้องกับลำดับการโหลด และเฉพาะหลังจาก query profile ยืนยันแล้วว่า pruning ทำงานได้ไม่ดีเท่านั้น clustering มีต้นทุน credit สำหรับการดูแลรักษาอย่างต่อเนื่อง ดังนั้นมันจึงเป็นการ optimize ที่ตั้งใจ ไม่ใช่ค่าเริ่มต้น

ควบคุมต้นทุนของ Snowflake อย่างไร? ผ่านการปรับขนาด warehouse ให้เหมาะสม, การตั้ง auto-suspend อย่างเข้มงวด, การจับคู่จำนวนคลัสเตอร์ให้ตรงกับ concurrency ที่เกิดขึ้นจริง และ resource monitor ที่จำกัดเพดานการใช้จ่าย credit resource monitor สามารถแจ้งเตือนหรือ suspend warehouse โดยอัตโนมัติเมื่อถึงโควตาที่กำหนด

-- cost_control.sql
-- A resource monitor caps credit spend and suspends warehouses
-- automatically when the monthly quota is reached.
CREATE RESOURCE MONITOR monthly_cap
  WITH CREDIT_QUOTA = 1000
  FREQUENCY = MONTHLY
  START_TIMESTAMP = IMMEDIATELY
  TRIGGERS
    ON 80 PERCENT DO NOTIFY
    ON 100 PERCENT DO SUSPEND;

ALTER WAREHOUSE analytics_wh SET RESOURCE_MONITOR = monthly_cap;

Streams และ Tasks หรือ Dynamic Tables? Dynamic Tables เหมาะกับ pipeline แบบ declarative ที่ข้อกำหนดคือความสดใหม่ระดับเป้าหมาย และ Snowflake สามารถจัดการ refresh ให้ได้ ส่วน Streams และ Tasks ยังคงเป็นเครื่องมือที่ถูกต้องเมื่อการแปลงข้อมูลต้องการการควบคุมแบบ imperative, มี side effect หรือมี logic ที่คิวรีเดียวไม่สามารถแสดงออกมาได้ การรู้ว่าแต่ละอย่างเหมาะกับตรงไหน แทนที่จะเลือกใช้อย่างใดอย่างหนึ่งเป็นค่าเริ่มต้น เป็นสัญญาณของประสบการณ์ในระบบ production

ELT บน Snowflake ต่างจาก ETL แบบดั้งเดิมอย่างไร? storage ที่ราคาถูกและ compute ที่ยืดหยุ่นของ Snowflake ทำให้เป็นไปได้จริงในการโหลดข้อมูลดิบเข้ามาก่อนแล้วค่อยแปลงในที่ ซึ่งเป็นรูปแบบที่สำรวจไว้ในคู่มือสถาปัตยกรรม ETL กับ ELT ผู้สมัครที่เตรียมตัวสำหรับลูปเต็มรูปแบบสามารถฝึกฝนกับโมดูล ETL และ ELT patterns ควบคู่ไปกับแทร็ก data engineering ที่กว้างกว่า

บทสรุป

• สถาปัตยกรรมของ Snowflake แยก storage, compute และ cloud services ออกเป็นสามชั้นที่เป็นอิสระต่อกัน และคำตอบด้านดีไซน์แทบทุกข้อล้วนโยงกลับไปที่การแยกส่วนนี้
• virtual warehouses ขยายแนวตั้งเพื่อรองรับคิวรีเดี่ยวที่หนักขึ้น และขยายแนวนอนเพื่อรองรับ concurrency ที่สูงขึ้น ส่วน auto-suspend และการเรียกเก็บเงินรายวินาทีทำให้ compute ที่ว่างงานไม่มีค่าใช้จ่าย
• micro-partitions พร้อม metadata แบบ min/max ต่อคอลัมน์ให้ partition pruning โดยอัตโนมัติ ซึ่งเป็นเหตุผลที่ Snowflake ไม่ต้องใช้ index แบบทำมือ
• เพิ่ม clustering key เฉพาะกับตารางระดับเทระไบต์ที่พิสูจน์แล้วว่า pruning ทำงานได้ไม่ดี เพราะการดูแลรักษาบริโภค credit
• จับคู่รูปแบบการนำเข้าข้อมูลให้ตรงกับความสดใหม่ที่ต้องการ: bulk COPY สำหรับ batch, Snowpipe สำหรับ micro-batch ต่อเนื่อง, Snowpipe Streaming สำหรับ latency ระดับต่ำกว่าวินาที
• เลือกใช้ Dynamic Tables สำหรับการแปลงข้อมูลแบบ incremental เชิง declarative ในปี 2026 และสงวน Streams และ Tasks ไว้สำหรับ logic แบบ imperative
• Time Travel และ zero-copy cloning ต่างใช้ประโยชน์จากความ immutable ของ micro-partition และ copy-on-write ทำให้คิวรีย้อนเวลาและการ clone แบบทันทีมีต้นทุนต่ำ
• ควบคุมต้นทุนด้วย warehouse ที่ปรับขนาดพอดี, auto-suspend อย่างเข้มงวด, คลัสเตอร์ที่จับคู่กับ concurrency และ resource monitor