Генерацию гипотез через дерево метрик считаю одним из самых результативных подходов. Особенно значимым для меня тут является возможность отделить личное мнение от принятия решений. Этакое «я нерепрезентативен» на максималках. Лично для меня это важно ещё и потому, что почти во всех продуктах, над которыми я работала, я сама не являлась core‑пользователем.
На сами метрики мы смотрим фактически с тремя задачами:
В крупных федеральных организациях всё активнее используется подход управления на основе данных, который требует активного использования и постоянной переделки, развития, модификации аналитических приложений, отчётов, данных. Тот опыт и наши наработки, которыми мы хотим поделиться в рамках данной статьи, приносят пользу на многих проектах, где речь идёт о сотнях аналитических отчётов и дэшбордов, нескольких тысячах показателей и сотнях и тысячах активных пользователей, где, самое главное, вендорские решения кастомизируются внутренними командами заказчика. Для таких случаев всё, о чём мы расскажем дальше, очень важно, для остальных — надеемся, что будут полезны отдельные мысли и технические решения.
Начнём с простого и наболевшего. Когда создаётся первая версия дэшборда, задача звучит просто: «показать данные хоть как-нибудь и побыстрее». Не до архитектуры, не до производительности — главное, чтобы цифры появились, и руководство смогло принять правильное управленческое решение. Потом уточняется задача, добавляются новые требования, меняются источники, добавляются разрезы данных, растёт нагрузка. И вот тот самый дэшборд, собранный на скорую руку, оказывается в проде — и технически работает не так и не с той скоростью, как нужно. А далее необходимо развивать функционал, обновлять версию. И сложности растут.
В этой статье команда авторов ГК Luxms, вендора платформы бизнес-аналитики Luxms BI, расскажет, почему так происходит и почему «оптимизация» — это не про критику, а про работу с реальностью, со сложной реальностью мира IT и мира данных. А еще — почему важно не только чинить, но и уважать чужой код.
📊 Информативные графики с двумя осями Y и тремя разными единицами измерения в Plotly!
В этом туториале я разберу, как с помощью мощной библиотеки Plotly на Python создать интерактивную визуализацию с тремя различными единицами измерения.
Вы узнаете:
• Как настроить вторичные оси Y и X
• Способы визуализации разнородных данных
• Техники форматирования шкал и меток
• Варианты красивого оформления мульти-осевых графиков
Всем доброго дня! Пишу здесь впервые. На написание меня этой статьи побудило желание рассказать людям об эффективном способе миграции от внутренней базы данных Sqlite3 к внешней БД PostgreSQL. Подобной статьи на Хабре я не нашел, поэтому надеюсь будет полезно.
Я всегда любила схемы и таблички. Если нужно было разобраться в новом проекте/топике/проблеме — я рисовала схему этого. Если нужно было принять решение — делала таблицу. Если я не могла положить что-то в один из этих форматов, значит, нужно было копать тему дальше. В Miro накопилось десятки рабочих пространств. И всегда хотелось сделать основную, самую главную схему для продуктовой команды, которая позволяла бы быстро и чётко возвращать всех к единой цели с единым пониманием — куда, зачем и как именно копаем. Дерево метрик — самый действенный инструмент, который мне попадался.
Что такое дерево метрик и зачем оно нужно?
Дерево метрик — это иерархическая структура, которая связывает бизнес-цель с подчинёнными метриками и действиями, помогая понять, какие показатели влияют на результат и где искать точки роста или проблемы.
Если просто: дерево метрик — это инструмент, который связывает:
Привет, Хабр! Меня зовут Александр Антипов, я продакт-оунер MWS Tables.
Раньше казалось, что «опытные пользователи ПК» — исчезающий вид, но реальность другая: сегодня сотрудники не просто работают с технологиями, а сами автоматизируют рутинные процессы. Без разработчиков и сложных систем — с помощью макросов, таблиц, SharePoint и других инструментов.
Полтора года назад мы в МТС создали для таких кейсов MWS Tables — внутреннюю платформу самостоятельной автоматизации. В этом посте — реальные примеры, как MWS Tables уже применяется на практике. Я покажу, как с помощью MWS Tables реализовали единый реестр для работы с качеством данных, централизованную систему по менеджменту IT-проектов и собственный таск-трекер. Все подробности — под катом.
Привет, друзья! Сегодня поговорим о том, как системный аналитик (то есть я, ты или тот парень из соседнего отдела) может использовать визуализацию, чтобы перестать быть "человеком, который пишет непонятные документы", и стать "тем, кто делает красивые картинки, которые все понимают". Ну, или хотя бы пытается.
Давайте признаем, что иногда объяснить разработчику, как работает процесс, — это как объяснить котику, почему нельзя есть кактус. Ты вроде всё правильно говоришь, но в итоге он всё равно делает или понимает по-своему. А всё почему?
Первое - причина в нас! (но это уже отдельная история)
Второе- потому что слова — это скучно.
Во многих соревнованиях тема дополнительных показателей является достаточно острой, иногда даже холиварной. По-другому быть не может, ведь они выходят на сцену в самый драматичный момент, когда определяются судьбы кубков, медалей, а порой и карьер.
Есть, например, мнение, что если бы Саутгейт-игрок забил тот пенальти в 1996, то, возможно, стиль сборной Англии при Саутгейте-тренере был более смелым.
Конечно, основная тема для споров - это мера случайности различных доппоказателей, сама по себе или в сравнении с "настоящей игрой". В каждом виде соревнований эти показатели и споры об их случайности свои, тут сложно придумать какой-то универсальный ответ.
Я довольно много играю в спортивное "Что? Где? Когда?", поэтому хочу сделать заход в этой области.
Данный отчет представляет собой аналитическое исследование авиапроисшествий, произошедших в период с 2014 по 2024 годы и расследованных МАК. В основу анализа легли данные о происшествиях, включающие сведения о типах воздушных судов, числе погибших, географическом расположении инцидентов, а также причинах катастроф
Всем привет! Меня зовут Олег Косарев. Я – ведущий инженер-программист. В группе компаний «Цифра» занимаюсь развитием и поддержкой продукта «Диспетчер». Моя основная специализация – Frontend-разработка.
В данной статье я хочу поделиться с вами нашим опытом по созданию MVP (Minimum Viable Product, «минимально жизнеспособный продукт») редактора аналитических панелей.
Привет, Хабр! Мы уже неоднократно поднимали вопросы оптимизации запросов к СУБД ClickHouse, которую все чаще используют как универсальное высокопроизводительное хранилище для аналитических задач. В случае с Visiology этот вопрос приобретает двойную ценность, так как мы используем оптимизацию для эффективного выполнения запросов в языке DAX.
Сегодня мы поговорим о применении группировок GROUP BY с учетом их производительности для относительно больших таблиц, например, с миллионами записей. Таким образом, речь пойдет об оценке кардинальности одного или нескольких столбцов. Эта задача, кстати, является достаточно нетривиальной. Но если Вы можете ее решить, появляется возможность для эффективных оптимизаций SQL. О них мы и поговорим сегодня.
Феномен Современного искусства с каждым днём приобретает новые, более широкие рамки и концепции. Но, их понимание и интерпретация для простого зрителя по-прежнему вызывает много вопросов.
Одними из ведущих факторов оценки искусства являются уникальность, сложность и, конечно же – стоимость.
Зачастую, совсем «простые» произведения имеют совсем не малую цену, величина которой порой, кажется, действительно несоизмерима с визуальной составляющей работ.
Наша команда решила разобраться с этим феноменом и провела исследование в области произведений современного искусства (делая особый акцент на изобразительном творчестве). Мы собрали статистические данные из открытых источников в интернете (с ресурсов, представляющих наибольших интерес у коллекционеров, покупателей, галеристов). На основании этих данных можно проследить аттрактивность предметов коллекционирования, их востребованность и ценность.
Среди всех вариантов расчета данных мы выбрали наиболее показательные поля для оценки: регион и год создания, стиль и тема искусства, площадь, ключевые слова, а также тип материала (из которого и на котором выполнено произведение).
Комбинация данных позволили выделить некоторое количество ведущих пунктов, ставших- основой для создания статистики.
Зависимость стоимости от региона (илл.1) показывает самые дорогостоящие произведения из Центральной Америки, цена которых варьируется от 3,5 до 4,8 млн. рублей. Следом за ними - произведения стоимостью от 500 тыс. до 1.5 млн. из Южной Азии и Западно-Африканского региона.
Ориентируются ли собаки по компасу, когда делают свои грязные дела? Оказывается — да! Если вам интересно, как можно это подтвердить в домашних условиях, используя компас, Байесовскую статистику и собаку (собака не включена), то добро пожаловать под кат.
Вопрос, чем заменить Power BI, стал актуален для многих пользователей одной из самых популярных BI-платформ. С точки зрения синтаксиса DAX и удобства работы с моделью данных наиболее очевидной альтернативой является Visiology. Но у этой платформы до недавнего времени не было своего ETL-инструментария. Недавно вендор представил свой Self-Service ETL, и у меня возник логичный профессиональный интерес к его тестированию. В этой статье я делюсь своими исследованиями возможностей SS ETL от Visiology по сравнению с Power Query.
Потратил пару месяцев, чтобы спарсить матчи и понять, насколько футбол хаотичная и непредсказуемая игра. И выводы оказались довольно неоднозначными. Но обо всём по порядку
Наш металлургический комбинат можно сравнить с популярным круглосуточным рестораном. Поставщики отгружают в него ингредиенты — сырье и полуфабрикаты, а на выходе получается готовое блюдо: сталь, а перед сталью — жидкий чугун. Чугун можно сравнить с бульоном, из которого потом получится полезный и наваристый суп.
Для производства чугуна различные агрегаты — доменные печи, агломашины, коксовые батареи — должны быть постоянно обеспечены сырьем и полуфабрикатами. Их отсутствие может привести к невыполнению производственной программы или вовсе остановке производства. Таким образом, обеспеченность сырьем необходимо постоянно контролировать, причем не только в моменте, но и наперед, чтобы не допустить даже вероятность несогласованного дефицита.
Чтобы своевременно удовлетворять потребность сталеплавильного производства в чугуне определенного количества и качества, необходимо планировать объемы поступления сырья, включая планы отгрузки, поступления, выгрузки, шихтования и вовлечения в доменные печи. В связи с тем, что в данном процессе традиционно много участников, каждый из которых отвечает за свой участок и планирует его, долгое время на комбинате не было единой системы планирования обеспечения сырьем. Каждый работал в своей «таблице», а для формирования консолидированных планов тратили много времени и сил, чтобы подготовить итоговый план производства и обеспечения сырьем, который всех бы устроил. Нам нужно было разработать систему, которая стала бы единым источником правды по планам производства и обеспечения сырьем нашего металлургического ресторана.
Привет, Хабр! Достаточно часто используются иерархические фильтры или отчеты с иерархией, и представление иерархии может быть актуально как для UI (например, иерархических фильтров), так и для отчетов или дашбордов. Если рассматривать только структуру запроса с иерархией, без расчета промежуточных итогов и т.д., то сохранение структуры иерархического UI элемента при большом уровне вложенности, а также передача этой иерархии с UI на бэкенд и дальше, например, в виде SQL запроса в СУБД может быть относительно нетривиальной задачей. При относительно большом уровне вложенности (например, иерархия в 10 уровней), при решении «в лоб» и сохранении всех 10 выбранных значений на последнем уровне иерархии, станет неудобно хранить и передавать в качестве параметров с UI на бэкенд (для 1000 строк и 10 уровней вложенности может быть уже условно 10000 параметров), также растет и количество параметров в SQL, и проблемы усугубляются в случае микросервисной архитектуры, когда запрос SQL не сразу отправляется, например, в ClickHouse, а ещё эти 10000 параметров «путешествуют» из UI в один или несколько микросервисов, пока не попадут в ClickHouse. В связи с этим хочу рассмотреть одно из возможных решений проблемы с помощью хеширования на примере C# и ClickHouse, но это «не идеи, проверенные на продакшене», больше тема к обсуждению. Тем, кому интересно решение проблем иерархических запросов на примере C# и ClickHouse — добро пожаловать под кат :)
Дата — это всего три числа, но даже такой маленький элемент интерфейса может серьезно повлиять на пользовательский опыт.
