Построение информационно-аналитической системы:
концепция и подходы R-Style Software Lab.

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

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

Неизменчивый, поддерживающий хронологию. В хранилище можно добавить информацию, но ее нельзя удалить или скорректировать. Если в каких-то данных, которые уже были введены в систему, произошли изменения, то мы вносим записи о произошедших коррективах, но старую информацию не уничтожаем. Проиллюстрируем сказанное. Предположим, кредиту стала соответствовать иная группа риска. Или, скажем, изменились реквизиты клиента (подобных примеров можно привести сколь угодно даже из разряда «штатных ситуаций».) Так вот, если в подобных случаях нарушать условие и корректировать прежние данные, то нам уже никогда не будет доступен «взгляд из прошлого», мы никогда не сможем выпустить отчет по состоянию на архивную дату. Потому что полной информации, соответствующей именно тому моменту времени, больше нет — теперь она другая. Подход же, который предполагает добавление в хранилище записей, отражающих новую ситуацию, устраняет означенный недостаток: все данные сохранены, и мы можем проследить историю любого изменения.

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

Укрощение Хроноса

Действительно, при поверхностном рассмотрении создается впечатление, что мы сами загнали себя в угол. С одной стороны, говорим, что в целях эффективного использования СУБД следует работать, не изменяя архивных данных, а с другой стороны, реальная банковская практика показывает, что так не получается. Мы — я имею в виду разработчиков R-Style Software Lab. — отдаем себе отчет в том, что такая проблема есть. Вот один из вариантов ее решения.

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

Организация структур данных — опять канон…

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

Перейдем теперь на более низкий, технический уровень. Структуры базы данных нашего хранилища тоже спроектированы классически — с учетом ROLAP-технологий — по схемам «звезда», «снежинка» или «созвездие». За счет этого для OLAP-анализа (OLAP — On-Line Analytical Processing — оперативная аналитическая обработка данных) можно использовать не только средства, разработанные компанией — производителем системы, но и сторонними компаниями. Сегодня на рынке есть достаточно широкий выбор OLAP-средств — от Oracle, Microsoft, многих других фирм. И наиболее эффективно они функционируют именно при условии, что хранилище организовано в соответствии с, так сказать, классическим каноном. Если в его основе иные принципы, то эти средства тоже будут работать, но пользователю уже будет значительно труднее, потому что так или иначе придется приводить свои данные посредством неких процедур к классическим структурам, за счет чего неизбежно будет теряться эффективность.

Между тем известен и прямо противоположный подход. Он состоит в полном отказе от OLAP-средств сторонних фирм. В этом случае пользователю доступны только те средства OLAP-анализа, которые ему предоставляет разработчик аналитической системы. Некоторые компании пошли таким путем и ведут собственные OLAP-разработки. R-Style Software Lab. позиционирует себя как поставщика не системных, а прикладных финансовых решений для конечного пользователя, и поэтому своей основной задачей мы видим построение такой прикладной системы, в которой специализированные средства сторонних фирм будут работать с нашим хранилищем максимально эффективно.

Желанные метаданные

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

Вопросы достоверности информации

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

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

Забытый аспект информационной безопасности

Всем известно, какое значение сейчас придается вопросам информационной безопасности банка. Сегодня на рынке можно встретить развитые средства управления доступом к информации, контроля за ее изменением и прочая, и прочая. Эти средства встраиваются в программное обеспечение как OLTP-, так и OLАР-назначения. Мы считаем, что не меньше внимания необходимо уделить этапу передачи данных между OLTP- и OLАР-системами, ведь во время пересылки и на обоих концах этого канала информация не должна быть открыта. Иначе останется лишь полностью довериться сотрудникам, которые осуществляют выгрузку данных из OLTP-систем и загрузку этой информации в хранилище. Хорошо, если никто ничего не посмотрит, не изменит! А если вдруг?

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

Средства анализа

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

Главная цель системы RS-DataHouse — гибкий, всесторонний анализ собранных данных. В этой связи продукт включает набор средств как интеллектуального, так и статического анализа, в том числе:

• готовые методики финансового анализа (как традиционные финансовые методики, так и авторские, разработанные аналитиками R-Style Software Lab.);
• средства адаптации готовых методик под требования конкретного банка;
• средства OLAP-анализа от известных фирм-разработчиков.

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

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

В заключение несколько слов об OLAP-средствах. В своей системе для выполнения OLAP-операций мы применяем Oracle Discoverer Release 3.1, который позволяет настроить «кубы анализа» и реализовать OLAP-технологию. Кроме того, в нем есть графика и генератор несложных по форме отчетов. В итоге выстраивается следующая цепочка: СУБД создано компанией Oracle — инструмент для реализации предметно-ориентированного хранилища разработан R-Style Software Lab. OLAP-средства предоставляет Oracle, финансовые методики создает либо банк, либо ведущие консалтинговые фирмы, а выполнение этих методик обеспечивает R-Style Software Lab. При таком подходе каждая компания занимается своим делом: Oracle разрабатывает системные средства, мы, используя наработки различных финансовых структур, наполняем эти средства предметным смыслом. Это тот курс, которого мы придерживаемся и который считаем верным.