Хранилище данных - Архитектура

В этой главе мы обсудим структуру бизнес-анализа для проектирования хранилища данных и архитектуру хранилища данных.

Структура бизнес-анализа

Бизнес-аналитик получает информацию из хранилищ данных, чтобы измерить производительность и внести критические изменения, чтобы завоевать других владельцев бизнеса на рынке. Наличие хранилища данных предлагает следующие преимущества -

  • Поскольку хранилище данных может быстро и эффективно собирать информацию, оно может повысить производительность бизнеса.

  • Хранилище данных предоставляет нам согласованное представление о клиентах и товарах, следовательно, оно помогает нам управлять отношениями с клиентами.

  • Хранилище данных также помогает снизить издержки, отслеживая тенденции и закономерности в течение длительного периода последовательным и надежным образом.

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

  • Представление сверху вниз - это представление позволяет выбрать соответствующую информацию, необходимую для хранилища данных.

  • Представление источника данных - это представление представляет информацию, которая собирается, хранится и управляется операционной системой.

  • Представление хранилища данных - это представление включает таблицы фактов и таблицы измерений. Он представляет информацию, хранящуюся в хранилище данных.

  • Представление бизнес-запроса - это представление данных с точки зрения конечного пользователя.

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

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

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

  • Средний уровень. На среднем уровне у нас есть сервер OLAP, который может быть реализован любым из следующих способов.

    • По реляционной OLAP (ROLAP), которая является расширенной системой управления реляционной базой данных. ROLAP отображает операции над многомерными данными в стандартные реляционные операции.

    • Модель многомерного OLAP (MOLAP), которая непосредственно реализует многомерные данные и операции.

  • Верхний уровень - этот уровень является уровнем клиентского интерфейса. Этот уровень содержит инструменты запросов и инструменты отчетности, инструменты анализа и инструменты анализа данных.

Следующая диаграмма изображает трехуровневую архитектуру хранилища данных -

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

Модели хранилищ данных

С точки зрения архитектуры хранилища данных у нас есть следующие модели хранилища данных -

  • Виртуальный склад
  • Витрина данных
  • Корпоративный склад

Виртуальный склад

Вид на оперативное хранилище данных называется виртуальным хранилищем. Это легко построить виртуальный склад. Создание виртуального хранилища требует избыточных мощностей на действующих серверах баз данных.

Data Mart

Витрина данных содержит подмножество общеорганизационных данных. Это подмножество данных является ценным для конкретных групп организации.

Другими словами, мы можем утверждать, что витрины данных содержат данные, специфичные для конкретной группы. Например, витрина маркетинговых данных может содержать данные, относящиеся к товарам, покупателям и продажам. Витрины данных ограничены предметами.

Что нужно помнить о витринах данных -

  • Для реализации витрин данных используются серверы на основе окон или Unix / Linux. Они реализованы на недорогих серверах.

  • Циклы витрины данных реализации измеряются в короткие периоды времени, то есть в неделях, а не в месяцах или годах.

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

  • Витрины данных имеют небольшой размер.

  • Витрины данных настраиваются отделом.

  • Источником витрины данных является хранилище данных, имеющее структурную структуру.

  • Данные витрины являются гибкими.

Корпоративный склад

  • Склад предприятия собирает всю информацию и предметы, охватывающие всю организацию

  • Это обеспечивает нам интеграцию данных в масштабах всего предприятия.

  • Данные интегрированы из операционных систем и внешних поставщиков информации.

  • Эта информация может варьироваться от нескольких гигабайт до сотен гигабайт, терабайт или более.

Менеджер нагрузки

Этот компонент выполняет операции, необходимые для извлечения и загрузки процесса.

Размер и сложность диспетчера нагрузки варьируются между конкретными решениями от одного хранилища данных до другого.

Архитектура диспетчера нагрузки

Диспетчер нагрузки выполняет следующие функции -

  • Извлечь данные из исходной системы.

  • Быстрая загрузка извлеченных данных во временное хранилище данных.

  • Выполните простые преобразования в структуру, похожую на структуру хранилища данных.

Менеджер нагрузки

Извлечь данные из источника

Данные извлекаются из оперативных баз данных или внешних поставщиков информации. Шлюзы - это прикладные программы, которые используются для извлечения данных. Он поддерживается базовой СУБД и позволяет клиентской программе генерировать SQL для выполнения на сервере. Open Database Connection (ODBC), Java Database Connection (JDBC), являются примерами шлюза.

Быстрая загрузка

  • Чтобы минимизировать общее окно загрузки, данные должны быть загружены в хранилище в кратчайшие сроки.

  • Преобразования влияют на скорость обработки данных.

  • Более эффективно загружать данные в реляционную базу данных до применения преобразований и проверок.

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

Простые преобразования

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

  • Удалите все столбцы, которые не требуются на складе.
  • Преобразуйте все значения в требуемые типы данных.

Заведующий складом

Менеджер склада отвечает за процесс управления складом. Он состоит из системного программного обеспечения сторонних производителей, программ на C и сценариев оболочки.

Размер и сложность менеджеров склада варьируются в зависимости от конкретных решений.

Архитектура менеджера склада

Менеджер склада включает в себя следующее:

  • Процесс контроля
  • Хранимые процедуры или C с SQL
  • Инструмент резервного копирования / восстановления
  • Сценарии SQL
Заведующий складом

Операции, выполняемые менеджером склада

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

  • Создает индексы, бизнес-представления, разделы на основе базовых данных.

  • Создает новые агрегаты и обновляет существующие агрегаты. Создает нормализации.

  • Преобразует и объединяет исходные данные в опубликованное хранилище данных.

  • Резервное копирование данных в хранилище данных.

  • Архивирует данные, которые достигли конца своей захваченной жизни.

Примечание . Менеджер склада также анализирует профили запросов, чтобы определить, подходят ли индексы и агрегаты.

Менеджер запросов

  • Менеджер запросов отвечает за направление запросов к подходящим таблицам.

  • Направляя запросы в соответствующие таблицы, можно повысить скорость запросов и генерации ответов.

  • Диспетчер запросов отвечает за планирование выполнения запросов, заданных пользователем.

Архитектура Query Manager

На следующем снимке экрана показана архитектура диспетчера запросов. Включает в себя следующее:

  • Перенаправление запросов через инструмент C или RDBMS
  • Хранимые процедуры
  • Инструмент управления запросами
  • Планирование запросов с помощью инструмента C или RDBMS
  • Планирование запросов с помощью стороннего программного обеспечения
Менеджер запросов

Подробная информация

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

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

Подробная информация

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

Сводная информация

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

Примечания к сводной информации следующие:

  • Сводная информация ускоряет выполнение обычных запросов.

  • Это увеличивает эксплуатационные расходы.

  • Его необходимо обновлять всякий раз, когда новые данные загружаются в хранилище данных.

  • Возможно, оно не было зарезервировано, поскольку оно может быть сгенерировано свежим из подробной информации.