Зачем Semantic Layer: single source of truth для metrics

В типичной компании метрика «выручка» определена в семи местах: SQL в Tableau, формула в Looker, CASE в Power BI, скрипт в Python notebook аналитика, dashboard в Mode, отчёт в Excel у CFO, и (если повезло) одна корректная версия в dbt-марте.

При следующем quarterly review CEO видит разные числа на разных дашбордах. Начинается hunt — какая формула «правильная». Аналитик тратит неделю, выясняет что один dashboard забыл вычитать refunds, другой добавляет tax. После «победы» формула одинакова в дашбордах сегодня. Через месяц финансовая команда добавит новую коррекцию — и история повторится.

Semantic Layer решает это: одна центральная декларация метрики, к которой обращаются все BI-инструменты, AI-агенты и аналитические скрипты.

Проблема — fragmentation metric definitions

Результаты в quarterly review:

Какое правильное? Скорее всего ни одно. Каждое — частично правильное, по своим определениям.

Это расфокусировка метрик. Знаменитая проблема data-команд.

Semantic Layer как central definition

Все consumers — через Semantic Layer. Метрика decoupled от BI tool. Формула revenue меняется в одном месте, и автоматически обновляется везде.

Что такое Semantic Layer технически

Semantic Layer — это прослойка между warehouse и BI-tools. Состоит из:

1. Metadata declarations (YAML файлы или DSL): описывают модели, dimensions, метрики, отношения.
2. Query engine: при запросе генерирует SQL под warehouse и выполняет.
3. API surface: JDBC, REST, GraphQL, Python SDK — точки входа для consumers.

Концептуально:

Consumer:  "give me revenue by region for Q4 2025"
              ↓
Semantic Layer (MetricFlow / Cube / LightDash):
  - Reads: metric definition `revenue = SUM(amount) - SUM(refunds)`
  - Reads: dimension `region` joined via customer_id -> region_id
  - Reads: time range Q4 2025 (Oct 1 - Dec 31)
  - Generates SQL:
    SELECT region, SUM(amount) - SUM(refunds) AS revenue
    FROM fct_orders o JOIN dim_customers c ON o.customer_id = c.customer_id
    WHERE order_date BETWEEN '2025-10-01' AND '2025-12-31'
    GROUP BY region
              ↓
Warehouse (Snowflake / DuckDB / BigQuery): выполняет SQL
              ↓
Consumer: получает результат

Consumer не пишет SQL. Не знает структуру таблиц. Знает только бизнес-метрики и измерения.

dbt Semantic Layer (MetricFlow)

dbt’s нативное решение — dbt Semantic Layer, основанное на движке MetricFlow (приобретён dbt Labs в 2023, открытый Python пакет).

Декларация в YAML:

# models/semantic_models/sm_orders.yml
semantic_models:
  - name: orders
    model: ref('fct_orders')
    entities:
      - name: order_id
        type: primary
      - name: customer_id
        type: foreign
    dimensions:
      - name: order_date
        type: time
        type_params:
          time_granularity: day
      - name: status
        type: categorical
    measures:
      - name: order_amount
        agg: sum
        expr: amount
      - name: refund_amount
        agg: sum
        expr: refund_amount
      - name: order_count
        agg: count
        expr: order_id

# models/semantic_models/mt_revenue.yml
metrics:
  - name: revenue
    description: "Net revenue: order amount minus refunds"
    type: derived
    type_params:
      expr: "order_amount - refund_amount"
      metrics:
        - name: order_amount
        - name: refund_amount

Это и есть single source of truth для revenue. Tableau, Looker, Python — все ссылаются на этот revenue metric.

dbt SL vs Cube vs LightDash vs AtScale

В рынке 2026 — четыре serious player’а:

В 2026:

• dbt SL становится default выбором для команд уже на dbt. Натуральная extension.
• Cube для headless BI и сложных metric calculations.
• LightDash для команд хочущих lightweight BI поверх dbt.
• AtScale — enterprise legacy.

Когда Semantic Layer нужен

Самый частый trigger — второй BI tool. Команда добавила Power BI рядом с Tableau, формулы разъехались — пора в SL.

Когда Semantic Layer НЕ нужен

Скип SL когда:

• Маленькая команда (менее 10 человек) с одним BI tool. dbt marts + Tableau native achievements достаточно.
• Простые метрики: суммы, count’ы, простые ratio. Один-два DAX или Looker measure покрывают.
• Стартап ранний: метрики ещё в стадии definition. SL добавит rigidity, нужна experimentation.
• Только один consumer: только Python notebook’и, или только один dashboard. Прямой SQL быстрее.

Cost-benefit

Setup cost (dbt SL):

• Декларация semantic_models в YAML: 1-2 недели для команды с 20 моделями.
• Integration с BI tools: 1-2 недели на каждое.
• Education команды (analysts, BI developers): 1 неделя.
• Continuous maintenance: ~10% времени analytics engineer.

Ongoing benefits:

• Метрики единые. Quarterly reviews без споров о цифрах. Бесценно для C-level trust.
• Faster onboarding new BI tool: «вот SL API, остальное вы знаете».
• AI integration: одна строка metric_query(['revenue'], group_by=['region']).
• Reduced BI tool license cost (LookML licenses, etc. — SL может частично заменить).
• Audit trail: все запросы метрик логированы централизованно.

Окупается обычно за 3-6 месяцев в средне-большой команде. В очень маленьких — может никогда.

Что внутри semantic_model

Минимальный пример для дальнейших уроков:

# models/semantic_models/sm_orders.yml
semantic_models:
  - name: orders
    description: "Orders facts table for revenue analytics"
    model: ref('fct_orders')

    entities:
      - name: order_id
        type: primary
      - name: customer_id
        type: foreign

    dimensions:
      - name: order_date
        type: time
        type_params:
          time_granularity: day
      - name: status
        type: categorical
      - name: region
        type: categorical
        expr: region_code

    measures:
      - name: order_amount
        agg: sum
        expr: amount
        agg_time_dimension: order_date

      - name: order_count
        agg: count
        expr: order_id
        agg_time_dimension: order_date

В следующих уроках разберём metrics types, derived и cumulative, saved queries и API.

Попробуй сам

1. Возьмите вашу самую частую метрику. Например — total revenue. Найдите все места, где она используется или определяется:

   • dbt mart?
   • Tableau dashboards?
   • Looker LookML?
   • Excel у бизнеса?
   • Python скрипты?

2. Запросите у каждого consumer’а: «можешь показать SQL/формулу как ты считаешь revenue?».

3. Сравните. Скорее всего найдёте расхождения. Маленькие (один не вычитает refunds) или большие (один считает gross, другой net).

4. Это и есть проблема, которую решает Semantic Layer.

5. Откройте dbt docs для Semantic Layer: https://docs.getdbt.com/docs/build/about-metricflow. Посмотрите концепты.

Бонус: возьмите 2 метрики и спросите бизнес: «эти две метрики могут противоречить друг другу?». Например: «ARR» и «active subscriber revenue». Часто противоречат через definitions. Если да — это red flag, нужен SL.

Ключевые выводы

1. Semantic Layer — central declaration метрик. Decouples определение от BI tool. Решает проблему fragmentation: «revenue определена в 7 местах с 7 формулами».
2. Технически SL = metadata layer + query engine + API. Consumers (BI, AI, Python) запрашивают метрику через API, SL генерирует SQL.
3. dbt Semantic Layer = MetricFlow (acquired by dbt Labs 2023). Native integration с dbt models. YAML decleration.
4. Конкуренты: Cube (mature, headless), LightDash (tight dbt integration, lightweight BI), AtScale (enterprise legacy).
5. Когда нужен: 2+ BI tools, AI/ML consumers, self-service analytics, composite metrics. Когда не нужен: 1 BI tool + 1 team + простые метрики.
6. Cost-benefit окупается обычно за 3-6 месяцев в средне-больших командах через единые метрики и faster BI tool onboarding.
7. semantic_model = декларация entities (keys), dimensions (group by), measures (aggregations). Metrics определены отдельно, ссылаются на measures.