🥇Formaty plików w dużych danych: krótki przegląd

Bóg Pogody autorstwa Remarina

Zespół Mail.ru Cloud Solutions oferuje tłumaczenie artykułu inżyniera Rahula Bhatii z firmy Clairvoyant na temat formatów plików w big data, najbardziej powszechnych funkcji formatów Hadoop oraz tego, który format jest lepszy do użycia.

Po co potrzebne są różne formaty plików

Poważnym wąskim gardłem w wydajności aplikacji wspierających HDFS, takich jak MapReduce i Spark, jest czas wyszukiwania, odczytu oraz zapisu danych. Problemy te pogłębiają trudności w zarządzaniu dużymi zbiorami danych, gdy nie mamy stałego, a ewolucyjnego schematu lub występują pewne ograniczenia przechowywania.

Przetwarzanie big data zwiększa obciążenie systemu magazynowania — Hadoop przechowuje dane nadmiarowo, aby osiągnąć odporność na błędy. Oprócz dysków obciążone są także procesor, sieć, system wejścia/wyjścia i tak dalej. W miarę wzrostu objętości danych rośnie również koszt ich przetwarzania i przechowywania.

Różne formaty plików w Hadoop stworzono w celu rozwiązania tych problemów. Wybór odpowiedniego formatu pliku może przynieść znaczące korzyści:

Szybszy czas odczytu.
Szybszy czas zapisu.
Pliki współdzielone.
Wsparcie dla ewolucji schematów.
Rozszerzone wsparcie dla kompresji.

Niektóre formaty plików są przeznaczone do ogólnego użytku, inne do bardziej specyficznych zastosowań, a jeszcze inne zostały opracowane z myślą o konkretnych cechach danych. Wybór jest naprawdę bardzo duży.

Format plików Avro

Dla serializacji danych szeroko wykorzystuje Avro — to oparty na wierszach, czyli wierszowy, format przechowywania danych w Hadoop. Przechowuje schemat w formacie JSON, co ułatwia jego odczyt i interpretację przez dowolny program. Same dane są przechowywane w formacie binarnym, kompaktowo i efektywnie.

System serializacji Avro jest neutralny względem języka. Pliki mogą być przetwarzane w różnych językach, obecnie są to C, C++, C#, Java, Python i Ruby.

Kluczową cechą Avro jest niezawodne wsparcie dla schematów danych, które zmieniają się w czasie, to znaczy ewoluują. Avro rozumie zmiany w schemacie — usuwanie, dodawanie lub modyfikowanie pól.

Avro wspiera różnorodne struktury danych. Na przykład, można stworzyć rekord, który zawiera tablicę, typ wyliczeniowy i pod-rekord.

Ten format idealnie nadaje się do zapisu w strefie przejściowej jeziora danych (jezioro danych, czyli data lake — zbiór instancji do przechowywania różnych typów danych bezpośrednio obok źródeł danych).

Oto, dlaczego ten format najlepiej sprawdza się do zapisu w strefie jeziora danych:

Dane z tej strefy zazwyczaj są odczytywane w całości do dalszego przetwarzania przez systemy niższej warstwy — a format oparty na wierszach jest w tym przypadku bardziej efektywny.
Systemy niższej warstwy mogą łatwo wyciągać tabele schematów z plików — nie ma potrzeby przechowywania schematów osobno w zewnętrznym magazynie metadanych.
Każda zmiana w pierwotnym schemacie jest łatwo obsługiwana (ewolucja schematu).

Format plików Parquet

Parquet to otwartoźródłowy format plików dla Hadoop, który przechowuje zagnieżdżone struktury danych w płaskim formacie kolumnowym..

W porównaniu z tradycyjnym podejściem opartym na wierszach, Parquet jest bardziej efektywny pod względem przechowywania i wydajności.

To szczególnie przydatne w przypadku zapytań, które odczytują określone kolumny z szerokiej (z wieloma kolumnami) tabeli. Dzięki formatowi plików odczytywane są tylko niezbędne kolumny, co minimalizuje operacje wejścia-wyjścia.

Małe wprowadzenie - wyjaśnienie: aby lepiej zrozumieć format pliku Parquet w Hadoop, przyjrzyjmy się formatowi opartemu na kolumnach — czyli kolumnowemu. W tym formacie przechowywane są razem jednorodne wartości każdej kolumny.

Na przykład, rekord zawiera pola ID, Name i Department. W tym przypadku wszystkie wartości kolumny ID będą przechowywane razem, podobnie jak wartości kolumny Name i tak dalej. Tabela będzie wyglądać mniej więcej tak:

ID
Name
Department

1
emp1
d1

2
emp2
d2

3
emp3
d3

W formacie wiersza dane zachowają się w następujący sposób:

1
emp1
d1
2
emp2
d2
3
emp3
d3

W kolumnowym formacie plików te same dane będą przechowywane w ten sposób:

1
2
3
emp1
emp2
emp3
d1
d2
d3

Format kolumnowy jest bardziej efektywny, gdy musisz wyciągnąć z tabeli kilka kolumn. Odczyta tylko potrzebne kolumny, ponieważ są one blisko siebie. W ten sposób operacje wejścia-wyjścia są zminimalizowane.

Na przykład potrzebujesz tylko kolumny NAME. W formacie wiersza Każdy wpis w zbiorze danych musi zostać załadowany, rozdzielony na pola, a następnie należy wydobyć dane NAME. Format kolumnowy pozwala bezpośrednio przejść do kolumny Name, ponieważ wszystkie wartości dla tej kolumny są przechowywane razem. Nie ma potrzeby przeszukiwania całego wpisu.

W ten sposób format kolumnowy zwiększa wydajność zapytań, ponieważ czas potrzebny na dotarcie do wymaganych kolumn jest krótszy, a liczba operacji wejścia-wyjścia jest zredukowana, ponieważ czytane są tylko potrzebne kolumny.

Jedną z unikalnych cech Parquet jest to, że w takim formacie może przechowywać dane z zagnieżdżonymi strukturami. Oznacza to, że w pliku Parquet nawet zagnieżdżone pola można czytać osobno, bez konieczności odczytywania wszystkich pól w zagnieżdżonej strukturze. Do przechowywania zagnieżdżonych struktur Parquet wykorzystuje algorytm rozdrobnienia i składania (shredding and assembly).

Aby zrozumieć format pliku Parquet w Hadoop, należy znać następujące terminy:

Grupa wierszy (row group): logiczne poziome podział danych na wiersze. Grupa wierszy składa się z fragmentu każdej kolumny w zbiorze danych.
Fragment kolumny (kolumna chunk): fragment konkretnej kolumny. Te fragmenty kolumn znajdują się w określonej grupie wierszy i będą sąsiadować ze sobą w pliku.
Strona (strona): fragmenty kolumn są dzielone na strony, zapisywane jedna po drugiej. Strony mają wspólny nagłówek, więc podczas czytania można pominąć niepotrzebne.

Tutaj nagłówek zawiera po prostu magiczną liczbę PAR1 (4 bajty), która identyfikuje plik jako plik formatu Parquet.

W stopce zapisano następujące:

Metadane pliku, które zawierają początkowe współrzędne metadanych każdej kolumny. Podczas czytania należy najpierw odczytać metadane pliku, aby znaleźć wszystkie interesujące fragmenty kolumn. Następnie fragmenty kolumn należy odczytywać sekwencyjnie. Metadane zawierają również wersję formatu, schemat oraz wszelkie dodatkowe pary klucz-wartość.
Długość metadanych (4 bajty).
Magiczna liczba PAR1 (4 bajty).

Format plików ORC

Optymalizowany format plików wierszowo-kolumnowych (Optimized Row Columnar, ORC) oferuje bardzo efektywny sposób przechowywania danych i został zaprojektowany, aby przezwyciężyć ograniczenia innych formatów. Przechowuje dane w idealnie kompaktowej formie, pomijając zbędne szczegóły — jednocześnie nie wymaga tworzenia dużych, skomplikowanych ani ręcznie zarządzanych indeksów.

Zalety formatu ORC:

Jeden plik jako wynik każdej zadań, co zmniejsza obciążenie NameNode (węzeł nazw).
Wsparcie dla typów danych Hive, w tym DateTime, typów dziesiętnych oraz złożonych typów danych (struktura, lista, mapa, unia).
Jednoczesne odczytywanie tego samego pliku przez różne procesy RecordReader.
Możliwość dzielenia plików bez skanowania pod kątem znaczników.
Ocena maksymalnego przydziału pamięci dla procesów odczytu/zapisu na podstawie informacji w stopce pliku.
Metadane są przechowywane w binarnym formacie serializacji Protocol Buffers, co pozwala na dodawanie i usuwanie pól.

ORC przechowuje kolekcje wierszy w jednym pliku, a wewnątrz kolekcji dane wierszowe są przechowywane w formacie kolumnowym.

Plik ORC przechowuje grupy wierszy, zwane paskami (stripes), oraz informacje pomocnicze w stopce pliku. Postscript na końcu pliku zawiera parametry kompresji oraz rozmiar skompresowanej stopki.

Domyślny rozmiar paska wynosi 250 MB. Dzięki takim dużym paskom odczyt z HDFS jest bardziej efektywny: odbywa się dużymi, ciągłymi blokami.

W stopce pliku zapisany jest wykaz pasków w pliku, liczba wierszy na pasek oraz typ danych każdej kolumny. Tam także zapisano wartości końcowe count, min, max i sum dla każdej kolumny.

Stopka paska zawiera katalog lokalizacji strumienia.

Dane szeregowe są używane podczas skanowania tabel.

Dane indeksowe zawierają minimalne i maksymalne wartości dla każdej kolumny oraz pozycje wierszy w każdej kolumnie. Indeksy ORC są używane tylko do wyboru pasków i grup wierszy, a nie do odpowiedzi na zapytania.

Porównanie różnych formatów plików

Avro w porównaniu do Parquet

Avro to format przechowywania po wierszach, podczas gdy Parquet przechowuje dane po kolumnach.
Parquet lepiej nadaje się do zapytań analitycznych, to znaczy operacje odczytu i zapytania o dane są znacznie bardziej efektywne niż zapisywanie.
Operacje zapisu w Avro są bardziej efektywne niż w Parquet.
Avro lepiej radzi sobie z ewolucją schematów. Parquet obsługuje jedynie dodawanie schematu, podczas gdy Avro posiada wielofunkcyjną ewolucję, co oznacza dodawanie lub zmianę kolumn.
Parquet jest idealny do zapytań o podzestaw kolumn w tabeli z wieloma kolumnami. Avro sprawdza się w operacjach ETL, gdzie żądamy wszystkich kolumn.