Витрина данных отделяет определения показателей от экранов: семантический слой дописывают агенты

Одна таблица ещё не означает один показатель. Если в одном отчёте «продажи» считают по созданным заказам, а в другом по оплатам, подключение к общей базе сохранит расхождение.

Витрина данных собирает подготовленные данные под задачу отдела или бизнеса. IBM описывает её как часть данных по определённой теме. Для ИТ-директора это, например, платежи и возвраты, уже приведённые к согласованным полям.

Семантический слой хранит правила расчёта поверх этих данных. dbt выносит определения показателей из BI в модели проекта; Cube даёт BI-клиентам SQL-интерфейс к своей модели. Экрану остаётся запросить показатель с нужными фильтрами.

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

Для примера возьмём «Чистые поступления». Считаем успешные платежи минус возвраты по дате каждого события. Это учебное определение, а не бухгалтерская выручка: признание выручки потребовало бы другого определения.

Возврат может уменьшать день возврата или пересчитывать день продажи. Обе модели встречаются в задачах бизнеса, но выбирать одну должен владелец показателя. Агенту нельзя поручать молча угадать её по названию столбца.

Начать можно с одного спорного показателя. Когда бизнес согласовал его смысл и контрольный пример, агент переносит определение в код, а остальные отчёты подключаются к принятому расчёту.

Агентам подходит работа с уже выбранными правилами. Они могут найти копии формулы, сопоставить поля, подготовить общую модель и проверки. Инженер ведёт машину агентов и проверяет, что перенос сохранил согласованный смысл.

Задача должна называть результат приёмки. В постановке задачи агенту это важнее длины описания: перенести один показатель и показать совпадение контрольных запросов в каждом клиенте.

Автоматический перенос не разрешает спор между отделами. Если маркетинг считает заказ по заявке, а финансы по оплате, нужно согласовать два названия и две формулы. Один общий файл не сделает разные задачи одинаковыми.

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

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

Контрольный набор должен содержать неудобные события. Ниже данные придуманы редакцией: платёж перед полуночью, возврат на следующий день, ещё один платёж и отмена без оплаты. Все часы указаны по МСК.

В этом наборе день возврата получает отрицательное событие, а отмена не влияет на поступления. Если BI показывает иной ответ, команда сначала сверяет контракт, параметры запроса и свежесть данных; внешний вид графика проверяется после расчёта.

Дальше повторите запрос по дням и регионам, с возвратом и без него. Добавьте к заказу несколько товарных строк: платёж должен остаться прежним. Так проверяется детализация данных, о которой Microsoft пишет в рекомендациях к таблицам фактов.

Правильная формула не синхронизирует обновление экранов. Один BI может запросить свежие данные, другой показать сохранённую копию. Вместе с ответом нужны время обновления и версия определения.

Совместимость проверяют на своём способе подключения. Cube поддерживает SQL API по протоколу PostgreSQL, но список поддержанных команд задан отдельно. Само наличие знакомого протокола ещё не доказывает, что конкретный отчёт использует общие показатели без локальных подмен.

Права пользователя тоже входят в проверку. Cube описывает ограничения строк по проверенному контексту пользователя. В вашей системе нужно подтвердить, что тот же принцип действует и через BI, и через экспорт, а фильтр не существует только на экране.

Наш опыт полезен здесь устройством общего расчёта. На сайте агенты переносили повторяющиеся правила в одно место и добавляли проверки. Один из таких эпизодов разобран и в статье про погашение технического долга.

У общего расчёта должна быть общая база сравнения. На /open подписи зон описывают карту с 2 июля 2026, а герой считает коммиты с 1 июля 2026. На снимке 8 октября их суммы различались; дата начала сама по себе не объясняет весь разрыв без истории обновления срезов.

Слова «единый источник» тоже требуют проверки. В нашей истории денег общий расчёт уже принят, а собственная таблица конверсии в инвентаре 7 октября ещё была в работе. Последнюю нельзя выдавать за готовый кейс клиентской витрины.

Для витрины из этих эпизодов следует условие сдачи. Изменение определения должно менять общий расчёт, проходить контрольные запросы и оставлять видимую версию. Копировать новую формулу во все экраны вручную означало бы вернуть причину расхождения.

Заказывать стоит один законченный перенос. Выберите показатель, по которому уже спорят отчёты, назовите его владельца и перечислите BI-клиенты. Сдача включает согласованное определение, изменения в репозитории и протокол контрольных запросов.

Существующий отчёт помогает восстановить поведение, но не становится истиной автоматически. Если бизнес подтвердил различия старых формул, новый слой должен сохранить их под разными именами. Если обнаружена ошибка, её исправление согласуют отдельно от переноса.

Работу можно вести своей командой или отдать инженеру с машиной агентов. На странице подписки на разработку тариф «Один проект» стоит 250 000 ₽ в месяц на 8 октября 2026: одна задача в работе, изменения в вашей ветке вашего репозитория, пауза в любой месяц.

В такой задаче инженер выделяет согласованный семантический слой и описывает контракт для BI-клиентов. Выбор новой архитектуры и спор о смысле показателя остаются за вашей командой; подписка даёт исполнение принятого решения.

Для обсуждения задачи откройте вход для руководителя с перечнем показателей и BI-клиентов. Этот адрес сейчас перенаправляет на страницу услуги.

1. Разделяйте подготовку данных и определение показателей: новая витрина сама не устраняет копии формул.

2. До переноса согласуйте контракт: событие, формулу, период, единицу, разрезы и владельца смысла.

3. Поручайте агентам исполнение и проверки, а решения о смысле принимайте с бизнесом.

4. Принимайте каждый BI на контрольных запросах, включая возврат, границу суток и соединение с деталями.

5. Проверяйте свежесть, права и версию вместе с числом; превращайте каждое расхождение в исправление и постоянную проверку.