Довольно распространённая история в компаниях, когда разные отделы по-разному считают казалось бы одну и ту же метрику. Если у вас также, и вам надоело тратить время на разборы, кто как считает, то вам нужно изучить Semantic layer По сути semantic layer — это прослойка между сырыми данными и потребителями (BI, ноутбуки, AI-ассистенты), в которой бизнес метрики определяются ровно один раз. Если revenue — это сумма платежей за вычетом фрода и тестовых транзакций, это записывается в коде (обычно YAML или SQL-предикаты), а дальше любой инструмент получает одну и ту же цифру через API

Что это даёт на практике

➖ Одна метрика = одно определение Вместо того чтобы пересчитывать DAU в каждом дашборде отдельно (и получать три разных числа), определяем его один раз — что значит «активный», за какой период, с какими фильтрами. Если определение меняется, правка ровно в одном месте ➖ Версионирование. Бизнес-логика эволюционирует и то, что вчера считалось медийной рекламой, завтра может разделиться на display и video. Semantic layer позволяет привязать определения к датам, так что старые отчёты пересчитываются по старым правилам, новые по новым ➖ Полнота и непротиворечивость

Хороший semantic layer гарантирует, что срезы внутри аспекта покрывают 100% данных и не пересекаются, иначе суммы просто не сойдутся

Как это реализуют

🔘У dbt есть MetricFlow (https://docs.getdbt.com/docs/build/about-metricflow), в нем метрики описываются в YAML-файлах как часть dbt-проекта, версионируются в git, а SQL генерируется автоматически. 🔘Cube (https://cube.dev/) делает то же через REST/GraphQL API, что удобнее для data-приложений 🔘В российских компаниях часто строят похожие вещи in-house — через словари предикатов на SQL/Python, которые можно комбинировать для мультиаспектных срезов: тип контента × модель оплаты × сегмент клиента

Semantic layer как фундамент для GenAI

Semantic layer оказался must have для LLM, потому что без него модель видит колонку amt_ttl_pre_dsc и понятия не имеет, что это gross revenue, а что net revenue в вашей компании — это всегда gross revenue * (1 - discount), она тем более не знает, если вы ей это не объяснили. Так что семантический слой выполняет роль онбординг бадди для LLM и объясняет агентам тот контекст, который живой аналитик впитывает за первые пару месяцев работы Snowflake (https://www.snowflake.com/en/) (это такая облачная БД) в Cortex Analyst (https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst) реализовал ровно этот паттерн: описываешь модель данных в YAML — определения метрик, синонимы, связи между таблицами — и пользователь задаёт вопрос на естественном языке, а LLM генерирует SQL и возвращает ответ Можно встроить в Mattermost/Slack или собственное приложение По факту semantic layer — это тот самый скучный инфраструктурный долг, который десять лет все игнорировали, а теперь без него вашу компанию в будущее могут и не взять...