Команда пропонує інженера Рахула Бхатії з компанії Clairvoyant про те, які формати файлів у великих даних, які найпоширеніші функції форматів Hadoop і який формат краще використовувати.
Навіщо потрібні різні формати файлів
Серйозне вузьке місце у продуктивності програм із підтримкою HDFS, таких як MapReduce та Spark – час пошуку, читання, а також запису даних. Ці проблеми посилюються труднощами в управлінні великими наборами даних, якщо ми не фіксована, а еволюціонуюча схема, чи є певні обмеження для зберігання.
Обробка великих даних збільшує навантаження на підсистему зберігання Hadoop зберігає дані надмірно для досягнення відмовостійкості. Крім дисків, навантажуються процесор, мережа, система вводу-виводу тощо. У міру зростання обсягу даних збільшується і вартість їхньої обробки та зберігання.
Різні формати файлів у вигадані для вирішення саме цих проблем. Вибір відповідного формату файлу може дати деякі істотні переваги:
- Швидший час читання.
- Найшвидший час запису.
- Файли, що розділяються.
- Підтримка еволюції схем.
- Розширена підтримка стискування.
Одні формати файлів призначені для загального використання, інші для більш специфічних варіантів, деякі розроблені з урахуванням конкретних характеристик даних. Тож вибір справді досить великий.
Формат файлів Avro
Для серіалізації даних широко використовують Avro - це заснований на рядках, тобто рядковий формат зберігання даних в Hadoop. Він зберігає схему у форматі JSON, полегшуючи її читання та інтерпретацію будь-якою програмою. Самі дані лежать у двійковому форматі, компактно та ефективно.
Система серіалізації Avro є нейтральною до мови. Файли можна обробляти різними мовами, зараз це C, C++, C#, Java, Python і Ruby.
Ключовою особливістю Avro є надійна підтримка схем даних, що змінюються з часом, тобто еволюціонують. Avro розуміє зміни схеми – видалення, додавання чи зміна полів.
Avro підтримує різноманітні структури даних. Наприклад, можна створити запис, який містить масив, тип і підзапис.
Цей формат ідеально підходить для запису в посадкову (перехідну) зону озера даних (, або data lake - колекція інстансів для зберігання різних типів даних (доповнення безпосередньо до джерел даних).
Так ось, для запису в посадкову зону озера даних такий формат найкраще підходить з таких причин:
- Дані з цієї зони зазвичай зчитуються повністю для подальшої обробки нижчими системами - і формат на основі рядків у цьому випадку ефективніший.
- Нижчі системи можуть легко витягувати таблиці схем із файлів — не потрібно зберігати схеми окремо в зовнішньому сховищі.
- Будь-яка зміна вихідної схеми легко обробляється (еволюція схеми).
Формат файлів Parquet
Parquet – опенсорсний формат файлів для Hadoop, який зберігає вкладені структури даних у плоскому стовпчастому форматі.
У порівнянні з традиційним малим підходом, Parquet більш ефективний з точки зору зберігання та продуктивності.
Це особливо корисно для запитів, які зчитують певні стовпці із широкої (з багатьма стовпцями) таблиці. Завдяки формату файлів читаються лише необхідні стовпці, тому введення-виведення зводиться до мінімуму.
Невеликий відступ-пояснення: щоб краще зрозуміти формат файлу Parquet в Hadoop, давайте подивимося, що таке заснований на стовпцях - тобто стовпчастий - формат. У такому форматі зберігаються однотипні значення кожного стовпця.
, запис включає поля ID, Name та Department. У цьому випадку всі значення стовпця 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
Стовпчастий формат ефективніший, коли вам потрібно запросити з таблиці кілька стовпців. Він прочитає лише необхідні стовпці, бо вони перебувають по сусідству. Таким чином, операції введення-виведення зводяться до мінімуму.
Наприклад, вам потрібний лише стовпець NAME. У кожен запис у наборі даних потрібно завантажити, розібрати по полях, а потім витягти дані NAME. Стовпчастий формат дозволяє перейти безпосередньо до стовпця Name, оскільки всі значення цього стовпця зберігаються разом. Не доведеться сканувати весь запис.
Таким чином, стовпчастий формат підвищує продуктивність запитів, оскільки для переходу до необхідних стовпців потрібно менше часу пошуку та скорочується кількість операцій вводу-виводу, адже відбувається читання лише потрібних стовпців.
Одна з унікальних особливостей полягає в тому, що в такому форматі він може зберігати дані із вкладеними структурами. Це означає, що у файлі Parquet навіть вкладені поля можна читати окремо без необхідності читати всі поля у вкладеній структурі. Для зберігання вкладених структур Parquet використовує алгоритм подрібнення та складання (shredding and assembly).
Щоб зрозуміти формат файлу Parquet у Hadoop, необхідно знати такі терміни:
- Група рядків (row group): логічне горизонтальне розбиття даних на рядки. Група рядків складається з фрагмента кожного стовпця у наборі даних.
- Фрагмент стовпця (column chunk): фрагмент конкретного стовпця. Ці фрагменти шпальт живуть у певній групі рядків і гарантовано будуть суміжними у файлі.
- Сторінка (page): фрагменти стовпців поділяються на сторінки, записані один за одним. Сторінки мають загальний заголовок, так що при читанні можна пропустити непотрібні.
Тут заголовок просто містить чарівне число PAR1 (4 байти), що ідентифікує файл як файл формату Parquet.
У футері записано таке:
- Метадані файлу, які містять стартові координати метаданих кожного стовпця. При читанні потрібно спочатку прочитати метадані файлу, щоб знайти всі фрагменти стовпців, що цікавлять. Потім фрагменти шпальт слід читати послідовно. Ще метадані включають версію формату, схему та будь-які додаткові пари ключ-значення.
- Довжина метаданих (4 байти).
- Чарівне число PAR1 (4 байти).
Формат файлів ORC
Оптимізований строково-стовпчастий формат файлів (Optimized Row Columnar, ) пропонує дуже ефективний спосіб зберігання даних і був розроблений, щоб подолати обмеження інших форматів. Зберігає дані в ідеально компактному вигляді, дозволяючи пропускати непотрібні деталі - при цьому не вимагає побудови великих, складних або обслуговуваних вручну індексів.
Переваги формату ORC:
- Один файл на виході кожного завдання, що зменшує навантаження на NameNode (вузол імен).
- Підтримка типів даних Hive, включаючи DateTime, десяткові та складні типи даних (struct, list, map та union).
- Одночасне зчитування того самого файлу різними процесами RecordReader.
- Можливість поділу файлів без сканування на наявність маркерів.
- Оцінка максимально можливого виділення пам'яті купи на процеси читання/запису за інформацією футері файлу.
- Метадані зберігаються у бінарному форматі серіалізації Protocol Buffers, який дозволяє додавати та видаляти поля.
ORC зберігає колекції рядків в одному файлі, а всередині колекції малі дані зберігаються в стовпчастому форматі.
Файл ORC зберігає групи рядків, які називаються смугами (stripes) та допоміжну інформацію у футері файлу. Postscript в кінці файлу містить параметри стиснення та розмір стисненого футера.
За замовчуванням розмір лінії становить 250 МБ. За рахунок смуг такого великого розміру читання HDFS виконується більш ефективно: великими безперервними блоками.
У футері файлу записано список смуг у файлі, кількість рядків на смугу та тип даних кожного стовпця. Там же записано результуюче значення count, min, max та sum по кожному стовпцю.
Футер смуги містить каталог розташування потоку.
Рядкові дані використовуються під час сканування таблиць.
Індексні дані включають мінімальні та максимальні значення для кожного стовпця та позиції рядків у кожному стовпці. Індекси ORC використовуються лише для вибору смуг та груп рядків, а не для відповіді на запити.
Порівняння різних форматів файлів
Avro у порівнянні з Parquet
- Avro - формат зберігання по рядках, тоді як Parquet зберігає дані по стовпчикам.
- Parquet краще підходить для аналітичних запитів, тобто операції читання та запит даних набагато ефективніші, ніж запис.
- Операції запису в Avro виконуються ефективніше, ніж у Parquet.
- Avro зріло працює з еволюцією схем. Parquet підтримує лише додавання схеми, а в Avro реалізована багатофункціональна еволюція, тобто додавання чи зміна стовпців.
- Parquet ідеально підходить для запиту підмножини стовпців у багатоколонній таблиці. Avro підходить для операцій ETL, де ми запитуємо усі стовпці.
ORC у порівнянні з Parquet
- Parquet краще зберігає вкладені дані.
- ORC краще пристосований до проштовхування предикатів (predicate pushdown).
- ORC підтримує властивості ACID.
- ORC краще стискає дані.
Що ще почитати на тему:
- .
- .
- .
Джерело: habr.com