Демистификация форматов данных Hadoop: Avro, ORC и Parquet

Инженерия данных 101

Демистификация форматов данных Hadoop: Avro, ORC и Parquet

Основные концепции и варианты использования трех форматов данных, широко используемых в Hadoop: Avro, ORC и Parquet.

Если вы работаете с Hadoop, вы, вероятно, столкнетесь с ситуациями, когда вам нужно выбрать правильный формат для ваших данных. В этом сообщении блога я расскажу об основных концепциях и вариантах использования трех форматов данных, широко используемых в Hadoop: Avro, ORC и Parquet.

Что такое Avro / ORC / Parquet?

Avro - это строковый формат данных косая черта, система сериализации данных, выпущенная рабочей группой Hadoop в 2009 году. Схема данных хранится как JSON (что означает удобочитаемость) в заголовке, в то время как остальные данные хранятся в двоичном формате. Одним из ярких моментов Avro является его надежная поддержка эволюции схемы.

ORC - это строковый столбчатый формат данных, оптимизированный для чтения, записи и обработки данных в Hive, он был создан Hortonworks в 2013 году в рамках инициативы Stinger по ускорению Hive. Файлы ORC состоят из полос данных, где каждая полоса содержит индекс, данные строки и нижний колонтитул (где удобно кэшируются ключевые статистические данные, такие как количество, максимальное, минимальное и сумма каждого столбца).

Parquet - это формат столбцовых данных строк, созданный Cloudera и Twitter в 2013 году. Файлы Parquet состоят из групп строк, верхнего и нижнего колонтитула, и в каждой группе строк данные в одних и тех же столбцах хранятся вместе. Parquet специализируется на эффективном хранении и обработке вложенных типов данных.

На что следует обратить внимание

Интенсивное чтение / запись и шаблон запроса. Строковые форматы данных в целом лучше подходят для хранения данных с интенсивным использованием записи, поскольку добавлять новые записи проще. Если будет часто запрашиваться только небольшое подмножество столбцов, столбцовые форматы будут вашими хорошими друзьями, поскольку будут доступны и переданы только те необходимые столбцы (тогда как форматы строк должны вытягивать все столбцы).

Сжатие. Сжатие является одним из ключевых аспектов, которые следует здесь учитывать, поскольку сжатие помогает сократить ресурсы, необходимые для хранения и передачи данных. Особенно когда вы получаете огромный объем данных (например, данные IoT), вам нужно хорошее сжатие. Столбцовые форматы лучше, чем строковые, с точки зрения сжатия, потому что хранение одного и того же типа значений вместе позволяет более эффективное сжатие. Чтобы быть конкретным, для каждого столбца используется другое и более эффективное кодирование. Вот почему столбчатые форматы хороши для разреженных наборов данных! ORC имеет лучшую степень сжатия из всех трех благодаря полосам.

Развитие схемы. Одной из проблем при работе с большими данными является частое изменение схемы данных: например, добавление / удаление столбцов и изменение имен столбцов. Если ваша схема данных сильно меняется и вам нужна высокая совместимость для ваших старых / новых приложений, Avro здесь для вас. Кроме того, схема данных Avro находится в формате JSON, и Avro может сохранять данные компактными, даже если существует множество различных схем.

Вложенные столбцы. Если у вас много сложных вложенных столбцов в наборе данных и вы часто запрашиваете только подмножество вложенных столбцов, Parquet будет хорошим выбором. Parquet реализован с использованием алгоритма измельчения и сборки записей, описанного в статье Dremel, который позволяет вам получать доступ и извлекать подколонки, не вытягивая оставшуюся часть вложенного столбца.

Поддержка платформы. И последнее, но не менее важное: при выборе формата данных вы должны учитывать платформу / структуру, которые вы используете, поскольку форматы данных работают по-разному в зависимости от того, где они используются. ORC лучше всего работает с Hive (поскольку он создан для Hive). Spark предоставляет отличную поддержку для обработки форматов паркета. Avro часто оказывается хорошим выбором для Kafka.

Ссылки

• Официальный документ Nexla: Введение в форматы больших данных

Хотите узнать больше о Data Engineering? Посмотрите мою колонку Инженерия данных 101 в статье На пути к науке о данных: