Сжатие данных *

Проект Trino (ранее PrestoSQL) изначально разработан в Meta, чтобы аналитики могли выполнять интерактивные запросы по широкому спектру хранилищ данных на базе Apache Hadoop. Благодаря эффективной обработке крупных наборов и сложных запросов, а также гибкому подключению к множеству источников данных, Trino быстро стал предпочтительным инструментом аналитики для крупных организаций.

Со временем потребности пользователей в аналитике эволюционировали. С ростом мобильного интернета и SaaS-приложений критически важной стала оперативная (в том числе потоковая) аналитика. Компаниям потребовались более производительные движки, поддерживающие большое число одновременных запросов и обеспечивающие низкие задержки. На этом фоне всё больше пользователей стали искать альтернативы.

StarRocks как новый аналитический движок получил широкое признание отрасли. Он демонстрирует заметные преимущества по производительности, поддержке высокой степени параллелизма и низкой задержке, привлекая внимание крупных компаний, таких как WeChat , Xiaohongshu (RedNote), Ctrip, Beike и др. Как именно StarRocks формирует свои преимущества? В чём его сходства и различия с Trino? Ниже — подробный разбор.

Привет! Я Рома, бэкендер-питонист в KTS.

Это вторая статья в моем цикле об алгоритме архивации bzip2. Первую можно прочитать здесь, но для понимания сегодняшней темы она необязательна. Ниже я разберу преобразование Барроуза-Уилера — ключевой этап сжатия bzip2.

Хранение 1 ГБ данных в облаке стоит от 2 до 12 рублей. Можно ждать, пока диски подешевеют, а можно сжать данные и получить «бесплатный» апгрейд хранилища. Но если вы храните данные в облаке, сжимать все подряд — как пытаться загрузить стиральную машинку не глядя: льняные брюки могут сесть в 5 раз и освободить место, но если кинуть в барабан кирпич, меньше он не станет, зато вы получите грохот, счет за электричество, недовольных соседей и возможно — сломанную машинку. 

Чтобы не потратить кучу CPU с сомнительным результатом, мы у себя в команде R&D Cloud.ru решили исследовать, как сделать сжатие оптимальным, чтобы не тратить время на упаковку того, что сжатию не поддается и эффективно расходовать вычислительные ресурсы.

Я Александр Аксенов, мой профиль — оптимизация хранения данных и мне есть что вам рассказать про то, как ускорить процесс сжатия до 80 раз, сэкономить CPU и сохранить качество. Звучит как кликбейт (так оно и есть 😃), но почему это технически правда и может пригодиться вы узнаете из статьи. Надеюсь, мои выводы окажутся полезными всем, кто работает с данными, в особенности инженерам СХД, DevOps, разработчикам распределенных систем и архитекторам облачных решений.

В части 1 и части 2 мы подробно рассмотрели процесс создания загрузочного образа RDP-клиента на базе Debian 12. В результате у нас получился готовый к использованию образ, который можно записать на USB-носитель или установить на жёсткий диск.

В некоторых случаях требуется уменьшить размер виртуального диска — не просто сжать образ, а физически уменьшить объём виртуального qcow2-диска.

Самый надёжный способ — создать новый образ с меньшим диском и перенести туда систему.

1. Назначение

CJON – это легковесный, компактный и человекочитаемый формат, предназначенный для использования в условиях ограниченных каналов связи, таких как SMS, DTMF, и низкоскоростная радиосвязь. Его основное назначение – передача структурированных телеметрических или управляющих данных в случаях, когда традиционный JSON слишком объёмен, а бинарные форматы непрактичны или плохо читаемы.

2. Области применения

• Дистанционная телеметрия для сельского хозяйства и промышленного оборудования
• Аварийные сообщения и тревоги
• Автоматизация в условиях низкоскоростной или оффлайн-связи
• Мобильные устройства, передающие структурированные данные через SMS или голосовую связь
• Передача данных по DTMF через GSM-сети

Недавно опубликованная третья редакция спецификации Portable Network Graphics (PNG) 2025 года, разработанная World Wide Web Consortium (W3C), привлекла внимание к эволюции этого формата (W3C PNG Specification (Third Edition, 2025)). Ранее я, как и многие, использовал PNG, не задумываясь о его развитии и различных редакциях. Углубившись в изучение спецификаций PNG (1996, 2003, 2025), я решил подготовить данную статью, чтобы обобщить ключевые изменения и их значение для веб-дизайна, разработки игр и мультимедиа. Статья не претендует на исчерпывающий охват, но стремится предоставить полезный обзор для всех заинтересованных, включая начинающих. Приветствуются любые замечания и предложения по улучшению материала в комментариях к публикации. Весь код, приведённый ниже, выложил в репозиторий. Надеюсь, чтение будет полезным и увлекательным.

Современные большие языковые модели впечатляют, но остаются громоздкими и статичными. В ближайшие годы мы перейдём от таких «гигантов» к персональным ИИ-спутникам: компактным и обучаемым на ходу. Ключ к этому — долговременная память (mem-векторы), модульные трансформеры, параметро-эффективное дообучение, внешние базы знаний и жёсткая оптимизация под локальное железо. Разбираем, какие технологии уже работают, какие ещё только вырастают из лабораторий и что ждёт нас завтра.

Каждый, кто работал с большими языковыми моделями (LLM), знает про ограничение длины контекста: модель не может напрямую обработать текст, превышающий определённое число токенов. Это накладывает ограничения на работу с длинными документами и обширным контекстом. Но что если бы мы могли упаковать длинный текст в один-единственный вектор и скормить его модели как обычный токен? Звучит фантастично, однако свежие исследования показывают, что это возможно – такие “mem-векторы” позволяют сохранить сотни и даже полторы тысячи токенов информации в одном эмбеддинге. Это принципиально иной подход, нежели классическое сжатие данных, и он сулит интересные применения.

Mem-вектор (от “memory vector”) – это специально обученный вектор, который хранит содержание целого текста. Идея в том, что если модель умеет предсказывать текст, то можно подобрать такой вектор на входе, при котором замороженная (неизменяемая) LLM сама декодирует исходный текст. Иначе говоря, mem-вектор играет роль «семени», из которого предобученная модель порождает заложенное в нём сообщение. В этой статье разберём, как это работает, почему вообще возможно “запихнуть” роман в один вектор и какие ограничения при этом появляются. Также сравним mem-подход с классическими алгоритмами сжатия (Huffman, арифметическое кодирование, zlib и др.), обсудим последние научные работы на эту тему и возможные применения: от Retrieval-Augmented Generation (RAG) до передачи новых знаний замороженным моделям. Центральная мысль: mem-векторы – это не просто компрессия текста, а способ напрямую скормить модели смысл и знания, минуя последовательное чтение токенов.

Давайте разберёмся в том, как работает новый метод квантования больших языковых моделей HIGGS (Hadamard Incoherence with Gaussian MSE-optimal GridS)

Как экономить до 90% оперативной памяти при загрузке pandas DataFrame из базы данных?

Сравним различные способы выгрузки данных и найдем метод для снижения потребления оперативной памяти.

Недавно прочитал статью на Пикабу про бесконечное сжатие, где предлагалось создать словарь 3-х байтовых блоков, и представлять информацию в виде ссылок на эти блоки. Понял что выигрыша в этом нет, но идея передавать не саму информацию, f что-то другое, меня зацепила. Начал размышлять, допустим демон на дне океана перекусывает нитку оптоволокна и смотрит как туда сюда бегут 1 и 0. Какой в них смысл? Одно и тоже. И правда как извлечь смысл из этого однообразия. А здесь вступают в игру фактор времени и договоренности. То есть добавляются дополнительные измерения о которых демон не знает. Стартовые, стоповые биты, длина пакета.

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

Как уместить словарь размером 250 КБ в 64 КБ ОЗУ с возможностью выполнения быстрого поиска? Для справки: даже современные методики сжатия наподобие gzip -9 не могут сжать этот файл до размера меньше 85 КБ.

В 1970-х Дуглас Макилрой столкнулся с этой непростой задачей при реализации проверки правописания для Unix в AT&T. Из-за ограничений компьютера PDP-11 весь словарь должен был умещаться всего в 64 КБ ОЗУ. Кажется, подобную задачу решить невозможно.

Вместо того, чтобы использовать стандартные методики сжатия, Дуглас воспользовался преимуществами свойств данных, разработав алгоритм сжатия, отличавшийся от теоретического минимума сжатия всего на 0,03 бита. И по сей день этот рекорд остаётся непревзойдённым.

История spell в Unix — это не только любопытный исторический факт. Это мастер-класс по проектированию в условиях жёстких ограничений: анализа первооснов задачи, применения математических наблюдений и проектирования изящных решений, работающих в условиях строгого дефицита ресурсов.

Привет! Меня зовут Михаил Мазанов, я отвечаю за технологический стек работы с медиаданными в Кинопоиске: от съёмок оригинальных проектов до доставки и просмотра видео на всех экранах. Для нашей пятой ежегодной конференции про стриминг PlayButton 2024 я готовил большой доклад про оптимизацию качества видео Кинопоиска, а для Хабра решил пересобрать его в виде статьи — для тех, кому текстовый формат предпочтительнее видео.

Кроме технических графиков, вас ждёт ещё и наглядная разница в работе алгоритмов сжатия на примере «Рика и Морти» и «Джона Уика».

Привет, Хабр! Меня зовут Александр Крестинин, я разработчик встроенного ПО в компании Whoosh. Мы в embedded-команде не только переливаем биты из одного регистра в другой, но и решаем разные бизнес-задачи. Иногда попадаются головоломки. 

Однажды мы подумали, что было бы здорово выводить на экраны самокатов анимации и изображения — показывать инструкции, как пользоваться сервисом, как начать и закончить поездку, и чтобы запускать DOOM.

Зачем?

1) Сделать комфортнее. Удобно видеть инструкции на большом и ярком экране перед глазами, а не нырять за ними в приложение на смартфоне. 

2) Сделать безопаснее. Пользователь меньше отвлекается на телефон, крепче держится за самокат и внимательнее смотрит на всё, что вокруг.

3) Почти у всех привычных устройств уже есть экраны, которые выводят пользователям видео и картинки, а почему бы не сделать то же самое на самокате?

Но тут возникает проблема. Микроконтроллер крайне ограничен в памяти и вычислительных ресурсах. Самая простая анимация занимает чрезмерно много места. А если внедрить в отрисовку алгоритмы сжатия, то вычислительная нагрузка увеличится и анимация будет сильно лагать.

Расскажу, как мы нашли решение этой задачи. Прошу под кат.

В этой статье я поделюсь своим опытом и еще некоторыми утилитами

Вообще меня побудило написать эту статью прохождение курса Базовый курс по CTF на онлайн платформе Stepik, он бесплатный и по окончании выдается сертификат (это не реклама, а совет).

Перейдем непосредственно к утилитам.

Я уже подготовил файл «нашпигованый» двумя стегоконтейнерами. Файл скриншота рабочего стола 1.jpg

Проверим его наличие на рабочем столе ls.

Сегодня я хотел бы познакомить читателей Хабра с цифровой стеганографией. В нынешнем примере мы создадим, протестируем, проанализируем и взломаем стегосистемы. Я использую операционную систему Kali GNU/Linux, но кому интересна тема на практике, тот может повторить все то же в любом другом дистрибутиве Линукс.
Но для начала совсем немного теории.