Переход на Arenadata: вызовы, решения и перспективы
Современные компании, работающие с большими данными, сталкиваются с необходимостью не только обработки огромных объемов информации, но и постоянного обновления своей технологической инфраструктуры. Одним из ключевых вызовов в таких процессах является своевременная миграция на актуальные платформы, особенно если используемое решение перестает поддерживаться или развиваться.
Именно с такой ситуацией столкнулась команда разработчиков при миграции: изначально использовались Oracle Big Data Appliance с Cloudera Hadoop Distribution, которые долгое время обеспечивало стабильную работу. Однако после прекращения его развития возникла необходимость выбора новой платформы, и предпочтение было отдано Arenadata Hadoop (ADH).
Этот переход оказался непростой задачей: требовалось не только перенести два кластера – регламентный и пользовательский, но и сохранить все механизмы обеспечения отказоустойчивости, а также адаптировать бизнес-процессы к новой среде. В статье мы подробно рассмотрим этапы миграции, возникающие вызовы и то, как они были решены, а также поделимся выводами о преимуществах и недостатках нового решения.
Этапы проекта
Процесс миграции был разделён на несколько этапов:
Подготовка инфраструктуры
На первом этапе основное внимание было сосредоточено на закупке, установке и настройке оборудования, а также проведении пилотных и нагрузочных тестов. Одновременно решалась проблема недостаточной производительности старой системы DRP, на которой размещались оба кластера — регламентный и пользовательский. Для её усиления была реализована временная архитектурная схема: часть нового оборудования использовалась для развертывания ADH и Cloudera, после чего на него был перенесён пользовательский кластер. Это позволило выиграть время и лучше подготовить старую систему к миграции.
Позже был развернут регламентный кластер, а также среды тестирования и разработки, что позволило приступить к основному этапу миграции.
Миграция
Основные работы по переносу данных выполнялись в течение следующего периода. В первую очередь была перенесена система хранения данных, включая озеро данных и процессы загрузки. Миграция витрин началась позже, так как они зависят от уже загруженных данных и представляют собой конечный продукт для пользователей.
Запуск в промышленную эксплуатацию
К началу следующего года большая часть функционала уже работала на новой платформе, процессы загрузки данных были стабилизированы, а система передана на сопровождение.
Завершение работ
На заключительном этапе подавляющее большинство процедур загрузки и витрин было переведено на новую архитектуру, оставались лишь финальные доработки и оптимизация процессов.
Плюсы и минусы решения
Плюсы:
- Обновление технологического стека. Переход на ADH позволил модернизировать все компоненты Hadoop, обеспечив актуальность инфраструктуры.
- Развитие платформы. Постепенно добавляются необходимые инструменты: в свежих релизах появилась поддержка Impala и Kyuubi, а в будущем ожидается Hue, который значительно упростит работу пользователей.
- Соответствие требованиям безопасности. Вендор оперативно добавил поддержку Kerberos и TLS для всех сервисов, что обеспечило соответствие корпоративным стандартам информационной безопасности.
Минусы:
- Недостаток функционала. На момент перехода отсутствовали ключевые инструменты, включая поддержку Impala, что потребовало временного использования более медленного и ресурсоёмкого Hive.
- Отсутствие полноценного аналога Cloudera Manager. В результате пришлось разрабатывать и интегрировать несколько параллельных решений для мониторинга, что усложнило эксплуатацию.
- Дополнительное обучение пользователей. Из-за изменения технологий потребовалось переучивать специалистов с Impala на Spark, что повлекло за собой временные неудобства.
В целом, переход на новую платформу оказался сложным, но со временем недостатки компенсируются за счёт доработок со стороны вендора и адаптации внутренней инфраструктуры.
