Semantic layer: метрика определяется один раз

К этому моменту вы умеете строить хранилище: слои medallion, модели star schema и OBT, трансформации в dbt. Витрины готовы, аналитик пишет SQL, получает числа. Казалось бы, всё. Но есть проблема, которая возникает именно тогда, когда хранилище уже работает и им пользуются много людей. Эту проблему решает semantic layer (он же metrics layer) — и это одна из самых обсуждаемых тем моделирования 2025-2026.

Проблема такая. «Выручка» (revenue) кажется простым понятием. Но как только три разных человека пишут SQL для «выручки», вы получаете три разных числа. И semantic layer — это слой, где метрика определяется один раз, чтобы все инструменты и все люди получали одно и то же число.

Проблема: одна метрика, три определения

Разберём на примере. Бизнес просит «выручку за апрель». В компании это считают трое.

Аналитик маркетинга пишет:

-- определение revenue #1 (маркетинг)
SELECT SUM(amount) FROM fct_orders
WHERE order_date BETWEEN '2026-04-01' AND '2026-04-30';

Аналитик финансов считает иначе — он вычитает возвраты:

-- определение revenue #2 (финансы): за вычетом возвратов
SELECT SUM(amount) - SUM(refund_amount) FROM fct_orders
WHERE order_date BETWEEN '2026-04-01' AND '2026-04-30';

Аналитик продукта берёт только оплаченные заказы и фильтрует тестовые:

-- определение revenue #3 (продукт): только оплаченные, без тестовых
SELECT SUM(amount) FROM fct_orders
WHERE status = 'paid' AND is_test = false
  AND order_date BETWEEN '2026-04-01' AND '2026-04-30';

Три запроса — три разных числа за один и тот же апрель. На совещании выясняется, что «выручка» у маркетинга 4.2 млн, у финансов 3.9 млн, у продукта 4.0 млн. Дальше час уходит не на решения, а на спор, чья цифра «правильная». Каждый прав в своей логике — но единого определения нет, и доверие к данным падает.

Это не выдуманная ситуация, а типичная боль зрелой аналитики. Чем больше людей и инструментов, тем хуже: определение метрики расползается по сотням SQL-запросов, дашбордов и Excel-файлов, и нигде нет канонической версии.

Решение: определение метрики отдельно от таблиц

Semantic layer разрывает этот хаос. Идея: вынести определение метрики из SQL-запросов в отдельный слой, где оно описано один раз, декларативно. Все инструменты обращаются за метрикой к этому слою — и получают одно число, потому что определение одно.

Метрика в semantic layer описывается обычно в YAML — это объявление, а не запрос:

# определение метрики revenue — единственное на всю компанию
metrics:
  - name: revenue
    label: "Выручка"
    description: "Сумма оплаченных заказов за вычетом возвратов, без тестовых"
    type: simple
    measure: order_amount
    filter: "status = 'paid' AND is_test = false"

  - name: net_revenue
    label: "Чистая выручка"
    type: derived
    expression: "revenue - refunds"

Здесь зафиксировано раз и навсегда: что считаем (order_amount), какой фильтр применяем (status = 'paid', без тестовых), как называется. Спор «чья выручка правильная» закрыт — выручка определена в одном месте, и это место — источник истины для метрики.

Ключевой момент: semantic layer отделяет определение метрики от физических таблиц. Это новый уровень разделения, которого мы ещё не видели. Раньше «модель данных» означала, как устроены таблицы. Semantic layer добавляет слой выше: бизнес-смысл («выручка», «отток», «средний чек») описан отдельно от того, в каких столбцах и таблицах физически лежат данные.

Когда Tableau, Excel и AI-агент запрашивают «revenue», запрос идёт в semantic layer; тот по определению генерирует корректный SQL к витринам и возвращает результат. Изменилось определение выручки — правят одну строку в YAML, и все инструменты автоматически начинают отдавать новое, согласованное число. Это и есть «определить метрику один раз».

Инструменты semantic layer

Semantic layer — не абстрактная идея, у него есть конкретные реализации (по состоянию на 2025-2026):

• dbt Semantic Layer (на движке MetricFlow) — semantic layer, встроенный в dbt: метрики описываются рядом с моделями, в той же кодовой базе.
• Cube — отдельный, независимый от dbt semantic layer; умеет pre-aggregations для ускорения.
• AtScale — semantic layer корпоративного уровня.
• Нативные metric views — Snowflake и Databricks добавили описание метрик в YAML прямо в warehouse.

Архитектурно подходы делятся на несколько типов: warehouse-native (метрики живут в самом warehouse), transformation-layer (метрики рядом с трансформациями, как dbt) и OLAP-acceleration (как Cube с предагрегациями). Детали инструментов вам как джуну знать наизусть не нужно — важно понимать роль слоя: единое определение метрик поверх витрин.

Почему это горячая тема именно сейчас: AI

Semantic layer обсуждался и раньше, но в 2025-2026 интерес резко вырос — и причина в AI-аналитике.

Появились text-to-SQL-инструменты и AI-агенты: пользователь спрашивает «какая была выручка в апреле» обычными словами, а LLM генерирует SQL и отвечает. Удобно — но рискованно. Откуда LLM знает, что выручка считается только по оплаченным заказам и без тестовых? Без semantic layer он этого не знает — он угадывает, сочиняя SQL из названий столбцов. И угадывает по-своему каждый раз: получается четвёртое, непредсказуемое определение «выручки».

Semantic layer решает это радикально. AI-агент не сочиняет SQL для метрики — он запрашивает метрику по имени из semantic layer. Определение «выручки» жёстко зафиксировано человеком в YAML, LLM лишь обращается к нему. Точность AI-аналитики резко растёт: модель не изобретает бизнес-логику, а пользуется готовой и проверенной.

Где semantic layer в общей картине

Соберём место semantic layer среди всего, что вы изучили. Это самый верхний слой аналитического стека:

Нижние слои отвечают на вопрос «как лежат данные». Semantic layer — на вопрос «что они значат для бизнеса». Это финальный уровень разделения ответственности: физическое устройство данных отделено от их бизнес-смысла. В следующем уроке мы подведём итог модуля большой дискуссией — «жив ли Kimball» — и посмотрим на современный консенсус целиком.

Попробуй сам

1. Возьмите метрику «средний чек» (average order value). Напишите два разных SQL-определения, которые дали бы разные числа (например, делить на число заказов или на число клиентов; включать или нет отменённые заказы).
2. Опишите эту метрику в YAML-стиле semantic layer: имя, что считаем, какой фильтр. Зафиксируйте одно каноническое определение.
3. Объясните, что физически произойдёт, когда бизнес решит изменить определение «среднего чека»: сколько мест нужно поправить с semantic layer и сколько — без него (когда метрика зашита в каждый дашборд).
4. Сформулируйте, почему AI-агенту, отвечающему на вопросы о данных, semantic layer нужен сильнее, чем человеку-аналитику.