Банк ВТБ унифицирует аналитическую платформу, образовавшуюся в результате слияний, на базе решений Arenadata.
Два года назад ВТБ завершил два крупных присоединения – Банк Москвы и ВТБ 24. В результате в банке образовалась очень сложная архитектура аналитического ландшафта. Естественным образом на нем сформировались три крупных блока, построенных на различных технологиях и обладающих функционалом различной степени зрелости. Получившееся наследие не устраивало ни ИТ, ни бизнес: сразу же столкнулись с дублированием и разрозненностью данных, как следствие – высокой стоимостью разработки и долгим временем создания новых продуктов. Кроме того, используемый технологический стек стремительно устаревал. Для ряда аналитических компонентов применялся комплекс Oracle SuperCluster, и еще большее число продуктов базировалось на Oracle BigData Appliance. Окончание жизненного цикла обоих решений стало огромной проблемой и привело к масштабной миграции ИТ-инфраструктуры на платформу Arenadata.
С какими задачами столкнулся банк в процессе выбора решения и миграции и чего он ожидает от перехода на единую платформу данных?
Проблемы объединенного ландшафта
|
|
|
Александр Бусыгин, начальник управления «Фабрика данных», банк ВТБ |
«Два крупных объединения – с Банком Москвы и ВТБ 24 – дались очень тяжело, это был сложный организационный процесс, все внимание было сконцентрировано на непрерывности бизнеса и соответствии регуляторным требованиям. На создание единой аналитической архитектуры и в целом комплексной архитектуры объединенного банка времени не хватало», – объясняет Александр Бусыгин, начальник управления «Фабрика данных» банка ВТБ. В рамках объединения на стороне ИТ проводился лишь минимальный набор мероприятий, позволявший поддерживать текущие бизнес-процессы на приемлемом уровне качества. Далее планировались масштабные задачи по приведению аналитической архитектуры банка к целевому состоянию.
Аналитическая архитектура ВТБ на момент старта программы по модернизации и оптимизации включала три крупных хранилища, унаследованных из присоединенных банков. Так, в Банке Москвы существовало единое хранилище на классическом Oracle объемом около 85 Тбайт. Его основной функционал фокусировался на рисках, а также отчетности – управленческой и обязательной. Хранилище ВТБ 24, занимавшегося розничным бизнесом, было построено на платформе Teradata. Сейчас оно самое большое – объем горячих данных этого хранилища составляет около 240 Тбайт и имеет огромное количество бизнес-функционала, у него несколько тыс. пользователей. Помимо классических задач отчетности, хранилище решает массу специфичных бизнес-задач – например, на нем работает движок, который для всех клиентов рассчитывает бонусные баллы, используемые в мобильном банке и в партнерских программах. Кроме того, из архитектуры ВТБ 24 приехало оперативное хранилище данных на технологии Oracle SuperCluster и озеро данных на базе Oracle BigData Appliance (интегрированная система, созданная совместно с Cloudera). Хранилище самого ВТБ работало на Oracle и было достаточно компактным – 60 Тбайт.
«В ходе объединения инфраструктуры пришлось интегрировать между собой все эти хранилища. Не было времени определить целевое состояние и реализовать его в ходе объединения», – констатирует Бусыгин.
В результате ожидаемо возник ряд проблем – полученная архитектура очевидно не оптимальна. Банк вынужден использовать три аналитических хранилища с дубликацией и низким качеством данных, ряд систем-источников подключен сразу к трем хранилищам для поддержания целостности данных. Наблюдаются огромные проблемы с качеством данных, так как каждое хранилище имеет свои процессы, технологии и команды. Наконец, не было целостной модели управления данными.
Упрощение и стандартизация
Различный технологический стек ведет не только к неоптимальной стоимости владения инфраструктурой, но и к возникновению массы бизнес-проблем. Например, усложнился регламент загрузки данных – в некоторых сложных ситуациях он достигает 6 дней. Это мало кого устраивает. Другая очевидная бизнес-проблема – крайне долгий вывод на рынок новых продуктов. Любая доработка бизнес-приложения влечет необходимость изменений во всех трех хранилищах, а зачастую и в озере данных. Это увеличивает бюджет доработок втрое-вчетверо и занимает длительное время, так как текущие хранилища живут в своем производственном цикле.
Наконец, большая технологическая проблема пришла со стороны вендора: Oracle SuperCluster и озеро данных на базе Oracle BigData Appliance подошли к концу жизненного цикла.
«Со временем ухудшается поддержка этих систем, мы не можем масштабироваться. А у нас огромный пул бизнес-инициатив, большой прирост данных», – подчеркивает Бусыгин.
Естественным стал вывод о невозможности поддерживать и развивать текущий ландшафт. Банк решился на создание единой полноценной платформы данных, которая должна включать в себя несколько компонент. Во-первых, это часть, отвечающая за загрузку и управление оперативными данными оперативного хранилища данных. Вторая компонента – хранилище данных с единой бизнес-моделью, включающее специализированные витрины для ad-hoc аналитики и банковских приложений, витрины с оперативными данными, пользовательские песочницы и т. д. Третья важная составляющая – озеро данных, ориентированное на задачи машинного обучения и data science, а также часть задач отчетности. Наконец, необходимо развивать слой аналитических и BI инструментов для работы с данными.
«Исторически сложилось, что у нас есть практически все BI-инструменты, присутствующие на рынке, их надо систематизировать. И внедрять новый инструментарий машинного обучения и data science», – отмечает Бусыгин.
Критерии выбора
При выборе технологической платформы для построения централизованной архитектуры управления данными выступало несколько важных критериев. Первым из них была функциональность. Специалисты ВТБ изучили бизнес-стратегию банка и оценили, какие продукты и в каком направлении планируется развивать в обозримой перспективе. Платформы оценивались на возможность покрытия этих задач.
Следующие два важных критерия – производительность и стоимость владения. С учетом объемов – особенно более 400 Тбайт горячих данных и дневным инкрементом 10-12 Тбайт – вопрос стоял очень остро. Кроме того, в целевое хранилище данные должны загружаться день в день. Что касается стоимости, то из-за различного технологического стека, использованного в хранилищах, банк сейчас вынужден платить втрое больше. Поэтому возникла необходимость найти единую платформу, стоимость владения которой была бы оптимальной.
Еще один острый вопрос, который встал ребром в течение 2020 года, – отсутствие санкционных рисков. «Это реальность, с которой вынуждены считаться. В банке уже сталкивались с ситуацией, когда решения, планировавшиеся к внедрению, приобрести не удалось», – говорит Бусыгин.
Качество поддержки – еще одна неотъемлемая характеристика любого решения, когда речь идет о внедрении в крупном банке. Здесь понимается наличие у поставщика профессионального сервиса, работающего круглосуточно и доступного во всех часовых поясах, а также возможность функции «премиальной», расширенной поддержки под специфичные потребности банка.
Требование к дорожной карте развития платформы и возможности на нее влиять выросли из того, что две платформы пришли к концу своего жизненного цикла и неожиданно оказались устаревшими. Банк попал в сложную ситуацию: ни о каком развитии бизнеса при отсутствии перспектив у используемых решений речи идти не может. «К сожалению, нас поставили перед фактом, никакого заблаговременного предупреждения не было», – подчеркивает Бусыгин. Эта тема стала болезненной, и поэтому начали обращать повышенное внимание на долгосрочные планы развития платформы.
Надежность решения и возможность его гибкого масштабирования также очень важны. На хранилищах работают критичные бизнес-процессы – и регуляторная отчетность, и приложения, остановка которых ведет к потере прибыли, штрафам, а в худшем случае – отзыву лицензии. Стандарт для хранилищ в ВТБ – надежность «четыре девятки». Кроме того, бизнес банка активно развивается, и необходима уверенность в том, что при необходимости в любой момент удастся этот рост поддержать со стороны ИТ-инфраструктуры.
Наконец, предпочтение отдавалось «единому окну» – возможности купить целевую платформу как комплекс, включающий в себя оборудование и лицензии ПО и поддерживаемый одной командой.
В числе возможных вариантов рассматривались решения Cloudera, Teradata, Oracle и Huawei. Но если говорить о полном покрытии выставленных критериев, то их закрыла только платформа Arenadata. Таким образом, банк принял для себя концептуальное решение на годы вперед.
Планы миграции
«После того, как определились с потенциальным поставщиком, мы организовали пилотный проект: одно дело – проектирование и теоретическая оценка, и совсем другое – работа системы в реальности», – подчеркивает Бусыгин. Для тестирования взяли два ключевых направления – производительность СУБД, сравнивая возможности Arenadata DB и SuperCluster, а также Arenadata Hadoop, который сравнивали с BigData Appliance. Тестирование проводили на сопоставимых мощностях, а объем обрабатываемых данных в пилоте был типовым для процессов ВТБ. Arenadata за полтора месяца тестирования показала очень достойные и стабильные результаты, проблем с точки зрения функционирования выявлено не было. Различий в производительности между текущим решением и новой платформой практически не наблюдалось.
Согласно разработанным планам, в ВТБ в течение следующих двух лет внедряется единое целевое хранилище данных на базе Arenadata DB, проводится миграция озера данных с BigData Appliance на Arenadata Hadoop. Кроме того, имеющиеся витрины данных в максимальной степени переносятся со старых платформ на новые.
Решения Oracle и Teradata временно остаются в архитектуре банка, и для этого есть несколько причин. Во-первых, банк уже сделал инвестиции в эти решения, и они должны вернуться – желательно с прибылью. Поэтому часть решений на них продолжит работать, речь идет о 15-20% функционала. Тем не менее на Arenadata переходят все ключевые системы.
Вторая причина – в банке есть ряд унаследованных бизнес-приложений, в том числе CRM, привязанных к решению конкретного вендора. Их банк планирует через некоторое время перевнедрять, и именно на этот момент запланирована миграция на новую платформу.
Эффекты и ожидания
В ходе проекта специалисты ВТБ уже перевели первую большую витрину, которая отвечает за формирование регулярной отчетности для ЦБ РФ, на Arenadata DB. Это произошло в сентябре 2020 года. Сейчас она работает в режиме опытно-промышленной эксплуатации. Параллельно ведется работа по полному переводу платформы на Arenadata DB, которую планируется завершить к апрелю 2021 года.
Банк уже получил инфраструктуру для создания целевого хранилища и озера данных – это программно-аппаратные комплексы Arenadata DB и Arenadata Hadoop на основе машины баз данных СКАЛА-СР. Их планируется развернуть до конца года, и со следующего года раз в квартал начнется перевод в опытно-промышленную эксплуатацию первых частей аналитических бизнес-приложений. Весь путь по созданию целевого хранилища и миграции озера данных планируется завершить до конца 2022 года. После этого предполагается заняться переносом на новую платформу оставшихся унаследованных приложений.
Что планируется получить от этого с точки зрения бизнеса?
«Безусловно, снизится стоимость владения платформой данных. Кроме того, мы хотим полностью исключить с горизонта банка все санкционные риски – столкнувшись с ними, банк больше не хочет от них зависеть», – резюмирует Бусыгин.
Кроме того, важной целью является сокращение времени вывода бизнес-продуктов на рынок – как минимум вдвое. Исходя из опыта нынешнего года, реальный эффект будет значительно выше, ведь параллельно идет переход процессов разработки на подходы DevOps. Ожидается, что бизнес будет очень доволен результатами и изменения в системах будут реализовываться очень быстро.
Интегрированные системы стали legacy
Около 10 лет назад многие производители увлеклись выпуском интегрированных систем – готовых программно-аппаратных комплексов, оптимизированных для решения определенного класса задач. Такие решения стали вполне востребованными: на рынке сформировались области для их эффективного применения. Возможность приобретения и быстрого внедрения преднастроенного комплекса, оптимального для решения возникшей задачи, выглядела весьма привлекательной.
Это было модное и популярное направление. Ярчайшим представителем таких систем является Teradata, до сих пор предпочитающая работать в таком формфакторе. У IBM и EMC также были неплохие машины, сейчас снятые с производства. Шире всех в этой нише был представлен Oracle сразу с несколькими популярными машинами, на которые сейчас снижается цена. Безусловно, это говорит о том, что время таких систем уходит и они стремительно становятся legacy. Преимущества, которые давали инженерные системы 10 лет назад, становятся неактуальными. Сейчас те же задачи решаются по-другому.
«На следующем витке развития ИТ происходит повсеместный уход от специализированных систем к гибридным платформам, и это осуществляется на фоне другого масштабного тренда – роста популярности платформ open source», – отмечает Сергей Золотарёв, генеральный директор Arenadata. Использование сугубо проприетарных интегрированных систем накладывает ряд ограничений на их использование и интеграцию. Именно поэтому все большую популярность приобретают облачные и динамические платформы; кроме того, очень интересен тренд в области виртуализации данных, когда можно получить к ним доступ независимо от их физического нахождения.
За время существования интегрированных систем их было установлено весьма много, и сейчас большим вызовом является безболезненный переход с них на полноценные платформы данных. На сегодняшний день существует ряд альтернатив, для которых неплохо отработаны методики миграции. Самое главное – новые платформы отвечают всем самым актуальным требованиям, предъявляемым заказчиками к современной аналитической платформе. Это и линейная масштабируемость до петабайт, и возможность работы с любыми форматами, и централизованное управление, и использование в составе платформы компонент open source.
Если смотреть на наиболее востребованные сценарии перехода с интегрированных систем на платформы данных, то их два. Очень часто происходит не полный переход, а частичный – так называемая «разгрузка» (offload), когда ядро логики длительное время остается на legacy-системе, а вычислительные процессы и витрины выносятся на платформу данных. Так, например, Сбербанк переносит вычислительные нагрузки с Teradata на Gleenplum. Второй подход – полная миграция, происходящая на горизонте 1-1,5 лет и сопровождающаяся «наведением порядка» в ИТ-инфраструктуре и ее реструктуризацией. Наиболее яркий и технически сложный пример такого проекта – работы, проводимые в ВТБ. На данный момент проведена базовая миграция, но все говорит о том, что подход был правильным и в дальнейшем все задачи проекта будут выполнены.
