Агрегат (хранилище данных)
Агрегат многомерных — это тип сводки, используемый в моделях хранилищ данных для сокращения времени, необходимого для предоставления ответов на типичные запросы к большим наборам данных . Причина, по которой агрегаты могут так резко повысить производительность хранилища данных, заключается в уменьшении количества строк, к которым осуществляется доступ при ответе на запрос. [1]
Используйте [ править ]
В своей простейшей форме агрегат представляет собой простую сводную таблицу, которую можно получить путем выполнения запроса Group by SQL. Более распространенное использование агрегатов — взять измерение и изменить его степень детализации. При изменении детализации измерения таблица фактов должна быть частично суммирована, чтобы соответствовать новому уровню детализации нового измерения , таким образом создавая новые таблицы измерений и фактов, соответствующие этому новому уровню детализации.
Дизайн [ править ]
Агрегаты иногда называют предварительно рассчитанными сводными данными, поскольку агрегаты обычно представляют собой предварительно вычисленные, частично суммированные данные, которые хранятся в новых агрегированных таблицах. Когда факты агрегируются, это делается либо путем устранения размерности, либо путем связывания фактов со свернутым измерением. Свернутые измерения должны представлять собой уменьшенные версии измерений, связанных с детализированными базовыми фактами. Таким образом, агрегированные таблицы измерений должны соответствовать базовым таблицам измерений. [2]
Производительность [ править ]
В 1996 году Ральф Кимбалл , широко известный как один из первых архитекторов хранилищ данных, заявил: [3]
Самый существенный способ повлиять на производительность большого хранилища данных — предоставить правильный набор совокупных (сводных) записей, сосуществующих с первичными базовыми записями. Агрегаты могут оказывать очень существенное влияние на производительность, в некоторых случаях ускоряя запросы в сто или даже в тысячу раз. Никаких других средств для получения столь впечатляющих результатов не существует.
Сложность [ править ]
Наличие агрегатов и атомарных данных увеличивает сложность многомерной модели. Эта сложность должна быть прозрачна для пользователей хранилища данных, поэтому при выполнении запроса хранилище данных должно возвращать данные из таблицы с правильной степенью детализации. Поэтому при выполнении запросов к хранилищу данных следует реализовать функциональность агрегатного навигатора, чтобы помочь определить правильную таблицу с правильной степенью детализации. Количество возможных агрегатов определяется всеми возможными комбинациями детализации измерений. Поскольку построение всех возможных агрегатов потребует больших затрат, рекомендуется выбрать подмножество таблиц, на которых будут выполняться агрегаты. Лучший способ выбрать это подмножество и решить, какие агрегаты создавать, — это отслеживать запросы и разрабатывать агрегаты в соответствии с шаблонами запросов. [4]
[ править ]
Наличие агрегированных данных в многомерной модели усложняет среду. Чтобы сделать эту дополнительную сложность прозрачной для пользователя, используется функция, известная как агрегатная навигация, для запроса таблиц измерений и фактов с правильным уровнем детализации. Агрегатная навигация по сути проверяет запрос, чтобы определить, можно ли на него ответить, используя агрегированную таблицу меньшего размера. [5]
Реализации агрегатных навигаторов можно найти в ряде технологий:
- OLAP- движки
- Материализованные представления
- Реляционные OLAP-сервисы ( ROLAP )
- BI или инструменты запросов Серверы приложений
Обычно рекомендуется использовать любую из первых трех технологий, поскольку преимущества в последнем случае ограничиваются одним интерфейсным бизнес-аналитики . инструментом [6]
Проблемы [ править ]
- Поскольку многомерные модели выигрывают от агрегатов только для больших наборов данных, следует учитывать, при каком размере наборов данных следует начинать использовать агрегаты.
- Можно также спросить себя, всегда ли хранилище данных обрабатывает наборы данных, которые слишком велики для прямых запросов, или иногда полезно опустить агрегированные таблицы при запуске нового проекта хранилища данных.
- Открытым остается вопрос, упростит ли исключение агрегатов в первой итерации построения нового хранилища данных структуру многомерной модели.
Ссылки [ править ]
- ^ Кристофер Адамсон, Освоение агрегатов хранилища данных: решения для повышения производительности звездообразной схемы , Wiley Publishing, Inc., 2006 г. ISBN 978-0-471-77709-0 , стр. 23
- ^ Ральф Кимбалл; Марджи Росс (2002). Инструментарий хранилища данных: Полное руководство по размерному моделированию (второе изд.). Компьютерное издательство Wiley. п. 356. ИСБН 0-471-20024-7 .
- ^ «Агрегированная навигация с (почти) отсутствием метаданных» . 15 августа 1995 г. Архивировано из оригинала 11 декабря 2010 г. Проверено 22 ноября 2010 г.
- ^ Kimball & Data Warehouse Toolkit , стр. 10. 355.
- ^ Kimball & Data Warehouse Toolkit , стр. 10. 137.
- ^ Kimball & Data Warehouse Toolkit , стр. 10. 354.