Hacker News Digest

Режим --long в Zstandard значительно улучшает сжатие геномных последовательностей, но требует удаления символов новой строки внутри записей.

Специализированные методы сжатия ДНК, такие как MiniPhy, достигают коэффициента сжатия (CR) 91, но работают медленно. Zstandard со стандартными настройками сжимает в 10 раз быстрее, но с CR всего 3.

Использование --long без удаления переносов дало скромное улучшение — CR 3.8. После удаления переносов (seqtk seq -l 0) CR вырос до 11. С максимальным размером окна (--long=31) CR достиг 31, уменьшив размер данных с 2.46ТБ до 80ГБ при увеличении времени сжатия на 80% по сравнению со стандартными настройками.

Хотя --long не дотягивает до специализированных методов, он предлагает хороший баланс между скоростью и эффективностью сжатия для больших файлов с повторяющимися последовательностями. Главное — предварительно удалить переносы строк.

• Удаление незначащих переносов строк в формате FASTA значительно улучшает сжатие Zstd, так как они нарушают поиск длинных совпадений.
• Zstd — байтовый компрессор, не учитывающий семантику данных, поэтому случайные переносы строк снижают его эффективность.
• Использование больших размеров окна (--long) в Zstd улучшает сжатие геномных данных, но требует больше памяти и совместимых настроек при распаковке.
• FASTA и FASTQ критикуются как неэффективные форматы, но остаются популярными из-за простоты и широкой поддержки.
• Для обработки больших геномных данных часто рекомендуется конвертировать FASTA/FASTQ в бинарные или колоночные форматы (например, Parquet).
• Создание специализированных словарей или препроцессинг данных могут значительно улучшить сжатие для специфичных структур.
• Геномные данные обладают высокой избыточностью из-за общих последовательностей у разных видов, что эффективно используется компрессорами.
• Многие инструменты биоинформатики используют внутренние бинарные форматы, но FASTA остаётся стандартом для обмена данными.
• Проблемы с устаревшими форматами и инструментами в биоинформатике частично связаны с трудностями финансирования их поддержки.

Две версии 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 размер даже немного вырос.

• Parquet разделён на две версии: v2 экономит место и ускоряет чтение, но экосистема (Spark, Iceberg, Delta Lake и др.) всё ещё в основном на v1.
• Справочная реализация — гигантская Java-библиотека с 74 000 строк кода на каждую комбинацию кодировки, что вызывает сомнения в оптимальности.
• Совместимость между библиотеками (PyArrow, Fastparquet, Spark) долго была проблемой, как и разные версии Scala в Spark.
• Даже простые оптимизации (мета-данные о сортировке) фактически не используются, а многие разработчики не знали о существовании v2.
• Несмотря на критику, Parquet всё равно крупный шаг вперёд по сравнению с предыдущими форматами, и вопросы скорее в медленной эволюции стандарта, чем в самой идее.