Файлови формати в големи данни: кратка образователна програма

Божество на времето от Remarin

Отбор Облачни решения на Mail.ru оферти превод на статия инженер Rahul Bhatia от Clairvoyant за това какви файлови формати има в големите данни, какви са най-често срещаните характеристики на Hadoop форматите и кой формат е по-добре да се използва.

Защо са необходими различни файлови формати?

Основно затруднение в производителността за HDFS-активирани приложения като MapReduce и Spark е времето, необходимо за търсене, четене и запис на данни. Тези проблеми се усложняват от трудността при управлението на големи набори от данни, ако имаме развиваща се схема, а не фиксирана, или ако има някои ограничения за съхранение.

Обработката на големи данни увеличава натоварването на подсистемата за съхранение - Hadoop съхранява данни излишно, за да постигне толерантност към грешки. Освен дискове се зареждат процесор, мрежа, входно/изходна система и т.н. С нарастването на обема на данните нарастват и разходите за тяхната обработка и съхранение.

Различни файлови формати в Hadoop изобретен за решаване точно на тези проблеми. Избирането на подходящ файлов формат може да осигури някои значителни предимства:

1. По-бързо време за четене.
2. По-бързо време за запис.
3. Споделени файлове.
4. Поддръжка за развитие на схемата.
5. Разширена поддръжка за компресиране.

Някои файлови формати са предназначени за обща употреба, други за по-специфични цели, а някои са проектирани да отговарят на специфични характеристики на данните. Така че изборът наистина е доста голям.

Avro файлов формат

За сериализация на данни Avro се използва широко - то базирани на низове, тоест формат за съхранение на низови данни в Hadoop. Той съхранява схемата във формат JSON, което я прави лесна за четене и интерпретиране от всяка програма. Самите данни са в двоичен формат, компактни и ефективни.

Системата за сериализация на Avro е езиково неутрална. Файловете могат да се обработват на различни езици, в момента C, C++, C#, Java, Python и Ruby.

Ключова характеристика на Avro е стабилната му поддръжка за схеми на данни, които се променят с времето, т.е. Avro разбира промените в схемата - изтриване, добавяне или промяна на полета.

Avro поддържа различни структури от данни. Например, можете да създадете запис, който съдържа масив, изброен тип и подзапис.

Този формат е идеален за запис в зоната за кацане (преход) на езеро с данни (езеро с данни, или езеро от данни - колекция от екземпляри за съхраняване на различни типове данни в допълнение към източниците на данни директно).

Така че този формат е най-подходящ за запис в зоната за кацане на езеро с данни поради следните причини:

1. Данните от тази зона обикновено се четат изцяло за по-нататъшна обработка от системи надолу по веригата - и базираният на ред формат е по-ефективен в този случай.
2. Системите надолу по веригата могат лесно да извличат таблици със схеми от файлове – няма нужда да съхранявате схеми отделно във външно мета хранилище.
3. Всяка промяна в оригиналната схема се обработва лесно (еволюция на схемата).

Формат на файл за паркет

Parquet е файлов формат с отворен код за Hadoop, който съхранява вложени структури от данни в плосък колонен формат.

В сравнение с традиционния редов подход, Parquet е по-ефективен по отношение на съхранение и производителност.

Това е особено полезно за заявки, които четат конкретни колони от широка (много колони) таблица. Благодарение на файловия формат се четат само необходимите колони, така че I/O е сведен до минимум.

Малко отклонение и пояснение: За да разберем по-добре файловия формат Parquet в Hadoop, нека да видим какво е базиран на колони – т.е. колонен – формат. Този формат съхранява подобни стойности за всяка колона заедно.

Например, записът включва полетата ID, Име и Отдел. В този случай всички стойности на колоната ID ще бъдат съхранени заедно, както и стойностите на колоната Name и т.н. Таблицата ще изглежда така:

ID
Име
отдел

1
emp1
d1

2
emp2
d2

3
emp3
d3

В низов формат данните ще бъдат записани, както следва:

1
emp1
d1
2
emp2
d2
3
emp3
d3

В колонен файлов формат същите данни ще бъдат записани по следния начин:

1
2
3
emp1
emp2
emp3
d1
d2
d3

Колонният формат е по-ефективен, когато трябва да направите заявка за множество колони от таблица. Той ще прочете само необходимите колони, защото те са съседни. По този начин I/O операциите са сведени до минимум.

Например, имате нужда само от колоната NAME. IN формат на низ Всеки запис в набора от данни трябва да бъде зареден, анализиран по поле и след това извлечени данните NAME. Форматът на колоната ви позволява да преминете директно към колоната Име, тъй като всички стойности за тази колона се съхраняват заедно. Не е нужно да сканирате целия запис.

По този начин колонният формат подобрява производителността на заявките, тъй като изисква по-малко време за търсене, за да стигне до необходимите колони, и намалява броя на I/O операциите, тъй като се четат само желаните колони.

Една от уникалните характеристики Паркет е, че в този формат може съхранява данни с вложени структури. Това означава, че във файл Parquet дори вложените полета могат да се четат поотделно, без да се налага да четете всички полета във вложената структура. Parquet използва алгоритъм за раздробяване и сглобяване за съхраняване на вложени структури.

За да разберете файловия формат Parquet в Hadoop, трябва да знаете следните термини:

1. Група низове (група редове): логическо хоризонтално разделяне на данните в редове. Група редове се състои от фрагмент от всяка колона в набора от данни.
2. Фрагмент от колона (част от колона): фрагмент от конкретна колона. Тези фрагменти от колони живеят в определена група редове и е гарантирано, че са съседни във файла.
3. Page (страница): Фрагментите от колони са разделени на страници, написани една след друга. Страниците имат общо заглавие, така че можете да пропускате ненужните при четене.

Тук заглавието съдържа само магическото число PAR1 (4 байта), което идентифицира файла като файл на Parquet.

Долният колонтитул казва следното:

1. Файлови метаданни, които съдържат началните координати на метаданните на всяка колона. Когато четете, първо трябва да прочетете метаданните на файла, за да намерите всички интересни фрагменти от колони. След това частите от колоната трябва да се прочетат последователно. Другите метаданни включват версията на формата, схемата и всички допълнителни двойки ключ-стойност.
2. Дължина на метаданните (4 байта).
3. магическо число PAR1 (4 байта).

ORC файлов формат

Оптимизиран файлов формат ред-колона (Оптимизирана колона на ред, CRO) предлага много ефективен начин за съхраняване на данни и е проектиран да преодолее ограниченията на други формати. Съхранява данните в съвършено компактна форма, което ви позволява да пропускате ненужните подробности - без да се налага изграждането на големи, сложни или ръчно поддържани индекси.

Предимства на ORC формата:

1. Един файл е изходът на всяка задача, което намалява натоварването на NameNode (именен възел).
2. Поддръжка за типове данни Hive, включително DateTime, десетични и сложни типове данни (структура, списък, карта и обединение).
3. Едновременно четене на един и същ файл от различни процеси на RecordReader.
4. Възможност за разделяне на файлове без сканиране за маркери.
5. Оценка на максимално възможното разпределение на паметта за четене/запис въз основа на информацията в долния колонтитул на файла.
6. Метаданните се съхраняват във формат за двоична сериализация на буферите на протокола, който позволява добавяне и премахване на полета.

ORC съхранява колекции от низове в един файл, а в колекцията данните за низове се съхраняват в колонен формат.

ORC файл съхранява групи от редове, наречени ивици, и поддържаща информация в долния колонтитул на файла. Postscript в края на файла съдържа параметри за компресиране и размера на компресирания долен колонтитул.

Размерът на лентата по подразбиране е 250 MB. Поради такива големи ивици, четенето от HDFS се извършва по-ефективно: в големи съседни блокове.

Долният колонтитул на файла записва списъка с ленти във файла, броя на редовете на лента и типа данни на всяка колона. Получената стойност на броя, мин., макс. и сумата за всяка колона също е записана там.

Долният колонтитул на лентата съдържа директория с местоположения на потоци.

Данните от редове се използват при сканиране на таблици.

Индексните данни включват минималните и максималните стойности за всяка колона и позицията на редовете във всяка колона. ORC индексите се използват само за избиране на ивици и групи редове, а не за отговаряне на заявки.

Сравнение на различни файлови формати

Авро в сравнение с Паркет

1. Avro е формат за съхранение на редове, докато Parquet съхранява данни в колони.
2. Parquet е по-подходящ за аналитични заявки, което означава, че операциите за четене и заявките за данни са много по-ефективни от записите.
3. Операциите за запис в Avro се извършват по-ефективно, отколкото в Parquet.
4. Avro се занимава с еволюцията на веригите по-зряло. Parquet поддържа само добавяне на схема, докато Avro поддържа многофункционална еволюция, тоест добавяне или промяна на колони.
5. Parquet е идеален за запитване към подмножество от колони в таблица с няколко колони. Avro е подходящ за ETL операции, където правим заявки за всички колони.

ORC срещу Паркет

1. Parquet съхранява по-добре вложените данни.
2. ORC е по-подходящ за натискане на предикат.
3. ORC поддържа ACID свойства.
4. ORC компресира данните по-добре.

Какво още да прочетете по темата:

1. Анализ на големи данни в облака: как една компания може да стане ориентирана към данни.
2. Скромно ръководство за схеми на бази данни.
3. Нашият телеграм канал за дигиталната трансформация.

Източник: www.habr.com