Разработка систем интеграции данных для банковских хранилищ данных
(Журнал "Банковские технологии", № 7, 2007 год)

Виктор Сусойкин, руководитель Управления финансовых приложений, РДТЕХ
Анатолий Волков, руководитель Отдела систем интеграции данных, РДТЕХ

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

С этой задачей справляются BPM-системы (Business Performance Management - Управление Эффективностью Бизнеса), центральной компонентой которых является хранилище данных.

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

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

Ключевой компонентой технологии построения хранилища является разработка системы интеграции данных, реализующей ETL-процесс (Extract-Transform-Load - Извлечение-Преобразование-Загрузка) наполнения банковского хранилища. Основная сложность в реализации данного процесса заключается в решении проблем идентификации и обработки "грязных данных".

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

Технология разработки систем интеграции данных
Большинство методологий создания хранилищ данных, в том числе Oracle Data Warehouse Method, базируются на принципе итерационной технологии разработки. При этом в процессе реализации системы интеграции данных, являющейся неотъемлемой частью хранилища данных, выделяют следующие шаги:

1. Идентификация данных из корпоративных и внешних источников, которые будут формировать хранилище.
2. Анализ источников данных и проектирование процессов загрузки. При этом важным моментом является выявление бизнес-правил, по которым данные будут отображаться в хранилище.
3. Определение процедур трансформации, очистки и логической интеграции данных источника перед их помещением в хранилище, а также регламентирование выполнения этих процедур, обновляющих хранилище данных.
4. Создание метаданных, описывающих источники и способы преобразования данных.
5. Заполнение хранилища данных. Этот процесс может потребовать нескольких итераций с учетом возможного уточнения структур данных при анализе схемы данных хранилища.

Классификация компонент ETL-процесса
Применительно к банковским хранилищам основу системы интеграции данных составляет ETL-процесс (см. рисунок), все операции которого можно классифицировать на 4 типа: загрузка из источников в stage-область, загрузка из stage-области в хранилище данных, верификация данных, перезагрузка данных. Цепочка загрузки данных "источники" - "stage-область" - "хранилище данных" состоит из 5 этапов, каждый из которых делится на определенное количество фаз.

Загрузка данных
Введем следующие обозначения в именовании фаз указанных 5 этапов цепочки загрузки. Название фазы в общем виде имеет вид NNSD_DECRIPTION, где NN - номер этапа, в рамках которого реализуется данная фаза, SD - краткий символьный идентификатор фазы и DECRIPTION - краткое описание сути фазы.

Первая часть ETL-процесса реализует загрузку из систем-источников в Stage-область. В ходе обязательной фазы 01A_EXTRACT производится копирование данных из удаленного источника в Stage-область. При этом не производится преобразования данных, но в ряде случаев появляется потребность в преобразовании несовместимых типов и наложении определенных фильтров. Далее, на протяжении необязательной фазы 01D_DIRTY производится первичная идентификация "грязных" данных. При выполнении процессов фазы формируется журнал, содержащий информацию о выявленных грязных данных. Следующая часть ETL-процесса реализует загрузку из Stage-области в Хранилище данных. Фаза 02A_GLOBAL_ID подразумевает процесс формирования глобальных ключей (используется при загрузке справочников). При этом производится анализ источников на предмет выяснения пересекаемости записей справочников и возможности объединения строк. Последующая необязательная фаза 2D_DIRTY отвечает за выявление возможных ошибок формирования глобальных ключей при объединении из разных источников. Фазы третьего этапа идентифицируют изменения в источнике: 03A_FIND_CHANGE определяет по каждому источнику перечень изменившихся с момента последней загрузки записей, 03A_FIND_DELETE - перечень удаленных в источнике записей. Следующая фаза 04A_PREPARE реализует основные алгоритмы преобразования и формирования строк в том виде, в котором они будут храниться в Хранилище. В случае, если все поля, участвующие в соединении, не изменились, формирование строк происходит в ходе фазы 04F_PREPARE_FAST. В завершении 4-го этапа (фаза 04D_PREPARE_DELETE) производится маркировка строк, которые будут подвержены удалению. На последнем 5-м этапе производится непосредственно загрузка в Хранилище данных - фаза 05A_LOAD_DWH (в случае справочников, данная фаза отвечает за загрузку в структуры, содержащие актуальные значения). При необходимости отслеживания исторических изменений реализуется также фаза 05H_LOAD_DWH_HISTORY.

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

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

При проверке корректности бухгалтерской базы по бизнес-правилам идет подсчет остатков и оборотов по отдельным лицевым и/или балансовым счетам. При этом для активного счета используется формула B_b+T_d-T_k=B_e, а для каждого пассивного счета B_b-T_d+T_k=B_e, где B_b - входящий остаток, B_e - исходящий остаток, T_d - дебетовый оборот, T_k - кредитовый оборот.

Для каждого счета, в случае дублирования остатков (для каждого периода хранится и входящий, и исходящий остатки) должен соблюдаться принцип преемственности остатков: Bⁿ_b = B^n-1_e, где Bⁿ_b - входящий остаток n-го периода, B^n-1_e - исходящий остаток (n-1)-периода.

Подсчет остатков по отдельным счетам на каждый период ведется по образцу , где Bⁿ_ia - остаток i-го активного счета на n-й период, Bⁿ_jp - остаток j-го пассивного счета на n-й период, а оборотов за каждый период по формуле , где Tⁱ_nd - дебетовый оборот по i-му счету за n-й период, Tⁱ_jk - кредитовый оборот по j-му счету за n-й период.

После этого осуществляется сверка проводок и ежедневных оборотов по лицевым счетам за каждый период:
, где T^nc_id - дебетовый оборот по i-му счету за n-й период в валюте счета, Tr^nc_jid - сумма j-й проводки по дебету i-го счета за n-й период в валюте счета;

, где T^nc_ik - кредитовый оборот по i-му счету за n-й период в валюте счета, Tr^nc_jik - сумма j-й проводки по кредиту i-го счета за n-й период в валюте счета;

, где T^nr_id - дебетовый оборот по i-му счету за n-й период в рублевом эквиваленте, Tr^nr_jid - сумма j-й проводки по дебету i-го счета за n-й период в рублевом эквиваленте;

, где T^nr_ik - кредитовый оборот по i-му счету за n-й период в рублевом эквиваленте, Tr^nr_jik - сумма j-й проводки по кредиту i-го счета за n-й период в рублевом эквиваленте.

Проверка корректности договорной базы по бизнес-правилам до разнесения по срокам идет по каждому договору и по каждой балансовой статье. Первая проводится по формуле , где A_ij - сумма i-й акции плана гашения / выплат по j-му договору, B_j - остаток на счете, на котором ведется j-й договор. Вторая - по формуле , где S_jl - сумма по j-му договору, входящему в l-ю балансовую статью, B_il - остаток на i-м счете, входящем в l-ю балансовую статью.

При проверке корректности разнесения по срокам для каждой балансовой статьи используется формула , где Ter_jl - сумма, приходящаяся на j-й интервал по l-й статье, B_il - остаток на i-м счете, входящем в l-ю балансовую статью.

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

Обратная связь
За более подробной информацией Вы можете обратиться в Рекламно-представительский отдел РДТЕХ
Телефоны в Москве: (495) 995-0-999

О компании | Контакты | Карта сайта | RSS-канал | Пишите в РДТЕХ

Copyright © РДТЕХ. Все права защищены.
1992 - 2010