Remkomplekty.ru

IT Новости из мира ПК
3 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

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

Корпоративные хранилища данных. Интеграция систем. Проектная документация.

Архитектура корпоративного хранилища данных

Основными компонентами корпоративного хранилища данных являются:

  • Модель данных;
  • База данных;
  • ETL-приложение;
  • BI-приложение.

Архитектура области хранения данных базы данных корпоративного хранилища, как правило, состоит из следующих областей:

  • область временного хранения данных (Staging Area) – предназначена для временного хранения данных, извлеченных из систем-источников; является промежуточным слоем между операционными системами компании и хранилищем данных;
  • область постоянного хранения данных, которая включает:
    • детальные данные (System of records) – область хранения детальных данных, приведенных к структуре модели данных корпоративного хранилища, прошедших очистку и обогащение;
    • агрегаты (Summary area) – сгруппированные по времени (чаще просуммированные) детальные данные;
    • витрины данных (Data Marts) – тематические наборы данных, хранящиеся в виде пригодном для их анализа (например, схема «звезда»); ориентированны на поддержку конкретных бизнес-процессов, приложений, подразделений компании, бизнес-целей;
  • интерфейсы обмена данными с другими системами (Data Exchange Interface или Feedback Area) – таблицы БД, в которых храняться подготовленные для передачи в другие информационные системы компании данные из области постоянного хранения данных;
  • метаданные (Metadata) – являются важной частью архитектуры хранилища данных. Метаданные — это данные, описывающие правила, по которым «живет» хранилище. Например, с точки зрения базы данных хранилища, метаданными является описание структур таблиц, взаимосвязей между ними, правил секционирования, описание витрин данных и т.п. С точки зрения ETL, метаданными являются описания правил извлечения и преобразования данных, периодичность выполнения ETL-процессов и т.п.

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

Ниже представлена общая схема организации областей хранения данных.

Область временного хранения данных (Staging Area)

Область временного хранения данных является промежуточным слоем между источниками данных и областью постоянного хранения. В данной области сохраняются извлеченные из операционных систем-источников (СУБД, csv, dbf, xml файлов, web-сервисов и т.д.) данные, производится их очистка, трансформация, обогащение, подготовка к загрузке в область постоянного хранения. Зачастую очередной цикл обработки и загрузки данных в хранилище не может быть начат пока не будут извлечены все необходимые данные из различных систем-источников, а в силу ряда причин (географической распределенности, разных циклов функционирования систем и т.п.) данные в источниках могут быть доступны в разные моменты по времени. Область временного хранения служит для сбора всех необходимых данных перед началом трансформации.

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

Ниже представлены основные принципы формирования области временного хранения.

  1. В области временного хранения данных должно быть относительно небольшое количество сущностей — до 20, в которые сохраняются все необходимые данные, извлеченные из систем-источников.
  2. Основой для проектирования состава сущностей области временного хранения должны являться предметные области (Subject Area) модели данных.
  3. При извлечении данных из систем-источников сами данные и их типы не должны принципиально изменяться.

Детальные данные (System of records)

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

Данная область содержит следующие типы сущностей:

  • справочники и классификаторы;
  • сущности, содержащие фактические значения;
  • сущности, описывающие связи.

Справочники и классификаторы определяют:

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

Сущности, содержащие фактические значения, – транзакционные данные из систем источников. Например, информация о совершенных телефонных звонках, выставленных счетах, проводках, проданных товарах и т.п.

Сущности, содержащие связи, определяют взаимосвязи между остальными сущностями. Например, Клиент-Услуга.

Область детальных данных не содержит никаких агрегатов. Только детальные, очищенные и структурированные в соответствии с моделью данные.

Агрегаты (Summary area)

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

Витрины данных (Data Marts)

Витрины данных являются объектами хранения аналитической информации, нацеленными на поддержку конкретных бизнес-функций, конкретных подразделений компании. На уровне базы данных витрины обычно реализуются по схеме «звезда» или «снежинка» и содержат данные из области детальных данных (System of records). Также могут быть реализованы в виде многомерного OLAP-куба. Витрины данных являются основой, обеспечивающей возможность проведения многомерного анализа (OLAP) данных.

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

  1. Витрины данных ориентированы на бизнес и при их проектировании необходимо учесть все измерения, показатели и иерархии, необходимые пользователям.
  2. При проектировании витрин данных необходимо учитывать особенности BI-приложения, используемого на проекте. Например, в Oracle Discoverer нет возможности создавать несбалансированные иерархии и это нужно учитывать.

Интерфейсы обмена данными (Data Exchange Interface)

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

Метаданные (Metadata)

Разработка и сопровождение системы с хорошо спроектированными и описанными метаданными является более простой задачей, нежели при отсутствии таковых. Метаданные хранилища включают:

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

Обычно управление метаданными осуществляется отдельными инструментами для каждого из компонентов хранилища. Например, для базы данных Oracle, метаданные которой хранятся в системных таблицах и настроечных файлах, это будет Oracle Enterprise Manager.

Журнал ВРМ World

Основные подходы к архитектуре Хранилищ данных

Как известно, Хранилища данных — это сравнительно новое технологическое решение, которое стало широко использоваться только в начале 90-х годов 20-го века, после того как Билл Инмон (Bill Inmon), ныне получивший всеобщее признание как «отец концепции Хранилища данных», опубликовал свою первую книгу по этой теме (W.H. Inmon, Building the Data Warehouse, QED/Wiley, 1991). Хотя отдельные элементы этой концепции и их техническое воплощение существовали и ранее (по сути дела, с 70-х годов прошлого века), только к концу 80-х годов была в полной мере осознана необходимость интеграции корпоративной информации и надлежащего управления ею, а также появились технические возможности для создания соответствующих систем, первоначально названных «хранилищами информации» (information warehouse) (Devlin, B.A. and Murphy, P.T. An Architecture for a Business and Information System. IBM Systems Journal. Volume 27, No. 1, 1988), а затем, с выходом книги Инмона, получивших свое нынешнее наименование Хранилищ данных.

На сегодняшний день существует два основных подхода к архитектуре Хранилищ данных. Это так называемая корпоративная информационная фабрика (Corporate Information Factory, сокр. CIF) Билла Инмона и Хранилище данных с архитектурой шины (Data Warehouse Bus, сокр. BUS) Ральфа Кимболла (Ralph Kimball). Рассмотрим каждый из них подробнее.

Corporate Information Factory

На рис. 1 представлен подход, используемый в Хранилищах данных с архитектурой CIF.

Рис. 1. Нормализованное Хранилище данных с пространственными витринами итоговых данных (CIF).

Когда-то этот подход был известен под названием корпоративного Хранилища данных (enterprise data warehouse, сокр. EDW). Работа такого Хранилища начинается со скоординированного извлечения данных из источников. После этого загружается реляционная база данных 1 с третьей нормальной формой 2 , содержащая атомарные данные. Получившееся нормализованное Хранилище используется для того, чтобы наполнить информацией дополнительные репозитории презентационных данных, т.е. данных, подготовленных для анализа. Эти репозитории, в частности, включают специализированные Хранилища для изучения и «добычи» данных (Data Mining), а также витрины данных.

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

Читать еще:  Архитектура операционной системы реферат

В качестве отличительных характеристик подхода Билла Инмона к архитектуре Хранилищ данных можно назвать следующие.

  1. Использование реляционной модели организации атомарных данных и пространственной — для организации суммарных данных.
  2. Использование итеративного или «спирального» подхода при создании больших Хранилищ данных, т.е. «строительство» Хранилища не сразу, а по частям. Это позволяет при необходимости вносить изменения в небольшие блоки данных или программных кодов и избавляет от необходимости перепрограммировать значительные объемы данных в Хранилище. То же самое можно сказать и о потенциальных ошибках: они также будут локализованы в пределах сравнительно небольшого массива без риска испортить все Хранилище.
  3. Использование третьей нормальной формы для организации атомарных данных, что обеспечивает высокую степень детальности интегрированных данных и, соответственно, предоставляет корпорациям широкие возможности для манипулирования ими и изменения формата и способа представления данных по мере необходимости.
  4. Хранилище данных — это проект корпоративного масштаба, охватывающий все отделы и обслуживающий нужды всех пользователей корпорации.
  5. Хранилище данных — это не механическая коллекция витрин данных, а физически целостный объект.

Data Warehouse Bus

Рис. 2 представляет альтернативный подход к архитектуре Хранилищ данных, известный как Хранилище с архитектурой шины или подход Ральфа Кимболла.

Рис. 2. Пространственное Хранилище данных.

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

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

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

Суммируя все вышесказанное, можно отметить типичные черты подхода Ральфа Кимболла.

  1. Использование пространственной модели организации данных с архитектурой «звезда» (star scheme).
  2. Использование двухуровневой архитектуры, которая включает стадию подготовки данных, недоступную для конечных пользователей, и Хранилище данных с архитектурой шины как таковое. В состав последнего входят несколько витрин атомарных данных, несколько витрин агрегированных данных и персональная витрина данных, но оно не содержит одного физически целостного или централизованного Хранилища данных.
  3. Хранилище данных с архитектурой шины обладает следующими характеристиками:
    • оно пространственное;
    • оно включает как данные о транзакциях, так и суммарные данные;
    • оно включает витрины данных, посвященные только одной предметной области или имеющие только одну таблицу фактов (fact table);
    • оно может содержать множество витрин данных в пределах одной базы данных.
  4. Хранилище данных не является единым физическим репозиторием (в отличие от подхода Билла Инмона). Это «виртуальное» Хранилище. Это коллекция витрин данных, каждая из которых имеет архитектуру типа «звезда».

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

Физическая архитектура хранения данных;

СУРБД Oracle, предназначенная для одновременного доступа к большим объемам (терабайтам) хранимой информации, скла­дывается из двух составляющих: базы данных (информации) и экземпляра (конкретной реализации системы). •

База данных. Состоит из физических файлов, хранящихся в системе, и логических файлов (например, схемы БД). Физические файлы хранятся на диске, а логические файлы являются компо­нентами физического уровня.

Итак, базы данных Oracle состоят из двух уровней: физическо­го и логического.

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

· Файлы данных хранят информацию, имеющуюся в БД. При­чем в БД может храниться и один файл данных и сотни. Инфор­мация из одной таблицы может быть распределена по нескольким файлам данных, а также несколько таблиц могут делить между собой пространство одного файла данных. При этом распределе­ние таблиц по нескольким файлам данных может значительно увеличить производительность системы. Количество файлов дан­ных ограничивается параметром maxdatafiles.

· Файлы журналов операций (redo log files) содержат информа­цию, необходимую для процесса восстановления в случае сбоя си­стемы, и все изменения, которые произошли в базе данных. С по­мощью журнала операций восстанавливают те изменения, кото­рые были произведены, но не зафиксированы перед сбоем сис­темы, поэтому файлы журналов операций должны быть очень хорошо защищены от аппаратных сбоев (как на программном, так и на аппаратном уровне). Если информация журнала опера­ций будет утеряна, восстановить систему будет практически не­возможно.

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

Логический уровень БДсоставляют следующие элементы: таб­личные пространства и схемы БД.

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

• Схемы БД — специальные логические структуры, с помощью которых в СУРБД Oracle происходит контроль над дисковым про­странством. Эти структуры состоят из блоков данных, экстентов, сегментов.

Блок данных — это наименьшая единица хранения данных в БД Oracle. Блоки данных, содержащие заголовочную информа­цию о себе и данные, физически хранятся на диске и в большин­стве систем занимают 2 Кбайт (2 048 байт), но для увеличения эф­фективности работы системы этот размер можно изменить.

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

При создании табличного пространства можно указать мини­мальное число экстент, что позволит контролировать все простран­ство хранилища БД.

Сегменты, в свою очередь, состоят из совокупностей эк­стентов, содержащих определенный вид данных. БД Oracle исполь­зует четыре типа сегментов:

· сегмент данных, хранящий пользовательские данные;

· индексный сегмент, содержащий индексы;

· сегмент отката, хранящий информацию отката, использу­емую при возврате к предыдущему состоянию БД;

· временный (промежуточный) сегмент, создаваемый в случае если для выполнения SQL-выражения необходимо дополнительное рабочее пространство и уничтожаемый сразу после выполнения SQL-команд. Промежуточные сегменты используются также в раз­личных операциях с БД, например при сортировке.

Экземпляр. Представляет собой конкретный способ доступа к данным и состоит из разделяемой памяти и процессов.

Разделяемая память (shared memory) используется для кэши­рования данных и индексов, а также для хранения программного кода. Разделяемая память подразделяется на несколько частей (или структур памяти), основными из которых являются: системная глобальная область (System Global Area) и программная глобаль­ная область (Program Global Area).

Системная глобальная область (SGA) — это область разделя­емой памяти, которая используется для хранения данных и уп­равляющей информации одного конкретного экземпляра Oracle. SGA размещается в памяти при запуске экземпляра Oracle и осво­бождает память при останове. Каждый запущенный экземпляр Oracle имеет свою собственную SGA.

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

Читать еще:  Централизованная архитектура бд

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

Буфер журнала изменений хранит данные об изме­нениях БД, записываясь в файл журнала изменений, использу­емого для восстановления экземпляра СУБД Oracle в случае сбоя системы, настолько быстро и эффективно, насколько это воз­можно.

Разделяемый пулхранит такие структуры разделяемой памяти, как разделяемые SQL-области в библиотечном кэше и внутренняя информация словаря данных. Состоит из библиотеч­ного кэша и кэша словаря данных.

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

Кэш словаря данных содержит набор таблиц и представлений, используемых в качестве ссылок к БД Oracle. Здесь хранится ин­формация о логической и физической структуре БД. Словарь дан­ных содержит следующую информацию:

· пользовательскую (например, пользовательские привилегии);

· ограничения целостности, определенные для таблиц БД;

· имена и типы данных всех столбцов таблиц БД;

· об объеме памяти, определенном и используемом объектами схемы данных.

Для обеспечения высокой производительности необходимо ус­танавливать достаточный объем памяти под кэш словаря данных.

• Программная глобальная область (PGA) — это область памя­ти, в которой хранятся данные и управляющая информация о серверных процессах Oracle. Размер и содержание PGA определя­ют опции, задаваемые при инсталляции Oracle. Эта область вклю­чает в себя следующие компоненты:

· пространство стека — память, хранящая переменные сеансов, массивы сеансов и т.д.;

· информация сеанса (только если Oracle работает не в мультинитиевом режиме);

· приватная SQ L-o б л а с т ь — часть PGA, где хранятся свя­занные переменные, и буферы реального времени.

Процесс — это механизм выполнения программного кода, ко­торый может быть незаметным для пользователя. Кроме того, не­сколько процессов могут работать одновременно. В разных опера­ционных системах и на разных платформах этот механизм может называться по-разному (процесс, нить, домен и т.д.). В СУРБД Oracle используются два вида процессов: пользовательские процессы и процессы Oracle, также называемые фоновыми, или теневыми. В некоторых операционных системах (например, Windows NT) про­цессы действительно являются нитями, но, чтобы не путаться в понятиях, будем называть их просто процессами.

· Пользовательские (клиентские) процессы — это пользователь­ские соединения с СУРБД. Пользовательский процесс управляет вводом и взаимодействует с серверными процессами в Oracle че­рез ее программный интерфейс. Он также используется для выда­чи информации пользователю и при необходимости представляет ее в более удобной форме.

· Процессы Oracle выполняют функции пользовательских про­цессов и могут быть разбиты на серверные (выполняющие функ­ции для активных процессов) и фоновые (выполняющие функ­ции СУРБД в целом).

Серверные (теневые) процессы взаимодействуют с процес­сами пользовательскими и Oracle, исполняя пользовательские зап­росы. Например, если пользовательский процесс запрашивает часть данных, которых еще нет в SGA, то теневой процесс несет ответ­ственность за считывание блоков данных из БД в SGA. При этом между пользовательским и теневым процессами возникает связь типа «один к одному», хотя один теневой процесс может одно­временно взаимодействовать с несколькими пользовательскими (конфигурация мультинитевого сервера), экономя системные ре­сурсы.

Фоновые процессыиспользуются для выполнения разнооб­разных задач СУРБД Oracle — от взаимодействия с экземпляром Oracle до записи грязных блоков на диск.

Представим некоторые из фоновых процессов Oracle.

DBWR (DataBase Writer) — ответственен за запись грязных блоков из блоковых буферов БД на диск. Когда транзакция изме­няет информацию в блоке данных, этот блок данных не обязан быть немедленно записан на диск. Следовательно, DBWR может записывать данные на диск более эффективно, чем выполнять запись всех изменений по отдельности, т.е. обычно он записыва­ет их тогда, когда они нужны для считывания. Записываются так­же те данные, которые были недавно использованы.

Для систем с асинхронным вводом-выводом достаточно одно­го процесса DBWR. Для остальных систем можно значительно уве­личить производительность, создав несколько процессов DBWR, таких как LGWR, СКРТ, PMON, SMON, RECO, ARCH, LCK«.

LGWR (LoG WRiter) — записывает данные из журнального буфера в журнал изменений.

СКРТ (ChecK PoinT) — дает сигнал процессам DBWR о необ­ходимости выполнения контрольной точки и обновления всех фай­лов данных и управляющих файлов. Контрольная точка — это со­бытие, при котором все измененные буферы БД записываются на диск. СКРТ — это необязательный процесс. Если процесс СКРТ не запущен, его работу принимает на себя процесс LGWR.

PMON (Process MONitor) — используется для поддержания остальных процессов и перезапуска после сбоя, а также очищает неиспользуемые области буферов и освобождает те ресурсы, ко­торые могут быть еще заняты. Ответственен за перезапуск всех за­висших процессов и диспетчеров.

SMON (System MONitor) — выполняет восстановление экзем­пляра при его запуске, что включает очистку временных сегмен­тов и восстановление незаконченных транзакций, а также де-фрагментирует БД.

RECO (RECOvery) — очищает незаконченные транзакции в распределенной БД. Выполняет фиксацию или откат спорных транз­акций.

ARCH (ARCHiver) — копирует файлы журнала изменений при их заполнении. Активен только в том случае, если СУРБД работает в режиме ARCHrVELOG. При работе системы в других режимах воз­можны ситуации, в которых не удастся восстановить ее после сбоя.

LCK« (Parallel Server LoCK) — использует при работе сервера в параллельном режиме до 10 процессов (л — от 0 до 9), которые выполняют функции межэкземплярной блокировки.

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

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

1. Нисходящий подход:

Основные компоненты обсуждаются ниже:

  1. Внешние источники —
    Внешний источник — это источник, откуда данные собираются независимо от типа данных. Данные могут быть структурированными, полуструктурированными и неструктурированными.
  2. Площадь сцены —
    Поскольку данные, извлеченные из внешних источников, не соответствуют определенному формату, необходимо проверить эти данные для загрузки в хранилище данных. Для этого рекомендуется использовать инструмент ETL .
    • E (извлечено): данные извлекаются из внешнего источника данных.
    • T (Transform): данные преобразуются в стандартный формат.
    • L (Load): данные загружаются в хранилище данных после преобразования их в стандартный формат.
  3. Хранилище данных —
    После очистки данных они сохраняются в хранилище данных в качестве центрального хранилища. Он фактически хранит метаданные, а фактические данные сохраняются в витринах данных. Обратите внимание, что хранилище данных хранит данные в чистом виде в этом нисходящем подходе.
  4. Витрины данных —
    Data Mart также является частью компонента хранения. Он хранит информацию об определенной функции организации, которая обрабатывается одним органом. В организации может быть как можно больше витрин данных в зависимости от функций. Можно также сказать, что витрина данных содержит подмножество данных, хранящихся в хранилище данных.
  5. Сбор данных —
    Практика анализа больших данных, представленных в хранилище данных, — это интеллектуальный анализ данных. Он используется для поиска скрытых паттернов, которые присутствуют в базе данных или в хранилище данных с помощью алгоритма интеллектуального анализа данных.

Этот подход определен Inmon как — хранилище данных как центральное хранилище для всей организации, и из него создаются витрины данных после создания всего хранилища данных.

Преимущества нисходящего подхода —

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

Недостатки нисходящего подхода —

  1. Стоимость, время, затрачиваемое на проектирование и его сопровождение, очень высоки.

2. Восходящий подход:

  1. Во-первых, данные извлекаются из внешних источников (так же, как это происходит в нисходящем подходе).
  2. Затем данные проходят через промежуточную область (как описано выше) и загружаются в витрины данных вместо хранилища данных. Витрины данных создаются в первую очередь и предоставляют возможность создания отчетов. Это относится к одной области бизнеса.
  3. Эти витрины данных затем интегрируются в хранилище данных.

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

Преимущества подхода снизу вверх —

  1. Как сначала создаются витрины данных, так и отчеты генерируются быстро.
  2. Мы можем разместить здесь большее количество витрин данных, и таким образом хранилище данных может быть расширено.
  3. Кроме того, затраты и время, затраченные на разработку этой модели, сравнительно невелики.

Недостаток подхода снизу вверх —

  1. Эта модель не так сильна, как нисходящий подход, так как размерное представление витрин данных не является согласованным, как в вышеприведенном подходе.

Записки виртуального админа

Новости, обзоры и заметки о виртуальных машинах и платформах виртуализации.

четверг, 27 февраля 2014 г.

Типы архитектур систем хранения данных

Это не новая тема, я её уже освещал на VMworld 2013 на сессии STO5420. Хранилища (такие штуки которые хранят информацию, и делают разные вещи с информацией) можно разделить на 4 группы. Главное здесь не зациклиться на не основных вещах.

Люди мысленно разделяют хранилища по их физическим свойствам типа интерконнекта (они все используют Infiniband!), протоколу (блочная СХД! Или NFS! Или мультипрокольная!) или даже аппаратное это или только программное решение (это просто софт на сервере!).

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

Поймите меня правильно — они важны, но не фундаментальны.

Тип 1. Кластеризованная архитектура (вертикально масштабируемые решения)

Такие решения характеризуются тем, что в них не используется общая память между контроллерами, и, по сути, данные находятся в кэше одного контроллера. СХД может быть A/A (оба контроллера активны), A/P (один контроллер пассивен), A/S (каждый контроллер обрабатывает свой объём данных, то есть у контроллеров ассиметричный доступ к данным).

Обработка данных такими СХД выглядит так:

Плюсы:

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

Минусы:

  • Масштабируемость ограничена мощностью контроллера или парой. Обычно до 1000 дисков.
  • Доступность данных гарантируется переключением между контроллерами. Что может привести к понижению производительности при выходе одного из строя.

Точки отказа:

  • Сам контроллер и его компоненты — железо и ПО.
  • Диски, порты в фабрике и т.д.

Примеры:

  • Active/Standby- Nimble, Pure Storage, Tintri, UCS Whiptail
  • Active/Passive- NetApp, EMC VNX*
  • Active/Active- HDS HUS, Dell Compellent, EMC VNX*, IBM V7000

Сюда же попадает все PCIe решения типа Fusion-IO или EMC XtremCache только без отказоустойчивости. Если это решение использует специализированное ПО для обеспечения отказоустойчивости, распределённого хранилища данных, целостности данных — смотрите на ПО, оно попадает под одну из четырёх архитектур.

Поверх такого можно поставить федеративное решение, чтобы сделать их более горизонтально масштабируемыми с точки зрения управления. Однако IO будет балансироваться ровно до попадания данных на контроллер. Такие решения также могут использоваться для балансировки между контроллерами и пулами (VDM Mobility у VNX и Clustered ONTAP у NetApp). Как по мне, такое решение можно с натяжкой назвать горизонтально масштабируемым. Так как данные, так или иначе, находятся за одним или другим контроллером. Балансировка и тюнинг важны, в отличие от архитектур 2 и 3, где она просто есть.

Тип 2. Слабо связанные (горизонтально масштабируемые решения)

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

Заметьте на картинке нода обозначена без отказоустойчивости, считается что устойчивость гарантируется распределённостью и копиями данных.

Обычно задержки в таких массивах прячут за хранилищем с низкой латентностью (NVRAM, SSD и т.д.), но в любом случае всегда больше задач по балансировке и копирования данных чем в обычном кластере типа 1 так как операции записи распределённые.

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

Преимущество такой архитектуры в простоте масштабирования и управления. Горизонтальное масштабируемые системы просто идеальны для транзакционных нагрузок так как из-за распределённой природы таких систем можно использовать не отказоустойчивые сервера не связанные между собой, с чем отлично справится старый добрый Ethernet.

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

Обработка запроса на запись выглядит следующим образом:

И, соответственно, на чтение:

Плюсы:

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

Минусы:

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

Точки отказа:

  • Все отказы на ноде приводят к полному её отказу.
  • Некоторые решения используют локальные RAID массивы, что приводит к тому что выход локального диска не приведёт к вывод из строя всей ноды.

Примеры:

  • Аппартные решения: EMC Isilon, Dell Equallogic, HP StoreVirtual 4000
  • Программные решения: VMware VSAN, IBM SONAS, HP StoreVirtual VSA, EMC ScaleIO, VMware Virsto
  • Конвергентные решения: SimpliVity, Nutanix.

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

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

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

Возьмём к примеру два решения от EMC — Isilon и XtremeIO. Не смотря на то что они оба очень похожи — оба решения горизонтально масштабируемы и оба используют Infiniband для интерконнекта разница в том, что Isilon использует Infiniband для минимизации задержек между нодами, и не использует общей памяти между нодами. Фактически, Isilon может использовать Ethernet (так и есть в VA версии), а XtremeIO зависим от RDMA.

Еще один важный момент отличия между двумя архитектурами: чем больше связанны контроллеры между собой, тем меньше, и предсказуемо меньше, будут задержки, но меньше масштабируемость из-за роста сложности системы.

Операции ввода-вывода выглядят так:

В распределённых системах не используется общая память, данные разнесены по разным нодам, но не транзакционно, а «лениво». То есть данные записываются на одну ноду, и с определённой периодичностью (иногда) копируются на другие ноды для обеспечения защищённости. Системы данного типа не транзакционны.

Неизбежный интерконнет всегда построен на Ethernet (просто потому что дёшево и всегда доступно), ноды не отказоустойчивы. Корректность данных не всегда обеспечивается СХД, а программным стеком выше с помощью контрольных сумм.

Эта простота делает данную архитектуру самой масштабируемой из всех. У неё абсолютно никакой зависимости от аппаратного обеспечения, и практически всегда выполнена в программном виде. Масштабируется до петабайт с такой же лёгкостью как другие СХД до терабайт. Обычно используется объектные и non-POSIX файловые системы часто даже лежащие поверх локальных ФС, используемых для базовых задач.

Ссылка на основную публикацию
Adblock
detector