Formaty plików w big data: krótki program edukacyjny

Bóstwo pogody autorstwa Remarina

Zespół Rozwiązania chmurowe Mail.ru oferuje tłumaczenie artykułu inżynier Rahul Bhatia z Clairvoyant o tym, jakie formaty plików występują w dużych zbiorach danych, jakie są najczęstsze cechy formatów Hadoop i jakiego formatu lepiej używać.

Dlaczego potrzebne są różne formaty plików?

Głównym wąskim gardłem wydajności aplikacji obsługujących HDFS, takich jak MapReduce i Spark, jest czas potrzebny na wyszukiwanie, odczytywanie i zapisywanie danych. Problemy te potęgują trudności w zarządzaniu dużymi zbiorami danych, jeśli mamy schemat ewoluujący, a nie stały, lub jeśli istnieją pewne ograniczenia dotyczące przechowywania.

Przetwarzanie dużych zbiorów danych zwiększa obciążenie podsystemu pamięci masowej – Hadoop przechowuje dane redundantnie, aby zapewnić odporność na awarie. Oprócz dysków ładowany jest procesor, sieć, system wejścia/wyjścia i tak dalej. Wraz ze wzrostem ilości danych rosną koszty ich przetwarzania i przechowywania.

Różne formaty plików w Hadoop wynaleziono, aby rozwiązać dokładnie te problemy. Wybór odpowiedniego formatu pliku może zapewnić kilka znaczących korzyści:

1. Szybszy czas czytania.
2. Szybszy czas nagrywania.
3. Udostępnione pliki.
4. Wsparcie ewolucji schematu.
5. Rozszerzona obsługa kompresji.

Niektóre formaty plików są przeznaczone do użytku ogólnego, inne do bardziej specyficznych zastosowań, a niektóre są zaprojektowane tak, aby spełniać określone cechy danych. Wybór jest więc naprawdę spory.

Format pliku Avro

dla serializacja danych Avro jest szeroko stosowane - to oparty na ciągach, czyli format przechowywania danych w postaci ciągów w Hadoop. Przechowuje schemat w formacie JSON, dzięki czemu jest łatwy do odczytania i interpretacji przez dowolny program. Same dane są w formacie binarnym, kompaktowe i wydajne.

System serializacji Avro jest neutralny językowo. Pliki można przetwarzać w różnych językach, obecnie C, C++, C#, Java, Python i Ruby.

Kluczową cechą Avro jest solidna obsługa schematów danych, które zmieniają się w czasie, to znaczy ewoluują. Avro rozumie zmiany schematu — usuwanie, dodawanie lub zmianę pól.

Avro obsługuje różnorodne struktury danych. Można na przykład utworzyć rekord zawierający tablicę, typ wyliczeniowy i podrekord.

Ten format jest idealny do zapisywania w strefie docelowej (przejściowej) jeziora danych (jezioro danychlub jezioro danych - zbiór instancji do przechowywania różnych typów danych oprócz bezpośrednich źródeł danych).

Dlatego ten format najlepiej nadaje się do zapisywania w strefie docelowej jeziora danych z następujących powodów:

1. Dane z tej strefy są zwykle odczytywane w całości w celu dalszego przetwarzania przez kolejne systemy – w tym przypadku format oparty na wierszach jest bardziej efektywny.
2. Systemy niższego szczebla mogą z łatwością pobierać tabele schematów z plików — nie ma potrzeby oddzielnego przechowywania schematów w zewnętrznej meta pamięci.
3. Wszelkie zmiany w oryginalnym schemacie są łatwo przetwarzane (ewolucja schematu).

Format pliku parkietu

Parquet to format pliku typu open source dla platformy Hadoop, w którym przechowywane są pliki zagnieżdżone struktury danych w płaskim formacie kolumnowym.

W porównaniu z tradycyjnym podejściem rzędowym, Parquet jest bardziej wydajny pod względem przechowywania i wydajności.

Jest to szczególnie przydatne w przypadku zapytań, które odczytują określone kolumny z szerokiej (wiele kolumn) tabeli. Dzięki formatowi pliku odczytywane są tylko niezbędne kolumny, więc liczba wejść/wyjść jest ograniczona do minimum.

Mała dygresja i wyjaśnienie: Aby lepiej zrozumieć format pliku Parquet w Hadoop, zobaczmy, czym jest format kolumnowy, czyli kolumnowy. Ten format przechowuje podobne wartości dla każdej kolumny razem.

na przykładrekord zawiera pola Identyfikator, Nazwisko i Dział. W takim przypadku wszystkie wartości kolumny ID będą przechowywane razem, podobnie jak wartości kolumny Nazwa i tak dalej. Tabela będzie wyglądać mniej więcej tak:

ID
Imię
Departament

1
emp1
d1

2
emp2
d2

3
emp3
d3

W formacie string dane zostaną zapisane w następujący sposób:

1
emp1
d1
2
emp2
d2
3
emp3
d3

W formacie pliku kolumnowego te same dane zostaną zapisane w następujący sposób:

1
2
3
emp1
emp2
emp3
d1
d2
d3

Format kolumnowy jest bardziej wydajny, gdy trzeba wykonać zapytanie dotyczące wielu kolumn z tabeli. Będzie czytać tylko wymagane kolumny, ponieważ sąsiadują ze sobą. W ten sposób operacje we/wy są ograniczone do minimum.

Na przykład potrzebujesz tylko kolumny NAZWA. W formacie string Każdy rekord w zestawie danych należy załadować, przeanalizować według pola, a następnie wyodrębnić dane NAZWA. Format kolumny umożliwia drążenie bezpośrednio do kolumny Nazwa, ponieważ wszystkie wartości dla tej kolumny są przechowywane razem. Nie musisz skanować całego nagrania.

Zatem format kolumnowy poprawia wydajność zapytań, ponieważ wymaga mniej czasu wyszukiwania, aby dotrzeć do wymaganych kolumn i zmniejsza liczbę operacji we/wy, ponieważ odczytywane są tylko żądane kolumny.

Jedna z unikalnych cech Parkiet jest to, że w tym formacie jest to możliwe przechowuj dane za pomocą zagnieżdżonych struktur. Oznacza to, że w pliku Parquet nawet zagnieżdżone pola można czytać pojedynczo, bez konieczności czytania wszystkich pól w zagnieżdżonej strukturze. Parkiet wykorzystuje algorytm rozdrabniania i montażu do przechowywania zagnieżdżonych struktur.

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

1. Grupa ciągów (grupa wierszy): logiczny poziomy podział danych na wiersze. Grupa wierszy składa się z fragmentu każdej kolumny w zestawie danych.
2. Fragment kolumny (fragment kolumny): Fragment określonej kolumny. Te fragmenty kolumn znajdują się w określonej grupie wierszy i na pewno będą sąsiadować ze sobą w pliku.
3. Strona (strona): Fragmenty kolumn podzielone są na strony pisane jedna po drugiej. Strony mają wspólny tytuł, dzięki czemu podczas czytania można pominąć niepotrzebne.

Tutaj tytuł zawiera tylko magiczną liczbę PAR1 (4 bajty), który identyfikuje plik jako plik Parquet.

W stopce jest napisane co następuje:

1. Metadane pliku zawierające współrzędne początkowe metadanych każdej kolumny. Podczas czytania musisz najpierw przeczytać metadane pliku, aby znaleźć wszystkie interesujące fragmenty kolumn. Następnie należy czytać fragmenty kolumn po kolei. Inne metadane obejmują wersję formatu, schemat i wszelkie dodatkowe pary klucz-wartość.
2. Długość metadanych (4 bajty).
3. magiczny numer PAR1 (4 bajty).

Format pliku ORC

Zoptymalizowany format pliku wiersz-kolumna (Zoptymalizowana kolumna wiersza, ORC) oferuje bardzo wydajny sposób przechowywania danych i został zaprojektowany w celu przezwyciężenia ograniczeń innych formatów. Przechowuje dane w idealnie zwartej formie, pozwalając na pominięcie niepotrzebnych szczegółów – bez konieczności budowania dużych, skomplikowanych lub ręcznie utrzymywanych indeksów.

Zalety formatu ORC:

1. Jeden plik jest wynikiem każdego zadania, co zmniejsza obciążenie NameNode (węzła nazwy).
2. Obsługa typów danych Hive, w tym DateTime, dziesiętnych i złożonych typów danych (struktura, lista, mapa i Unia).
3. Jednoczesny odczyt tego samego pliku przez różne procesy RecordReadera.
4. Możliwość dzielenia plików bez skanowania w poszukiwaniu znaczników.
5. Oszacowanie maksymalnej możliwej alokacji pamięci sterty dla procesów odczytu/zapisu na podstawie informacji zawartych w stopce pliku.
6. Metadane są przechowywane w binarnym formacie serializacji Protocol Buffers, który umożliwia dodawanie i usuwanie pól.

ORC przechowuje kolekcje ciągów w jednym pliku, a w obrębie kolekcji dane ciągów są przechowywane w formacie kolumnowym.

Plik ORC przechowuje grupy linii zwane paskami i informacje pomocnicze w stopce pliku. Postscript na końcu pliku zawiera parametry kompresji i rozmiar skompresowanej stopki.

Domyślny rozmiar paska to 250 MB. Dzięki tak dużym paskom odczyt z HDFS odbywa się wydajniej: w dużych, sąsiadujących ze sobą blokach.

W stopce pliku zapisana jest lista torów w pliku, liczba wierszy na tor oraz typ danych w każdej kolumnie. Zapisuje się tam również wynikową wartość licznika, min, max i sumy dla każdej kolumny.

W stopce paska znajduje się katalog lokalizacji strumieni.

Dane wierszy są używane podczas skanowania tabel.

Dane indeksowe obejmują wartości minimalne i maksymalne dla każdej kolumny oraz położenie wierszy w każdej kolumnie. Indeksy ORC służą wyłącznie do wybierania pasków i grup wierszy, a nie do odpowiadania na zapytania.

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

Avro w porównaniu do Parkietu

1. Avro to format przechowywania wierszy, podczas gdy Parquet przechowuje dane w kolumnach.
2. Parkiet lepiej nadaje się do zapytań analitycznych, co oznacza, że ​​operacje odczytu i wysyłania zapytań do danych są znacznie wydajniejsze niż zapisy.
3. Operacje zapisu w Avro są wykonywane wydajniej niż w Parquet.
4. Avro dojrzalej radzi sobie z ewolucją obwodów. Parquet obsługuje tylko dodawanie schematów, podczas gdy Avro obsługuje ewolucję wielofunkcyjną, czyli dodawanie lub zmianę kolumn.
5. Parkiet idealnie nadaje się do wykonywania zapytań dotyczących podzbioru kolumn w tabeli wielokolumnowej. Avro nadaje się do operacji ETL, w których odpytujemy wszystkie kolumny.

ORC kontra parkiet

1. Parkiet lepiej przechowuje zagnieżdżone dane.
2. ORC lepiej nadaje się do predykowania przesuwania w dół.
3. ORC obsługuje właściwości ACID.
4. ORC lepiej kompresuje dane.

Co jeszcze przeczytać na ten temat:

1. Analiza Big Data w chmurze: jak firma może zorientować się na dane.
2. Skromny przewodnik po schematach baz danych.
3. Nasz kanał telegramowy na temat transformacji cyfrowej.

Źródło: www.habr.com