Büyük veride dosya formatları: kısa bir eğitim programı

Remarin'den Hava Durumu Tanrısı

Ekip Mail.ru Bulut Çözümleri sunar makale çevirisi Clairvoyant'tan mühendis Rahul Bhatia, büyük veride hangi dosya formatlarının bulunduğunu, Hadoop formatlarının en yaygın özelliklerinin neler olduğunu ve hangi formatın kullanılmasının daha iyi olduğunu anlatıyor.

Neden farklı dosya formatlarına ihtiyaç var?

MapReduce ve Spark gibi HDFS özellikli uygulamalar için büyük bir performans darboğazı, verileri aramak, okumak ve yazmak için gereken süredir. Bu sorunlar, sabit bir şema yerine gelişen bir şemaya sahip olmamız veya bazı depolama kısıtlamaları olması durumunda, büyük veri kümelerini yönetmenin zorluğuyla daha da artar.

Büyük verilerin işlenmesi, depolama alt sistemi üzerindeki yükü artırır - Hadoop, hata toleransını sağlamak için verileri yedekli olarak depolar. Disklere ek olarak işlemci, ağ, giriş/çıkış sistemi vb. de yüklenir. Veri hacmi arttıkça, işlenmesi ve saklanması maliyeti de artar.

Çeşitli dosya formatları Hadoop'un tam olarak bu sorunları çözmek için icat edildi. Uygun dosya biçimini seçmek bazı önemli avantajlar sağlayabilir:

1. Daha hızlı okuma süresi.
2. Daha hızlı kayıt süresi.
3. Paylaşılan dosyalar.
4. Şema gelişimi desteği.
5. Genişletilmiş sıkıştırma desteği.

Bazı dosya formatları genel kullanıma yöneliktir, diğerleri daha özel kullanımlara yöneliktir ve bazıları da belirli veri özelliklerini karşılayacak şekilde tasarlanmıştır. Yani seçim gerçekten oldukça büyük.

Avro dosya formatı

için veri serileştirme Avro yaygın olarak kullanılmaktadır - dize tabanlıyani Hadoop'ta bir dize veri depolama formatıdır. Şemayı JSON formatında saklayarak herhangi bir program tarafından okunmasını ve yorumlanmasını kolaylaştırır. Verilerin kendisi ikili formattadır, kompakt ve etkilidir.

Avro'nun serileştirme sistemi dil açısından tarafsızdır. Dosyalar şu anda C, C++, C#, Java, Python ve Ruby olmak üzere çeşitli dillerde işlenebilir.

Avro'nun önemli bir özelliği, zamanla değişen, yani gelişen veri şemalarına yönelik güçlü desteğidir. Avro, alanların silinmesi, eklenmesi veya değiştirilmesi gibi şema değişikliklerini anlar.

Avro çeşitli veri yapılarını destekler. Örneğin, bir dizi, numaralandırılmış bir tür ve bir alt kayıt içeren bir kayıt oluşturabilirsiniz.

Bu format, bir veri gölünün giriş (geçiş) bölgesine yazmak için idealdir (veri gölüveya veri gölü - doğrudan veri kaynaklarına ek olarak çeşitli veri türlerinin depolanmasına yönelik bir örnek koleksiyonu).

Dolayısıyla bu biçim, aşağıdaki nedenlerden dolayı veri gölünün giriş bölgesine yazmak için en uygunudur:

1. Bu bölgeden gelen veriler genellikle aşağı akış sistemleri tarafından daha ileri işlemler için bütünüyle okunur ve bu durumda satır tabanlı format daha verimli olur.
2. Aşağı akış sistemleri, şema tablolarını dosyalardan kolayca alabilir; şemaları harici meta depolamada ayrı olarak saklamaya gerek yoktur.
3. Orijinal şemada yapılan herhangi bir değişiklik kolaylıkla işlenir (şema gelişimi).

Parke Dosya Formatı

Parke, Hadoop için depolanan açık kaynaklı bir dosya formatıdır. düz sütunlu formatta iç içe geçmiş veri yapıları.

Geleneksel sıra yaklaşımıyla karşılaştırıldığında Parke, depolama ve performans açısından daha verimlidir.

Bu, özellikle geniş (çok sütunlu) bir tablodan belirli sütunları okuyan sorgular için kullanışlıdır. Dosya formatı sayesinde yalnızca gerekli sütunlar okunur, böylece G/Ç minimumda tutulur.

Küçük bir ara ve açıklama: Hadoop'ta Parquet dosya formatını daha iyi anlamak için sütun tabanlı (yani sütunlu) formatın ne olduğuna bakalım. Bu format, her sütun için benzer değerleri bir arada saklar.

Örneğinkayıt Kimlik, Ad ve Departman alanlarını içerir. Bu durumda tüm Kimlik sütunu değerleri, Ad sütunu değerleri vb. gibi birlikte depolanacaktır. Tablo şöyle görünecek:

ID
Name
bölüm

1
emp1
d1

2
emp2
d2

3
emp3
d3

Dize formatında veriler aşağıdaki gibi kaydedilecektir:

1
emp1
d1
2
emp2
d2
3
emp3
d3

Sütunlu dosya formatında aynı veriler şu şekilde kaydedilir:

1
2
3
emp1
emp2
emp3
d1
d2
d3

Bir tablodan birden çok sütunu sorgulamanız gerektiğinde sütunlu biçim daha verimlidir. Bitişik oldukları için yalnızca gerekli sütunları okuyacaktır. Bu şekilde I/O işlemleri minimumda tutulur.

Örneğin yalnızca NAME sütununa ihtiyacınız var. İÇİNDE dize biçimi Veri kümesindeki her kaydın yüklenmesi, alana göre ayrıştırılması ve ardından NAME verilerinin çıkarılması gerekir. Sütun formatı, o sütuna ait tüm değerlerin bir arada saklanması nedeniyle doğrudan Ad sütununa gitmenize olanak tanır. Kaydın tamamını taramanıza gerek yoktur.

Böylece sütunlu biçim, gerekli sütunlara ulaşmak için daha az arama süresi gerektirdiğinden sorgu performansını artırır ve yalnızca istenen sütunlar okunduğu için G/Ç işlemlerinin sayısını azaltır.

Benzersiz özelliklerden biri Parke bu formatta mümkün mü verileri iç içe geçmiş yapılarla depolayın. Bu, bir Parke dosyasında, iç içe geçmiş alanların bile, iç içe yapıdaki tüm alanları okumaya gerek kalmadan ayrı ayrı okunabileceği anlamına gelir. Parke, iç içe geçmiş yapıları depolamak için bir parçalama ve birleştirme algoritması kullanır.

Hadoop'ta Parke dosya formatını anlamak için aşağıdaki terimleri bilmeniz gerekir:

1. Dize grubu (satır grubu): verilerin mantıksal olarak satırlara bölünmesi. Bir satır grubu, veri kümesindeki her sütunun bir parçasından oluşur.
2. Sütun parçası (sütun öbeği): Belirli bir sütunun parçası. Bu sütun parçaları belirli bir satır grubunda bulunur ve dosyada bitişik olmaları garanti edilir.
3. Sayfa (sayfa): Sütun parçaları birbiri ardına yazılan sayfalara bölünmüştür. Sayfaların ortak bir başlığı olduğundan okurken gereksiz olanları atlayabilirsiniz.

Burada başlık sadece sihirli sayıyı içeriyor PAR1 (4 bayt), dosyayı Parke dosyası olarak tanımlar.

Altbilgide şunu söylüyor:

1. Her sütunun meta verilerinin başlangıç ​​koordinatlarını içeren dosya meta verileri. Okurken, ilgilendiğiniz tüm sütun parçalarını bulmak için öncelikle dosyanın meta verilerini okumalısınız. Sütun bölümleri daha sonra sırayla okunmalıdır. Diğer meta veriler format sürümünü, şemayı ve varsa ek anahtar/değer çiftlerini içerir.
2. Meta veri uzunluğu (4 bayt).
3. sihirli sayı PAR1 (4 bayt).

ORC Dosya Formatı

Optimize edilmiş satır-sütun dosya formatı (Optimize Edilmiş Satır Sütunu, ORC) verileri depolamak için çok etkili bir yol sunar ve diğer formatların sınırlamalarının üstesinden gelmek üzere tasarlanmıştır. Verileri mükemmel derecede kompakt bir biçimde depolayarak, büyük, karmaşık veya manuel olarak bakımı yapılan dizinlerin oluşturulmasına gerek kalmadan gereksiz ayrıntıları atlamanıza olanak tanır.

ORC formatının avantajları:

1. Bir dosya, her görevin çıktısıdır ve bu, NameNode (isim düğümü) üzerindeki yükü azaltır.
2. DateTime, ondalık ve karmaşık veri türleri (yapı, liste, harita ve birleşim) dahil olmak üzere Hive veri türleri için destek.
3. Aynı dosyanın farklı RecordReader işlemleri tarafından eşzamanlı okunması.
4. İşaretçileri taramadan dosyaları bölme yeteneği.
5. Dosya altbilgisindeki bilgilere dayanarak okuma/yazma işlemleri için mümkün olan maksimum yığın bellek tahsisinin tahmini.
6. Meta veriler, alanların eklenmesine ve kaldırılmasına olanak tanıyan Protokol Tamponları ikili serileştirme biçiminde saklanır.

ORC, dize koleksiyonlarını tek bir dosyada saklar ve koleksiyon içinde dize verileri sütunlu bir biçimde saklanır.

Bir ORC dosyası, şerit adı verilen satır gruplarını ve destekleyici bilgileri dosyanın altbilgisinde saklar. Dosyanın sonundaki Postscript, sıkıştırma parametrelerini ve sıkıştırılmış altbilginin boyutunu içerir.

Varsayılan şerit boyutu 250 MB'dir. Bu kadar büyük şeritler nedeniyle, HDFS'den okuma daha verimli bir şekilde gerçekleştirilir: büyük bitişik bloklar halinde.

Dosya altbilgisi, dosyadaki şeritlerin listesini, şerit başına satır sayısını ve her sütunun veri türünü kaydeder. Her sütun için sonuç olarak sayılan, min, maks ve toplam değeri de burada yazılır.

Şeridin altbilgisi akış konumlarının bir dizinini içerir.

Tablolar taranırken satır verileri kullanılır.

İndeks verileri, her bir sütun için minimum ve maksimum değerleri ve her sütundaki satırların konumunu içerir. ORC indeksleri sorguları yanıtlamak için değil, yalnızca şeritleri ve satır gruplarını seçmek için kullanılır.

Farklı dosya formatlarının karşılaştırılması

Avro'nun Parke ile karşılaştırılması

1. Avro bir satır depolama formatıdır, Parquet ise verileri sütunlarda saklar.
2. Parke analitik sorgular için daha uygundur; yani okuma işlemleri ve veri sorgulama, yazma işlemlerine göre çok daha verimlidir.
3. Avro'da yazma işlemleri Parquet'e göre daha verimli gerçekleştirilir.
4. Avro devre evrimini daha olgun bir şekilde ele alıyor. Parquet yalnızca şema eklemeyi desteklerken Avro, çok işlevli evrimi, yani sütun eklemeyi veya değiştirmeyi destekler.
5. Parke, çok sütunlu bir tablodaki sütunların bir alt kümesini sorgulamak için idealdir. Avro, tüm sütunları sorguladığımız ETL işlemleri için uygundur.

ORC ve Parke

1. Parke iç içe geçmiş verileri daha iyi saklar.
2. ORC, aşağı itmeyi öngörmek için daha uygundur.
3. ORC, ACID özelliklerini destekler.
4. ORC verileri daha iyi sıkıştırır.

Konuyla ilgili başka ne okunmalı?:

1. Bulutta büyük veri analizi: Bir şirket nasıl veri odaklı hale gelebilir?.
2. Veritabanı Şemaları İçin Mütevazı Bir Kılavuz.
3. Dijital dönüşümle ilgili telegram kanalımız.

Kaynak: habr.com