Реферат на тему Архитектура хранилища данных

Содержание:

Введение. 3

1. Централизованная ETL с параллельными хранилищами и
витринами данных. 4

2. Хранилище с накоплением данных в витринах. 6

3. Хранилище данных
с интеграционной шиной. 9

4. Рекомендованная архитектура КХД. 12

Заключение. 16

Список использованной литературы: 17

Введение:

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

Хранилища данных и витрины данных не имеют четкой единой
письменной архитектуры. У компаний обычно есть дублирующие XД,
или, наоборот, многоуровневые витрины данных, которые имеют только одно
функциональное хранилище данных. Однако существует несколько наиболее
эффективных (и наиболее распространенных) архитектур XД.

Целью данного реферата является изучение архитектуры хранилищ
данных. Для достижения поставленной цели необходимо подробно рассмотреть
следующие аспекты, а именно: централизованная ETL с параллельными хранилищами и
витринами данных; хранилище с накоплением данных в витринах; хранилище данных с
интеграционной шиной; рекомендованная архитектура КХД.

В данном реферате в основе изучена литература Асадуллаева С.
«Архитектуры хранилищ данных» часть I и часть II. А
также более современная литература Дадян, Э. Г. «Данные:
хранение и обработка», «Современные базы данных. Основы. Часть 1: Учебное
пособие», «Проектирование современных баз данных: Учебно-методическое пособие».

Заключение:

В данном реферате изучена архитектура хранилищ данных, а
конкретно следующие аспекты:

· централизованная ETL с
параллельными хранилищами и витринами данных;

· хранилище с накоплением
данных в витринах;

· хранилище данных с
интеграционной шиной;

· рекомендованная
архитектура корпоративного хранилища данных (КXД).

Также в данном реферате изучены
достоинства и ограничения следующих архитектур:

· Хранилище данных (XД) с накоплением данных в витрине данных (BД);

· централизованная ETL с параллельными хранилищем
данных (ХД) и витриной данных (ВД);

· Хранилище данных (XД) с интеграционной шиной;

· рекомендованная архитектура хранилища
данных.

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

Фрагмент текста работы:

1. Централизованная ETL с
параллельными хранилищами и витринами данных. В данном изучаемом случае система
извлечения, преобразования и загрузки данных (ЕТL) является центром построения
всей архитектуры корпоративного хранилища данных (КXД). Информация из разных источников
поступает в ЕТL, а ЕТL выгружает чистые и согласованные данные в центральное
хранилище данных (ЦXД), оперативное хранилище данных (OCД), если оно есть, и при необходимости выгружает их во временное хранилище.
Это обычная практика КХД. Необычно загружать данные непосредственно из ЕТL в
витрину данных.

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

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