Оперативное хранилище в АБС – два в одном

Ссылки сюда (2) →

• Владимир Рахтеенко, генеральный директор ООО «Заказные ИнформСистемы».
• Андрей Таранов, аналитик ООО «Заказные ИнформСистемы».

«Оперативное хранилище в АБС – два в одном»

Летом 2003 года в Интернете проходила дискуссия экспертов-представителей банков и фирм-разработчиков банковских систем, под названием «Хранилища данных. Для чего они нужны банкам?» (интересующихся подробностями отошлем на сайт).

Мнение одного из участников (А.В. Погудина, руководителя банковского направления компании «ЦФТ») на наш взгляд очень точно описывает существующую ситуацию. Позволим себе процитировать:

«На данном этапе развития российского рынка банковских информационных технологий уместно ставить вопрос иначе «Хранилища данных. Почему их нет в банках?»…

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

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

На наш взгляд, причина сложившейся ситуации лежит в устоявшемся представлении о том, что для автоматизации оперативной и аналитической работы банку необходимы различные системы. Начиная с первых публикаций о хранилищах данных, всегда подчеркивалась разница задач, решаемых OLTP-системами и хранилищами. Эти задачи требовали различных средств и различных, специально оптимизированных для этого, структур. OLTP и хранилище рассматривались как независимо существующие компоненты. Связь между ними односторонняя — данные выгружаются из OLTP в хранилище. Как правило, автоматизация этих компонент — это два различных независимых проекта на различных программно-аппаратных платформах, причем решения выбираются от разных фирм-поставщиков. Соответственно, расходы на приобретение систем удваиваются. Усилия персонала банка на внедрение и сопряжение отдельных систем с трудом поддаются координации.

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

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

К созданию подобного оперативного хранилища (аналитической АБС) нас привел детальный анализ бизнес-задач клиента, показавший, что аналитические данные регулярно используются в процессе оперативного управления. И мы предположили, что аналитическое хранилище не обязательно должно быть физически отделено от OLTP-системы. Более того, хранилище может быть погружено в OLTP-систему и фактически составлять ее базовый компонент. Именно такой вариант реализован в нашей банковской системе GROSS (с сентября 2004 г. CustIS Bank), базирующейся на учетно-аналитическом ядре CustIS Accounting® (одна из торговых марок компании «Заказные ИнформСистемы»).

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

Правильное хранилище правильных данных

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

• Хранение больших объемов данных;
• Гибкость структуры данных хранилища;
• Высокая скорость чтения данных из хранилища;
• Распределенное согласованное хранение данных с возможностью встречных исправлений;
• Высокие требования к информационной безопасности;
• Длительный период эксплуатации;
• Интеграция со сторонними системами.

Говоря о больших объемах данных, мы имеем в виду сотни гигабайт и терабайты. Реальные хранилища с такими объемами данных успешно работают у наших клиентов.

Необходимость гибкой структуры данных хранилища обусловлена тем, что динамика бизнеса приводит к постоянному потоку новых требований к информационным системам. По оценкам, приводимым в обзорах журнала Journal of Defense Software Engineering, в больших проектах автоматизации на этапах проектирования и программирования объем дополнительных требований заказчика растет на 2-10% в месяц. Для отечественных предприятий эта величина еще больше, поскольку динамика организационных и функциональных изменений в несколько раз выше. Очевидно, что появление новых финансовых продуктов и услуг в операционной АБС, новая оргструктура банка, изменения в составе ЦФО (центров финансовой ответственности) должны оперативно отражаться в виде новых аналитических показателей в хранилище.

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

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

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

Длительный период эксплуатации хранилища в банке (имеется в виду срок не менее 10 лет) обязательно требует, чтобы решение было программно и аппаратно масштабируемым.

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

Препятствия на пути к правильному хранилищу

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

Однако даже использование самых мощных СУБД оставляет открытыми вопросы о реализации разных, зачастую противоположных с технической точки зрения требований. Эти вопросы автоматизаторам приходится решать снова и снова при построении реальных программно-технологических комплексов. Приведем примеры взаимно противоречивых требований к хранилищу:

1. Статичность структуры СУБД — динамичность структур данных в хранилище. Изменение логической структуры базы данных хранилища в процессе его эксплуатации находится в противоречии со статичной структурой реляционной базы данных.
2. Целостная обработка данных на сервере СУБД — изменение алгоритмов обработки информации с течением времени. Изменения, вносимые при доработке и адаптации системы, могут нарушать корректную работу системы и целостность данных в хранилище. Избежать этого помогает правило исторической преемственности всех изменений: для «старых» данных должны работать соответствующие им по времени алгоритмы.
3. Жесткая информационная безопасность — динамичность структур данных в хранилище. Необходимо сохранять управление доступом к данным в расширяющейся структуре хранилища.
4. Распределенное хранение данных — возможность встречных изменений на нескольких серверах.

Многие из приведенных примеров, по меткому выражению авторитетного специалиста в области баз данных М.Р. Когаловского, представляют собой «проблему на все времена». Мы, со своей стороны, приняли этот вызов и, как нам представляется, достигли убедительных результатов, создав «оперативное хранилище» в рамках автоматизированной системы GROSS.

От OLTP к оперативному хранилищу — в рамках одной АБС

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

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

• структуры и характеристики информации, хранящейся в системе
• права доступа к информации
• алгоритмы обработки информации.

Базовый принцип, который обеспечивает параллельное решение операционных и аналитических задач в GROSS — это последовательное преобразование разнородной информации, характерной для первичных документов, в однородную — для учета и анализа (см. Рисунок).

Рисунок. Последовательное преобразование информации в АБС GROSS

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

То, что метаданные являются функцией от времени, означает, что они начинают работать ровно с того момента, который в них указан. Выполнение этого требования — тяжелое проектное решение для хранилища, построенного на реляционных СУБД, поскольку заметно снижает производительность и усложняет правила работы с ним. Но для нас хранилище — это, прежде всего, учетная система. Поэтому, отступая назад по времени, мы должны переходить на те правила учета, которые существовали на тот момент, иначе учетная система разрушается. А это и означает, что метаданные, описывающие учетные правила, тоже должны быть маркированы временем жизни. Только тогда можно будет поддерживать все «накаты» и «откаты» операционных дней, не разрушая учетную систему и согласованность информации в хранилище.

Последовательное преобразование информации в АБС GROSS

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

В GROSS поддерживается несколько уровней иерархии объектов. Верхний уровень — договоры, сделки. Промежуточные уровни — операции, события в жизненном цикле документов и сделок, распоряжения, платежные документы, мемориальные ордера. Нижний уровень — счета и проводки. Богатая аналитика изначально заложена в объектах всех уровней — от договоров до лицевых и синтетических счетов. Приведем типовой перечень базовых аналитических атрибутов-размерностей:

• филиал;
• валюта счета;
• вид финансового/материального актива;
• банковский продукт;
• центр ответственности;
• клиент/контрагент;
• посредник (дилер, брокер и т.д.);
• признак привлечения/размещения средств;
• ссылка на договор/сделку;
• остаток в валюте счета;
• остаток и обороты в валюте плана счетов;
• курс переоценки.

Специалисты банка могут сами пополнять список аналитических атрибутов.

Параллельное ведение множества видов учета и планов счетов в системе основано на представлении учета как совокупности проводок, генерируемых на разных этапах жизненного цикла документов. Для любого звена технологической цепочки обработки документа можно настроить дополнительный шаблон проводок для нового плана счетов. План счетов (ПС) трактуется как свободно настраиваемая иерархия синтетических счетов, на нижнем уровне этой иерархии — аналитические счета с произвольными наборами атрибутов. В настоящее время в системе реализованы планы счетов: регламентированный ПС Банка России, ПС налогового учета, разнообразные ПС управленческого учета. Готовится план счетов для поддержки МСФО.

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

Особенность всех видов учета — хранение сальдо и оборотов на определенные даты, проведение проводок на любую дату в будущее и в прошлое, «откат» и «накат» дней с перерасчетом проводок. Тем самым поддерживается постоянная актуальность хранилища: архивные данные не замораживаются, сохраняется возможность отслеживать все изменения, происходящие в операционной АБС.

Как снимаются противоречия в оперативном хранилище GROSS

Возвращаясь к взаимно противоречивым требованиям, возникающим при построении хранилища, остановимся кратко на тех системных решениях, благодаря которым они были разрешены в АБС GROSS

1. Для поддержки динамической структуры базы данных (БД) хранилища и преодоления проблем, связанных с ее периодическим расширением в процессе эксплуатации АБС было выбрано атрибутное представление сущностей (объектов) в БД и описание структуры сущностей с помощью метаданных. Атрибутное представление — это способ хранения сущностей в таблицах реляционной БД, позволяющий расширять логическую структуру сущностей (данных) без изменения физической структуры таблиц БД.
2. Сохранение целостности данных при доработке и адаптации системы (а она может самостоятельно выполняться персоналом банка-заказчика) обеспечивается описанием алгоритмов с помощью набора высокоуровневых правил, гарантирующих логическую целостность информации. Принцип историчности последовательно выполняется как для данных, так и для метаданных, обеспечивая согласованные изменения информации в хранилище.
3. Для контроля и управления доступом к данным в постепенно расширяющейся динамичной структуре хранилища, описание правил доступа было реализовано с помощью механизма ролей. Набор правил описывается метаданными и может пополняться.
4. Атрибутное хранение представляет собой своего рода компактную свертку информации о структурах данных. Сложная система связей и ссылок обеспечивает динамичность логической схемы БД без изменения физической, но она же замедляет выборку данных. Высокая степень производительности, достижению которой нами было приложено немало усилий, достигается благодаря оптимальному использованию СУБД Oracle, компактной схеме БД, разгрузке трафика между сервером и клиентским приложению и обеспечением конкурентной работы пользователей без блокировок общих ресурсов. Все запросы к БД, которые требуют оперативного отклика или являются часто используемыми, — оптимизируются.
5. Поддержку согласованного распределенного хранения данных и в АБС и в хранилище обеспечивают специально разработанные механизмы синхронизации метаданных, позволяющие выполнять одновременные (параллельные) изменения в структуре данных и в самих данных на нескольких серверах.

Очевидное преимущество подобного гибрида «OLTP–хранилище» — это постоянная актуальность данных и оперативность получения аналитических отчетов персоналом банка. Некоторой потерей скорости (по сравнению с традиционными хранилищами) наши пользователи расплачиваются за то, что внедряют у себя одну систему вместо двух, за то, что им не приходится заниматься перегрузкой данных из OLTP в хранилище, за возможность оперативно ставить и решать аналитические задачи, вести управленческий учет и в режиме on-line корректировать действия операционных работников. На наш взгляд, практические (экономические в том числе) преимущества такого решения с лихвой компенсируют те качества, в которых оно проигрывает теоретически выдержанным решениям.

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

Ссылки

---

Репликация: База Знаний «Заказных Информ Систем» → «Оперативное хранилище в АБС – два в одном»

Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».