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

Привет, Хабр! Меня зовут Ольга, я финансовый директор Аспро и руководитель продукта Аспро.Финансы.

За девять месяцев 2026 года правила расчета фонда оплаты труда поменялись дважды. В ноябре 2025 года приняли закон, который поднял НДС и взносы для ИТ-компаний с января. В июле 2026 года приняли второй закон, который отменил часть уже принятых на будущее изменений и перенес их на несколько лет вперед. Компания, которая посчитала бюджет по правилам ноября 2025 года, к лету уже считала неправильно.

Разберем, что изменилось в 2026 году, что готовится на 2027, и как считать, сколько стоит один сотрудник.

Причалы на обложке складываются в S-57, а в коде слева спрятаны две строки. Кто первый расшифрует, пишите в комментарии.

У больших данных часто есть одна проблема: самые важные выводы зависят не от сложности алгоритмов, а от того, насколько аккуратно собраны и сопоставлены исходные источники. Автор собрал карту мелодий отправления для 2496 станций Большого Токио, объединив разрозненные вики, аудиоархивы и открытые данные, но столкнулся с тем, что даже названия станций оказались отдельной задачей для анализа.

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

Перед вами график гласных Международного Фонетического Алфавита. Если вы когда-либо интересовались фонетикой или даже лингвистикой в целом, вы видели этот график. Его учит каждый студент-лингвист на первом курсе. Тем не менее, он неверен.

Из этой статьи вы узнаете:

1. Как мы до этого дошли - почему ошибка из 1917-го года до сих пор воспроизводится в каждом учебнике в 2026-м

2. Как на самом деле выглядит пространство гласных

3. Как на самом деле связаны артикуляция и акустика гласных

4. Как программно вычислить положение конкретного звука в прострастве гласных

5. Как правильную теорию можно использовать для улучшения английского произношения и уменьшения акцента

В первой части мы, исследователи Smart Engines, представили наш портативный томограф и рассказали про его устройство. Судя по вопросам после докладов, самой убедительной части в той истории как раз и не хватало: а как это выглядит вживую? Поэтому сегодня никаких аксиальных коллинеаций. Мы включили запись на телефоне и сняли одно исследование целиком, от первого кадра до 3D‑картинки.

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

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

В этой статье попробуем разобраться.

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

Рассказываем, как мы в Smart Engines  создали первый в мире носимый томограф свободного позиционирования. Устройство весит менее 5 кг, помещается в чемодан, его можно фактически держать в руках и при этом получать полноценную 3D‑реконструкцию исследуемого объекта — без привычного для КТ массивного кольца и сложной стационарной механики. Благодаря этому нам удалось реализовать принцип «не пациент идет к томографу, а томограф — к пациенту».

К этой статье меня подтолкнула причина донельзя прозаическая. Сижу недавно на брифинге, и прилетает жалоба: сервер отчётов работает из рук вон плохо. Сервер при этом не мой, в орбиту обслуживания он не входил, а тут пришлось вспомнить, как оно всё устроено у 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