Обзор подготовлен

версия для печати
Пример решения: Как выбрать решение по созданию единого хранилища данных в банке

Пример решения: Как выбрать решение по созданию единого хранилища данных в банке

Сегодня банки понимают необходимость и ценность консолидированного решения для сбора, обработки и анализа данных на основе корпоративного информационного хранилища. Компания РДТЕХ предлагает комплексное решение, в рамках которого необходимые банку функциональные модули (системы обязательной и управленческой отчётности, финансового планирования и бюджетирования, оценки рисков) создаются на основе единого, корпоративного хранилища данных на базе технологий Oracle и Informatica.

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

Тенденция решать все эти задачи точечно, на уровне отдельных департаментов и подразделений, при помощи различных систем осталась в прошлом: сегодня банки понимают необходимость и ценность консолидированного решения для сбора, обработки и анализа данных на основе корпоративного информационного хранилища (далее КИХ).

При выборе поставщика единого корпоративного хранилища данных необходимо принимать во внимание, что решения, предлагаемые крупными западными вендорами, помимо очевидных плюсов – использования проверенных лучших практик для финансовой отрасли, упрощения процессов интеграции банка в мировую систему финансовой коммуникации - обладают и существенным недостатком, а именно - не учитывают специфику национального законодательства, которое в России и странах СНГ значительно отличается от западного.

Понимая все эти трудности, компания РДТЕХ использует комплексный подход, в рамках которого необходимые банку функциональные модули (системы обязательной и управленческой отчётности, финансового планирования и бюджетирования, оценки рисков) создаются на основе единого, консолидированного корпоративного хранилища данных. При этом хранилище строится при помощи передовых технологий крупнейших вендоров: Oracle и Informatica, на основе типовой логической модели, разработанной специалистами РДТЕХ под специфику национальных банков России и стран СНГ. Особое внимание при построении хранилища уделяется процессу сбора, очистки, верификации данных. Грамотное построение процесса загрузки информации в хранилище гарантирует использование полных, непротиворечивых, актуальных данных при построении любых видов отчётности (как обязательной, так и управленческой), анализе рисков, планировании и бюджетировании.

Системная архитектура корпоративного хранилища данных

Решение «Система корпоративной и обязательной отчетности финансового института на основе единого хранилища данных» РДТЕХ представляет собой не просто хранилище данных, консолидирующее информацию из банковских систем-источников, это комплексное решение, состоящее из набора модулей, каждый из которых обладает определенной функциональностью (см. Рис. 1).

Системные модули:

  • модуль «Загрузка данных» (ETL): предназначен для извлечения, трансформации, консолидации, проверки и приведения к единому формату информации, находящейся в автоматизированных системах банка;

  • модуль «Безопасность»: предназначен для управления правами доступа пользователей к КИХ;

  • модуль «Рабочее хранилище данных (далее РХД)»: содержит типовую банковскую модель , предназначенную для накопления и постоянного хранения сделочной информации, а также данных бухучета, клиентских данных и нормативно-справочной информации (НСИ).

Функциональные модули – «Обязательная отчётность ЦБ» , «Налоговая отчётность» , «Отчётность МСФО» , «Управленческая отчётность» , «Анализ рисков» и др. – являются витринами данных и используют в своей работе очищенные и консолидированные данные из РХД. Функциональные модули, в отличие от системных, предназначены для решения конкретных задач анализа данных и построения отчётности, которые ежедневно возникают у бизнес-подразделений банка.

Концептуальная схема корпоративного хранилища данных РДТЕХ Рис. 1

Модуль «Загрузка данных (ETL)»

Системныймодуль «Загрузка данных (ETL)» решает первоочередную задачу – создание единого источника унифицированной, консолидированной информации, объединяющего все разнородные, нередко дублирующиесяили неполные данные, хранящиеся в различных системах-источниках банка. Таким образом, хранилище данных становится единственным источником для заведомо правильной чистой информации, структурированной в единую типовую банковскую модель, позволяющую использовать данные для всестороннего анализа и формирования аналитической, обязательной и специализированной отчётности банка.

Основными функциональными блоками данногомодуля являются:

  • ETL-средство

    Средство получения и преобразования данных из различных систем-источников, единая платформа интеграции данных, которая позволяет получать доступ и проводить интеграцию данных любого формата, из любых источников и доставлять их в хранилище с высокой скоростью. Обычно в качествеETL-средств в решении РДТЕХ используются продукты Informatica PowerCenter или Oracle Data Integrator.

  • Оперативный склад данных КИХ (Stage-область)

    Промежуточная область хранения загруженных данных. В этой области выполняется очистка, верификация данных и приведение их к единому формату хранения в РХД.

  • Блок верификации данных

    Совокупность средств, выполняющих проверку корректности загружаемых данных.

  • Рабочее хранилище данных (РХД)

    Область хранения очищенных и консолидированных данных, загруженных из оперативного склада данных КИХ.

  • Интерфейсы управления

    Интерфейсы управления – набор автоматизированных рабочих мест(АРМ), позволяющих осуществлять управление модулем «Загрузка данных».


Информация из систем-источников банка с помощью промышленного ETL-средства попадает в Stage-область, где происходит консолидация данных, очистка, верификация, приведение к формату типовой банковской логической модели, на базе которой строится рабочее хранилище данных. 

Загрузка данных из систем-источников банка в РХД может происходить в следующих режимах:

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

  • Регламентная загрузка данных. Производится в ночное время, выполняет загрузку изменений данных справочников и данных-фактов за предыдущий операционный день.

  • Исправительная загрузка (перезагрузка) данных. Даёт возможность перезагрузки данных за определённый период времени в прошлом. Например, перезагрузка справочных данных приводит к частичной замене истории изменений справочника за период, пересекающийся с периодом перезагрузки по тем данным, которые подвергаются перезагрузке.


Порядок обработки данных в ходе работы модуля «Загрузка данных»

Порядок обработки данных состоит из пяти последовательных фаз, каждая из которых выполняет соответствующие преобразования данных.

Порядок обработки данных

1. Загрузка данных из системы-источника (PHASE_01).

На данной фазе происходит копирование определенного набора данных из системы-источника банка в Stage-область и его подготовка для дальнейшего преобразования.

2. Формирование глобальных ключей (PHASE_02).

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

3. Поиск изменений относительно текущего состояния РХД (PHASE_03).

  • Определение новых и измененных записей в источнике;

  • Определение удаленных строк в источнике.

4. Преобразование и подготовка данных для загрузки вРХД (PHASE_04).

На данной фазе происходит формирование строк загружаемой сущности в том виде, в котором они будут храниться в РХД. Для этого на основе исходной постановки задачи по загрузке выполняется привязка атрибутов таблицы системы-источника и атрибутов таблицы РХД (возможно, с использованием необходимых преобразований); определение и простановка условий соединения с зависимыми таблицами РХД; вычисление хеш–значения загружаемых атрибутов.

5. Загрузка данных в РХД (PHASE_05).

  • Загрузка в РХД структур, содержащие актуальные данные. Вставка новых записей и обновление уже существующих данных в актуальном срезе загружаемой структуры.

  • Загрузка данных в исторические таблицы. Загрузка данных в таблицу с поддержкой истории изменений по всем значимым (т.е. не служебным) полям загружаемой структуры.

Типы загрузки

При загрузке можно выделить следующие типы загрузкиданных:

  • загрузка таблиц-справочников, при которой используются все фазы, описанные выше;

  • загрузка таблиц-фактов, при которой могут быть пропущены следующие фазы из описанных выше:

    • PHASE_02;

    • PHASE_03;

    • PHASE_05H.

Проверка качества данных

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

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

В корпоративном информационном хранилище РДТЕХ механизм отслеживания качества данных, загружаемых в хранилище, автоматизирован, проверки данных проходят на различных этапах их загрузки и использования (см. рис 3).  Модуль верификации данных, являющийся универсальным, реализуется процедурами, зарегистрированными в специальном справочнике правил верификации. Проверка данных может осуществляться как на уровне одной строки, так и на уровне таблицы.Набор правил верификации является гибким, расширяемым и может изменяться в процессе эксплуатации модуля.

Концептуальная модель потока данных с зонами покрытия проверками данных

Проверки данных выполняются автоматически при движении информации по всем потокам, передающим данные от системы-источника до витрины.Потоки данных характеризуются следующими параметрами:

  • период, за который происходит загрузка;

  • источник данных – совокупность первичных данных в одном формате с единой кодификацией данных (первичных ключей и связей) и НСИ;

  • режим загрузки – разновидности загрузки: инициализирующая, регламентная или исправительная.

Проверки выполняются автоматически при движении данных по всем потокам в следующих ключевых местах:

  1. Точка выполнения технических проверок над данными (фаза PHASE_01B_DIRTY процесса загрузки данных). Проверки запускаются после того как осуществлён захват данных из источника и данные размещены в оперативном складе (Stage-область) без трансформации. На данном этапе выполняется первичная верификация загружаемых данных: проверка форматов полей, типов данных, обязательности их заполнения и т.д. 

  2. Точка выполнения технических проверок над данными (фаза PHASE_04B_DIRTY процесса загрузки данных). Проверки запускаются после преобразования (трансформации) данных к единому виду РХД. На этот этап поступает только часть данных (новые и изменённые) за период загрузки. Выполняется верификация данных на предмет уникальности записей, ссылочной целостности и соответствия данных формату РХД.

  3. Точка выполнения бизнес-проверок. Проверки выполняются над данными, размещенными в РХД. На данном этапе обрабатываются все данные за период. Основные проверки данного этапа – бухгалтерские и функциональные. Например, проверка остатков и оборотов активных счетов в рублях и валюте, контроль баланса, сверка графика погашения кредитови остатков на ссудных счетах и т.д.

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

Функционал модуля верификации данных позволяет на регулярной основе автоматически проводить проверки качества данных и в оперативном режиме предоставлять результаты проверокв виде отчётов для пользователей, ответственных за исправление ошибок.

Модуль «Рабочее хранилище данных (РХД)». Типовая модель данных РДТЕХ для банков.

На основании большого опыта работы в области построения хранилищ данных для отечественных и зарубежных финансовых организаций, специалисты РДТЕХ разработали типовую банковскую модель данных, описывающую все бизнес-процессы банка в их взаимосвязи. Данная модель лежит в основе РХД и  обеспечивает единую основу для подготовки всех видов банковской отчётности, бюджетирования, планирования, расчёта рисков и других бизнес-задач.

Типовая модель данных корпоративного хранилища состоит из следующих компонентов:

  • Логическая модель. Представляет собой наборы взаимосвязанных сущностей, соответствующихпо уровню детализации понятиям первичного учёта банковской предметной области. Сущности логической модели  группируются в такие бизнес-области, как Субъекты, Бухгалтерия, Кредитные сделки, Депозитные сделки, Банковские карты и другие;

  • Физическая модель. Отображает логическую модель на уровень таблиц (и других объектов) базы данных Oracle;

  • Глоссарий модели. Описывает в бизнес-терминах определения всех атрибутов/сущностей логической модели.

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

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

Описание взаимосвязей между различными сущностями логической модели реализовано при помощи технологии визуализации - продукта OracleDesigner - что позволяет значительно облегчить процесс описания модели,  внесения изменений и поддержку их версионности. При помощи данной технологии всегда возможно отследить, как та или иная сущность логической модели связана с физической моделью или системой-источником, т.е.  перейти от конкретной сущности логической модели к соответсвующей ей таблице в рабочем хранилище данных или определённому набору данных источника, содержащегопервичную информацию. В репозитории Oracle Designer легко проанализировать источники данных в различных разрезах при помощи отчётов, например, наборы загруженных в КИХ данных и их качество.

Отчёты по логической модели строятся на базе продукта Oracle Business Intelligence Publisher и экспортируются в различные форматы - XML, RTF, PDF, XLS и HTML – что делает типовую модель данных ещё более удобной в использовании.

Типовая  банковская модель РДТЕХ успешно используется в реальной практике внедрения хранилищ данных в коммерческих банках России и стран СНГ.

Функциональные модули хранилища данных

На основании собранной в системах-источниках проверенной информации, трансформированной согласно логической модели, производится наполнение функциональных модулей – витрин данных, которые завершают работу комплексного решения по хранению и анализу данных в банке.

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

В комплексном решении РДТЕХ реализованы основные функциональные модули, необходимые для эффективной деятельности банка:

  • Модуль «Обязательная отчётность для ЦБ»

  • Модуль «Налоговая отчётность»

  • Модуль «Отчётность МСФО»

  • Модуль «Управленческая отчётность»

  • Модуль «Анализ рисков»

  • Модуль «Финансовое планирование и бюджетирование»

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

О компании: Компания РДТЕХ успешно работает на рынке информационных технологий с 1992 года. РДТЕХ предлагает комплекс услуг для финансовых институтов - разработку заказных систем на базе программных продуктов ведущих мировых производителей, лидеров рынка корпоративного обеспечения – Oracle, i2, внедрение бизнес-приложений Oracle, в том числе специализированных решений на платформе отраслевого бизнес-приложения Oracle Financial Services Analytical Applications (OFSAA), консалтинг, продажу лицензий и технической документации, авторизованное обучение и техническую поддержку ПО Oracle.

Анатолий Волков, директор Центра финансовых решений РДТЕХ
Евгений Пустозёров, консультант Центра финансовых решений РДТЕХ

Техноблог | Форумы | ТВ | Архив
Toolbar | КПК-версия | Подписка на новости  | RSS