|
Действия ...
Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
|
10.09.2019, 10:57
|
|||
|---|---|---|---|
|
|||
Оптимизация distinct count мер |
|||
|
#18+
Перечитав все, что можно найти по distinct count оптимизации в многомерном кубе MS SSAS, прихожу к мнению, что единственный вариант в случае, если атрибут попавший под distinct count имеет слишком большое число исходных строк с учетом нужных агрегаций, - это предрассчитанные факты. Но таких фактов, спасибо пытливым умам заказчиков, получается множество... Встает вопрос, можно ли как-то вывести нужный предрасчитаный факт в зависимости от накиданных пользователем полей в сводной? То есть, например: пользователь выбрал "Уникальное число магазинов", с продажами Товар-Месяц и видит нужный факт, или пользователь выбрал "Уникальное число магазинов", с продажами Бренд_товара-Месяц и видит нужный факт... (Таких разрезов может быть до нескольких десятков и пользователю неудобно выбирать нужный факт самостоятельно и может ошибиться). Может кто-то знает, как это сделать в вычислении у куба? (Вычисление для вывод нужного факта в зависимости от гранулярности сводной по измерениям...) Проблема очень распространенная, как я понял. Увы пока решения нет.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
10.09.2019, 15:53
|
|||
|---|---|---|---|
Оптимизация distinct count мер |
|||
|
#18+
DreamTheme, Оно? https://www.mssqltips.com/sqlservertip/2491/enabling-drillthrough-in-analysis-services/ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
11.09.2019, 09:13
|
|||
|---|---|---|---|
|
|||
Оптимизация distinct count мер |
|||
|
#18+
Да, тоже поможет для части случаев. Но изначально идея была наиболее частые запросы пользователей к тяжелому факту с distinct count (около 200 млн строк) создать в виде готовых таблиц. Т.е. изначально Товар-Магазин-Месяц, и добавить Регион-Бренд товара-Месяц и около 10 прочих вариаций. Затем создать вычисляемое выражение, которое при его вытягивании на сводную в Excel неким образом смотрит на текущую гранулярность по всем измерениям и выбирает для отображения соответствующий факт, а если такого нет, то выводит исходную тяжелую меру. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
11.09.2019, 09:41
|
|||
|---|---|---|---|
|
|||
Оптимизация distinct count мер |
|||
|
#18+
DreamTheme, в любом случае фильтр + sum отработают быстрее чем Distinct Count. Что если ввести поле "выручка за день" и по ней считать сумму по примененным фильтрам - бренд / категория / регион и т.д.? С Уважением, Георгий ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
11.09.2019, 17:41
|
|||
|---|---|---|---|
|
|||
Оптимизация distinct count мер |
|||
|
#18+
George Nordic, я рассчитываю [Уникальное число магазинов]. Исходных данных Магазин-Товар-Месяц около 200 млн. и горизонт будет все увеличиваться. Пользователям, конечно, не нравится, когда они смотрят [Уникальное число магазинов] в разрезе Регион-Товар-Месяц, что эти 300 тыс. строк выгружаются очень долго. Причина понятна, distinct count всех магазинов внутри каждого сочетания Регион-Товар-Месяц, с учетом, что в одном регионе может быть несколько тысяч магазинов. И из-за того, что измерение магазинов имеет самое большое число элементов листового уровня (магазины) любые агрегации не значительно уменьшают выборку для distinct count( Но пользователи не хотят, чтобы нужно было выбирать нужный факт из предрасчитанных разрезов. Тем более, что их может получиться несколько сотен, если пытаться покрыть все запросы.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
12.09.2019, 10:06
|
|||
|---|---|---|---|
|
|||
Оптимизация distinct count мер |
|||
|
#18+
DreamTheme, а что мешает сделать, например, 4 отдельных поля, сумма, флаг 1 если сумма 0, остаток в шт, флаг 1 если остаток 0 по Магазин-Товар-День? Таким образом, если мы хотим видеть магазины где не было продаж, или остаток был ноль - мы просто ставим фильтр по ненулевым и получаем выборку. Или ставим фильтр "магазин-месяц" и считаем сумму по "сумма" или "остаток". Идея понятна? Отпишите georgend@mail.ru, помогу - данная задача очень типовая. С Уважением, Георгий ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
18.09.2019, 16:43
|
|||
|---|---|---|---|
Оптимизация distinct count мер |
|||
|
#18+
DreamTheme, Рассмотрите ROLAP на исходную БД с колумстором. На Вертике должно быть круто, но и на MSSQL тоже должно рулить с 2016. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.09.2019, 11:01
|
|||
|---|---|---|---|
Оптимизация distinct count мер |
|||
|
#18+
DreamTheme, у вас фактов 200млн в мес? я просто проверил на своих данных и немного в другом разрезе, но по сути ничего не меняет: >220 млн строк исходных данных 4млн значений атрибута (аналог ваших магазинов), по которому будем считать DC результирующая матрица 7000x120=840тыс вычислений DC в кубе агрегатов нет от слова вообще, до уровня единственного факта спуститься не проблема. измерений около 30, всего атрибутов около 200 первый расчет полторы минуты (но куб в продакшене и добавляются новые данные каждые 2 минуты, мог попасть на ожидание обработки) последующие срезы, выборки, сортировки - не больше 10 сек. каждая замена одного измерения (7000 строк) другим (4500 строк) - минута, дальше опять без проблем (видимо насчитывает необходимые агрегаты) добавление в запрос других не DC мер - 5-30 сек. в зависимости от функции агрегации по железу, 2xXeon e5-2643 (10 логических процов на SSAS, 6 на SQL, 2 на остальное), 128Gb RAM (напополам с SQL) , в SSAS кроме этой базы еще 2 десятка баз из которых половина с такими же характеристиками и нагрузкой. за 1000 сек интервал: SSAS Avg Current connection = 55.6, Avg Queries answered/sec = 3.679, Avg Time\query = 565.19 ms ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.09.2019, 15:25
|
|||
|---|---|---|---|
|
|||
Оптимизация distinct count мер |
|||
|
#18+
a_voroninDreamTheme, Рассмотрите ROLAP на исходную БД с колумстором. . а почему не просто Molap + колумстор? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.09.2019, 17:53
|
|||
|---|---|---|---|
Оптимизация distinct count мер |
|||
|
#18+
StarikNavy, а смысл? MOLAP после обработки к исходным данным не обращается. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
19.09.2019, 21:20
|
|||
|---|---|---|---|
Оптимизация distinct count мер |
|||
|
#18+
ShIgorDreamTheme, у вас фактов 200млн в мес? я просто проверил на своих данных и немного в другом разрезе, но по сути ничего не меняет: >220 млн строк исходных данных 4млн значений атрибута (аналог ваших магазинов), по которому будем считать DC результирующая матрица 7000x120=840тыс вычислений DC в кубе агрегатов нет от слова вообще, до уровня единственного факта спуститься не проблема. измерений около 30, всего атрибутов около 200 первый расчет полторы минуты (но куб в продакшене и добавляются новые данные каждые 2 минуты, мог попасть на ожидание обработки) последующие срезы, выборки, сортировки - не больше 10 сек. каждая замена одного измерения (7000 строк) другим (4500 строк) - минута, дальше опять без проблем (видимо насчитывает необходимые агрегаты) добавление в запрос других не DC мер - 5-30 сек. в зависимости от функции агрегации по железу, 2xXeon e5-2643 (10 логических процов на SSAS, 6 на SQL, 2 на остальное), 128Gb RAM (напополам с SQL) , в SSAS кроме этой базы еще 2 десятка баз из которых половина с такими же характеристиками и нагрузкой. за 1000 сек интервал: SSAS Avg Current connection = 55.6, Avg Queries answered/sec = 3.679, Avg Time\query = 565.19 ms Помимо мер измерения вытаскивали? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
20.09.2019, 08:53
|
|||
|---|---|---|---|
Оптимизация distinct count мер |
|||
|
#18+
T87, одной мерой матрицу не получишь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
20.09.2019, 11:55
|
|||
|---|---|---|---|
|
|||
Оптимизация distinct count мер |
|||
|
#18+
Основная проблема в том, что у нас Standard 2014 и ни Columnstore ни многопоточной обработки( ROLAP не поддерживается. Не уверен, но пока не удается что-либо ускорить, хотя данных не так и много. Данные пополняются раз в месяц и сейчас их около 250 млн. строк. Разрез Магазин-Товар-Месяц. Есть измерения для магазинов (около 300 000), товаров (20 000), месяцев (20). И, например, distinct count для вычисления уникального числа Магазинов в разрезе Регион-БрендТовара-Месяц, на холодную, идет около 10 минут. Но есть необходимость расчета и более сложных формул, например Взвешенной дистрибуции (для него нужен факт Магазин-Месяц, привязываемый через многие-ко-многим к основному факту). Поэтому особо тяжелые расчеты (для нашего сервера) думали делать предрасчитанными, но пользователям не удобно выбирать из списка нужный факт, и они ошибаются.. Искали способ, чтобы в вычислении выводился нужный факт в зависимости от того, какие атрибуты набросают в сводной пользователи. Железо: 20 виртуальных процов Intel Xeon X5650 2,67 ГГц, 96 Гб ОЗУ (SSAS + DBE). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
20.09.2019, 12:59
|
|||
|---|---|---|---|
|
|||
Оптимизация distinct count мер |
|||
|
#18+
Так же интересен факт, что при сложных запросах к кубу (выборка через сводную Excel), которые могут висеть около 1-2 часов (часто падая по лимиту для запроса в 2 часа), нагрузка на сервере редко более 30%. Есть подозрение, что несколько не оптимально настроена служба SSAS, либо все дело в SQL Standard 2014 (хорошо хоть x64).. Может есть идеи, что в первую очередь нужно проверить, настройки, вроде, все дефолтные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
20.09.2019, 14:24
|
|||
|---|---|---|---|
Оптимизация distinct count мер |
|||
|
#18+
DreamThemeЕсть измерения для магазинов (около 300 000), товаров (20 000), месяцев (20) если действительно 300 000 магазинов, то обратитесь в премьер-поддержку MS, они крупным клиентам помогают если нет, то выкидывайте из куба закрытые магазины и товары, которые уже не поставляются ваши 20 месяцев ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
20.09.2019, 14:43
|
|||
|---|---|---|---|
|
|||
Оптимизация distinct count мер |
|||
|
#18+
Критик, там магазины просто и торговых представителей есть в том числе) Похоже единственное решение, все же, предрасчет наиболее важных срезов и их использование. Хорошо бы, если через MDX в вычислениях можно было вывести нужный срез (за несколько сек), в зависимости от того, какие атрибуты накидали в сводник. Ну а если такого среза нет, то вывести расчетное DC (и висеть пару часов). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
20.09.2019, 14:50
|
|||
|---|---|---|---|
Оптимизация distinct count мер |
|||
|
#18+
ShIgorStarikNavy, а смысл? MOLAP после обработки к исходным данным не обращается. Потому что MOLAP обращается к копии исходных данных в OLAP БД. А это менее эффективный механизм, чем более современные DISTINCT COUNT на колумнсторе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
20.09.2019, 14:55
|
|||
|---|---|---|---|
Оптимизация distinct count мер |
|||
|
#18+
a_voronin, ответ не в тему речь о MOLAP на columnstore а не о ROLAP ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
20.09.2019, 15:34
|
|||
|---|---|---|---|
Оптимизация distinct count мер |
|||
|
#18+
ShIgora_voronin, ответ не в тему речь о MOLAP на columnstore а не о ROLAP Речь шла об ускорении DISTINCT COUNT. Мое предложение состояло в том, чтобы отказать от MOLAP и сделать ROLAP на исходную БД для DISTINCT COUNT группы мер. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.09.2019, 11:25
|
|||
|---|---|---|---|
|
|||
Оптимизация distinct count мер |
|||
|
#18+
>>а смысл? MOLAP после обработки к исходным данным не обращается a_voroninПотому что MOLAP обращается к копии исходных данных в OLAP БД. А это менее эффективный механизм, чем более современные DISTINCT COUNT на колумнсторе. я наверное туплю, но ведь куда лезет запрос за данными - не зависит от того молап это или ролап. как укажем. т.е. в классическом случаем у нас есть хранилище, куда ЕТЛ заливаеn данные (сооответственно это хранилище мы можем переделать на колумсторе), дальше строим куб с ДистиктКаунтами. в чем приемущество именно РОЛАП - к нижках же пишут что РОЛАП нужен, если у нас надо данные поддерживать в актуальном состоянии ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
23.09.2019, 12:21
|
|||
|---|---|---|---|
Оптимизация distinct count мер |
|||
|
#18+
DreamTheme, в первую очередь заменить сервер. SSAS сродни компьютерным играм с прожорливой графикой. попробуйте погонять современные игры с полными настройками на железе 10летней давности, боюсь что даже топовые видюхи тех лет приведут в удручающее состояние любого. найдите(купите) обычный комп с хорошим процом (4GHz), память DDR4, SSD m.2 c чтением/запись 3000/1000 и тупо протестируйте Ваши запросы на нем. Поверьте, Вашему удивлению не будет предела. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
24.09.2019, 13:32
|
|||
|---|---|---|---|
Оптимизация distinct count мер |
|||
|
#18+
StarikNavy>>а смысл? MOLAP после обработки к исходным данным не обращается a_voroninПотому что MOLAP обращается к копии исходных данных в OLAP БД. А это менее эффективный механизм, чем более современные DISTINCT COUNT на колумнсторе. я наверное туплю, но ведь куда лезет запрос за данными - не зависит от того молап это или ролап. как укажем. т.е. в классическом случаем у нас есть хранилище, куда ЕТЛ заливаеn данные (сооответственно это хранилище мы можем переделать на колумсторе), дальше строим куб с ДистиктКаунтами. в чем приемущество именно РОЛАП - к нижках же пишут что РОЛАП нужен, если у нас надо данные поддерживать в актуальном состоянии Преимущество ROLAP в том, что считать distict count будет не SSAS, а БД, которая может это делать эффективнее. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
24.09.2019, 18:25
|
|||
|---|---|---|---|
|
|||
Оптимизация distinct count мер |
|||
|
#18+
ShIgor, подскажите, а что именно плохо в моей конфигурации? Я думал, что по железу - вполне нормально? И проблема только в Standard редакции сервера (лимиты 64 Гб ОЗУ и по процам...). И из-за отсутствия многопоточности (ограничение редакции) мощность сервера даже не раскроется... >>Железо: 20 виртуальных процов Intel Xeon X5650 2,67 ГГц, 96 Гб ОЗУ (SSAS + DBE). Диск там вроде нормальный, хотя и через сетевой интерфейс вроде. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
26.09.2019, 14:37
|
|||
|---|---|---|---|
|
|||
Оптимизация distinct count мер |
|||
|
#18+
Товарищи, может у кого есть на примете какая-нибудь ссылка на описание оптимальных настроек SSAS службы? Например, многие рекомендуют увеличить размер пакетов для обмена и подобное... Но реально у нас на сервере, кроме соответствующих лимитов на ОЗУ ничего не меняли. И еще включено логирование запросов, но там по умолчанию, - не все запросы. HardMemoryLimit 80 LowMemoryLimit 45 TotalMemoryLimit 75 VertiPaqMemoryLimit 60 Так же актуален вопрос оптимальной конфигурации (см. прошлый пост). Что может быть причиной, что запросы крутятся долго (до двух часов), а загрузка ОЗУ и процов не более 30%? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
27.09.2019, 09:27
|
|||
|---|---|---|---|
|
|||
Оптимизация distinct count мер |
|||
|
#18+
a_voroninStarikNavy>>а смысл? MOLAP после обработки к исходным данным не обращается пропущено... я наверное туплю, но ведь куда лезет запрос за данными - не зависит от того молап это или ролап. как укажем. т.е. в классическом случаем у нас есть хранилище, куда ЕТЛ заливаеn данные (сооответственно это хранилище мы можем переделать на колумсторе), дальше строим куб с ДистиктКаунтами. в чем приемущество именно РОЛАП - к нижках же пишут что РОЛАП нужен, если у нас надо данные поддерживать в актуальном состоянии Преимущество ROLAP в том, что считать distict count будет не SSAS, а БД, которая может это делать эффективнее. Создал тестовую группу мер с фактом в режиме ROLAP (ProactiveCaching=Off). При процессинге она обрабатывалась как обычно. А при попытке вывести ее в сводной идет чтение секций OLAP без обращения к DWH. В чем может быть причина? Похоже не работает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
|
|
|
start [/forum/topic.php?fid=49&mobile=1&tid=1857492]: |
0ms |
get settings: |
11ms |
get forum list: |
15ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
68ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
60ms |
get tp. blocked users: |
2ms |
| others: | 14ms |
| total: | 189ms |
| 0 / 0 |
Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...
