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

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

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

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

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

Цель этой статьи — показать, в какой плоскости начинается результативность аналитики. Она будет полезна руководителям, которые задаются вопросом из заголовка, и аналитикам, которые много работают, но не видят измеримого эффекта.

В чём, на мой взгляд, лежит корень этой проблемы?

Основной барьер для получения дивидендов от аналитической функции — это не просто культура принятия решений на данных (которую все пытаются описать модным и часто спекулятивным термином data-driven culture). Ключевая проблема — в системе взаимодействия, обратной связи и ответственности за результат, принятой в компании.

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

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

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

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

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

Полноценных open-source-альтернатив, которые закрыли бы все наши потребности, не нашлось. Поэтому мы решили создать свой «мультитул» — low-code-фреймворк для генерации гетерогенных Airflow DAG с незамысловатым названием dag_generator.

Цель этой статьи — поделиться опытом внедрения подобного инструмента. Генерация выполняется по старинке, так что про ИИ здесь пока ничего не найдете.

Обычный трейдер смотрит на свечной график, но свеча — это уже тень прошлого, постфактум. Между тем настоящая динамика рождается в глубине торгового стакана — Limit Order Book, где борьба заявок определяет будущий импульс.

Проблема в том, что историю стакана почти нигде не увидеть: розничные терминалы для частных клиентов дают лишь текущую таблицу DOM ( Depth of Market ) и это статичный срез без прошлого.

Чтобы увидеть то, на что обычный трейдер не обращает внимание я собрал инструмент, который превращает исторические данные L2 Order Book (стакан заданной глубиной) и Trades Stream (обезличенные сделки) в тепловые карты и позволяет изучать эволюцию заявок на Московской бирже через браузер с Deep Zoom — плавно, как в Google Maps.

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

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

Power BI и язык DAX являются удобными инструментами аналитиков. В DAX важно учитывать гранулярность — уровень детализации, который зависит от текущего контекста фильтров и группировки.

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

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

Давай поговорим о North Star Metric (NSM). Меня, если честно, иногда бесит, когда её преподносят как какую-то магию, которая сама по себе выведет бизнес в лидеры. Это не так.

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

Вся суть не в том, чтобы найти «идеальную метрику». Суть в том, чтобы заставить все отделы говорить на одном языке. И здесь как раз помогает метрика Полярной Звезды.

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

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

Привет, Хабр! Меня зовут Денис Мишкин, я - Product Manager одного из инструментов отчетности компании «Форсайт». Весной этого года мы выпустили новый продукт «Форсайт. Умные таблицы», который призван ускорить импортозамещение табличных редакторов, а-ля MS Excel, и BI-систем. Хочу рассказать вам о новом классе продукта, который сделает процесс создания аналитических отчетов максимально удобным и комфортным для пользователя, обогащая их опыт новыми уникальными возможностями.

Место нового продукта в экосистеме продуктов «Форсайт»

«Форсайт. Аналитическая платформа» – это универсальное и гибкое решение класса Enterprise BI, для реализации задач любой сложности. Оно дает не только возможности создания многомерной кубовой модели данных средствами загрузки этих данных (ETL), но и средствами доставки этих данных конечному потребителю в виде отчетности. Инструменты отчетности можно разделить на 2 крупных блока:

• информационные панели (дашборды) + Ad hoc, позволяющие легко и наглядно визуализировать данные;

• Pixel Perfect + табличная отчетность, которая призвана подготавливать регламентированную отчетность в строгой структуре и оформлении (регламентные отчеты).

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

«Обучил, запустил и забыл» — плохая стратегия работы с ML‑моделями, но она часто встречается после удачного тестирования. Качество моделей может незаметно снижаться, и если пропустить этот момент — последствия могут дорого стоить. Когда мы начали задумываться о системе мониторинга, одна из наших моделей начала выдавать предсказания, которые требовали незамедлительного вмешательства в выстроенную работу. Но разум подсказывал, что проблема не в процессе, а в модели. О том, каким трудоемким оказалось наше расследование, и как мы восстанавливали и изучали каждую составляющую процесса почти вслепую, читайте по ссылке.

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

Часто в работе возникает потребность жестко выдерживать тайминг при заслушивании серии докладов: при защите проектов, программ развития, дипломных работ и прочее. Если в повестке дня какого-либо мероприятия 10+ докладчиков, то без строгого соблюдения регламента невозможно не выбиться из графика. Как правило, это приводит к тому, что запланированное время мероприятия увеличивается кратно. А докладчикам, выступающим последними, фактически не достаётся должного внимания.

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

Сеть кофеен — это текучка, гибкие графики, подмены, совместители и десятки локаций. А если считать зарплату вручную, это еще и боль. Особенно когда всё построено на Excel: где-то не проставили смену, забыли штраф, не учли роль. На связи Анна Астахова, директор по развитию ИТ-интегратора «Белый код». Рассказываю, как мы автоматизировали расчёт зарплаты в сети кофеен, в которой более 150 сотрудников и нестандартизованной системой мотивации.

Привет!

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

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

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

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

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

Привет. Меня зовут Евгений, и я продуктовый менеджер направления отчетности и визуализации данных в компании «Форсайт».

Хотя корпоративная «Форсайт. Аналитической платформа» (далее просто Платформа) имеет в своем арсенале большое число различного инструментария, на мой взгляд, именно инструменты отчетности фактически являются ключевым блоком и «лицом» Платформы и BI-приложений, реализованных на ее основе. Ведь это первое, c чем сталкивается конечный пользователь и на что обращает внимание при работе: наличие необходимых функций, удобство построения пользовательского интерфейса, скорость работы — все это пользователи часто записывают именно на счет компонентов отчетности.

Хочу поделиться с вами нашей «вендорской» историей от том, как развивался инструментарий отчетности в составе нашей Платформы, какие интересные компоненты появились у нас относительно недавно, и над чем новым «Форсайт» работает прямо сейчас. Итак, начинаем!

Всем привет!

Меня зовут Владимир Павлов, я продакт‑менеджер. Недавно я проходил кейс‑интервью и получил отказ со следующим комментарием:

«Правильно выбираешь ключевые метрики, но не хватает измеримости, структуры, прокси‑ и контр‑метрик.»

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

Оплатив платный доступ к GPT, приступил к Vibe Coding.

Это третья часть серии «23 фичи Luxms BI, которыми мы гордимся». В первой мы говорили о платформенности и архитектуре, о том, на чем держится система. Во второй – о классическом BI-функционале, который делает систему BI-системой.

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

Мой путь от простых телефонных заметок к системе персонального знания начался с боли: потеря данных при смене устройств, неудобная синхронизация, отсутствие контроля. Прорыв случился с Obsidian — приложением, которое, как и VS Code, строится вокруг открытого формата (Markdown), локального хранения и расширяемости через плагины. Именно этот принцип «я управляю инструментом, а не наоборот» стал ключевым: Obsidian — не блокнот, а операционная система для мышления.