Формат orc что это
Русские Блоги
Большие данные: формат хранения файлов Hive-ORC
1. Структура файла ORC
Хранение колонки
Из-за особенностей запроса OLAP, столбчатое хранилище может улучшить производительность запроса, но как это сделать? Это начинается с принципа столбцового хранения.Как видно из рисунка 1, относительно хранения строк, обычно используемого в реляционных базах данных, все элементы каждого столбца сохраняются последовательно при использовании столбцового хранения. Эта функция может привести к следующей оптимизации запроса:
Следует отметить, что ORC необходимо использовать дополнительные ресурсы ЦП для сжатия и распаковки при чтении и записи. Конечно, эта часть потребления ЦП очень мала.
Модель данных
В отличие от Parquet, ORC изначально не поддерживает вложенные форматы данных, но реализует поддержку вложенных форматов посредством специальной обработки сложных типов данных, таких как следующие таблицы кустов:
Файловая структура
Как и в Parquet, ORC-файлы также хранятся в двоичном режиме, поэтому они не могут быть непосредственно прочитаны, ORC-файлы также самоанализируются, они содержат много метаданных, эти метаданные сериализуются изоморфным ProtoBuffer. Файловая структура ORC показана на следующем рисунке, который включает следующие понятия:
В файле ORC хранятся три уровня статистической информации: уровень файла, уровень чередования и уровень группы строк, и все они могут использоваться для определения возможности пропуска определенных данных на основе поисковых ARGuments (условия предиката при нажатии). Статистическая информация включает в себя количество членов и наличие нулевого значения, а некоторая конкретная статистическая информация устанавливается для различных типов данных.
（1）file level
В конце файла ORC будет записана статистика на уровне файлов и статистика столбцов во всем файле. Эта информация в основном используется для оптимизации запросов, а также может выводить результаты для некоторых простых агрегатных запросов, таких как max, min и sum.
（2）stripe level
Файлы ORC будут хранить статистику уровня полосы для каждого поля. Считыватель ORC использует эту статистику, чтобы определить, какие записи полосы необходимо прочитать для запроса. Например, если полоса имеет поля max (a) = 10 и min (a) = 3, то когда условие where равно> 10 или = 1000)
whether to create row indexes
Три, операция Java ORC
Перейдите на официальный сайт https://orc.apache.org, чтобы загрузить исходный пакет orc, затем скомпилируйте и получите orc-core-1.3.0.jar, orc-mapreduce-1.3.0.jar, orc-tools-1.3.0.jar Добавьте его в проект
В большинстве случаев все еще рекомендуется преобразовывать текстовые файлы в формат ORC в Hive. Этот тип генерации файлов ORC локально с помощью JAVA относится к сценариям особых потребностей.
Форматы файлов в больших данных: краткий ликбез
Команда Mail.ru Cloud Solutions предлагает перевод статьи инженера Рахула Бхатии из компании Clairvoyant о том, какие есть форматы файлов в больших данных, какие самые распространенные функции форматов Hadoop и какой формат лучше использовать.
Зачем нужны разные форматы файлов
Серьезное узкое место в производительности приложений с поддержкой HDFS, таких как MapReduce и Spark — время поиска, чтения, а также записи данных. Эти проблемы усугубляются трудностями в управлении большими наборами данных, если у нас не фиксированная, а эволюционирующая схема, или присутствуют некие ограничения на хранение.
Обработка больших данных увеличивает нагрузку на подсистему хранения — Hadoop хранит данные избыточно для достижения отказоустойчивости. Кроме дисков, нагружаются процессор, сеть, система ввода-вывода и так далее. По мере роста объема данных увеличивается и стоимость их обработки и хранения.
Различные форматы файлов в 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 | Name | Department |
| 1 | emp1 | d1 |
| 2 | emp2 | d2 |
| 3 | emp3 | d3 |
Столбчатый формат более эффективен, когда вам нужно запросить из таблицы несколько столбцов. Он прочитает только необходимые столбцы, потому что они находятся по соседству. Таким образом, операции ввода-вывода сводятся к минимуму.
Например, вам нужен только столбец NAME. В строковом формате каждую запись в наборе данных нужно загрузить, разобрать по полям, а затем извлечь данные NAME. Столбчатый формат позволяет перейти непосредственно к столбцу Name, так как все значения для этого столбца хранятся вместе. Не придется сканировать всю запись.
Таким образом, столбчатый формат повышает производительность запросов, поскольку для перехода к требуемым столбцам требуется меньше времени поиска и сокращается количество операций ввода-вывода, ведь происходит чтение только нужных столбцов.
Одна из уникальных особенностей Parquet заключается в том, что в таком формате он может хранить данные с вложенными структурами. Это означает, что в файле Parquet даже вложенные поля можно читать по отдельности без необходимости читать все поля во вложенной структуре. Для хранения вложенных структур Parquet использует алгоритм измельчения и сборки (shredding and assembly).
Чтобы понять формат файла Parquet в Hadoop, необходимо знать следующие термины:
Здесь заголовок просто содержит волшебное число PAR1 (4 байта), которое идентифицирует файл как файл формата Parquet.
В футере записано следующее:
Формат файлов ORC
Оптимизированный строково-столбчатый формат файлов (Optimized Row Columnar, ORC) предлагает очень эффективный способ хранения данных и был разработан, чтобы преодолеть ограничения других форматов. Хранит данные в идеально компактном виде, позволяя пропускать ненужные детали — при этом не требует построения больших, сложных или обслуживаемых вручную индексов.
Преимущества формата ORC:
ORC хранит коллекции строк в одном файле, а внутри коллекции строчные данные хранятся в столбчатом формате.
Файл ORC хранит группы строк, которые называются полосами (stripes) и вспомогательную информацию в футере файла. Postscript в конце файла содержит параметры сжатия и размер сжатого футера.
По умолчанию размер полосы составляет 250 МБ. За счет полос такого большого размера чтение из HDFS выполняется более эффективно: большими непрерывными блоками.
В футере файла записан список полос в файле, количество строк на полосу и тип данных каждого столбца. Там же записано результирующее значение count, min, max и sum по каждому столбцу.
Футер полосы содержит каталог местоположений потока.
Строчные данные используются при сканировании таблиц.
Индексные данные включают минимальные и максимальные значения для каждого столбца и позиции строк в каждом столбце. Индексы ORC используются только для выбора полос и групп строк, а не для ответа на запросы.
Сравнение разных форматов файлов
Avro по сравнению с Parquet
ORC по сравнению с Parquet
Какие бывают форматы файлов в больших данных и как их лучше использовать: краткий ликбез
Перевели статью инженера Рахула Бхатии из компании 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 | Name | Department |
| 1 | emp1 | d1 |
| 2 | emp2 | d2 |
| 3 | emp3 | d3 |
В строковом формате данные сохранятся следующим образом:
В столбчатом формате файлов те же данные сохранятся так:
Столбчатый формат более эффективен, когда вам нужно запросить из таблицы несколько столбцов. Он прочитает только необходимые столбцы, потому что они находятся по соседству. Таким образом, операции ввода-вывода сводятся к минимуму.
Например, вам нужен только столбец NAME. В строковом формате каждую запись в наборе данных нужно загрузить, разобрать по полям, а затем извлечь данные NAME. Столбчатый формат позволяет перейти непосредственно к столбцу Name, так как все значения для этого столбца хранятся вместе. Не придется сканировать всю запись.
Таким образом, столбчатый формат повышает производительность запросов, поскольку для перехода к требуемым столбцам требуется меньше времени поиска и сокращается количество операций ввода-вывода, ведь происходит чтение только нужных столбцов.
Одна из уникальных особенностей Parquet заключается в том, что в таком формате он может хранить данные с вложенными структурами. Это означает, что в файле Parquet даже вложенные поля можно читать по отдельности без необходимости читать все поля во вложенной структуре. Для хранения вложенных структур Parquet использует алгоритм измельчения и сборки (shredding and assembly).
Чтобы понять формат файла Parquet в Hadoop, необходимо знать следующие термины:
Здесь заголовок просто содержит волшебное число PAR1 (4 байта), которое идентифицирует файл как файл формата Parquet.
В футере записано следующее:
Формат файлов ORC
Оптимизированный строково-столбчатый формат файлов (Optimized Row Columnar, ORC) предлагает очень эффективный способ хранения данных и был разработан, чтобы преодолеть ограничения других форматов. Хранит данные в идеально компактном виде, позволяя пропускать ненужные детали — при этом не требует построения больших, сложных или обслуживаемых вручную индексов.
Преимущества формата ORC:
ORC хранит коллекции строк в одном файле, а внутри коллекции строчные данные хранятся в столбчатом формате.
Файл ORC хранит группы строк, которые называются полосами (stripes) и вспомогательную информацию в футере файла. Postscript в конце файла содержит параметры сжатия и размер сжатого футера.
По умолчанию размер полосы составляет 250 МБ. За счет полос такого большого размера чтение из HDFS выполняется более эффективно: большими непрерывными блоками.
В футере файла записан список полос в файле, количество строк на полосу и тип данных каждого столбца. Там же записано результирующее значение count, min, max и sum по каждому столбцу.
Футер полосы содержит каталог местоположений потока. Строчные данные используются при сканировании таблиц.
Индексные данные включают минимальные и максимальные значения для каждого столбца и позиции строк в каждом столбце. Индексы ORC используются только для выбора полос и групп строк, а не для ответа на запросы.
О сравнении форматов хранения в Hadoop: начнем с ORC
В Hadoop входят продукты, которые могут работать с файлами разных форматов. Я неоднократно искал, читал и думал над тем — какой же формат лучше. Относительно случайно столкнувшись с форматом ORC, заинтересовался, почитал (и даже чуть покодил) и вот что понял — сравнивать форматы как таковые некорректно. Точнее, их обычно сравнивают, на мой взгляд, некорректным образом. Собственно, статья об этом, а также о формате Apache ORC (в техническом плане) и предоставляемых им возможностях.
Начну с вопроса: каким может быть размер реляционной таблицы (в байтах и очень примерно), состоящей из 10 тысяч строк (по два целых поля в строке)? Обычно здесь ставят кат, а ответ помещают под катом — я отвечу здесь: 628 байт. А детали и историю перенесу под кат.
Как все началось: собрал я библиотеку для работы с Apache ORC (см. заглавную страницу проекта — https://orc.apache.org) и скомпилировал их же пример про запись в ORC (что голову ломать — начинаем с того, что работает), это в нем было 2 поля и 10 тысяч строк. Запустил — получил orc-файл, поскольку делал я это где-то не в офисе — на всякий случай переписал библиотеку и файл на флэшку (торопился — не стал смотреть размер, думаю, флэшка-то выдержит).
Но как-то быстро переписалось… Посмотрел на размер — 628 байт. Подумал — ошибка, сел и начал разбираться. Запустил утилиту для просмотра ORC из той же собранной библиотеки — содержимое файла показывает, все честно — 10 тысяч строк. Вот после этого я и призадумался — как может 10 тысяч строк влезть в 628 байт (я к тому времени уже немного знал про ORC и понимал, что там есть еще и метаданные — формат же самодостаточный). Разобрался, делюсь.
О формате ORC
Не буду повторять здесь общие слова про формат — см. ссылку выше, там хорошо написано. Сфокусируюсь на двух прилагательных в превосходной форме с картинки выше (картинка взята с заглавной страницы проекта): давайте попробуем разобраться — почему ORC «самый быстрый» и «самый компактный».
Скорость
Скорость бывает разная, применительно к данным — как минимум скорость чтения или записи (можно углубляться и дальше, но давайте пока остановимся). Поскольку в лозунге выше явно упоминается Hadoop, то рассматривать будем прежде всего скорость чтения.
Процитирую еще немного из документации ORC:
It is optimized for large streaming reads, but with integrated support for finding required rows quickly. Storing data in a columnar format lets the reader read, decompress, and process only the values that are required for the current query.
Размер
Тут цитаты не нашлось, скажу своими словами
Предоставление возможностей
Хочу обратить Ваше внимание на формулировки из цитат выше: «оптимизирован под. «, «содержит поддержку. «, «позволяет производить чтение. » — формат файла, как язык программирования, является средством (в данном случае, обеспечения эффективного хранения и доступа к данным). Будет ли хранение и доступ к данным действительно эффективными зависит не только от средства, но и от того, кто и как этим средством пользуется.
Давайте посмотрим — какие возможности для обеспечения скорости и компактности предоставляет формат.
Колончатое хранение и страйпы
Данные в ORC хранятся в виде колонок, прежде всего это влияет на размер. Для обеспечения скорости потокового чтения файл разбит на так называемые «страйпы» (stripes), каждый страйп является самодостаточным, т.е. может быть прочитан отдельно (а, следовательно, параллельно). Из-за страйпов размер файла увеличится (не уникальные значения колонок будут храниться несколько раз — в тех страйпах, где такие значения встречаются) — тот самый баланс «скорость — размер» (он же компромисс).
Индексы
Формат ORC подразумевает индексы, позволяющие определить — содержит ли страйп (а точнее — части страйпа по 10 тысяч строк, так называемые «row group») искомые данные или нет. Индексы строятся по каждой из колонок. Это влияет на скорость чтения, увеличивая размер. При потоковом чтении индексы, кстати, можно и не читать.
Сжатие
Все метаданные хранятся в сжатом виде, а это
(ниже мы увидим, что метаданные составляют существенную часть файла)
Значения колонок также хранятся в сжатом виде. При этом обеспечивается возможность чтения и распаковки только того блока данных, который нужен (т.е. сжимается не файл и не страйп целиком). Сжатие влияет и на размер, и на скорость чтения.
Кодирование
Значения колонок — а файл хранит именно эти значения — хранятся в кодированном виде (encoded). В текущей версии формата (ORC v1) для целых чисел, например, доступно 4 варианта кодирования. При этом кодируется не вся колонка целиком, кодируются части колонки, каждая часть может быть закодирована оптимальным для этой части образом (такие части в спецификации называют «run»-ом). Таким образом достигается минимизация суммарной длины хранимых данных. Опять же влияние на размер и на скорость.
Посмотрим ORC файл
Давайте очень кратко посмотрим — что внутри ORC файла (того самого — 628 байт). Для тех, кого не очень интересуют технические детали — пролистайте до следующего раздела (про сравнение форматов).
Вот так определялась наша таблица в примере записи в ORC:
Метаданные
Информация о длинах (я привожу скриншоты jupyter notebook, думаю, достаточно понятно)
Что мы здесь видим:
Обратим внимание здесь на соотношение объема данных и метаданных (276 к 352 байт). Но эти 276 байт данных — тоже не только данные, данные содержат немного «лишнего» (здесь для краткости не привожу скриншоты — с ними длинно получается, обойдусь только своими комментариями), что входит в данные:
Потоки PRESENT — это битовые строки, позволяющие понять — где в колонках стоят NULL. Для нашего примера их присутствие выглядит странно (в статистике нашего файла явно написано, что NULL-ов в данных нет — зачем тогда включать PRESENT? Похоже на недоработку. )
Итого собственно данные занимают 216 байт, метаданные — 352.
Также из метаданных видно, что обе колонки закодированы с помощью DIRECT_V2 метода (для целых он допускает 4 вида представления, за деталями отсылаю к спецификации — она есть на сайте проекта).
Данные
Посмотрим (опять без скриншотов для краткости), как же 10 тысяч чисел поместилось в 103 байта (для колонки «x»):
Завершая обзор представления нашей простой таблицы в файле скажу, что индексы в этом примере вырождены — указывают на начало потока данных. С индексами я разберусь на реальных примерах, возможно, опишу в отдельной статье.
Для интересующихся: по ссылке можно найти jupyter notebook, в котором я «разбирался» во внутренностях формата. Можно им воспользоваться и повторить (ORC файл там тоже приложен).
Уверен, что многие читатели «потерялись» — да, формат ORC не является простым (как в плане понимания деталей, так и в плане использования предоставляемых возможностей).
О сравнении форматов
Теперь перейдем к главному — некорректности сравнения форматов.
Как часто сравнивают форматы: давайте сравним размер файлов в формате А и Б, скорость чтения (разных видов чтения — случайное, потоковое и т.п.) в формате А и Б. Сравнили, сделали вывод — формат А лучше формата Б.
На примере последнего из перечисленных выше средств обеспечения компактности (кодирования): можно ли в ORC закодировать данные оптимальным образом? Да, возможности есть — см. выше. Но точно также можно этого и не делать! Это зависит от «писателя» (writer в терминологии ORC): в приведенном выше примере писатель это смог сделать. Но он мог бы просто записать 2 раза по 10 тысяч чисел и это тоже было бы корректно с точки зрения формата. Сравнивая форматы «на размер» мы сравниваем не только и не столько форматы, сколько алгоритмическое качество использующих эти форматы прикладных систем.
Кто есть «писатель» в Hadoop? Их много — например, Hive, который создает таблицу, хранящую свои данные в файлах в формате ORC. Сравнивая, к примеру, ORC с Parquet-ом в Hadoop, мы на самом деле оцениваем качество реализации алгоритма преобразования данных, реализованного в Hive. Мы не сравниваем форматы (как таковые).
Важная особенность Hadoop
В классическом реляционном мире у нас не было никакой возможности повлиять на размер таблицы в Oracle — она как-то хранилась и только Oracle знал — как. В Hadoop ситуация чуть другая: мы можем посмотреть — как хранится та или иная таблица (насколько хорошо у Hive, например, получилось ее «закодировать»). И, если мы видим, что это можно улучшить, — у нас есть для этого реальная возможность: создать свой более оптимальный ORC файл и дать его Hive-у в качестве внешней таблицы.
Сравним ORC и QVD
Я недавно описал формат QVD, который активно используется QlikVew/QlikSense. Давайте для иллюстрации очень кратко сравим эти два формата с точки зрения возможностей, которые они предоставляют для достижения максимальной скорости чтения и минимизации размера. Возможности ORC описаны выше, что у QVD:
Колончатое хранение
QVD может считаться «колончатым» форматом, в нем нет дублирования значений колонок — уникальные значения хранятся один раз. НО он не допускает параллельной обработки — сначала необходимо полностью считать значения всех колонок, потом можно параллельно читать строки.
А дублирование есть на уровне строк — строки хранят повторяющиеся значения индекса в таблице символов.
Сжатие
Не сталкивался со сжатыми QVD файлами — не довелось — тэг такой в метаданных есть, возможно, каждая из частей, про которую в метаданных есть смещение и длина (а это — каждая таблица символов и вся таблица строк), может быть сжата. В этом случае параллельное чтение строк — «давай до свиданья».
Индексы
В QVD файле нет возможности понять — какую его часть необходимо читать. На практике приходится побайтово разбирать таблицу символов (каждую!), не очень эффективный способ.
Кодирование
Кодирование в QVD не применяется, можно провести аналогию битового индекса в таблице строк с кодированием, но эта аналогия «компенсируется» дублированием чисел строками в таблицах символов (детали — см. в статье, кратко — значение колонки часто представлено числом И строкой).
Вывод по этому краткому сравнению у меня лично получился такой — формат QVD практически не содержит возможностей, позволяющих компактно хранить и быстро читать содержащиеся в файлах этого формата данные.
(Прозвучало как-то обидно для QVD, чуть дополню — формат был создан очень давно, используется только QlikView/QlikSense, а они «хранят» все данные в памяти. Я думаю, что QVD файл просто читается весь «как есть» в память, а далее эти замечательные во всех отношениях BI продукты очень быстро работают с этим представлением — тут они мастера. )
Вместо заключения
Покритиковал и ничего пока не предложил… — предлагаю.
Мне представляется, что сравнивать форматы нужно не на примере их конкретной реализации, сравнивать форматы нужно с точки зрения входящих в них инструментальных средств и возможности использовать эти средства для решения наших конкретных задач. Скорость работы работы процессоров постоянно растет, сейчас мы можем себе позволить практически любые алгоритмы преобразования данных после того, как они считаны — все равно чтение с диска будет медленнее. Именно поэтому «выразительные средства» форматов важны.
Выше я кратко перечислил интересные, на мой взгляд, возможности формата ORC. У меня еще нет статистики по тому, как обстоит дело на практике (какие из этих возможностей и в какой мере используются Hive-ом, например). Когда появится — напишу. В ближайших планах сделать подобный обзор другого популярного формата хранения — Parquet.
Ну и — совсем в заключение — в современном мире очень много информации, к сожалению, часть этой информации является слишком поверхностной. Не будем поддаваться, будем смотреть в суть.