Цифра Брокер: оптимизация витрин данных

«Цифра Брокер» - одна из крупнейших российских инвестиционных компаний, работающая на рынке более 13 лет и входящая в число заметных игроков по объему операций частных инвесторов. Компания развивает мобильное приложение и онлайн‑платформу, а за ними стоит брокерская АБС, торговые системы Московской и Санкт‑Петербургской бирж, внутренние CRM‑и DWH‑контур. Хранилище и витрины данных работают в связке с учетными системами, CRM и инфраструктурой риск‑менеджмента - от них зависят управленческие отчеты, регуляторная отчетность и аналитика по клиентам.

Оптимизация шла в боевом DWH, которое обслуживает брокерское направление (отчеты по клиентской активности, оборотам, комиссиям и позициям, а также витрины для продуктовой и риск‑аналитики). Уже в первые месяцы удалось в разы сократить время формирования ряда ключевых витрин данных.

1. С чем пришел клиент

К моменту старта проекта у клиента уже было корпоративное хранилище данных, развивавшееся несколько лет. Его строили под растущие запросы бизнеса - новые продукты, требования регулятора, развитие мобильного приложения. Со временем в архитектуре накопился технический долг.

Baseline формировали по нескольким индикаторам. Смотрели длительность ключевых процедур и время готовности отчетов, фиксировали количество инцидентов в месяц, связанных с DWH, и объем ручных операций поддержки (перезапуски, корректировки, дополнительные проверки).

2. Откуда брались данные и почему к ним были высокие требования

Хранилище данных брокера собирает информацию сразу из нескольких классов систем. Основной поток идет из учетных и торговых систем (сделки на Московской и Санкт‑Петербургской биржах, операции клиентов, остатки и позиции по счетам, тарифы и комиссии). Дополнительно загружаются CRM‑данные о клиентах, их сегментах, реакциях на продуктовые кампании. На стороне регуляторной отчетности присутствуют свои наборы требований к качеству и полноте данных.

Качество исходных данных было хорошим, но в хранилище оказалось много исторических слоев логики. За годы внедрялись новые правила тарификации, менялись продукты, появлялись новые площадки, а в DWH оставались следы всех этих изменений.

3. Какое решение выбрали

Команда хотела сохранить существующее хранилище и доработать его так, чтобы оно выдерживало нагрузку и рост бизнеса. Поэтому выбрали точечное усиление команды через аутстаффинг Senior PL/SQL‑разработчика с опытом DWH‑проектов.

Система, вокруг которой строился проект, - это корпоративное DWH брокера, разделенное на стандартные слои: загрузка (staging), интеграционный слой и витрины данных для бизнес‑направлений. DWH интегрируется с брокерской АБС, торговыми системами бирж, CRM и контуром отчетности. Именно здесь находятся витрины данных - клиентские профили, торговая активность, комиссии, остатки и позиции, отчеты под регулятора.

Решение заключалось в пересборке критичных участков внутри этого DWH. В задачи вошло перепроектирование части витрин, переписывание PL/SQL‑процедур, наведение порядка в индексах и запросах, а также внедрение минимального, но рабочего мониторинга длительности процессов.

4. Как шли работы и сколько это заняло

Первые три с половиной месяца ушли на интенсивную фазу оптимизации. Работу разбили на короткие итерации: брали одну витрину или набор взаимосвязанных процедур, формулировали гипотезы по оптимизации (индексы, переписывание запросов, декомпозиция логики), согласовывали подход с внутренним DWH‑лидом и владельцами данных, а затем проверяли изменения на тестовом контуре.

После первых результатов формат работ эволюционировал. Аутстаффинг перестал быть чисто ресурсной историей - наш PL/SQL‑разработчик стал фактическим техническим лидом по части DWH‑инициатив. Проект перешел в режим долгосрочного сопровождения и развития.

5. Кто делал проект - команда и роли

Со стороны БизнесМатики в проекте участвует опытный PL/SQL Developer с фокусом на DWH‑проектах (оптимизация запросов, проектирование витрин, работа с большими объемами данных и высоконагруженными базами). Его задача была предлагать архитектурные решения, которые вписываются в реальность брокера.

6. На чем все это работает

Технологическая основа проекта - DWH на базе промышленной СУБД. Логика хранилища реализована на PL/SQL (хранимые процедуры, пакеты, триггеры, которые обрабатывают данные из источников и формируют витрины).

Для интеграций используются стандартные механизмы выгрузки из учетных и торговых систем, а также ETL‑процессы, перенаправляющие данные в staging‑слой DWH. В хранилище выделены несколько слоев - от сырых данных до агрегированных витрин для отчетности и аналитики.

В рамках проекта активно применялись средства анализа планов выполнения запросов, переиндексация и настройка статистики, а также внутренние средства мониторинга длительности процессов. Отдельного упора на модные технологические тренды не делали: ключевой эффект дала системная работа с уже имеющимся стеком.

7. Итоги

Наш PL/SQL‑разработчик, который работает над проектом с 2023 года, описывает специфику так:

DWH‑проекты в брокерском сегменте непростые. Приходится работать с большими объемами данных и учитывать специфику брокерской деятельности, которая многим разработчикам не знакома. Тем не менее все поставленные задачи удается решать, и на горизонте видно продолжение работы - новые витрины и поддержка существующих контуров.