Snowflake di 2026: Arsitektur, SQL, dan Pertanyaan Interview Data Engineer

Pertanyaan interview Snowflake menguji apakah seorang data engineer memahami arsitektur platform yang decoupled, bukan sekadar sintaks SQL-nya. Desain multi-cluster shared-data yang dipelopori Snowflake memisahkan storage, compute, dan services menjadi tiga lapisan independen, dan pemisahan itulah yang menjelaskan hampir setiap keputusan performa dan biaya yang diambil sebuah tim di platform ini. Panduan ini membahas arsitektur Snowflake, pola SQL yang menjaga query tetap cepat dan murah pada 2026, serta pertanyaan interview yang mengungkap pengalaman produksi sesungguhnya.

Arsitektur Snowflake: Storage, Compute, dan Cloud Services

Ciri khas arsitektur Snowflake adalah storage dan compute yang terpisah secara fisik. Data disimpan satu kali di lapisan storage tersentralisasi yang didukung oleh cloud object store seperti Amazon S3 atau Azure Blob Storage. Sejumlah cluster compute mana pun dapat membaca data yang sama secara bersamaan tanpa menyalinnya, sebuah pendekatan yang diberi nama multi-cluster shared data oleh tim engineering aslinya dalam makalah SIGMOD 2016 yang memperkenalkan desain tersebut.

Lapisan storage menyimpan data dalam file kolumnar yang immutable dan terkompresi, disebut micro-partition. Seorang pengguna tidak pernah mengelola file-file ini secara langsung. Snowflake yang menulisnya, melacak metadata-nya, dan memulihkan ruangnya kembali. Lapisan compute terdiri dari virtual warehouse, masing-masing berupa cluster server yang disediakan Snowflake sesuai permintaan. Lapisan cloud services berada di atas keduanya dan mengoordinasikan segalanya: melakukan parsing SQL, menyusun rencana query, menegakkan kontrol akses, mengelola transaksi, serta menyimpan metadata yang memungkinkan fitur seperti Time Travel dan zero-copy cloning.

Karena lapisan-lapisan ini independen, sebuah warehouse dapat diubah ukurannya atau dihapus tanpa menyentuh satu byte data pun, dan storage dapat tumbuh hingga petabyte tanpa perlu menyediakan compute apa pun.

-- 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.

Menghapus analytics_wh setelah skrip itu dijalankan akan menghentikan seluruh penagihan compute, sementara setiap tabel tetap dapat di-query begitu sebuah warehouse baru dibuat. Decoupling itulah gagasan tunggal terpenting yang harus mampu diartikulasikan dalam sebuah interview.

Bagaimana Virtual Warehouse Menskalakan Compute Snowflake

Sebuah virtual warehouse adalah cluster compute bernama yang diukur dalam satuan T-shirt: X-Small, Small, Medium, Large, dan seterusnya. Setiap langkah naik menggandakan baik jumlah server maupun konsumsi credit per jam, sehingga warehouse Large berbiaya empat kali lipat dari Small tetapi juga menyelesaikan query yang berat dalam scan kira-kira empat kali lebih cepat. Trade-off harga-terhadap-performa yang linear ini berarti opsi termurah sering kali justru warehouse yang lebih besar namun berjalan dalam waktu lebih singkat.

Ada dua dimensi penskalaan, dan mengacaukan keduanya merupakan jebakan interview yang umum. Penskalaan vertikal mengubah ukuran satu warehouse untuk mempercepat satu query. Penskalaan horizontal menambah cluster ke sebuah multi-cluster warehouse untuk melayani lebih banyak query bersamaan. Sebuah dashboard yang diakses 200 analis pada pukul 9 pagi membutuhkan lebih banyak cluster, bukan yang lebih besar; sedangkan backfill malam hari atas satu triliun baris membutuhkan yang lebih besar, bukan lebih banyak cluster.

-- 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 dan AUTO_RESUME adalah yang membuat pendekatan ini ekonomis. Warehouse yang di-suspend tidak berbiaya apa pun, dan Snowflake menagih per detik dengan minimum 60 detik. Menetapkan auto-suspend yang singkat pada warehouse interaktif mencegah cluster yang menganggur membakar credit di antara query.

Micro-Partition dan Clustering Key untuk SQL yang Cepat

Snowflake menyimpan setiap tabel sebagai sekumpulan micro-partition, masing-masing menampung 50 hingga 500 MB data yang belum terkompresi dalam format kolumnar. Untuk setiap micro-partition, Snowflake mencatat nilai minimum dan maksimum tiap kolom dalam metadata-nya. Ketika sebuah query memfilter pada suatu kolom, optimizer membaca metadata itu dan melewati partisi mana pun yang rentang nilainya tidak mungkin cocok, sebuah proses yang disebut partition pruning. Inilah sebabnya Snowflake tidak membutuhkan index manual: pruning terjadi otomatis pada setiap kolom.

Pruning bekerja paling baik ketika kolom filter berkorelasi dengan urutan data saat dimuat. Sebuah tabel yang di-ingest berdasarkan tanggal akan mem-prune query rentang tanggal secara efisien. Ketika sebuah tabel besar sering difilter pada kolom yang tidak terkait dengan urutan pemuatan, sebuah clustering key menempatkan baris-baris terkait secara berdekatan di seluruh micro-partition sehingga pruning tetap efektif seiring pertumbuhan tabel.

-- 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 tidaklah gratis: Snowflake menjalankan sebuah layanan background otomatis untuk memeliharanya, dan layanan itu mengonsumsi credit. Aturan praktisnya adalah menambahkan clustering key hanya pada tabel dalam kisaran terabyte yang profil query-nya menunjukkan pruning yang buruk. Tabel yang lebih kecil mem-prune dengan baik dengan sendirinya, dan clustering key yang prematur hanya memboroskan uang. Menjelaskan trade-off itu sering kali menjadi pembeda antara jawaban seorang junior dan seorang senior.

Memuat dan Mentransformasi Data: Snowpipe, Streams, dan Dynamic Tables

Tiga pola ingestion mencakup sebagian besar beban kerja. Bulk COPY INTO memuat file yang di-stage dalam satu perintah dan cocok untuk pekerjaan batch terjadwal. Snowpipe memuat file secara terus-menerus dalam micro-batch serverless, dipicu oleh event cloud storage, untuk kedatangan yang mendekati real-time. Snowpipe Streaming mendorong baris individual melalui API berlatensi rendah ketika kesegaran sub-detik menjadi penting. Memilih di antara ketiganya berdasarkan kebutuhan latensi dan ukuran file adalah pertanyaan interview yang sering muncul, dan jawaban yang benar dimulai dengan "tergantung pada kesegaran yang benar-benar dibutuhkan konsumen di hilir."

Transformasi di dalam warehouse secara historis mengandalkan Streams dan Tasks. Sebuah Stream menangkap perubahan tingkat baris pada sebuah tabel (change data capture), dan sebuah Task menjalankan SQL secara terjadwal untuk mengonsumsi perubahan itu dan menggabungkannya ke hilir.

-- 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);

Pada 2026, Dynamic Tables telah menjadi cara yang lebih disukai untuk mengekspresikan transformasi inkremental. Alih-alih menyambungkan sebuah Stream ke sebuah Task dan menulis merge secara manual, sebuah Dynamic Table mendeklarasikan target lag dan sebuah query, lalu Snowflake yang menghitung refresh inkremental secara otomatis. Ini menghilangkan sebagian besar boilerplate orkestrasi sambil menjaga hasil tetap segar.

-- 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;

Bagi tim yang membangun di atas format terbuka, Iceberg table milik Snowflake memungkinkan warehouse membaca dan menulis data Apache Iceberg yang tersimpan di cloud bucket milik pelanggan sendiri, sehingga menghindari lock-in sambil tetap mempertahankan query engine dan governance Snowflake. Banyak tim memasangkan Snowflake dengan dbt untuk transformasi yang ter-version-control dan teruji, sebuah alur kerja yang dibahas dalam panduan transformasi dan pengujian data dbt.

Pertanyaan Interview Snowflake untuk Data Engineer

Pertanyaan-pertanyaan di bawah ini muncul berulang kali dalam interview data engineering Snowflake. Jawaban yang kuat mengaitkan sebuah fitur kembali ke pemisahan storage-compute, alih-alih mengulang sintaks.

Masalah apa yang diselesaikan oleh pemisahan storage dan compute? Pemisahan itu menghilangkan contention. Analis yang menjalankan dashboard, tim data science yang melatih feature, dan pekerjaan ELT yang memuat data masing-masing dapat berjalan pada warehouse-nya sendiri terhadap tabel yang sama tanpa berebut sumber daya atau menyalin data. Compute diskalakan untuk pekerjaan berat dan di-suspend saat menganggur, sementara biaya storage tetap datar terlepas dari berapa banyak compute yang terpasang.

Bagaimana Time Travel dan zero-copy cloning bekerja? Keduanya bertumpu pada immutability micro-partition. Karena Snowflake tidak pernah menimpa micro-partition, versi lama tetap tersimpan di disk selama jendela retensi (hingga 90 hari pada Enterprise). Time Travel meng-query sebuah tabel pada suatu timestamp di masa lalu dengan menunjuk ke partisi-partisi lama itu, dan CLONE membuat tabel baru yang mereferensikan partisi yang sama tanpa menduplikasi storage hingga salah satu sisi diubah. Copy-on-write itulah yang membuat sebuah clone dari tabel petabyte menjadi instan dan nyaris gratis.

Kapan sebuah clustering key sebaiknya didefinisikan? Hanya pada tabel besar (kira-kira satu terabyte atau lebih) yang sering difilter atau di-join pada kolom yang tidak terkait dengan urutan pemuatannya, dan hanya setelah sebuah query profile mengonfirmasi pruning yang buruk. Clustering menimbulkan biaya credit pemeliharaan yang berkelanjutan, sehingga ia merupakan optimasi yang disengaja, bukan pengaturan default.

Bagaimana biaya Snowflake dikendalikan? Melalui pengaturan ukuran warehouse, auto-suspend yang agresif, penyesuaian jumlah cluster dengan konkurensi nyata, serta resource monitor yang membatasi pengeluaran credit. Sebuah resource monitor dapat memberi notifikasi atau men-suspend warehouse secara otomatis begitu sebuah kuota tercapai.

-- 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 dan Tasks atau Dynamic Tables? Dynamic Tables cocok untuk pipeline deklaratif di mana kesegaran target adalah persyaratannya dan Snowflake dapat mengelola refresh-nya. Streams dan Tasks tetap menjadi alat yang tepat ketika transformasi membutuhkan kontrol imperatif, side effect, atau logika yang tidak dapat diungkapkan oleh satu query tunggal. Mengetahui di mana masing-masing cocok, alih-alih otomatis memilih salah satu, menandakan pengalaman produksi.

Apa perbedaan ELT di Snowflake dengan ETL tradisional? Storage yang murah dan compute yang elastis dari Snowflake membuatnya praktis untuk memuat data mentah terlebih dahulu dan mentransformasinya di tempat, sebuah pola yang dieksplorasi dalam panduan arsitektur ETL vs ELT. Kandidat yang bersiap untuk keseluruhan alur dapat berlatih dengan modul pola ETL dan ELT bersama dengan jalur data engineering yang lebih luas.

Kesimpulan

• Arsitektur Snowflake memisahkan storage, compute, dan cloud services menjadi tiga lapisan independen, dan hampir setiap jawaban desain berpangkal pada pemisahan itu
• Virtual warehouse diskalakan secara vertikal untuk query tunggal yang lebih berat dan secara horizontal untuk konkurensi yang lebih tinggi; auto-suspend dan penagihan per detik menjaga compute yang menganggur tetap gratis
• Micro-partition dengan metadata min/max per kolom memberikan partition pruning otomatis, itulah sebabnya Snowflake tidak membutuhkan index manual
• Tambahkan clustering key hanya pada tabel berskala terabyte dengan pruning yang terbukti buruk, karena pemeliharaannya mengonsumsi credit
• Sesuaikan pola ingestion dengan kesegaran yang dibutuhkan: bulk COPY untuk batch, Snowpipe untuk micro-batch berkelanjutan, Snowpipe Streaming untuk latensi sub-detik
• Utamakan Dynamic Tables untuk transformasi inkremental deklaratif pada 2026, dan cadangkan Streams dan Tasks untuk logika imperatif
• Time Travel dan zero-copy cloning sama-sama memanfaatkan immutability micro-partition dan copy-on-write, membuat query point-in-time dan clone instan menjadi murah
• Kendalikan biaya dengan warehouse berukuran tepat, auto-suspend yang agresif, cluster yang sesuai konkurensi, dan resource monitor