Визуализация данных *

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

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

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

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

Но «похоже на правду» для аналитического отчёта - довольно опасный критерий. Особенно если речь идёт о финансовых показателях.

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

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

Продолжение разбора 24 миллионов оценок из Rate Me: как средняя оценка зависит от возраста оцениваемого, почему мужчины и женщины по-разному реагируют на разницу в возрасте, и проверка мифа о взаимности - щедрых оценщиков не оценивают щедрее. Три графика, полный массив, без сэмплирования.

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

Есть куча песка. Уберем одну песчинку — куча останется кучей. Уберем еще — куча по-прежнему будет кучей. Но если каждый раз убирать по чуть-чуть, то рано или поздно кучу нельзя будет назвать таковой. И, конечно же, границы определения в таком случае сильно размыты. Кто-то мог бы утвердить, что куча начинается от 3 песчинок, но стоит ли такое делать? Не думаю.

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

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

Привет, Хабр!

Меня зовут Илья Петров, я руковожу продуктом Digital Q.Sensor BI в «Диасофт». За последний год я неоднократно слышал одну и ту же фразу от разных команд — и своих, и клиентских: «нам бы сюда буквально пару графиков». И каждый раз внутри у меня загорается тревожная лампочка, потому что я примерно знаю, чем это заканчивается.

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

Чем отличается настоящий аналитический агент от генератора SQL, почему семантический слой важнее размера языковой модели и почему локальная LLM ещё не означает технологическую независимость?

В 2026 году AI‑ассистент или AI‑агент появился едва ли не у каждого российского BI‑вендора. Проблема в том, что одинаковая наклейка «AI» скрывает совершенно разные механизмы: где‑то это чат к данным, где‑то генератор SQL, где‑то помощник разработчика дашбордов, а где‑то — мультиагентная система с оркестратором, отдельными ролями и проверкой результата.

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

Как мы исследовали AI‑агентов

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

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

Видим, что нам необходимо проверять на покрытие именно сущности, а не ветвление, сценарии или код, как это делают, допустим, coverage.py или pytest-cov

Это вторая статья из цикла про прототип Plyra — мой домашний прототип для которого я еще толком не сформулировал класс, но похоже как будто на Smart Knowledge Mesh или по крайней мере фронтенд для него. В первой я рассказывал про существующие проблемы в работе со сложными и запутанными знаниями и то как я пришел к идее прототипа. Здесь я попробую объяснить идею через сравнение с космосом и тому куда в итоге переедет «клубок» запутанности.

Всем привет! Меня зовут Сергей Ронжин, я архитектор CPM/IBP-платформы Optimacros для интегрированного планирования, бюджетирования и бизнес-аналитики. В статье поделюсь своим опытом – расскажу о планировании в FMCG-бизнесе и том, какую цену платят компании, когда допускают ошибки в этом процессе. Чтобы добавить статье пользы, поделюсь практическими советами, как от «планирования ради плана» перейти к «планированию для прибыли». Статья будет полезна моделерам и архитекторам CPM/IBP-решений, а также бизнес-пользователям FMCG-компаний и специалистам по планированию.

Шесть российских RPA‑платформ, более 300 критериев и тысячи страниц документации. В начале исследования мы ожидали увидеть привычный для enterprise‑рынка разрыв между несколькими лидерами и остальными участниками. Вместо этого обнаружили сформировавшееся ядро зрелых платформ, каждая из которых способна работать в крупном корпоративном контуре.

Это не значит, что продукты одинаковы. Наоборот, различия есть, но искать их нужно не в базовом списке функций. Они проявляются в архитектуре, эксплуатации, требованиях к команде, работе с отечественной инфраструктурой, ИИ‑возможностях и полной стоимости владения.

В конце июля июля мы опубликовали исследование «RPA Круг Громова 2026». В этой статье расскажу, как мы его делали, какие гипотезы не подтвердились и на что смотреть заказчику, если пункт «умеет создавать программных роботов» уже ничего не объясняет.

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

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

В Инновационном центре «Безопасный транспорт» при ЦОДД интерактивную отчётность и дашборды создают в BI‑системе «Visiology». Платформа позволяет кастомизировать визуализацию, собирая из различных виджетов полноценные отчёты.

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

Подключите OpenSearch Dashboards к Manticore Search, исследуйте данные в Discover и создавайте визуализации и дашборды в знакомом интерфейсе.

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

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

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

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

Всем привет! С вами снова я, тимлид команды разработки «Графини» Павел Мирошин. Надеюсь, вы успели отдохнуть и не слишком грустите по ушедшему лету. Я вот не успел — трудился над новым релизом. Но оно того стоило.

Этот маленький промежуточный релиз с летним вайбом — 2026H1.1 «Салон» — скрывает в себе очень важную и долгожданную фичу: «Алертинг» или, по-нашему, «Оповещения». Мы не стали копировать решение у наших зарубежных коллег, а разработали своё видение этого сервиса.

Под катом обзор этого функционала, а также рассказ о других обновлениях релиза.

В статье рассматривается архитектурная гипотеза-прототип, предлагающая распределение сущностей по разным слоям и реализацию сквозного связывания между элементами различных canvas-пространств. Через призму теории о: компонентных систем управления контентом (CCMS) и баз знаний нового поколения (LLM-wiki), решая проблему масштабирования визуальных связей в интерфейсах.

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

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

Поэтому я открыл свою самую тяжёлую модель — 22 таблицы, 206 колонок, 86 мер — и прочитал её целиком. Двадцать мер из восьмидесяти шести меняют расчёт в зависимости от того, до какого уровня развернули матрицу: из-за них сверка «итог в итог» после переноса сходится идеально и ничего не доказывает. Шесть производственных договорённостей зашиты прямо в формулы и не описаны больше нигде.

Разбираю, что на самом деле переносится при миграции BI и почему документацию в ландшафте на 800+ отчётов придётся отдавать машине.

Бизнес-вопрос редко звучит как готовая аналитическая задача. Руководитель может спросить: «Какие подразделения требуют внимания?», «Пользуются ли приложением?» или «Почему результат изменился?». В этих формулировках понятен общий интерес, но ещё нет показателей, правил расчёта и структуры будущего отчёта.

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

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

В этой статье разберу сам переход от вопроса к показателям. Без универсального каталога KPI, потому что один и тот же показатель может быть полезен в одном процессе и бесполезен в другом.

Маркетолог прислал мне скрин дашборда и одно слово: «пусто».

На скрине — панель «Количество пришедших по реферальной ссылке за период». Ноль. Под ней — график регистраций. Тоже ноль. Ссылка, по которой он пришёл, вела на дашборд с фильтром по конкретному slug — тому самому, который он неделю крутил в закупке.

Я открыл ту же ссылку, поменял в урле from=now-6h на from=now-30d и увидел 16 регистраций.

Дефолтный интервал в Grafana — 6 часов. У бота ночью в этой гео никого нет. Аналитика работала идеально и показывала абсолютно честный ноль.

Это самая безобидная из историй, которые тут будут. Дальше — про то, как мы строили продуктовую аналитику для Telegram-бота с AI-персонажами на ~300K MAU, ~75 RPS в пике и ~1.5M событий в день: без ClickHouse, без Amplitude, без единой event-таблицы. Двенадцать дашбордов в Grafana поверх боевой MySQL. Три из них какое-то время врали, и это выяснилось не сразу.

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

Статья — не туториал «подключите MySQL к Grafana за 10 шагов». Это разбор того, что происходит, когда продуктовые метрики приходится доставать из схемы, которую проектировали под продукт, а не под аналитику, — и когда по этим метрикам прямо сейчас решают, лить трафик дальше или нет.

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

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

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

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

Но «всё» нельзя использовать как границу проекта. Его сначала нужно разобрать на решения, роли, показатели, источники и сценарии проверки.