На Apache Superset я перенёс один отчёт. Одна таблица, пара графиков, день работы. Это была годовая цель: показать, что умею. Показал. Пользуются при этом по-прежнему исходной версией в Power BI — она никуда не делась и работает.

Перенос в компании идёт всерьёз: есть отделы, где Superset нравится больше, есть коллеги, которые делают на нём кастомные визуалы и публикуют отчёты десятками. И чем ближе отчёт к одной таблице, тем легче он едет. Мои — не такие.

Поэтому я зашёл с другой стороны: не переносить, а сначала понять, что внутри. Открыл свою самую тяжёлую модель.

Отчёт по эффективности производства: 22 таблицы, 206 колонок, 86 мер, самая длинная из которых почти на 3800 символов.

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

Это не невезение с конкретным отчётом. Документация BI устаревает по умолчанию: её пишут обычно один раз, при сдаче, и кладут в ящик вместе с инструкцией к микроволновке, а модель после этого правят каждый месяц и никому об этом не говорят. Я и сам так делал — когда правило надо учесть сегодня, а описывать его некогда, оно уезжает прямо в формулу, и это всегда выигрывает по скорости.

Раз описания нет, при переносе будем сверять цифры — это же самое очевидное, что можно сделать.

Почему обычная сверка тут не подходит

Представим приёмку. Открыли два экрана рядом, старый и новый, выбрали один и тот же месяц. Итог: было 0,87, стало 0,87. Пожали руки, закрыли задачу, пошли пить кофе.

А через неделю приходит мастер смены и говорит, что на его агрегате цифра врёт. Идёте смотреть вместе: итог по цеху по-прежнему сходится идеально, разворачиваете матрицу до блоков оборудования — и получаете расхождение в полтора раза.

Предсказать это можно заранее, не дожидаясь мастера смены.

Дело в том, что сверка «итог в итог» молча опирается на допущение, будто у показателя есть одно правильное значение. В семантической модели это допущение часто неверно. Разберём три примера.

1. Мера, которая считает доступное время, содержит функцию ISINSCOPE.

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

Итог при такой сверке сойдётся почти всегда, потому что верхний уровень — самая простая ветка выражения, и именно её мы и сравниваем.

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

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

3. Третий случай проще и обиднее. На целевой платформе другая гранулярность: витрина собрана по суткам и агрегату, а исходная мера считалась по строкам производства, так что целевого разреза для сверки там просто нет. Сверять нечего.

Во всех трёх случаях цифры ведут себя одинаково: они сходятся или расходятся, но ничего не сообщают о том, что именно считается. Совпадение итогов подтверждает совпадение итогов — и только. Определение показателя при этом остаётся непроверенным, а вся содержательная часть переноса сидит именно в нём.

Дальше — про то, где это определение лежит и почему его так трудно достать.

Что мы на самом деле переносим

На этом месте до меня и дошло, чем я на самом деле занимаюсь.

Читаю модель медленно, с карандашом, и выписываю всё, что из неё узнаю о заводе:

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

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

Поэтому, когда такую меру придётся переносить на другую платформу, работа сведётся к реставрации: восстанавливать давнее решение по его отпечатку в коде, примерно как реставратор восстанавливает замысел по слоям краски. Дашборд и метрики — следы. Переносится логика.

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

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

Ограничение стоит не там, где на него смотрят

Я разделяю подход из «Цели» Голдратта: производительность системы определяется её ограничением, а улучшения вне ограничения на выход системы не влияют.

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

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

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

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

Вопрос, который мне задают чаще всего: а как тогда считать эффект.

Посчитать экономический эффект BI-проекта очень трудно, потому что дашборд ничего не производит сам: он меняет решение человека, а вклад дашборда в это решение от остальных факторов отделяется с большим трудом.

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

Что происходит, когда логики нет

Я видел этот сценарий на разных данных и в разных подразделениях, и он повторяется до деталей.

Сначала пользователи приходят с вопросами, потом с претензиями, а потом перестают приходить вовсе и начинают выгружать данные напрямую из источника, чтобы проверить BI вручную в Excel. Доверие падает быстро, а восстанавливается долго и мучительно.

Когда я разбираю такое расхождение, я почти никогда не начинаю с формул: сначала рисую архитектуру движения данных, потом делаю последовательные срезы от дашборда к витрине и дальше к источнику, нахожу этап, на котором логика расходится, и только после этого чиню причину.

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

Откуда логика берётся правильным путём

У нас в компании внедряется продуктовый подход, я и сам проходил продуктовую лабораторию. Главное, что оттуда осталось у меня в работе, — привычка задавать три вопроса до того, как открыть Power BI.

Какую проблему решает этот дашборд. Какую задачу пользователя он закрывает. Какое решение человек примет, посмотрев на экран.

Когда ответы есть, я проектирую дашборд сверху вниз, без разрывов:

Задача: мастер смены должен понять, где сегодня теряется производительность.
Вопрос экрана: какой агрегат просел относительно плана и почему.
Показатель: ОЭО (общая эффективность оборудования) по агрегатам с разложением на три коэффициента.
Расчёт: определение каждого коэффициента, что входит в знаменатель, какие простои исключаются и на каком основании.
Источник: таблицы, гранулярность, глубина истории, периодичность обновления.
Колонка: имена полей, типы, ключи.

Дойдя до шестого пункта, я сажусь и пишу техническое задание для базистов, и вот эта цепочка переживает любую миграцию: она одинаково работает для Power BI, для Superset и для того, что придёт им на смену лет через пять.

Документация как рабочий слой

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

Значит, документация становится рабочим слоем системы.

Что у меня работает как минимальное описание отчёта:

задача пользователя и решение, которое по дашборду принимается;
показатели: определение, формула, единица, направление «больше — лучше»;
договорённости расчёта: что входит в знаменатель, что исключается, на каком основании;
источники: система, таблица, гранулярность, периодичность обновления;
разграничение доступа: кто какие строки видит;
ограничения и известные допущения.

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

Описать сотни отчётов руками не выйдет ни у кого. Это свойство задачи.

Где я на этом пути

Я разрабатываю инструмент на python в тандеме с корпоративным DeepSeek, который читает выгрузку модели, собирает контекст, задаёт владельцу отчёта вопросы по недостающим смыслам и генерирует черновик документации по шаблону. Пайплайн из двадцати шагов, останавливается там, где нужен человек, и продолжает с места остановки.

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

Доступное время, ч
Что считает: фонд времени агрегата за выбранный период за вычетом плановых остановок.
Зависит от уровня детализации: на уровне цеха и агрегата результат умножается на количество линий, на уровне блока оборудования множитель не применяется. Значения на разных уровнях не сводятся друг к другу арифметически.
Исключения: простой по причине «нет заказа» не вычитается.
Константы в выражении: длительность смены 12 ч; правило односменного режима действует с 01.10 прошлого года. Текущий день считается от начала последней смены до времени обновления данных.
Вопросы владельцу отчёта (в документ не попадут, пока не будет ответа):
— почему простой «нет заказа» не считается потерей; — на каком основании выбрана дата 01.10 и относится ли правило ко всем цехам; — какое решение принимает мастер смены по этому показателю.

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

Через конвейер на реальных данных прошло пять крупных отчётов, самые тяжёлые — 266 и 199 МБ. Разбираются нормально, без плясок с бубном.

Разбирать выгрузку модели можно по-разному. Рабочий формат сейчас — .bim. Рядом держу в работе .pbit с разбором через языковую модель и TMDL: сравниваю варианты по производительности, потому что дешёвый в реализации вариант с плохим результатом мне не нужен, как и наоборот. Параллельно идёт тест на разных версиях корпоративных языковых моделей.

Целевая картина: документацию ведёт ИИ

Последовательность:

Читает. Забирает модель отчёта целиком — таблицы, колонки, меры, связи, роли RLS (Row-Level Security, разграничение доступа по строкам), макет страниц. Модель отчёта — структурированный файл, и машина справляется с ним лучше человека хотя бы потому, что не устаёт на шестидесятой мере.

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

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

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

Граница проходит ровно здесь: машина берёт на себя чтение, распознавание и письмо, человек отвечает за бизнес-задачу и бизнес-смысл. И когда человек однажды уволится, с ним уйдёт его опыт, а определения показателей останутся на месте.

Что упрощается и что усложняется

Отдельно — про сам переход, потому что про него спрашивают чаще, чем про документацию. У нас в рамках импортозамещения выбор пал на Apache Superset. При переходе с Power BI часть работы становится тяжелее, часть — заметно легче, и по моему опыту стороны примерно уравновешиваются.

Тяжелее становится с мерами. Быстро поправить расчёт в Superset не выйдет, так что каждое изменение стоит дороже, чем привычный клик в Power BI. Отсюда следует правило, которое я стараюсь держать: если логика унифицирована и есть чёткое понимание, где и как считается показатель, все расчёты уезжают в источник. Тогда одна правка расходится сразу по всем решениям, которые на нём стоят, и то, что казалось потерей гибкости, оборачивается управляемостью.
Ограничения по визуалу тоже есть, и я перестал считать их бедой. Они честно возвращают всех к дисциплине: заказчик начинает точнее формулировать техническое задание, заранее договариваться о том, какую проблему решает дашборд, и внимательнее относиться к трудовым ресурсам команды. В Power BI можно нарисовать что угодно и как угодно, и именно поэтому там так легко нарисовать то, чем потом никто не пользуется.

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

Возражения, которые я слышу чаще всего

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

«Почему языковая модель, если есть парсер с шаблоном?» Парсер разбирает структуру и отлично с этим справляется, я его и использую как первый шаг. Дальше нужно прочитать выражение и сказать словами, что оно делает, — вот здесь парсер останавливается, а модель работает.

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

«У нас коллеги переносят отчёты десятками, и ничего не ломается». У нас тоже. Что именно едет легко: отчёты, где расчёт простой и умещается в витрину. Ломается на других — там, где в мерах сидят договорённости, о которых знал один человек. Момент, когда очередь дойдёт до них, наступает в любой компании, просто не в первый месяц.

Мой вывод из практики такой

Документация BI устаревает по умолчанию. Разовый документ при сдаче отчёта эту проблему не решает.
Сверяйте определение показателя. Цифра работает индикатором расхождения.
У показателя, зависящего от уровня детализации, эталонного значения нет. Итог с итогом у него сойдётся всегда.
Переносится логика. Дашборд и метрики — её следы. Направление переноса роли не играет.
Ускорение разработки дашбордов идёт мимо ограничения, пока логика не описана.
Экономия времени становится эффектом только вместе с ответом, куда ушло высвобожденное время. Если в ограничение — считайте; если в производство новых дашбордов — это просто более быстрый путь к той же стене.
Проектируйте сверху вниз: задача → вопрос → показатель → расчёт → источник → колонка. Дойдя до колонки, можно писать техническое задание базистам.
Описать сотни отчётов руками не выйдет. Считайте это свойством задачи.

При миграции переносится описанная логика, а всё, что осталось неописанным, вы каждый раз восстанавливаете заново, по коду и по памяти коллег. Отсюда простое следствие: каждый отчёт, логику которого вы описали сегодня, удешевляет не только тот перенос, который у вас впереди. Он удешевляет и следующий — на Superset, на то, что придёт после Superset, и на любую передачу отчёта другому человеку.

Поэтому разбирать модель стоит даже там, где переносить вы пока ничего не собираетесь. Я, собственно, ровно тем и занимаюсь.

Миграция Power BI → Apache Superset: что переносится на самом деле