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

К этой статье меня подтолкнула причина донельзя прозаическая. Сижу недавно на брифинге, и прилетает жалоба: сервер отчётов работает из рук вон плохо. Сервер при этом не мой, в орбиту обслуживания он не входил, а тут пришлось вспомнить, как оно всё устроено у SQL Server Reporting Services (SSRS), вспомнить молодость, так сказать. Вспомнил. Заодно собрал то, чего мне самому когда-то не хватало, — и решил, что пора всё это выложить в одну статью.

Сервер отчётов — сервис незаметный, пока кто-нибудь из бизнеса не напишет: «а почему мне со вчерашнего дня не приходит утренняя рассылка». Сидишь, открываешь портал, видишь, что подписка вроде есть, вроде активна, а письма не уходят. Ну и как оно всегда было? Лезешь в логи, а логов нормальных нет, есть только таблица где-то внутри базы, в которую редко кто, кроме DBA, и заглядывал.

Знакомо? Если вы держите SSRS или его старшего брата Power BI Report Server, наверняка знакомо.

Вопросы, на которые SSRS обязан отвечать сам, звучат просто.

Какие рассылки упали этой ночью и по какой причине?

Какие отчёты открывают чаще всего, а какие не открывали полгода? Это обычная статистика использования отчётов, которой в портале нет.

Где сервер реально упирается в ресурсы?

Кто владелец подписки, которая ломается третью неделю подряд?

Штатными средствами ни один из этих ответов не достаётся: портал показывает список объектов, а журнал выполнения лежит таблицей в служебной базе, без графиков поверх. Ниже — как я собрал дашборд в Grafana поверх базы ReportServer и какие грабли попались по дороге.

В одном из проектов мы развернули рабочую версию управленческой аналитики на сервере. Данные приходили из нескольких внутренних систем, часть доступа была организована через API смежной команды, а сверху уже строились витрины и дашборды. Первую версию показали руководству, получили согласование и перешли к дальнейшему развитию.

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

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

Я не считаю эту ситуацию особенностью конкретной BI-системы. В нашем случае использовалась Visiology, но похожий сценарий возможен с Power BI, DataLens, Metabase и практически любым другим продуктом. Причина обычно находится не в одной кнопке и даже не в самой платформе. Проблема в том, что дашборд воспринимают как итог внедрения, хотя на самом деле это только пользовательский интерфейс большого контура.

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

Как ошибка Google AI привела меня к собственному анализатору тренировок

Всё началось с выбора велокомпьютера.

Я сравнивал несколько недорогих вариантов и решил спросить совета у Google AI. В итоге он убедил меня выбрать CYCPLUS M1, рассказав среди прочего, что его можно подключить к компьютеру по USB как Mass Storage. Позже выяснилось, что USB там нужен только для питания, а FIT-файлы приходится получать по Bluetooth.

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

Так появился FIT Visualizer — расширение для VS Code с историей тренировок, автоматической сегментацией поездок и AI, который помнит предыдущие заезды и умеет объяснить, что изменилось.

При этом CYCPLUS M1 оказался только отправной точкой. FIT Visualizer работает с FIT-файлами от разных источников — Garmin, Wahoo, Polar, Suunto, COROS, Bryton, Hammerhead, Sigma и других велокомпьютеров, спортивных часов и тренировочных сервисов.

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

О том, как презентовать дизайн людям, которые не говорят на языке UX и интерфейсов, как реагировать на критику и превращать обсуждение в конструктивный диалог, рассказал Никита Полубояров, тимлид отдела UX/UI студии AkademiaDev.

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

На тот момент я уже работал с Power BI и DataLens, а рабочую версию управленческой аналитики мы развернули на сервере в Visiology. Прототип показали руководству и получили согласование на дальнейшее развитие. То есть на уровне первой демонстрации всё получилось: данные загрузились, дашборды открылись, показатели можно было обсуждать уже не на словах.

Если смотреть только на этот момент, систему можно считать выбранной успешно.

За годы работы с 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 «Салон» — скрывает в себе очень важную и долгожданную фичу: «Алертинг» или, по-нашему, «Оповещения». Мы не стали копировать решение у наших зарубежных коллег, а разработали своё видение этого сервиса.

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