Требования к техническому и программному обеспечению
Аналитические системы всегда предъявляли существенно более высокие, чем традиционные СОД, требования к аппаратному обеспечению и программному обеспечению. И, приступая к построению аналитической системы, следует понимать, что её реализация практически невозможна без разрешения таких вопросов как:
неоднородность программной среды
распределенность
защиты данных от несанкционированного доступа
построения и ведения многоуровневых справочников метаданных
эффективное хранение и обработка очень больших объемов данных
Основополагающим отличием ХД от традиционных СОД является то, что они практически никогда не создаются на пустом месте. И практически всегда, конечное решение будет разнородным (с точки зрения производителей программных средств, принципов построения, операционных систем) .
Основой ХД являются не внутренние, как в большинстве традиционных СОД, а внешние источники данных.
Внешние источники данных - основа ХД - хранилища данных
различного рода ИС,
электронные архивы,
общедоступные и коммерческие электронные каталоги,
справочники,
статистические сборники.
Как правило, сегодня в любой организации реально функционирует множество несвязанных или слабо связанных СОД. В большинстве случаев, они создавались в различное время, различными коллективами разработчиков и реализованы на основе различных программных и аппаратных средств. Таким образом, уже сама основа, на которой будет строиться ХД, чаще всего уже является крайне неоднородной. Добавьте сюда средства выгрузки, транспортировки, реализации целевой БД ХД.
Очевидно, что в таких условиях, даже говорить об однородности программных средств чрезвычайно сложно. Поэтому задача построения ХД - это задача построения единой согласовано функционирующей информационной системы, на основе неоднородных программных средств и решений. И уже сам выбор средств реализации ХД становится чрезвычайно сложной задачей. Здесь должно учитываться множество факторов, включая, взаимную совместимость различных программных компонент, легкость их освоения и использования, эффективность функционирования, стабильность и даже формы, уровень и потенциальную перспективность взаимоотношений различных фирм производителей
Типичная архитектура ХД
представлена на рисунке
Менеджер загрузки ( load manager ) выполняет операции, связанные с извлечением и загрузкой данных в ХД.
Менеджер хранилища ( warehouse manager ) выполняет операции, связанные с управлением информацией, помещенной в ХД:
анализ непротиворечивости данных;
создание индексов и представлений для базовых таблиц;
денормализация данных (при необходимости);
обобщение данных (при необходимости);
резервное хранение и архивирование
Менеджер запросов ( query manager ) выполняет операции, связанные с управлением пользовательскими запросами.
|
Основные компоненты ХД
К основным компонентам информационного хранилища данных (ХД) относятся:
ПО (программное обеспечение) промежуточного слоя
Обеспечивает сетевой доступ и доступ к базам данных. Сюда относятся сетевые и коммуникационные протоколы, драйверы, системы обмена сообщениями и пр.
Транзакционные БД (баз данных) и внешние источники информации
БД OLTP-систем исторически предназначались для эффективной обработки структур данных в относительно небольшом числе четко определенных транзакций. Из-за ограниченной целевой направленности "учетных" систем применяемые в них структуры данных плохо подходят для систем поддержки принятия решений. Кроме того, возраст многих установленных OLTP-систем достигает 10 - 15 лет.
Уровень доступа к данным
Относящееся сюда ПО обеспечивает общение конечных пользователей с информационным ХДм и загрузку требуемых данных из транзакционных систем. В настоящее время универсальным языком общения служит язык структурированных запросов (SQL).
Загрузка и предварительная обработка
Этот уровень включает в себя набор средств для загрузки данных из OLTP-систем и внешних источников. Выполняется, как правило, в сочетании с дополнительной обработкой: проверкой данных на чистоту, консолидацией, форматированием, фильтрацией и пр.
Информационное ХД - хранилище данных
Представляет собой ядро всей системы - один или несколько серверов БД.
Метаданные
Метаданные (репозиторий, "данные о данных"). Играют роль справочника, содержащего сведения об источниках первичных данных, алгоритмах обработки, которым исходные данные были подвергнуты, и т. д.
Уровень информационного доступа
Обеспечивает непосредственное общение пользователя с данным ХД посредством стандартных систем манипулирования, анализа и предоставления данных типа MS Excel , MS Access , Lotus и др.
Уровень управления (администрирования)
Отслеживает выполнение процедур, необходимых для обновления информационного хранилища или поддержания его состояния. Здесь программируются процедуры подкачки данных, перестройки индексов, выполнения итоговых (суммирующих) расчетов, репликации данных, построения отчетов, формирования сообщений пользователям, контроля целостности и др.
|
Проблемы интеграции данных
Любая крупная и давно существующая корпорация обладает несколькими базами данных, относящимися к разным видам деятельности. Данные могут иметь разные представления, а иногда могут быть даже несогласованными (например, из-за ошибки ввода в одну из БД). Это нехорошо даже для OLTP-систем и в принципе непригодно для OLAP-систем, которые должны обрабатывать общие исторические согласованные корпоративные данные. Более того, для оперативной аналитической обработки требуется привлечение внешних источников данных, которые тем более могут обладать разными форматами и требовать согласования.
Подход к построению ХД для интеграции неоднородных источников данных принципиально отличается от подхода динамической интеграции разнородных БД. В случае ХД данных реально строится новое крупномасштабное ХД, управление данными в котором происходит, вообще говоря, по другим правилам, нежели в исходных оперативных БД.
Основные проблемы реализации хранилищ данных
Неоднородность программной среды
ХД практически никогда не создается на пустом месте. Почти всегда конечное решение будет разнородным, т.е. в нем будут использоваться автономно разработанные программные средства. Прежде всего это касается формирования интегрированного согласованного набора данных, которые могут поступать из разнородных БД, электронных архивов, публичных и коммерческих электронных каталогов, справочников, статистических сборников. При построении ХД приходится решать задачу построения единой, согласованно функционирующей информационной системы на основе неоднородных программных средств и решений. При выборе средств реализации ХД приходится учитывать множество факторов, включающих уровень совместимости различных программных компонентов, легкость их освоения и использования, эффективность функционирования и т.д.
Распределенный характер организации
В концепции ХД предопределено то, что операционная аналитическая обработка может выполняться в любом узле сети независимо от места расположения основного хранилища. Хотя при аналитической обработке данные только читаются, и потребность в синхронизации отсутствует, для достижения эффективности необходимо поддерживать репликацию данных в разных узлах сети. (На самом деле, все не так просто. Одним из требований к хранилищам данных является то, чтобы свежая информация поступала в ХД как можно быстрее. Т.е. потенциально любая модификация оперативной БД может инициировать добавление данных к хранилищу данных, а тогда потребуется обновить и все реплики, для чего синхронизация все-таки нужна.)
Повышение требований к безопасности данных
Собранная вместе согласованная информация об истории развития корпорации, ее успехах и неудачах, о взаимоотношениях с поставщиками и заказчиками, об истории и состоянии рынка дает возможность анализа прошлой и текущей деятельности корпорации и построения прогнозов для будущего. Эта информация настолько ценна для корпорации, что нельзя допустить возможности ее утечки (на самом деле, если ХД одной корпорации попадет в руки аналитиков другой корпорации, то все аналитические прогнозы первой корпорации сразу станут неверными). В системах, основанных на хранилищах данных, оказывается недостаточной защита данных в стиле языка SQL, которую обеспечивают обычные коммерческие СУБД. Для обеспечения должного уровня защиты доступ к данным должен контролироваться не только на уровне таблиц и их столбцов, но и на уровне отдельных строк. Приходится также решать вопросы аутентификации пользователей, защиты данных при их перемещении в ХД из оперативных БД и внешних источников, защиты данных при их передаче по сети
Необходимость наличия многоуровневых справочников метаданных
Если роль метаданных (обычно содержащихся в таблицах-каталогах) в оперативных информационных системах достаточно ограничена, то для OLAP-систем наличие развитых метаданных и средств их предоставления конечным пользователям является одним из основных условий успешной реализации. Например, прежде, чем менеджер корпорации задаст системе свой вопрос, он должен понять, какая информация имеется, насколько она актуальна, можно ли ей доверять, сколько времени может занять формирование ответа и т.д.
Для пользователя OLAP-системы требуются метаданные, по крайней мере, следующих типов.
Типы метаданных для пользователя OLAP-системы
Описания структур данных, их взаимосвязей.
Информация о хранимых на ХД и поддерживаемых им агрегатах данных.
Информация об источниках данных и о степени их достоверности. Одна и та же информация могла попасть в ХД из разных источников. Пользователь должен иметь возможность узнать, какой источник был выбран основным, и каким образом производились согласование и очистка данных.
Информация о периодичности обновлений данных. Желательно знать не только то, какому моменту времени соответствуют интересующие его данные, но и когда они в следующий раз будут обновлены.
Информация о владельцах данных. Пользователю OLAP-системы может оказаться полезной информация о наличии в системе данных, к которым он не имеет доступа, о владельцах этих данных и о действиях, которые он должен предпринять, чтобы получить доступ к данным.
Статистические оценки времени выполнения запросов. До выполнения запроса полезно иметь хотя бы приблизительную оценку времени, которое потребуется для получения ответа, и объема этого ответа.
Потребность в эффективном хранении и обработке очень больших объемов информации
Уже сейчас известны примеры ХД, содержащих терабайты информации. По данным консалтинговой компании Meta Group , около половины корпораций, использующих или планирующих использовать ХД, предполагает довести их объем до сотен гигабайт. Проблемой таких больших хранилищ является то, что накладные расходы на внешнюю память возрастают нелинейно при возрастании объема хранилища. Исследования, проведенные на основе тестового набора TPC-D, показали, что для БД объемом в 100 гигабайт потребуется внешняя память объемом в 4.87 раза большая, чем нужно собственно для полезных данных. При дальнейшем росте БД этот коэффициент увеличивается.
Реализация хранилищ и витрин данных
Варианты реализации ХД
Виртуальное ХД
В его основе - репозиторий метаданных, которые описывают источники информации (БД транзакционных систем, внешние файлы и др.), SQL-запросы для их считывания и процедуры обработки и предоставления информации. Непосредственный доступ к последним обеспечивает ПО промежуточного слоя. В этом случае избыточность данных нулевая. Конечные пользователи фактически работают с транзакционными системами напрямую со всеми вытекающими отсюда плюсами (доступ к "живым" данным в реальном времени) и минусами (интенсивный сетевой трафик, снижение производительности OLTP-систем и реальная угроза их работоспособности вследствие неудачных действий пользователей-аналитиков).
Витрины данных - это набор тематически связанных БД, которые содержат информацию, относящуюся к отдельным аспектам деятельности корпорации. По сути дела, витрина данных - это облегченный вариант ХД, содержащий только тематически объединенные данные. Целевая база данных максимально приближена к конечному пользователю и может содержать тематически ориентированные агрегатные данные. Витрина данных, естественно, существенно меньше по объему, чем корпоративное ХД, и для его реализации не требуется особо мощная вычислительная техника.
Глобальное ХД
В последнее время все более популярной становится идея совместить концепции хранилища и витрины данных в одной реализации и использовать ХД в качестве единственного источника интегрированных данных для всех витрин данных. Тогда естественной становится такая трехуровневая архитектура системы:
Первый уровень - корпоративное ХД на основе одной из современных РСУБД. Это ХД интегрированных в основном детализированных данных. РСУБД обеспечивают эффективное хранение и управление данными очень большого объема, но не слишком хорошо соответствуют потребностям OLAP-систем, в частности, в связи с требованием многомерного представления данных
Второй уровень - витрины данных на основе многомерной СУБД (примером - Oracle Express Server ). Такие СУБД почти идеально подходят для целей разработки OLAP-систем, но пока не позволяют хранить сверхбольшие объемы данных (предельный размер многомерной БД составляет 10-40 Гбайт). В данном случае это и не требуется, поскольку речь идет о витринах данных. Заметим, что витрина данных не обязательно должна быть полностью сформирована. Она может содержать ссылки на ХД и добирать оттуда информацию по мере поступления запросов. Конечно, это несколько увеличивает время отклика, но зато снимает проблему ограниченного объема многомерной БД
Третий уровень - клиентские рабочие места конечных пользователей, на которых устанавливаются средства оперативного анализа данных
| |
Скачать 2.04 Mb.