Parquet и ORC — что это вообще такое❓❓❓

Сегодня оба формата воспринимаются как стандарт для Data Lake.
Но появились они как ответ на реальные боли Hadoop-эры.
Начало 2010-х.
В экосистеме Apache Hadoop данные лежат в HDFS, аналитика делается через Apache Hive.
Проблема простая:
🔴CSV / TSV занимают много места
🔴Full table scan работает медленно
🔴Компрессия слабая
🔴Нет нормальной статистики по данным
🔴Hive буквально читает всё подряд.
Команда Hive понимает: нужен формат, который будет ускорять аналитические запросы.
Так в 2013 году появляется Apache ORC(Optimized Row Columnar).

Что такое ORC?🤔

📝ORC — это колоночный формат хранения данных. Файл в ORC логически делится на Stripes — крупные блоки данных, внутри которых хранятся сами колоночные данные и индексная информация. В конце файла находится Footer с общей метаинформацией и PostScript, содержащий служебные данные о структуре файла и параметрах компрессии. Внутри ORC хранится статистика по данным — min/max индексы по колонкам, встроенные Bloom filters для ускорения фильтрации, а также используется продвинутая схема компрессии, позволяющая эффективно сжимать данные разных типов. Изначально ORC создавался как «ускоритель Hive» и отлично подходит для тяжёлых DWH-нагрузок и сценариев с full table scan, где важно максимально оптимизировать чтение больших объёмов данных.

Параллельно Cloudera и Twitter понимают: Нужен формат, который будет работать не только с Hive. В том же 2013 году появляется Apache Parquet.
Его идея — универсальность:
🟣поддержка разных движков
🟣сложные nested структуры
🟣хорошая совместимость
🟣кросс-платформенность

Что такое Parquet🤔

📝Parquet — это колоночный формат хранения данных, в котором файл логически разделён на Row Groups — крупные блоки строк, внутри которых данные организованы по колонкам в виде Column Chunks, а минимальной единицей хранения являются Pages. В конце файла находится Footer, содержащий схему и метаданные. В footer хранится статистика по каждой колонке: минимальные и максимальные значения, количество строк, число null-значений и другая служебная информация.

Когда движок, например Apache Spark, выполняет запрос, он сначала читает footer, анализирует статистику и определяет, какие Row Groups можно пропустить. Затем он считывает только те блоки, где потенциально есть подходящие данные, и загружает только нужные колонки. Такой механизм называется predicate pushdown, column pruning и data skipping. Благодаря этому существенно уменьшается объём чтения с диска и снижается нагрузка на CPU и сеть, поэтому Parquet в разы быстрее обычных строковых форматов вроде CSV.


🐱Parquet и ORC появились не ради «ещё одного формата». Они стали ответом на практическую проблему: читать терабайты CSV — дорого, медленно и неэффективно. Строковые форматы заставляют движок загружать весь файл целиком, даже если в запросе нужны всего несколько колонок.

Колоночное хранение изменило экономику аналитики: стало меньше I/O, меньше нагрузки на CPU, сократился shuffle и в целом подешевела инфраструктура. Движки начали читать только нужные колонки и пропускать ненужные блоки данных, что кратно ускорило запросы.

Именно поэтому сегодня почти любой современный Data Lake строится поверх Parquet (реже ORC) — это уже не просто формат, а стандарт индустрии.