На хабре публикация [1] про Quite OK Image [2] проект по быстрому сжатию изображений который сравнивают с форматом PNG, на самом деле, давно устаревший для Web'а и заменённый .webp и сравнения очень условные. Автор и сам признается что ничего не понимает в криптографии и просто решил сделать эксперимент, но внезапно "обрел славу" изобретателя нового формата. При том что сложного алгоритма там нет, а лишь доработанный формат RLE (Run length encoding), с некоторыми неплохими идеями, правда.

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

Где это действительно применимо - это малые изображения, до 64 килобайт и особенно в играх где не популярен формат webp. Разработчики игр, правда, давно уже используют разнообразные собственные форматы хранения спрайтов и отдельных графических элементов.

В общем и целом ажиотаж не обоснован. А из интересных, необычных, алгоритмов и инструментов сжатия я могу посоветовать посмотреть Precomp [2] утилита от Кристиана Шнаадера по пере-сжатию архивов, иногда может уменьших существующий архив в несколько раз через пересжимание содержимого архива более эффективными алгоритмами. А также посмотреть на промежуточных победителей Global Data Compression Competitions 2021 (GDCC) [4] там много очень интересных проектов/решений/алгоритмов, как правило довольно сложных. И почти во всех случаях экспериментальных, практически не используемых в промышленных системах.

Между прочим, для хранения данных проблемы компрессии также крайне актуальны и, если для оперативных данных используются, в основном, lz4, gzip, xzip, bzip2, то для долгосрочной архивации структурированных данных могут быть и другие алгоритмы, дающие лучшее сжатие с приемлимой скоростью.

Ссылки:
[1] https://habr.com/ru/news/t/591577/
[2] https://phoboslab.org/log/2021/11/qoi-fast-lossless-image-compression
[3] http://schnaader.info/precomp.php
[4] https://www.gdcc.tech/

#compression #algorithms

Одна из интересных ниш для стартапов сейчас - это использование ИИ для сокращения объёмов хранения данных и повышения эффективности хранилищ. Стартап Densify [1] позволяет провести такую оптимизацию с обещанием сокращения расходов на хранение в облаках до 80%. Другой стартап Cast AI [2] помогает оптимизировать облачную инфраструктуру на AWS, Azure или GCP.

Другой взгляд на эту же проблему и тоже через ИИ - это стартапы по созданию алгоритмов сжатия изображений, также, с ИИ. Vance AI [3] и Compression AI [4] декларируют сжатие изображение лучше всех остальных алгоритмов. Сжатие, конечно, всегда с потерями (lossy compression), но визуально это незаметно.

Есть похожие проекты для видео, также повышающие качество сжатия.

В ситуации когда, например, в России ожидается дефицит систем хранения и растёт цена за облачное хранение файлов такие алгоритмы и подходы будут как никогда кстати.

Ссылки:
[1] https://venturebeat.com/2018/03/06/densify-uses-ai-to-cut-businesses-cloud-spending-by-up-to-80/
[2] https://venturebeat.com/2021/10/12/cloud-optimization-startup-cast-ai-raises-10m/
[3] https://vanceai.com/image-compressor/
[4] https://compression.ai/

#ai #data #startups #compression

Для тех кто любит сжатие данных также как это люблю я, подборка полезных ссылок:
- про сжатие CSV файла в 22 ГБ в 1.5 ГБ файла Parquet [1] включает преобразование структур данных, сжатие zstd внутри файла parquet и тд. Для сравнения оригинальный сжатый файл был около 12GB. Для работы на ноутбуках и десктопах может быть значимо.
- Bzip3 [2] автор позиционирует как замену Bzip2. Сжимает существенно лучше чем Bzip2, немного лучше чем Xz и 7Zip (LZMA2), при этом не существенно теряет в скорости. В общем надо измерять.
- PLZip [3] и LZTurbo [4] два особо быстрых декомпрессора для lzip и lz77 соответственно, важно когда скорость сжатия некритична, а скорость распаковки важна

Ссылки:
[1] https://medium.com/@deephavendatalabs/the-r-place-dataset-bf4b0d70ce72
[2] https://github.com/kspalaiologos/bzip3
[3] https://www.nongnu.org/lzip/plzip.html
[4] https://sites.google.com/site/powturbo/home

#compression #tools #opensource

Про сжатие данных и о том почему я регулярно пишу что Parquet - это реально значимый формат хранения и обмена данными, важнее довольно многих.

Я приведу в пример данные с которыми я лично работал в аналитических задачах. У меня есть выгрузка слепка данных из российского реестра юридических лиц ЕГРЮЛ в виде 11 миллионов записей в которых 12 полей-признаков места организации, её типа, кода окопф, оквэд, кладр, статус ликвидации и тд. Без названий и без идентификаторов, данные нужны только для аналитической работы и построения кубов и срезов для BI. В общеё сложности - это 4.07ГБ. Не очень много когда один файл и много когда таких файлов десятки. С файлом нужно иметь возможность работать, загружать в СУБД или библиотеку вроде Pandas. Как сжать эти данные?

Самое очевидное - это сжать классическими архиваторами и хранить так. Gzip даёт сжатие до 337 МБ это примерно 8.3%, альтернативный Gzip'у архиватор LZ4 для быстрого сжатия и разжатия даёт компрессию до 340МБ это тоже примерно 8.3%, а LMA-архивация с помощь. XZ даёт 136МБ это примерно 3%, но она работает значительно медленнее. Все архиваторы проверялись в режиме максимального сжатия (ключ -9).

Так вот, а если этот же CSV файл преобразовать в parquet формат со сжатием, то итоговый файл получается размером в 109МБ, это примерно 2.7% от оригинального и, при этом, с ним весьма удобно работать с инструментами вроде Pandas при том что скорость преобразования значительно быстрее чем сжатие с помощью xz, к примеру. Во многом, похоже, это происходит из-заавтоматической идентификации типов полей и их преобразования.

Причём даже если повторить используемый в parquet трюк с колоночным сжатием, так просто такой результат повторить непросто. Например, у меня есть код который из CSV файла создаёт пучёк одноколоночных CSV файлов сжатие которых по отдельности должно быть лучше чем сжатие оригинального файла. Сжатые одноколоночные файлы дают дополнительное сжатие. GZIP файлы таких файлов занимают 221 МБ вместо 337 МБ. Аналогично для lz4 и только для xz размер общий файлов увеличивается до 139 МБ.

Конечно никто такие одноколочные файлы не делает, это трюк из давнего прошлого, я привожу его исключительно как иллюстрацию. Речь о том что Parquet файл значительно меньше и практичнее в общим случаях.

Отдельная история про сжатие данных для долгосрочного хранения и для сохранения интеграции с унаследованными системами. Тем не менее, имея выбор формата для хранения данных - Parquet это хороший выбор.

Для того чтобы он стал отличным ему нехватает только некоторых опций работы стандартными инструментами. Чтобы его можно было открыть в Excel, в браузере, в чтобы были аналоги grep/cat/awk/sed или csvkit и ещё много разных других инструментов. Тем не менее и сейчас его уже можно использовать.

#dataengineering #data #compression #parquet

Чем с больше данных тем больше потребности в их эффективном сжатии. Из любопытных продуктов на эту тему:
- llama-zip - LLM-powered lossless compression tool, как уже понятно использует языковую модель LLAMA для сжатия текстов на английском языке. Работает только с текстами, сжимает как-то совсем неимоверно судя по примерам. Хочется дождаться его внешнего тестирования и сравнений с другими.
- ts_zip архиватор от Fabrice Bellard работающий с помощью встроенной языковой модели RWKV 169M v4 . Автор известен тем что создал NNCP, компрессор и прекомпрессор на основе нейросетей и побеждающий несколько лет в конкурсе Large Text Compression Benchmark

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

1. Если у данных есть предопределённые схемы то самый эффективный способ их отдавать - это Parquet.
2. Если хранение данных вообще ничем не ограничено, то сохранять в JSONL
3. Если данные нужны для аналитики и их хочется сохранять сжатыми, то форматы gz, br, xz, zst, lz4 и bz2 если их обрабатывать в Clickhouse и в формате gz если в DuckDB. Фактически надо использовать сжатие GZip'ом при всех его недостатках.
4. Для холодного хранения можно сжимать чем угодно дающим хорошее сжатие, например xz, bz2 или 7z


#thoughts #compression #data #datatools