Когда работаешь с большими языковыми моделями (LLM) и бизнес-аналитикой, один из вечных камней преткновения — как дать людям (особенно не технарям) гибкий доступ к данным, не превратив это в хаос. Strata — попытка отойти от классических BI-инструментов и сделать semantic layer, который не просто оборачивает данные, а активно управляет ими, не давая LLM или пользователю уйти в неверные трактовки.
Я пробовал Strata — разработанную бывшим инженером Netflix, который четыре года ковырялся с self-service для бизнес-пользователей. В этом посте разбираем, как Strata решает проблемы expressiveness и контроля, почему отказ от универсальной BI-совместимости может быть не такой уж плохой идеей и как это вписывается в современные agentic workflows.
Строгие имена и автоматический data blending
Главная фишка Strata — жёсткий контроль имен и семантики. В одном проекте не может быть двух сущностей с одинаковым именем, например, «Revenue». За этим стоит не только порядок, но и автоматический выбор источника данных, если Revenue мапится на несколько таблиц.
Это реально круто, потому что многие semantic layers страдают от неоднозначностей — пользователь запрашивает «Revenue», а система не знает, какую из нескольких версий отдавать. В Strata решается на уровне гранулярности и скорости — если запрос можно отдать в быстрый движок (Druid, ClickHouse), он выберет его, иначе уйдёт в более медленный, но полный источник (например, Trino).
Это значит, что можно свободно смешивать данные из разных domain’ов и источников — Strata сама понимает, где лучше считать. Такой подход идеально работает на практике, когда у тебя есть исторические данные в дешевом хранилище и свежие — в быстрых OLAP системах.
Partition- и aggregate-aware routing: данные работают на тебя
Другой важный момент — aware routing. Strata понимает, какие данные лежат в каких частях, и умеет направлять запросы, чтобы минимизировать время ответа и нагрузку на систему.
На практике это означает, что часто запрашиваемые запросы попадают в быстрый движок, а редкие — не тормозят всю систему. Сложные меры (snapshot, LOD, compound) поддерживаются из коробки, что решает большую часть головной боли с кастомными расчетами.
Если ты работал с Looker или Cube, понимаешь, что там с LOD и snapshot-метриками часто приходится мучиться. Strata даёт возможность создавать кастомные расчеты, которые могут span’ить разные факты и домены, а также работать с когортах. Например, можно создать когорту пользователей и применять её как фильтр к целому запросу или отдельной метрике.
MCP и отказ от классических BI-интеграций
Странное, на первый взгляд, решение — не строить semantic layer для BI-инструментов напрямую. Вместо этого Strata предлагает API и MCP (Multi-Channel Platform) для кастомных сценариев.
На практике это значит, что Strata — не просто еще один слой, к которому цепляется Tableau или Power BI. Это полноценный full stack, с дашбордами, подписками и экспортом в Google Sheets, но управляемый через agentic workflows и интерактивное общение с самим semantic слоем.
Плюс, в условиях растущей роли LLM, Strata умеет «говорить нет» — то есть не разрешать запросы, которые не имеют смысла или не могут быть корректно обработаны, в отличие от многих LLM-ориентированных решений, которые стремятся угодить пользователю любой ценой.
Пример: как Strata обрабатывает запросы с несколькими источниками
Допустим, у вас есть метрика Revenue, которая хранится частично в ClickHouse (быстрый access к последним данным) и частично — в Trino (полная история).
SELECT
date,
sum(Revenue) as total_revenue
FROM
Sales
WHERE
date BETWEEN '2024-01-01' AND '2024-03-31'
GROUP BY
date
Strata автоматически определит, что для указанного диапазона можно использовать ClickHouse, если данные там есть, и переключится на Trino для более старых дат. Это избавляет от необходимости вручную писать сложные UNION-запросы или настраивать ETL.
При этом, если Revenue определена в двух местах, Strata не позволит случайно смешать данные из разных источников без корректного агрегационного контекста.
Кому Strata полезна и где подводные камни
Strata — отличный вариант для компаний, где бизнес-пользователи хотят гибкости, но не готовы разбираться в сложностях данных. Она работает, если у вас разношерстные источники, и нужно быстро переключаться между ними без потери консистентности.
Встроенный MCP и API дают простор для интеграций и agentic workflows, что актуально для AI-driven development. Если вы строите свои приложения вокруг LLM и хотите контролировать, что модель видит и как обрабатывает запросы — Strata может помочь.
Минус — это ранняя бета, не open source и требует понимания Docker для запуска. Также отказ от классических BI-интеграций может обернуться дополнительной работой, если ваша команда привыкла к Tableau или Power BI.
Что попробовать дальше
Если вам близка идея semantic layer с жёстким контролем и поддержкой кастомных вычислений на уровне данных, попробуйте Strata локально через Docker. Особое внимание уделите тому, как Strata справляется с автоматическим выбором источника и проверкой запросов — это редкий случай, когда semantic layer не просто оборачивает данные, а реально понимает их контекст.
Для тех, кто уже строит агентные workflows с LLM, Strata может стать надёжным фильтром и маршрутизатором запросов. Добавьте сюда поддержку когорты и сложных метрик — и получите инструмент, который может реально снизить число «тупых» запросов к вашим данным.
В итоге, Strata — не панацея, но интересный опыт, который стоит изучить тем, кто хочет уйти от бесконтрольного AI coding и получить semantic layer с чувством ответственности за данные.
Попробуй сам: Cursor — AI-редактор для разработчиков.
Источник: https://strata.do/