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

Я все еще изучаю основы OLAP, кубов и SSAS, но упираюсь в барьер производительности и не уверен, что понимаю, что происходит.

Итак, у меня есть простой куб, который определяет два простых измерения (тип и площадь), третью иерархию измерения времени (год->квартал->месяц->день->час->10 минут) и одну меру (сумма в поле под названием Count). База данных отслеживает события: когда они происходят, какого типа, где произошли. Таблица фактов представляет собой предварительно рассчитанную сводку событий для каждого 10-минутного интервала.

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

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

Я не понимаю. Я ожидаю, что переход к кварталам или годам займет больше всего времени, поскольку он должен собрать все данные. Переход к самой низкой метрике, сильно отфильтрованной примерно до 180 ячеек (6 интервалов, 10 типов, 3 области), кажется, должен быть самым быстрым. Почему куб обрабатывает весь набор данных, а не только видимое его подмножество? Почему высший уровень агрегации такой быстрый, а самый низкий уровень такой медленный?

Самое главное, могу ли я что-нибудь сделать с помощью конфигурации или дизайна, чтобы улучшить его?

Некоторые дополнительные детали, которые, как я только что подумал, могут иметь значение: Это SSAS 2005, работающий на SQL Server 2005, использующий Visual Studio 2005 для проектирования бизнес-аналитики. Куб настроен (по умолчанию) на полный MOLAP, но не разбит на разделы. Таблица фактов содержит 1 838 304 строки, так что это не сумасшедшая корпоративная база данных, но и не простая тестовая база данных. Разделения нет, и все SQL-процессы выполняются на одном сервере, к которому я получаю удаленный доступ со своей рабочей станции.


sql-server olap ssas cube
person CodexArcanum    schedule 07.07.2010    source источник

Ответы (3)


arrow_upward
0
arrow_downward

Когда вы смотрите на минутном уровне - вы говорите обо всех событиях с 12:00 до 12:10 вне зависимости от дня?

Я думаю, что если вам нужно, чтобы это работало быстрее (потому что, очевидно, это будет сканировать все), вам нужно будет сделать две части вашего измерения «времени» ортогональными - сделать измерение даты и измерение времени.

Если вы получаете 1/1/1900 12:00 до 1/1/1900 12:10, я не уверен, что это может быть тогда...

person Cade Roux    schedule 07.07.2010
comment
Это хорошая теория, я проверил ее, чтобы убедиться, но это не так. Глядя на детализированный куб за 2009-Q1-January-1-0, я получаю подсчет за каждые 10 минут. Затем я использовал эти даты в SQL-запросе к исходным данным и подтвердил, что сумма (количество) верна. То, на что я смотрю, — это итоги за каждые 10 минут в этом часовом окне, и он также показывает совокупные итоги: за каждый час этого дня, каждый день этого месяца и т. д. Но все это было раньше. Но теперь я могу бесплатно выполнять детализацию в любом месте, потому что браузер загрузил весь куб в память. - person CodexArcanum; 08.07.2010

arrow_upward
0
arrow_downward

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

Предполагая, что это не так, то, что предлагает Кейд о создании измерения даты и времени, было бы наиболее очевидным подходом, но это еще один большой запрет в SSAS. Дополнительные сведения см. в этой статье: http://www.sqlservercentral.com/articles/T-SQL/70167/

Надеюсь это поможет.

person ajdams    schedule 07.07.2010
comment
Эта статья из SQL Server Central была почти повсеместно раскритикована в последующем обсуждении, потому что 1) обработка измерений CTE была расточительно неэффективной и 2) отдельные измерения даты и времени обычно считаются лучшими почти для всех видов анализа. - person Cade Roux; 08.07.2010
comment
На самом деле мне было интересно об этом, так как у меня сложилось впечатление, что аналитики повсеместно рекомендуют DateTimeTable для OLAP. Казалось бы, столь же фундаментальным, как хэш-карта для этого поля. Спасибо за особое мнение, приятно видеть все мысли по этому поводу. - person CodexArcanum; 08.07.2010
comment
@CodexArcanum Я не видел таблицу DateTime. В Кимбалле это всегда измерение даты с естественным целочисленным ключом формы ГГГГММДД и измерение времени (в соответствующем размере) с естественным целочисленным ключом ЧЧММСС. ЕДИНСТВЕННЫЙ случай, когда DateTime был бы полезен, - это произвольные диапазоны с датой и временем - скажем, с 8:38 в понедельник до 10:25 в пятницу. Они относительно редки, и, поскольку они в основном непрерывны, возможно, что лучше использовать столбец фактов даты и времени, который является дополнительным фильтром в запросе (который уже указывает критерии измерения даты, чтобы приблизиться). - person Cade Roux; 18.07.2010

arrow_upward
0
arrow_downward

Я бы также проверил, чтобы убедиться, что вы используете последнюю версию sp для sql server 2005.

Версия RTM имела некоторые проблемы с производительностью SSAS.

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

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

дополнительная информация: http://ms-olap.blogspot.com/2008/10/attribute-relationship-example.html

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

person Jason Horner    schedule 09.07.2010