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

На 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‑контура для организации, где данные о разных направлениях деятельности уже находились в операционных системах и единой базе, но значительная часть отчётности проходила через выгрузки и ручную обработку. Пользователям были нужны сведения об учебных процессах, финансах, задолженностях, движении контингента, нагрузке и других направлениях. На верхнем уровне запрос действительно можно было свести к формулировке: собрать всё в одном месте.

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

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

Мы поговорили с тремя командами, которые используют продукты из экосистемы Инфостарт Маркетплейс в повседневной работе:

В 1С ежедневно накапливаются данные о контрагентах, номенклатуре, остатках, продажах, договорах и сотрудниках. Они нужны не только для учета: руководители используют их в дашбордах, аналитики — в BI-системах, а смежные сервисы — для обмена справочниками и показателями.

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

Искусственный интеллект уже умеет за считанные минуты собирать дашборды, которые выглядят вполне профессионально. Проблема в том, что убедительный интерфейс легко маскирует слабую постановку задачи и сомнительные выводы. В этой статье — эксперимент с тремя промптами для Claude Design и разбор того, где заканчиваются возможности модели и начинается работа аналитика.

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

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

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

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

Я разобрал свежие кейсы OpenAI, Anthropic и Hex: что действительно улучшает ответы, какие очевидные подходы уже провалились, из чего складывается реальная стоимость и как за шесть шагов проверить

Что общего у Бенджамина Франклина, японских пенсионеров и американских зумеров? Всех их спрашивали о смерти, бессмертии и о том, сколько они хотят прожить. Только данные разбросаны по сотням статей, сайтов, стат. сборников и архивов.

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

Я решил, это исправить. В этой статье я расскажу, как родился проект «Кто хочет жить вечно», почему вопрос бывает важнее ответа и как я собирал со всего интернета материалы, упаковывая их в инфографику на 40 графиков.

JSON, который считает сам себя. Ставишь = в ячейку — и она становится формулой. На диске при этом остаётся обычный JSON, который откроет кто угодно.

Тот, кто готовится к квартальному комитету, меньше всего хочет слышать адресованный лично вопрос: «Что изменилось в деньгах после твоего управления?» или в духе: «Какой эффект лично ты принёс компании?» Холод в желудке после этих фраз как раз и формирует взрослого управленца, хотелось бы, чтобы развитие происходило менее драматически.

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

Как это обычно бывает, инициатива похоронила инициатора, а простой список с пометками «что | откуда | пригодится в...» перерос в чуть ли не исследование.

Рекомендательная лента почти любого музыкального сервиса оптимизируется под одну метрику — удержание. Мне захотелось не рассуждать об этом абстрактно, а измерить: так появился OpenEar — open-source privacy-first дашборд, который считает прозрачные метрики музыкального разнообразия по истории ListenBrainz.

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

Мы в Диасофт развиваем Digital Q.Sensor BI — промышленную BI‑платформу, в которую команда продукта встраивает мультиагентные ИИ‑системы. И поэтому хорошо понимаем, почему вокруг AI‑native аналитики сегодня столько споров.

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

В статье эксперт «Диасофт» делится своими выводами — без попытки представить единственно правильный ответ. Скорее, это взгляд человека, который непосредственно работает с внедрением мультиагентных ИИ‑систем в промышленную BI‑платформу и наблюдает за тем, как меняется сам подход к аналитике.

Кстати, тех, кто дочитает статью до конца, ждет бонус.

Я руководитель, поэтому в 1С мне чаще всего нужны не документы сами по себе, а ответ на несколько довольно простых вопросов.

Как идут продажи?
Выполняем ли план?
Что изменилось по сравнению с прошлым периодом?
Есть ли просроченная задолженность?
Сколько сотрудников сейчас на местах?

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

Допустим, утром мне достаточно такой информации:

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

Встроенный граф Obsidian хорош ровно до момента, когда vault разрастается и превращается в клубок линий. Я решил сделать из базы знаний место, которое можно запомнить, — и собрал open-source плагин CosmoGraph 3D на Three.js и WebGL. В статье разбираю весь путь от metadataCache и wikilinks до сферической раскладки по золотому углу, процедурного рельефа, кратеров, bloom и нативного ItemView внутри Obsidian. Без облачной обработки заметок и без рассказов о «магии»: только код, архитектурные компромиссы и честный список того, что ещё предстоит ускорить.

Делаем приложение, которое готовит расчётные наборы данных для нативного BI-конструктора Битрикс24.

Пользователь описывает нужные показатели обычной фразой, приложение через ИИ-помощника собирает набор и публикует датасет в «Рабочее место аналитика». Аналитику остаётся один раз собрать по нему график, выбрав нужные поля и способы визуализации.

Я полез в данные соревнования Pokemon TCG AI Battle посмотреть, кто там выигрывает, и залип на другом. На публичной таблице 6806 команд. Самая поздняя отправка решения датирована 16 августа, 23:58:53. После этой секунды не отправил никто

1668 команд из 6806, почти четверть поля, сделали финальную отправку именно в этот день: 824 из них после шести вечера, 350 в последний час. Похоже, немалая часть узнала про срок в тот же день, когда он истекал

У Jira есть REST API, есть JQL, есть маркетплейс с дашбордами. Но как только метрики становятся чуть сложнее, чем «сколько задач закрыто за спринт», всё это упирается в потолок: