Сегодня ключевой тенденцией построения IT-инфраструктуры в украинских банках является создание единого центра хранения данных, извлеченных из систем оперативной обработки различных подразделений банка, с целью использования их в качестве основы принятия решений.
Необходимость оперативно получать достоверную информацию по текущей деятельности банка управленцам высшего и среднего звена в последние годы привела к значительной активизации процессов создания хранилищ данных. Хранилище теперь воспринимается руководителями банков не просто как имиджевая составляющая, а как обязательный вид обеспечения современного финансового менеджмента. Динамично меняющиеся условия внешней среды, жесткая конкуренция определяют все новые требования со стороны управленцев к информационному обеспечению принятия решений, способствуя постоянному развитию таких систем.
Причины и предпосылки
Результат от принятия эффективных решений во всех сферах управления трудно переоценить. Управленческие решения в бизнесе практически всегда принимает человек, поэтому качество принятия решения зависит от знаний, опыта, интуиции и информированности управленца. Современные информационные системы не могут ни помочь, ни помешать в принятии решения, они обеспечивают только один аспект поддержки принятия конкретного решения — информацию. Цель таких систем — обеспечить менеджера нужной достоверной полной информацией в нужный момент времени.
В зависимости от задачи, для принятия решения менеджеру могут понадобиться данные некоторого набора показателей как внутреннего характера (заявки, остатки по счетам и т.п.), так и внешних (рыночные процентные ставки, индексы, данные по конкурентам, финансовые отчеты потенциальных заемщиков и т.п.). Получение таких данных может быть сопряжено с проблемами.
Внешние данные, как правило, вообще отсутствуют в базах данных основной системы, предназначенной для автоматизации выполнения и учета конкретных операций банка (их принято классифицировать как OLTP-системы, англ. On-Line Transaction Processing). Но даже внутренние данные, в принципе имеющиеся в OLTP, — могут быть недоступны менеджеру ввиду того, что они рассредоточены по разным программным модулям и системам, функционирующим в организации. Например, зарплата, учет договоров хозяйственной деятельности банка, учет дилинговых сделок, операций с векселями, с ценными бумагами — в большинстве банков ведутся в отдельных локальных системах, зачастую от разных поставщиков. Идеи создания абсолютно полнофункциональной системы автоматизации, которая охватывала бы все виды деятельности банка, в том числе и на перспективу — вполне утопичны, как показывает практика. А информационные запросы менеджеров зачастую имеют интегральный характер. Например, необходимо получить ответ на вопрос: какая сумма совокупных активов уже размещена банком в финансово-промышленной группе А (с учетом всех аффилированных структур и лиц), допустимо ли размещать их еще и если да — то в какой сумме.
Кроме того, данные в OLTP-системах организованы с целью оптимизации поддержки конкретной совокупности технологических операций. Наиболее критичным требованием для продуктов такого класса является производительность выполнения процессов актуализации данных, инициируемых множеством пользователей в ходе выполнения конкретных бизнес-операций (учет нового клиента, открытие счета, учет факта оплаты . по кредитному договору и т.п.)
В базах данных OLTP-систем может накапливаться со временем большой объем исторической информации, которая практически не используется в процессах оперативной обработки данных и только усложняет и удорожает администрирование системы данных, снижая при этом производительность работы конечного операционного работника, скорость обработки транзакций и удорожая сопровождение и использование той системы. Но удалить эти данные из обрабатывающей системы по различным причинам нельзя, поскольку они используются для формирования отчетов различного рода, и не только аналитического характера. Так, в банке длительный срок должны храниться платежные документы и проводки по ним, поскольку может понадобиться сформировать выписку по счету клиента за длительный период (например по запросу суда). Если предварительно заархивированные данные из системы все же удаляются, процесс их извлечения из архива в случае необходимости трудоемкий.
Первыми с этими проблемами столкнулись крупные западные корпорации, в системах обработки данных, в которых к началу 1990-х годов накопились огромные объемы информации, а качество решения аналитических задач при этом не только не улучшилось, а даже ухудшилось.
Возникла парадоксальная ситуация — в системах обработки данных хранились огромные объемы информации, значительная часть которой практически не использовалась в рамках процессов обработки. Печатались (зачастую в круглосуточном режиме) кипы отчетов, а менеджеры, особенно управленцы верхнего звена, которым требовались данные для принятия решений, не могли их получить вовремя и с нужной степенью достоверности.
Понятие хранилища данных (Data Warehouse)
Билл Инмон (W. Inmon), занимавшийся проблемами организации корпоративных баз данных, в начале 1990-х годов ввел понятие «хранилища данных». Он определил его как «предметно-ориентированный, интегрированный, неизменчивый, поддерживающий хронологию выделенный набор данных, организованный для целей поддержки управления», призванный выступать в роли «единого и единственного источника истины», обеспечивающего менеджеров и аналитиков достоверной информацией, необходимой для анализа и принятия решений.
В основе концепции хранилищ лежит разделение наборов данных, используемых в системах оперативной обработки данных OLTP, и наборов данных, применяемых в системах поддержки принятия решений (СППР, англ. DSS — Decision Support System). То есть хранилища действительно реализуются как единый реальный интегрированный источник данных, а не как виртуальный источник, опирающийся на распределенные базы данных различных OLTP-систем.
Такое разделение данных позволяет«улучшить характеристики производительности и стоимости OLTP-систем, убрав из них функцию хранения исторических данных большой глубины, и получить хранилище исторических данных, интегрированных из разных источников — как внешних, так и внутренних, хранящихся оптимальным способом с позиций их использования в задачах аналитической обработки.
Концепция хранилища данных ориентирована на способ хранения»и подготовки данных для анализа, а не на способ их использования. Необходимо подчеркнуть, что концепция не дает рецептов реализации информационно-аналитической системы и не является универсальным решением для таких систем. Она определяет только раздельное хранение данных операционных и аналитических приложений и соответственно разные подходы к ним: разную их организацию, разные способы актуализации этих данных. Естественно, способ дальнейшего использования данных учитывается при проектировании и разработке конкретного хранилища (как и любой информационной системы), но само по себе понятие хранилища данных не предопределяет способов анализа.
Остановимся на наиболее существенных принципах организации центров управления и анализа данных.
- Перед помещением в хранилище все данные проверяются на непротиворечивость, приводятся к единой системе понятий и единому формату. Это позволяет данным, помещенным в хранилище, претендовать на новое качество «единого и единственного источника истины». Для решения ряда задач может понадобиться, кроме интегрированного отображения некоторого объекта хранения, и сохранения значений некоторых атрибутов экземпляра этого объекта в различных источниках со ссылкой на источник. Такой подход не противоречит данному принципу.
- Данные из хранилища никогда не удаляются, происшедшие изменения добавляются в хранилище с указанием времени изменения, таким образом, в хранилище данных хранятся моментальные снимки данных на определенный момент времени. Строгое соблюдение этого принципа для некоторого слоя оперативных детальных данных может оказаться проблематичным, особенно при высоких требованиях относительно периодичности обновления данных. Очевидно, необходимо руководствоваться прежде всего целесообразностью.
- Пополнение хранилища выполняется с установленной периодичностью. Поскольку, исходя из природы хранилища, оно представляет собой распределенное решение (это отдельная совокупность данных), необходимо решать задачу асинхронной ассиметричной синхронизации данных из различных OLTP-систем и внешних источников с базой данных хранилища. Для некоторых задач оперативного характера может требоваться очень свежая информация, что может вызвать существенные сложности при реализации.
- Структура хранилища должна обеспечивать быстрое и эффективное чтение данных. С целью ускорения этих процессов данные заранее агрегируются в наиболее часто используемых разрезах. Определение, какие из разрезов агрегирования должны храниться, а какие рассчитываться «на лету» — еще одна непростая проблема при построении хранилища данных.
- В хранилище должны помещаться данные, существенные с позиций анализа. Не все данные из всех систем оперативной обработки данных пригодны для анализа и впоследствии будут востребованы. Необходим взвешенный подход к определению состава хранимых данных. Этот принцип определен «предметной ориентированностью» хранилища, хотя, поскольку понятие хранилища определяет лишь концепцию хранения данных, практически не затрагивая способ их использования, здесь встречаются разные варианты решений, в зависимости от преследуемых владельцем хранилища целей.
Для построения хранилища данных необходимо решить следующие классы задач:
- определить круг пользователей хранилища данных и решаемых ими задач;
- определить перечень хранимых данных и их структуры, в том числе и структуры хранимых агрегированных данных;
- определить источники получения данных и разработать процедуры извлечения данных из этих источников;
- разработать процедуры очистки (проверки целостности и непротиворечивости данных из каждого источника и разных источников) и загрузки данных в хранили ще, в том числе и процедуры создания хранимых агрегатов.
Все данные, которые содержатся в хранилище, можно разделить на следующие категории:
- метаданные (данные о данных);
- агрегированные данные;
- детальные данные
Важной особенностью промышленных систем на основе хранилищ данных являются метаданные. Это разного рода системные словари, позволяющие контролировать состав и структуру информации в хранилище, управлять процессами загрузки и расчетов и т.п. Без слоя управленческих данных хранилище со временем грозит превратиться в большую электронную свалку.
Ключевым отличием информации хранилища является не только способ его наполнения (из различных внешних и внутренних источников, включая OLTP-системы), но и модель хранения данных, в особенности это касается агрегированной информации. В хранилище информация размещается в денормализованном виде в форме классической «снежинки» или «звезды». Такой подход позволяет существенно снизить время отклика базы данных при выполнении запросов. Не вдаваясь в технологические особенности проектирования, отметим, что происходит это за счет некоторой избыточности хранения данных. Такая форма хранения информации в корпоративных хранилищах является общемировой практикой. Вместе с тем часть детальных данных вполне может храниться в нормализованных таблицах. Требование к специальным структурам хранения обусловлено некоторым специальным способом использования данных, о чем целесообразно сказать подробнее.
Использовать информацию, накопленную в хранилище, можно как с помощью традиционных отчетов, так и с использованием динамических запросов к базе данных. Существуют также совершенно специфические способы использования информации, предназначенные специально для аналитических задач. К ним относятся так называемые OLAP-технологии (On-Line Analytical Processing) и технологии интеллектуального анализа данных (ИАД). В английском языке существует два термина, переводимые как ИАД, — Knowledge Discovery in Databases (KDD) и Data Mining (DM), часто употребляемые как синонимы.
В 1993 году вышла в свет статья крупнейшего специалиста в области баз данных, автора реляционной модели, теории нормализации баз данных д-ра Е. Кодда, в которых анализировался продукт EssBase малоизвестной тогда фирмы Arbor Software. В этой статье были сформулированы известные 12 правил Кодда, ставшие первым определением того, что следует понимать под распространенным сегодня определением OLAP.
С практической точки зрения решительный шаг, который делает OLAP-технология, состоит в том, чтобы, отказавшись от излишней общности, сделать процесс анализа максимально быстрым. В рамках этой технологии предполагается, что состав и структура показателей для анализа известен заранее и меняется очень редко (для некоторых видов систем — практически не меняется). Пользователь может выполнять над данными в таком многомерном представлении набор OLAP-операций подъема (консолидации по некоторым направлениям), спуска (детализации по некоторому направлению), поворота (изменения направления сортировки).
Детальные данные в системах хранилищ данных чаще всего являются источником для интеллектуального анализа. Главными задачами ИАД являются поиск функциональных и логических закономерностей в накопленной информации, построение моделей и правил, которые объясняют найденные аномалии и (или) прогнозируют с некоторой вероятностью развитиевнекоторых процессов. Классификация задач ИАД по типам производимой информации чаще всего выглядит таким образом:
- классификация. Позволяет выявить признаки, характеризующие однотипные группы объектов — классы, с целью отнесения нового объекта к определенному классу по имеющимся значениям его характеристик;
- кластеризация — определение группировок, присущих исследуемым данным;
- выявление ассоциаций — определение связей между некоторыми свойствами или объектами;
- выявление последовательностей — выявление связанности между событиями, разнесенными во времени;
- прогнозирование — на основе исторических и текущих данных оценка будущих значений показателей.
ИАД в настоящий момент чрезвычайно актуален. В результате решения этих задач пользователь получает новые данные и даже новые знания. Наиболее востребованы в банковской сфере задачи данного класса в области анализа рисков, прогнозирования, в маркетинговых исследованиях и т.п.
Аспекты внедрения
Централизованное хранилище данных банка является звеном, объединяющим разнородные системы обработки данных в единую распределенную информационную систему.
Ключевым требованием для эффективного внедрения хранилища данных представляется наличие в банке учетных и управленческих стандартов и строгая дисциплина их соблюдения. Это не является специфическим требованием только систем с хранилищами данных, это требование является основным при создании корпоративных информационных систем вообще. Должны существовать, поддерживаться в актуальном состоянии и строго соблюдаться стандарты учета всех основных операций, определены единые бухгалтерские и информационные модели их учета. Иначе в некоторых случаях окажутся невыполнимыми задачи интеграции данных из разных источников. А в некоторых случаях сами данные, накопленные в хранилище, окажутся непригодными для каких-то аспектов анализа из-за отсутствия единой методологии их порождения. Исторический срез каких-либо данных имеет смысл анализировать, если эти данные отражают некоторые семантически и методологически однородные понятия.
Важным для успеха систем на основе хранилищ является наличие единого «хозяина» системы — администратора данных (не путать с привычной ролью администратора БД). В зависимости от масштаба системы и круга решаемых задач функция администратора данных может быть возложена даже на группу специалистов. Администратор данных должен знать состав и структуру хранилища, семантику данных, которые в нем хранятся, источники, из которых выгружаются данные, ограничения и допущения по данным, правила разрешения проблем и противоречий, правила преобразования данных, направления их использования и т. п. Администратор данных руководит развитием и доработками хранилища.
Понимание менеджерами высшего звена роли таких систем, их заинтересованность в создании информационной базы для принятия решений — ключевой фактор успеха IТ-проектов, связанных с хранилищами данных.
Поскольку информация хранилища используется в качестве источника для поддержки принятия управленческих решений, в том числе высшим руководством банка, качество информационного обеспечения влияет на эффективность банковского менеджмента и бизнес банка в целом.