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