|
|
|
Aggregations в SSAS
|
|||
|---|---|---|---|
|
#18+
Просьба помочь со следующей проблемой. Есть OLAP Куб, сделанный в SSAS. В кубе 10 партиций в среднем по 2,5 ГБ (около 28 млн. строк в каждой). Данные в партиции выгружены на конец каждого месяца, соответственно в каждой партиции только одна дата - конец соответствующего месяца. 13 измерений. 13 вычисляемых мер (в разделе Calculations). NullProcessing для мер выставлен в значение Preseve (кроме одной количественной меры). Для ускорения работы куба создаю Агрегаты. Делаю пока только для одной партиции, чтобы посмотреть размер. Агрегат всего по двум измерениям (Дата и Подразделение) для одной единственной партиции выходит равным около 4,5Гб. Т.е. больше размера партиции! При том что в Design Почему такое может быть? И как уменьшить? В измерении около 36тыс. дат. Но в партиции непосредственно только одна дата используется. Может он для остальных дат, для которых нет значения проставляет 0 и это так влияет на размер? Ещё не могу понять как интерпретировать отображение рассчитанных агрегатов в режиме Advanced View. Там строки - все измерения, столбцы (A0 и A1) - агрегаты. Но в моём случае, хоть и указано для двух измерений AggregationUsage = Default, а для остальных None, почему-то галочка стоит только одна, в столбце A1 напротив Даты. А в столбце A0 напротив Подразделения никакой галочки нет (хотя свойство AggregationUsage = Default) , и вообще в столбце A0 галочки нет нигде. Что это значит? Буду благодарен за любую помощь. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2018, 17:02 |
|
||
|
Aggregations в SSAS
|
|||
|---|---|---|---|
|
#18+
veery_goodДля ускорения работы куба создаю Агрегаты. При том что в Design Почему такое может быть? И как уменьшить? Агрегаты не для ускорения работы куба . А для ускорения построения типовых отчетов, которые сверяют цифры на "верхних этажах". Допустим, у Вас 100 тысяч товаров, которые разложены по 5-6 категориям. Каждый день продается на сумму в N шекелей. Так вот построить на пересечении день-категория (где категория неключевой атрибут измерения товаров) - это кошерно. Потому что в отчете по дням в строки и по категориям в столбик Вы сможете быстро увидеть нулевые продажи какой-либо категории, которая продается ежедневно. Отсюда вывод - в исходных цифрах какой-то шлемазл все напутал. Не нужно пользоваться design подсказками. Или вдумчиво смотрите на трассу MDX запросов от Ваших пользователей, или делаете агрегаты чисто для себя, интуитивно. Такое может быть, если у Вас для 10 товаров и 10 строк продаж за день условно получается 10 байт. И 2 измерения - товар и дата. А каждый товар имеет уникальное свойство штрихкод. И уникальное свойство производитель. И уникальное свойство RGB цвет. И все это неключевые атрибуты измерения товаров. Как только Вы создаете агрегаты - один на пересечении дня и штрихкода, другой на пересечении дня и производителя, третий для цвета и дня - и получаете 40 байт вместо 10, из которых 30 байт будут в flex файле и 10 байт в fact.data файле. Как уменьшить - удалить все, в чем не разбираетесь, и заказать экспертизу со стороны, чтобы Вам помогли в первый раз сделать агрегаты правильно, а потом Вы и самостоятельно научитесь. Удачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.10.2018, 20:36 |
|
||
|
Aggregations в SSAS
|
|||
|---|---|---|---|
|
#18+
veery_goodПри том что в Design Не дописал. Имел ввиду, что в Design Aggregations я ограничиваю Estimated storage reaches не более 100Мб. Что вообще означает эта цифра, если итог настолько отличается от заданных параметров? Andy_OLAPКак уменьшить - удалить все, в чем не разбираетесь, и заказать экспертизу со стороны, чтобы Вам помогли в первый раз сделать агрегаты правильно, а потом Вы и самостоятельно научитесь. К сожалению, на данный момент нужно справляться собственными силами. Может есть какие-то параметры для сжатия агрегата? Те же нулевые значения там хранятся или нет? Может параметр Slice на партиции может как-то повлиять на итоговый размер? Ещё заметил, пытаясь разными способами строить агрегат, что иногда на выходе формируется два файла agg.rigid.data и agg.flex.data, а иногда только один, по объёму равный сумме обоих. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2018, 10:07 |
|
||
|
Aggregations в SSAS
|
|||
|---|---|---|---|
|
#18+
veery_good, 36 тысяч дат???? - 100 лет? причем всего 10 месячных партиций. не ставьте агрегат на листовом уровне измерения Дата. да и вообще, забудьте об агрегатах, хотя бы на время - разберитесь с датами. если только одна дата в партиции, значит ли что каждая строка факта тоже имеет одну и ту же дату? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2018, 10:42 |
|
||
|
Aggregations в SSAS
|
|||
|---|---|---|---|
|
#18+
ShIgor36 тысяч дат???? - 100 лет? причем всего 10 месячных партиций. Есть универсальное измерение с датами и там даты с 1950 по 2050 год. В кубе оно используется. При работе с кубом, если вывести какую-нибудь меру в строки по датам, то там, конечно будут только 10 дат. Я просто предполагал, что может быть при построении агрегата и незначащие даты как-то участвуют и занимают лишнее место. Но сегодня попробовал построить агрегат по измерению, имеющему только два значения "Да" и "Нет". Только по нему и больше не почему. И у меня вышло, что файл agg.rigid.data занимает 4,2 Гб, при размере файла с фактом fact.data 2,5Гб. Так что мое предположение на счёт дат скорее всего не верное и дело в чём-то другом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2018, 11:05 |
|
||
|
Aggregations в SSAS
|
|||
|---|---|---|---|
|
#18+
veery_good, где-то я уже это видел. версия SSAS какая? была проблема в очистке этих файлов. помогал Process Clear и Process Full. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2018, 12:35 |
|
||
|
Aggregations в SSAS
|
|||
|---|---|---|---|
|
#18+
1) поменяй все меры в группе на то что идёт по умолчанию (если убеждения позволяют) 2) убедись что в измерениях связанных с этой группой мер нет атрибутов с изменённым default_member 3) после сноса всех дизайнов агрегаций - в ручную установи только те атрибуты на гранулярности которых тестируешь (у тебя нужных всего 2 насколько видно). 4) отпроцесь (в т.ч. индексы естественно) и смотри в Profiler на свой MDX запрос - должно быть "get data from ... aggregation" вместо "..from ... partition", проверь размер агрегаций (по отношению к размерам партиций), в партициях в запрос можешь ещё OrderBy добавить - там компрессия неплохо срабатывает если туда кардинальность правильную подобрать потом добавь обратно null processing = Preserve и сравни результат. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2018, 12:50 |
|
||
|
Aggregations в SSAS
|
|||
|---|---|---|---|
|
#18+
ShIgorверсия SSAS какая? Версия 14.0.1016.259 vikkiv1) поменяй все меры в группе на то что идёт по умолчанию (если убеждения позволяют) 2) убедись что в измерениях связанных с этой группой мер нет атрибутов с изменённым default_member 3) после сноса всех дизайнов агрегаций - в ручную установи только те атрибуты на гранулярности которых тестируешь (у тебя нужных всего 2 насколько видно). 4) отпроцесь (в т.ч. индексы естественно) и смотри в Profiler на свой MDX запрос - должно быть "get data from ... aggregation" вместо "..from ... partition", проверь размер агрегаций (по отношению к размерам партиций), в партициях в запрос можешь ещё OrderBy добавить - там компрессия неплохо срабатывает если туда кардинальность правильную подобрать потом добавь обратно null processing = Preserve и сравни результат. Спасибо, попробую. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2018, 17:11 |
|
||
|
Aggregations в SSAS
|
|||
|---|---|---|---|
|
#18+
veery_goodНе дописал. Имел ввиду, что в Design Aggregations я ограничиваю Estimated storage reaches не более 100Мб. Что вообще означает эта цифра, если итог настолько отличается от заданных параметров? Design Aggregations придумали не для Вас как разработчика, а для маркетологов, которые стремятся вытеснить oracle из сознания заказчиков, а для этого говорят - в нашей линейке продуктов все просто, вот как в SSMS легко работать с SQL базой, вот как в SSDT легко делать OLAP кубы, вот как в типовом дизайнере можно выбрать несколько вариантов агрегации "одной левой" - и все таки будет летать. Не верьте. В том числе документации. Делайте все лично или не делайте вообще никаких схем агрегации. Вам правильно расписали - "3) после сноса всех дизайнов агрегаций - в ручную установи только те атрибуты на гранулярности которых тестируешь (у тебя нужных всего 2 насколько видно)." Если у Вас привязка фактов на уровне месяца, а Вы создаете несколько вариантов, где будет агрегат из измерения даты на уровне недели или дня недели - то OLAP молча построит такие служебные файлы размером в несколько раз больше от исходного, но будет использовать только исходный, ни один из пользователей кубов - в доброй памяти и трезвом рассудке - никогда не построит распределение продаж месяца по дням недели, там будет одинаковая цифра на каждый из дней недели, понимаете? И схема будет - только смысла в ней ровно 0%. Поэтому схема прикручивается исключительно вручную, когда БЕЗ нее ну никак. А это "никак" определяется по анализу того, какие запросы в куб отправляют пользователи. Вполне может получиться, что Вы по ТЗ составили куб из 100 групп мер с 1000 показателями и 200 измерениям - а пользователи ежедневно строят отчеты по 10 мерам и 2-3 измерениям, а остальное - лежит в документации, которую никто не читает. Нужно отталкиваться не от того, что Вы в куб запихали, потому что кто-то сказал "а и это тоже нужно будет", а от того, что реально используется в жизни... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2018, 17:25 |
|
||
|
Aggregations в SSAS
|
|||
|---|---|---|---|
|
#18+
veery_good, Установите плагин для студии BIDS Helper, с которым удобнее работать с дизайном агрегаций ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2018, 17:54 |
|
||
|
Aggregations в SSAS
|
|||
|---|---|---|---|
|
#18+
Если у Вас измерения с натуральными иерархиями и соотношение количества элементов между мемберами иерархии в несколько раз и агрегаты построены по популярным комбинациям мемберов (но нет избыточных агрегатов), то скорость сказывается на вращении куба Только что снова видел презентацию куба, где измерения из одного атрибута. Измерения "Страны", "Города"... позорище ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2018, 18:12 |
|
||
|
Aggregations в SSAS
|
|||
|---|---|---|---|
|
#18+
Alex_496Если у Вас измерения с натуральными иерархиями и соотношение количества элементов между мемберами иерархии в несколько раз и агрегаты построены по популярным комбинациям мемберов (но нет избыточных агрегатов), то скорость сказывается на вращении куба Только что снова видел презентацию куба, где измерения из одного атрибута. Измерения "Страны", "Города"... позорище Вы бы предпочли сделать измерение "Города" с неключевым атрибутом "Страны". Понимаю. А затем возникнет новая группа мер, где будут планы продаж по менеджерам, которые работают на несколько стран региона. И многие-ко-многим можно будет прикрутить к перечню стран, но не к городам. И тут выяснится, что или придется заводить фиктивный город на каждую страну в измерение, или делать отдельное измерение из стран. Потому что проще прикрутить slicers в Excel сразу из измерения "Страны", даже если там всего лишь один ключевой атрибут. Плюс не забывайте о молодежи, которая привыкает все мышкой в PowerBI строить. Им проще сразу найти "Страны". В общем, не все так очевидно. С точки зрения разработчика - таки да. С точки зрения пользователя куба, который примерно представляет, что еще потом будет в него добавляться - иногда проще сделать так, чтобы самый тупой пользователь строил отчеты самостоятельно, а не дергал Вас на каждый чих. Вы слишком много сидели в банках, где все кошерно, по документации, и все читают регламенты и прочие бумаги. В других местах обычно человек берет в руки Excel и начинает "крутить" куб без какого-либо чтения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2018, 18:20 |
|
||
|
Aggregations в SSAS
|
|||
|---|---|---|---|
|
#18+
Andy_OLAPAlex_496Если у Вас измерения с натуральными иерархиями и соотношение количества элементов между мемберами иерархии в несколько раз и агрегаты построены по популярным комбинациям мемберов (но нет избыточных агрегатов), то скорость сказывается на вращении куба Только что снова видел презентацию куба, где измерения из одного атрибута. Измерения "Страны", "Города"... позорище Вы бы предпочли сделать измерение "Города" с неключевым атрибутом "Страны". Понимаю. А затем возникнет новая группа мер, где будут планы продаж по менеджерам, которые работают на несколько стран региона. И многие-ко-многим можно будет прикрутить к перечню стран, но не к городам. И тут выяснится, что или придется заводить фиктивный город на каждую страну в измерение, или делать отдельное измерение из стран. Потому что проще прикрутить slicers в Excel сразу из измерения "Страны", даже если там всего лишь один ключевой атрибут. Плюс не забывайте о молодежи, которая привыкает все мышкой в PowerBI строить. Им проще сразу найти "Страны". В общем, не все так очевидно. С точки зрения разработчика - таки да. С точки зрения пользователя куба, который примерно представляет, что еще потом будет в него добавляться - иногда проще сделать так, чтобы самый тупой пользователь строил отчеты самостоятельно, а не дергал Вас на каждый чих. Вы слишком много сидели в банках, где все кошерно, по документации, и все читают регламенты и прочие бумаги. В других местах обычно человек берет в руки Excel и начинает "крутить" куб без какого-либо чтения. И P&L и ДДС делали совместно с начальником планового отдела по данным 1С и это не в банке. Иерархии Заказчику очень понравились, приходилось отговаривать от ненатуральных иерархий. А вот в процессе анализа при верчении куба можно налететь на случай, когда при отсутствии иерархии по фактовым ключам Минск будет в Беларуси и окажется в Азербайджане. Не заметив последнего пользователь будет смотреть на РБ Минск и сделает искаженные выводы. Натуральные иерархии имеют и ряд других преимуществ. Slicers прикручивали. ---- В банках не кошерно, там кровавые аджайлы на всю голову ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.10.2018, 21:17 |
|
||
|
Aggregations в SSAS
|
|||
|---|---|---|---|
|
#18+
Alex_496---- В банках не кошерно, там кровавые аджайлы на всю голову Посмотрел еще раз Ваши статьи , не нашел ничего, что было бы про agile. Вы поделитесь когда-либо своими cool stories? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2018, 16:00 |
|
||
|
Aggregations в SSAS
|
|||
|---|---|---|---|
|
#18+
Andy_OLAPAlex_496---- В банках не кошерно, там кровавые аджайлы на всю голову Посмотрел еще раз Ваши статьи , не нашел ничего, что было бы про agile. Вы поделитесь когда-либо своими cool stories? Лучше про что-нибудь полезное напишу, как время будет. А за stories можно сходить, поработать годик-другой, посмотреть изнутри. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.10.2018, 16:52 |
|
||
|
Aggregations в SSAS
|
|||
|---|---|---|---|
|
#18+
Alex_496А за stories можно сходить, поработать годик-другой, посмотреть изнутри. Вы имеете в виду купить свой банк и поработать в нем пару лет, чтобы посмотреть изнутри, как это? Нет, мне уже в таком возрасте нельзя на такой нервной работе, и так бессонница мучает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 06.10.2018, 00:16 |
|
||
|
|

start [/forum/topic.php?fid=49&msg=39712815&tid=1857756]: |
0ms |
get settings: |
11ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
166ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
53ms |
get tp. blocked users: |
2ms |
| others: | 238ms |
| total: | 505ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...