ETL HIZLANDIRMA İPUÇLARI
·
Her zaman DB’de minimum seviyede log tutmaya
çalışın.Çünkü her işlem birde log olarak kaydedildiğinden inanılmaz vakit
kaybedersiniz.
·
Oracle DB’ler için APPEND hint’i eklemeyi
unutmayın,SQL Server için Bulk methodu tercih edin.
·
Incremental update ile yükleme yapmaya çalışın
her zaman,truncate-insert’den olabildiğince uzak durun.
·
Bir aktarımın çalışma hızı network ile doğrudan
orantılıdır.Gereksiz sütunlar row başına byte’ı arttıracağından sadece
gereklileri alın.Özellikle açıklama,json veya clob sütunlar içeren bir satırı
aktarmak başka bir tablodaki hepsi integer olan 1000 satır 10 sütunluk bir
tablodan daha yavaş olabilir!!
·
Network konusuna bir diğer bakış açısı ELT
yaklaşımıdır.ETL methodundan veri iki kez serverlar arası aktarılırken ELT’de
tek seferde aktarılır x2 süre kazancı demektir en kötü ihtimalle.Çünkü veri
aktarımında en çok vakit veri transferinde yani networkde geçer.
·
Verileri
başka bir veri kaynağına yazma CPU gerektirir dolayısıyla netwrok yanında
CPU’nuzunda yüksek olması gerekir.Yazma yaptığınızda CPU değerlerinizin ne
kadar yükseldiğini gözlemleyebilirsiniz.
·
ODI ile SQL Server’a veri aktarıyorsunuz
muhakkak BULK knowledge module’unu seçin.
·
SSIS ile SQL Server’a veri aktarıyorsanız fast
load methodunu muhakkak seçin.
·
ADF ile çalışıyorsanız Lake’e parquet formatta
atıp lake’den okumanız çok hızlı olacaktır.
·
Index veya constraint barındıran tablolara veri
aktarımı yapmayın mümkünse index veya constraintsiz şekilde aynı metadaya sahip
bir tablo yaratın oraya yükleyin ve o tablodan ana tablonuza bulk yükleyin.
·
Delete-Insert Incrementallarda daha kötü
performansa sebep olabilir özellikle Columnar DB’lerde Synapse-Bigquery gibi
buralarda bunlardan kaçınmaya dikkat edin merge into veya exchange partition
gibi methodlar tercih edin.
·
ODS katmanlarındaki tüm tablolarını muhakkak
parallel çalıştırın çünkü birbirlerini beklemeleri gerekmez vakit
kaybetmeyin.DM katmanlarında paralell çalıştırabilecekleriniz varsa bile
yapmanızı tavsiye etmem çünkü ilerleyen zamanlarda birbirlerine bağımlı stepler
yaratılabilir ve karmaşıklık olabilir.
·
Verileri muhakkak source tabloda filtreleyin
targeta alıp filtrelemeniz size süre kazandırmaz.
·
Dönüşümleri source’da değil target’ınızda
yapın.Genellikle DWH makineniz source makinelerden güçlü olurlar.
·
Dönüşümler RAM odaklıdır RAM’inizin yüksek
olmasına dikkat edin.
·
Source tablonuzda CDC yaptığınız sütunlar
üzerinde muhakkak index olsun.
·
DM veya STG katmanlarınızdaki Mappinglerinizde
muhakkak SQL hızlandırma adımlarınızı uygulamanız gerekir.Çünkü bu kısım DWH
üzerindedir genelde ve bir çok dönüşüm ve join barındırır network işin içinde
değildir.Burada hızı SQL hızlandırmalarıyla çözebilirsiniz.(Bunu başka bir
yazımızda değinelim 😊)
·
Özellikle Fact tablolarınızda partition koymayı
unutmayın.
·
Tüm ETL sürenizi arttıran stepleri tespit edin
bunların çoğu genelde SQL kaynaklı problemlerdir ve çoğu durumda subquery’leri
temporary tabloları basıp işimiz bitince bunları drop etmek çok ciddi süre
kazandırır!!!
·
Implict conversion dediğimiz sizin yapmadığınız
ama data tiplerinden kaynaklı database’in kendisinin uyguladığı dönüşümlerden
kaçıp doğru veri tiplerini seçmeye dikkat edin.
Hüseyin Albayrak
