On yıl boyunca kurumlar iki ayrı sistem işletti: ham veriyi ucuza saklayan data lake ve hızlı SQL için yapılandırılmış data warehouse. Veri çoğu zaman iki kez kopyalandı, iki kez yönetildi, iki gerçek üretti. Lakehouse mimarisi bu ikiliği bitirme iddiasındadır: nesne depolamanın ucuzluğu ile warehouse'un güvenilirliğini tek katmanda buluşturur.
Sorun: lake ile warehouse arasındaki uçurum
Klasik mimaride veri akışı şöyleydi: kaynaklar → data lake (Parquet/CSV, ucuz ama ACID yok) → ETL → data warehouse (hızlı, ACID, ama pahalı ve kapalı). Sonuç: gecikme, ikili maliyet, lineage kopukluğu ve 'hangi kopya doğru' tartışması.
Açık tablo formatları
Lakehouse'u mümkün kılan teknoloji açık tablo formatlarıdır: Apache Iceberg, Delta Lake ve Apache Hudi. Bunlar nesne depolamadaki Parquet dosyalarının üzerine bir metadata katmanı ekler ve şu yetenekleri getirir:
- ACID transaction: eşzamanlı yazma/okuma tutarlılığı.
- Time-travel: tablonun geçmiş bir versiyonunu sorgulama (audit ve hata düzeltme için kritik).
- Schema evolution: kolon ekleme/değiştirme tabloyu yeniden yazmadan.
- Partition evolution / hidden partitioning: sorgu performansını bozmadan partition stratejisi değiştirme.
Medallion mimari
Lakehouse'ta veri genelde üç kalite katmanında ilerler:
- Bronze: kaynaktan gelen ham veri, neredeyse dokunulmadan.
- Silver: temizlenmiş, tekilleştirilmiş, birleştirilmiş veri.
- Gold: iş için hazır, agregat ve metric tabloları (BI ve ML buradan beslenir).
Her katman aynı açık formatta durur; ayrı sistem yok, sadece olgunluk seviyesi farklı.
Compute-storage ayrımı
Lakehouse'ın ekonomik avantajı, hesaplama ile depolamanın ayrı ölçeklenmesidir. Veri S3/ADLS/GCS'de ucuza durur; sorgu anında Spark, Trino, Dremio veya Databricks gibi motorlar geçici olarak hesaplama açar. Gece kimse sorgu yapmıyorsa compute maliyeti sıfıra iner; warehouse'taki '7/24 açık küme' maliyeti ortadan kalkar.
Warehouse tamamen ölüyor mu?
Hayır. Çok düşük gecikme gerektiren, yüksek eşzamanlı BI yüklerinde Snowflake/BigQuery gibi yönetilen warehouse'lar hâlâ daha öngörülebilir performans verir. Birçok kurum hibrit gider: lakehouse ham + silver + ML için, warehouse ise gold/BI servis katmanı için. Iceberg gibi formatların hem Snowflake hem Spark tarafından okunabilmesi bu hibridi kolaylaştırır.
Geçiş planı
Mevcut lake + warehouse'tan lakehouse'a tipik geçiş:
- Bir açık format seçin (ekosisteminize göre Iceberg veya Delta).
- Bronze/silver katmanı lake'ten lakehouse formatına taşıyın.
- dbt veya Spark ile gold katmanı tanımlayın; metric'leri semantik katmana bağlayın.
- BI araçlarını önce gold tablolarına yöneltin, warehouse'u kademeli emekliye ayırın.
- Time-travel ve lineage'ı denetim süreçlerine entegre edin.
Sonuç
Lakehouse, 'ucuz ama dağınık lake' ile 'hızlı ama pahalı warehouse' arasındaki on yıllık tercihi açık tablo formatlarıyla ortadan kaldırır. ACID, time-travel ve schema evolution sayesinde tek bir veri kopyası hem ML hem BI'ı besler. Doğru kurulduğunda ikili maliyet, ikili kopya ve 'hangisi doğru' tartışması biter.
