Impala Bölüm 13: Impalad Query Planner

Cloudera Impala
Okunma süresi: 3 dakika

Impala mimarisini anlatırken Query Planner’dan bahsetmiştik; ama oldukça sığ bir şekilde bahsetmiştik. Bu kısmı anlamak, sorgularınızın nasıl işlediğini ve dolayısıyla Impala’nın çalışma mantığını anlamak açısından önemli. O yüzden bu bölümde biraz daha detaylarına gireceğiz.

Query Planner, sorgu ulaştığında öncelikle mantıksal bir plan oluşturur. Oluşturulan bu planın execute edilebilmesi için en iyi duruma getirir ve son olarak farklı node’lar üzerinde çalışabilmesi için fragment’lere bölerek Query Coordinator’a iletir. Şimdi bunları biraz daha ayrıntılı inceleyelim.

Aşama 1: Mantıksal Plan Oluşturulması

Query Planner, öncelikle sorgunun parse (ayrıştırma) işlemini yaparak mantıksal bir plan oluşturmaya başlar. Mantıksal plan dediğimiz şey, aslında bir sorgunun yürütülmesindeki ardışık adımlardır. Aşağıdaki resimde görüleceği gibi bir ağaç şeklinde temsil edilir.

Bir sorgulama işleminde yukarıdaki gibi bir planda adımlar en alttan, üste doğru ilerler. Node’lar verileri işler ve ağacın tepesine doğru tırmanma gerçekleşir. Her bir node, plan operator olarak bilinen tek bir işlemi yürütmektedir. Konuyla ilgili operatörler:

Scan: Ağacın yaprakları scan node’larını içerir. Bu node’lar tabloyu tarar ve WHERE ifadesindeki filtreleri uygularlar. Her farklı veri erişimi için bir scan node vardır: CSV, Parquet vb.

Aggregate: Bu node’lar GROUP BY ve SUM gibi aggregate fonksiyonlarını temsil eder.

Top-N: Bu node sonuçları sıralar ve yalnızca ilk N sonuçlarını tutar.

Join: Left tablodaki her bir satır için right tabloda eşleşen satırları bulur. Join operator’ünü uygulamak için çeşitli algoritmalar kullanılır: Nested loop, sort-merge ve hash-join en çok bilinelerdir.

Query Planner, mantıksal planı oluşturduktan sonra ikinci aşama olarak sorguyu optimize (en iyi duruma getirmek) etmeye çalışır.

Aşama 2: Query Plan’ın Optimizasyonu

Bizler bir sorgu yazıyor olsak ta, bu sorgunun planını, yani nasıl gerçekleştirileceğine dair bir bildirimde bulunma şansımız olmuyor. Bir gün oldukça optimal bir sorgu ile çalışırken, başka bir gün sorgu sonuçları kötüleşebiliyor. Bunun nedeni değişen veriler, kaynak yeterliliği, istastiklerin güncelliği vb. birçok faktörden etkileniyor.

Diğer bir kısıt ise zaman problemidir. Size verileri hızlıca iletebilmek için plana çok kısa bir süre içerisinde karar vermek zorundadır, bu sebeple olası her senaryoyu deneme şansı yoktur. Kısıtlı bir sürede üretebildiği planlar içerisinden en optimal bulduğunu seçmek zorundadır.

Query optimizer’lar, sorgu sonuçlarını değiştirmeden plan ağacını değiştirerek olası süreleri hesaplarlar. Bizler için en ideal durum, sorgunun en kısa sürdüğü durumdur. Optimizer bunu başarmak için olabildiğince az veriyi işleyerek sonuca ulaşmaya çalışır ve bunun için iki yöntemden faydalanır: Early elimination ve join optimization.

Early Elimination

Mantıksal ağacın altından mümkün olduğunca çok satırın kaldırılması işlemidir. Bu işlem, filtreleri (WHERE ifadesi) ağacın altına iterek gerçekleştirilir. Scan node’ları ne kadar çok satırı ortadan kaldırabilirse, o kadar az satır ağaçta daha yukarı tırmanacaktır.

Join Optimization

Early elimination tamamlandıktan sonra sıra join optimization işlemine gelir. Cebirsel yasalar bize inner join’lerin değiştirilebilir ve ilişkilendirilebilir olduğunu söyler, yani tabloların sırasının sonuç üzerinde bir etkisi yoktur. Ancak, işlem süresi üzerinde büyük bir etkisi vardır.

Birinci tablonun her satırı, ikinci tablonun her satırıyla eşleştirir. Çoğu durumda eşleştirme, bir tabloyu tamamen bellekte tutarak ve ikinci tabloyu satır satır tarayarak yapılır. Tarama sırasında, taranan her satır in-memory tablonun her satırıyla eşleştirilir. En küçük tabloyu bellekte tutmak ve en büyük tabloyu taramak mantıklı olandır. Impala tarafından uygulanan bir left-deep tree stratejisi, sağ taraftaki tabloyu bellekte tutar ve sol taraftaki tabloyu tarar. Bu yüzden soldaki tablomuzu büyük, sağdakini ise küçük olanı koyarak sorgularımızı yazmalıyız.

Tabii hash-join algoritmasını tercih etmesi durumunda senaryo farklılaşır. Bu algoritma, sağ taraftaki tablonun tüm satırlarından bir hash tablo oluşturmakla başlar. Hash fonksiyonu, join sütunlarını hash değeri olarak kullanır. Hash tablo tamamlandığında, sol taraftaki tablo taranır. Bu tablodaki her satır, join sütunlarında hash edilir ve her bir hash değeri, hash tablosundaki ilgili satırları işaret eder.

Göreceğiniz gibi, algoritmanın uygulanması nispeten basittir, ancak hash tablonun belleğe sığabilecek boyutta olmasını gerektirir. Hash-join algoritmasının daha büyük bir sınırlaması da yalnızca equijoin tahminlerini desteklemesidir. Bir eşitlik, birleştirme sütunları arasındaki eşitlik testidir ve bu kısıtlama, hash değerlerinin yalnızca eşitlik üzerinde karşılaştırılabilir olmasından kaynaklanmaktadır.

Join optimizasyonu için en kritik durum istatistiklerin güncel olmasıdır. Eğer istatistikler güncel değilse Query Optimizer sol ve sağ tabloları doğru şekilde belirleyemeyecektir, çünkü maliyetlerini gerçekçi olarak bilemeyecektir. Bu durumda da daha önce bahsettiğim join hint’lerini kullanmak gerekir. Okumadıysanız Join Optimizasyonu konusunu okumanızı tavsiye ederim.

Artık her şeyin tamamlanmasından sonra nihayetinde dağıtık şekilde işlenebilmesi için en uygun bulunan plan fragment’lere bölünmesi gerekir.

Aşama 3: Optimize Edilmiş Plan Fragment’lerini Dağıtma

Query Planner’ın son görevi, optimize edilmiş planı, plan fragment’lerine bölmektir. Aşağıdaki resimde gösterildiği gibi, her plan fragment’i cluster’daki bir veya daha fazla node’a dağıtılır.

Resmin üst tarafında, optimize edilmiş mantıksal planı görebilirsiniz. Her node’a bir fragment numarası (F#) eklenmiştir. Resmin alt tarafında, her bir fragment’in fiziksel dağılımını görüyorsunuz. Örneğin, F#1 fragment’i (weblog tablosunu tarayan) node 1 ve node 2’de konuşlandırılırken, F#4 fragment’i (country tablosunu tarayan) yalnızca node 4’te konuşlandırılır.

Fragmentation’ın amacı, veri yerelliğini (data locality) en üst düzeye çıkararak node’lar arasındaki genel veri aktarımını en aza indirmektir. Her plan operatörü kendi dağıtılmış versiyonuna dönüştürülür.

+2
+2

Veri Bilimci Yetiştirme Programı

Her yerde geçerli @datasciencearth sertifikası

Bu program ülkemizde büyük işgücü açığı bulunan Veri Bilimi konusunda çalışabilecek yeterliliklerde Veri Bilimciler yetiştirmek için kurgulanmıştır.

Ücretli ve Ücretsiz Eğitimler

Türkiye'nin en büyük veri bilimi topluluğu ile kariyerinizi inşa edin.

Gruplarımıza katılın!

Data Science Earth

Data Science Earth ekibi, üst düzey Veri Bilim çözümleri üretmek amacı ile toplanmış akademisyenler ve uzmanlardan oluşmaktadır. Öncelikli olarak veri bilincini geliştirmeyi ve küreselleşen rekabet ortamında verinin gücünün doğru kullanılmasını sağlamayı amaçlamaktadır.

Sponsor

QuestionPro 35 farklı soru seçim özelliği ile anket çalışmalarımıza güç katmaktadır.