Data lake ve veri ambarı: İki ayrı dünya
Geleneksel olarak data lake ve data warehouse ayrı sistemler olarak konumlandırılırdı. Data lake, ham ve yarı yapılandırılmış verilerin (loglar, IoT verileri, JSON dosyaları) maliyet-effective şekilde depolandığı yer. SQL sorguları için optimize edilmemiş, daha çok veri bilimi ve ML kullanım senaryolarına uygun.
Data warehouse ise yapılandırılmış, temizlenmiş ve modellemesi yapılmış verilerin iş raporlaması için kullanıldığı yer. SQL tabanlı, ACID işlemleri destekler, BI araçlarıyla doğrudan çalışır. Ancak yapılandırılmamış veriler için uygun değildir ve yüksek maliyetlidir.
Sonuç: Veri mühendisleri verileri data lake'e yükler, sonra başka bir süreçle data warehouse'a taşır. İki ayrı veri kopyası, iki ayrı yönetim yükü, veri tutarsızlıkları ve gecikme.
Lakehouse paradigması: İki dünyayı birleştirmek
Lakehouse kavramı, 2010'ların sonlarında Databricks tarafından popülerleştirildi. Temel fikir: Data lake'in esnekliğini (çok çeşitli veri tiplerini, düşük maliyetle, açık formatta saklama) ve data warehouse'un yeteneklerini (ACID işlemleri, SQL sorguları, tablo bazlı erişim kontrolü) tek bir sistemde birleştirmek.
Lakehouse'un sağladığı avantajlar:
- Veri tekrarını azaltır: Tek veri deposu, hem ham veri hem de dönüştürülmüş veri için kullanılır.
- Maliyet düşürür: Object storage (Azure Data Lake Storage) üzerine inşa edilir, pahalı veritabanı sunucuları yerine.
- Açık standartlara dayanır: Delta format, Parquet, Apache Spark — vendor lock-in yok.
- Hem veri bilimi hem BI: Aynı veri üzerinde notebook ile ML, SQL ile raporlama yapılabilir.
Delta format: Lakehouse'un temeli
Lakehouse sistemlerinin çalışmasını sağlayan kritik unsur Delta formatıdır. Delta, Parquet dosya formatının üzerine inşa edilmiş bir katman ve şu temel özellikleri ekler:
ACID işlemleri: Birden fazla yazma işlemini atomik olarak yapabilirsiniz. Transaction log sayesinde veri tutarlılığı garantilenir.
Time travel: Verilerinizin geçmiş hallerine sorgu atabilirsiniz. Yanlış bir veri yazdıysanız, kolayca eski hale dönebilirsiniz.
Schema enforcement: Tanımlanmış şemaya uymayan verilerin yazılmasını engeller. Veri kalitesini otomatik olarak korur.
UPSERT (merge): Verileri hem güncelleyebilir hem de yeni veri ekleyebilirsiniz. Incremental veri yüklemesi kolaylaşır.
Data skipping: Sorgu motorları, metadata üzerinden hangi dosyaların sorguya dahil edilmesi gerektiğini hızlıca belirler. Bu, sorgu performansını ciddi oranda artırır.
💡 Delta formatının en güçlü yanı: Açık kaynak. Azure Databricks, Snowflake, Google BigQuery, Apache Spark — Delta formatını okuyabiliyor. Yani bir kez Delta'ya yazdığınız veri, istediğiniz platformdan erişilebilir. Vendor bağımlılığı oluşmaz.
Fabric Lakehouse: Adım adım mimari
Microsoft Fabric'te Lakehouse deneyimi, bu paradigmayı tek tıkla kurmanızı sağlıyor. İşte tipik bir Fabric Lakehouse mimarisinin katmanları:
1. Veri alma (Ingestion) katmanı
Data Factory veya Eventstream ile kaynak sistemlerden veriler Fabric Lakehouse'a aktarılır. Burada bronze, silver ve gold tabakaları kavramı devreye girer: Bronze (ham, orijinal veri), Silver (temizlenmiş ve dönüştürülmüş veri), Gold (iş kullanıcıları için hazır, агрегат veriler). Bu tabakalaşma, veri kalitesini artırır ve farklı tüketici gruplarının ihtiyaçlarına hitap eder.
2. Depolama katmanı (OneLake)
Fabric Lakehouse, OneLake üzerinde . parquet dosyaları olarak verileri saklar. OneLake'in short-cut özelliği sayesinde, farklı workspace'lerdeki ekipler aynı veriye erişebilir — veri kopyalanmadan. Klasik ADLS Gen2 yapısında dosyalar "abfss://" protokolüyle saklanır.
3. Dönüşüm katmanı (Spark / Notebook)
Spark Notebook'ları ile veriler bronze'dan silver'a, silver'dan gold'a dönüştürülür. PySpark veya Spark SQL kullanılarak veri temizleme, kalite kontrolleri ve iş kuralları uygulanır. Her notebook, CI/CD pipeline'ına entegre edilebilir.
4. Semantik katman (Warehouse veya Direct Lake)
Lakehouse üzerinde Fabric Warehouse kurarak, verilerinizi SQL ile sorgulanabilir hale getirebilirsiniz. Warehouse, T-SQL sözdizimini destekler — yani klasik SQL bilen herkes doğrudan sorgu yazabilir. Alternatif olarak, Power BI Direct Lake modu ile Lakehouse'taki verileri doğrudan sorgulayabilirsiniz.
Gerçek senaryo: E-ticaret veri platformu
Bir e-ticaret platformu düşünün: Web sitesi logları (JSON, yarı yapılandırılmış), POS verileri (yapılandırılmış SQL), müşteri destek kayıtları (metin), IoT envanter verileri (zaman serisi) — hepsi farklı formatlarda ve farklı sistemlerde.
Geleneksel yaklaşım: ETL araçlarıyla her kaynaktan veri çekilir, dönüştürülür, ayrı bir veri ambarına yüklenir. Data lake ayrı tutulur. Her iki sistemi yönetmek, senkronize tutmak, yedeklemek — operasyonel yük çok ağır.
Fabric Lakehouse yaklaşımı: Data Factory ile tüm kaynaklardan veriler bronze tabakasına yüklenir. Spark ile temizleme ve dönüştürme yapılır, silver tabakasına alınır. Warehouse'da gold tabakası kurulur ve SQL ile iş raporlaması yapılır. Aynı anda veri bilimcileri aynı Lakehouse üzerinde ML modelleri geliştirir. Power BI Direct Lake ile anlık raporlama yapılır. Tek veri deposu, sıfır veri tekrarı, merkezi yönetim.
Kimball yaklaşımı ile Fabric Lakehouse
Lakehouse, Kimball'ın dimensional modeling yaklaşımını tamamen ortadan kaldırmıyor. Aksine, gold tabakasında Kimball ilkelerine uygun star schema yapıları kurmak, raporlama performansını ve kullanılabilirliğini artırıyor.
Fabric Warehouse'da fact ve dimension tabloları Delta formatında tutulabilir. Spark ile fact tabloyu güncellerken, dimension tablolarının SCD Type 2 tarihselliğini yönetebilirsiniz. Power BI ise bu yapıyı Direct Lake veya T-SQL üzerinden tüketir.