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

Полгода назад я так устал вручную ковыряться в JSON, что написал свой редактор — просто чтобы не сойти с ума. Выложил статью на Хабр, не ожидая ничего особенного. А в итоге получил 54 звезды, 4 форка и десятки комментариев с болью, очень похожей на мою: у кого-то конфиги для Unity, у кого-то — прошивки, у кого-то — просто ненависть к блокноту как JSON-редактору. Рассказываю, как усталость от рутины превратилась в проект, который теперь развивает не только один человек, а целое небольшое комьюнити.

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

Меня зовут Александр Ларин, я руковожу центром обучения и технической поддержки в GlowByte. Мы постоянно внедряем FineBI у клиентов и регулярно слышим один и тот же вопрос: «а где почитать или посмотреть, чтобы разобраться самому?» Решил собрать ответ в одном месте.

Расскажу, как и почему я в какой-то момент решил написать собственный pivot grid — без сторонних библиотек, на чистом JavaScript и DOM. И что из этого получилось: от первой версии с обычным GROUP BY до кэширования больших выборок и цепочки связанных гридов.

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

Сегодня разберем один из подходов, помогающий снизить градус проблемы с формированием потребностей: внедрение в регламент закупок чек-листа на фазе формирования потребности. Покажем на живых примерах, как ИИ-аналитик Raft AI4BI может помочь в имплементации подхода.

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

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

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

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

(Всё упоминаемое программное обеспечение в статье не является рекламой, а описывается исключтельно потому, что мы на практике успешно его применяем).

Когда у вас появляется продукт с активными процессами и большим количеством пользователей, объём данных начинает расти быстрее, чем ожидалось. На старте всё выглядит достаточно просто: есть PostgreSQL, где хранятся основные сущности, есть Kafka с событиями, и кажется, что этого достаточно для решения большинства задач.

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

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

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

Сегодня разберемся, что такое кросс-фильтрация в Apache Superset и какую неожиданную опасность она может нести.

Мне кажется, у каждого управленца есть любимый дашборд. Лично мой внешне совсем не похож на “красивую BI-аналитику”.

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

— аварии в очереди;
— юридические лица в очереди;
— заявки, по которым не было звонка клиенту;
— незаполненные слоты на 9:00;
— количество техников, загруженных менее чем на 80% сегодня;
— количество техников, загруженных менее чем на 80% завтра.

Это дашборд по координации заявок, в котором можно увидеть актуальную картину по процессу прямо сейчас. Например, сегодня в одном из наших филиалов утром можно было увидеть: 12 аварии в очереди, 151 заявок без звонка, 28 незаполненных слотов на 9:00 и 9 техников, загруженных менее чем на 80% на сегодня. 

С точки зрения “красивого BI” это выглядит очень просто. С точки зрения управления — это один из самых полезных инструментов.

Или: как embedded-разработчик случайно написал визуализатор временных рядов

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

Статья написана не без помощи LLM, от нее по большей части редактура. Прошу камнями не кидаться

Приятного чтения!

С чего всё началось

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

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

Но иногда появляется потребность в визуализации. Пока речь идет о низкочастотных датчиках и малом количестве данных - все довольно просто, но как только данных становится больше, а частоты выше - всплывает множество нюансов. При 70 кГц через 10 секунд работы датчика у меня уже 700 000 точек. Через минуту – 4.2 миллиона. А пользователь при этом хочет масштабировать/панорамировать оси, выделять области, нажимать кнопки – и всё это должно отзываться мгновенно. Стандартный подход «передать всё в библиотеку» ломается очень быстро.

Когда бизнес обсуждает внедрение ИИ-бота, разговор часто быстро уходит в технологии.

Какая модель? Голос или текст? RAG или сценарий?
Как отреагирует потребитель? Сколько будет стоить разработка?
Насколько похожим на человека будет бот, или все догадаются сразу?

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

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

Звучит очевидно, но при внедрении большинство теряют главный вопрос:

Где именно в техподдержке прячется экономический эффект от ИИ-бота?

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

У большинства контакт-центров уже есть базовая отчетность.

На что обычно смотрят руководители?

— количество обращений;
— время ответа оператора;
— среднее время обработки обращения;
— время ожидания на линии;
— количество потерянных звонков;
— SLA;
— загрузку операторов;
— количество обращений по каналам.

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

Например, мы видим, что:

— количество обращений растет;
— время ожидания увеличивается;
— SLA проседает;
— часть клиентов не дожидается ответа;
— операторы работают в перегрузе;
— в пиковые часы поддержка не справляется.

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

В этой статье я поделюсь опытом работы с ТЭП на основе BIM-моделей и расскажу о разработке инструмента «ТЭП Контроль».

В менеджерской среде есть изречение: «Управлять можно только тем, что можно измерить». Рискнем его дополнить — данных сейчас генерируется так много, что одного измерения уже мало: «…а эффективно управлять — лишь когда результаты измерений представлены наглядно». В предыдущих статьях про адаптивное администрирование Sigla Vision мы описывали, как собирать данные об изменении объектов BI-системы. Теперь покажем, как представить эти данные наглядно, и приведем примеры наших дашбордов — мы назвали их «системными», чтобы отличать от пользовательских.

Статья пригодится BI-разработчикам и ИТ-специалистам, которые развивают или сопровождают Sigla Vision и другие BI-системы.

Здесь мы разбираем, как системные дашборды помогают решать задачи администрирования Sigla Vision, и прикладываем код для PostgreSQL, который готовит таблицы-источники датасетов для комплексного дашборда «Состояние системы». В нем можно отслеживать, как меняются во времени количественные показатели по объектам: дашбордам, подключениям, ролям, пользователям, рабочим книгам, элементам корзины и т. д.

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

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

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

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

Готового мониторинга для SSRS и Power BI Report Server в сети нет - одни обзоры «SQL Server» с CPU и памятью. Собрал свой на Grafana: трейс упавших рассылок, тяжёлые отчёты, ночная нагрузка pbix и грабли с часовым поясом. Сборку отдаю целиком.

Всем привет!

Меня зовут Никита, я CEO компании VSL BI. Мы занимаемся внедрением BI-аналитики и автоматизацией отчетности для бизнеса.

Недавно к нам обратилась спортивная школа для детей.

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

Поэтому основной целью проекта стало создание единой системы аналитики, в которой данные из Alfa CRM автоматически собираются, обрабатываются и отображаются в виде дашбордов для руководства.

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

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

Введение

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

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

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

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

Тем не менее, детские установки «правильного» или «хорошего» поведения имеют колоссальное значение в жизни каждого взрослого.

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

Ролик «Le petit frere» («Младший брат»)

Посмотреть видео (рис. 1) с двуязычными субтитрами можно в https://my.mail.ru/mail/emmerald/video/_myvideo/2.html :