Обновить

Иллюзия точности метрик: о чем не принято говорить в «высоком обществе» BI-аналитиков

Уровень сложностиСредний
Время на прочтение6 мин
Охват и читатели9.2K
Всего голосов 6: ↑5 и ↓1+5
Комментарии25

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

то что меры бывают аддитивные и неаддитивные известно с 1985 года

Давно известно, ещё с 14 века примерно.

аналитической платформы rapeed

Высокая кухня нейминга, однако :)

- Why do your users look so sad?
- Because we have rapeed them! Several times.

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

по сути, покажите свои sql запросы с подсчетом distinct тогда можно будет и поговорить предметно

У нас нет SQL-запросов. В этом и соль. Как считаются count distinct вживую, можно посмотреть здесь

По сути статьи вопросов нет, так как в ней нет особо полезной информации. Весь текст сводится к двум тезисам:

  • Смотрите-ка, иногда метрики считаются неправильно

  • А вот у нас есть вундервафля, в которой мы считаем правильно. Но как мы это делаем, мы вам не скажем.

Ну как-то так, если честно.

И что не так?

Не так здесь то, что вы не понимаете, что здесь не так

Дык, сказали же - тупо в лоб, в смысле, по сырым данным.

Я имел ввиду, что тут вся статья тупо в лоб рекламная и с, образовательной или инженерной точки зрения, бесполезная. И я бы попросил автора не использовать Habr в качестве аналога VC, ProductHunt и других самопиарных площадок.

Ну не прям вся - напоминание про неаддитивные показатели (и объяснение, почему они такие) всё же имеет практическую ценность, но в целом соглашусь, что статья скорее рекламная, нежели техническая.

Было бы интересно прочитать, как именно неаддитивные показатели считаются "в лоб" на каких-то приличных объёмах. Хотя бы в самых общих чертах, чисто для понимания логики и почему этого не сделали в том же мышкрософте.

О таком не принято говорить только на проектах на которых не знают о валидации показателей :)

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

Их почти всегда можно найти, а зачастую и сами метрики. Любые цифры что перекладываются в дашборд, бизнес наверняка давно считает сам, и там как правило знают где у них считается правильно, а где не совсем. А там и вам подскажут :)

Ну кто считает уникальные значения через SUM в DAX?

DISTINCTCOUNT(Table[CHECK_ID])

СOUNTROWS(VALUES(Table[CHECK_ID]))

, можно еще через GROUPBY, обернутый в SUMX.

Речь шла о расчёте в DAX остатков, а не уникальных значений. Как Вы остатки в DAX посчитаете?
Если же говорить о расчёте уникальных, то он возможен при наличии сырых данных. О чем и речь в статье.

Ошибка 2), а не 3) в вашем списке

да-да, если у аналитика ЕСТЬ сырые данные, он будет DISTINCTCOUNT использовать. Статья про то, и пример про ту ситуацию, когда сырых данных нет. Тогда и SUM, и DISTINCTCOUNT дадут одну и ту же неправильную сумму.

Правильно ли я понимаю что расчеты строятся сразу на сырых данных ?

Всё верно, и только на исходных данных всё рассчитывается непосредственно в момент запроса

Получается вы говорите что etl больше не нужен нужно просто считать на сырах дынных, есть идея почему вообще etl делается если можно его не делать? Ваш движок плохие данные тоже исправляет налету? Или работает на идеальных данных?

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

Теперь стало понятнее, что это не замена ETL, а скорее его дополнение. При этом тесты часто нужны не только после выполнения пайплайна, но и прямо внутри ETL — на разных этапах обработки данных. На практике такие проверки чаще всего реализуются средствами самого ETL и обычно в декларативном виде. То есть SQL напрямую почти не пишут (он создаётся один раз — как и сами тесты), а затем просто указывают, к каким таблицам и какие проверки нужно применять.

Какое отклонение в процентах от рассчитанных показателей? Показывают ли ваши отчёты, где бонусы накрутили и оплатили ими покупки?

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

Публикации