DWH vs Data Lake vs Delta Lake

 

Verinin Artan Karmaşıklığı ve Yönetim Problemleri

Son yıllarda verinin hem hacmi hem kaynağı hem de kullanım şekli ciddi bir değişim geçirdi. Eskiden bir işletmenin sahip olduğu veri, yalnızca müşteri, ürün ve fatura bilgileri gibi sınırlı, yapılandırılmış verilere dayanıyordu. Ancak teknolojinin hızla gelişmesiyle birlikte bu sınırlar ortadan kalktı.

Artık bir firmanın elindeki veri, sadece fatura kesmek için kullanılan sistemlerdeki bilgilerden ibaret değil. Web sitesi tıklamaları, sosyal medya etkileşimleri, IoT cihazlarından gelen sensör verileri, uygulama logları, müşteri davranış kayıtları ve daha fazlası iş süreçlerinde karar almanın merkezine oturdu.

Veri büyüklüğüyle birlikte kaynak çeşitliliği de arttı. Bugün bir işletmenin elinde onlarca farklı uygulamanın ürettiği veri bulunuyor. Bu verilerin her biri, birbirinden bağımsız sistemlerde saklanıyor. Dolayısıyla, geçmişte tek bir veritabanında toplanan veri artık çok farklı kaynaklardan beslenir hale geldi.

İşte bu değişim, firmaları yeni bir sorunla karşı karşıya bıraktı:
Farklı sistemlerden gelen verileri, merkezi, tutarlı ve analiz edilebilir bir yapıya dönüştürmek.

Tam da bu ihtiyaçların sonucu olarak karşımıza sırasıyla Data Warehouse, Data Lake ve Delta Lake çözümleri çıktı.

 

Data Warehouse (DWH)  Neden Ortaya Çıktı, Ne İhtiyacı Çözdü?

Data Warehouse kavramı, aslında firmaların operasyonel sistemler üzerinde yaşadığı temel sorunlardan doğdu.

Veri kaynaklarının çeşitlenmesiyle birlikte şirketler şunu fark etti:

• Veriye ulaşmak için her sistemin kendi veritabanına bağlanmak zorundasın, bu da işlem sayısını ve karmaşıklığı ciddi şekilde arttırır.
• Operasyonel sistemler (OLTP) yüksek hızda veri girişi ve işlem için optimize edilmiştir, analiz için değil.
• OLTP sistemlerde tarihsel veri saklamak zordur, çünkü veriler sürekli güncellenir ve sistem genellikle sadece "son hali" tutar.
• Analiz ve raporlama gibi ağır işlemler için bu sistemler kaynak ayırmaz, dolayısıyla bu işlemler hem sistem performansını düşürür hem de veri bütünlüğünü riske atar.

Başka bir problem de merkezi yapı eksikliğiydi. Firmalar, farklı kaynaklarda tutulan verileri birleştirip tutarlı bir şekilde analiz etmekte zorlanıyordu. Bunun günlük hayattaki örnekleri şunlardır:

• CRM’de müşteri "Ahmet Yılmaz" olarak kayıtlıyken, fatura sisteminde "A. Yılmaz" olarak tutulabilir.
• Sipariş kaydında "12-04-2024 15:32" formatında tarih kullanılırken, fatura sisteminde "2024/04/12 15:32:00" formatı tercih edilmiş olabilir.
• Ürün verisi bir kaynaktan "SKU-123", başka bir kaynaktan "SKU_123" olarak gelebilir.

Bu farklılıklar, doğru analiz yapılmasını engelleyen ciddi sorunlara yol açıyordu. Şirketler, aynı ürüne ya da aynı müşteriye ait verileri, farklı sistemlerde birbirine eşleştiremez hale geliyordu.

Örneğin, bir perakende zincirinde müşteri sadakat programı uyguluyorsanız, müşterinizin alışveriş davranışlarını anlamak için CRM’den, POS sisteminden ve kampanya yönetim platformundan gelen verileri birleştirmeniz gerekir. Ancak bu sistemlerde müşteri verileri farklı biçimlerde tutulduğunda doğru analiz yapmak neredeyse imkansız hale gelir.

Aynı problem lojistik sektöründe de görülür. Sevkiyat tarihi bir sistemde UTC zaman diliminde tutulurken, diğeri yerel saat kullanır. İki verinin birleştirilmesinde tarih uyuşmazlıkları, hatalı raporlamalara sebep olur.

Data Warehouse, bu karmaşanın ortadan kalkmasını sağlayan merkezi bir yapıdır. Tüm verileri standartlaştırır, tarihsel olarak saklar, analiz için optimize eder ve iş kararları için güvenilir bir kaynak sunar.

DWH sistemlerinin sunduğu temel faydalar şunlardır:

• Operasyonel sistemlerin yükünü azaltır ve performansı korur.
• Verinin geçmiş versiyonlarını saklayarak, geçmişe dönük analiz yapılmasına olanak sağlar.
• Merkezi bir veri kaynağı sunarak, sistemler arası tutarsızlıkları ortadan kaldırır.
• Veri temizleme ve standardizasyon işlemleri sayesinde, raporların doğruluk oranını yükseltir.

Özetle; DWH yapıları sadece “veriyi saklamak” için değil, kurumsal verinin doğru analiz edilebilmesi için ortaya çıkmış, bir nevi temel ihtiyaçtır.

Data Warehouse Mimarisi — Temel Yapı, Kullanım Senaryoları ve Avantajları

Data Warehouse kavramı, sadece veriyi toplamakla kalmaz, aynı zamanda bu veriyi analiz için en uygun yapıya dönüştürür. Bunu yapabilmek için belirli bir mimari tasarıma ihtiyaç vardır. Bu yapı, genel olarak üç temel katmandan oluşur:

a) Kaynak Sistemler (Source Systems)
Bu katmanda, veriyi üreten sistemler yer alır. Bunlar genellikle operasyonel veritabanlarıdır. CRM, ERP, sipariş sistemleri, finansal yazılımlar, web sunucuları, IoT cihazları ve daha birçok kaynaktan gelen veriler bu katmanın parçasıdır.

Buradaki en büyük problem, her sistemin farklı veritabanı yapısına ve veri standardına sahip olmasıdır. Örneğin bir müşteri kaydı; CRM’de 10 alan içerirken, ERP sisteminde sadece 5 alandan oluşabilir.

 

b) ETL Süreçleri (Extract, Transform, Load)
DWH mimarisinin belki de en önemli katmanıdır. Farklı kaynaklardan gelen verilerin okunması (Extract), iş kurallarına göre temizlenmesi ve dönüştürülmesi (Transform) ve hedef sisteme yüklenmesi (Load) bu süreçte gerçekleşir.

Bu aşamada tipik olarak şu işlemler yapılır:

• Veri temizliği: Null değerlerin kontrolü, hatalı verilerin düzeltilmesi.
• Kod standardizasyonu: Örneğin "Erkek/Kadın" yerine "M/F" gibi tek tip format kullanımı.
• Kimlik eşleştirme: Bir müşteri kaydının farklı sistemlerdeki ID’lerinin birleştirilmesi.
• Tarihsel veri yönetimi: Slowly Changing Dimension (SCD) kurallarına göre geçmiş verinin saklanması.

Bu süreç, Data Warehouse'un kalitesini ve güvenilirliğini doğrudan etkiler. Kötü tasarlanmış bir ETL süreci, DWH sisteminin sağlıklı çalışmasını imkansız hale getirir.

 

c) Data Warehouse Katmanı
ETL süreciyle temizlenmiş ve standardize edilmiş veriler, bu katmanda saklanır. Genellikle iki ana model tercih edilir:

• Kimball Modeli (Dimensional Modeling): Star Schema, Snowflake Schema gibi yapılarla raporlamaya odaklanır. Boyut tabloları (Dimension) ve ölçüm tabloları (Fact) şeklinde veri organize edilir.
• Inmon Modeli (Corporate Information Factory): Normalleştirilmiş yapılarla önce kurumsal veri deposu (Enterprise Data Warehouse) oluşturulur, ardından Data Mart’lar aracılığıyla raporlama yapılır.

Her iki modelin de amacı aynıdır: veriyi anlamlı, hızlı ve tutarlı şekilde analiz edilebilir hale getirmek.

 

DWH Kullanım Senaryoları

Data Warehouse sistemleri, neredeyse her sektörde farklı problemleri çözmek için kullanılır. İşte bazı örnek senaryolar:

• Bir bankanın kredi başvurularında, müşterinin son 5 yıllık kredi skorunun değişimini analiz etmek.
• Bir perakende firmasının, ürün fiyat değişimlerini yıllık bazda raporlamak.
• Bir sigorta şirketinin hasar dosyalarını, poliçe süresi ve müşteri özelliklerine göre segmentleyerek risk analizleri yapmak.
• Bir e-ticaret firmasının, geçmiş kampanyalara ait satış performansını kıyaslayabilmesi.

Tüm bu senaryolarda verinin sadece "anlık" hali değil, geçmişi de analiz edilir. Bunu yapmanın tek yolu, DWH gibi tarihsel veri saklayan, performanslı sorgulamalara uygun bir yapıya sahip olmaktır.

DWH’nin Avantajları:

• Tarihsel Veri Saklama: Geçmişe dönük analizler yapmanızı sağlar.
• Veri Tutarlılığı: Tüm sistemlerden gelen verileri tek bir yerde temiz, doğrulanmış ve standartlaştırılmış halde saklar.
• Performans: Sorgular için optimize edilmiş yapı sunar, OLTP sistemlerde yaşanabilecek performans problemlerini ortadan kaldırır.
• Merkezi Yapı: Dağınık kaynaklardan gelen verileri bir araya toplar, yönetimi kolaylaştırır.

Data Lake  Neden Ortaya Çıktı, Ne Sorunları Çözdü?

Data Warehouse yapıları uzun yıllar boyunca veri analiz dünyasının temel taşını oluşturdu. Fakat zaman değişti, veri hacmi katlanarak büyüdü, veri kaynakları çeşitlendi ve şirketlerin sadece yapılandırılmış veriye değil, yapılandırılmamış veriye de ihtiyaçları artmaya başladı.

Bir DWH sistemi, relational yapıda ve genellikle tablolara uygun, düzenli (structured) veriler için tasarlanmıştı. Ancak modern iş dünyasında artık şunlar da verinin parçası haline geldi:

• Uygulama log dosyaları
• Sunucu hata logları
• Web sitesi tıklama geçmişleri
• Mobil uygulama kullanım kayıtları
• Sensör verileri (IoT)
• JSON, XML gibi yarı yapılandırılmış dosyalar
• Video, ses, görsel dosyalar

Bu verilerin ortak noktası, klasik veritabanı sistemlerine sığmıyor olmalarıdır. Hacimleri büyük, yapıları esnek, hatta çoğu zaman şemaları bile sabit değil.

Bir örnek düşünelim:
Bir e-ticaret firmasının ürün detay sayfasında, kullanıcıların gerçekleştirdiği her tıklamanın kaydını almak istiyorsunuz.

• Bir müşteri, ürün fotoğrafına tıklamış.
• Başka biri yorum sekmesini açmış.
• Bir diğeri fiyat bilgisini kontrol etmiş.

Her tıklama ayrı bir olay, her olay farklı bir JSON yapısında.

Bu veri, klasik anlamda bir tablonun satır ve sütun yapısına sığmaz. Üstelik bu log verileri saniyede binlerce adet üretilebilir ve bu veriyi hızlıca kaydedip ileride işlemek isteyebilirsiniz.

İşte bu durum, DWH sistemlerinin sınırlarına dayanıldığı anlamına geliyordu. Çünkü:

• DWH sistemleri bu kadar büyük hacimli, esnek yapılı veriyi depolamak için uygun değildir.
• Veriyi önce şemaya uydurmak gerekir, bu da veri yükleme sırasında kayıplara ve esneklik sorunlarına yol açar.
• DWH sistemlerinde disk alanı ve donanım maliyetleri çok daha yüksektir.

Data Lake’in Doğuşu

Tüm bu nedenlerle, veri dünyası yeni bir çözüm arayışına girdi:
Veriyi önce depolayalım, sonra işleriz.

Data Lake yaklaşımı bu prensibe dayanır. Yapılandırılmış ya da yapılandırılmamış fark etmeksizin tüm veriler olduğu gibi, ham haliyle saklanır.

Data Lake, verinin adeta bir hammadde deposudur.

Bir fabrika gibi düşünün:

• Ürün üretilmeden önce hammadde neyse, Data Lake’te de veri o şekilde tutulur.
• Ne zaman hangi veriye, hangi iş için ihtiyaç duyulacağı bilinemez; bu yüzden veriyi önce kaybetmeden toplamak ve saklamak gerekir.

Data Lake’in Kullanım Senaryoları

Data Lake yapıları, özellikle aşağıdaki durumlar için tercih edilir:

• Yüksek hacimli, şeması değişken verilerin saklanması.
• Veri modelinin baştan net olmadığı durumlarda esnek depolama.
• Veri bilimi (Data Science) ve makine öğrenmesi projeleri için geniş veri havuzu.
• Web log analizi, IoT sensör verileri, clickstream gibi sürekli akan veri kaynaklarının depolanması.
• Farklı kaynaklardan gelen verilerin ileride birleştirilmek üzere arşivlenmesi.

Bir lojistik firmasını düşünün:
Her taşıma aracının GPS cihazından saniyede konum bilgisi geliyor. Bu veriyi relational bir veritabanında anlık olarak kaydetmeye çalışırsanız, sistem kısa sürede tıkanır. Bunun yerine, veriyi bir Data Lake’e ham haliyle saklarsınız. Daha sonra ihtiyaç olduğunda bu veriyi filtreleyip analiz edebilirsiniz.

Benzer şekilde, bir bankanın fraud (dolandırıcılık) tespiti yapmak için müşteri hareketlerini, kart işlemlerini, uygulama giriş loglarını ve web tıklamalarını eş zamanlı izlemesi gerekir. Tüm bu farklı veri türleri, Data Lake gibi esnek ve ölçeklenebilir bir ortamda depolanır.

Data Lake Mimarisi , Kullanım Şekli, Avantajları, Eksileri

Data Lake, yapılandırılmamış ve yarı yapılandırılmış verilerin yüksek hacimli, esnek bir şekilde depolanmasına olanak tanır. Bu mimari, veriyi olduğu gibi, ham haliyle saklayarak gelecekteki analiz ve işleme ihtiyaçları için erişilebilir kılar. Data Lake’in temel amacı, veriyi baştan belirli bir şemaya uydurmadan önce depolamak, böylece daha sonra işlenebilmesini sağlamaktır.

Data Lake mimarisi genellikle şu temel bileşenlerden oluşur:

1. Veri Depolama Katmanı Data Lake’in en temel bileşeni, verilerin saklandığı depolama alanıdır. Bu katman, verinin ham biçimde saklanmasını sağlar ve genellikle büyük veri sistemleri (örneğin Hadoop HDFS, Amazon S3) üzerinde bulunur. Depolama alanı, düşük maliyetli ve ölçeklenebilir olmalıdır çünkü veri miktarı hızla artabilir. Bu katman, yapılandırılmış, yarı yapılandırılmış ve yapılandırılmamış verilerin tümünü aynı ortamda depolamayı mümkün kılar.
2. Veri İşleme Katmanı Bu katman, verilerin analiz edilmeden önce işlenmesi ve dönüştürülmesi gereken aşamadır. Veri işleme, çeşitli veri işleme motorları kullanılarak yapılabilir; örneğin, Apache Spark veya Apache Flink gibi araçlar veri üzerinde karmaşık analizler ve dönüştürme işlemleri gerçekleştirebilir. Ayrıca, veri mühendisleri veya veri bilimcileri, veri ambarına veya başka bir analitik platforma yüklenmeden önce veriyi işlemek için ETL/ELT süreçlerini kullanabilir.
3. Veri Yönetimi ve Güvenlik Katmanı Data Lake’te veriyi depolamak kadar onu yönetmek de kritik bir unsurdur. Verinin tutarlılığı, güvenliği ve erişilebilirliği sağlanmalıdır. Bu katman, veri yönetimini sağlayan metadata yönetimi, veri kalitesi denetimleri ve veri güvenliği politikaları gibi bileşenleri içerir. Metadata, verinin içeriği, anlamı ve kaynağı hakkında bilgi sağlar ve bu bilgi, kullanıcıların veri üzerinde etkili analizler yapabilmesi için önemlidir.
4. Veri Analizi Katmanı Bu katman, Data Lake'te saklanan verilerin analiz edilmesini sağlar. Veri bilimcilerinin ve analistlerinin, veriyi sorgulamalarına ve raporlar oluşturmasına olanak tanır. Yüksek performanslı analizler yapmak için SQL, Python, R gibi diller ve araçlar kullanılabilir. Ayrıca, Data Lake’teki verilerden anlamlı sonuçlar çıkarmak için makine öğrenmesi ve yapay zeka modelleri de eğitilebilir.

Data Lake’in Avantajları

1. Esneklik ve Çeşitlilik Data Lake, verinin her türünü depolayabilen esnek bir yapıya sahiptir. Yapılandırılmış, yarı yapılandırılmış ve yapılandırılmamış veriler bir arada saklanabilir. Bu, kullanıcıların çeşitli veri kaynaklarından gelen verileri entegre etmelerini sağlar. Verinin türü, boyutu veya formatı konusunda herhangi bir sınırlama yoktur.
2. Düşük Maliyet Yapılandırılmamış veriler, Data Lake gibi sistemlerde daha düşük maliyetlerle saklanabilir. Verinin ham haliyle saklanması, gereksiz veri dönüştürme işlemlerinin önüne geçer ve donanım maliyetlerini minimize eder. Ayrıca, ölçeklenebilir yapısı sayesinde, veri miktarındaki artışa paralel olarak maliyetlerin artırılması engellenir.
3. Ölçeklenebilirlik Data Lake’in mimarisi, veri miktarındaki artışla uyumlu olarak ölçeklenebilir. Yatayda büyüme (horizontal scaling) imkanı sunarak veri depolama kapasitesinin hızla artırılmasına olanak tanır. Bu, büyük veri ortamlarında oldukça önemli bir avantajdır, çünkü verinin hızla büyüyen boyutlarını yönetmek için sürekli olarak ek kapasite sağlanabilir.
4. Veri Bilimi ve Makine Öğrenmesi Uyumlu Data Lake, veri bilimcileri için büyük veri setlerine erişim imkanı tanır ve makine öğrenmesi (ML) projeleri için zengin bir veri kaynağı sağlar. Ham veri üzerinde yapılan analizler ve veri mühendisliği çalışmaları, doğru modelleme ve tahminler için temel oluşturur. Veri bilimcileri, çeşitli algoritmalar kullanarak bu veriler üzerinde derinlemesine analizler yapabilir.

Data Lake’in Eksileri

1. Veri Tutarsızlığı Data Lake’te verinin ham haliyle depolanması, bazen tutarsız verilere yol açabilir. ACID transaction garantisi olmadan veri yüklemesi yapılırsa, veri tutarsızlıkları oluşabilir. Bu durum, veri güvenliği ve doğruluğu açısından ciddi sorunlara yol açabilir. Ayrıca, veri karmaşası, kullanıcıların doğru veri setlerine ulaşmalarını zorlaştırabilir.
2. Data Swamp Riski Data Lake, veriyi esnek bir şekilde depolayabilme imkanı sunsa da, doğru yönetilmediğinde "data swamp" (veri bataklığı) riskiyle karşı karşıya kalabilir. Bu durumda, veri setlerinin tanımları, sınıflandırılmaları veya etiketlenmeleri yapılmazsa, zamanla bu veriler erişilemez hale gelebilir. Bu, ileride veri üzerinde anlamlı analizler yapmayı imkansız hale getirebilir.
3. Raporlama Zorluğu Data Lake’teki verilerin ham halde saklanıyor olması, raporlama ve analitik süreçleri zorlaştırabilir. Veriyi analiz edebilmek için önce verinin uygun hale getirilmesi gereklidir. Raporlama araçları genellikle bu tür ham verilerle doğrudan çalışamaz, dolayısıyla kullanıcıların veriyi işlemek için ekstra adımlar atması gerekebilir.

Sonuç olarak, Data Lake’in sunduğu esneklik ve düşük maliyet avantajları, onu büyük veri ve veri bilimi projeleri için cazip bir çözüm haline getirirken, veri tutarlılığı ve yönetim konusundaki zorluklar, dikkatli bir planlama ve yönetim gerektirir.

Delta Lake Ne Yapıyor?

Data Lake’ler, büyük veri işleme süreçlerinin temel yapı taşlarından biri haline gelmiştir. Ancak, bu yapıların bir dizi sınırlamaları bulunmaktadır. Özellikle veri kalitesi, tutarlılık ve yönetilebilirlik gibi konular, Data Lake'lerin verimli kullanılmasını zorlaştırmaktadır. İşte bu noktada Delta Lake devreye giriyor. Delta Lake, Data Lake üzerindeki en büyük gelişim olarak kabul edilir çünkü veri üzerinde tutarlılık ve doğruluk sağlayan ACID işlemleri sunar. Bu sayede, Delta Lake, Data Lake'lerin yaygın olarak karşılaştığı sorunları çözerek, veri mühendisliğinde ve veri bilimi projelerinde daha sağlam ve güvenilir bir çözüm sunar.

Delta Lake, Apache Spark ile entegre çalışarak, verilerin yüksek hızda işlenmesine olanak tanır ve büyük veri ortamlarında işlemleri daha verimli hale getirir. Ayrıca, time travel özelliği sayesinde, verinin geçmiş sürümlerine kolayca erişim imkanı sağlar ve veri kaybını önler. Delta Lake'in sunduğu ACID garantileri, veri üzerinde yapılan her türlü işlemi izleyebilir ve hata durumlarında veriye geri dönme imkanı verir.

Data Lake’lerde sıklıkla karşılaşılan sorunlardan biri de verilerin karmaşık bir biçimde saklanmasıdır. Bu, veri analistlerinin ve veri bilimcilerinin doğru veri setlerine ulaşmasını zorlaştırır. Delta Lake, bu sorunları çözmek için verileri daha yapılandırılmış bir formatta saklar ve sorgu performansını iyileştirir. Ayrıca, Delta Lake'in veri yönetimi özellikleri sayesinde, veriler kolayca temizlenebilir, sıkıştırılabilir ve optimize edilebilir.

Özetle, Delta Lake, Data Lake'lerin sunduğu esneklikten ödün vermeden, verilerin tutarlılığını ve yönetilebilirliğini sağlayarak, büyük veri sistemlerinde önemli bir iyileştirme ve gelişim sunar. Bu, özellikle veri mühendisliğinde büyük veri setlerinin yönetimi, güvenliği ve analizi konusunda büyük bir adım anlamına gelir.

Delta Lake Mimarisi, Kullanım Şekli, Avantajları, Eksileri

Delta Lake, özellikle büyük veri analizleri için kullanılan, Apache Spark tabanlı bir açık kaynaklı veri saklama katmanıdır. Verilerin zaman içinde doğru ve tutarlı bir şekilde saklanması ve işlenmesi için ACID işlemleri (Atomicity, Consistency, Isolation, Durability) sağlar. Delta Lake, Data Lake ve veri ambarları arasındaki boşluğu doldurarak, veriyi yönetilebilir ve analiz edilebilir hale getirir. Bu çözüm, veri mühendisliğinde ve veri bilimi projelerinde büyük veri setleriyle çalışırken önemli avantajlar sunar.

Delta Lake Mimari Bileşenleri

1. Delta Log Delta Lake’in en temel bileşeni, verinin nasıl değiştiğini ve güncellendiğini izleyen Delta Log’dur. Delta Log, her veri işlemi (güncelleme, silme, ekleme vb.) için bir kayıt tutar. Bu sayede, veri üzerinde yapılacak her türlü işlemin geri alınabilir ve izlenebilir olmasını sağlar. Delta Log, verinin konsistensini ve doğruluğunu güvence altına alır.
2. Veri Depolama Katmanı Delta Lake, veriyi genellikle bir Data Lake ortamında saklar. Bu ortamda, veriler Apache Parquet formatında saklanır ve bu, büyük veri setlerinin hızlı bir şekilde depolanmasını ve okunmasını sağlar. Delta Lake, verilerin daha sonra işlenmesi için veri mühendisliği ve veri bilimi süreçlerinde kullanılmak üzere yüksek performanslı bir veri yapısı sunar.
3. ACID İşlemleri Delta Lake, ACID garantileri sağlayarak verilerin tutarlılığını ve doğruluğunu korur. Bu, verinin paralel işleme süreçlerinde bile güvenilir olmasını sağlar. ACID garantileri, özellikle büyük veri işleme ve analiz süreçlerinde önemlidir çünkü verilerin tutarlı ve hatasız bir şekilde işlenmesi gerekir.
4. Time Travel Delta Lake’in sunduğu önemli özelliklerden biri de time travel özelliğidir. Bu özellik sayesinde, kullanıcılar geçmişteki veri sürümlerine erişebilir ve herhangi bir hatalı veri güncellemesi veya silme işleminden önceki veriye dönebilirler. Bu, veri kaybı veya hatalı veri güncellemelerinin önüne geçilmesini sağlar.
5. Veri Sıkıştırma ve Yönetim Delta Lake, veri yönetimi ve performans iyileştirmeleri için çeşitli teknikler kullanır. Bunlar arasında verilerin sıkıştırılması, eski verilerin arşivlenmesi ve küçük dosyaların büyük dosyalar haline getirilmesi yer alır. Bu teknikler, veri setlerinin daha verimli bir şekilde saklanmasını sağlar.

Delta Lake’in Avantajları

1. ACID Garantileri Delta Lake, verinin doğruluğunu ve tutarlılığını garanti eder. ACID işlemleri sayesinde veri kaybı veya çakışan işlemler gibi problemler ortadan kalkar. Bu, verinin her zaman tutarlı ve güvenilir olmasını sağlar, özellikle büyük veri işleme süreçlerinde önemlidir.
2. Time Travel Özelliği Delta Lake'in time travel özelliği, verinin geçmiş sürümlerine kolayca erişilmesini sağlar. Bu özellik, hatalı veri güncellemeleri veya silme işlemlerinden sonra veri kaybı yaşanmasının önüne geçer. Ayrıca, geçmiş veri sürümleri üzerinde test ve analiz yapma imkanı sunar.
3. Yüksek Performans ve Ölçeklenebilirlik Delta Lake, Apache Spark üzerinde çalışarak büyük veri işlemlerini hızlandırır. Bu sayede, veri mühendisleri ve veri bilimcileri büyük veri setleri üzerinde analizler yaparken yüksek performans alır. Ayrıca, Delta Lake’in mimarisi, yatayda ölçeklenebilir, yani veri miktarındaki artışa paralel olarak daha fazla işlem gücü eklenebilir.
4. Veri Entegrasyonu ve Esneklik Delta Lake, farklı veri kaynaklarından gelen verilerin entegre edilmesine olanak tanır. Yapılandırılmış ve yapılandırılmamış verilerin aynı ortamda depolanması, veri mühendisliğinde büyük esneklik sağlar. Delta Lake, veri işleme ve analiz süreçlerinde esnekliği arttırarak daha hızlı ve verimli çözümler sunar.
5. Veri Kalitesi Yönetimi Delta Lake, veri kalitesinin yönetilmesine yardımcı olur. Veriler, yanlış formatlarda veya hatalı olanlar temizlenip düzenlenmeden depolanmaz. Bu, veri mühendisliği süreçlerini iyileştirir ve verinin doğruluğunu arttırır.

Delta Lake’in Eksileri

1. Yüksek Maliyetli Kurulum Delta Lake, Apache Spark gibi büyük veri platformlarını gerektirdiği için, bu altyapıların kurulumu ve yönetimi maliyetli olabilir. Özellikle küçük ve orta ölçekli şirketler için bu maliyetler, veri analitiği süreçlerinin verimli ve uygun maliyetli bir şekilde gerçekleştirilmesini engelleyebilir.Gerçi cloud seçeneği ile bu o kadar da korktucu gelmiyor insana artık.
2. Veri Hacmi ve Yönetim Zorlukları Delta Lake, büyük veri setlerini yönetmek için güçlü bir araç olmasına rağmen, büyük veri hacimlerinin yönetilmesi hala zorluklar yaratabilir. Verinin doğru şekilde sıkıştırılması, düzenlenmesi ve etiketlenmesi gereklidir. Ayrıca, çok büyük veri setlerinde zamanla seyahat özelliği de verimli çalışmak için yüksek performanslı altyapı gerektirir.
3. Öğrenme Zorluğu Delta Lake, özellikle yeni başlayanlar için öğrenilmesi gereken yeni bir sistem olabilir. Diğer yapılara göre öğrenmesi ve uygulaması daha zor olduğunu söylemek lazım.

Sonuç olarak, Delta Lake, veriyi güvenli bir şekilde depolayarak analitik ve makine öğrenmesi uygulamaları için güçlü bir altyapı sunar. Ancak, yüksek maliyetler, veri yönetimi zorlukları ve öğrenme zorluğu gibi eksileri de göz önünde bulundurulmalıdır.

Data Warehouse vs Data Lake vs Delta Lake Karşılaştırma

Hepsini karşılaştıracak olursak:

• Data Warehouse:
  Yapılandırılmış veriler için optimize edilmiştir. Yüksek veri kalitesi, güçlü tutarlılık (ACID) ve hızlı raporlama sunar. Genelde iş zekası ve karar destek sistemleri için tercih edilir.
• Data Lake:
  Her tür veriyi (yapısal, yarı-yapısal, yapılandırılmamış) ham formatta saklar. Esnektir ve ölçeklenebilir. Ancak veri kalitesi kontrolü yoktur; zamanla “Data Swamp” riskine yol açabilir.
• Delta Lake:
  Data Lake üzerine ACID garantileri, versiyonlama (time travel) ve güvenilir güncelleme imkanı ekler. Esneklik ve veri ambarı disiplinini bir araya getirir.

Özet:
Data Warehouse, doğruluk ve raporlama için;
Data Lake, esneklik ve ham veri saklama için;
Delta Lake, bu iki çözümü bir araya getirmek için tercih edilir.

Birçok veri platformu artık bu yapıların bir arada çalıştığı çok katmanlı bir mimari kullanmaktadır. Özellikle Microsoft Fabric ve Databricks gibi servisler, bu üç yapıyı senkron çalıştırarak veri ihtiyaçlarının tamamını karşılamayı hedefliyorlar.

DWH’da Veri Bütünlüğü Veri Temizliği

 

DWH’da Veri Bütünlüğü Veri Temizliği

Veri bütünlüğü tüm ortamlarda olduğu gibi DWH’da da en önemli konulardan bir tanesi.Veri bütünlüğünü şöyle özetleyebiliriz müşteri tablosunda olmayan bir müşteriye ait satış olmamalıdır.Biz genelde dimensional modellemede(kimball) inmon modelleme kadar özen göstermeyebiliyoruz veri bütünlüğüne ama bizde de elbette sorunlara yol açabiliyor.

Normalde kaynak sistemlerimizin normalize edilmesini ve bütünlüğün FK’larla sağlanmasını bekliyoruz.Fakat bu her zaman istenildiği ölçüde başarılı olmayabiliyor.Özellikle eski sistemlerde bu çok başımıza gelebiliyor.Bu durumda yapmamız gereken ilk şey kaynak sistemde bu sorunları düzeltmek olmalı.Çünkü software ve data engineer olarak ayrılsakda bu bir bütün meselesi ve söz konusu olan iş dağılımı değil şirketin bütünlüğü.Dolayısıyla testlerinizde böyle bir örnek ile karşılaştınız veya iş biriminiz fark ettiğinde,sorunu kendi tarafınızda çözmeye çalışmaktansa kaynak sistemdeki arkadaşlarla görüşüp datayı orada düzenletirseniz sizin süreciniz dışındada bu datayla bir şekilde ilgilenen olursa onlar için de bu sorunu düzeltmiş olursunuz.

Fakat diyelim ki dokunulamıyor kaynak sisteme bu durumda ne yapacağız?Bu durumda sorunun sizin pipeline’lardan kaynaklanmadığını göstermek için “Tanımsız Kayıt” veya “Kaynakda Bulunamadı” gibi bir tanımlama ile bu sorunlu kayıtları göstermeniz lazım.Bunun içinde yapmanız gereken şey aslında çok basit.Fact’inizi doldururken ilgili FK’ları dolduracağınız pipeline’da BI katmanında joinleneceği dimension ile pipeline’da joinleyip varlık yokluk kontrolüne koyduktan sonra yok ise -1 var ise ilgili id’yi basabilirsiniz.Peki bu -1 neyi ifade edecek?Bu -1,dimension tablosuna öncesinde -1 idli,”Tanımsız Kayıt” açıklamalı eklediğiniz satır ile eşleşecek ve BI tarafında kullanıcılar Tanımsız Kayıt görecekler.Böylelikle sorunlu kayıtları hemen fark edebilecekler.Kaynak sistemde kayıtları düzeltebiliyorsanız dahi böyle bir mekanizma kurmanız hatalı kayıtları tespitini çok kolaylaştıracaktır.Tek sorun pipeline süresi uzayacaktır bence varsın uzasın veri bütünlüğü çok önemli bir konu çünkü.

Bir diğer önemli konu asla ama asla veri filtrelemeyin!.Bu çok canınızı sıkacak bir konudur.Örneğin bir log tablonuz var sizden xxxxx tipindeki işlemler istendi sadece,sizde ODS’e bu şekilde aldınız haliyle fact tablonuzada direkt ODS’den çıktınız.Fakat sonrasında yyyyy tipindeki işlemlerde istendi.Bu durumda ODS’e bunu aldınız fakat fact’iniz bu sefer başka tipdeki işlemleri göstermeye başladı.O yüzden muhakkak ODS’e full almaya çalışın veya bunu kullanan factlerinizde yarını düşünerek uygun filtrenizi verin.Bir diğer konu ODS full aldınız ama fact’e sadece belirli bir kısmı aldınız.Bu durumda diğerlerini istediğinizde tekrar çalışmanız gerekir.Peki son kullanıcı sadece durumu xxx olanları istiyor bu durumda ne yapmalıyız?Siz full çıkın kullanıcı için filtre koyun filtrelisiniz kendisi.Bunu yapamayız C level için yaptık,bu durumda yine fact’i full çıkın rapor veya dashboardda filtreleyin ama factiniz hala full olsun.

DWH’da en önemli konulardan bir tanesi granularity.Yani en dip seviyede veri vermeye çalışmalıyız.Çünkü yine aynı sebepten kesinlikle yarın detay seviyesi sorulacak ve size ek çalışma masrafı çıkacak.O yüzden en dip seviyede verin zaten BI toolunda aggregate olacak.Performans sorunu yaşarsanız en dip seviyedeki fact’inizden aggregate fact tablo çıkabilirsiniz.

 

Peki veri temizliği konularında ne yapabiliriz?

Burada o kadar fazla case karşınıza çıkacak ki herbiri birbirinden farklı olabilir.Fakat şunu söyleyebiliriz burada yine kaynakda işi çözdürmeye özen gösterin bu sizin için olduğu kadar onlar içinde çok değerli olacaktır.

Örnek verelim hemen.Mesela diyelim ki CRM uygulamanızın bir tablosu var müşteriye yapılan işlemleri tutuyor.Sizden işlem tipi bazında her gün kaç işlem yapıldı kaç farklı müşteriye yapıldı gibi bir rapor isteniyor.Fakat tablonuzda işlem tipi yok 😊İşlem tipi açıklama sütununda belirli bir prefix ile free text tutulmuş.Aşağıdaki örneklerde olduğu gibi.

Limit Değişikliği:Müşteri istedi değiştirdik.

İlan Hakkı Değişikliği:Müşteri ek istedi verdik.

Böyle bir tabloda belirli bir prefix ve sonrası free text verilmiş ya da daha kötüsü hiç prefix yok direkt açıklama içinde kuralsız yazılmış.Bu durumda açıklama alanını parçalayıp kendiniz bir işlem tipi alanı yaratabilirsiniz ama yarın kurala uymayan bir tip gelebilir ve sizin kuralınız işlemeyebilir.Bu yüzden kesinlikle kaynak sistemde böyle bir alan açılmasını istemelisiniz.

Free text bir alandan içinde xxxx veya yyyy gibi değerler aratacak şeklinde bir kural işleteceksiniz, öncesinde muhakkak lower veya upper fonksiyonları ile tüm yazıyı düzenleyin case sensitiveden gol yiyebilirsiniz.

 Diyelimki bu açıklama alanından işlemtipini ayırabildiniz bu bir fact tablo olduğu için kesinlikle text bir alan bırakmamalısınız.Bu durumda öncesinde bir lookup tablo yaratmanız gerekir.Lookup tablolar kaynakdan gelmeyen sizin oluşturduğunuz id ve açıklama barındıran tablolardır.Hangi işlem tipine hangi id’nin geleceği belli olduktan sonra artık fact tablonuzdaki işlemtipi_key sütununa bu lookup tablosundaki id’i basmanız gerekir.

Bunu yapmamızın çok önemli iki sebebi var.Birincisi text alanlar fact üzerinde çok ciddi yer kaplıyorlar.İkincisi İşlemtipini lookupdan almazsanız fact üzerinden almak zorunda kalırsınız bu da sadece işlemi olan işlemtiplerini getirmenizi sağlar.Fakat son kullanıcı tüm işlem tiplerini görmek ister yani işlemi yok ise xxx işlemtipinden 0 adet işlem var görmek ister.Ayrıca BI toolunuzdaki filtrelenizdede factten veri getirdiğinizde çok yavaş açılacaktır.

Örnekler çoğaltılabilir.Bir diğer konu artık JSON’ların hayatımızda çok fazla yer alması.JSON’lardan verileri çıkarmak istediğinizde ona bir text gibi davranıp text fonksiyonları ile örneğin SUBSTRING,LEFT vb kullanıp kesinlikle istediğiniz değeri dışarı almayın.JSON sütunlar tercih edilmesinin sebebi yeni bir sütunun hemen eklenebilmesidir.2 hafta doğru çalışan kodunuz bir günde çalışamaz olabilir çünkü siz statik bir kod yazmış oldunuz.JSON fonksiyonlar kullanarak key value ilişkisinden scalar değeri döndürün muhakkak.Ayrıca kesinlikle tüm sütunları çıkarmaya çalışmayın lazım oldukça alırsınız çoğunu hiç bir zaman kullanmayacaksanız.JSON için yazdığım bir yazım vardı blog ve linkedin profilimden görebilirsiniz.

Yine bir örnek daha verelim, telefon veya tc no sütunu free text girilmiş.Bu sütunlar belirli bir pattern’i takip ettiği için düzenlememiz hala bir nebze kolay.Öncelikle tüm verilerimizi aynı formatta vermemiz çok önemli o yüzden şu şekil bir telefon formatı vermemlisiniz son kullanıcıya.

+905555555555

05555555555

5555555555

0555 555 55 55

Çünkü son kullanıcı böyle bir bilgi alacaksa muhakkak sonrasında bir işlem yapacaktır ve bu durumda onun otomatize etmeye çalıştığı yapıya zarar verecektir.Bu yüzden iş birimleri ile el sıkıştığınız bir formata karar verip tüm gelen datalar için bu formata uyacak şekilde düzenlemeniz gerekir.Elbette söylemeye gerek yok kaynakta düzenletebilirseniz ne mutlu 😊

 

Açıkçası ne kadar örnek versek az kalacak veri temizliği özelinde, o yüzden veriye bunun kaynakda mı düzenlemesi lazım, benim tarafımda mı diye baktıktan sonra bu işlemleri yapmanız en doğrusu olacaktır.

 

Umarım faydalı olmuştur,sonraki yazılarda görüşmek üzere😊

 

 

 

 

Azure Synapse ve SQL Pools

 

Azure Synapse ve SQL Pools

Azure Synapse Analytics,Microsoftun big data ve klasik DWH yapısını bir araya getirdiği bir servisi.Bunun içerisinde Sparkda var,SQL’de var,ADF’de var.Bir lake üzerine kurulu bir yapı olduğundan diğer iş birimlerininde bağlanıp datalar üzerinde işlem yapması veya machine learning üzerine bir servisin buradaki datalara erişimi son derece kolay.

 

 

 

Ölçeklenebilir olması bu kadar farklı servisin ayakta olması ve senkronize bir şekilde bir biri ile çalışmasıyla sizin uğraşmamanız bu servisi seçmeniz için yeterli gerçekten.

Çok büyük datalarda Spark dönüşümleri ve sourcedan data aktarımları için ADF gerçekten iyi.DB tarafında ise nodelar üzerinde bir mimari ve columnstore bir DB olması performansı çok arttırıyor.Elbette bunun bir dezavantajı da var klasik columnstore DB’lerde olduğu gibi update-delete komutları uzun sürebiliyor ama ben kendim çok ciddi sorunlar yaşamadığımı söylemeliyim.Ayrıca tablo seçimleri ve data skew konuları komplexleri arttıran konular klasik DWH’lara göre.Artık detaya inebiliriz sanırım.

 

Azure Synapse Analytics içerisinde iki tip SQL pool seçeneği bulunmaktadır.Biz her ne kadar Dedicated üzerine konuşacak olsakda serverlessda yerine göre kullanılabiliyor.

 

Aşağıdaki resim üzerine konuşacağız ama ilk bilmeniz gereken Dedicated SQL pool 7/24 sizin için ayrılmış başkasının kullanamadığı bir kaynak.Yani sanki clouddda bir makine satın almışsınız gibi düşünebilirsiniz.

Serverless ise siz ne zaman sorgu gönderirseniz o zaman ihtiyacınız kadar olan kaynağı genel havuzdan çekip sizin işinizi bitirip sonra başkasının işlerini yapmaya devam eden kaynaklar olarak düşünebilirsiniz.

Resmi incelemeye başlayalım çünkü bize genel mimariyi anlatacak aslında.Gördüğümüz ilk şey her iki mimaride de Node’lar üzerinde bir yapı kurulduğu.Yani biz sorguyu gönderdiğimizde Control Node uygun Compute Node’ları seçip işi dağıtıyor.

Serverless üzerinde konuşup hemen asıl konumuza dönelim şimdi.Control Node sizin sorgu isteğinizi aldıktan sonra sorgunuzun kullanacağı kaynak miktarını ölçüp ona göre node sayısını ayarlar ve sorgunuzu döndürür.Bunu genelde dedicated SQL pool seçimi yapmamış datayı Lake veya Storage üzerinde file formatta tutan firmalar kullanabiliyor.File’ı sanki tabloymuş gibi from kısmına koyup sonra SQL yazdığınızı düşünün😊Bunun içinde OPENROWSET fonksiyonu ile ve değişmekle beraber genelde parquet formatındaki dosyalar üzerinde işlem yaparlar.

Bunun dezavantajı şudur çok büyük kaynak isteyen sorgu gönderirseniz çok büyük bir maliyet ile karşılaşabilirsiniz.Burada kullandıkça öde mantığı olduğundan mümkün olduğunca az sorgu göndermek istersiniz.Hatta power bi veya başka bir bi toolu bağlanacaksa import mode yapmalısınızki her seferinde gelip sorguyu çalıştırmasın maliyet çıkarmasın.

Şunu unutmayın Serverless SQL Pool her Synapse içinde hazır kurulu gelir,sizin kurulum yapmanıza gerek yoktur.Ayrıca kullanmadığınız sürece hiç bir maliyet çıkarmaz açıp kapamaya çalışmayın diğer servisler gibi.

Ayrıca serverless üzerinde hiç bir data saklayamacağınızı unutmayın sadece metada saklayabilirsiniz.Yani tablo veya materilazed view yaratamazsınız ama external table veya view yaratabilirsiniz çünkü bunlar datayı lakede tutmaya devam ederken metadayı serverless üzerinde tutabilir.

Serverless üzerine çok bile konuştuk bence artık Dedicated SQL Pool zamanı😊

 

 

Dedicated SQL Pool kurulumu yapacağınız zaman size bunun kaç node olması gerektiği sorulacaktır.Bunu seçmeden önce şunu bilmemiz lazım.MPP mimarisinde Control Node ve Compute Node’lar var.Control Node tek bir tane ve bu sorguları uygun Compute Node’lara dağıtıp döndürmekle ilgileniyor kendi üzerinde hiç bir işlem gerçekleşmiyor.Compute Node ise işin olduğu Node’lar aslında sorgularınız bunlar üzerinde hesaplanıp sonuç dönüyor.Haliyle ne kadar çok Compute Node olursa o kadar fazla paralel çalışıp yük dağıtılabilir oluyor.Buda performansı arttıryor.Fakat fazla Compute Node için daha yüksek servis seviyesi seçiyorsunuz bu da maliyet demek oluyor.

DW100C ile DW30000C arasında servis seviyesi seçebiliyorsunuz bu seçimler arttıkça Node sayısı ve Ram artıyor.Burada bilmemiz gereken bir kavram daha ortaya çıkıyor o da Distribution.

Synapse siz hangi servis seviyesinde çalışırsanız çalışın dataları 60 farklı distribution üzerinde tutuyor aynı zamanda sorgularıda 60 farklı distribution üzerinde çalıştırıyor.60 farklı parallelin sonucu birleştirilip döndürülüyor.Haliyle sorgu süresi en uzun distribution’ın çalışma süresi+birleştirme süresi kadar oluyor.Bu da data skew konusu buna değineceğiz.

Servis leveliniz arttıkça Compute Node 1’den 2’e,3’e max 60’a kadar yükselecektir.Örneğin 2 compute node için her bir node üzerinde 30 distribution olacaktır.Çünkü toplamda her zaman 60 distrbution var.60 Node seçtiğinizde ise her bir node’a 1 distribution düşecek ve hızı tahmin edebilirsiniz ve maliyeti de elbette 😊

Daha iyi anlamak isterseniz Node’ları fiziksel bilgisayarlar distrbutionları mantıksal bölmeler gibi düşünebilirsiniz.Dolayısıyla örneğin siz DWH100C de 1 bilgisayarda 60 işlemi aynı anda yapıp birleştirip döndürmeye çalışırken DWH30000C’de 1 bilgisayar 1 işlem yapar.Ayrıca dönüşüm işlemleri ciddi RAM harcadığından aynı anda çok fazla sorgu talebi gelirse hak verirsiniz sıraya almak zorunda kalacaktır.Örneğin DW100C için u sayı 4 sorgu ve en az %25 RAM boşta olmalı iken DW1000C için 32 sorgu %3 RAM seviyelerine düşebiliyor.

DWH200C’den DWH300C’ye geçişde bile performansımız ciddi artmıştı.Maliyet şirketinizin gücüne göre değişecektir elbette.Hesaplama aracından hesaplayabilrisiniz.

Burada şunu söylemekte lazım.Bazı firmalar SQL Pool kullanılmayan saatlerde bunu kapatıp açan mekanizmalar kuruyor çünkü Sql pool full performans kullanının veya kullanmayın aynı parayı kesiyor.

 

 

 

 Konuyu çok uzattım sanırım hadi SQL Pool tablo yapılarına girelim😊

Node ve Distribution’dan bahsettik.Buna göre tablolarımızın tiplerini seçmemiz gerekiyor.

·       Round Robin

·       Hash

·       Replicated

Round Robin

Genelde ODS tabloları için kullanılan bir tiptir.Çünkü özelliği olabildiğince hızlı bir şekilde datanın tabloya yazılmasıdır.Mümkün olabildiğince eşit bir şekilde tüm distributionlara datayı dağıtır.Ama datalar hızlı yüklenirken rastgele dağıldığından join işlemleri veya select işlemleri bu tablolar üzerinde çok daha yavaş olur bunlar asla nihai tablo gibi kullanılmamalıdır.ODS ve staging için sadece unutmayın.

Replicated

Tüm distributionlarda 1-1 aynı datayı yaratır tabloyu bölmez.Bu yüzden başka distributiondan veri getirmekle vakit kaybetmez kendi üzerindeki ile işini görür o yüzden çok hızlıdır.Ama aynı data 60 kere yazıldığından sadece küçük tablolar için kullanılmaldıır.Bunlar max 2-3 milyonluk dimension tablolar olabilir 100milyonluk dimensionlar için bu methodu kullanmayın!.

 

 

 

 

Hash

Büyük tablolar için en iyi saklama methoduur.Fact ve büyük dimensionlar bu tipte bir tabloda saklanır her zaman.Çünkü select ve join işlemleri çok hızlıdır.Her bir satır bir distributionda saklanır bu methodda ama burada şöyle bir soru ortaya çıkıyor hangisini nerede olacak nasıl biliyor?Bir Hash  fonksyion aracılığı ile bunu yapıyor.Örneğin siz FirmaID verdiniz buna göre hashle dediniz FirmaId 1 hep 1 nolu distrubitona gidiyor FirmaID 55 40 nolu distrbıutiona gidiyor.Fakat burada şöyle bir sorun var sizin datanızın %75’i firmaId 1 diyelim.Bu durumda %75’i 1 nolu distirbutiona gidiyor ve diğer distributionlar boş yatıyor.İşte buda data skew dediğimiz kavramı ortaya çıkarıyor.Yani Distrbutionlar arası data farkı.Bu tip durumlarda ekstra sütunlar vererek ya da daha normal dağılım gösteren tek bir sütun seçerek hash değerine ulaşmanız lazım.Açıkçası burada biraz deneme yanılma yapacaksınız en iyi performansı bulmak için.Şuda var ki mümkün olduğunca joinlerde kullacağınız veya aggregationda group by da gelecek sütunlar üzerinden hash değeri oluşturmak isteyeceksiniz ki performans artılarınız olsun.Genelde primarykey gibi sütunları seçmemeye dikkat edin hepsi unique olması değil tablonun ilgili sütun bazında 60’a en yakın eşit dağılımını istiyoruz çünkü.

Data skew değerine ulaşmak için var olan hazır sorgular inceleyebilirsiniz buraya yazıp yer kaplatmayayım.Aynı zamanda bir sorgunun hangi distributionda ne kadar veri işlediğinide görebilirsiniz.

 

Synapse’de işlem yaparken en önemli şeylerden biri data_skew olayı buna çok özen gösterin ve ne yaparsanız yapın DWH100C ile çokda efektif bir DWH yaratamazsınız biraz daha yüksek bir servis seçebilirsiniz