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