Как стать автором
Обновить

Комментарии 2

  1. Это конечно убиться на DAX'е всё запихать в вычислемую меру чтобы на каждый клик юзера делать пересчет ресурсоемких (в сравнении с простыми агрегациями) статистик. Если настолько "термины в ней истолкованы достаточно вольно " что не было проверки на нормальность распрделения / t-распрделения, то проще было не городить многоэтажной формулы, а подставлять в if какой-нибудь PERCENTILE.EXC на уровне 99% - меньше жрать ресурсов, код читать сильно проще и примерно те же градации цвета на выходе.

  2. А еще проще - прологарифмировать вашу переменную и ее отправить в цветовые градации, а в tooltips - отражать исходные факты.

Ох, да, пока писал меру, ощущения были именно такие)

1. "Нормальность" распределения видна на графиках, поэтому решил о ней даже не упоминать) Фактически, для распределения, отличного от нормального, больше подойдет второй способ, описанный в статье. Но необходимость использования этого способа, на мой взгляд, возникнет только при мультимодальном распределении, а это - не наш случай.

2. По поводу "жора" ресурсов. Сейчас пощелкал фильтрами, включив анализатор производительности. Получилось, что мера на карте пересчитывается за 1619 мс., в то время, как простой CALCULATE( SUM(), FILTER()) в соседней матрице, отрабатывает за 1517 мс. Разница небольшая. Хотя, я уверен, что всегда можно ускорить имеющийся расчет, было бы время)

3. Вариант с 99-м перцентилем, нам, к сожалению, не подойдет, так как его значение = 5334, что позволяет отбросить лишь наблюдения по Москве, но пропускает Московскую область и Санкт-Петербург. Конечно, можно подобрать то значение, которое подойдет для наших целей, но где гарантия, что его не нужно будет корректировать, спустя какое-то время. Мы же хотели максимально автоматизировать расчет. А вот про использование логарифмической шкалы - очень интересная идея, спасибо! Обязательно попробую и напишу апдэйт по результатам.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории