Sanırım tanımlayabileceğim temel fark, kayıt odaklı ve sütun yönelimli formatlarla ilgili. Kayıt odaklı formatlar hepimizin alışkın olduğu şeylerdir - metin dosyaları, CSV, TSV gibi sınırlandırılmış formatlar. AVRO, zamanla şemayı değiştirebildiğinden, örneğin bir kayıttan sütun eklemek veya kaldırmak gibi, onlardan biraz daha iyidir. Çeşitli formatların (özellikle sıkıştırma dahil) diğer hileleri, bir formatın bölünüp bölünemeyeceğini içerir - yani, veri kümesinin herhangi bir yerinden bir kayıt bloğunu okuyabilir ve yine de şemasını biliyor musunuz? Ama burada, Parquet gibi sütunlu biçimler hakkında daha fazla ayrıntı var.
Parke ve diğer sütun biçimleri, yaygın bir Hadoop durumunu çok verimli bir şekilde ele alır. İyi tasarlanmış bir ilişkisel veritabanında beklediğinizden çok daha fazla sütuna sahip tablolara (veri kümelerine) sahip olmak yaygındır - yüz veya iki yüz sütun olağandışı değildir. Sık sık bir yer olarak Hadoop kullandığından, bu böyledir denormalize , ilişkisel biçimlerden verileri - evet, birçok tekrarlanan değer elde edersiniz ve birçok tablonun tümü tek bir tablo halinde düzleştirilmiş. Ancak tüm birleştirmeler tamamlandığı için sorgulamak çok daha kolay hale gelir. Zaman içinde durum verilerini tutmak gibi başka avantajlar da vardır. Her neyse, bir tabloda bir sürü sütun olması yaygındır.
Diyelim ki 132 sütun var ve bazıları gerçekten uzun metin alanları, her biri birbirini takip eden farklı sütun ve kayıt başına belki 10K kullanıyor.
SQL bakış açısından bu tabloları sorgulamak kolay olsa da, bu yüzden fazla sütunun yalnızca birkaçına dayalı olarak bir dizi kayıt almak isteyeceğiniz yaygındır. Örneğin, satışları> 500 $ olan müşteriler için tüm kayıtları Şubat ve Mart aylarında isteyebilirsiniz.
Bunu bir satır biçiminde yapmak için, sorgunun veri kümesinin her kaydını taraması gerekir. İlk satırı okuyun, kaydı alanlara (sütunlar) ayırın ve tarih ve satış sütunlarını alın, koşulu karşılıyorsa sonucunuza ekleyin. Tekrar et. 10 yıllık (120 aylık) bir geçmişiniz varsa, o aylardan 2 tanesini bulmak için her bir kaydı okuyorsunuz. Elbette bu, bir bölümü yıl ve ay boyunca kullanmak için harika bir fırsat, ancak yine de, müşterinin satışlarının> 500 $ olup olmadığını bulmak için bu iki ay boyunca her bir kaydın / satırın 10K'sını okuyup ayrıştırıyorsunuz.
Sütunlu bir biçimde, bir kaydın her bir sütunu (alanı), türünün diğerleriyle birlikte depolanır, diskteki birçok farklı bloğa yayılır - birlikte yıl için sütunlar, birlikte ay için sütunlar, müşteri çalışan el kitabı için sütunlar (veya diğer uzun metin) ve bu kayıtları bu kadar büyük yapan diğerlerinin hepsi diskte kendi ayrı yerlerinde ve tabii ki birlikte satış için sütunlar. Evet, tarih ve aylar sayıdır ve satışlar da öyle - bunlar sadece birkaç bayttır. Sorgumuzla hangi kayıtların eşleştiğini belirlemek için her kayıt için yalnızca birkaç bayt okumak zorunda olsaydık harika olmaz mıydı? Kurtarmak için sütunlu depolama!
Bölümler olmasa bile, sorgumuzun karşılanması için gereken küçük alanların taranması süper hızlıdır - hepsi kayıt sırasına göre düzenlenmiştir ve hepsi aynı boyuttadır, bu nedenle disk, dahil edilen kayıtları kontrol etmek için çok daha az veri arar. Çalışan el kitabını ve diğer uzun metin alanlarını okumaya gerek yok - sadece onları görmezden gelin. Dolayısıyla, sütunları satırlar yerine birbirleriyle gruplayarak, neredeyse her zaman daha az veri tarayabilirsiniz. Kazan!
Ama bekleyin, daha iyi olur. Sorgunuz yalnızca bu değerleri ve birkaç tanesini (diyelim ki 132 sütunun 10'unu) bilmesi gerekiyorsa ve bu çalışan el kitabı sütunu umurunda değilse, geri dönmek için doğru kayıtları seçtikten sonra, artık yalnızca gitmesi gerekecekti Veri kümemizdeki 132 sütunun diğer 122'sini göz ardı ederek sonuçları işlemek için ihtiyaç duyduğu 10 sütuna geri döndük. Yine, çok fazla okumayı atlıyoruz.
(Not: Bu nedenle, sütunlu formatlar düz dönüşümler yaparken kötü bir seçimdir, örneğin, iki tablonun tümünü yeni bir tablo olarak kaydettiğiniz büyük (ger) sonuç kümesinde birleştiriyorsanız, kaynaklar her halükarda tamamen taranacaktır, bu nedenle okuma performansında pek fazla fayda yoktur ve sütunlu formatlar, öğelerin nerede olduğu hakkında daha fazla hatırlamaya ihtiyaç duyduğundan, benzer bir satır formatından daha fazla bellek kullanırlar).
Sütunlu olmanın bir yararı daha: veriler etrafa yayılır. Tek bir kayıt elde etmek için, 132 işçinin her biri 132 veri bloğundaki 132 farklı yerden veri okuyup yazmasını sağlayabilirsiniz. Paralelleştirme için Yay!
Ve şimdi kesinleşen için: Sıkıştırma algoritmaları, tekrar eden kalıpları bulabildiğinde çok daha iyi çalışıyor. Sen sıkıştırmak olabilir AABBBBBBCCCCCCCCCCCCCCCColarak 2A6B16Cancak ABCABCBCBCBCCCCCCCCCCCCCCküçük olarak elde değildir (iyi, aslında, bu durumda olur ama güven bana :-)). Yani bir kez daha, daha az okumak. Ve yazmak da.
Bu nedenle, sık sorulan soruları yanıtlamak için çok daha az veri okuyoruz, paralel olarak okuma ve yazma potansiyeli daha hızlıdır ve sıkıştırma çok daha iyi çalışma eğilimindedir.
Sütun, giriş tarafınız büyük olduğunda ve çıktınız filtrelenmiş bir alt küme olduğunda harikadır: büyükten küçüğe harika. Girdi ve çıktılar hemen hemen aynı olduğunda yararlı değil.
Ancak bizim durumumuzda Impala, 5, 10, 20 veya 30 dakikada çalışan ve çoğu birkaç saniye veya bir dakika içinde biten eski Hive sorgularımızı aldı.
Umarım bu, sorunuzun en azından bir kısmını yanıtlamanıza yardımcı olur!