Корпоративное хранилище в ГПБ существует с девяностых. Тогда оно создавалось исключительно под задачи регуляторной и текущей отчетности. Соответственно и архитектура была такой, чтобы соответствовать требованиям этих задач.
Изначально мы использовали SAP ASE. В нем была реализована довольно сложная бизнес-логика, и все работало неплохо, но старая система не потянула бы расширение, не хватало производительности. Также были пробелы и в документировании — из-за огромного легаси, о котором даже спросить было некого.
По мере развития IT-ландшафта и появления новых систем, росли требования заказчиков, ставились новые задачи. В 2009 году стало понятно, что надо менять подход к работе с КХД, аналитическую платформу и инструменты по работе с хранилищем. Выбрали новые: SAP IQ, а в качестве «интеллекта» — DataStage (тогда он еще не принадлежал IBM).
Перед командой стояла задача создать объединенное хранилище данных, не порушив при этом работу всех систем. Нужно было незаметно для потребителей перевести всё со старого хранилища на новое.
Все инструменты были собраны, лицензии куплены, но дальше все встало по независящим от нас причинам. И в итоге мы сели на два стула: старое хранилище хоть и устарело, но продолжало работать и развиваться, а новое решало ограниченный круг задач, которые в силу специфики не могли быть реализованы на старой версии (в тот момент там крутилось несколько сервисов по отчетности).
В 2017 году решили довести все до ума. Нарастили команду и начали дорабатывать новое хранилище под требования бизнеса и переводить в него пользователей со старого. Возможно, проще (да и быстрее, что уж говорить) было бы оставить старое хранилище в покое, построив новое «рядом». Однако ничем хорошим это бы не кончилось: пришлось бы дробить усилия и поддерживать две системы одновременно.
Например, на старом хранилище работал справочник валют, который используется кучей разнообразных сервисов. Из-за своей специфики его пришлось бы дублировать на новом и поддерживать и там, и там. И таких сервисов был не один. Кажущаяся экономия в итоге привела бы к росту костов.
А еще перед глазами вставал опыт пары компаний, вставших на путь дублирования КХД, который привел их в итоге к необходимости создавать несколько хранилищ, работающих «в параллели» с предыдущими. В итоге мы решили не гнаться за сиюминутной выгодой и сосредоточиться на «длинной дистанции».
Что представляет собой наше КХД сейчас
по 70-100 одновременно запущенных процессов на 7 нодах;
7000 атрибутов (вместо 2000 на старом);
в среднем 270 конкурентных пользователей в день, в пике около 400;
около 170k уникальных исполнений скриптов за месяц;
Объем: 350 Тбайт (100 в сжатом виде);
Команда с 17 человек в 2017 году увеличилась до 100.
Старое хранилище хоть не было большим и не принимало участия «во всем», но за годы так глубоко встроилось в «ландшафт», что в нем завелись очень разные процессы. Начиная от внутреннего сервиса по расчету премии и заканчивая некоторыми операционными процессами, которые, в идеале, не должны работать на КХД (других возможностей реализации в банке на тот момент просто не существовало).
На старте проекта было очень сложно оценить его масштабы. Понимание приходило по мере работы: мы собрали всех потребителей, проанализировали все сервисы. Оказалось, что так или иначе к работе придется подключать практически все IT-подразделения банка и много коллег из бизнеса. Из-за того, что работа с хранилищами у многих была реализована по-разному, требовалось, как минимум, тестировать сервисы после их переноса и удостоверяться, что все работает так, как надо.
Тут надо понимать, что процесс цифровой трансформации, который начался в банке в 2018 году, происходил с таким масштабом, что уместно вспомнить поговорку «пока противник рисует карты, мы вручную меняем ландшафт». IT-ландшафт менялся так быстро, что помимо перевода пользователей на новую платформу, приходилось еще и перепиливать работу хранилища под работу с новыми системами
Еще одна проблема с которой мы столкнулись в процессе — отсутствие документации. Для многих сервисов она безнадежно устарела. А спросить было не у кого — многие из тех, кто вел ее, уволились, перешли в другие подразделения. Выуживать данные приходилось с огромным трудом. Часто перенос таких сервисов на новую платформу превращался в задачу по созданию этих сервисов заново.
Вот пример: в банке заработал Розничный кредитный конвейер. Все заявки, которые оформляют клиенты, стали проходить через эту систему. Главная ее задача — сократить время одобрения заявки (в некоторых случаях на это теперь уходят минуты, а не дни). Все аналитические, прогнозные модели, и еще кучу сервисов конвейера пришлось переводить на работу с новой системой.
Помимо технических трудностей, мы столкнулись с чисто человеческими проблемами: многих пришлось убеждать перейти на новое КХД и переламывать принцип «работает — не трогай». Люди просто не видели смысла что-то менять. Даже те, кто попробовал работать с новой платформой и убедился, что она лучше, откладывали переход «на потом». На увещевания ушло около трети всего времени, затраченного на переход.
Некоторые подразделения начали жаловаться, что с новой системой выросло время ожидания данных. Стало понятно, что нужно оптимизировать популярные запросы — иначе будут замедляться ключевые бизнес-процессы.
В качестве метаданных для метрик под оптимизацию подтягиваются логи от СУБД, которые можно анализировать — например, отследить эффективность использования объектов и витрин. Мы прошлись по логам и поняли, что пользователи определенного департамента массово обращаются к нескольким объектам витрин всегда джойном: берется один объект и джойнится другой. И так для каждого пользователя много раз ежедневно.
Либо же в процедуре объекты используются последовательно: то есть сделали манипуляцию с одним, затем с другим и обязательно берут атрибуты из второго объекта. Или всегда используют объект, а в нём один атрибут умножают на курс валюты.
Регулярно изучая дашборд на Graphana и выхватывая оттуда подобные паттерны, мы начали собирать хит-парады неоптимальных запросов. ТОП-10 рассылаются разработчикам и в поддержку — они подхватывают и оптимизируют всё, начиная с самого надоедливого.
В результате архитектору моделей данных видно, какие пользовательские манипуляции нужно реализовывать изменением ETL. Чтобы пользователю не приходилось джойнить, и был один объект, который позволит просто сделать SELECT. Если какую-то формулу часто используют, то её разработчик тоже сделает в ETL-тракте, а пользователь тогда сможет получить данные в готовом виде.
DevOps/DataOps
Для оптимизации процесса разработки в КХД мы решили построить CI/CD-процесс на базе инструментов, которые уже использовались в банке другими подразделениями, но не применялись к работе с СУБД.
У департамента появился репозиторий в Git и пайплайны в Teamcity, а вся работа по изменению хранилища велась через pull-request в Bitbucket — с непрерывной интеграцией (feature-ветки разных спецов → общая release-ветка) и непрерывной доставкой изменений.
Так как речь шла об автоматизации, потребовалось создать стандарты, без которых она невозможна: правила хранения кода в Git и правила написания кода на SQL. Но самое интересное у нас внутри пайплайнов Teamcity. Мы не смогли использовать готовые решения, которые не подходили из-за специфики БД SAP IQ, и не хотелось зависеть от сторонних продуктов. Поэтому все шаги по трансформации, тестированию и установке поставки написали на Python сами.
В созданном фреймворке есть утилиты, необходимые для проведения патча по всем этапам сценария установки:
сборка патча;
очистка среды на билд-сервере;
создание необходимого количества сущностей окружения;
тестовая установка, регресс-тестирование объектов.
Также мы нагрузили фреймворк вспомогательными утилитами, которые упрощают задачу разработчикам, помогают контролировать актуальность репозитория, собирают мусор (экспорт DDL-объектов в нужном для Git формате, мониторинговые отчеты о расхождении Git и прода IQ, разбор веток гита с автоматическим очищением ненужных и т.п).
Также мы разработали необычный пилот: консистентный срез данных, необходимых для отладки в изолированной среде. Срез нужен, чтобы не поднимать для каждого разработчика свою виртуалку. Написанная на Python утилита, по условиям, выставленным к одной или нескольким таблицам, собирает данные, руководствуясь ключевой целостностью, и дообогащает их справочной информацией.
К заголовкам таких временных табличек прибавляется уникальное для среды имя типа: “Вася”. Таким образом для каждого разработчика можно создать среду даже в рамках одного сервера — изолированную от других, и содержащую только необходимую для тестирования информацию.
Как все мониторить?
В какой-то момент пришло понимание, что необходимо создать единую систему, которая была бы простой, легко поддерживаемой, гибкой и масштабируемой. Справились за пять дней. Система могла отслеживать работу различных, не связанных друг с другом процессов. Поэтому и назвали мы ее без изысков — «Универсальный мониторинг». Сейчас она следит более чем за 200 метриками КХД.
Создать систему так быстро и сделать ее простой нам помогла стандартизация инструментов разработки. Мы использовали уже имеющиеся — ETL-систему IBM InfoSphere DataStage + SQL. Гибкость достигается за счет DbC-интерфейса для подключения параметризации, координат, источников и SQL-запросов. А расширяемость — благодаря DataStage, который позволяет параллельно запускать одни и те же процессы с разными параметрами. Все это позволяет нашему мониторингу использовать одновременно несколько источников для получения метрик.
В начале цикла работы система мониторинга получает перечень задач, которые нужно запустить, исходя из внутреннего расписания (они могут стартовать в определенные интервалы времени, по определенным дням, с нужной частотой). Система читает параметры каждой из них, подключается к двум источникам и с помощью SQL-запроса получает из одного текущее значение метрики, а из другого — пороговые значения для нее. Значения сравниваются, логируются, отправляются пользователям. Если они выходят за пороговые, пользователям отправляется сообщение об ошибке. Алерт может прийти по любому каналу — в почту, СМС, мессенджер.
Инспектор
Помимо «Универсального мониторинга» у нас еще есть «Инспектор» — наша внутренняя разработка, которая аккумулирует информацию из различных систем мониторинга и собирает сведения о результатах тестов, анализа объектов или данных. Основная задача инспектора — контроль последовательности проверок в других системах и сбор данных по результатам этих проверок.
Чтобы избежать запуска «ненужных» тестов, на основе данных из множества различных систем, в том числе «Универсального мониторинга», создается очередь запуска — процесс проверок. Например, нет смысла проверять качество данных в базе, если при ее загрузке возникли технические проблемы: если проверка корректности загрузки вернет ошибку, следующая за ней проверка на качество данных не будет запущена до тех пор, пока проблема не будет устранена.
Цепочка проверок может выглядеть, например так: проверка доступности источника —> проверка корректного запуска по выгрузке данных —> завершение выгрузки —> сверка данных с КХД —> контроль согласованных данных —> контроль запуска постобработок в техническом слое —> проверка сборки консолидированного слоя —> контроль сборки пользовательских витрин —> контроль качества данных.
Работа систем (и «Инспектора», и «Универсального мониторинга») визуализируется в Grafana, что позволяет быстро оценивать состояние критичных процессов КХД. А для управления мы сами создали утилиты, которые позволяют быстро запускать и настраивать проверки.
В планах у нас значительная переработка «Универсального мониторинга». Сейчас система по расширяемости приближается к своим пределам. В перспективе мы хотим отказаться от ETL, как от основы этого инструмента и реализовать систему в виде микросервиса. Кроме этого хотим добавить возможность сравнения не только пар значений, но и целых наборов. Забирать данные из большего количества источников, более гибко настраивать расписание и рассылки.
Каталог данных
Во многих крупных компаниях каталог данных ведет отдельное подразделение CDO и для этого используются дорогостоящие enterprise-решения. У на всё организовано внутри IT, своими силами. Но если нет подробного Data Lineage, то аналитики не всегда понимают, где им достать требуемые бизнесом данные. Особые сложности начали возникать на SAP ASE — там система велась с девяностых, расположение данных давно покрыто туманом неизвестности.
Чтобы разобраться с этой проблемой, при объединении КХД мы решили каталог данных, DataLineage и технический глоссарий реализовать в корпоративном Confluence с автоматическим документированием.
Каталог представляет собой описание данных, которые регистрируются и учитываются в автоматизированных системах, а затем перетекают в КХД, где они консолидируются и предоставляются пользователям. Для создания каталога мы собрали несколько разрозненных хранилищ метаданных.
Метаданные в данном случае — это описание нескольких IT-компонентов корпоративного хранилища данных, в том числе и ETL-инструментарий, который позволяет поставлять в DWH данные со всех источников банка. Помимо этого в качестве источника для документирования используется фреймворк на базе PowerDesigner в котором архитекторы моделей данных ведут физические модели STAGE, CORE и Data Mart.
Перенос обновлений в структуре КХД в Confluence реализуется через стандартное API Confluence при помощи разработанного нами фреймворка на Python. Фреймворк работает в одну сторону — от структуры физической модели данных к их описанию. Свои плагины к Confluence писать не стали, обошлись стандартным API, чтобы не вторгаться в работу команды, которая развивает Confluence внутри Газпромбанка.
В результате описаны и постоянно доступны в Confluence:
физические модели данных слоев КХД – STAGE, CORE, Data Mart;
физические модели данных витрин источников;
физические имена таблиц и названия столбцов КХД, источников;
техническое происхождение данных, DataLineage между слоями КХД, трансформация ETL.
Напоследок
Если интересны детали или хотите подробностей о каком-то конкретном направлении работы с КХД, напишите в комментариях, раскроем тему подробней. А пока несколько советов для тех, кто столкнется с похожей задачей.
Не плодите сущности. Сначала может показаться, что самый простой и дешевый выход – создание второго КХД в параллель со старым. Мы попробовали и сидеть сразу на двух стульях нам не понравилось. Как минимум, это выльется в необходимость поддержки двух хранилищ. Плюс появятся сервисы (обязательно появятся), которые должны работать и в новой системе, и в старой. Вам эта головная боль не нужна.
Проведите разъяснительную работу заранее. Сопротивление будет всегда. Пользователи привыкли работать так, как привыкли и не готовы изменить парадигму своей работы даже зная, что изменения к лучшему.
Обеспечьте бесшовность. Этот совет вытекает из предыдущего: чем проще переход, тем легче и проще будет всех уговорить.
Не затягивайте с оптимизацией. Если игнорировать пользователей, жалующихся, что все стало работать дольше (но все ведь работает!), то будет сложнее доносить свою позицию до остальных. Слухи-то расползутся.