Каждый день человечество генерирует порядка 330 млн терабайт данных. Хотя по оценкам экспертов Google всего 10% из них являются свежими и оригинальными, даже копии копий нужно где-то хранить. И эта задача имеет ряд нюансов. Здесь уместно провести аналогию с известным транспортным парадоксом: чем больше дорог строится, тем больше образуется автомобилей, чтобы заполнить их (постулат Льюиса — Могриджа).

Недостаточно построить очень много дата-центров. Один из наиболее очевидных способов сэкономить на хранении данных — это архивирование файлов и сжатие изображений. Есть и другие подходы, которые помогают записать больше данных на диск и быстрее их обрабатывать.

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

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

Помимо прямой стоимости хранения, специалисты выделяют издержки, связанные с охраной окружающей среды. Согласно отчету Комиссии по международной торговле США, в мире насчитывается более 8 000 центров обработки данных. В Европе абсолютным лидером по количеству дата-центров являются Нидерланды. ЦОДов в стране настолько много, что в прошлом году правительство ввело мораторий на запуск новых площадок. Дело в том, что плохо контролируемое строительство становится яблоком раздора — местные жители были крайне обеспокоены тем, что для охлаждения серверов использовалась питьевая вода. Более того, многие активисты подняли вопрос о чрезмерном потреблении электроэнергии центрами обработки данных.

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

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

Взять и сократить объемы: алгоритмы сжатия

Здесь применяют разные алгоритмы. И одним из наиболее распространенных остается Gzip, способный сжимать файлы на 70% (его в том числе применяют для ускорения передачи по сети). В основе лежит механизм DEFLATE, который сам по себе представляет комбинацию алгоритма LZ77 и кодирования по методу Хаффмана. Первый ищет повторяющиеся последовательности в тексте, заменяя их указателями на идентичные строки. Во втором случае каждому символу ставят в соответствие код переменной длины, и он тем короче, чем чаще появляется символ.

Степень сжатия Gzip составляет около 2,7x-3x. Скорость сжатия составляет от 100 Мбит/сек, а скорость распаковки — ≈440 Мбит/сек.

Snappy — обеспечивает сжатие без потерь. Он интегрирован в Hadoop Common и часто используется для сжатия баз данных. Коэффициент сжатия Snappy составляет ≈2х. Скорость сжатия составляет ≈580 Мбит/сек, а распаковки — ≈2020 Мбит/сек.

LZ4 — алгоритм сжатия без потерь, который ориентирован на быстрое сжатие данных. Чаще всего его используют в приложениях, где большая нагрузка и требуется дешевое и быстрое сжатие данных без дополнительных нагрузок на процессор.Степень сжатия LZ4 составляет ≈2,5x. Скорость сжатия составляет ≈800 Мбит/сек, а скорость распаковки — ≈4220 Мбит/сек.

Zstd — обеспечивает сжатие без потерь. Он не зависит от типа данных и предназначен для сжатия в реальном времени. Степень сжатия Zstd составляет ≈2,8x. Скорость сжатия составляет ≈530 Мбит/сек, а распаковки — ≈1360 Мбит/сек.

Относительно новый метод сжатия Brotli заточен под работу с небольшими текстовыми документами в вебе. Он имеет встроенный словарь фраз и последовательностей, часто встречающихся в HTML-документах.

На всякий случай заметим, что в вопросе сжатия данных не существует «серебряной пули». Алгоритм выбирают исходя из конкретных задач. Например, уже упомянутый Gzip часто применяют в контексте big data.

Дедупликация и выбор диапазона значений

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

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

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

Определенной выгоды с точки зрения хранилищ можно добиться, оптимизируя программы на уровне кода. Так, определенное количество памяти можно сэкономить, если использовать наименьший integer, удовлетворяющий требованиям задачи. В некоторых случаях подход может сэкономить до 90% памяти.

Как вариант, заменить float32 на float16. Но такой подход снизит точность расчетов. Прибегать к нему стоит только после тщательной оценки его влияния на работу кода. Можно попробовать найти некую форму зависимости между метриками и производительностью алгоритма, хотя это и не всегда легко.

Еще один потенциальный вектор — оптимизация работы с JSON. В этом формате часто хранят большие данные. Однако специалисты отмечают, что работа с ним может вызывать сложности в таких инструментах как Hadoop (отчасти из-за сильной типизации и отсутствия схем). Решением проблемы могут стать системы вроде Avro. Это — ориентированная на строки среда для сериализации данных. Она позволяет выделять типы данных и кодировки без парсинга JSON-файлов. Но также можно обратиться к альтернативным форматам. Об одном из них — языке UCL — мы рассказывали в прошлом материале. Его автор внес множество синтаксических изменений, которые не сильно, но облегчают записи и повышают читаемость — например, в UCL не нужны фигурные скобки для описания верхних объектов.

Эффект оптимизаций

Сжатие данных и оптимизация кода помогает экономить на дисковом пространстве и электроэнергии — особенно в масштабах big data и дата-центров. Например, условные метеостанции и погодные установки генерируют петабайты данных ежегодно. И их операторы активно используют механизмы сжатия и округления битов, чтобы экономить на накопителях.

Очевидно, что ЦОД используют не только в качестве большого машинного зала с дисками, на виртуальной инфраструктуре развернуты сотни и тысячи приложений. В таком контексте меньший объем данных обозначает оптимизированную загруженность сети, занятость CPU, GPU и других компонентов на обработке.

Наконец, работать с большими массивами неструктурированных данных в традиционных файловых хранилищах неудобно: усложняется иерархическая структура папок, увеличивается время поиска нужной информации, снижается скорость доступа. Размещать миллиарды единиц контента различных форматов лучше в объектом хранилище, которое будет расширяться автоматически вместе с ростом объема данных.

Что еще прочитать в нашем блоге о хранении данных:

• Внутренние и внешние признаки надежности сети ЦОД
• Импортозамещение систем резервного копирования и автоматизация работы с бэкапами
• SSD, CD, HDD, OptiNAND… DNA — выбираем перспективные накопители для резервного копирования