Impala Bölüm 7: Partitioning

Cloudera Impala
Okunma süresi: 3 dakika

Hive konusunu okuduysanız da Impala’da bazı şeyler değişiyor, bu yüzden konuyu tekrarlamak istiyorum.

Partitioning performans için önemli bir etkendir. Temelde tablo verilerini partition key dediğimiz, belirli bir sütun değerine göre verileri parçalayarak saklarız. Petabyte boyutunda verileri tararken, sorgularımızda filtrelerken tüm tablo taranacağı için (full scan) veri boyutuna göre sürecin oldukça uzaması söz konusudur. Bu sebeple doğru partition key belirleyerek verileri filtrelemek istediğimizde sadece ilgili verilere ulaşmış oluruz. Bu da okuma performansımızı önemli derece arttırır. İki tip partitioning vardır: Static ve Dynamic. Şimdi bunlara bakalım.

Static Partitioning

Static partitioning ile partition’ları manuel olarak yükleriz. Bunun için de hangi veriyi hangi partition’a eklememiz gerektiğini bilmemiz gerekiyor. Bunu bir örnek üzerinden açıklayalım.

Öncelikle şubelerimiz ve günlük işlem özetlerini tuttuğumuz bir tablomuz olsun:

Görüleceği gibi branch adında bir partition key belirledik ve buna göre oluşturduk. Bir sütunu da seçebilirdik; ama burada temelde zaten sadece ilgili veriler bu partition’a yazılacağı için aynı verinin tablo içinde yer alması pek tercih edilmez.

Ayrıca partition dediğimiz şey aslında bir dizindir, table create ederken de aslında bir dizin oluşturulur ve içerisinde file’lar saklanır. Doğal olarak bir partition oluşturduğumuzda, aslında bir dizin oluşturduğumuz için kullandığımız alanın adı veya tablo içerisinde olması gibi zorunluluklarımız yoktur. Yani RDBMS’teki partition mantığı ile pek alakası yoktur.

Şimdi bu tabloya bir veri yüklerken static partition metodu kullanarak insert etmek istediğimiz şu şekilde yapmamız gerekir:

Görüleceği gibi verinin yazılacağı partition’ı SQL ifadesinde belirtmiş olduk. Temel mantığı olayların sizin planlamanıza göre gelişmesi.

Dynamic Partitioning

Dynamic partitioning ile anlayacağınız üzere gelen veriye göre kendi otomatik olarak partition işlemini gerçekleştirir, böylece sizin manuel müdahaleniz gerekmez.

Yalnız anlayacağınız üzere dynamic partition yapısı çok fazla sayıda partition üretme potansiyeli olduğu için sorgulamanın yapılacağı, parçalanacak datanın uygun parçalara ayrılmasını sağlayacak alanın seçilmesi esastır. Bu konuda dikkatli olmak gerekiyor.

Yine aynı tabloyu kullanarak dynamic partition insert nasıl yapalım.

Gördüğünüz gibi partition yapılacak bilgiyi açıkça vermedim, peki neye göre partition yapıyor? Select ifademizde seçilen son sütun yani yukarıdaki col3 sütunundaki bilgiye göre otomatik olarak partition yapıyor olacak. Yani dikkat etmeniz gereken partition yapılacak sütunu sonuncu olarak vermeniz gerekiyor.

Hangi Partition Modelini Seçmeliyiz?

Static partition’dan bahsederken, önceden veri bilgisini gerektirdiğinden söz etmiştik, bu yüzden static modelde ilerlemek için verilerin önceden bilindiği yerlerde kullanabiliriz.

Yine de static partition’ın çok fazla manuel çaba gerektirdiğini gördüğümüz için; her partition’ı yüklemek için ayrı sorgu yazmamız gerekir, bu nedenle de verilerin çok fazla benzersiz olmadığı ve daha az sayıda partition oluşmasını sağlaması açısından static partition kullanılması önerilir.

Bunun aksine, dynamic partition, veriler bizim tarafımızdan bilinmediğinde veya partition sütununda daha benzersiz değerlere sahip olduğunda uygundur, örneğin tarih bazında partition yapmak gibi.

Bununla birlikte, static partition’ın dynamic’ten daha hızlı olduğunu unutmayın, Impala’ya her şeyi önceden vermiş oluruz, böylece daha az karşılaştırma olur.

Ancak dynamic olarak, Impala tek başına tüm karşılaştırmaları yapmak ve ardından verileri uygun partition’a yüklemek zorundadır, bu da doğal olarak daha yavaş çalışacaktır. En uygun seçenek verilerinize göre partition türünü sizi seçmenizdir.

Alter Partition

Production ortamında sıklıkla partition ekleme ve silme işlemlerini gerçekleştiririz. O yüzden bu işlemleri bilmek önemlidir.

Bir tablonun partitionlarını görmek için:

Tablodan bir partition’ı silmek için:

Eğer bir partition’ı silinmeye karşı korumalı hale getirmek istersek:

Partition’ı tekrar silinebilir hale getirmek istiyorsak:

Bir partition’ı geçici bir süre kapatmak istiyor olabilirsiniz, bazen silmek yerine uygun bir çözüm olabilir. Bunun için:

Offline ettiğimiz partition’ı tekrar kullanıma açmak için:

Bu tür bir partition silme operasyonunda tablomuz internal ise (biz öyle oluşturduk) drop komutu ile partition ile birlikte veriler de silindi. Eğer external bir tablo olsaydı yalnızca metadata’yı silmiş olacaktık, verileri silmek için HDFS’e gidip manuel olarak bizim silmemiz gerekirdi.

Tabloya bir partition eklemek için:

Bir tablo için HDFS içerisinde mkdir ile dizin create ettiğinizde, bunun tablo için partition olarak kullanılmasını istiyorsak iki yolumuz vardır. Örnekle açıklayayım. Öncelikle WŞubesi diye bir partition dizini oluşturalım:

Şimdi Wşubesi dizinini partition olarak elemek için ilk yöntem manuel olarak partition bilgisini eklemektir. Böylece Hive Metastore ilgili dizin partition olarak kaydedilir:

İkinci yöntem ise recover komutunu kullanmaktır:

Bu komuttan sonra ilgili dizin otomatik olarak partition diye eklenir.

0
0

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.