Чем сжатие без потерь отличается от удаления строк, почему результат зависит от содержимого и как сравнивать размер вместе со временем чтения.
Файл стал меньше — что произошло с таблицей
Аналитик получил выгрузку заказов и заметил, что после сохранения её размер уменьшился. Возникает естественный вопрос: не исчезла ли часть записей? Размер файла и число записей описывают разные свойства. Первый показывает объём представления данных, второй — сколько объектов или событий в нём содержится.
Сжатие без потерь меняет способ представления содержимого так, чтобы его можно было восстановить. Оно позволяет хранить некоторые данные компактнее. Удаление строк, выборка за короткий период или округление значений — другие операции, и их нельзя называть тем же результатом.
Почему повторения помогают экономить место
Представьте условный список из ста заказов, в которых название одного города повторяется много раз. Вместо буквального повторения длинных фрагментов компактное представление может использовать закономерности и короткие обозначения. Это упрощённая аналогия, а не описание конкретного алгоритма.
Чтобы восстановить исходное содержимое, получателю нужен совместимый способ чтения. В спецификации GZIP формат прямо описан как сжатие без потерь. Такая гарантия относится к восстановлению представленного содержимого: она не подтверждает правильность исходных заказов или бизнес-логики отчёта.
Условный пример двух объёмов
Допустим, учебная выгрузка содержит тысячу записей и занимает десять мегабайт. После сжатия она занимает четыре мегабайта. Число записей остаётся равным тысяче, если исходные данные восстановлены полностью. Объём хранения уменьшился на шесть мегабайт, то есть на шестьдесят процентов.
Если другой файл занял те же четыре мегабайта после удаления шестисот записей, это уже другая история: в нём осталось четыреста записей. Одинаковый размер не делает наборы одинаковыми. Проверять нужно и объём, и содержимое.
Для такой проверки в учебном примере сравнивают число записей, выбранные значения и контрольные итоги после чтения. Сжатие не должно незаметно превращать точные суммы в приближённые или выбрасывать неизвестные значения. Если это произошло, ищут отдельное преобразование данных.
Сжатие может быть частью файлового формата
Табличный формат иногда поддерживает сжатие внутри файла. Например, спецификация Parquet описывает разные способы сжатия блоков данных. Поэтому название формата ещё не сообщает, каким способом сжато содержимое.
Важна совместимость: система, которая пишет данные, и система, которая читает их, должны поддерживать используемый вариант. При обмене наборами стоит фиксировать не только имя файла, но и требования к его чтению. Это особенно полезно, когда данные передаются между разными инструментами и командами.
Почему меньше не всегда означает быстрее
Компактные данные занимают меньше места и требуют передать меньше байтов. Но на их преобразование и восстановление тоже расходуются вычислительные ресурсы. Итоговое время зависит от состава данных, устройства хранения и выбранного способа обработки.
Авторы Zstandard описывают компромисс между скоростью сжатия и получаемым размером. Из этого не следует универсальное правило, что максимальное сжатие всегда выгоднее. Для конкретного набора нужен проверяемый результат, а не только красивый процент экономии.
В условном испытании два варианта могут одинаково восстанавливать тысячу записей, но отличаться временем записи и последующего чтения. Команда выбирает подходящий вариант под свою задачу: архив, регулярный обмен или часто используемый аналитический набор. Универсальный победитель для всех этих случаев не обязателен.
Что сравнить на небольшом примере
- Совпало ли восстановленное содержимое?
- Как изменился размер в байтах?
- Сколько времени занимает запись и чтение?
- Поддерживает ли получатель выбранный вариант?
- Соответствует ли проверочный набор настоящим данным?
Так сжатие становится понятным выбором представления, а не поводом сомневаться в количестве заказов по одному размеру файла. Сохранность содержимого проверяют отдельно от экономии места.
Как перейти к практике
Если хотите понимать, как такие решения работают в проектах, посмотрите Архитектор данных. Начните с назначения механизмов, затем связывайте их с задачами вашей команды.
