# 2026'da Snowflake: Mimari, SQL ve Veri Mühendisi Mülakat Soruları > Veri mühendisleri için 2026 Snowflake mimarisi rehberi: depolama ile işlem gücünün nasıl ayrıldığı, sanal warehouse'ların ve micro-partition'ların nasıl çalıştığı ve üretim deneyimini ölçen mülakat soruları. - Published: 2026-06-29 - Updated: 2026-07-06 - Author: SharpSkill - Tags: snowflake, data-engineering, data-warehouse, sql, snowflake-architecture, dynamic-tables - Reading time: 10 min --- Snowflake mülakat soruları, bir veri mühendisinin platformun yalnızca SQL sözdizimini değil, ayrık (decoupled) mimarisini de anlayıp anlamadığını ölçer. Snowflake'in öncülük ettiği çok kümeli paylaşımlı veri (multi-cluster shared-data) tasarımı; depolamayı, işlem gücünü ve servisleri birbirinden bağımsız üç katmana ayırır ve bu ayrım, bir ekibin platform üzerinde aldığı neredeyse her performans ve maliyet kararını açıklar. Bu rehber; Snowflake mimarisini, 2026 yılında sorguları hızlı ve ucuz tutan SQL desenlerini ve gerçek üretim deneyimini ortaya çıkaran mülakat sorularını ele alır. > **Snowflake'in üç katmanlı mimarisi tek cümlede** > > Snowflake, bir veri ambarını birbirinden bağımsız üç katmana böler: sıkıştırılmış kolonsal veriyi tutan merkezi depolama, esnek işlem gücü sağlayan sanal warehouse'lar ve metadata, güvenlik ile sorgu optimizasyonunu yöneten bir cloud services katmanı. Her katman, diğerlerini etkilemeden ölçeklenir. ## Snowflake Mimarisi: Depolama, İşlem Gücü ve Cloud Services Snowflake mimarisinin belirleyici özelliği, depolama ile işlem gücünün fiziksel olarak ayrık olmasıdır. Veri, Amazon S3 veya Azure Blob Storage gibi bulut nesne depolarıyla desteklenen merkezi bir depolama katmanında tek bir kez saklanır. İstenilen sayıda işlem kümesi, veriyi kopyalamadan aynı veriyi eşzamanlı olarak okuyabilir; bu yaklaşımı özgün mühendislik ekibi, tasarımı tanıtan 2016 SIGMOD makalesinde [multi-cluster shared data](https://dl.acm.org/doi/10.1145/2882903.2903741) olarak adlandırmıştır. Depolama katmanı, veriyi micro-partition adı verilen değişmez (immutable), sıkıştırılmış ve kolonsal dosyalarda tutar. Kullanıcı bu dosyaları asla doğrudan yönetmez. Snowflake onları yazar, metadata'larını izler ve geri kazanır. İşlem katmanı, her biri Snowflake'in talep üzerine sağladığı bir sunucu kümesi olan sanal warehouse'lardan oluşur. Cloud services katmanı her ikisinin de üzerinde yer alır ve her şeyi koordine eder: SQL'i ayrıştırır, sorguları planlar, erişim denetimini uygular, işlemleri (transaction) yönetir ve Time Travel ile zero-copy cloning gibi özellikleri mümkün kılan metadata'yı saklar. Bu katmanlar bağımsız olduğundan, tek bir veri baytına dahi dokunmadan bir warehouse yeniden boyutlandırılabilir veya silinebilir ve herhangi bir işlem gücü sağlamaya gerek kalmadan depolama petabaytlara kadar büyüyebilir. ```sql -- 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. ``` Bu betik çalıştıktan sonra `analytics_wh` warehouse'unu silmek, tüm işlem faturalandırmasını durdururken her tablo, yeni bir warehouse oluşturulur oluşturulmaz sorgulanabilir kalır. Bu ayrıştırma (decoupling), bir mülakatta ifade edilmesi gereken en önemli tek fikirdir. ## Sanal Warehouse'lar Snowflake İşlem Gücünü Nasıl Ölçekler Sanal warehouse, X-Small, Small, Medium, Large ve yukarısı gibi tişört bedenleriyle boyutlandırılan, adlandırılmış bir işlem kümesidir. Her bir boyut adımı hem sunucu sayısını hem de saatlik kredi tüketimini iki katına çıkarır; dolayısıyla bir Large warehouse, bir Small'a göre dört kat maliyetlidir ama tarama ağırlıklı bir sorguyu da kabaca dört kat daha hızlı bitirir. Bu doğrusal fiyat-performans dengesi, en ucuz seçeneğin çoğu zaman daha kısa süre çalışan daha büyük bir warehouse olduğu anlamına gelir. İki ölçekleme boyutu vardır ve bunları karıştırmak yaygın bir mülakat tuzağıdır. Dikey ölçekleme, tek bir sorguyu hızlandırmak için tek bir warehouse'u yeniden boyutlandırır. Yatay ölçekleme ise daha fazla eşzamanlı sorguya hizmet vermek için çok kümeli bir warehouse'a kümeler ekler. Sabah 9'da 200 analistin eriştiği bir dashboard daha büyük değil, daha fazla kümeye ihtiyaç duyar; bir trilyon satırlık gecelik bir geri dolum (backfill) ise daha fazla değil, daha büyük bir kümeye ihtiyaç duyar. > **Dikey ve yatay ölçekleme karşılaştırması** > > Çok fazla veri tarayan tek bir yavaş sorguyu hızlandırmak için bir warehouse'u yeniden boyutlandırın (dikey). Birçok kullanıcı aynı anda sorgu çalıştırıp istekler kuyruğa girmeye başladığında çok kümeli bir warehouse'a kümeler ekleyin (yatay). Biri ağır bir iş için gecikmeyi (latency) düzeltir; diğeri birçok küçük iş için eşzamanlılığı (concurrency) düzeltir. ```sql -- 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` ve `AUTO_RESUME`, bunu ekonomik kılan şeylerdir. Askıya alınmış bir warehouse hiçbir maliyet yaratmaz ve Snowflake, 60 saniyelik bir minimumla saniye başına faturalandırma yapar. Etkileşimli warehouse'larda kısa bir otomatik askıya alma süresi ayarlamak, boştaki kümelerin sorgular arasında kredi tüketmesini önler. ## Hızlı SQL için Micro-Partition'lar ve Clustering Key'ler Snowflake her tabloyu, her biri kolonsal formatta 50 ila 500 MB sıkıştırılmamış veri tutan bir [micro-partition](https://docs.snowflake.com/en/user-guide/tables-clustering-micropartitions) kümesi olarak saklar. Snowflake, her micro-partition için her sütunun minimum ve maksimum değerini metadata'sında kaydeder. Bir sorgu bir sütuna göre filtreleme yaptığında, optimizasyon motoru bu metadata'yı okur ve değer aralığı eşleşemeyecek her partition'ı atlar; bu sürece partition pruning denir. Snowflake'in manuel index'e ihtiyaç duymamasının nedeni budur: pruning her sütunda otomatik olarak gerçekleşir. Pruning, filtre sütunu verinin yüklenme sırasıyla ilişkili olduğunda en iyi şekilde çalışır. Tarihe göre alınan (ingest) bir tablo, tarih aralığı sorgularını verimli biçimde budayarak pruning yapar. Büyük bir tablo sıklıkla yükleme sırasıyla ilgisiz bir sütuna göre filtrelendiğinde, bir clustering key ilişkili satırları micro-partition'lar arasında bir araya toplayarak tablo büyüdükçe pruning'in etkili kalmasını sağlar. ```sql -- 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'ler ücretsiz değildir: Snowflake bunları korumak için otomatik bir arka plan servisi çalıştırır ve bu servis kredi tüketir. Pratik kural, yalnızca sorgu profillerinin zayıf pruning gösterdiği, terabayt ölçeğindeki tablolara bir clustering key eklemektir. Daha küçük tablolar kendi başlarına iyi pruning yapar ve zamansız bir clustering key para israfına yol açar. Bu dengeyi açıklayabilmek, çoğu zaman junior ile senior bir yanıt arasındaki farktır. > **Clustering, kazandırdığından daha fazlasına mal olabilir** > > Sık ekleme ve güncelleme yapılan bir tabloda, otomatik yeniden kümeleme (reclustering) servisi clustering key'i korumak için micro-partition'ları sürekli yeniden düzenler ve bu bakım, hızlandırdığı sorgulardan daha fazla kredi tüketebilir. Önce sorgu iş yükünü query profile ile ölçün ve clustering'i yazıldığından çok daha fazla okunan tablolara ayırın. ## Veri Yükleme ve Dönüştürme: Snowpipe, Stream'ler ve Dynamic Table'lar Üç alım (ingestion) deseni çoğu iş yükünü kapsar. Toplu `COPY INTO`, hazırlanmış (staged) dosyaları tek bir komutla yükler ve zamanlanmış toplu işlere uygundur. Snowpipe, dosyaları bulut depolama olaylarıyla tetiklenen sunucusuz mikro toplu işler halinde sürekli yükleyerek neredeyse gerçek zamanlı ulaşım sağlar. Snowpipe Streaming ise saniyenin altında tazelik gerektiğinde tek tek satırları düşük gecikmeli bir API üzerinden aktarır. Bunlar arasında gecikme ve dosya boyutu gereksinimlerine göre seçim yapmak sık karşılaşılan bir mülakat sorusudur ve doğru yanıt "aşağı akıştaki tüketicinin gerçekte ihtiyaç duyduğu tazeliğe bağlı" ifadesiyle başlar. Warehouse içindeki dönüşüm tarihsel olarak Stream'ler ve Task'lara dayanmaktaydı. Bir Stream, bir tablodaki satır düzeyindeki değişiklikleri yakalar (change data capture) ve bir Task, bu değişiklikleri tüketip aşağı akışa merge etmek için SQL'i belirli bir zaman çizelgesinde çalıştırır. ```sql -- 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 yılında Dynamic Table'lar, artımlı (incremental) dönüşümleri ifade etmenin tercih edilen yolu haline geldi. Bir Stream'i bir Task'a bağlayıp merge işlemini elle yazmak yerine, bir Dynamic Table bir hedef gecikme (target lag) ve bir sorgu tanımlar; Snowflake ise artımlı yenilemeyi otomatik olarak hesaplar. Bu, sonuçları taze tutarken orkestrasyon boilerplate'inin çoğunu ortadan kaldırır. ```sql -- 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; ``` Açık formatlar üzerine inşa eden ekipler için Snowflake'in Iceberg tabloları, warehouse'un müşterinin kendi bulut kovasında (bucket) saklanan [Apache Iceberg](https://iceberg.apache.org/) verisini okuyup yazmasına olanak tanır; bu da Snowflake'in sorgu motorunu ve yönetişimini korurken kilitlenmeyi (lock-in) önler. Birçok ekip, sürüm kontrollü ve test edilmiş dönüşümler için Snowflake'i [dbt](https://docs.getdbt.com/) ile eşleştirir; bu iş akışı [dbt veri dönüşümleri ve test rehberinde](/blog/data-engineering/dbt-data-transformations-testing-interview-2026) ele alınmaktadır. ## Veri Mühendisleri için Snowflake Mülakat Soruları Aşağıdaki sorular Snowflake veri mühendisliği mülakatlarında tekrar tekrar karşımıza çıkar. Güçlü yanıtlar, bir özelliği sözdizimi ezberlemek yerine depolama-işlem gücü ayrımına bağlar. **Depolama ile işlem gücünü ayırmak hangi sorunu çözer?** Çekişmeyi (contention) ortadan kaldırır. Dashboard çalıştıran analistler, öznitelik (feature) eğiten bir veri bilimi ekibi ve veri yükleyen bir ELT işi, aynı tablolar üzerinde kaynaklar için rekabet etmeden veya veriyi kopyalamadan her biri kendi warehouse'unda çalışabilir. İşlem gücü ağır bir iş için yukarı ölçeklenir ve boştayken askıya alınır; depolama maliyeti ise ne kadar işlem gücü bağlı olursa olsun sabit kalır. **Time Travel ve zero-copy cloning nasıl çalışır?** Her ikisi de micro-partition'ların değişmezliğine (immutability) dayanır. Snowflake bir micro-partition'ın üzerine asla yazmadığı için, eski sürümler saklama penceresi boyunca (Enterprise'da 90 güne kadar) diskte kalır. Time Travel, bu eski partition'ları işaret ederek bir tabloyu geçmiş bir zaman damgasındaki haliyle sorgular ve `CLONE`, bir taraf değiştirilene kadar depolamayı çoğaltmadan aynı partition'lara referans veren yeni bir tablo oluşturur. Bir petabaytlık tablonun klonunu anında ve neredeyse ücretsiz kılan şey, yazarken kopyalama (copy-on-write) yöntemidir. **Bir clustering key ne zaman tanımlanmalıdır?** Yalnızca yükleme sırasıyla ilgisiz bir sütuna göre sık filtrelenen veya join edilen büyük tablolarda (kabaca bir terabayt veya üzeri) ve yalnızca bir query profile zayıf pruning'i doğruladıktan sonra. Clustering, süregelen bir bakım kredisi maliyeti getirir; dolayısıyla bu bir varsayılan değil, bilinçli bir optimizasyondur. **Snowflake maliyeti nasıl kontrol edilir?** Warehouse boyutlandırma, agresif otomatik askıya alma, küme sayısını gerçek eşzamanlılıkla eşleştirme ve kredi harcamasını sınırlayan resource monitor'lar aracılığıyla. Bir resource monitor, bir kota aşıldığında warehouse'ları otomatik olarak bildirebilir veya askıya alabilir. ```sql -- 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; ``` **Stream'ler ve Task'lar mı yoksa Dynamic Table'lar mı?** Dynamic Table'lar, hedef tazeliğin gereksinim olduğu ve Snowflake'in yenilemeyi yönetebildiği bildirimsel (declarative) pipeline'lara uygundur. Stream'ler ve Task'lar, dönüşüm tek bir sorgunun ifade edemeyeceği zorunlu (imperative) denetim, yan etkiler veya mantık gerektirdiğinde hâlâ doğru araç olarak kalır. Birine varsayılan olarak yönelmek yerine her birinin nereye uyduğunu bilmek, üretim deneyiminin işaretidir. **Snowflake üzerinde ELT, geleneksel ETL'den nasıl farklıdır?** Snowflake'in ucuz depolaması ve esnek işlem gücü, ham veriyi önce yüklemeyi ve yerinde dönüştürmeyi pratik hale getirir; bu desen [ETL ve ELT mimarisi rehberinde](/blog/data-engineering/etl-vs-elt-data-pipeline-architecture) incelenmektedir. Tüm döngüye hazırlanan adaylar, daha geniş [veri mühendisliği izleğinin](/technologies/data-engineering) yanı sıra [ETL ve ELT desenleri modülünü](/technologies/data-engineering/interview-questions/etl-elt-patterns) çalışabilir. ## Sonuç - Snowflake mimarisi depolamayı, işlem gücünü ve cloud services'i birbirinden bağımsız üç katmana ayırır ve neredeyse her tasarım yanıtı bu ayrıma dayanır - Sanal warehouse'lar daha ağır tekil sorgular için dikey, daha yüksek eşzamanlılık için yatay olarak ölçeklenir; otomatik askıya alma ve saniye başına faturalandırma boştaki işlem gücünü ücretsiz tutar - Sütun başına min/max metadata'ya sahip micro-partition'lar otomatik partition pruning sağlar; Snowflake'in manuel index'e ihtiyaç duymamasının nedeni de budur - Clustering key'leri yalnızca kanıtlanmış zayıf pruning'e sahip terabayt ölçeğindeki tablolara ekleyin, çünkü bakım kredi tüketir - Alım desenini gereken tazeliğe göre eşleştirin: toplu iş için toplu COPY, sürekli mikro toplu işler için Snowpipe, saniyenin altında gecikme için Snowpipe Streaming - 2026 yılında bildirimsel artımlı dönüşümler için Dynamic Table'ları tercih edin ve Stream'ler ile Task'ları zorunlu mantığa ayırın - Time Travel ve zero-copy cloning'in her ikisi de micro-partition değişmezliğinden ve copy-on-write'tan yararlanarak zaman noktasındaki sorguları ve anlık klonları ucuz hale getirir - Maliyeti doğru boyutlandırılmış warehouse'lar, agresif otomatik askıya alma, eşzamanlılıkla eşleştirilmiş kümeler ve resource monitor'larla kontrol edin --- Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack. HTML version of this page: https://sharpskill.dev/tr/blog/data-engineering/snowflake-architecture-sql-data-engineer-interview-2026