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

Привет!

Перед вами новое исследование, посвящённое одной из ключевых технологий управления данными — процессам извлечения, преобразования и загрузки данных (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 — не блокнот, а операционная система для мышления.

Работа с процессами, которые имеются в любой компании, ведется уже не один год и кажется, что все уже давно изучено, описано и зачем еще раз подымать этот вроде бы теоретический вопрос. Дело в том, что при работе с процессами специалисты действуют в рамках установленной и принятой на сегодняшний день сообществом специалистов парадигмы, основываясь на которой осуществляется работа с ними (моделирование, контроль, анализ, совершенствование).

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

Но почему важно иметь точное понимание, что такое операционный процесс и что такое процесс управления?

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

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

Продукт «Форсайт. Бюджетирование» уже имеет свою историю успеха: он был выпущен в 2018 году, в следующем 2019 году включен в Реестр российского ПО и за прошедшее время было выполнено значительное количество его внедрений. Из наиболее крупных можно выделить проекты в «Росэнергоатоме», «РусГидро», VK, Иркутской нефтяной компании, «Газпром нефть», Ikon Tyres (Айкон Тайерс), «Лайм-Займ».

При разработке этого продукта (как и других отраслевых решений нашей компании) использовался подход, когда в основе лежит наша флагманская разработка – «Форсайт. Аналитическая платформа», а в продукте разрабатывается дополнительная специализированная функциональность, позволяющая более эффективно автоматизировать процессы, на которые нацелен продукт. При этом уникальность такого подхода на рынке в том, что базовая для продукта платформа «Форсайт. Аналитическая платформа» сама является полноценным продуктом enterprise уровня с широким набором инструментов и сервисов. Разрабатываемые отраслевые продукты на базе платформы получают всю функциональность базовой платформы и высокий уровень защиты и безопасности (платформа сертифицирована ФСТЭК на соответствие 4 уровню доверия). Также отраслевые продукты, как «заказчики функциональности», влияют на развитие самой платформы. Функциональность «Форсайт. Бюджетирование», например, примерно на 80% состояла из функциональности платформы. Важным результатом применяемого подхода является получаемый синергетический эффект: в совместном развитии и функциональных возможностей продуктов, и инструментов базовой платформы.

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

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

Маркетинг утверждал: «Мы привели лиды, а вы просто не умеете продавать». Продажи отвечали: «Ваши лиды — говно».

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

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

А что на счет самих данных, если мы их рассматриваем как продукт? Как будем оценивать их ценность, как будем планировать их развитие?

В статье предлагаю экспериментальный набор UX‑метрик: они помогут увидеть, где ваш продукт реально теряет пользу для пользователя. Методика готова к тестированию — цифр пока нет, но каркас для расчётов уже работает.

Всем привет! Меня зовут Ульяна Айкович и я исследователь БКС Мир Инвестиций. Сегодня я расскажу, как мы можем глубже анализировать время выполнения заданий, а также как измерить группы респондентов в немодерируемых UX тестах.

В данной статье я разберу не только медиану и процентили для оценки времени, но и критерий Манна–Уитни — простой способ статистически сравнить две группы респондентов.

Приятного прочтения и погружения в мир статистики!

Я пришел в Data Science не сразу. Учился в магистратуре по вечерам, работая в совершенно другой сфере (строительство). Осваивать машинное обучение и анализ данных было интересно, но один из самых неожиданных вопросов, который возник буквально сразу - в какой среде писать код?

На первый взгляд кажется, что Jupyter Notebook, Google Colab, Kaggle и сравнительно новая Marimo - это одно и то же, ноутбук с ячейками и Python (так же поддерживаются другие языки программирования). Но на практике каждая из этих сред подходит для разных задач, где-то удобнее учиться, а где-то работать командой.

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

Статья будет полезна:

В настоящее время я занимаюсь подготовкой рукописи для второго издания книги «История моей страны. Записки военного инженера-программиста». Естественно, в ней много старых черно-белых фотографий разного качества. Это не только бытовые фотографии, но и уникальные фотографии вычислительной техники, которая сегодня не только не выпускается, но порой и не сохранилось ни одного экземпляра. В 90-е года эту технику бойко сдавали на драгметаллы. Но сегодня еще живут люди, которые работали в те времена, видели и даже творили на этой техники. Они могут рассказать, как и что выглядело. Я знаю многих людей глубоко пенсионного возраста, которые занимаются восстановлением старых фотографий в цвете. Это тяжелая и кропотливая работа. Но в конце августа сего года вышла модель генерации изображений Nano Banana от компании Google, которая просто совершила революцию в этом деле, но и она, несмотря на свои возможности, имела недостатки:

Изучая получившийся клеточный автомат Коллатца (CCA), ранее описанный в статье. Я задумался о том, как лучше показать взаимодействие его клеток, чтобы это было доступно и наглядно. Простое описание опций, это теоретическая часть, но как известно, практика, помогает укрепить понимание протекающих процессов.

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

Игра - Лабиринт

Не откладывая задачу в долгий ящик, представляю Вам прототип игры "Лабиринт".  На рисунке 1, представлен пример поля лабиринта, основанного на CCA. Справа от поля имеется легенда с описанием цветов ячеек.

Привет, Хабр! Некоторые функции DAX из Power BI могут выглядеть интуитивно понятными, но при детальном рассмотрении ведут себя не совсем ожидаемо. Например, SUMMARIZE не агрегирует «сразу», в месте использования, но SUMMARIZE реализуется через «виртуальную», «отложенную» агрегацию за счет сохранения состояния. Для суммы, т.е. SUM, промежуточное состояние и есть сумма и особенности SUMMARIZE не проявляются, но для любой другой агрегации (например, среднего AVERAGE) становится понятно, что в Power BI уже учитывается так называемое состояние для корректного расчета SUMMARIZE, т.е. данные по всем записям сохраняются в состоянии. В других СУБД единственный аналог — только State и Merge комбинаторы из ClickHouse, поэтому для иллюстрации состояний будет рассмотрен пример из ClickHouse, соответствующий DAX с SUMMARIZE и AVERAGE. Интересующимся особенностями SUMMARIZE в Power BI — добро пожаловать под кат :)

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

20 ноября состоялся официальный запуск Nano Banana Pro (Gemini-3-Pro-Image-Preview) с мощной базой Gemini 3 Pro. Это уже более взрослый инструмент для дизайна, инфографики и контента. Мы с вами не только рассмотрим нововведения, почему именно модель стала прорывной, но и на реальных примерах наглядно в этом убедимся.

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

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

Привет, Хабр! На связи снова Иван Чаплыгин, руководитель отдела ИТ-переводов КРОК. Сегодня хочу рассказать, как Kanban – подход, заточенный прежде всего под нужны разработчиков, можно использовать в бэк-офисе. Под катом – наш нехитрый опыт внедрения Kanban в дашборды Jira.