Миграция Big Data на практике: как мы готовили напильники
Всем привет, меня зовут Алексей Марьин, я IT-лидер стрима «Озеро данных» в ВТБ. До 2019 года мы активно и вполне успешно использовали для анализа и обработки больших данных продукт Oracle Big Data Appliance с Cloudera Hadoop Distribution внутри. И всё было хорошо, пока Oracle не решил прекратить развивать это направление бизнеса. Тогда пришлось задуматься об альтернативе, и мы обратились к Arenadata Hadoop. По пути мы столкнулись с некоторыми, так скажем, особенностями: пришлось кое-что допиливать напильником.
Сейчас многие сталкиваются с похожими проблемами импортозамещения продуктов. Так что мы с коллегой, директором проектов службы развития больших данных Дмитрием Власовым, решили написать эту статью, чтобы подсказать решения и предупредить о трудностях.
С чего всё началось
Сперва расскажу, что предстояло переносить. Это были два кластера: регламентный и пользовательский. Мы специально разнесли два этих вида нагрузки, чтобы точно избежать конфликтов за ресурсы. Заодно пользовательский кластер выполняет функцию DR: так как все реплики источников и построенные витрины реплицируются на второй кластер, в случае отказа первого он может начать выполнять функцию регламентного, а аналитики данных временно выселяются на мороз.
Архитектура старого озера
Как я уже говорил, всё это замечательно себе работало на Oracle BDA и Cloudera. А потом развитие продуктов превратилось в тыкву и, хотя сопровождение ещё оставалось, пропала возможность расширить кластер (или даже заменить сломавшийся узел) или получить новую версию Cloudera.
Вариантов спасения было немного: искать готовый продукт на замену, причём импортозамещённый, или писать решение самим. Второй вариант был чем-то из области фантастики: разработка подобного продукта потребовала бы, наверное, сотен человеко-лет времени и финансирования уровня чёрной дыры в бюджете. Нельзя сказать, что это всегда неверно: у ВТБ есть несколько доморощенных платформенных решений, но это те компоненты, которые измеряются сотнями, если не тысячами инсталляций. Так что выбор был очевидным. Составили список требований и пошли изучать предложения. Необходимо было, чтобы решение закрывало если не все задачи, то большую часть, или чтобы специалисты были готовы оперативно что-то доработать по нашей просьбе. При детальном анализе выяснилось, что на рынке практически в гордом одиночестве присутствует молодая, но динамично развивающаяся Arenadata. Именно у них нашлось подходящее решение, а также готовность адаптироваться и доделывать что-то непосредственно под наши хотелки. К этому ещё вернёмся чуть позже.
В каком-то смысле банку повезло столкнуться с миграцией на импортозамещённый продукт заранее, ещё до 2022. Тогда, в 2020 году, в ВТБ началась цифровая трансформация (мы о ней уже писали здесь), и переезд на Arenadata Hadoop стал частью этого масштабного процесса. Это дало возможность как следует подготовиться к переезду, ведь объём работ предстоял большой: нам предстояло перенести около 5 Пб данных.
Этапы проекта
Миграция шла в несколько этапов:
Подготовка инфраструктуры. До конца 2021 года мы занимались в основном закупкой, монтажом и настройкой оборудования. Тогда же провели пилотные и нагрузочные запуски.
Параллельно мы решали другую проблему: старая система DRP, на которой находились сразу два кластера — регламентный и пользовательский, уже не справлялась с нагрузкой, и нужно было как-то её усилить. Мы пошли на инженерную хитрость: взяли часть нового оборудования для DAPP и поставили на него ADH и Cloudera. Затем перенесли на него пользовательский кластер. Эта промежуточная архитектура позволила нам выиграть время и лучше подготовить старую систему к миграции.
Архитектура старого озера на новом железе
Позже, в конце 2021 года, мы подняли на DAPP и регламентный кластер, а также необходимые среды тестирования, разработки и т. д. С этого момента можно было приступать к миграции.
Миграция. Длилась с 2022 до начала 2023 года. В первую очередь перенесли озеро данных, процессы загрузки. Миграцию витрин мы начали чуть позже, потому что витрины — это конечный продукт для пользователей, и он базируется на уже загруженных данных.
Запуск в промышленную эксплуатацию. Зима 2023 года. Уже в феврале на новой системе DAPP работало более 80% функционала, данные активно грузились и комплекс был поставлен на поддержку.
Завершение работ. Весна 2023. В мае процесс миграции практически закончился: более 95% процедур загрузки и 70% витрин уже работали на новом кластере, осталось только «подобрать хвосты», то есть довести до финала какие-то мелочи.
Архитектура нового озера
Специфика импортозамещённого решения
Перейдя на отечественный продукт, мы столкнулись с рядом проблем. В первую очередь не хватало необходимого функционала. Вплоть до того, что ещё на старте нам пришлось выждать время, пока вендор не добавит нужные с точки зрения информационной безопасности фичи: аутентификацию через Kerberos и TLS у всех сервисов.
Кое-чего нам не хватает до сих пор: например, полнофункционального аналога Cloudera Manager. В итоге за время проекта у нас выросло как минимум три параллельных решения по мониторингу кластера и процессов на нём, которые мы теперь мучительно сращиваем в одно. А из-за отсутствия поддержки Impala на момент миграции нам приходилось страдать с более медленным и прожорливым Hive и переучивать пользователей на Spark. Правда, была и другая сторона медали: с переходом на ADH произошло обновление всех компонентов Hadoop.
Что сейчас? Мы всё ещё ждём от Arenadata поддержки некоторых других нужных нам инструментов. Уже есть хорошие новости: в релизе 3.2.4.1 появилась Impala, которая должна спасти наших дата-сайентистов, чахнущих над задумчивым Hive. В последнем релизе 3.2.4.2 мы получили Kyuubi, который должен позволить нам вернуть более продвинутых дата-сайентистов, умеющих не только писать на Spark, но и выписывать себе в сессии все доступные ядра в рамки приличия. Наконец, ближе к середине года наконец должен будет появиться Hue, который на голову выше идущего сейчас в поставке Zeppelin и не требует от пользователей ковыряния в кишках «бобра».
Собственная разработка
Не всё, что мы использовали при миграции с Oracle BDA на Arenadata Hadoop, было готовыми решениями. Пришлось и самим кое-что написать. Об этом уже подробнее расскажет мой коллега, передаю ему слово.
Дмитрий ВласовДиректор проектов службы развития больших данных
Мы разработали собственный фреймворк загрузки сырых данных. Со второго раза. Так как в новом релизе Hadoop обновились практически все мажорные версии, желание начать жить по-новому было непреодолимым. Но с горьким опытом приходит понимание, что слона (даже жёлтого и плюшевого) лучше есть по частям.
Первая версия фреймворка была заказана у одной известной компании. Авторы много думали над UX, но результат получился довольно квадратно-гнездовым. Когда тебе нужно забрать за минимальное время и разложить по правильным патрициям несколько сотен Гб, нужно иметь возможность влиять на генерируемый код, а этот фреймворк такого не позволял. Никакая возможность сгенерировать весь необходимый код на основе описания формата источника в Excel этого не перевесит.
Вторая версия была написана подпольно и победила первую в революционной борьбе. Она, конечно, тоже неидеальна и по её равиоли-коду плачет основательный реинжиниринг, но она решила главную задачу. Теперь любой из шагов процесса можно переопределить под конкретную СУБД, систему-источник или конкретную таблицу:
как понять границы инкремента на источнике;
как забрать инкремент;
какой частью данных на кластере его сравнивать;
какие партиции нужно перезаписать, а какие дополнить.
Если очень верхнеуровнево, фреймворк выглядит вот так:
Как работает ДАГ в рамках фреймворка
Команда фреймворка реализует всевозможные cross-cutting concerns и мёрджит доработки конкретных ETL-методов от разработчиков тиражных команд. Аналитикам в тиражных командах остаётся только выучить YAML и писать на нём свои настройки. А также немножко Python, чтобы написать соответствующий ДАГ Airflow.
Да, у нас нет генератора ДАГов. Да, его можно было бы написать. Нет, мы его не написали. Да, он был в первой версии фреймворка, но он был настолько ужасен, что мы решили вынести почти всю логику в Spark. С оставшейся в ДАГах логикой может справиться даже аналитик. Может быть, мы ещё напишем новый генератор, с лаптой и девицами.
В ходе миграции пришлось заняться ещё одной собственной разработкой — инструментом синхронизации кластеров, который мы назвали просто: Hadoop Sync.
Мы всегда решали вопрос георезервирования кластера и разделения регламентной и пользовательской нагрузки созданием двух отдельных кластеров с одинаковым набором данных в озере и витринах. Также мы решаем задачу копирования данных на непромышленные контуры. Ранее мы пользовались инструментом Wandisco Fusion, перехватывающим все запросы к HDFS на оба кластера. Но при переезде стало понятно, что дальше нам с ним не по пути: он был несовместим с решением от Arenadata. Вендор настоятельно рекомендовал использовать их новое решение — Wandisco LDM, но после весны 2022 года пришлось искать что-то импортозамещённое. Вот только на рынке такого решения не оказалось, пришлось писать самим.
UI нашего Hadoop Sync
Ранее инструменты Wandiscо де-факто считались стандартом для подобных задач в банке. Перед нами был выбор: либо начинать всё с чистого листа, либо взять за основу опенсорсное решение и начать его дорабатывать. После довольно длительного исследования командой мы выбрали второй путь, а в качестве подопытного решения взяли CircusTrain. Забегая вперед, скажу: всё оказалось не так просто и у «бесплатного» решения было множество проблем и допущений. Ну вы и сами знаете про то, где обычно лежит «бесплатный сыр».
Одним из таких допущений стало то, что мы не стали реализовывать псевдо-онлайн-репликацию данных. Стоимость такого решения была бы слишком высока, и потому мы остановились на варианте, когда вызов Hadoop Sync осуществляет пользователь самостоятельно после окончания записи данных. На приёмнике данных реализовали так называемую транзакционную защищённость. Это в дальнейшем стало дополнительной головной болью для команды разработки и поддержки, потому что не все пользователи данных понимали, что до окончания репликации данные по факту не обновляются.
Уже сейчас мы реализовываем доработку, которая даст пользователю самостоятельно выбрать, в каком режиме копировать и что важнее: безопасность или синхронность источника и приёмника. Для конечного потребителя данных важно понимать, что важнее. Первый вариант — целостность транзакции, и неважно, были ли изменения данных, либо второй вариант: данные будут меняться максимально быстро, но есть риск остановки процессов по чтению исходных данных. Справедливости ради надо сказать, что эта проблема не была решена даже в Wandisco, но там было немного проще: была поддержка и банк просто делал тикет в соответствующую службу компании.
При планировании мы изначально исходили из того, что решение не будет монолитом и просто сервисом, который «запускаешь, и он копирует». Мы начали проектировать на базе микросервисного подхода на стеке, который принят как стандарт в банке. На первом этапе сделали акцент на уменьшении времени вывода минимального необходимого функционала, но, к сожалению, это негативно сказалось на качестве. И в результате команде пришлось больше времени тратить на поддержку и устранение ошибок.
Что ж, сейчас общая схема решения с Hadoop Sync выглядит так:
Функциональная схема Hadoop Sync
Развиваясь далее, мы стали добавлять внешние хранилища данных, например S3. И наша задача сейчас — создать систему для потребителей в банке, которая сможет не только работать с большими данными в экосистеме Hadoop, но и обычными реляционными БД.
Миграция в цифрах
Процесс миграции был долгим и трудоёмким. Вот несколько цифр, которые позволят оценить масштаб работ:
2 года занял проект миграции на новую платформу;
для его осуществления привлекли более 1000 человек;
для проекта разработан функционал обработки потоков данных, включающий более 1000 потоков;
на отечественное решение перенесено хранилище объёмом 5 Пб данных, ежедневной загрузкой 12 Тб и 3 тысячами пользователей;
с DAPP интегрированы корпоративные хранилища, мастер-системы, Legacy-системы.
Вместо резюме
Что остаётся сказать напоследок? Даже если привычное проверенное зарубежное решение вам больше недоступно, можно — и вполне реально! — найти адекватную отечественную замену. Не факт, что вы сразу получите все необходимые инструменты. Возможно придётся подождать, пока вендор их реализует. И нужно быть готовым к тому, что всё равно где-то что-то придётся разрабатывать и самим.
Делитесь в комментариях и своим опытом миграции на импортозамещённые продукты — что на что вы меняли, какие отечественные аналоги удалось найти, чем они вам понравились (или нет).
