Hadoop’ta Verilerimiz Nasıl Saklanıyor?

Hadoop’ta verilerimiz HDFS içerisinde saklanır. HDFS üzerinde ise dilediğimiz herhangi bir formatta veriyi atabiliriz. Örneğin bir video dosyasının .mp4, .avi gibi herhangi bir formata sahip olabilir, bunun için bir kısıtlaması yoktur. Kritik olan ise metin dosyalarıdır. Bunun için yine bir sınırlama yoktur, yani .txt veya .csv gibi bir formatta atabilirsiniz; fakat ileride göreceğimiz gibi Hive, Impala gibi bir engine ile sorgulama yapacaksanız sakladığınız dosya formatı oldukça önemli hale geliyor. Bu tür işlemler için HDFS içerisinde alttaki dosya formatlarını kullanabiliriz. Şimdi bu dosya formatlarını genel hatları ile ele alalım.

 

SequenceFile

Verileri anahtar / değer çiftleri olarak saklar. SequenceFiles içinde saklanan kayıtlar için üç format vardır:

 

  1. Uncompressed

Çoğunlukla, sıkıştırılmamış SequenceFile, girdi / çıktı (I/O) için daha az verimli olduklarından ve disk üzerinde sıkıştırılmış biçimdeki aynı verilerden daha fazla yer kapladığından, sıkıştırılmış alternatiflerine göre hiçbir avantaj sağlamaz.

 

  1. RecordCompressed

Bu format dosyaya eklenen her bir kayıt bazında sıkıştırma yapar.

 

  1. BlockCompressed

Bu format, her kayıt eklendiğinde sıkıştırma yapmaz, verilerin sıkıştırılacak blok boyutuna ulaşmasını bekler. Blok sıkıştırma, Uncompressed SequenceFile ile karşılaştırıldığında daha iyi sıkıştırma oranları sağlar ve genellikle SequenceFile için tercih edilen sıkıştırma seçeneğidir. Ayrıca, burada bloklanacak referansın HDFS veya dosya sistemi bloğu ile ilgisi yoktur. Blok sıkıştırmasındaki bir blok, tek bir HDFS bloğunda birlikte sıkıştırılmış bir kayıt grubunu belirtir.

 

Biçimden bağımsız olarak, her SequenceFile, kullanılan sıkıştırma kod çözücüsü, anahtar ve değer sınıfı adları, kullanıcı tanımlı meta veriler ve rastgele oluşturulmuş bir işaretleyici gibi, dosya hakkında temel meta veriler içeren ortak bir üstbilgi biçimi kullanır. Bu senkronizasyon işaretçisi, ayrıca dosyada rastgele noktaların aranmasına izin vermek için dosyanın gövdesine yazılır ve ayrılabilirliği kolaylaştırmanın anahtarıdır. Örneğin, blok sıkıştırması durumunda, bu senkronizasyon işaretleyici dosyadaki her bloktan önce yazılacaktır.

 

SequenceFile, Hadoop ekosisteminde iyi bir şekilde desteklenir, ancak ekosistem dışındaki destekleri sınırlıdır. Onlar da sadece Java’da desteklenir. SequenceFile’ın yaygın kullanımı genelde küçük dosyalara bir kapsayıcı olması içindir. Hadoop’ta çok sayıda küçük dosyayı saklamak birkaç soruna neden olabilir.

 

Bunlaran biri, NameNode için aşırı bellek kullanımıdır, çünkü HDFS’de depolanan her dosya için meta veriler bellekte tutulur. Bir başka potansiyel sorun da bu dosyalardaki verileri işlemektir, birçok küçük dosya birçok işlem görevine yol açarak işlemlerde aşırı kaynak tüketimine neden olabilir. Hadoop büyük dosyalar için optimize edildiğinden, daha küçük dosyaları bir SequenceFile içinde paketlemek, bu dosyaların depolanmasını ve işlenmesini çok daha verimli hale getirir.

 

Avro

Avro belki de dört formattan en basitidir, çünkü sütun bazlı değildir ve ilişkisel veritabanlarındaki gibi satır bazlı saklar. Avro’nun ana amacı, verileri sıkıştırmak ve bunu şema esnekliğini kaybetmeden yapabilmektir. Örneğin, Hadoop’u belge deposu olarak kullanmak ve tüm verilerinizi JSON olarak sıkıştırmak için Avro dosyalarında tutmak isteyebilirsiniz. Çalışmak istediğiniz bazı karmaşık şemalara sahip olabilirsiniz ve tümü Avro ile de çalışabilir. Avro’nun esnekliği, istediğiniz sayıda şema çalışmanıza ve hala düzgün bir sıkıştırma elde etmenize olanak sağlar.

 

Bir başka pozitif yanı ise Avro dosyaları dinamik olarak yazılmıştır. Bu, şema esnekliğine ve RPC desteğine izin verir. Bununla birlikte Avro, veri sıkıştırma için mükemmel bir formattır ve Spark’taki çoğu sıkıştırma tekniği için varsayılan olacaktır.

 

Olumlu yanlarından sonra olumsuzluklarına bakacak olursak, Avro diğerlerden daha maliyetlidir. Örneğin, bir sütun bazlı formata kıyasla mümkün olan en iyi sıkıştırmayı elde edemezsiniz. Ayrıca, tüm veri formatları, sorgular için satır bazlı geçişe ihtiyaç duyacaktır. Şema esnekliği, diskte daha fazla yer tutmasından daha önemli ise bu durum çok fazla bir sorun olmayabilir elbette.

 

Parquet

Parquet, Avro’dan farklı bir amaca sahiptir. Maksimum şema esnekliğine izin vermek yerine, sorgu hızlarını artırmak ve disk i/o’sunu azaltmak için kullanabileceğiniz şema türlerini optimize etmeye çalışır. Parquet, sütunlarda iç içe tiplere izin vererek geleneksel sütun bazlı tutmanın bazı zayıflıklarının üstesinden gelmeye çalışır. Böylece teknik olarak bir dizi olan bir sütuna ya da aslında birkaç sütun olan bir sütuna sahip olabilirsiniz.

 

Parquet, çok sayıda düşük seviye optimizasyona ve belgelerde bulabileceğiniz diskte nasıl depolandığı ile ilgili bir dizi ayrıntıya sahiptir. Parquet belki de Spark ile ilgili birçok projede göreceğiniz en yaygın dosya formatıdır ve ben de kullanma eğilimindeyim.

 

ORC (Optimized Row Columnar)

ORC, Parquet’nin sütun biçimini paylaşır ancak bazı farklılıklar vardır. Başlıca farklılıklardan biri iç içe geçen veri türlerine izin veren listeler ve haritalar gibi karmaşık türleri destekler. Sıkıştırma söz konusu olduğunda, ORC’nin verileri Parquet’den daha verimli bir şekilde sıkıştırdığı söylenir, ancak bu verilerinizin nasıl yapılandırıldığına bağlıdır.

 

Parquet’de desteklenen özelliklerin yanı sıra, ORC ayrıca ACID işlem garantilerini de destekler. ACID’den yararlanabilecek uygulamaların sayısı düşünüldüğünde çok önemlidir. ACID işlemlerinin sadece veri biçiminde eklenmesi biraz karmaşıktır.

 

Presto veya Athena kullanıyorsanız, ORC tercih edilen formattır. Presto engine’in de yapılan son değişikliklerle, ORC kullanımının birçok avantajı oluyor. Ek olarak, ORC stream verilerini işleyebilen birkaç sütun formatından biridir. ORC ayrıca client tarafında önbelleğe almayı da destekler ve bu da son derece değerli olabilir.

 

Her türlü OLAP iş yükü için ORC gerçekten çok iyidir.

 

RC File

RCFile formatı özellikle MapReduce uygulamaları için performanslı işlem yapabilmeyi desteklemek için geliştirilmiştir, ancak pratikte yalnızca Hive için depolama biçimi olarak kullanıldığı görülür. RCFile formatı hızlı veri yükleme, hızlı sorgu işleme ve yüksek verimli depolama alanı kullanımı sağlamak için geliştirilmiştir. RCFile formatı dosyaları satır bölmelerine böler, sonra her bölmede sütun odaklı depolama kullanır.

 

Her ne kadar RCFile formatı, SequenceFiles ile karşılaştırıldığında sorgu ve sıkıştırma performansı açısından avantajları olsa da, sorgu süreleri ve sıkıştırma için en uygun performansı önleyen bazı eksikliklere de sahiptir. ORC ve Parquet gibi daha yeni sütun biçimleri bu eksikliklerin çoğunu giderir ve çoğu yeni uygulama için muhtemelen RCFile kullanımının yerini alacaktır. RCFile, Hive depolama alanında kullanılan oldukça yaygın bir formattır.

 

Hangisini Kullanmalı?

Dağıtılmış hesaplama dünyasında, belirli bir platforma avantajlı testler tasarlamak çok kolaydır. Her birini sahip olduğunuz analitik iş yükü için denemenizi tavsiye ederim. Bunların her biriyle çalıştıktan sonra, bana yardımcı olacak bazı yöntemler buldum:

 

Presto veya Athena kullanıyorsanız ORC, muhtemelen sizin için en iyi formattır.

 

Spark kullanıyorsanız Parquet veya Avro, en mantıklı olanıdır.

 

Hive kullanıyorsanız veya kendi MapReduce işlerinizi yazıyorsanız, ORC muhtemelen sizin için en iyi seçenektir.

 

JSON kullanıyorsanız, yalnızca gerçek seçeneğiniz Avro’dur veya JSON’unuzu biçimlendirecek bir pipe line oluşturmak istiyorsanız, diğer biçimlerden herhangi birini kullanabilirsiniz.

 

Genel olarak, her format bir metin dosyasını veya bir csv’yi depolamak için bazı büyük optimizasyonlar sağlar, ancak doğru seçenek ne için kullanacağınıza bağlıdır.

 

Kullandığım Teknik Terimlerin Kısa Açıklaması

Pipe Line: İletim Hattı. Boru Hattı diye çevriliyor; ama bu doğru bir çeviri değil. Bizim terminolojimize göre İletim Hattı diye çevirmek daha uygundur ve ben bunu kullanmayı tercih ediyorum. Bir iş kapsamında bir veya birden çok noktadan verinin belirli bir merkeze taşınmasını sağlayan alt yapıdır. Örneğin araç sensörlerinden aldığımız bir veriyi Hadoop’a yazmak istiyor olabiliriz. Hadoop anlık ve küçük boyutlu verilerin yazılması için uygun değildir, bu sebeple sensörlerden akan verinin Spark’a iletilmesi, analiz edildikten sonra belirli bir veri boyutuna erişmesi sonucunda büyük bloklar halinde Hadoop’a yazılabilir. Uçtan uca tasarladığımız bu yapı Pipe Line olarak tanımlanmaktadır.

 

RPC: Remote Procedure Call; Uzaktan Yordam Çağrısı. Sunucular arasında iletişim ihtiyacı varsa, aradaki iletişimin sağlanmasına olanak tanıyan iletişim teknolojisidir.

 

I/O: Input/Output; Girdi/Çıktı.

 

Stream: Akan veriyi tarif etmek için kullanıyoruz. Bir sisteme sürekli veri iletimini tarif eder. Örneğin araçların sensörlerinden gelen anlık veriler.

 

Client: İstemci. Bir sunucu üzerinde çalışan sistemden talepte bulunan kullanıcı bilgisayarını temsil eder. Örneğin veritabanına bağlanmak isteyen kullanıcı.

 

OLAP: Online Analytical Processing. Çevrimiçi Analiz İşleme olarak çevirebiliriz. OLAP sistemler raporlama ve hesaplamaya dayanan analiz işlemleri için kullanılırlar. Microsoft dünyasında buna ek olarak OLAP küpleri ile 3 veya daha fazla kırılım elde edecek şekilde yapılar da tasarlamak mümkündür.

 

ACID:

A: Atomicity,

C: Consistency,

I: Isolation,

D: Durability.

Atomicity: Bir transaction sırasında bir işlemin başarısızlığı tüm işlemleri etkiler ve tümü başarısız sayılır. Örneğin banka hesabımızdan başka bir bankaya havale yaptığımızı varsayalım. Biz havale işlemi için onay verdiğimizde veritabanında hesabımızdan bir eksiltme yapılır ve karşı bankaya mesaj iletilir. Karşı banka ise aldığına dair bir onay gönderir. Eğer alamadıysa onay gelmeyeceği için hesabımızdan eksiltilen miktarın yeniden eski haline getiriliyor olması gerekir. Bu sebeple bizim bankamız kendi yaptığı işlemi tek başına başarılı sayamaz, karşı bankanın işlemini de başarılı yapması gerekir ve tüm işlemler bir bütün kabul edilir.

 

Consistency: Bir transaction, şema içerisinde tanımlanan foreign key, unique check gibi tüm kurallara uymak zorundadır, aksi halde başarısız kabul edilir.

 

Isolaiton: Commit edilmemiş bir transaction içerisindeki işlemler yalnız transaction tarafından bilinir, commit edildikten sonra işlem herkese yansır.

 

Durability: Commit edilen verinin veritabanına yazıldığından muhakkak emin olunmalıdır, commit edildikten sonra veri yok olmaz.

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.