Jakie są wady i zalety formatu parkietu w porównaniu z innymi formatami?

Charakterystyka parkietu Apache to:

• Samoopisujące
• Format kolumnowy
• Niezależne od języka

W porównaniu do Avro, Sequence Files, RC File itp. Chcę mieć przegląd formatów. Przeczytałem już: Jak Impala współpracuje z formatami plików Hadoop , daje wgląd w formaty, ale chciałbym wiedzieć, w jaki sposób odbywa się dostęp do danych i przechowywanie danych w każdym z tych formatów. Jak parkiet ma przewagę nad innymi?

Myślę, że główna różnica, jaką mogę opisać, dotyczy formatów zorientowanych na rekordy i formatów zorientowanych na kolumny. Formaty zorientowane na nagrania są tym, do czego wszyscy jesteśmy przyzwyczajeni - pliki tekstowe, formaty rozdzielane, takie jak CSV, TSV. AVRO jest nieco fajniejsze niż te, ponieważ z czasem może zmieniać schemat, np. Dodając lub usuwając kolumny z rekordu. Inne sztuczki różnych formatów (szczególnie w tym kompresji) dotyczą tego, czy format można podzielić - to znaczy, czy możesz odczytać blok rekordów z dowolnego miejsca w zbiorze danych i nadal znać jego schemat? Ale tutaj jest więcej szczegółów na temat formatów kolumnowych, takich jak Parkiet.

Parkiet i inne formaty kolumnowe bardzo wydajnie radzą sobie z typową sytuacją na platformie Hadoop. Często tabele (zestawy danych) mają o wiele więcej kolumn, niż można by oczekiwać w dobrze zaprojektowanej relacyjnej bazie danych - sto lub dwieście kolumn nie jest niczym niezwykłym. Dzieje się tak, ponieważ często używamy Hadoop jako miejsca do denormalizacji danych z formatów relacyjnych - tak, otrzymujesz wiele powtarzających się wartości i wiele tabel spłaszczonych w jedną. Ale zapytanie staje się znacznie łatwiejsze, ponieważ wszystkie łączenia są opracowane. Istnieją inne zalety, takie jak zachowywanie danych stanu w czasie. Tak czy inaczej, często mamy w tabeli mnóstwo kolumn.

Załóżmy, że mamy 132 kolumny, a niektóre z nich to naprawdę długie pola tekstowe, każda inna kolumna jedna po drugiej i zajmują może 10 KB na rekord.

Podczas wykonywania zapytań dotyczących tych tabel z punktu widzenia SQL, często chcesz uzyskać pewien zakres rekordów na podstawie tylko kilku z tych ponad stu kolumn. Na przykład możesz potrzebować wszystkich rekordów z lutego i marca dla klientów ze sprzedażą> 500 USD.

Aby to zrobić w formacie wierszowym, kwerenda musiałaby przeskanować każdy rekord zbioru danych. Przeczytaj pierwszy wiersz, przeanalizuj rekord na pola (kolumny) i pobierz kolumny z datą i sprzedażą, dołącz je do wyniku, jeśli spełnia warunek. Powtarzać. Jeśli masz 10 lat (120 miesięcy) historii, czytasz każdy rekord tylko po to, aby znaleźć 2 z tych miesięcy. Oczywiście jest to świetna okazja, aby użyć partycji dla roku i miesiąca, ale mimo to czytasz i analizujesz 10 000 każdego rekordu / wiersza przez te dwa miesiące, aby sprawdzić, czy sprzedaż klienta przekracza 500 USD.

W formacie kolumnowym każda kolumna (pole) rekordu jest przechowywana razem z innymi tego rodzaju, rozłożonymi na wiele różnych bloków na dysku - kolumny na rok razem, kolumny na miesiąc razem, kolumny z podręcznika pracownika klienta (lub inne) długi tekst) i wszystkie inne, które sprawiają, że te rekordy są tak ogromne, wszystko w osobnym miejscu na dysku i oczywiście kolumny do sprzedaży razem. No cóż, data i miesiące to liczby, podobnie jak sprzedaż - to tylko kilka bajtów. Czy nie byłoby wspaniale, gdybyśmy musieli odczytać tylko kilka bajtów dla każdego rekordu, aby określić, które rekordy pasują do naszego zapytania? Kolumnowy magazyn na ratunek!

Nawet bez partycji skanowanie małych pól potrzebnych do spełnienia naszego zapytania jest superszybkie - wszystkie są uporządkowane według rekordów i mają ten sam rozmiar, więc dysk szuka o wiele mniej danych w poszukiwaniu dołączonych rekordów. Nie musisz czytać tego podręcznika pracownika ani innych długich pól tekstowych - po prostu je zignoruj. Tak więc, grupując kolumny ze sobą, zamiast wierszy, prawie zawsze można przeskanować mniej danych. Zdobyć!

Zaczekaj, robi się coraz lepiej. Gdyby zapytanie wymagało tylko podania tych wartości i kilku innych (powiedzmy 10 ze 132 kolumn) i nie przejmowało się tą kolumną z podręcznikiem pracownika, po wybraniu odpowiednich rekordów do zwrócenia wystarczyłoby teraz tylko przejść z powrotem do 10 kolumn potrzebnych do wyrenderowania wyników, ignorując pozostałe 122 ze 132 w naszym zbiorze danych. Ponownie pomijamy dużo czytania.

(Uwaga: z tego powodu formaty kolumnowe są kiepskim wyborem podczas wykonywania prostych przekształceń, na przykład, jeśli łączysz wszystkie dwie tabele w jeden duży (ger) zestaw wyników, który zapisujesz jako nową tabelę, źródła i tak zostaną całkowicie przeskanowane, więc nie ma dużej korzyści z wydajności odczytu, a ponieważ formaty kolumnowe muszą pamiętać więcej o miejscu, w którym się znajdują, zużywają więcej pamięci niż podobny format wierszy).

Jeszcze jedna zaleta kolumnowości: dane są rozproszone. Aby uzyskać pojedynczy rekord, możesz mieć 132 pracowników, z których każdy odczytuje (i zapisuje) dane z / do 132 różnych miejsc w 132 blokach danych. Brawo za zrównoleglenie!

A teraz dla klinczera: algorytmy kompresji działają znacznie lepiej, gdy mogą znaleźć powtarzające się wzorce. Można skompresować AABBBBBBCCCCCCCCCCCCCCCCtak 2A6B16C, ale ABCABCBCBCBCCCCCCCCCCCCCCnie dostać tak małe (no, rzeczywiście, w tym przypadku, że będzie, ale uwierzcie mi :-)). Więc jeszcze raz mniej czytania. I pisanie też.

Dlatego czytamy dużo mniej danych, aby odpowiedzieć na typowe zapytania, równoległe odczytywanie i zapisywanie jest potencjalnie szybsze, a kompresja zwykle działa znacznie lepiej.

Kolumnowy jest świetny, gdy strona wejściowa jest duża, a wyjście jest przefiltrowanym podzbiorem: od dużego do małego jest świetne. Nie tak korzystne, gdy dane wejściowe i wyjściowe są mniej więcej takie same.

Ale w naszym przypadku Impala zajęła się naszymi starymi zapytaniami Hive, które trwały 5, 10, 20 lub 30 minut i zakończyły się w ciągu kilku sekund lub minuty.

Mam nadzieję, że pomoże to odpowiedzieć przynajmniej na część pytania!

Avro to format przechowywania oparty na wierszach dla platformy Hadoop.

Parkiet to oparty na kolumnach format przechowywania dla Hadoop.

Jeśli Twój przypadek użycia zazwyczaj skanuje lub pobiera wszystkie pola w wierszu w każdym zapytaniu, Avro jest zwykle najlepszym wyborem.

Jeśli zestaw danych zawiera wiele kolumn, a przypadek użycia zazwyczaj obejmuje pracę z podzbiorem tych kolumn, a nie z całymi rekordami, Parquet jest zoptymalizowany pod kątem tego rodzaju pracy.

Źródło

Odpowiedź Toma jest dość szczegółowa i wyczerpująca, ale możesz być również zainteresowany tym prostym badaniem na temat Parquet vs Avro przeprowadzonym w Allstate Insurance, podsumowanym tutaj:

„Ogólnie rzecz biorąc, Parquet wykazał podobne lub lepsze wyniki w każdym teście [niż Avro]. Różnice w wydajności zapytań w większych zestawach danych na korzyść Parqueta częściowo wynikają z wyników kompresji; podczas odpytywania szerokiego zestawu danych Spark musiał odczytać 3,5x mniej danych dla Parquet niż Avro. Avro nie działało dobrze podczas przetwarzania całego zbioru danych, jak podejrzewano ”.

Wybór odpowiedniego formatu pliku jest ważny przy tworzeniu wydajnych aplikacji danych. Koncepcje przedstawione w tym poście są przenoszone do Pandas, Dask, Spark i Presto / AWS Athena.

Przycinanie kolumn

Przycinanie kolumn to duża poprawa wydajności, która jest możliwa w przypadku formatów plików opartych na kolumnach (Parquet, ORC), ale nie jest możliwa w przypadku formatów plików opartych na wierszach (CSV, Avro).

Załóżmy, że masz zestaw danych zawierający 100 kolumn i chcesz wczytać dwie z nich do ramki DataFrame. Oto, jak możesz to zrobić z Pandas, jeśli dane są przechowywane w pliku Parquet.

import pandas as pd

pd.read_parquet('some_file.parquet', columns = ['id', 'firstname'])

Parkiet to format pliku kolumnowego, więc Pandy mogą przechwytywać kolumny istotne dla zapytania i mogą pominąć inne kolumny. To ogromna poprawa wydajności.

Jeśli dane są przechowywane w pliku CSV, możesz to odczytać w ten sposób:

import pandas as pd

pd.read_csv('some_file.csv', usecols = ['id', 'firstname'])

usecols nie można pominąć całych kolumn ze względu na wierszowy charakter formatu pliku CSV.

Spark nie wymaga od użytkowników jawnego wyświetlania kolumn, które będą używane w zapytaniu. Spark tworzy plan wykonania i automatycznie wykorzystuje przycinanie kolumn, gdy tylko jest to możliwe. Oczywiście przycinanie kolumn jest możliwe tylko wtedy, gdy podstawowy format pliku jest zorientowany na kolumny.

Popularność

Spark i Pandas mają wbudowane czytniki zapisujące pliki CSV, JSON, ORC, Parquet i tekstowe. Nie mają wbudowanych czytników dla Avro.

Avro jest popularny w ekosystemie Hadoop. Parkiet zyskał znaczną przyczepność poza ekosystemem Hadoop. Na przykład projekt Delta Lake jest tworzony na plikach Parquet.

Arrow to ważny projekt, który ułatwia pracę z plikami Parquet w wielu różnych językach (C, C ++, Go, Java, JavaScript, MATLAB, Python, R, Ruby, Rust), ale nie obsługuje Avro. Pilniki parkietowe są łatwiejsze w użyciu, ponieważ są obsługiwane przez wiele różnych projektów.

Schemat

Parquet przechowuje schemat pliku w metadanych pliku. Pliki CSV nie przechowują metadanych plików, więc czytelnicy muszą być dostarczeni ze schematem lub schemat musi zostać wywnioskowany. Dostarczanie schematu jest żmudne, a wnioskowanie o schemacie jest podatne na błędy / kosztowne.

Avro przechowuje również schemat danych w samym pliku. Posiadanie schematu w plikach jest ogromną zaletą i jest jednym z powodów, dla których nowoczesny projekt danych nie powinien polegać na JSON lub CSV.

Metadane kolumny

Parquet przechowuje statystyki metadanych dla każdej kolumny i pozwala użytkownikom dodawać również własne metadane kolumn .

Metadane wartości kolumny min / max pozwalają na filtrowanie predykatów Parquet, które jest obsługiwane przez platformy obliczeniowe klastra Dask & Spark.

Oto jak pobrać statystyki kolumn za pomocą PyArrow.

import pyarrow.parquet as pq

parquet_file = pq.ParquetFile('some_file.parquet')
print(parquet_file.metadata.row_group(0).column(1).statistics)

<pyarrow._parquet.Statistics object at 0x11ac17eb0>
  has_min_max: True
  min: 1
  max: 9
  null_count: 0
  distinct_count: 0
  num_values: 3
  physical_type: INT64
  logical_type: None
  converted_type (legacy): NONE

Złożone typy kolumn

Parquet pozwala na tworzenie złożonych typów kolumn, takich jak tablice, słowniki i zagnieżdżone schematy. Nie ma niezawodnej metody przechowywania złożonych typów w prostych formatach plików, takich jak CSV.

Kompresja

Kolumnowe formaty plików przechowują powiązane typy w wierszach, dzięki czemu można je łatwiej kompresować. Ten plik CSV jest stosunkowo trudny do skompresowania.

first_name,age
ken,30
felicia,36
mia,2

Te dane są łatwiejsze do skompresowania, gdy powiązane typy są przechowywane w tym samym wierszu:

ken,felicia,mia
30,36,2

Pliki Parquet są najczęściej kompresowane za pomocą algorytmu kompresji Snappy. Skompresowane pliki Snappy można podzielić i szybko nadmuchać. Systemy Big Data chcą zmniejszyć rozmiar plików na dysku, ale chcą też przyspieszyć nadmuchiwanie much i przeprowadzanie zapytań analitycznych.

Zmienny charakter pliku

Jak opisano tutaj, pilniki parkietowe są niezmienne . Pliki CSV są zmienne.

Dodanie wiersza do pliku CSV jest łatwe. Nie można łatwo dodać wiersza do pliku Parquet.

Jeziora danych

W środowisku dużych zbiorów danych będziesz pracować z setkami lub tysiącami plików Parquet. Ważne jest partycjonowanie plików na dysku, unikanie dużych plików i kompaktowanie małych plików. Optymalny układ danych na dysku zależy od wzorców zapytań.