Семантический слой: сравнение

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

Разберём четыре категории семантического стека и девять инструментов, которые реально стоит рассматривать в 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    model: ref('orders')    entities:      - name: order_id        type: primary      - name: user_id        type: foreign    dimensions:      - name: created_at        type: time    measures:      - name: amount        agg: sum      - name: refund        agg: sum metrics:  - name: net_revenue    type: expression    label: Чистая выручка    expression: amount - refund

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

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

Cube

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

Пример модели в 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: 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 нужен дополнительный слой интеграции.

Подписывайтесь на наш telegram канал

Встроенные в 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-прайс.

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

Инструмент	Категория	Кому подходит	API для ИИ	OSI	Привязка
dbt Semantic Layer	Чистый	dbt-команды	SQL, JDBC, GraphQL, MCP	Да	dbt Cloud
Cube	Чистый (headless)	Встраиваемая аналитика, ИИ	SQL, REST, GraphQL, MDX	Да	Нет
AtScale	Чистый (enterprise)	Большие BI-стеки, OLAP-наследие	SQL, MDX, REST, Python	Да	Нет
Snowflake Semantic Views	В хранилище	Snowflake-команды, Cortex Analyst	SQL, Cortex	Да	Snowflake
Databricks Metric Views	В хранилище	Databricks-команды, Genie	SQL, Genie	Частично	Databricks
Looker / LookML	BI-native	Google Cloud, Gemini	SQL, Looker API	Частично	Looker
GoodData	BI-native	SaaS, встраивание	REST, GoodData Cloud	Частично	GoodData
MicroStrategy ONE	BI-native	Fortune 500, наследие	SQL, MicroStrategy API	Нет	MicroStrategy
Atlan	Контекстный	ИИ-агенты поверх слоёв	MCP, REST	Да	Поверх слоёв

Регистрируйтесь в SubQuery

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

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

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

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

Итог

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

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