Комментарии (98)
- Бенчмарк с 650GB данных считается микробенчмарком; реальные рабочие нагрузки часто достигают PB/EB-масштабов, где распределенные системы остаются актуальными.
- Основным узким местом выступает I/O (особенно сетевая пропускная способность экземпляров, как c5.4xlarge с 10Gbps), а не CPU, что делает single-node инструменты (DuckDB, Polars) эффективными для таких объемов.
- Spark необходим для распределенных вычислений при работе с очень большими данными или конкурентных запросах к частям данных, но для 650GB его преимущества сомнительны.
- Предлагались альтернативы: DuckLake, awk, GNU-инструменты, а также использование экземпляров с более высокой пропускной способностью (m6a вместо c5).
- Многие рабочие нагрузки в реальности меньше 650GB, и Spark часто используется избыточно для задач, где достаточно single-node решений.
The two versions of Parquet
Две версии Parquet
DuckDB недавно описали, как SQL-движки, не реализовав полностью спецификацию Parquet, тормозят её развитие. То же происходит в экосистеме: после выхода моей библиотеки Carpet я включил v2 по умолчанию, но быстро откатил изменение — устаревший Pandas не читал такие файлы.
Почему v2 не внедрён
Спецификация готова, но нет согласия, какие именно фичи считать «ядром» v2. Обсуждение в apache/parquet-format длится четвёртый год. Смешиваются два независимых направления:
- новые кодировки (
RLE_DICTIONARY,DELTA_BYTE_ARRAY) — ломают только столбец; - новая структура страниц (Data Page V2) — ломает весь файл.
Логические типы (например, VARIANT) не привязаны к версии формата.
Альтернативы
В ML-среде Parquet и ORC стали тесны, поэтому появились форматы Nimble (Facebook) и LV2 (LanceDB), но в data-engineering Parquet остаётся королём.
Производительность v2
Достаточно выставить WriterVersion.PARQUET_2_0.
| Датасет | Алгоритм | v1, МБ | v2, МБ | Δ |
|---|---|---|---|---|
| Италия | без сжатия | 564 | 355 | –37 % |
| Италия | SNAPPY | 220 | 198 | –10 % |
| NYC | без сжатия | 760 | 511 | –33 % |
| NYC | SNAPPY | 542 | 480 | –11 % |
Новые кодировки лучше уплотняют данные до компрессии, поэтому выигрыш больше у несжатых файлов, а у ZSTD размер даже немного вырос.
Комментарии (44)
- Parquet разделён на две версии: v2 экономит место и ускоряет чтение, но экосистема (Spark, Iceberg, Delta Lake и др.) всё ещё в основном на v1.
- Справочная реализация — гигантская Java-библиотека с 74 000 строк кода на каждую комбинацию кодировки, что вызывает сомнения в оптимальности.
- Совместимость между библиотеками (PyArrow, Fastparquet, Spark) долго была проблемой, как и разные версии Scala в Spark.
- Даже простые оптимизации (мета-данные о сортировке) фактически не используются, а многие разработчики не знали о существовании v2.
- Несмотря на критику, Parquet всё равно крупный шаг вперёд по сравнению с предыдущими форматами, и вопросы скорее в медленной эволюции стандарта, чем в самой идее.