Какой семантический слой выбрать

Выбирать семантический слой по чек-листу фич — верный способ через год переписывать метрики с нуля. Рынок распался на четыре категории, и инструмент из каждой закрывает свою задачу. Если вы не поймёте разницу заранее, покупка превратится в дорогостоящее недоразумение.

Разберём четыре категории семантического стека и девять инструментов, которые реально стоит рассматривать в 2026 году. Для каждого покажу пример модели, плюсы и минусы, а в конце сведём всё в одну таблицу.

Четыре категории, а не одна

Термин «семантический слой» слишком широк. На практике это четыре разных типа инструментов, и они не взаимозаменяемы.

flowchart TD
  A[Семантический стек] --> B[Чистые семантические слои]
  A --> C[Встроенные в хранилище]
  A --> D[Встроенные в BI]
  A --> E[Контекстный слой]
  B --> B1[dbt Semantic Layer, Cube, AtScale]
  C --> C1[Snowflake Semantic Views, Databricks Metric Views]
  D --> D1[Looker/LookML, GoodData, MicroStrategy]
  E --> E1[Atlan]

• Чистые семантические слои определяют метрики в коде (YAML, SQL или DSL) и отдают их любому инструменту. Лидеры — dbt Semantic Layer, Cube, AtScale.
• Встроенные в хранилище определяют метрики прямо в дата-воркхаусе. Быстро, но привязывают вас к одному вендору: Snowflake Semantic Views или Databricks Metric Views.
• Встроенные в BI живут внутри BI-инструмента и задали сам тренд. Это Looker/LookML, GoodData, MicroStrategy ONE.
• Контекстный слой не считает метрики, а оборачивает их управляемым контекстом для ИИ-агентов. Типичный пример — Atlan.

Ключевая мысль: слой отвечает на вопрос «что значит метрика», а контекстный слой — «как ИИ-агент может этой метрикой пользоваться».

Чистые семантические слои

dbt Semantic Layer (MetricFlow)

Выбор команд, которые уже сидят на dbt. Метрики описываются в версионируемом YAML рядом с моделями, а стандарт Open Semantic Interchange делает определения переносимыми между BI и ИИ-агентами. Под капотом крутится MetricFlow — DSL для измерений, мер, сущностей и временной гранулярности.

Пример определения метрики в YAML:

# metrics/net_revenue.ymlsemantic_models:  - name: orders    # Имя семантической модели    description: |      Данные о заказах. Зерно таблицы — идентификатор заказа, то есть каждая строка — это один заказ.    model: ref('orders') # Модель и схема dbt, на которых строится слой    defaults:      agg_time_dimension: metric_time    entities: # Сущности — это ключи таблицы, по которым можно связывать данные.      - name: order_id        type: primary      - name: customer        type: foreign        expr: customer_id    measures:   # Меры — это агрегации по колонкам, например суммы или количества.      - name: order_total        agg: sum    dimensions: # Измерения бывают категориальными или временными. Они добавляют контекст к метрике, а типичный запрос выглядит как «Метрика по Измерению».      - name: metric_time        expr: cast(ordered_at as date)        type: time        type_params:          time_granularity: day  - name: customers    # Имя второй семантической модели    description: >      Справочник клиентов. Зерно таблицы — одна строка на одного клиента.    model: ref('customers') # Модель и схема dbt, на которых строится слой    defaults:      agg_time_dimension: first_ordered_at    entities: # Сущности — это ключи таблицы, по которым можно связывать данные.      - name: customer        type: primary        expr: customer_id    dimensions: # Измерения бывают категориальными или временными. Они добавляют контекст к метрике, а типичный запрос выглядит как «Метрика по Измерению».      - name: is_new_customer        type: categorical        expr: case when first_ordered_at is not null then true else false end      - name: first_ordered_at        type: time        type_params:          time_granularity: day

Плюсы:

• единый код-фёрст рабочий процесс с трансформациями
• OSI-переносимость
• широчайший набор готовых интеграций с BI (Hex, Mode, Lightdash, Tableau, Power BI)
• MCP-совместимый экспорт для ИИ-агентов.

Минусы:

• во многих конфигурациях нужен dbt Cloud
• определения живут в коде, а не в интерфейсе — аналитикам без инженерного бэкграунда сложнее
• смотреть в UI не получится.

Cube

Головной (headless) слой. Одно определение метрики, четыре API (SQL, REST, GraphQL, MDX), открытое ядро. Идеален, если метрики нужны одновременно BI-инструменту, продуктовому дашборду и ИИ-копайлоту. Движок преагрегаций кэширует запросы и выдаёт ответы за доли секунды.

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

Пример модели в Cube:

# schema/Orders.ymlcubes:  - name: orders    sql: SELECT * FROM orders     measures:      - name: total_amount        sql: amount        type: sum      - name: net_revenue        sql: "amount - refund"        type: sum     dimensions:      - name: user_id        sql: user_id        type: string      - name: created_at        sql: created_at        type: time    joins:      - name: users        relationship: many_to_one        sql: "{orders.user_id} = {users.id}"

Плюсы:

• один источник метрик для BI, встроенной аналитики и ИИ
• четыре API из одного определения
• открытое ядро (Cube Core) плюс управляемый Cube Cloud
• движок преагрегаций для быстрых ответов
• участник OSI.

Минусы:

• инженерная настройка тяжелее, чем у BI-нативных моделей
• экосистема готовых BI-интеграций меньше, чем у dbt SL и Looker
• self-hosted без Cube Cloud требует возни.

AtScale

Корпоративный вариант. Понимает MDX, SQL, DAX, REST и Python, автоматически строит агрегаты под миллиардные таблицы. Выбор компаний с наследием из Excel и OLAP-кубов, которым нужно, чтобы та же метрика работала в Power BI, Tableau, ThoughtSpot и кастомных приложениях.

Пример определения в AtScale (MDX-выражение для меры):

# Выручка по продуктуcube: salesmeasure:  name: Revenue  type: measure  sql: SUM(sales.amount)  format: currency  drill_members:    - [Product].[Product Name]    - [Customer].[Country]

Плюсы:

• MDX + SQL + DAX + REST + Python из одного определения
• автоматическая генерация агрегатов без ручной настройки
• AI-Link отдаёт определения прямо агентам
• зрелые enterprise-безопасность и управление
• участник OSI.

Минусы:

• enterprise-прайс, не для маленьких команд
• настройка самая долгая
• оптимален при наследии OLAP-кубов, для greenfield — избыточен.

Встроенные в хранилище

Snowflake Semantic Views

Если вы уже живёте в одном хранилище, зачем поднимать отдельный сервис? Snowflake Semantic Views определяют метрики прямо в воркхаусе, наследуют права доступа платформы и отдаются нативному ИИ-агенту Cortex Analyst.

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

CREATE OR REPLACE METRIC VIEW sales_metrics ASSELECT  order_month,  SUM(amount) AS revenueFROM ordersGROUP BY order_month;-- Cortex Analyst читает метрику напрямую

Плюсы:

• разворачивается быстрее всех — метрики живут там же, где данные
• нативная работа с Cortex Analyst для text-to-SQL
• ролевой доступ наследуется из Snowflake
• Snowflake — участник OSI.

Минусы:

• жёсткая привязка к Snowflake, определения не переносятся в другой воркхаус
• новее dbt SL и Looker, функциональность ещё допиливается
• при гибридных стеках возникают проблемы перевода между dbt-моделями и снежными.

Databricks Metric Views

Для Databricks-команд аналог снежного варианта: метрики на SQL внутри Lakehouse, потребление через Genie, управление через Unity Catalog.

Пример определения (YAML-схема Metric View):

# metric_views/sales_metrics.yamlmetric_view:  name: sales_metrics  catalog: main  schema: metrics  metrics:    - name: revenue      expression: SUM(amount)  dimensions:    - name: order_month      expression: DATE_TRUNC('month', created_at)

Плюсы:

• метрики консистентны с существующими Lakehouse-рабочими процессами
• нативный Genie-агент; интеграция с Unity Catalog для управления
• YAML/DDL схемы для код-фёрст подхода

Минусы:

• привязка к Databricks
• новее устоявшихся вариантов
• агентам не на Genie нужен дополнительный слой интеграции.

Встроенные в BI

Looker / LookML

Looker (в составе Google Cloud) задал код-фёрст шаблон, который потом скопировали dbt и Cube. LookML — первый язык моделирования, доведённый до продакшена в масштабе. Крепкая связка с Gemini и BigQuery.

Пример модели в LookML:

# orders.view.lkmlview: orders {  dimension: created_at {    type: time    sql: ${TABLE}.created_at ;;  }  measure: revenue {    type: sum    sql: ${amount} ;;  }  measure: net_revenue {    type: sum    sql: ${amount} - ${refund} ;;  }}

Плюсы:

• эталонный код-фёрст семантический слой
• глубокая интеграция с Gemini и оптимизация под BigQuery
• Looker Modeler позволяет шарить определения наружу.

Минусы:

• привязка к Looker, портируемость наружу ограничена
• меньше готовых интеграций, чем у dbt SL.

GoodData

Заточен под встраивание аналитики в чужие продукты. Мультитенантность у него встроена в модель данных: одно определение метрики обслуживает тысячи клиентских тенантов с изоляцией доступа.

Пример модели в GoodData (Logical Data Model):

# LDM для мультитенантного SaaSlogical_data_model:  datasets:    - name: orders      columns:        - name: amount          ldmType: FACT        - name: order_date          ldmType: DATE      references:        - name: tenant          ldmType: REFERENCE          dataset: tenants

Плюсы:

• мультитенантность по умолчанию
• white-label дашборды с изоляцией тенантов
• headless-режим для API-потребления
• частичный OSI.

Минусы:

• нишевый — не общий слой для внутренней аналитики
• история с ИИ-агентами развита слабее, чем у dbt SL или Cube
• экосистема интеграций меньше.

MicroStrategy ONE

Тяжёлая платформа с многолетним наследием для банков, страховщиков и ритейла. Модель данных существует с тех пор, как термин «семантический слой» ещё не придумали.

Пример: метрики задаются в схематической модели, а для встраивания и ИИ используются HyperIntelligence и агент Auto. Кода в классическом смысле тут меньше — это больше про визуальный конструктор и API.

Плюсы:

• десятилетия прод-зрелости
• HyperIntelligence для встраивания контекста в корпоративные приложения
• агент Auto для запросов на естественном языке
• наследие прав доступа и широкие коннекторы.

Минусы:

• самый тяжёлый и долгий цикл внедрения
• готовность к ИИ-агентам отстаёт от Snowflake, Databricks и dbt SL
• нет OSI — риск портируемости.

Контекстный слой

Atlan

Atlan — не семантический слой, а слой над ним. Он читает определения из любых семантических движков, привязывает их к lineage, владельцу, глоссарию и правам доступа, а потом отдаёт этот управляемый контекст ИИ-агентам через MCP-сервер.

Семантический слой отвечает, что значит метрика. Контекстный слой отвечает, кто её утвердил, откуда она и кому её можно показывать. Для агентов это решает проблему доверия к цифре.

flowchart LR
  SL[dbt / Cube / Snowflake] --> SLD[Определения метрик]
  SLD --> ATL[Контекстный слой Atlan]
  ATL --> GOV[Lineage, владелец, глоссарий, доступ]
  GOV --> MCP[MCP-сервер]
  MCP --> AG[ИИ-агент]

Плюсы:

• объединяет управление и lineage поверх нескольких семантических слоёв
• отдаёт контекст агентам через MCP
• связка с слоем поднимает точность ответов в разы по сравнению с работой на одних схемах.

Минусы:

• не заменяет семантический слой — нужен движок под ним
• ценность максимальна при уже существующем слое или каталоге
• enterprise-прайс.

Сравнительная таблица

Как выбирать по своему кейсу

• dbt-команда, стандартизирующая метрики → dbt Semantic Layer. Если не хотите зависеть от dbt Cloud — Cube.
• Встроенная аналитика и ИИ-приложения → Cube: много API, одно определение.
• Один воркхаус, нативный ИИ → Snowflake Semantic Views или Databricks Metric Views.
• Большой enterprise со смешанным BI (Power BI, Excel, Tableau) → AtScale, Cube
• ИИ-агенты поверх нескольких семантических слоёв → контекстный слой поверх выбранного движка.

Не попали в список

Некоторые инструменты называют себя семантическими слоями, но живут в соседних категориях: OLAP-ускорители, оркестраторы агентов и BI с встроенным моделированием. Надёжный тест — спросить, какой семантический слой инструмент потребляет или заменяет. Если ответ «мы и есть слой», а по сути это ускорение запросов или дашборды — это категория-сосед, и использовать её вместо настоящего слоя значит копить интеграционный долг.

Итог

Выбор семантического слоя — это вопрос не «какой круче», а «где живёт ваша бизнес-логика и кто ей пользуется». Чистые слои закрывают BI и ИИ, встроенные в хранилище — скорость и простоту в рамках одного вендора, BI-нативные — глубину внутри одного инструмента, а контекстный слой добавляет то, что нужно ИИ-агентам: управляемость и доверие к цифре.

Главный совет: не давайте контекстному слою или каталогу заменять шаг выбора чистого семантического слоя. Сначала выберите, где считаются метрики, а потом решайте, как ими будут пользоваться агенты.