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

На деле переносить проект с многокомпонентной системой обработки данных, масштаба Петабайта, из локальной среды в облачную — это сплошные “но”. Для миграции есть много продуктов: Hadoop, Hive, Yarn, Spark, Kafka, Zookeeper, Jupyter, Zeppelin. Учитывая принципиальное различие среды, в этом многообразии легко потеряться и наделать ошибок.

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

1. Копировать данные в облако — это просто

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

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

• передачу
• интеграцию данных
• верификацию данных
• отчетность

Если определенная часть данных преимущественно статична или умеренно динамична, можно использовать решение вроде AWS Snowball, которое позволяет копировать массивы на физическое устройство. Данные будут загружены из вашей локальной сети, после чего накопитель отправят обратно в ЦОД AWS и зальют данные в хранилище S3.


Хорошим тоном считается разделить перенос данных на два этапа. После того, как большая часть массива будет отправлена и загружена в хранилище, используйте прямое соединение облачного провайдера, чтобы выгрузить остатки. Для этого можно использовать методы Hadoop DistCP или Kafka Mirroring. У обоих методов есть свои нюансы. DistCP требует постоянного планирования и глубокой настройки, к тому же, не все объекты получится помещать в черные и белые списки. Kafka MirrorMaker, помимо глубокой настройки, нуждается в экспорте метрик через управленческое расширение JMX для измерения пропускной способности, задержки и общей стабильности.

2. Облако работает так же, как и локальное хранилище

Локальное хранилище и облачное — это не одно и то же. Наглядный пример — Zookeeper и Kafka. Клиентская библиотека ZK кеширует разрешенные адреса серверов ZK на весь срок службы: это большая проблема для развертывания в облаке, которое потребует «костыли» — статические сетевые интерфейсы ENI для серверов ZK.

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

3. Хранилище объектов на 100% заменяет HDFS

Разделение слоев хранения и вычисления — это отличная идея, но есть нюанс.

За исключением Google Cloud Storage, который использует сильную согласованность данных (strong consistency), большинство остальных хранилищ объектов работают по модели «согласованность в конечном счете» (eventually consistent). Это значит, что их можно использовать и для ввода необработанных и обработанных данных, и для вывода результатов, но нельзя как временное хранилище.

4. Развернуть облачную инфраструктуру можно из пользовательского интерфейса

Для небольшой тестовой среды это может быть легко, но чем выше требования к инфраструктуре, тем выше вероятность, что придется писать код. Вам, возможно, захочется иметь несколько сред (Dev, QA, Prod). Это можно реализовать с помощью CloudFormation и Terraform, но скопипастить нужные куски кода не получится, придется многое переделывать под себя.

5. Для корректной видимости в облаке нужно просто использовать ${SaaS_name}

Хорошая видимость (ведение журнала и мониторинг) старой и новой среды — это важнейшее условие для успешной миграции.

Это может быть непросто из-за использования в средах разных систем. Например, Prometheus и ELK для локальной среды, а NewRelic и Sumologic для облачной. Даже если одно SaaS решение применяется в обоих средах — это сложно масштабировать.

6. Облако масштабируется до бесконечности

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

7. Я просто перенесу свою инфраструктуру без изменений

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

Еще один хороший пример — оптимизированная для облака платформа больших данных EMR. На первый взгляд простая, она требует тонкой настройки с помощью пост-установочных сценариев. Можно кастомизировать размер кучи (heap size), сторонние архивы JAR, UDF, надстройки безопасности. Также отмечу, что до сих пор нет способов обеспечить высокую доступность (HA) для главных узлов NameNode или YARN ResourceManager.

8. Перенести Hadoop/Spark задачи в облако — это просто

На самом деле нет. Для успешного переноса задач нужно иметь четкое представление о своей бизнес-логике и пайплайнах: от первоначального поступления необработанных данных до высококачественных массивов. Все становится еще сложнее, когда результаты пайплайнов Х и Y — это входящие данные пайплайна Z. Все компоненты потоков и взаимосвязей должны отображаться максимально четко. Это можно реализовать с помощью DAG.

9. Облако сократит эксплуатационные расходы и бюджет на персонал

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

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

10. No-Ops близко...

No-Ops — это мечта любого бизнеса. Полностью автоматизированная среда без необходимости в услугах и продуктах от третьих лиц. Возможно ли это?

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

---

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