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

федеральное государственное бюджетное образовательное 

учреждение высшего профессионального  образования

Санкт-Петербургский государственный  политехнический университет

 

Факультет Экономики и Менеджмента

Кафедра «Экономика и менеджмент недвижимости и технологий»

 

 

 

Курсовая работа

Дисциплина: «Информационные технологии в экономике»

Тема: «Архитектура хранилищ данных»

                                     

 

 

 

                      Выполнили: студенты гр.4072/2     ________        Филатова  Т.М.

                                                                                                           Кленова Ю. С.

          Приняла:                                                                                 Гуторова Н.В..

 

 

 

Санкт-Петербург

2012 г.

Содержание:

Введение……………………………………………………………………….......3

Глава 1. Архитектура  хранилищ данных

1. Централизованная ETL с параллельными хранилищами и витринами данных…………………………………………………………………........4
2. Хранилище с накоплением данных в витринах………………………......7
3. Хранилище данных с интеграционной шиной………………………….11
4. Рекомендованная архитектура КХД……………………………………..14

Заключение……………………………………………………………….............18

Список использованной литературы……………………………………….......19

 

 

 

 

 

 

 

 

 

 

 

 

 

Введение

 

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

 

 

 

 

 

 

 

 

Глава 1. Архитектура хранилищ данных

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

 

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

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

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

Еще одним решением является двойное  подключение подобных витрин – напрямую к средствам ETL и к хранилищу  данных, что приводит к недоразумениям и рассогласованиям результатов  аналитических работ. Причина кроется  в том, что данные, поступающие в хранилище, как правило, проходят дополнительные проверки на непротиворечивость с уже загруженными данными. Например, может прийти финансовый документ с реквизитами, почти совпадающими с документом, поступившим в ЦХД ранее. Система ETL, не обладая памятью обо всех загруженных данных, не может выявить, является ли новый документ законным исправлением существующего, или это ошибка.

 

Рис. 1. Централизованная ETL с параллельными  ХД И ВД

 

 

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

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

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

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

 

 

 

 

 

 

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

 

Основанием  для появления этой архитектуры  явились следующие предпосылки.

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

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

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

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

 

Диагноз – пользователи независимых прикладных витрин говорят на разных языках бизнеса, и каждая витрина содержит собственные  метаданные.

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

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

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

Эта работа невозможна без использования средств ведения метаданных и НСИ, область действия которых будет распространяться только на центральное хранилище (ЦХД), так как независимые витрины данных содержат свои метаданные и НСИ.

В результате руководство и эксперты могут получить согласованные и непротиворечивые отчеты, но они не смогут проследить происхождение данных сквозным образом, так как между независимыми витринами и ЦХД есть разрыв в ведении метаданных.

Таким образом, стремление к достижению сиюминутных результатов и к демонстрации быстрых успехов приводит к отказу от единого, сквозного управления метаданными и НСИ. Итогом такого подхода является наличие семантических островов, где сотрудники говорят на разных бизнес – языках.

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

 

Широкое распространение  сервис - ориентированной архитектуры (СОА) привело к желанию использовать ее в решениях для корпоративных хранилищ данных (КХД) вместо средств извлечения, преобразования и загрузки данных (ETL) в центральное хранилище (ЦХД) и вместо средств выборки, реструктуризации и доставки данных (SRD) в витрины данных.

Интеграционная  шина, которая лежит в основе СОА, предназначена для интеграции веб - сервисов и приложений и выполняет  следующие задачи:

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

 

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

На  первый взгляд функциональные возможности  СОА позволяют применить ее для  замены ETL и SRD. Действительно, ETL выполняет  посреднические функции между ЦХД  и источниками данных, а SRD является посредником между ЦХД и витринами  данных. Если заменить ETL и SRD на интеграционную шину, то, казалось бы, можно воспользоваться гибкостью, предоставляемой шиной для интеграции приложений. Представим себе, что ЦХД, оперативный склад данных (ОСД), зоны временного хранения, системы ведения метаданных и НСИ обращаются к шине как независимые приложения с запросами к источникам данных на обновление данных.

Прежде всего, в разы возрастет нагрузка на системы-источники данных, так как одна и та же информация будет многократно передаваться по запросам в ЦХД, ОСД, зоны временного хранения и системы управления метаданными и НСИ. Очевидное решение – создать собственное хранилище данных при шине для кеширования запросов.

Во-вторых, регламент сбора информации, ранее  централизованный в ETL, теперь рассеян  по приложениям, запрашивающим данных. Рано или поздно возникнут рассогласования в регламентах сбора данных для ЦХД, ОСД, систем ведения НСИ и метаданных. Данные, собранные по разным методикам, в разные отрезки времени, обработанные по разным алгоритмам, будут несогласованны друг с другом. Тем самым будет разрушена основная цель создания ЦХД как единого источника согласованных непротиворечивых данных.