Научная статья на тему '«Хранилище данных» как основа построения информационной системы управления рисками предприятия'

«Хранилище данных» как основа построения информационной системы управления рисками предприятия Текст научной статьи по специальности «Компьютерные и информационные науки»

CC BY
632
169
i Надоели баннеры? Вы всегда можете отключить рекламу.
i Надоели баннеры? Вы всегда можете отключить рекламу.
iНе можете найти то, что вам нужно? Попробуйте сервис подбора литературы.
i Надоели баннеры? Вы всегда можете отключить рекламу.

Текст научной работы на тему ««Хранилище данных» как основа построения информационной системы управления рисками предприятия»

«ХРАНИЛИЩЕ ДАННЫХ» КАК ОСНОВА ПОСТРОЕНИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ УПРАВЛЕНИЯ РИСКАМИ

ПРЕДПРИЯТИЯ А.В. Мандрыкин, канд. техн. наук, доцент

Воронежский государственный технический университет

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

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

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

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

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

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

• Предметно-ориентированны. ХД должно разрабатываться с учетом специфики предметной области, а не прикладных областей деятельности. В отличие от БД в традиционных OLTP-системах, где данные подобраны в соответствии с конкретными приложениями, информация в ХД предназначена для решения задачи поддержки принятия решений. Для СППР требуются «исторические» данные - факты за определенные интервалы времени. Хорошо спроектированные структуры данных ХД отражают развитие всех направлений бизнес-процесса компании во времени.

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

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

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

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

Ральф Кимбалл (Ralph Kimball), один из соавторов концепции Хранилищ данных, описывал хранилище данных как «место, где люди могут получить доступ к своим данным». Он же сформулировал и основные требования к хранилищам данных:

• поддержка высокой скорости получения данных из хранилища;

• поддержка внутренней непротиворечивости данных;

• возможность получения и сравнения так называемых срезов данных (slice and dice);

• наличие удобных утилит просмотра данных в хранилище;

• полнота и достоверность хранимых данных;

• поддержка качественного процесса пополнения данных.

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

Компоненты, входящие в типичное ХД, представлены на рис. 1.

Рис.1. Типичная структура Хранилища данных

Оперативные данные собираются из различных источников, очищаются, интегрируются и складываются в реляционное ХД. При этом они уже доступны для анализа при помощи различных средств построения отчетов. Затем данные (полностью или частично) подготавливаются для OLAP-анализа. Они могут быть загружены в специальную БД OLAP или остав-

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

Рассмотрим основные этапы построения Хранилища данных.

Рис. 2. Этапы создания Хранилища данных

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

по отделам (подразделениям) для создания витрин данных. Уже на этом этапе нужно выявить и избавиться по возможности от дублирования отчетности.

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

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

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

Другой путь - это начать с описания всей системы, всех имеющихся данных, отработать взаимосвязь этих данных и затем приступать к созданию единого хранилища. Этот процесс более сложный, но представляет из себя объективный взгляд на систему в целом. Здесь, как и во многих случаях, хорош принцип «золотой середины». Например, начать с проектирования хранилища и витрины данных для пилотного проекта, но не в каком-то автономном виде, а в связи с данными других отделов и с заранее приведенной в порядок единой Нормативно-справочной системы (НСИ) компании. Любое изменение в пилотном проекте, а также изменения в других объектах системы следует отслеживать в разрезе взаимодействия друг с другом и влияния на систему в целом, причем выделить это в отдельный процесс, с детальным протоколированием. Таким образом, на базе одного из отделов можно будет выработать некое стандартное решение и использовать это решение в дальнейшем для построения общего хранилища и витрин данных для других подразделений.

Отдельно хотелось бы отметить процесс проектирования процедур извлечения, загрузки и преобразования данных (ETL - extract, transform and load). На этом этапе решаются проблемы совместимости данных из разных источников, то, каким образом будут осуществлены данные процедуры, с помощью каких средств. Наряду с анализом и стандартизацией информации это один из самых трудоемких и ответственных этапов, а также один из наиболее затратных по времени.

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

Из наиболее часто возникающих вопросов можно выделить задачу определения периодичности сбо-

ра, загрузки и обработки информации из различных источников первичной информации - транзакционных баз данных, то есть как часто необходимо обновлять данные в хранилище. От этого зависит, как и когда запускать соответствующие процедуры, какие требования предъявлять к каналам передачи данных в сети, как распределять нагрузку. Что касается процедур БТЬ, то существует целый ряд мощных инструментов от различных поставщиков, также активно используются на данном этапе хранимые серверные процедуры, благодаря которым, избегая больших издержек, можно регулировать параметры данного процесса.

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

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

Реализованное по вышеприведенным принципам Хранилище данных позволяет реализовать оптимальную информационную систему управления рисками (ИСУР) на предприятии, примерная структура которой представлена на рис. 3.

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

Сфера детализированных данных

Сфера агрегированных показателей

Сфера

закономерностей

Г енераторы запросов, информационнопоисковые системы

Системы оперативной аналитической обработки данных (OLAP)

Системы интеллектуального анализа данных (Data Mining)

Информационные системы руководителя (ИСР) 4 Ґ [■ ч Витрины данных ' Хранилище данных Щ . J

' к 1

Сбор, очистка и согласование данных из внешних источников

Транзакционные системы, источники данных

OLTP

¥

Рис. 3. Примерная структура ИСУР, построенной на основе ХД

Рассмотрим существующие на рынке решения для построения эффективного Хранилища данных.

В основном хранилища данных функционируют на базе реляционных СУБД. Согласно данным компании Gartner, среди лидеров - поставщиков СУБД сегодня ведущей компанией является Oracle. Их последний продукт - СУБД Oracle 10g - отвечает практически всем требованиям качества обслуживания и безопасности, а также обладает возможностями кластеризации. Эта СУБД дает возможности параллельной обработки данных, имеет встроенные средства OLAP, извлечения, преобразования и загрузки данных, бизнес-анализа, распространения отчетов и т.д.

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

Компания IBM известна своей СУБД DB2. Ее основные особенности - развитые средства самовосстановления и автоматического выполнения операций,

связанных с поддержкой базы данных. Эта СУБД поддерживает создание Хранилищ данных и включает средства переноса данных в Хранилище и управления Хранилищами. Также СУБД DB2 обеспечивает поддержку реляционных и комплексных данных, возможность работы на мультипроцессорных платформах, 64-разрядную архитектуру памяти, средства распределенного администрирования и обработки данных и многие другие возможности. Компания IBM предоставляет новые функциональности практически в каждом обновлении своей СУБД, что усиливает ее конкурентоспособность.

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

Существуют и другие, менее известные, решения для построения Хранилищ данных.

i Надоели баннеры? Вы всегда можете отключить рекламу.