Örnek sorular
Pe File Formats Table FormatsZorluk 1
Bir ekip 80 sütunlu bir tabloyu Parquet olarak saklıyor ve analitik sorgularda her seferinde yalnızca 3-4 sütun okuyor. Parquet bu erişim örüntüsüne neden iyi uyuyor?
- aDeğerleri sütun sütun sakladığı için yalnızca istenen column chunk'lar okunur✓
- bHer alanı düz metin olarak sakladığı için tüm sütunlar eşit hızda ayrıştırılır
- cTek bir sütun gerekse bile tüm satırın deserialize edilmesini gerektirir
- dYalnızca bir dosyanın ilk sütununu okumayı destekler, keyfi sütunları değil
Açıklama:Parquet sütunlu (columnar) bir formattır; her sütunun verisi column chunk'larda art arda saklanır, bu yüzden okuyucu istenmeyen sütunların chunk'larını atlayabilir; satır-yönelimli formatlar ise tüm kaydı okumak zorundadır.
Pe File Formats Table FormatsZorluk 1
Bir alım (ingestion) işi her seferinde tek bir tam kaydı ekliyor ve tek tek sütunları neredeyse hiç geri okumuyor. Hangi depolama düzeni bu örüntüye daha doğal uyar?
- aSütunlu, çünkü column chunk'lar diğer sütunlara dokunmadan bağımsız eklenebilir
- bSatır-yönelimli, çünkü tam bir kayıt art arda yazılabilir✓
- cSütunlu, çünkü dictionary encoding her yazmayı herhangi bir satır formatından hızlı yapar
- dSatır-yönelimli, çünkü dosyanın asla büyümesini engeller
Açıklama:Satır-yönelimli formatlar (ör. Avro) tam bir kaydı bir arada saklar; bu, tüm kaydı yazan/okuyan iş yüklerine uyar. Sütunlu formatlar ise çok sayıda satır boyunca sütun alt kümesi okumayı optimize eder, tekil tam kayıt eklemeyi değil.
Pe File Formats Table FormatsZorluk 1
Parquet dosya formatında row group (satır grubu) nedir?
- aBir dictionary page içinde saklanan tek bir sıkıştırılmış değer
- bBir tarih sütununa göre partition'lanmış dosyaların bulunduğu dizin
- cSatırların yatay dilimi; sütun başına bir column chunk✓
- dDosyanın şemasını listeleyen footer bölümü
Açıklama:Row group, dosyanın satırlarının yatay bir bölümlemesidir; bir row group içinde her sütunun, o satırlara ait değerleri tutan kendi column chunk'ı vardır.
Pe File Formats Table FormatsZorluk 1
Bir Parquet dosyasının footer'ı öncelikle neyi içerir?
- aRow-group/chunk metadata'sı ve istatistikler✓
- bDosyadaki her satırın sıkıştırılmamış ham değerleri
- cHer sütun için ayrı bir dictionary page kopyası
- dDosyayı yazmak için kullanılan Spark job konfigürasyonu
Açıklama:Footer, dosyanın şemasını ve row group/column chunk'ları tanımlayan metadata'yı (sütun bazlı istatistikler dahil) saklar; okuyucular dosyanın hangi kısımlarını okuyacağını buna göre planlar.
Pe File Formats Table FormatsZorluk 2
Parquet column chunk'ları metadata'sında min/max istatistikleri taşıyabilir. Sorgu motorları bu istatistikleri tipik olarak nasıl kullanır?
- aSütun için hangi sıkıştırma codec'inin kullanıldığına karar vermek için
- bBir row group içindeki sütunların fiziksel sırasına karar vermek için
- cDictionary page silinmişse onu yeniden oluşturmak için
- dFiltre eşleşemiyorsa o row group'u atlamak için✓
Açıklama:Bir sorgu bir sütun üzerinde filtre uyguluyorsa ve bir row group'un min/max aralığı bu koşulu sağlayamıyorsa motor o row group'u hiç okumadan atlayabilir; buna sıklıkla predicate pushdown ya da row-group skipping denir.
Pe File Formats Table FormatsZorluk 1
gzip ile karşılaştırıldığında, Parquet'te snappy sıkıştırma codec'ini kullanmanın tipik takası nedir?
- aSnappy gzip'ten çok daha küçük sıkıştırır ama açması çok daha yavaştır
- bSnappy daha hızlıdır ama genelde gzip'ten büyük dosya üretir✓
- cSnappy ve gzip her zaman aynı dosya boyutunu ve hızı üretir
- dSnappy yalnızca satır-yönelimli formatlarla kullanılabilir, Parquet ile değil
Açıklama:Snappy sıkıştırma oranından çok hızı önceliklendirir; gzip ise genelde daha fazla CPU süresi karşılığında daha sıkı sıkıştırır — codec'ler arasındaki klasik hız-vs-oran takası.