Статья довольно старая, но я все же решил ее перевести, потому что многие, до сих пор, несколько неверно воспринимают описываемые ниже подходы к построению архитектуры хранилищ данных.
Источник: http://www.rittmanmead.com/2009/07/drilling-down-in-the-oracle-next-generation-reference-dw-architecture/
Погружение в детали эталонной архитектуры Хранилищ Данных от Oracle.
Если вы читали этот блог на протяжении нескольких последних лет или слышали мои презентации по архитектуре хранилищ данных от Oracle, вы, возможно, уже видели эту архитектурную диаграмму, составленную Doug Cackett, Simon Griffiths, Kevin Lancaster, Andrew Bond и Keith Laker, сотрудниками Oracle в Великобритании, к подготовке концепций которой я тоже приложил руку.
Это эталонная архитектура хранилища данных. BI и EPM архитектура, поддерживающая структурированные и неструктурированные источники данных, доступ к данным со стороны BI приложений, таких как Oracle BI EE и Oracle EPM Suite, и трехуровневое хранилище со следующими уровнями: стейджинг (stage), детальные данные (foundation), отчетные данные (access and performance). Идея состоит в том, чтобы придумать, как соединить сильные стороны БД Oracle, OBIEE и EPM Suite вместе с Fusion Middleware в архитектуру BI/ХД "следующего поколения".
Презентация моего авторства с последнего Oracle BI симпозиума в Лондоне содержит больше подробностей об этой идее, если вы заинтересованы в детальном понимании.
Если пока оставить в стороне ПО промежуточного уровня и BI инструменты, описываемая архитектура хранилища данных уже использовалась нами в последнее время и использовалась вполне успешно. Уровень стейджинга достаточно очевиден, назначение же уровней для детальных или отчетных данных выглядит несколько запутанным поначалу, потому я попытаюсь объяснить в этом постинге зачем они на самом деле нужны.
Уровень стейджинга это такая "посадочная площадка" для входящих данных, и, в обычном случае, это такая куча таблиц, заполняющихся данными посредством програм выгрузки данных из некоторого набора систем источников. Также вы можете обнаружить там внешние (external) таблицы или таблицы по отслеживанию изменений в источниках данных, заполняемые Oracle CDC. Области стейджинговых данных особенно важны при использовании ELT (Выгрузить-Загрузить-Преобразовать) инструментов, таких как Oracle Warehouse Builder и Oracle Data Integrator, которые используют СУБД и язык запросов SQL для преобразования ваших данных.
Большинство людей, работающих с хранилищами данных на протяжении последних лет десяти, знают концепцию моделирования по схеме Звезда. Моделирование размерностей, с таблицами фактов, измерениями, иерархиями, путями углубления в данные и т.п. это отличный способ для демонстрации данных бизнес пользователям.
Этот же подход позволяет успешно работать с данными таким специализированным BI инструментам как Oracle BI. Встраивая пути детализации данных в сами данные и денормализируя данные в более простые таблицы, вы делаете работу оптимизатора запросов Oracle более легкой, вы минимизируете количество соединений, и вы презентуете вашим пользователям более простую и легкую для понимания модель данных. И все это мы получаем благодаря тому, что в нашей архитектуре есть слой отчетных данных.
В то время как модель измерений отличная вещь для организации доступа к информации, эта модель не совсем хороша для долговременного хранения данных. Особенно, если вы ожидаете, что требования к анализируемым данным будут изменяться со временем. Что, если вы решите использовать Essbase или Oracle OLAP как средство для исследования данных, или, даже, инструмент вроде Qlikview или Gemini от Microsoft, которые вообще не используют измерения? Что, если вы захотите переделать ваши звезды, переделать факты в измерения, пересобрать иерархии, или добавить новую продуктовую линейку, имеющую полностью другой набор атрибутов, к текущему справочнику продуктов? Не выйдет ли так, что вы, с помощью модели дименшинов полностью загнали себя в угол, или хуже того, вы потеряли часть детальной информации, использовав высокоуровневую агрегацию данных. Внесение изменений в такое хранилище данных может быть совсем не легким.
Учитывая описанное, уровень детальных данных в эталонной архитектуре используется для целей управления информацией. Сохраняя ваши исходные данные независимо от меняющихся бизнес требований и средств выполнения запросов, и при этом совершенно неважно, какие выдвинуты требования для BI и какой конкретно инструмент отчетности вам необходимо поддерживать. Данные на этом уровне обычно сохраняются в третьей нормальной форме, с иерархиями организованными в виде значений в столбцах таблиц, а не специальным образом организованных таблиц для иерархий. Структуры таблиц данных этого уровня одновременно и достаточно гибкие и не занимают избыточного места на диске.
Детальные данные содержат значения сущностей для всех ключевых элементов хранилища, при этом значение может быть сохранено в двух формах, в виде «текущего» значения в одной таблице и истории изменений ключевого атрибута в виде отдельной, исторической таблицы. Бизнес ключ и идентификатор в системе источнике используются на этом уровне совместно, все данные должны быть уже очищены, преобразованы, а все ошибочные данные должны попасть в отдельную область стейджинга для отклоненных данных. Суть этой отдельной области в том, чтобы обеспечить отсутствие потерь в исходных данных, особенно в ситуациях, когда в ХД используется новая система кодификации объектов, которая может и не учесть всех необходимых для будущего анализа деталей. Обратите внимание, что на этом уровне нет суррогатных ключей, медленно изменяющихся размерностей, жестко заданных иерархий и других характерных для размерностной модели деталей, необходимых на уровне отчетности.
Уровень отчетности это то место, где вы используете звезды, как в виде денормализованных таблиц, так и в виде модели снежинка. На этом уровне вы делаете все возможное, чтобы оптимизировать доступ к данным для вашего инструмента генерации пользовательских запросов. И не забывайте, что у вас всегда есть оригинальный набор данных, который вы храните на детальном уровне, в случае если вам необходимо будет переконфигурировать ваши датамарты.
Я уверен, что этот подход имеет несколько ключевых достоинств. Во-первых, как многие из нас, OBIEE разработчиков, привыкли считать, не каждая аналитика может быть реализована посредством запроса на получение данных из измерений, особенно если мы уйдем из сферы финансов или учета продаж. Если вы используете инструмент вроде OBIEE, вы можете организовать доступ как к отчетным так и к детальным данным внутри одного механизма создания отчетности. Делаться это может как созданием виртуальных звезд поверх третьей нормальной формы детального уровня данных, так и организацией доступа к сырым данным через Oracle Publisher (или Discoverer).
Ключевой выгодой в этом случае является тот факт, что ваше ХД будет чем-то большим, чем просто реализацией требований ваших пользователей в виде размерностной модели на текущий момент. В тоже время, Ральф Кимбол мог бы сказать, что вы смогли бы изящно адаптировать вашу размерностную модель для учета изменений и новых данных, по моему опыту выходит, что это более выкрутасное занятие, чем поддерживать промежуточный слой данных в третьей нормальной форме, и выкатить, при необходимости, новую согласованную модель размерностй в случае существенных изменений в требованиях. Более того, как я упоминул ранее, не все можно описать моделью измерений. И, если вы можете обеспечить в вашем ХД доступ не только к размерностной модели, но и к детальным данным, особенно в случае использования Exadata, с ее секционированием по хешу/диапазонам, вы сможете удовлетворить требования ваших пользователей к быстрому доступу к данным, особенно если они хотят работать с транзакионными данным или данными, не укладывающимися в рамерностную модель.
Хочу также привести вопрос и ответ автора из комментариев к этой заметке. Ответ, в тезисной форме, еще раз повторяет рассуждения из самой заметки.
Вопрос – Извините за столь позднее комментирование, я так понял, что после стейджинга вы хотите иметь еще один слой который содержит ту же структуру, в третьей нормальной форме, что мы имеем в источнике, тот же OLTP?
Ответ – Ок, второй уровень (уровень детальных данных) будет нормализованным и соединяющим в себе все источники. Принимая во внимание то, что источники сами по себе могут быть нормализованы или спроектированы не совсем правильно, а так же то, что у нас несколько источников вообще, уровень детальных данных дает нам:
- Правильно спроектированный нормализованный уровень данных.
- Объединяющий данные полученные из нескольких систем.
- Сохраняющий историю изменений.
- И все это в структурах данных не увязанных на особенности инструмента генерации пользовательских запросов.
И именно в этом и состоят отличия от обычных OLTP систем, которые вы упомянули в вопросе.
Я бы добавил так же тот факт, что даже из правильно спроектированных и нормализованных источников данных в ХД могут отбираться только определенные части общей структуры, или даже части таблицы. Что может привести как к усложнению структуры ХД по сравнению с источником, так и наоборот, к ее упрощению.
Комментариев нет:
Отправить комментарий
Примечание. Отправлять комментарии могут только участники этого блога.