Сжатие данных в примерах

Теория и стратегия представления данных

Девид Мертц (David Mertz) (mertz@gnosis.cx) 19.04.2012

Разработчик
Gnosis Software, Inc.

Эта статья представляет собой учебник для начинающих по основным типам сжатия
данных, содержащий вводное объяснение математических методов и алгоритмов,
используемых в технологиях сжатия. В статье приводятся краткое рассмотрение
вопросов и примеры, призванные помочь вам в выборе подходящих инструментальных
средств и методов сжатия для ваших приложений. Статья содержит ссылки на более
широкие теоретические обсуждения и готовые к использованию инструментальные
средства и библиотеки для сжатия данных. Обновление: Таблицы 1 и 2 были обновлены
для исправления ошибок форматирования. – ред.

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

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

Правильный выбор инструментальных средств и библиотек сжатия для конкретного

приложения зависит от характеристик данных и назначения самого приложения: потоковой
передачи данных или работы с файлами; ожидаемых шаблонов и закономерностей в
данных; относительной важности использования ресурсов ЦП и памяти, потребностей в
каналах передачи и требований к хранению и других факторов.

Что понимается под сжатием данных? Если говорить кратко, то сжатие устраняет из
данных избыточность; в терминах же теории информации сжатие увеличивает энтропию
сжатого текста. Однако оба этих утверждения по существу по существу верны в силу
определения самих понятий. Избыточность может быть выражена в самых разных формах.
Одним типом является последовательности повторяющихся битов (11111111). Вторым
– последовательности повторяющихся байтов (XXXXXXXX). Однако чаще избыточность
проявляется в более крупном масштабе и выражается либо закономерностями в наборе
данных, взятом как единое целое, либо последовательностями различной длины,
имеющими общие признаки. По существу, цель сжатия данных заключается в поиске

© Copyright IBM Corporation 2012 Торговые марки

Сжатие данных в примерах Страница 1 из 9
developerWorks® ibm.com/developerWorks/ru/

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

компактные представления «типовых» наборов данных. Это описание может показаться
несколько туманным, но мы постараемся раскрыть его суть на практических примерах.

Сжатие без потерь и с потерями

Фактически существуют два в корне различающихся подхода к сжатию данных: сжатие
с потерями и без потерь. Эта статья, в основном, посвящена методам сжатия без
потерь, но для начала полезно изучить различия. Сжатие без потерь предусматривает
преобразование представления набора данных таким образом, чтобы затем можно было в
точности воспроизвести первоначальный набор данных путем обратного преобразования
(распаковки). Сжатие с потерями – это представление, которое позволяет воспроизводить
нечто «очень похожее» на первоначальный набор данных. Преимущество использования
методов сжатия с потерями заключается в том, что они зачастую позволяют получать
намного более компактные представления данных по сравнению с методами сжатия без
потерь. Чаще всего методы сжатия с потерями применяются для обработки изображений,
звуковых файлов и видео. Сжатие с потерями в этих областях может оказаться уместным
благодаря тому, что человек воспринимает битовую комбинацию цифрового изображения/
звука не с «побитовой» точностью, а скорее оценивает музыку или изображение в целом.

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

нужна программа, которая делает «примерно» то, а не точно то, что было запрошено
в действительности. То же касается и баз данных, которые должны хранить именно те
данные, которые были в них загружены. По крайней мере, это не подойдет для решения
большинства задач (и мне известно очень мало практических примеров использования
сжатия с потерями за пределами тех данных, которые сами по себе описывают чувственное
восприятие реального мира (например, изображений и звуков)).

Пример набора данных

В данной статье будет использоваться специально подготовленное гипотетическое
представление данных. Приведем простой для понимания пример. В городе Гринфилд
(штат Массачусетс, США) используются префиксы телефонных номеров 772-, 773- и 774-.
(К сведению читателей за пределами США: в США местные телефонные номера являются
семизначными и традиционно представляются в виде ###-####; префиксы назначаются
в соответствии с географическим местоположением). Также предположим, что из всех
трех префиксов чаще всего используется первый. Частями суффикса могут быть любые
другие цифры с приблизительно равной вероятностью. Набор интересующих нас данных
находится в «списке всех телефонных номеров, которые в настоящее время находятся в
активном пользовании». Можно попробовать подобрать причину, почему это могло бы быть
интересным с точки зрения программирования, но в данном случае это не важно.

Изначально интересующий нас набор данных имеет стандартное представление:

многоколоночный отчет (возможно, сгенерированный в качестве результата выполнения
какого-либо запроса или процесса компиляции). Первые несколько строк этого отчета могли
бы выглядеть следующим образом:

Сжатие данных в примерах Страница 2 из 9

ibm.com/developerWorks/ru/ developerWorks®

Таблица 1. Многоколоночный отчет

=============================================================
772-7628 772-8601 772-0113 773-3429 774-9833
773-4319 774-3920 772-0893 772-9934 773-8923
773-1134 772-4930 772-9390 774-9992 772-2314
[...]

Сжатие пустых мест

Сжатие пустых мест может быть охарактеризовано в более общем смысле как «удаление
того, что нас не интересует». Даже несмотря на то, что этот метод с технической точки
зрения представляет собой метод сжатия с потерями, он все равно полезен для многих
типов представлений данных, с которыми мы сталкиваемся в реальном мире. Например,
даже несмотря на то, что HTML намного удобнее читать в текстовом редакторе при
добавлении отступов и междустрочных интервалов, ни одно из этих «пустых мест» никак
не влияет на визуализацию HTML-документа в Web-браузере. Если вам точно известно,
что конкретный документ HTML предназначается исключительно для Web-браузера (или
для какого-либо робота/поискового агента), то, возможно, будет неплохо убрать все пустые
места, чтобы документ передавался быстрее и занимал меньше места в хранилище.
Все то, что мы удаляем при сжатии пустых мест, в действительности не несет никакой
функциональной нагрузки.

В случае с представленным примером из описанного отчета можно удалить лишь

небольшую часть информации. Строка символов «=» по верхнему краю отчета не несет
никакого функционального наполнения; то же самое касается символов «-» в номерах и
пробелов между номерами. Все это полезно для человека, читающего исходный отчет, но
не имеет никакого значения, если мы рассматриваем эти символы в качестве «данных». То,
что мы удаляем, – это не совсем «пустое место» в традиционном смысле, но является им по
сути.

Сжатие пустых мест крайне «дешево» с точки зрения реализации. Вопрос состоит лишь
в считывании потока данных и исключении из выходного потока нескольких конкретных
значений. Во многих случаях этап «распаковки» вообще не предусматривается. Однако
даже если бы мы захотели воссоздать что-то близкое к оригиналу потока данных, это
потребовало бы лишь небольшого объема ресурсов ЦП или памяти. Восстановленные
данные не обязательно будут совпадать с исходными данными; это зависит от того, какие
правила и ограничения содержались в оригинале. Страница HTML, напечатанная человеком
в текстовом редакторе, вероятно, будет содержать пробелы, расставленные согласно
определенным правилам. Это же относится и к автоматизированным инструментальным
средствам, которые часто создают «обоснованные» отступы и интервалы в коде HTML.
В случае с жестким форматом отчета, представленным в нашем примере, не существует
никаких причин, по которым первоначальное представление не могло бы быть воссоздано
каким-либо «форматирующим распаковщиком».

Групповое кодирование
Групповое кодирование (RLE) является простейшим из широко используемых методов
сжатия без потерь. Подобно сжатию пустых мест, оно не требует особых затрат, особенно

Сжатие данных в примерах Страница 3 из 9

developerWorks® ibm.com/developerWorks/ru/

для декодирования. Идея, стоящая за данным методом, заключается в том, что многие
представления данных состоят большей частью из строк повторяющихся байтов. Наш
образец отчета является одним из таких представлений данных. Он начинается со строки
повторяющихся символов «=» и имеет разбросанные по отчету строки, состоящие только
из пробелов. Вместо того чтобы представлять каждый символ с помощью его собственного
байта, метод RLE предусматривает (иногда или всегда) указание количества повторений, за
которым следует символ, который необходимо воспроизвести указанное число раз.

Если в обрабатываемом формате данных преобладают повторяющиеся байты, то может

быть уместным и эффективным использование алгоритма, в котором один или несколько
байтов указывают количество повторений, а затем следует повторяемый символ. Однако
если имеются строки символов единичной длины, для их кодирования потребуются два
(или более) байта. Другими словами, для одного символа ASCII «X» входного потока мог
бы потребоваться выходной битовый поток 00000001 01011000. С другой стороны, для
кодирования ста следующих друг за другом символов «X» использовалось бы то же самое
количество битов: 01100100 01011000, что весьма эффективно.

В различных вариантах RLE часто применяется избирательное использование байтов для

указания числа повторений, в то время как остальные байты просто представляют сами
себя. Для этого должно быть зарезервировано как минимум одно однобайтовое значение,
которое в случае необходимости может удаляться из выходных данных. Например, в нашем
образце отчета по телефонным номерам известно, что вся информация во входном потоке
состоит из простых символов ASCII. В частности, у всех таких символов первый бит ASCII-
значения равен 0. Мы могли бы использовать этот первый бит ASCII для указания на то,
что байт указывает число повторений, а не обычный символ. Следующие семь битов байта
итератора могли бы использоваться для указания числа повторений, а в следующем байте
мог бы содержаться повторяющийся символ. Так, например, мы могли бы представить
строку «YXXXXXXXX» следующим образом:
"Y" Iter(8) "X"
01001111 10001000 01011000

Этот пример не объясняет, как отбрасывать значения байта итератора и не предусматривает

возможности использования более 127 повторений одного символа. Однако различные
вариации RLE при необходимости решают и эти задачи.

Кодирование по методу Хаффмана

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

Сжатие данных в примерах Страница 4 из 9

ibm.com/developerWorks/ru/ developerWorks®

закодированной последовательности встречается 0, это значит, что на этом месте находится

другой символ, закодированный большим количеством бит.

Представим, что мы применили кодирование по методу Хаффмана для кодирования нашего

примера (предположим, что мы уже подвергли отчет сжатию пустых мест). Мы могли бы
получить следующий результат:

Таблица 2. Результаты кодирования по методу Хаффмана

Encoding Symbol
1 7
010 2
011 3
00000 4
00001 5
00010 6
00011 8
00100 9
00101 0
00111 1

Исходный набор символов (состоящий из чисел) может быть легко закодирован (без сжатия)
в виде 4-х битных последовательностей (полубайтов). Приведенное кодирование по методу
Хаффмана будет использовать до 5 битов для символов в наихудшем случае, что очевидно
хуже кодирования с помощью полубайтов. Однако в лучшем случае потребуется всего 1
бит; при этом известно, что именно лучший случай будет использоваться чаще всего (так
как именно этот символ чаще всего встречается в данных). Таким образом, мы могли бы
закодировать конкретный телефонный номер следующим образом:
772 7628 --> 1 1 010 1 00010 010 00011

При кодировании с помощью полубайтов представление телефонного номера заняло бы 28

бит, в нашем же случае кодирование занимает 19 бит. Пробелы добавлены в пример только
для лучшего восприятия; их присутствие в кодированных символах не требуется, так как по
таблице кодов всегда можно определить, достигнут конец закодированного символа или нет
(правда, при этом все равно необходимо отслеживать текущую позицию в данных).

Кодирование по методу Хаффмана по-прежнему является очень «дешевым» для

декодирования с точки зрения процессорного времени. Однако оно требует поиска в
таблице кодов, поэтому не может быть столь же «дешевым», как RLE. Кодирование по
методу Хаффмана является довольно затратным, так как требует полного сканирования
данных и построения таблицы частот символов. В некоторых случаях при использовании
кодирования по методу Хаффмана уместным является «короткий путь». Стандартное
кодирование по методу Хаффмана применяется к конкретному кодируемому набору
данных, при этом в выходных данных вначале следует таблица символов. Однако если
передается не одиночный набор данных, а целый формат с одинаковыми закономерностями
встречаемости символов, то можно использовать глобальную таблицу Хаффмана. При
наличии такой таблицы мы можем жестко запрограммировать поиск в своих исполняемых
файлах, что значительно «удешевит» сжатие и распаковку (за исключением начальной
глобальной дискретизации и жесткого кодирования). Например, если мы знаем, что наш

Сжатие данных в примерах Страница 5 из 9

developerWorks® ibm.com/developerWorks/ru/

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

Сжатие по алгоритму Лемпеля-Зива

Вероятно, самым значимым методом сжатия без потерь является алгоритм Лемпеля-Зива.
В этой статье речь пойдет о варианте LZ78, но LZ77 и другие варианты работают схожим
образом. Идея, заложенная в алгоритме LZ78, заключается в кодировании потоковой
последовательности байтов с использованием некоторой динамической таблицы. В начале
сжатия битового потока таблица LZ заполняется фактическим набором символов, наряду
с несколькими пустыми слотами. В алгоритме применяются таблицы разных размеров,
но в данном примере с телефонными номерами (со сжатием пустых мест) используется
таблица из 32 элементов (этого достаточно для данного примера, но может оказаться
мало для других типов данных). Вначале мы заполняем первые десять слотов символами
используемого алфавита (цифрами). По мере поступления новых байтов сначала выводится
значение из таблицы, соответствующее самой длинной подходящей последовательности,
а затем в следующий доступный слот записывается последовательность длиной N+1. В
наихудшем случае мы используем 5 битов вместо 4 для отдельного символа, однако в
большинстве случаев мы сможем обойтись 5 битами на несколько символов. Рассмотрим
пример работы этого алгоритма (слот таблицы указан в квадратных скобках):
7 --> Поиск: 7 найдено --> добавлять нечего --> продолжить поиск
7 --> Поиск: 77 не найдено --> добавить '77' to [11] --> вывести [7]=00111
2 --> Поиск: 72 не найдено --> добавить '72' to [12] --> вывести [7]=00111
7 --> Поиск: 27 не найдено --> добавить '27' to [13] --> вывести [2]=00010
6 --> Поиск: 76 не найдено --> добавить '76' to [14] --> вывести [7]=00111
2 --> Поиск: 62 не найдено --> добавить '62' to [15] --> вывести [6]=00110
8 --> Поиск: 28 не найдено --> добавить '28' to [16] --> вывести [2]=00010

До сих пор мы не извлекли из этого никакой пользы, но давайте перейдем к следующему

телефонному номеру:
7 --> Поиск: 87 не найдено --> добавить '87 to [17] --> вывести [8]=00100
7 --> Поиск: 77 найдено --> добавлять нечего --> продолжить поиск
2 --> Поиск: 772 не найдено --> добавить '772' to [18] --> вывести [11]=01011
8 --> Поиск: 28 найдено --> добавлять нечего --> продолжить поиск
6 --> Поиск: 286 не найдено --> добавить '286' to [19] --> вывести [16]=10000
....

Приведенных операций должно быть достаточно для демонстрации работы модели. Хотя
никакого заметного сжатия пока не достигнуто, уже видно, что мы повторно использовали
слоты 11 и 16, закодировав по два символа одним выходным символом. Кроме того, мы уже
накопили крайне полезную последовательность байтов 772 в слоте 18, которая впоследствии
неоднократно будет встречаться в потоке.

Алгоритм LZ78 заполняет одну таблицу символов полезными (предположительно) записями,

затем записывает эту таблицу, очищает ее и начинает новую. В такой ситуации таблица
из 32 символов может оказаться недостаточной, так как будет очищена прежде, чем
нам удастся неоднократно воспользоваться такими последовательностями, как 772 и ей

Сжатие данных в примерах Страница 6 из 9

ibm.com/developerWorks/ru/ developerWorks®

подобные. Однако с помощью небольшой таблицы проще проиллюстрировать работу

алгоритма.

В типичных наборах данных варианты метода Лемпеля-Зива достигают значительно более

высоких коэффициентов сжатия, чем методы Хаффмана и RLE. С другой стороны, варианты
метода Лемпеля-Зива тратят значительные ресурсы на итерации, а их таблицы могут
занимать много места в памяти. Большинство существующих инструментальных средств и
библиотек сжатия используют комбинацию методов Лемпеля-Зива и Хаффмана.

Правильная постановка задачи

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

Необходимо еще раз взглянуть на проблему, которую представляют данные. Так как это
не общий набор данных и для него существуют четкие предварительные требования,
то проблему можно переформулировать. Известно, что существует максимум 30000
телефонных номеров (от 7720000 до 7749999), некоторые из которых являются активными, а
некоторые – нет. Перед нами не стоит задача вывести полное представление всех активных
номеров. Нам просто требуется указать с помощью логического значения, активен данный
номер или нет. Размышляя о проблеме подобным образом, мы можем просто выделить
30000 битов в памяти и в системе хранения и использовать каждый бит для индикации
активности («да» или «нет») соответствующего телефонного номера. Порядок битов в
битовом массиве может соответствовать телефонным номерам, отсортированным по
возрастанию (от меньшего к большему).

Подобное решение на основе битового массива идеально со всех точек зрения. Оно требует
ровно 3750 байт для представления набора данных; различные методы сжатия будут
использовать меняющийся объем в зависимости от количества телефонных номеров в
наборе и эффективности сжатия. Однако если 10000 из 30000 возможных телефонных
номеров являются активными и если даже самому эффективному методу сжатия требуется
несколько байтов на один телефонный номер, то битовый массив однозначно выигрывает.
С точки зрения потребностей в ресурсах ЦП битовый массив не только превосходит
любой из рассмотренных методов сжатия, но и оказывается лучше, чем обычный метод
представления телефонных номеров в виде строк (без сжатия). Проход по битовому массиву
и увеличение счетчика текущего телефонного номера могут эффективно выполняться даже
во встроенном кэше современных процессоров.

Из этого простого примера можно понять, что далеко не каждая проблема имеет такое
идеальное решение, как рассмотренная выше. Многие проблемы действительно требуют
использования значительного объема ресурсов памяти, пропускной способности, хранилища

Сжатие данных в примерах Страница 7 из 9

developerWorks® ibm.com/developerWorks/ru/

и ЦП; и в большинстве подобных случаев методы сжатия могут облегчить или снизить
эти требования. Но более важный вывод состоит в том, что перед применением методов
сжатия стоит еще раз удостовериться, что для представления данных выбрана правильная
концепция.

Посвящается памяти Клода Шеннона (Claude Shannon).

Сжатие данных в примерах Страница 8 из 9

ibm.com/developerWorks/ru/ developerWorks®

Об авторе
Девид Мертц (David Mertz)

Девид Мертц считает, что искусственные языки вполне естественны, а

естественные кажутся немного искусственными. Вы можете связаться с ним по
mertz@gnosis.cx; вы можете исследовать все стороны его жизни на его личной
web-странице. Посмотрите его книгу, Text Processing in Python. Пожелания и
предложения по поводу прошлых и будущих статей только приветствуются.

© Copyright IBM Corporation 2012

(www.ibm.com/legal/copytrade.shtml)
Торговые марки
(www.ibm.com/developerworks/ru/ibm/trademarks/)

Сжатие данных в примерах Страница 9 из 9