Pull to refresh
184.56
MWS
Больше, чем облако

Когда данных слишком много… как оптимизировать хранение

Level of difficultyEasy
Reading time5 min
Views4.7K
image

Каждый день человечество генерирует порядка 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 и других компонентов на обработке.

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

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




Top.Mail.Ru
Tags:
Hubs:
Total votes 8: ↑6 and ↓2+6
Comments4

Articles

Information

Website
mws.ru
Registered
Founded
Employees
501–1,000 employees
Location
Россия