Чем открыть паркет файл

Русские Блоги

Чтение и запись файла Parquet и объединение небольших файлов Parquet

содержание

1. Введение

Сначала сделаем снимок официального сайта, который может помочь нам лучше понять формат файла и содержимое Parquet.

Конструкция паркета позволяет ему иметь лучшую степень сжатия и более высокую скорость фильтрации.

Один файл имеет несколько групп строк
Группа строк состоит из нескольких столбцов
В одном столбце несколько страниц

FileMetaData\Row Group metadata\column metadata

Два, схема (MessageType)

Каждая схема имеет корень с именем message, который содержит несколько полей.

Каждое поле содержит три атрибута:
repetition, type, name

Повторение бывает трех видов:

Тип может быть: int32, int64, int96, float, double, boolean, binary, group.

Остальные, кроме группы, называются примитивными типами.Группа объединяет примитивные типы.

Три, получение MessageType

3.1 Построить из строки

3.2 Создание из кода

3.3 Получить через Parquet-файл

Помимо получения через метаданные, вы также можете получить через файлы или с помощью следующих методов

Не забудьте закрыть его после прочтения схемы, в противном случае может возникнуть ошибка java.net.SocketException: слишком много открытых файлов.

3.4 Полный пример

Четыре, паркет читать и писать

4.1 Чтение и запись локальных файлов

4.2 Чтение и запись файлов HDFS

Второй параметр 0 в group.getString («bookName», 0) подготовлен для повторяемого поля (повторяется), чтобы получить количество значений, начиная с 0, поэтому, соответствующие требуемому типу, все равны 0.

Пять, объедините небольшие файлы Parquet

Объединение файлов Parquet должно быть очень практичной операцией, потому что много раз, когда мы используем систему сообщений, такую ​​как Kafka, для сбора данных, может быть сгенерировано много небольших файлов.

Слишком много маленьких файлов замедлит работу приложения, поэтому нам нужно объединить небольшие файлы.

Вышеупомянутое сначала проверит, согласована ли схема паркета в каталоге, а затем объединится.

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

Источник

Как использовать Parquet и не поскользнуться

О хранении данных в Parquet-файлах не так много информации на Хабре, поэтому надеемся, рассказ об опыте Wrike по его внедрению в связке со Spark вам пригодится.
В частности, в этой статье вы узнаете:

— зачем нужен “паркет”;
— как он устроен;
— когда стоит его использовать;
— в каких случаях он не очень удобен.

Наверное, стоит начать с вопроса, зачем мы вообще начали искать новый способ хранения данных вместо предварительной агрегации и сохранения результата в БД и какими критериями руководствовались при принятии решения?

В отделе аналитики Wrike мы используем Apache Spark, масштабируемый и набирающий популярность инструмент для работы с большими данным (у нас это разнообразные логи и иные потоки входящих данных и событий). Подробнее о том, как у нас работает Spark, мы рассказывали ранее.

Изначально нам хотелось развернуть систему быстро и без особых инфраструктурных изощрений, поэтому мы решили ограничиться Standalone кластер-менеджером Спарка и текстовыми файлами, в которые записывали Json. На тот момент у нас не было большого входного потока данных, так что развёртывать hadoop и т.п. не было смысла.

После нескольких недель работы мы поняли, что с json данными работать неудобно и трудоемко: медленное чтение, к тому же при многочисленных тестовых запросов каждый раз Spark вынужден сначала прочесть файл, определить схему и только потом подобраться непосредственно к выполнению самого запроса. Конечно, путь Спарку можно сократить, заранее указав схему, но каждый раз проделывать эту дополнительную работу нам не хотелось.
Покопавшись в Спарке, мы обнаружили, что сам он активно использует у себя внутри parquet-формат.

Что такое Parquet

Parquet — это бинарный, колоночно-ориентированный формат хранения данных, изначально созданный для экосистемы hadoop. Разработчики уверяют, что данный формат хранения идеален для big data (неизменяемых).
Первое впечатление — ура, со Spark наконец-то стало удобно работать, он просто ожил, но, как ни странно, подкинул нам несколько неожиданных проблем. Дело в том, что parquet ведёт себя как неизменяемая таблица или БД. Значит для колонок определён тип, и если вдруг у вас комбинируется сложный тип данных (скажем, вложенный json) с простым (обычное строковое значение), то вся система разрушится. Например, возьмём два события и напишем их в формате Json:
<
“event_name”: “event 1”,
“value”: “this is first value”,
>

В parquet-файл записать их не получится, так как в первом случае у вас строка, а во втором сложный тип. Хуже, если система записывает входной поток данных в файл, скажем, каждый час. В первый час могут прийти события со строковыми value, а во второй — в виде сложного типа. В итоге, конечно, получится записать parquet файлы, но при операции merge schema вы наткнётесь на ошибку несовместимости типов.

Чтобы решить эту проблему, нам пришлось пойти на небольшой компромисс. Мы определили точно известную и гарантируемую поставщиком данных схему для части информации, а в остальном брали только верхнеуровневые ключи. При этом сами данные записывали как текст (зачастую это был json), который мы хранили в ячейке (в дальнейшем с помощью простых map-reduce операций это превращалось в удобный DataFrame) в случае примера выше ‘ “value”: <“reason”: “Ok”>‘ превращается в ‘ “value”: “<\”reason\”: \”Ok\”>” ‘. Также мы столкнулись с некоторыми особенностями разбиения данных на части Спарком.

Как выглядит структура Parquet файлов

Parquet является довольно сложным форматом по сравнению с тем же текстовым файлом с json внутри.
Примечательно, что свои корни этот формат пустил даже в разработки Google, а именно в их проект под названием Dremel — об этом уже упоминалось на Хабре, но мы не будем углубляться в дебри Dremel, желающие могут прочитать об этом тут: research.google.com/pubs/pub36632.html.

Если коротко, Parquet использует архитектуру, основанную на “уровнях определения” (definition levels) и “уровнях повторения” (repetition levels), что позволяет довольно эффективно кодировать данные, а информация о схеме выносится в отдельные метаданные.
При этом оптимально хранятся и пустые значения.

Структура Parquet-файла хорошо проиллюстрирована в документации:

Файлы имеют несколько уровней разбиения на части, благодаря чему возможно довольно эффективное параллельное исполнение операций поверх них:

Row-group — это разбиение, позволяющее параллельно работать с данными на уровне Map-Reduce
Column chunk — разбиение на уровне колонок, позволяющее распределять IO операции
Page — Разбиение колонок на страницы, позволяющее распределять работу по кодированию и сжатию

Если сохранить данные в parquet файл на диск, используя самою привычную нам файловую систему, вы обнаружите, что вместо файла создаётся директория, в которой содержится целая коллекция файлов. Часть из них — это метаинформация, в ней — схема, а также различная служебная информация, включая частичный индекс, позволяющий считывать только необходимые блоки данных при запросе. Остальные части, или партиции, это и есть наши Row group.

Для интуитивного понимания будем считать Row groups набором файлов, объединённых общей информацией. Кстати, это разбиение используется HDFS для реализации data locality, когда каждая нода в кластере может считывать те данные, которые непосредственно расположены у неё на диске. Более того, row group выступает единицей Map Reduce, и каждая map-reduce задача в Spark работает со своей row-group. Поэтому worker обязан поместить группу строк в память, и при настройке размера группы надо учитывать минимальный объём памяти, выделяемый на задачу на самой слабой ноде, иначе можно наткнуться на OOM.
В нашем случае мы столкнулись с тем, что в определённых условиях Spark, считывая текстовый файл, формировал только одну партицию, и из-за этого преобразование данных выполнялось только на одном ядре, хотя ресурсов было доступно гораздо больше. С помощью операции repartition в rdd мы разбили входные данные, в итоге получилось несколько row groups, и проблема ушла.

Column chunk (разбиение на уровне колонок) — оптимизирует работу с диском (дисками). Если представить данные как таблицу, то они записываются не построчно, а по колонкам.

Представим таблицу:

Тогда в текстовом файле, скажем, csv мы бы хранили данные на диске примерно так:

В случае с Parquet:

Благодаря этому мы можем считывать только необходимые нам колонки.

Из всего многообразия колонок на деле аналитику в конкретный момент нужны лишь несколько, к тому же большинство колонок остается пустыми. Parquet в разы ускоряет процесс работы с данными, более того — подобное структурирование информации упрощает сжатие и кодирование данных за счёт их однородности и похожести.

Каждая колонка делится на страницы (Pages), которые, в свою очередь, содержат метаинформацию и данные, закодированные по принципу архитектуры из проекта Dremel. За счёт этого достигается довольно эффективное и быстрое кодирование. Кроме того, на данном уровне производится сжатие (если оно настроено). На данный момент доступны кодеки snappy, gzip, lzo.

Есть ли подводные камни?

За счёт “паркетной” организации данных сложно настроить их стриминг — если передавать данные, то полностью всё группу. Также, если вы утеряли метаинформацию или изменили контрольную сумму для Страницы данных, то вся страница будет потеряна (если для Column chank — то chank потерян, аналогично для row group). На каждом из уровней разбиения строятся контрольные суммы, так что можно отключить их вычисления на уровне файловой системы для улучшения производительности.

Выводы:

Достоинства хранения данных в Parquet:

В Wrike мы уже достаточно давно используем parquet-файлы в качестве хранения обогащённых событийных данных, наши аналитики гоняют довольно много запросов к ним каждый день, у нас выработалась особая методика работы с данной технологией, так что с удовольствием поделимся опытом с теми, кто хочет попробовать parquet в деле, и ответим на все вопросы в комментариях.

P.S. Конечно, в последствии мы не раз пересматривали свои взгляды по поводу формы хранения данных, например, нам советовали более популярный Avro формат, но пока острой необходимости что-то менять у нас нет.

Для тех, кто до сих пор не понял разницу между строково-ориентированными данными и колончато-ориентированными, есть прекрасное видео от Cloudera,
а также довольно занимательная презентация о форматах хранения данных для аналитики.

Источник

Как просмотреть файл apache parquet в windows?

Я не смог найти простых объяснений на английском языке относительно файлов Apache Parquet. Такой как:

Любая помощь по этим вопросам приветствуется.

Утилита Windows для открытия и просмотра файлов Parquet: github.com/mukunku/ParquetViewer

Что такое паркет Apache?

Мне нужен Hadoop или HDFS?

Нет. Файлы Parquet могут храниться в любой файловой системе, а не только в HDFS. Как упоминалось выше, это формат файла. Таким образом, он похож на любой другой файл, у которого есть имя и расширение .паркет. Что обычно происходит в средах больших данных, так это то, что один набор данных будет разделен (или разделен) на несколько паркетных файлов для еще большей эффективности.

Все продукты Apache для работы с большими данными по умолчанию поддерживают файлы Parquet. Вот почему может показаться, что он может существовать только в экосистеме Apache.

Как я могу создавать / читать паркетные файлы?

Как уже упоминалось, все текущие продукты Apache для работы с большими данными, такие как Hadoop, Hive, Spark и т. д., По умолчанию поддерживают файлы Parquet.

Таким образом, эти системы можно использовать для создания или чтения данных Parquet. Но это далеко не практично. Представьте, что для чтения или создания файла CSV вам нужно установить Hadoop / HDFS + Hive и настроить их. К счастью, есть и другие решения.

Чтобы создать свои собственные пилки паркета:

Чтобы просмотреть содержимое файла паркета:

Есть другие способы?

ParquetViewer не смог открыть почти ни один из моих файлов. 🙁

@ShaharPrish Я бы открыл тикет в репозитории с некоторыми файлами примеров.

Источник

Как просмотреть файл Apache Parquet в Windows?

Apache Parquet: внутреннее устройство файла Parquet и проверка файловой структуры Parquet

Я не смог найти простых объяснений на английском языке относительно файлов Apache Parquet. Такие как:

Любая помощь по этим вопросам приветствуется.

Что такое паркет Apache?

Мне нужен Hadoop или HDFS?

Нет. Файлы Parquet могут храниться в любой файловой системе, а не только в HDFS. Как упоминалось выше, это формат файла. Так что это как любой другой файл, у которого есть имя и .паркет расширение. Однако в средах больших данных обычно происходит то, что один набор данных будет разделен (или разделен) на несколько файлов паркета для еще большей эффективности.

Все продукты Apache для работы с большими данными по умолчанию поддерживают файлы Parquet. Вот почему может показаться, что он может существовать только в экосистеме Apache.

Как я могу создавать / читать паркетные файлы?

Как уже упоминалось, все текущие продукты Apache для работы с большими данными, такие как Hadoop, Hive, Spark и т. Д., По умолчанию поддерживают файлы Parquet.

Таким образом, эти системы можно использовать для создания или чтения данных Parquet. Но это далеко не практично. Представьте, что для чтения или создания файла CSV вам нужно установить Hadoop / HDFS + Hive и настроить их. К счастью, есть и другие решения.

Чтобы создать свои собственные пилки паркета:

Чтобы просмотреть содержимое файла паркета:

Есть другие способы?

Теперь это возможно с помощью Apache Arrow, который помогает упростить связь / передачу между различными форматами данных, см. Мой ответ здесь или официальную документацию в случае Python.

В основном это позволяет вам быстро читать / писать файлы паркета в пандах. DataFrame как мода дает вам преимущества использования notebooks просматривать и обрабатывать такие файлы, как если бы это был обычный csv файл.

Затем вы можете просто использовать панды для управления паркетными файлами:

В дополнение к обширному ответу @ sal есть еще один вопрос, с которым я столкнулся в этом контексте:

Как я могу получить доступ к данным в файле паркета с помощью SQL?

Поскольку мы все еще находимся здесь в контексте Windows, я знаю не так уж много способов сделать это. Наилучшие результаты были достигнуты при использовании Spark в качестве механизма SQL с Python в качестве интерфейса для Spark. Тем не менее, я предполагаю, что среда Zeppelin тоже работает, но я еще не пробовал это делать.

Майкл Гарланик написал очень хорошее руководство по установке комбинации Spark / Python.

После настройки я могу взаимодействовать с паркетом через:

После загрузки паркетов таким образом вы можете взаимодействовать с Pyspark API, например. через:

Возможно, уже слишком поздно для этой темы, просто сделайте какое-нибудь дополнение для тех, кто хочет просмотреть файл Parquet с помощью настольного приложения, работающего на MAC или Linux.
Существует настольное приложение для просмотра Parquet, а также других данных в двоичном формате, таких как ORC и AVRO. Это чистое приложение Java, поэтому его можно запускать в Linux, Mac, а также в Windows. Пожалуйста, проверьте Bigdata File Viewer для подробностей.

Он поддерживает сложные типы данных, такие как массив, карта и т. Д.

На Mac, если мы хотим просматривать контент, мы можем установить ‘parquet-tools’

Мы всегда можем прочитать паркетный файл в фрейм данных в Spark и увидеть его содержимое.

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

Источник

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

Apache Parquet

Содержание

Описание

Apache Parquet был создан с целью сделать преимущества сжатого и эффективного столбцового представления данных доступными для любого проекта в экосистеме Hadoop. Он позволяет задавать схемы сжатия на уровне столбцов и рассчитан на возможность добавлять новые кодировки по мере их изобретения и реализации.

Терминология

При понимании принципа работы Apache Parquet применяются следующие термины:

Иерархически файл состоит из одной или нескольких групп строк. Группа строк содержит ровно один кусок столбца на столбец. Куски столбцов содержат одну или несколько страниц.

Особенности

Apache Parquet реализован с использованием алгоритма измельчения и сборки записей, вмещающий сложные структуры данных, которые можно использовать для хранения данных. Это дает свои преимущества и недостатки.

Преимущества

Значения в каждом столбце физически хранятся в смежных местах памяти, и это столбцовое хранилище обеспечивает следующие преимущества:

Недостатки

К недостаткам можно отнести:

Модули

Модули Apache Parquet:

Сжатие и кодирование

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

Кодировка словаря

Parquet имеет автоматическое кодирование словаря, динамически включаемое для данных с небольшим количеством уникальных значений ( Кодирование длин серий (RLE)

Чтобы оптимизировать хранение нескольких экземпляров одного и того же значения, одно значение сохраняется один раз вместе с количеством экземпляров.

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

Упаковка битов

Хранение целых чисел обычно выполняется с выделенными 32 или 64 битами на целое число. Для небольших целых чисел упаковка нескольких целых в одном и том же пространстве делает хранение более эффективным.

Вложенная кодировка

Для кодирования вложенных столбцов Parquet использует кодировку Dremel с уровнями определения и повторения. Уровни определения указывают, сколько необязательных полей в пути для столбца определены. Уровни повторения указывают, для какого повторяемого поля в пути значение имеет повторение. Максимальные уровни определения и повторения могут быть вычислены из схемы (т. е. сколько существует вложенности). Это определяет максимальное количество битов, необходимых для хранения уровней (уровни определены для всех значений в столбце).

Структура файла

Рассмотрим следующий пример:

В приведенном выше примере в этой таблице есть N столбцов, разбитых на M групп строк. Метаданные файла содержат местоположения всех начальных местоположений метаданных столбца.

Метаданные, в свою очередь, записываются после данных, чтобы обеспечить однопроходную запись. Ожидается, что сначала прочитаются метаданные файла, чтобы найти все интересующие их фрагменты столбцов. Затем фрагменты столбцов будут прочтены последовательно.

Файлы имеют несколько уровней разбиения на части, благодаря чему возможно довольно эффективное параллельное исполнение операций поверх них:

Метаданные

В Apache Parquet осуществляется работа с тремя типами метаданных [Источник 2] :

Рассмотрим формат на рисунке 2:

Формат явно предназначен для отделения метаданных от данных. Это позволяет разбивать столбцы на несколько файлов, а также иметь один файл метаданных, ссылающийся на несколько файлов паркета.

Предполагается, что типы переменных, поддерживаемые форматом файла, должны быть как можно более минимальны, с учетом того, как типы влияют на дисковое хранилище. Например, 16-разрядные числа явно не поддерживаются в формате хранения, поскольку они покрыты 32-разрядными числами с эффективным кодированием. Это уменьшает сложность реализации чтения и записи для формата. Типы:

Восстановление после ошибок

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

Потенциальное расширение: с небольшими группами строк самой большой проблемой является размещение метаданных файла в конце. Если во время записи метаданных файла произойдет ошибка, все записанные данные будут нечитаемыми. Это можно исправить, записав метаданные файла в каждую N-ю группу строк. Метаданные каждого файла будут включать все группы строк, написанные до сих пор. Комбинируя это со стратегией, используемой для файлов rc или avro с использованием маркеров синхронизации, читатель может восстановить частично записанные файлы.

Источник