Bir mobil operatör için 18 ay süren bir analitik platform projesi yaptık. Başlangıçta Azure Synapse’i tercih ettik: Microsoft “tek platformda data warehouse + data lake + Spark + raporlama” diyordu, takım da Power BI bağımlısıydı. 18 ay sonunda projenin önemli kısmını Microsoft Fabric’e taşıdık. Bu yazı o yolculuğun kararlarını anlatıyor; Synapse hâlâ hayatta ve doğru senaryoda doğru ürün, ama hangi senaryo için olduğunu bilmek lazım.

Synapse’in Üç Yüzü

Çoğu kişi Synapse derken Dedicated SQL Pool’u (eski adıyla SQL Data Warehouse) anlıyor. Aslında Synapse şemsiyesi altında üç ayrı motor var:

1. Dedicated SQL Pool: Provision edilmiş, MPP mimarisi, DWU bazlı fiyat.
2. Serverless SQL Pool: Pay-per-query, data lake üzerinde T-SQL.
3. Spark Pool: Apache Spark, notebook + pyspark/scala.

Üçü farklı maliyet modeli, farklı performans karakteristiği, farklı kullanım kalıpları. Karıştırırsan ya bütçe patlar ya performans yetmez.

Dedicated SQL Pool: Provision Maliyeti Sürpriz Olmamalı

Telekom projesinde başlangıç DWU seviyesi DW1000c oldu (~13.000 USD/ay 7/24 çalıştırırsan). 24 milyar satırlık çağrı detay kayıtları vardı; bu boyut için DW1000c gerçekten uygundu, sorgular saniyeler içinde geri dönüyordu. Ancak fark ettik ki:

• İş saatleri dışında %5 kullanım: Gece ve hafta sonu sorgu yok ama biz 7/24 ödüyorduk.
• Pause/Resume var ama el ile: Logic Apps + Azure Function ile her gece 22:00’de pause, sabah 07:00’de resume scriptledik. Aylık fatura 13K → 5K USD’ye düştü.
• Kapatınca depolama ücreti devam: ~50 USD/TB/ay, 30 TB veri için ~1.500 USD. Bu kalıcı, pause yardımcı olmuyor.

Workload tipi sürekli ad-hoc query veya 7/24 dashboard’a hizmet ediyorsa Dedicated SQL Pool mantıklı. Eğer yük günlük batch + saatlik birkaç query ise pause/resume otomasyonu olmadan Dedicated SQL Pool seçmek pahalı bir hata.

DWU Seçimi: Workload Bazlı Sizing

DWU yazıldığı kadar basit değil çünkü her DWU seviyesi compute + memory + concurrency triplet’ini değiştiriyor:

DWU	Compute node	Memory/node	Concurrent query	Aylık (West Europe)
DW100c	1	60 GB	4	~1.300 USD
DW500c	5	60 GB	20	~6.500 USD
DW1000c	10	60 GB	32	~13.000 USD
DW3000c	30	60 GB	48	~39.000 USD

İlk 6 ay DW1000c’de kaldık, sonra Power BI direct query kullanan iş kullanıcıları artınca concurrent query darboğazına girdik (sürekli 32 query queue), DW2000c’ye çıktık. Workload management classifier’larıyla küçük sorguları bir resource class’a, büyük ETL query’lerini başkasına atayarak adillik sağladık.

Distribution Strategy: Round-Robin Tuzağı

Dedicated SQL Pool’da tablo oluştururken distribution method seçimi performansı en çok belirleyen karar. Default (kaldırıldı ama eski projelerde hâlâ var) ROUND_ROBIN, ad-hoc tablolar için iyi ama join-heavy workload’da felaket. Telekom projesinde başta yaptığımız hata: tüm fact tablolarını ROUND_ROBIN bıraktık, JOIN sorguları data movement’tan dolayı 5 dakika sürdü. HASH distribution’a çevirince (call_id sütunu üzerinden) süre 12 saniyeye indi.

CREATE TABLE fact_call_detail (
    call_id BIGINT NOT NULL,
    msisdn VARCHAR(20),
    start_time DATETIME2,
    duration_sec INT,
    cell_id INT,
    rate_plan_id INT
)
WITH (
    DISTRIBUTION = HASH(call_id),
    CLUSTERED COLUMNSTORE INDEX,
    PARTITION (start_time RANGE RIGHT FOR VALUES (
        '2025-01-01', '2025-04-01', '2025-07-01', '2025-10-01',
        '2026-01-01', '2026-04-01'
    ))
);

Pratik kuralım: Dimension tabloları (boyut tabloları, küçük ve sık join’lenen) REPLICATE; fact tabloları HASH; staging tabloları ROUND_ROBIN.

Serverless SQL Pool: Pay-Per-Query’nin Sürprizi

Serverless’ı pazarlık olarak çok seviyoruz: data lake üzerinde T-SQL, sadece işlenen veri kadar öde (~5 USD / TB scanned). Lakin sahada gördüğüm üç sürpriz:

1. SELECT * yazan analist 100 TB’lik bir Parquet dosyasını taradığında 500 USD’lik tek query yazmış olur.
2. CSV dosyaları çok pahalı: Parquet column-level scan yapar, CSV tüm satırı okur. CSV üzerinde Serverless query asla yapma; önce Parquet’a çevir.
3. Partition pruning’i kontrol et: OPENROWSET kullanırken filepath() filter’ı eklemezsen bütün data lake’i tarar.

-- Yanlış: tüm yıllar taranır
SELECT COUNT(*) FROM OPENROWSET(
    BULK 'https://datalake.dfs.core.windows.net/raw/calls/year=*/month=*/*.parquet',
    FORMAT = 'PARQUET'
) AS [r] WHERE [r].duration_sec > 60;

-- Doğru: filepath() ile partition pruning
SELECT COUNT(*) FROM OPENROWSET(
    BULK 'https://datalake.dfs.core.windows.net/raw/calls/year=*/month=*/*.parquet',
    FORMAT = 'PARQUET'
) AS [r]
WHERE [r].filepath(1) = '2026'
  AND [r].filepath(2) IN ('03','04')
  AND [r].duration_sec > 60;

Serverless workload’unu cost guardrail olmadan koymak felakete yol açar. Per-user veya per-database query limit’i mutlaka kur. Telekom projesinde aylık Serverless faturası 2.300 USD’den 800 USD’ye sadece “CSV’leri Parquet’a çevirip partition strategy uygulayarak” indi.

Spark Pool: Soğuk Başlangıç Tuzağı

Synapse Spark Pool’un en büyük operasyonel sorunu cold start: Pool stop’ta iken bir notebook açtığında Spark cluster’ı 3-7 dakika spinning up oluyor. ETL pipeline’da bu fark kritik. Çözümler:

• Auto-pause süresini iyi ayarla: Eğer her 10 dakikada bir pipeline çalışıyorsa, auto-pause 15 dakika yap. Sürekli stop/start yerine sürekli açık tut.
• Pool sizing’de Medium başlangıç: Small pool overhead’ı yüzünden Medium’a göre toplamda daha pahalı çıkabilir. Kendi workload’una göre 1-2 hafta benchmark yap.
• Notebook scheduler’ı Pipeline trigger’a bağla, manuel açma kalmasın. Engineer’lar UI’dan açıp unutuyor.

Fabric’e Geçiş Kararı

2025 yılında Microsoft Fabric, Synapse’in halefi olarak konumlandı. Yeni feature’lar (Direct Lake mode, OneLake unified storage, copilot) Fabric’e gidiyor; Synapse’e sadece bug fix geliyor. Telekom projesinde Fabric’e geçiş kararını şu üç sebeple verdik:

1. Capacity bazlı fiyatlandırma Synapse’in fragmente DWU + Serverless + Spark + Power BI Premium hesabından çok daha öngörülebilir oldu. F64 capacity (~9.000 USD/ay) ile tüm workload’ı tek havuza koyduk.
2. Direct Lake mode Power BI’da OneLake’teki Parquet’ı doğrudan sorguladığı için import refresh süresi kalktı. 4 saat süren günlük import → 0 saat.
3. Notebook ve SQL endpoint birlikte aynı Lakehouse üzerinde, ayrı ayrı pool yönetmiyorsun.

Geçiş 3 ay sürdü, en çok efor harcanan kısım Synapse pipeline’larını Fabric Data Factory’ye taşımak oldu (sözdizimi farkları). Aylık toplam Synapse + Power BI faturası ~24.000 USD’den Fabric F64 ~9.000 USD’ye indi. Performans kazancı bonus.

Synapse Hâlâ Tercih Edilmeli mi?

Yeni greenfield proje için: Hayır, Fabric’e başla. Microsoft yatırımı oraya gidiyor.

Mevcut Synapse projesi varsa: Acil değiştirme. Capacity-based fiyatlandırma + Direct Lake değer üretiyorsa migration’a yatırım yap, ama 12-18 aylık plan gerekir.

Niş senaryolarda Synapse hâlâ üstün:

• Çok büyük (PB+) MPP query’leri için Dedicated SQL Pool olgun.
• VNet integration ve Private Endpoint ile compliance açısından Fabric’ten daha esnek (Fabric’in private link tarafı 2026 başında olgunlaşıyor).
• SQL Server / Azure SQL ekosistemine alışkın takımlarda öğrenme eğrisi düşük.

Çıkardığım Genel Dersler

1. Maliyet öngörülemez gibi göründüğünde tooling sorunudur: Cost analysis dashboard’ı ve daily budget alert kurmadan production data warehouse açma.
2. Pause/Resume otomasyonu Day 1 kurulmalı: Sonra “ben yaparım” deyip ödenen 4 ay var.
3. Format kararları (CSV vs Parquet) bütçeyi 3-5x değiştirebilir: Data lake’te ham veriyi Parquet’a çevirmek için Pipeline kur.
4. Distribution strategy compute kararının kendisi kadar önemli: Yanlış distribution = 10x slow query.
5. Vendor roadmap’ini takip et: Synapse → Fabric geçişini 6 ay önceden bilseydim Synapse yatırımını farklı yapardım.

Veri platformu projeleri 18-36 aylık vadeli kararlar; ürün seçerken “şu an ne pazarlanıyor” değil “3 yıl sonra ne destekleniyor olacak” sorusunu sorman lazım. CloudSpark olarak Synapse, Fabric ve Databricks projelerinde mimari gözden geçirme + maliyet optimizasyonu hizmeti veriyoruz; mevcut platform faturasını gözden geçirmek istersen bağlan.