Looker ломают не запросы, а модель: 6 ошибок, из-за которых дашборды врут

Looker ломают не запросы, а модель: 6 ошибок, из-за которых дашборды врут

Looker берут за “красивый BI”, а потом строят там витрину как в SQL-скрипте: без единого слоя смыслов, без названий метрик и без правил агрегации. Итог предсказуем: один и тот же KPI в разных отчётах считается по-разному.

Главные поломки:
— смешали сырые события и бизнес-метрики в одной Explore;
— не зафиксировали grain, и метрика внезапно дублируется;
— оставили много derived fields вместо одной central metric;
— дали всем доступ к всему, и пользователи начинают собирать “свои истины”.

Что должно быть в нормальной модели: одна сущность — одна гранулярность; KPI описаны в measure, а не в названии графика; join-ы проверены на дубли; фильтры не меняют смысл метрики; для каждой роли есть свой слой — от сырья до готового отчёта.

Что обычно можно убрать: 80% ad hoc полей, лишние dimension groups, дублирующиеся explores и красивые, но бесполезные графики “на всякий случай”. Что добавить: словарь метрик, тесты на дубли после join-ов и список отчётов, которые реально открывают каждый день.

Если Looker начинает спорить сам с собой, проблема почти всегда не в визуализации, а в семантике. Сначала чините модель, потом дашборд.