Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Hello, world! Меня зовут Руслан, я работаю в отделе внедрения АО «Россельхозбанк» и в этой статье поделюсь с вами, как мы переносили данные из АБС «БИСквит» в систему ЦФТ-Банк. Если вы так же, как и мы когда-то, задумаетесь о смене основной банковской системы или уже находитесь в этом процессе, то вам, определенно, сюда!
В случае с нашим банком сам по себе непростой процесс миграции с одной АБС на другую был усложнен большим объемом переносимых данных: более 12 миллионов клиентов, 25 миллионов депозитов и 2-х миллиардов документов. Сейчас в банке работают 68 региональных филиалов, размещенных централизованно в одной автоматизированной банковской системе (АБС) с единой клиентской базой. Для достижения такого результата потребовалось около восьми лет: начиная с централизации разрозненного набора самостоятельных региональных филиалов и заканчивая миграцией в ЦФТ. Стоит отметить, что у каждого из филиалов банка был отдельный «БИСквит» с особенностями ведения тех или иных продуктов/состояний базы данных (БД).
Старая АБС имела существенные ограничения по количеству одновременно работающих сессий, так как пользователи подключались напрямую к БД. Архитектурное решение ЦФТ позволило снизить нагрузку на основную БД за счет перевода пользователей на работу через серверы приложений. Цели банка по привлечению большего числа клиентов также требовали применения еще более прогрессивных и современных решений. Поэтому за этапом централизации последовал этап перехода на новую АБC, и были начаты работы по проекту миграции данных из старой системы («БИСквит» от компании «БИС») в новую (ЦФТ-Банк от ЦФТ).
1. Особенности выбора и подготовки инструментов миграции.
Из-за децентрализации системы «БИСквит» в разных филиалах использовался разный набор таблиц базы данных, а также разнились подходы к ведению бизнес-данных. Поэтому первый вопрос, на который предстояло ответить нашей команде, звучал так: «Данные из каких таблиц нужно переносить из одной АБС в другую?». Для решения этой задачи был проведен анализ существующих в банке продуктов, собрана статистика по количеству записей в таблицах БД в разрезе филиалов и определен перечень значимых сущностей для миграции.
На следующем этапе был разработан подход к формализации правил переноса данных из таблиц источника в таблицы приемника. Был составлен маппинг полей (соответствие таблиц и реквизитов системы-источник системе-приемнику), маппинг классификаторов, порядок проверки результатов миграции и запущен процесс разработки инструментов экспорта и импорта.
Ко всему прочему нам нужно было ограничить объем данных для миграции, учитывая количество филиалов в банке и большое количество бизнес-данных. Поэтому волевым решением определили, что в новую АБС переносим только действовавшие в текущем году объекты/договоры (кредиты, депозиты и т.п.) и данные по балансу (документы и счета) с глубиной в 3 года от даты миграции.
Как уже упоминалось выше, в нашем банке используется система ЦФТ-Банк. Систему ЦФТ-Ритейл-банк нам заменила подсистема «R2 – Розница» (это отдельная большая история, которая потянет на еще один рассказ :) ). Для миграции большего объема данных продуктов физиков (относительно юриков) технология инструментов миграции была разделена на следующие части:
1. Миграция продуктов «R2 – Розница»: кредиты, депозиты, карты, страховки, резервирование физических лиц. Отличие миграции продуктов Розницы от остальных продуктов заключается в миграции данных в несколько этапов:
- заполнение миграционных таблиц (так называемые M#);
- подготовка и перенос данных в таблицы-прототипы (так называемые P#);
- перенос в целевые таблицы.
Во время самого переноса из таблиц-прототипов (P#) в целевые таблицы (Z#) предполагается отключение всех пользователей от БД, отключение индексов и ограничений.
Применение такого подхода к миграции продуктов Розницы связано исключительно с их большим объемом (60-65% от общего объема мигрируемых данных) и необходимостью выполнения ряда преобразований (из-за различий в структуре таблиц БИСквит и ЦФТ).
2. Миграция всех остальных сущностей: пользователи, клиенты ФЛ и ЮЛ, кассы, депозиты и кредиты юридических лиц и пр. Миграция этого типа продуктов выполнялась с помощью стандартного инструмента загрузки данных в ЦФТ-Банк – «универсального импорта», при помощи которого данные из файлов загружались в таблицы универсального импорта, а затем сразу в целевые таблицы.
2. Тестирование и отладка инструментов миграции.
«Ну что же, инструменты в первом приближении готовы, пора двигаться дальше!», - подумали мы и споткнулись о «кривоту» данных в источнике уже на этапе экспорта)). Было выявлено много ошибок, таких как перенос строки в ФИО клиента, закрытый счет у открытого договора, дата рождения больше даты выдачи документа и т.д.
На самом деле, это было ожидаемо – ведь у нас очень много филиалов и пользователей, способных плодить некорректные данные с бешенной скоростью (да, БИСквит в этом плане позволял пользователям довольно многое). Таким образом, был дан старт следующему этапу - процессу подготовки данных к миграции с помощью инструментов пред- и постмиграционных мероприятий (ППМ). В рамках проработки инструментов ППМ было выработано несколько способов исправления данных:
- полностью ручное выявление и исправление ошибок. Подход применим в случаях, когда применение следующих описанных способов нецелесообразно;
- выгрузка некорректных данных в отчет по определенному алгоритму (в зависимости от вида ошибок) с последующим ручным исправлением. Подход применим как для источника, так и для приемника;
- конвертация данных. При таком подходе данные исправляются автоматической операцией непосредственно перед миграцией/после миграции. Процесс подготовки филиала к миграции итерационный, и проверки готовности филиала к миграции конвертации необходимо запускать перед каждым тестовым циклом (пользователи ведь не переставали создавать новые данные). Подход применим как для источника, так и для приемника;
- алгоритм миграции. Этот пункт похож на предыдущий, но отличается тем, что исправление (изменение) данных происходит в момент экспорта данных. Этот вариант имеет несколько недостатков, например, увеличение времени экспорта (поэтому такой подход применялся редко и в обоснованных случаях) и сложность при проведении сверки миграции (о сверке поговорим несколько позже).
«Теперь точно можно выгружать!». Мы, конечно, понимали, что существует общая проблема для крупных объектов миграции - длительное время выгрузки (требовалось распараллеливание), но на текущем этапе отладки это не было столь критично. Поэтому идем дальше и перекладываем выгруженные файлы с сервера БД «БИСквит» на FIO ЦФТ.
Итак, миграция в ЦФТ разделялась на:
· миграцию Ядровой части и ЦФТ-Банк (так называемое ИБСО, через универсальный импорт);
· миграцию продуктов Розницы.
На самом деле, и в импорте ИБСО, и в импорте Розницы важна последовательность импорта, что невозможно «держать в голове» и требует некой формализации. На начальном этапе формализация вылилась в инструкции по миграции, а в последствии постепенно переросла еще и в автоматизацию в виде отдельного инструмента в Навигаторе под названием «Тайминг»:
В то время как универсальный импорт уже не был чем-то новым и не требовал существенных доработок, инструменты миграции Розницы, что называется, разрабатывались с подрядчиком «нуля». Миграция Розницы выполнялась в такой последовательности:
1) Файлы выгрузки всех розничных объектов собираются в единый каталог;
2) Запускается инструмент, группирующий файлы по определенным маскам имени файлов и приводящий их имена к единообразию;
3) Запускается инструмент, формирующий файл с перечнем имен файлов, реквизитами из этих файлов и порядковым номером реквизита в файле (назовем его "FB_METADATA.EXP").
Первым при импорте Розницы загружается файл FB_METADATA.EXP. Таким образом, решаются следующие задачи:
а) сверяется структура выгруженных таблиц с предсозданными таблицами M# в БД Oracle, что позволяет выявить ошибки экспорта или настройки таблиц M#;
б) определяется структура выгруженных таблиц для дальнейшего использования.
4) После генерируются скрипты для загрузки данных с FIO с помощью SQLLoader в три этапа:
1. импорт данных из файла в техническую таблицу (T#);
2. вставка данных из технических таблиц в таблицы миграции (M#);
3. удаление созданной технической таблицы.
5) На заполненных M# создаются заранее определенные индексы и выполняются ручные проверки данных на корректность (скриптами с помощью SQLDeveloper). На этапе заполнения таблиц миграции мы имеем в базе «плоские» данные (данные, в которых не восстановлена ссылочная целостность).
После проверки выгруженных данных и подтверждения их корректности можно приступать к подготовке к переносу в конечные таблицы, который состоит из ряда этапов:
1) Заполнение таблиц прототипов (P#) с резервированием идентификаторов (ID) для новых записей;
2) Восстановление ссылок на записи (таблицы R#) и на массивы (таблицы C#) для новых ID;
3) Восстановление ссылок на уже существующие в БД записи (таблицы E#).
В финальной части импорта выполняется перенос данных в целевые таблицы (с обязательным отключением триггеров и ограничений для ускорения процесса импорта) и проверка результатов миграции. Схематично процесс миграции продуктов Розницы можно отразить в следующем виде:
3. Внедрение пилотного филиала.
К внедрению пилотного филиала инструмент автоматизации уже был готов на 90%, существенно облегчил нам жизнь и сократил время миграции примерно в три раза. Внедрение пилота проходило в выходные дни для уменьшения влияния процесса перехода на работу филиала. В целом, переход был тщательно проработан и выполнен с минимальными проблемами и ошибками.
Дальше нас ждала подготовка к миграции филиала с наличием архивного «БИСквита» (в результате слияния двух «БИСквитов») и к миграции нескольких филиалов за раз одновременно! Но об этом, а также об особенностях миграции в новую АБС карточек клиентов, поговорим в следующий раз.
