Статья была написана 22.03.2008 для блога компании Ирбикон. Автор – Тагир Билалов
Работая в ПрограмБанке, в проекте “Нострадамус”, я познакомился с одной из сторон создания банковских хранилищ данных на основе реляционной модели данных. Данный текст я написал после семинара своего нового работодателя, компании Ирбикон, для бывших коллег, многие из которых активно интересовались решениями SAS (в свое время аналитический комплекс “Нострадамус” разрабатывался на технологиях SAS). Мои новые коллеги могут обвинить меня после прочтения в отсутствии патриотизма, но у меня есть поводы с почтением относиться к тому, чем занимался раньше.
Особая благодарность Михаилу Капитонову за его ценные сведения о мировых банковских стандартах Basel и комментарии по архитектуре SAS BIS в ходе семинара и в кулуарах, Федору Хилькевичу за мудрое руководство нашим МДМ-овским коллективом и его жесткую линию разработки в соответствии со стандартами и Вадиму Александрову, вместе с которым мы проводили самостоятельное исследование наличия в схеме BIS DDS такого понятия как “Блок”.
Для банковского сегмента SAS предлагает Banking Intelligence Solution, в рамках которого специалистами внедрения предполагается создание и последующее наполнение хранилища детальных данных – BIS DDS (Detailed Data Storage), рекомендованная схема которого создана по стандартам Basel 1,2,3, то есть отвечает общемировой схеме банковского бизнеса, которая порядком отличается от российской, где очень серьезная часть отводится учету бухгалтерских операций. На такой случай SAS предлагает унифицированный подход к кастомизации хранилища.
Западная модель банковского бизнеса вращается вокруг прочнейшей связки “Клиент” и “Сделка” (Account). Под этим словом никоим образом не понимается привычное российским разработчикам понятие банковского счета. Это именно сделка. Которой присущ определенный риск, и, в конечном счете, вся отчетность западных банков должна отражать именно риск его банкротства.
Итак, в основу угла кладется сделка с клиентом. Сделка, которая может относиться к депозитам, кредитам, страховому бизнесу (которым на западе занимаются именно банки, в то время как в России узаконено разделение кредитных и страховых компаний) и т.д. Так возникает связка “Сделка” и “Продукт” (типичный пример – депозитный вклад “Пенсионер Плюс”). В свою очередь клиенты делятся на сегменты. И так далее… Полная схема хранилища BIS DDS включает более 700 таблиц, и если постараться, можно найти в ней таблицы и связки, подходящие в случае конкретного внедрения. Так, например, совсем недавно мы приступили к внедрению банковского измерения “Блок” (ДКМСБ, VIP, Private, Investment, Корпоративный блок и т.п.). После некоторого анализа обнаружили в предлагаемой схеме таблицу BUSINESS_LINE и ее историзированные связки с таблицами ORGANIZATION_UNIT и FINANCIAL_PRODUCT. После дополнительной кастомизации с данной таблицей будут связаны и таблица сделок и отдельные проводки.
Вот и дошла очередь поговорить о проводках как об основе российских стандартов учета. В западной модели места для них не нашлось, но наши специалисты отмечают, что при каждом внедрении SAS BIS в российском банке требуется создавать и поддерживать механизм отслеживания изменений в полной таблице банковских проводок, куда могут входить односторонние, двусторонние и даже трехсторонние (с учетом курсовой разницы) проводки. Кстати, для кросс-курсов валют по какой-то причине таблицы в BIS DDS не обнаружилось, но когда это обсуждалось на нашем семинаре, я как раз пропустил объяснение возможных причин отсутствия наинужнейшей в любой финансовой аналитике таблицы CURRENCY_RATE.
Собственно, почему и зачем следует придерживаться стандартов SAS? Дело в том, что при соответствии банковского хранилища установленной схеме или незначительной кастомизации гораздо легче переходить с версии на версию, и, что самое главное, поверх BIS DDS может быть установлен один из других серийных продуктов SAS для банковской сферы, например, кредитный скоринг, решения FM (финансовая аналитика, корректировки и трансформация отчетности, линии прогнозирования и т.д.) и SPM (всевозможное планирование и отчетность по соблюдению KPI) и некоторые другие.
Теперь что касается механизма работы и стратегии внедрения. Тут вся изюминка в том, что никаких ручных модификаций какой-либо информации сделать нельзя, разве что это специально оговорено в виде формата изменения поставляемых Банком справочников типовых измерений. Специалисты и аналитики SAS должны лишь обеспечить технологическую цепочку импорта данных из систем-источников (обычно OLTP-системы), их унификации, объединения, проверки целостности и окончательной загрузки в хранилище DDS. Как поступить с полученной информацией в дальнейшем – дело вкуса Заказчика, но менять ее невозможно. Зато можно и нужно эффективно использовать! Как правило, создаются масштабные кубы (многомерные таблицы) и их детальные данные, которые в дальнейшем используются OLAP-сервером и доступны для анализа аналитиками банка через обычный браузер с поддержкой Java. Но, что также было отмечено на нашем семинаре, хранилище SAS BIS может быть использовано и как промежуточная ступень, как система-источник информации для других банковских систем. Так, в нашем конкретном случае по информации, каждодневно загружаемой и обновляемой в хранилище, формируется выходной файл с коллекторской информацией о должниках и их просрочках платежей. Кроме того, как правило, параллельно внедрению хранилища стартует и проект Data Quality, ориентированный на автоматическую проверку корректности данных в хранилище. Например, узнать, у каких клиентов не заполнен адрес или что-то в таком духе.
Сложностей во внедрении хватает. Полной цепочке загрузки соответствуют мегабайты кода и макросов. Но на удивление все работает достаточно быстро, в основном, за счет полного отсутствия транзакционности в таблицах SAS. Плюс уникальная работа с датастепами, в которых за один шаг обрабатывается одна запись таблицы и которую на этом шаге можно как угодно обработать в зависимости от информации в записи. Наличествует в SAS и поддержка SQL-механизмов, которые порой оправдывают себя на небольших (до миллиона записей) таблицах. Но, несмотря на то, что мне и другим разработчикам первое время очень хотелось написать быстренький и понятненький SELECT, в реальности всегда оказывается, что оптимизированный датастеп работает быстрее, хоть на его разработку и уходит гораздо больше времени.
Непривычным для программиста является и полное отсутствие средств отладки – понять, что и как у тебя произошло на том или ином этапе, можно лишь по данным в исходных и результирующих таблицах, и по лог-файлу, размер которого для разовой полной загрузки хранилища может составлять десятки мегабайт.
Ну и напоследок несколько других занятных фактов. В практике внедрения SAS в России встречались случаи, когда для успешного внедрения приходилось менять стандарты ведения бизнеса Банка. Объем хранилища с информацией по кредитным продуктам конкретно нашего банка за два года работы – порядка 300 Гигабайт. Основные затыки в производительности SAS всегда связаны с работой дисковой подсистемы, а существующее ограничение по размеру используемой оперативной памяти в 2 Гигабайта (лицензия включала в себя только 32-битное решение) довольно существенное. Ошибки на этапе загрузки, как правило, не очень критичны для банковского бизнеса, так как день можно проработать на данных предыдущего дня, оперативно исправить ситуацию и при следующей загрузке данные будут актуализированы. Информационный портал хранилища можно донельзя разнообразить при помощи разнообразных стандартных и пользовательских портлетов (используется связка Java и ASP технологии, а провайдером доступа выступает продукт BEA Weblogic).
Ну и, конечно, в деле построения OLAP и DataWareHouse используется лишь часть могучих статистических механизмов SAS, ведь система эта создавалась в свое время как статистический пакет.
Можно сделать и выводы насчет преимуществ подходов к построению хранилищ. Определенная строгость и негибкость касаемо изменения данных в хранилище полностью окупает себя скоростью его формирования и скоростью доступа к отчетам. Как ни странно, мне до сих пор больше импонирует Нострадамус, но лишь потому, что тогда я сам разрабатывал инструментарий для создания прикладных решений, а теперь создаю прикладные решения, зачастую лишь догадываясь, как поведет себя в том или ином случае импортная система. Да и создание заказной разработки на ядре “Нострика” сравнимо по времени с внедрением платформы SAS. Так что то, что в свое время финансовая аналитика в Програмбанке отошла от SAS в сторону собственной разработки, вполне имеет право на жизнь и дальнейшее развитие.
Новости