Миграция точно вовремя: как импортозаместить СУБД и не остановить бизнес-процессы
После ухода большого числа западных вендоров ИТ-решений банки, телеком, крупный ретейл и компании из других отраслей оказались в абсолютно новой для себя ситуации. Им приходится не просто оперативно мигрировать на новое хранилище данных, но и организовывать свою деятельность так, чтобы не потерять наработки в области аналитики, которые обслуживают задачи бизнеса.
Уже несколько лет компания Arenadata реализует проекты миграции в российских организациях. Ее эксперты одними из первых на отечественном рынке предложили свои методические рекомендации по переносу данных с западных СУБД на российские разработки и подробно разобрали нюансы. О том, как правильно выстроить миграцию, мы поговорили c Антоном Балагаевым, директором по консалтингу Arenadata.
Антон, на ваш взгляд, с чего вообще надо начинать миграцию? На какие первоочередные вопросы стоит ответить?
Три самых главных вопроса: где находится то, что должно быть мигрировано, что именно нужно перенести, и кто будет отвечать за миграцию.
В основном речь идет о реляционном коде. Как правило, это хранимые процедуры, ETL-процессы или приложения, через код которых идет обращение. Что мигрируется — тоже понятно. Это метаданные, которые в каждой системе строятся по-своему. Еще это, конечно, функциональный код, какая-то обвязка над SQL и непосредственно SQL, понятный любому аналитику.
А вот кто мигрирует — существенно зависит от того, что мигрируется. Если мы говорим о функциональном коде, здесь основная роль у разработчика, потому что аналитик не всегда может понять алгоритмы на используемом языке программирования. Если же мы говорим о миграции ETL, где большую часть могут составлять встроенные процессы или генерация запросов, роль разработчика может быть значительно меньше. А в случае с миграцией метаданных таблиц или простых объектов разработчик практически не нужен — здесь аналитику достаточно почитать документацию.
У каждого заказчика все построено по-своему. У кого-то больше хранимых процедур, кто-то больше ведет все в ETL. Поэтому, если считать стоимость миграции, у каждой из этих задач в формуле расчета будет свой вес.
Ранее вы говорили об оценке, согласно которой при миграции переписывание кода занимает порядка 80% времени и ресурсов. Почему это так и что еще, помимо переписывания кода, важно понимать для оценки трудозатрат и сроков?
Да, действительно, наш опыт показывает, что в среднем на это уходит около 80%. Но вообще надо смотреть case by case. Например, от некоторых наших клиентов я знаю, что в банковской отрасли нередко используются приложения, которые работают только с «родной» базой данных. В таком случае процент при миграции смещен в сторону координационных работ, поскольку у них есть несколько десятков активных потребителей, которые работают на своих аналитических системах, и под эти системы создавались целые кластеры. Поэтому, конечно, перед миграцией необходимо убедиться в том, что аналитики смогут продолжить свою работу. А для этого надо точно знать, кто и через какие аналитические приложения работает с мигрируемыми данными.
Стоит также учитывать разные обвязки, например CI/CD. Кроме того, нередко нужен вендорский контроль, потому что без дополнительного экспертного мнения при сложной миграции можно потратить слишком много времени на какую-то специфичную задачу. И, конечно, невозможно обойтись без обучения команды. Есть немало случаев, когда специалисты переходят с технологии, которой пользовались пару десятков лет. В таком случае надо адаптироваться к новому стеку, понять, где и на какие уступки можно пойти, какие преимущества есть у новых технологий.
Это касается и инфраструктуры?
Да, конечно! Пожалуй, самая массовая миграция сейчас — с Oracle Exadata. Оборудование, на котором работает этот комплекс, все-таки отличается от оборудования, на котором работают популярные кластерные системы. Важно понимать разницу, как это оборудование правильно переиспользовать, как сайзить новое оборудование на замену и так далее.
Давайте немного подробнее остановимся на этом. У вас уже есть какой-то опыт решения вопросов с поставками оборудования? Или вы ищите какие-то обходные пути?
Есть несколько основных сценариев, с которыми мы уже сталкивались. Первый — когда новых серверов нет и не будет. Это означает, что необходимо высвободить ресурсы уже имеющихся мощностей. Критически важно здесь доступное дисковое пространство. Общий подход — удалить лишнее и сжать нужное. Что это означает на практике: вы начинаете сжимать данные максимально эффективными алгоритмами, используете СУБД с колоночным хранением, пересматриваете политику создания резервных копий, в крайнем случае объединяете контуры, например разработки и тестирования.
Второй — когда какое-то оборудование все-таки есть. Я бы здесь обратил особое внимание на то, что надо хорошо знать используемый софт. Одни системы дают незначительную нагрузку на процессор, но потребляют очень много дискового пространства, другие, напротив, требуют серьезных вычислительных ресурсов. От этого непосредственно зависит, что вы сделаете с доступным оборудованием: будете использовать в комплексе или пересоберете его в других конфигурациях.
Самый удачный вариант — третий, когда новое «железо» достать удалось. Это самый понятный вариант, не требующий необычных подходов, однако и в таком случае не следует сбрасывать со счетов новые реалии. Можно порекомендовать, во-первых, ответственно отнестись к прогнозу динамики роста объемов и нагрузки, иначе вы рискуете чрезмерно быстро выбрать все ресурсы закупленного оборудования. Помимо этого, я бы рекомендовал оптимизировать стоимость терабайта хранения, рассмотреть возможность «температурного» хранения данных с учетом возможностей их сжатия и тщательнее следить за режимом эксплуатации: обеспечивать равномерную нагрузку на серверные мощности, по возможности не делить сетевую инфраструктуру с другими системами.
А как вы относитесь к решению проблем с «железом» за счет перехода в облако?
Работа с решениями Big Data в облаках требует особого подхода к настройке инфраструктуры и пристального внимания как специалистов от провайдера, так и вендора СУБД. В целом схема рабочая для сравнительно небольших инсталляций, но сетапы в сотни терабайт по-прежнему не стоит размещать в облаках.
Какие рекомендации по общей организации процесса миграции можете дать?
Здесь особых откровений нет. Миграция — это проект, а значит, требует проектного подхода: с планированием времени и ресурсов, контролем качества и сроков, с артефактами, наличие которых подтверждает выполнение задачи и возможность перехода к следующей. Существенно помочь выстроить близкий к реальности ресурсный и проектный план сможет пилотный проект. Нередко пилот помогает точнее оценить требуемый объем кластеров, скорректировать оценку трудозатрат на те или иные задачи и тем самым значительно снизить риски не уложиться в сроки и выйти за рамки бюджета.
Можете привести примеры удачного пилота?
Например, у одного из наших заказчиков из банковского сектора есть большая технологическая программа миграции, причем сразу в двух направлениях: они меняют хранилище на Arenadata DB и заодно переезжают на Arenadata Hadoop. Таким образом, миграцией охвачен весь аналитический стек банка. Два года назад они сделали пилот, в рамках которого оттестировали перенос наработок на новый стек и целевую нагрузку на кластер по одной из ключевых систем.
Мы очень тесно сотрудничали и продолжаем работать с ними по проекту миграции. На их примере, на самом деле, очень хорошо видно, что пилот — это не только проверка нового стека, но и подготовка команды, которой с этим стеком предстоит дальше работать.
Что касается стека, вы сказали, что именно в банковской отрасли типично использование целого спектра вендорских решений, которые завязаны друг на друга. Как это вообще решается?
Достаточно болезненно на самом деле. Могу привести еще один пример, на этот раз государственная организация, сейчас тоже мигрирует с Oracle. У них полностью оракловый стек: Data Integrator, GoldenGate, Application Express. И как раз много логики заложено в APEX, аналога которого на рынке в настоящее время попросту нет. Простых решений подобной задачи, конечно, не бывает. Поэтому очень важно собрать правильную команду с комплексной экспертизой, особенно если вы проанализировали все варианты и поняли, что предстоит писать свою замену вендорскому решению.
Но это же, как правило, занимает массу времени?
Да, повторить сложное вендорское решение в короткие сроки нереально, и это в принципе недешевый проект. Но если других решений нет, значит, вы будете собирать команду и планировать проект так, чтобы операционная деятельность не остановилась. Я бы даже рискнул сказать, что важна не столько техническая сторона переезда с одной СУБД на другую или переписывание ETL, сколько правильное планирование, при котором миграция не тормозит и не обгоняет бизнес-процессы.
На что, на ваш взгляд, нужно обращать внимание при подборе команды, своей или внешней?
О комплексной экспертизе я уже сказал. Помимо этого, надо понимать, способны ли люди быстро обучаться, а команды — оперативно масштабироваться. От одного из наших заказчиков, которого я уже упоминал (коммерческий банк), мы знаем, что они очень быстро росли, по ряду направлений — в разы за квартал. Не каждый подрядчик готов поддержать такой рост.
Сталкивались ли вы с миграцией хранилищ данных «в лоб»?
Да, такой опыт есть. В подобном случае практически ничего не переписывается, но и технический долг, конечно, тоже сохраняется. Здесь сам заказчик решает, есть ли у него время на переписывание кода.
Опубликовано 23.08.2022