о визуализации данных и жизни

Позднее Ctrl + ↑

Алгоритм Δλ: элементарные частицы данных

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

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

Вот типичный интерактивный бизнес-отчёт:

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

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

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

Утром машина начала выдавать брак и пришлось потратить несколько часов на ремонт, ещё час она выходила на рабочий режим, после чего её производительность стала отличной. Эффективность за день получилась всего 22% из-за плохого старта.

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

На визуализации видна общая эффективность предприятия, а также изменение эффективности во времени и разбивка по цехам (в поисках слабого звена можно спуститься по иерархии до машин и бригад). Такая визуализация выявляет проблемы и помогает повысить эффективность, а не просто констатирует факт.

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

Следующая теоретическая заметка выйдет 30 мая.

Курс по визуализации данных, 23 и 24 апреля

23 и 24 апреля мы с техдиром лаборатории Димой Семьюшкиным провели брейнвошинг по визуализации данных — первый после двухлетнего перерыва.

Свою (дизайнерскую) часть курса я посвятила описанному накануне алгоритму визуализации данных. Участники приняли наш нестандартный подход с интересом, задавали вопросы, помогали прояснить сложные моменты и точнее сформулировать суть алгоритма, тестировали его на рабочих задачах. Курс показал, что сам алгоритм и процесс обучения требуют доработки, но вектор выбран правильный. Я получила заряд вдохновения и буду «копать» дальше!

Дима взял за основу обкатанные на прошлых курсах лекции и дополнил их ещё более понятными и наглядными объяснениями. Судя по отзывам, введение в D3.js стало по-настоящему простым и доступным даже для «совсем новичков». Правда, опытным программистам не хватило сложных примеров и было скучновато. Постараемся это исправить на следующем курсе.

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

На курс собрались ребята из Риги, Рязани, Омска, Питера и Москвы, из Билайна, Сбербанка и других замечательных компаний, а заодно почти вся лабораторная команда. Спасибо всем за эти два дня, было здорово!

Следующий курс — осенью.

Алгоритм Δλ: главная идея и шаги

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

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

Та же масса на каркасе, образованном осью времени, даёт диаграмму финишей:

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

Другие примеры частиц данных:
— солдат и мирный житель в визуализация потерь «Fallen.io»,
— землетрясение в истории землетрясений,
— час активности или сна на диаграмме о ритме жизни городов,
— гол и голевой момент в футбольной аналитике,
— попытка ответа на вопрос в статистике тренажёра ПДД,
— танк в сравнении характеристик танков WoT,
— трата в анализе личных расходов,
— доллар на логарифмической мани-грамме.

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

Создание визуализации сводится к следующим шагам:

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

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

    Чтобы познакомиться с нашим алгоритмом «из первых рук» и научиться его применять, приходите на брейнвошинг по визуализации данных, который я проведу в Москве, 23 и 24 апреля.

    Следующая теоретическая заметка выйдет 16 мая.

    Реальность данных и постановка задачи

    Качественная визуализация показывает реальность данных под определённым углом, который интересует наблюдателя. Реальность данных отвечает на вопрос «Что происходит?», а постановка задачи (угол) — на вопрос «Зачем мы исследуем данные?» или, иначе говоря, «Что мы ищем?»

    Вернёмся к примеру с маршрутными такси. Реальность данных:

    Автобусы перевозят пассажиров по маршрутам общественного транспорта. Маршрут состоит из остановок, за день на маршруте выполняется несколько рейсов. Расписание движения по маршруту для каждого рейса задано временем прибытия на остановку. В каждый момент о каждой «машине» известны координаты, скорость и количество пассажиров на борту, а также какой рейс по какому маршруту она выполняет, и какой водитель за рулём.

    Транспортные аналитики хотят выяснить:
    Как меняется загруженность автобусов на маршруте в среднем в течение дня?
    Как часто и насколько серьёзно нарушается расписание движения?
    Где находятся, насколько загружены, как сильно отклоняются от расписания автобусы в данный момент времени?

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

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

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

    Задачу о визуализации нарушений на одном из маршрутов я решала в рубрике «Вопрос-ответ». Вот как будет выглядеть сводка по нарушениям на маршруте утром, днём и вечером:

    Опоздания по утрам и вечерам концентрируются в разных частях маршрута.

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

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

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

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

    Следующая теоретическая заметка выйдет 11 апреля.

    Реальность данных, примеры

    Данные порождает объективная реальность. Например, по маршрутам общественного транспорта ездят автобусы, которые в разное время перевозят разное количество пассажиров, соблюдают расписание или опаздывают, нарушают скоростной режим и правила дорожного движения, сходят с рейса. Датчики собирают данные о местонахождении, скорости и загруженности каждой «машины» в каждый момент времени. После этого данные попадают в базу данных и доступны в виде отчётов (срезов): время посещения остановок и отклонения от расписания на конкретном маршруте, загруженность маршрута в зависимости от времени дня, список нарушений конретного водителя за день/неделю/месяц и т. п.

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

    Реальность данных — это выжимка объективной реальности, которая касается только конкретной задачи и доступных данных. В описанном выше примере, реальность данных выглядит так. Автобусы перевозят пассажиров по маршрутам общественного транспорта. Маршрут состоит из остановок, за день на маршруте выполняется несколько рейсов. Расписание движения по маршруту для каждого рейса задано временем прибытия на остановку. В каждый момент о каждой «машине» известны координаты, скорость и количество пассажиров на борту, а также какой рейс по какому маршруту она выполняет, и какой водитель за рулём.

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

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

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

    Тренажёр ПДД
    В базе данных результатов тестирования на знание правил ПДД есть таблица ответов и таблица со статистикой по билетам. Таблица ответов содержит поля: ID пользователя, ID вопроса, результат (верный или неверный ответ), дата и время, сам ответ и др. Таблица билетов содержит: ID пользователя, ID билета, сдал/не сдал, количество верных ответов, дата и время, тип тестирования, потраченное на билет время (в секундах).

    В реальности данных пользователи отвечают на вопросы экзамена ПДД по билетам или вразнобой, дают правильный ответ или ошибаются. Билет считается сданным, если при тестировании допущено 2 и менее ошибок. Количество попыток неограничено.

    Рейтинг школ
    В сводной таблице по школам Москвы указаны: название и номер школы, количество учеников, список средних баллов на выпускных экзаменах и ЕГЭ по разным предметам, доли поступлений в ведущие ВУЗы.

    В реальности данных выпускники сдают экзамены и ЕГЭ по разным предметам в разных школах Москвы, с разными результатами и поступают в разные ВУЗы.

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

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

    Следующая теоретическая заметка выйдет 28 марта.

    Ранее Ctrl + ↓