Миграция больших данных в облако

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

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

Этапы миграции big data в облако

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

Анализ текущего состояния

Первый этап — это подготовка к миграции, которая начинается с тщательного изучения текущей инфраструктуры и данных компании. Это своего рода аудит инфраструктуры и зависимостей. Здесь важно:

• Провести инвентаризацию всех данных. Определить их объём, формат, источники и актуальность.
• Оценить используемые платформы, инструменты и архитектуру. Например, это могут быть локальные серверы, распределённые системы хранения, потоки данных от IoT-устройств или данных из ERP/CRM-систем.
• Определить критичность данных. Какие из них жизненно важны для бизнеса, а какие можно перенести позже?
• Проверить доступность данных, уровни доступа и конфиденциальность.

Этот этап позволяет понять, насколько данные готовы к миграции, какие данные можно и нужно оптимизировать. Ещё на этом этапе выявляются потенциальные риски. Допустим, когда данные не структурированы, их предварительная обработка предотвратит возможные проблемы при переносе в облако.

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

Проектирование архитектуры миграции

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

• Где и как будут храниться данные, какие сервисы и инструменты планируется использовать. Например, вы можете выбрать распределённое объектное хранилище для архивов и облачную базу данных для структурированных данных.
• Подготовку данных — очистку от ненужной информации, сжатие, преобразование в нужный формат (если источники данных различаются).
• Расчёт ресурсов. Определяется объём облачного хранилища, вычислительные мощности и пропускная способность сети, необходимые для переноса данных.
• Оценка влияния на бизнес-процессы. Здесь решается, как минимизировать время простоя при миграции.

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

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

Миграция

На этапе миграции всё, что было запланировано, начинает воплощаться в жизнь. Как правило, в процессе миграции происходит:

• Развёртывание облачных ресурсов. Создаются хранилища, настраиваются виртуальные машины и контейнеры, необходимые для обработки данных.
• Настройка систем управления задачами. Это может быть оркестрация потоков данных или планирование очерёдности передачи различных наборов данных.
• Перенос данных. На практике этот процесс делится на два этапа: первичная миграция полного объёма данных и синхронизация инкрементальных (новых или обновлённых) данных.
• Тестирование и оптимизация. На каждом этапе выполняется проверка целостности данных, производительности систем и правильности настроек.

Этот этап критически важен для обеспечения работоспособности всех бизнес-процессов. Неправильная настройка может привести к потере данных или длительным простоям. Особенно при миграции данных из SAP.

Приёмка и завершение миграции

Финальный этап предполагает, что всё прошло гладко, и теперь в этом надо удостовериться. Для этого выполняется:

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

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

Инструменты для миграции больших данных

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

1. Инструменты репликации и синхронизации. Например, использование специализированных сервисов, позволяющих создавать реплики баз данных, синхронизировать данные в реальном времени и настраивать миграцию с минимальными потерями.
2. Пакетная передача данных. Применение инструментов для групповой обработки данных позволяет оптимизировать процесс, например через интеграцию с протоколами передачи больших данных.
3. Миграция через API. Если облачная платформа поддерживает API-интерфейсы, их можно использовать для точечной передачи и обработки данных.
4. Облачные шлюзы. Подход для подключения локальной инфраструктуры напрямую к облачной платформе, что упрощает передачу больших объёмов данных.
5. Кастомные скрипты. Разработка собственных решений для миграции, если стандартные инструменты не отвечают требованиям конкретного проекта. Как правило, у поставщиков облачных услуг уже есть готовые решения. Но иногда приходится изобретать велосипед, адаптируясь под особенности инфраструктуры компании-клиента.

Задачи, которые стоят перед провайдером во время миграции

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

Огромные объёмы данных

Большие данные (big data) представляют собой массивы объёмов в несколько терабайт, петабайт или ещё больше. Передача таких массивов данных по сети может занять недели или даже месяцы, особенно если пропускная способность соединения ограничена. Например, перенос 1 петабайта данных через соединение со скоростью 1 Гбит/с займёт более 100 дней.

Как можно решить эту задачу? Есть как минимум три варианта.

• Физическая транспортировка носителей. Облачные провайдеры таких случаях готовы предложить услуги физической миграции. Такой способ позволяет перенести данные на носителях, которые затем отправляются в дата-центр провайдера.
• Ускорение передачи данных. Использование WAN-оптимизации, оптимизированных для больших данных протоколов и других технологий позволяет существенно уменьшить время передачи информации.
• Локальная предобработка. В некоторых случаях допустимо применение EDGE-устройств для фильтрации и сжатия данных перед отправкой в облако.

Совместимость форматов и структур

Разнородность данных — ещё одна частая проблема, которую приходится решать техническим специалистам. Источники данных (CRM, ERP, IoT-устройства, лог-файлы) могут использовать разные форматы и структуры, что усложняет миграцию.

Здесь допустимы разные подходы к решению задачи. Например, использование ETL (Extract, Transform, Load) инструментов вроде Apache NiFi, Talend или Informatica, позволяет преобразовать данные в унифицированный формат перед загрузкой. Или создание облачного хранилища типа озера данных (data lake) для работы с данными в их оригинальном формате, с последующей обработкой. Также возможна интеграция AI/ML для автоматического выявления и преобразования структур данных.

Обеспечение безопасности

Передача и хранение данных требуют строгого соблюдения стандартов безопасности. Особенно это важно для отраслей, регулируемых законом (ФЗ-152, GDPR, HIPAA). Поэтому важно использовать инструменты защиты данных и назначить ответственных за отдельные области инфраструктуры. Например:

1. Шифрование. Все данные должны быть зашифрованы как на этапе передачи (TLS/SSL), так и в состоянии покоя (AES-256).
2. Определение границ ответственности между провайдером и клиентом.
3. Мониторинги. Внедрение инструментов для отслеживания активности с данными.

Сокращение времени простоя

Простой систем во время миграции — серьёзный риск для бизнеса. Порой даже критический. А репликация данных в реальном времени может быть сложной, особенно в условиях ограниченных сетевых ресурсов. В такой ситуации выручает гибридная стратегия. Имеется в виду постепенная миграция с сохранением работы локальной инфраструктуры.

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

И ещё не стоит забывать про планирование миграции. В ряде случаев имеет смысл выполнение миграции в периоды минимальной активности бизнеса.

Оптимизация издержек

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

Использование калькуляторов TCO (Total Cost of Ownership) от облачных провайдеров также будет нормальной практикой.

Заключение

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

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