Fabric Forumlarının En Sık Sorusu

Microsoft Fabric kullanıcılarının en çok tartıştığı konu şudur: _"Lakehouse mı, Warehouse mı kullanmalıyım?"_ Bu soru Microsoft Tech Community, Reddit r/PowerBI ve Stack Overflow'da her hafta onlarca kez soruluyor. Ve cevabı düşündüğünüzden daha nüanslı.

Bu rehberde, gerçek dünya projelerinden edindiğimiz deneyimlerle her iki yapının avantajlarını, sınırlarını ve en yaygın hataları ele alacağız.

💡Kısa cevap: Çoğu durumda Lakehouse ile başlayın. Warehouse'a yalnızca spesifik SQL ihtiyaçlarınız varsa geçin.

Lakehouse Nedir?

Fabric Lakehouse, Data Lake'in esnekliğini ve SQL Warehouse'ın yapısını tek bir yerde birleştirir. Veriler Delta/Parquet formatında OneLake'de saklanır ve hem Spark (Python/Scala) hem de SQL Endpoint üzerinden sorgulanabilir.

Lakehouse Güçlü Yanları

  • Delta formatı: ACID transaction desteği, time travel, schema evolution
  • Spark erişimi: Python, PySpark, Scala ile güçlü veri dönüşümü
  • DirectLake modu: Import hızında, DirectQuery esnekliğinde — Power BI raporlarında devrim
  • Maliyet: CU tüketimi Warehouse'a göre genellikle daha düşük
  • Dosya desteği: CSV, JSON, Parquet, Avro gibi dosyaları doğrudan okuyabilme

Lakehouse Sınırları

  • SQL Endpoint read-only — INSERT/UPDATE/DELETE yapılamaz
  • Stored procedure ve view desteği yok (SQL Endpoint'te)
  • T-SQL'e alışkın DBA'lar için öğrenme eğrisi var
⚠️Forum Hatası #1: "Lakehouse'da neden INSERT INTO çalışmıyor?" — Çünkü SQL Endpoint read-only. Veri yazma işlemlerini Notebook veya Dataflow üzerinden yapmanız gerekir.

Warehouse Nedir?

Fabric Warehouse, geleneksel SQL Data Warehouse deneyimini Fabric içinde sunar. T-SQL ile tam okuma/yazma desteği vardır. Stored procedure, view, schema yönetimi gibi klasik DWH özellikleri mevcuttur.

Warehouse Güçlü Yanları

  • Tam T-SQL desteği: INSERT, UPDATE, DELETE, MERGE, SP, View
  • DBA-friendly: SQL Server/Azure SQL deneyimine çok benzer
  • Cross-database sorgulama: Birden fazla Warehouse ve Lakehouse'u tek sorguda birleştirebilme
  • Security: Tablo ve kolon düzeyinde güvenlik

Warehouse Sınırları

  • Spark erişimi yok — sadece T-SQL
  • CU tüketimi daha yüksek olabilir
  • Python/PySpark ile dönüşüm yapılamaz

Karşılaştırma Tablosu

| Özellik | Lakehouse | Warehouse |

|---|---|---|

| Veri yazma | Spark/Notebook/Dataflow | T-SQL (INSERT/UPDATE/DELETE) |

| Veri okuma | SQL Endpoint + Spark | T-SQL |

| Stored Procedure | ❌ | ✅ |

| View | ❌ (SQL Endpoint'te) | ✅ |

| Spark/Python | ✅ | ❌ |

| DirectLake | ✅ | ✅ |

| Dosya formatı | Delta/Parquet (+ CSV, JSON) | Delta/Parquet |

| Maliyet (CU) | Genellikle düşük | Genellikle yüksek |

| Öğrenme eğrisi | Spark bilgisi gerekir | SQL bilgisi yeterli |

Karar Ağacı

Forum'da En Sık Yapılan Hatalar

Hata 1: Her şeyi Warehouse'a koymak

Geleneksel DWH alışkanlığıyla tüm verileri Warehouse'a yükleyen ekipler, gereksiz CU tüketimine maruz kalır. Ham verileri Lakehouse'da tutup, sadece son katmanı (Gold) Warehouse'a koymak çok daha verimli.

Python
class="code-comment"># Lakehouse'da Bronze → Silver → Gold katmanı
class="code-comment"># Bronze: Ham veri (Lakehouse Files bölümüne yükle)
class="code-comment"># Silver: Temizlenmiş veri (Notebook ile dönüştür)
df_silver = (spark.read.format(class="code-string">"delta").load(class="code-string">"Tables/bronze_satislar")
    .filter(class="code-string">"Tutar > class="code-number">0")
    .dropDuplicates([class="code-string">"SiparisID"])
)
df_silver.write.format(class="code-string">"delta").mode(class="code-string">"overwrite").save(class="code-string">"Tables/silver_satislar")

class="code-comment"># Gold: İş katmanı (Warehouseclass="code-string">'a veya Lakehouse'a)
df_gold = (df_silver
    .groupBy(class="code-string">"UrunKategorisi", class="code-string">"Yil", class="code-string">"Ay")
    .agg({class="code-string">"Tutar": class="code-string">"sum", class="code-string">"SiparisID": class="code-string">"countDistinct"})
)
df_gold.write.format(class="code-string">"delta").mode(class="code-string">"overwrite").save(class="code-string">"Tables/gold_satis_ozet")
Medallion Architecture (Bronze-Silver-Gold)
KaynaklarERP, CRM, APIStagingHam VeriVeri AmbarıStar SchemaRaporlamaPower BIUçtan Uca Veri Pipeline Mimarisi

Hata 2: DirectLake'i anlamamak

DirectLake, Power BI'ın en heyecan verici özelliğidir ama forumlarda en çok kafa karışıklığı yaratan konu:

  • DirectLake, Lakehouse ve Warehouse'dan doğrudan Delta dosyalarını okur
  • Import gibi hızlı ama DirectQuery gibi her zaman güncel
  • Fallback: Büyük tablolarda veya desteklenmeyen DAX'larda otomatik olarak DirectQuery'ye düşer
SQL
-- DirectLake fallback'i tetikleyen durumlar:
-- 1. Çok fazla satır (varsayılan limit: ~1.5 milyar)
-- 2. Desteklenmeyen DAX fonksiyonları
-- 3. RLS (Row Level Security) bazı senaryolarda

-- Fallback durumunu kontrol etmek için:
-- Semantic Model > Settings > DirectLake Behavior
-- "DirectLake Only" seçerseniz fallback olmaz ama hata alabilirsiniz
⚠️Forum Hatası #2: "DirectLake raporlarım yavaş" — Muhtemelen DirectQuery'ye fallback yapıyor. Semantic model ayarlarından "DirectLake behavior" kontrol edin.

Hata 3: Shortcut'ları yanlış kullanmak

OneLake Shortcuts, başka bir Lakehouse veya harici depolamadan (ADLS, S3) veri referanslama imkânı sunar — veriyi kopyalamadan. Ama forumda sık görülen hata: Shortcut üzerinden yoğun JOIN sorguları çalıştırmak. Bu durumda veriler ağ üzerinden çekildiği için performans çok düşer.

Hibrit Mimari: En İyi Uygulama

Pratikte çoğu kurumsal proje her ikisini de kullanır:

  • Bronze/Silver: Lakehouse'da (Spark ile dönüşüm)
  • Gold: İhtiyaca göre Lakehouse veya Warehouse
  • Raporlama: DirectLake ile Power BI

Sonuç

Lakehouse vs Warehouse sorusunun cevabı "ikisi de" olabilir. Spark dönüşümü ve dosya esnekliği için Lakehouse, T-SQL ve SP desteği için Warehouse kullanın. Medallion Architecture (Bronze-Silver-Gold) ile katmanlı bir yapı kurarak her iki dünyanın da avantajlarından yararlanın. Önemli olan doğru katmanda doğru aracı kullanmak.

💡Fabric mimarinizi birlikte planlayalım. Mevcut veri kaynaklarınıza göre Lakehouse/Warehouse dengesini en verimli şekilde kuruyoruz.