Облачное хранение

Компания за год генерирует сотни терабайт данных: логи, бэкапы, базы, видео с камер. Выбрать облачное хранилище вроде бы просто, но дешевый гигабайт на поверку может разорить, а привычная «личная» логика работы с файлами здесь только мешает. Почему бизнесу не подходят потребительские облака и при чем тут температура данных?

Почему бизнесу не подходит «личная» логика

Популярные платформы для облачного хранения данных принято считать «облаком для личного». Но когда речь заходит о бизнесе, те же самые технологии превращаются в сложную, многослойную инфраструктуру. Для частного пользователя хранение данных в облаке – это способ поделиться фотографиями с поездки или не потерять важные документы. Для бизнеса такая логика «снял телефон – залил фото – забыл» не работает. У компании совершенно другие вопросы. Сколько это будет стоить через год, когда данных станет в два раза больше? Как быстро получить доступ к архиву трехлетней давности, если придет налоговая? И главное – как разграничить данные: что хранить в высокодоступном облаке, без чего работа встанет, а что просто должно лежать «на всякий случай»?

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

Объекты, блоки и папки – три кита, на которых все держится

Чтобы разобраться, какие облачные хранилища бывают, нужно обратить внимание на два ключевых параметра: как осуществляется доступ к хранилищу и по какой модели оно развернуто. По архитектуре доступа существуют объектные хранилища (например, S3), блочные хранилища и файловые хранилища (такие как NAS).

Объектные хранилища хранят данные в виде «объектов» – это файл, снабженный метаданными и уникальным идентификатором, без привычной файлово-иерархической структуры (то есть не как папки и подпапки, а скорее как таблица с записями, датами создания, редактирования и так далее). Такие хранилища (например, S3) используют для больших объемов неструктурированных данных: медиафайлов, логов, бэкапов, архивов, а также фрагментов кода.

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

Файловые хранилища работают по протоколам NFS, CIFS или SMB и выглядят для пользователя как сетевые папки с иерархией каталогов. Один из самых распространенных примеров – FTP-хранилище, где есть общая файловая папка со структурой и иерархией. Данный тип хранилища удобен для совместной работы с файлами, общих сетевых дисков и резервных копий, когда нужны привычные «обычные» сетевые папки.

Свое, чужое или «все сразу»

Существует еще один подход к классификации облачных хранилищ – по модели развертывания, по среде, в которой это хранилище работает. Здесь обычно выделяют три основных типа: публичное облако, частное облако и гибридную инфраструктуру.

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

Хранилище в частном (приватном) облаке, напротив, полностью контролируется ИТ-персоналом самого заказчика. Такое выделенное облачное хранилище может находиться либо в собственном ЦОДе компании, либо быть частью инфраструктуры облачного провайдера, но изолированной и настроенной индивидуально под заказчика. Для данных под 152-ФЗ и требований ФСТЭК часто требуется именно частное облако с сертифицированным ПО.

Гибридная и мультиоблачная инфраструктура сочетает публичные и частные среды. Например, часть данных компания держит в своем дата-центре, часть загружает в объектное хранилище типа S3, а для совместной работы использует облачную NAS-папку от внешнего провайдера. Такой подход позволяет балансировать между стоимостью, производительностью и требованиями к безопасности данных.

«Горячее», «холодное» и «ледяное» – почему дешевый гигабайт может разорить

Еще один поход к классификации облачных хранилищ связан с уровнем «холодности» данных – то есть с тем, как часто необходимо обращаться к этим данным. Многие облачные провайдеры также делят хранилища по частоте обращения к данным в хранилище.

«Горячее» (standard) хранилище предполагает высокую доступность и частые операции чтения и записи. Именно такие хранилища – самые дорогие в линейке, потому что они рассчитаны на постоянную работу с данными.

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

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

Как не заблудиться в этих трех соснах

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

Первый вопрос – как часто предполагается обращаться к данным? Если каждый день, подойдет только «горячее» хранилище и только блочная архитектура. Если доступ нужен примерно раз в месяц – стоит смотреть в сторону «холодного» и объектного. Если данные требуются «на всякий случай» и лежать будут годами – «ледяное».

Второй вопрос – кто и откуда получает доступ к хранилищу? Если данные должны быть доступны всей стране через браузер, лучше взять публичное облако. Если доступ нужен только сотрудникам из офиса – присмотреться к частному облаку. А если и те, и другие – готовиться к гибридной инфраструктуре.

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

Четвертый и самый важный вопрос – что произойдет, если эти данные исчезнут или станут недоступны на сутки? Ответ на него сразу отсекает половину вариантов. Если исчезновение данных приведет к остановке производства, нельзя экономить ни на классе хранения, ни на модели развертывания. Если же пропажа данных вызовет лишь легкое сожаление – можно смело отправлять их в «ледяное» хранилище.

Вывод

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

Автор — Полина Абаимова, менеджер продукта Отдела развития облачных продуктов компании ГК Softline («Софтлайн Решения»)

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

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

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

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

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

Другими словами, возможностей запросов и инструментов, извлекающих метаданные, для удовлетворения имеющихся потребностей бизнеса сегодня явно недостаточно. Обусловлено это следующими причинами:

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

Единый достоверный источник сведений об информационных активах организации

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

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

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

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

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

Продукты и сервисы каталогов данных

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

Приведем примеры продуктов для ведения каталогов данных.

• Azure Data Catalog и AWS Glue – сервисы каталогизации данных, встроенные в платформы публичного облака.
• Функции каталога данных поддерживают многие платформы для интеграции данных, в том числе Informatica Enterprise Data Catalog, Talend Data Catalog, SAP Data Hub и IBM Infosphere Information Governance Catalog.
• Некоторые каталоги данных предназначены для платформ больших данных и гибридных облаков. К ним относятся, в частности, Cloudera Data Platform и InfoWorks DataFoundry, поддерживающие операции с данными и их настройку.
• Существуют автономные платформы с функциями машинного обучения: Unifi Data Catalog, Alation Data Catalog, Collibra Catalog, Waterline Data и IBM Watson Knowledge Catalog.
• Инструменты для управления основными данными (например, Stibo Systems и Reltio), а также платформы клиентских данных (Arm Treasure Data) также могут использоваться в качестве каталогов данных.

Машинное обучение для лучшего понимания данных

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

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

Collibra использует машинное обучение, чтобы помочь администраторам классифицировать данные. Компонент Automatic Data Classification анализирует новые наборы данных и сопоставляет их с 40 уже имеющимися классификаторами – адресов, финансовой информации и идентификаторов продуктов.

Waterline Data использует патентованную технологию отпечатков, которая автоматизирует обнаружение, классификацию и управление корпоративными данными. Одним из направлений является идентификация и маркировка конфиденциальных данных, которая, как утверждается, сокращает время, требуемое для маркировки, на 80%.

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

Корпоративная система обработки и настройки данных InfoWorks Data Foundry непосредственно интегрирована с алгоритмами машинного обучения. Интерфейс визуального программирования, требующий написания минимального объема программного кода, позволяет конечным пользователям объединить данные с алгоритмами машинного обучения: кластеризацией k-means и классификацией по алгоритму случайных лесов.

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