Привет, Хабр! Если вы работаете с большими данными, то для вас, скорее всего, Parquet — это как воздух. Стандарт де-факто для колоночного хранения в экосистеме Hadoop, Spark, и вообще всего, что связано с аналитикой. Он эффективен, надёжен и поддерживается практически всеми инструментами. Казалось бы, живи и радуйся.

Но что, если я скажу, что в мире современных SSD, многоядерных CPU и вездесущих векторных баз данных старый добрый Parquet начинает показывать свой возраст? Он был спроектирован в эпоху, когда узким местом были HDD и сетевые задержки, а не скорость процессора. Сегодня железо изменилось, задачи тоже, и на сцену выходят новые, амбициозные форматы.

Давайте разберёмся, где именно Parquet даёт слабину и кто эти дерзкие новички, которые метят на его трон.

За основу взята статья Dipankar Mazumdar.

С чем у Parquet проблемы?

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

Проблема №1: Большие метаданные и «проблема маленьких файлов»

Каждый Parquet-файл хранит свои метаданные (схему, статистику по колонкам и т.д.) в футере (в конце файла). Чтобы прочитать даже одну строчку, движку нужно сначала прочитать этот футер. Если у вас много маленьких файлов (классика для стриминговых пайплайнов), вы тратите кучу времени на чтение тысяч этих футеров, что создаёт огромное количество I/O операций и убивает производительность.

Проблема №2: Последовательное декодирование в мире тотального параллелизма

Parquet сжимает данные на уровне страниц (pages) внутри групп строк (row groups). Однако декодирование этих страниц внутри одной колонки — процесс по большей части последовательный. В эпоху, когда у нас в ноутбуках по 16 ядер, а на серверах — по 64 и больше, неспособность полностью распараллелить декодирование становится серьёзным узким местом. Процессор простаивает, а мы ждём.

Проблема №3: Не всегда оптимальное сжатие для современных железок

Parquet использует кодеки общего назначения вроде Snappy, Gzip или ZSTD. Они хороши, но не всегда идеально подходят для современных реалий, особенно для SSD. Скорость чтения с NVMe SSD настолько высока, что узким местом становится CPU, который не успевает распаковывать данные. Нужен баланс между степенью сжатия и скоростью декомпрессии, и стандартные кодеки не всегда его обеспечивают.

Проблема №4: Ограниченная поддержка новых типов данных (привет, векторы!)

Parquet был создан для табличных данных. Но что делать с современными AI/ML-ворклоадами? Векторные эмбеддинги, данные временных рядов, разреженные матрицы — всё это можно запихнуть в Parquet, но это будет похоже на попытку перевезти пианино в багажнике седана. Формат не оптимизирован для таких структур, что приводит к неэффективному хранению и медленному доступу.

Знакомьтесь: претенденты на трон

Свято место пусто не бывает. Инженеры из разных компаний (Meta, Databricks, Google) и open-source сообществ взялись за решение этих проблем. Вот самые интересные проекты.

1. BtrBlocks: Выжимаем максимум из SSD

Разработчик: Meta (Facebook)

Главная фишка: Феноменальное сжатие и скорость распаковки, заточенные под SSD.

Как это работает под капотом?
Инженеры Meta заметили, что с быстрыми SSD процессор стал узким местом. Идея BtrBlocks проста: давайте сожмём данные сильнее, чтобы уменьшить объём чтения с диска, но используем для этого такие алгоритмы, которые можно очень быстро распаковать.

Целочисленное сжатие: BtrBlocks использует специализированные алгоритмы для сжатия чисел (например, Patched Frame-of-Reference), которые работают гораздо эффективнее ZSTD на числовых данных.
Сжатие строк: Для строковых данных применяется подход с созданием словаря и последующим сжатием целочисленных индексов.

В итоге BtrBlocks обеспечивает в 2-4 раза лучшее сжатие, чем Parquet с ZSTD, и при этом показывает на 2-5 раз более высокую скорость сканирования (чтения).

Где использовать: Аналитические базы данных, где данные лежат на быстрых SSD и запросы сканируют большие объёмы данных (например, ScyllaDB, в которой он уже используется).

Компромиссы: BtrBlocks — это скорее библиотека сжатия, а не полноценный файловый формат. Ему не хватает богатой системы метаданных, как у Parquet.

2. FastLanes: Дайте волю ядрам!

Разработчик: Google

Главная фишка: Максимальный параллелизм при декодировании.

Как это работает под капотом?
FastLanes решает проблему №2 — последовательное декодирование. Формат спроектирован так, чтобы каждую колонку можно было разбить на независимые «полосы» (lanes), которые декодируются параллельно в разных потоках.

Независимые "полосы": Каждая полоса содержит свои собственные метаданные, что позволяет декодировать её, не оглядываясь на соседей.
Оптимизация под SIMD: Алгоритмы сжатия в FastLanes разработаны с учётом использования SIMD-инструкций (Single Instruction, Multiple Data), что даёт дополнительный буст производительности на современных CPU.

Результаты впечатляют: FastLanes показывает в 3-6 раз более высокую пропускную способность при чтении по сравнению с Parquet.

Где использовать: Высокопроизводительные аналитические системы, работающие на многоядерных процессорах, где важна минимальная задержка запроса.

Компромиссы: Проект пока менее зрелый и не так широко распространён, как остальные.

3. Lance: Формат для эры AI/ML

Разработчик: LanceDB

Главная фишка: Создан специально для AI/ML-задач, особенно для векторного поиска и работы с мультимодальными данными.

Как это работает под капотом?
Lance — это не просто замена Parquet, это переосмысление формата для новых задач.

Оптимизация для векторного поиска: Данные хранятся таким образом, чтобы обеспечить сверхбыстрый поиск ближайших соседей (ANN), что является основой для векторных баз данных.
Нулевое копирование (Zero-copy): Lance использует Apache Arrow в качестве in-memory модели, что позволяет читать данные с диска прямо в память GPU без лишних преобразований и копирований.
Версионирование данных (Time Travel): Встроенная поддержка версий данных, как в Git. Вы можете легко откатиться к предыдущему состоянию датасета, что бесценно для воспроизводимости ML-экспериментов.

Где использовать: Везде, где вы работаете с векторными эмбеддингами, датасетами для нейросетей, изображениями, аудио и т.д. Идеально для построения систем RAG (Retrieval-Augmented Generation).

Компромиссы: Пока ещё не стал индустриальным стандартом и может быть избыточен для классической табличной аналитики.

4. Vortex: Экстремальное сжатие для всего

Разработчик: Сообщество, с активным участием инженеров из Intel.

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

Как это работает под капотом?
Vortex — это не просто формат, а скорее фреймворк для сжатия. Он рассматривает данные как дерево кодировок, где каждый узел применяет свой, наиболее подходящий алгоритм.

Композитное сжатие: Vortex может комбинировать различные техники: словарное кодирование, RLE (Run-Length Encoding), дельта-кодирование и другие, применяя их рекурсивно.
Поддержка разреженных данных: Он отлично справляется с данными, где много нулей или повторяющихся значений, достигая невероятных коэффициентов сжатия.

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

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

Компромиссы: Очень молодой проект. Находится в стадии активной разработки, и его экосистема пока ограничена.

Сводная таблица: кто на что горазд

Критерий	Parquet	BtrBlocks	FastLanes	Lance	Vortex
Пропускная способность	Средняя	Высокая	Очень высокая	Высокая	Зависит от данных
Задержка	Высокая	Низкая	Очень низкая	Очень низкая	Зависит от данных
Коэфф. сжатия	Хороший	Отличный	Хороший	Хороший	Экстремальный
Параллелизм	Ограниченный	Хороший	Отличный	Хороший	Хороший
Основной юзкейс	Общая аналитика	Быстрые сканы с SSD	OLAP на CPU	AI/ML, векторный поиск	Разреженные/сложные данные
Зрелость	Стандарт индустрии	Используется в проде	Экспериментальный	Быстро растёт	Ранняя стадия
Ключевая фича	Экосистема	Сжатие/скорость на SSD	Параллелизм	Версионирование, векторы	Композитное сжатие

Так что же выбрать? Серебряной пули нет

Означает ли всё это, что пора срочно переписывать все свои пайплайны и выбрасывать Parquet на свалку истории? Конечно, нет.

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

Если вы строите аналитическую СУБД на быстрых дисках и упираетесь в CPU при сканировании — посмотрите в сторону BtrBlocks.
Если вам нужна минимальная задержка в OLAP-системе с десятками ядер — FastLanes может стать вашим спасением.
Если вы работаете с векторными эмбеддингами и ML-моделями — Lance выглядит как формат, созданный специально для вас.
А если у вас специфичные, очень разреженные данные, и место на диске стоит дороже золота — Vortex может сотворить чудо.

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

Подпиывайтесь на новости на нашем канале

Parquet — король умер? Да здравствует… кто? Обзор BtrBlocks, FastLanes, Lance и Vortex