|
Персональные инструменты |
![]() |
||
|
![]() |
![]() Оперативное хранилище в АБС – два в одномМатериал из CustisWikiВерсия от 19:27, 19 сентября 2008; StasFomin (обсуждение | вклад) («Articles-rahtej-taranov-bt7-8-2003.htm» переименована в «Оперативное хранилище в АБС – два в одном»)
«Оперативное хранилище в АБС – два в одном»[1] Летом 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. Однако даже использование самых мощных СУБД оставляет открытыми вопросы о реализации разных, зачастую противоположных с технической точки зрения требований. Эти вопросы автоматизаторам приходится решать снова и снова при построении реальных программно-технологических комплексов. Приведем примеры взаимно противоречивых требований к хранилищу:
Многие из приведенных примеров, по меткому выражению авторитетного специалиста в области баз данных М.Р. Когаловского (Когаловский М.Р. Энциклопедия технологий баз данных. М., 2002. С. 22–23.), представляют собой «проблему на все времена». Мы, со своей стороны, приняли этот вызов и, как нам представляется, достигли убедительных результатов, создав «оперативное хранилище» в рамках автоматизированной системы GROSS. От OLTP к оперативному хранилищу — в рамках одной АБССоздавая свою банковскую систему, мы старались удовлетворить всем требованиям, предъявляемым к хранилищам, и одновременно разрешить сопутствующие противоречия. Иногда это достигалось путем определенных компромиссов. Основной упор был сделан на обеспечении динамичности структур данных и алгоритмов их обработки, на строгой системе безопасности в сочетании с высокой скоростью выборки данных. При проектировании и разработке системы был применен объектно-ориентированный подход и последовательно выдерживался принцип декларативного представления данных и бизнес-правил их преобразования. Поэтому метаданными описываются следующие аспекты системы:
Базовый принцип, который обеспечивает параллельное решение операционных и аналитических задач в GROSS — это последовательное преобразование разнородной информации, характерной для первичных документов, в однородную — для учета и анализа (см. Рисунок). Преобразование оперативной информации в аналитическую обеспечивает механизм ведения различных видов учета и множества планов счетов. Для описания данных и методов их преобразования служат метаданные — декларативное представление всех компонентов системы (документов, бизнес-правил, справочников, иерархий, отчетов). Принцип историчности выполняется не только для данных, но и для метаданных — это обеспечивает согласованные изменения в прошлых операционных днях и, соответственно, в хранилище. То, что метаданные являются функцией от времени, означает, что они начинают работать ровно с того момента, который в них указан. Выполнение этого требования — тяжелое проектное решение для хранилища, построенного на реляционных СУБД, поскольку заметно снижает производительность и усложняет правила работы с ним. Но для нас хранилище — это, прежде всего, учетная система. Поэтому, отступая назад по времени, мы должны переходить на те правила учета, которые существовали на тот момент, иначе учетная система разрушается. А это и означает, что метаданные, описывающие учетные правила, тоже должны быть маркированы временем жизни. Только тогда можно будет поддерживать все «накаты» и «откаты» операционных дней, не разрушая учетную систему и согласованность информации в хранилище. Последовательное преобразование информации в АБС GROSSОстановимся кратко на том, как происходит преобразование оперативной информации в аналитическую, какие базовые системные механизмы его реализуют. В GROSS поддерживается несколько уровней иерархии объектов. Верхний уровень — договоры, сделки. Промежуточные уровни — операции, события в жизненном цикле документов и сделок, распоряжения, платежные документы, мемориальные ордера. Нижний уровень — счета и проводки. Богатая аналитика изначально заложена в объектах всех уровней — от договоров до лицевых и синтетических счетов. Приведем типовой перечень базовых аналитических атрибутов-размерностей:
Специалисты банка могут сами пополнять список аналитических атрибутов. Параллельное ведение множества видов учета и планов счетов в системе основано на представлении учета как совокупности проводок, генерируемых на разных этапах жизненного цикла документов. Для любого звена технологической цепочки обработки документа можно настроить дополнительный шаблон проводок для нового плана счетов. План счетов (ПС) трактуется как свободно настраиваемая иерархия синтетических счетов, на нижнем уровне этой иерархии — аналитические счета с произвольными наборами атрибутов. В настоящее время в системе реализованы планы счетов: регламентированный ПС Банка России, ПС налогового учета, разнообразные ПС управленческого учета. Готовится план счетов для поддержки МСФО. В процессе жизненного цикла документы переходят из состояния в состояние. Переход в новое состояние сопровождается выполнением набора операций, которые находят отражение в финансовом и управленческом учете — по шаблонам генерируются проводки (отдельный шаблон для каждого вида учета и плана счетов). Один и тот же банковский документ отражается в любом количестве планов счетов проводками. Особенность всех видов учета — хранение сальдо и оборотов на определенные даты, проведение проводок на любую дату в будущее и в прошлое, «откат» и «накат» дней с перерасчетом проводок. Тем самым поддерживается постоянная актуальность хранилища: архивные данные не замораживаются, сохраняется возможность отслеживать все изменения, происходящие в операционной АБС. Как снимаются противоречия в оперативном хранилище GROSSВозвращаясь к взаимно противоречивым требованиям, возникающим при построении хранилища, остановимся кратко на тех системных решениях, благодаря которым они были разрешены в АБС GROSS
Очевидное преимущество подобного гибрида «OLTP–хранилище» — это постоянная актуальность данных и оперативность получения аналитических отчетов персоналом банка. Некоторой потерей скорости (по сравнению с традиционными хранилищами) наши пользователи расплачиваются за то, что внедряют у себя одну систему вместо двух, за то, что им не приходится заниматься перегрузкой данных из OLTP в хранилище, за возможность оперативно ставить и решать аналитические задачи, вести управленческий учет и в режиме on-line корректировать действия операционных работников. На наш взгляд, практические (экономические в том числе) преимущества такого решения с лихвой компенсируют те качества, в которых оно проигрывает теоретически выдержанным решениям. В правомерности нашего подхода мы убедились на ряде успешных проектов, реализовав на основе универсального учетно-аналитического ядра масштабные информационные системы для наших клиентов, работающих как в банковской сфере, так и в других секторах бизнеса. Ссылки
Любые правки этой статьи будут перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion». Репликация: База Знаний «Заказных Информ Систем» → «Оперативное хранилище в АБС – два в одном» |
![]() |
![]() |
![]() |