Почему же я так топлю за Vega stack?

Дисклаймер: Я собирался написать этот пост в течении последних нескольких месяцев; Меня опередили. Изначальный черновик был достаточно похож на пост Робина, поэтому я добавил чуть больше подробностей о применении Vega в моем отделе. Пост во многом основан на презентации, которую я делал на NYC VIS Meetup летом 2018

Экосистема библиотек и инструментов визуализации сейчас намного более устоявшаяся, нежели, скажем, лет 5 назад. И все же, даже краткий обзор библиотек визуализации (и это только python) показывает многообразие решений и библиотек.

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

Часто инструменты и решения завязаны на конкретны формат визуализации, — печать, IDE (Jupyter, RStudio), web, мобильное устройство — и так далее. А ведь нередко визуализацию необходимо воплотить в нескольких форматах (интерактивная онлайн, статичная как часть презентации, печатная продукция).

С другой стороны, многие инструменты завязаны на формат работы / доступа — для разработчиков/аналитиков с конкретным языком программирования, дизайнеров, или аналитиков, которым нужен простой интерфейс с GUI.

Классическое разделение ролей (аналитик vs. дизайнер vs. фронт-энд девелопер) тоже не помогает — дизайнеру проще перерисовать картинку, нежели обсудить пресеты “на берегу”, аналитик не будет тратить свое время на шрифты.

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

Такой подход несет в себе свои ограничения — зависимость от инструмента, его возможностей, стоимости, сложность миграции, часто — сложность репликации / вторичного использования.

С моей точки зрения, Vega — идеальное решение означенной проблемы . Почему?

1. Спецификация

Концепция Vega (тот самый “declarative approach”) подразумевает создание спецификации как единого стандарта описания визуализации — в точности по заветам “The grammar of Graphics” Вилкинсона, однако сильно прокачанный с точки зрения возможностей интерактивности.

Спецификация как Медиум

Что это означает практически?

1. Спецификация — простой файл json, который можно прочитать, редактировать или написать вручную (и без знания языков программирования), в любом текстовом редакторе.
2. Соответственно, любой инструмент или язык программирования может сгенерировать спецификацию (если может генерировать json-файл) (см., например, Visdown)
3. “Стандартный движок” Vega основан на d3, и позволяет реализовать почти все, что может эта библиотека — однако могут быть и другие “движки” (по аналогии — как SQL работает и для MySQL, и для Postgress, и для Hive). Пример такого “внедрения” — MapD.
4. Любой “конечный продукт” Vega — это движок + спецификация. Спецификация всегда доступна — таким образом, конечный результат всегда можно изменить или использовать для другой визуализации

2. Разделение “контента”, “стиля” и “данных”

Разделение контента и стиля — классический подход для веб-страниц. Контент — это html, стиль — css. Vega переносит этот подход на визуализацию — стиль можно указать через систему конфигураций и тем. Дизайнеры могут определять — и легко обновлять, — шаблоны (цвета, шрифты, отступы, и так далее.); аналитик может в принципе не думать об дизайне как таковом, указывая лишь тип палитры — скажем, категориальная, цвет (что не мешает при необходимости определять свойства конкретных объектов).

Такой же подход и к данным — их можно внедрить в саму спецификацию, или указать доступ к ним по ссылке, или вообще стримить. таким образом, одну визуализацию можно использовать еще раз, просто изменив данные в csv/json.

Один забавный побочный результат — визуализацию можно “украсть”, заменяя ссылку на данные и конфигурации — результат будет выглядеть как ваша уникальная, брендированная визуализация. Таким же образом один чарт можно использовать для разных форматов, например для веба и для печати, просто изменив конфигурации.

Хороший пример разделения дизайна и контента — в этом ноутбуке.

3. Интеракция

Vega (и её субпродукт, vega-light, об этом ниже) позволяют создавать не только статические визуализации, но и добавлять сложную интерацию — такие как зум и пан, скролл, выбор элементов и пересчет визуализации для них, работа с интерфейсами; Все это достаточно легко реализовать без необходимости знания языков программирования. Если верить девелоперам, внутренности этой интерактивности оптимизированы, и результат, как правило, работают лучше, чем если бы их написал средней руки программист на сыром d3.

Несколько хороших примеров интерактивности тут, тут и тут.

3. Уже существующая, бесплатная экосистема

Экосистема Vega (неполная)

Vega — это не только красивая “концепция”, но и талантливая реализация. На самом деле, вокруг и на основе Vega существует достаточно большая экосистема инструментов:

• Vega Lite, “упрощенный” (на самом деле, более семантический) вариант vega для генерации классических чартов.
• Lyra, своего рода графический редактор для Веги, сейчас несколько заброшен, но работает.
• Voyager2, графический редактор (слегка напоминает Tableau), который пытается “предложить” наиболее интересные визуализации на основе конкретных данных (кстати, есть вариант как плагин для Jupyterlab).
• Онлайн редактор/просмотрщик Vega / Vega-lite, с возможностью публикации
• Встроенный редактор/просмотрщик Vega / Vega-lite для Jupyter
• отдельный Desktop редактор
• для Python и R есть библиотеки Altair, позволяющие генерировать графику (и экспортировать, при необходимости). Отдельно стоит подчеркнуть — Altair удивительно красиво написан, и позволяет редактировать и комбинировать чарты в одну линию кода (на контрасте с очень “общительным” Matplotlib), а главное — наследовать чарты.
• pdvega соединяет привычный интерфейс визуализации pandas с Altair — по сути дела замещая Matplotib под капотом. (а еще есть gpdvega — для визуализации из geopandas)
• множество экспериментальных библиотек типа VisDown, часть можно посмотреть здесь
• имплементация Vega в Observabl
• имплементация Vega для react
• использование Vega не ограничивает нашу работу с Javascript — на самом деле объект Vega View позволяет легко интегрировать визуализацию с окружением.

Vega так-же поддерживается рядом платформ, включая MapD, Jupyter, Ntract, Flourish, WikiMedia, Kibana. Наконец, Apple и Google вовсю используют Vega для своих проектов. Существуют плагины для создания карт на основе веги в Leaflet and OpenLayer.

Команда UW IDL (создатели Vega и Vega Lite) активно используют стек в своей академической работе — например для Draco, алгоритма поиска/оценки лучшей визуализации

Процесс

Как стоит применять все это богатство возможностей на практике?

Vega Chart на нашем блоге

Процессы и задачи в разных командах отличаются! Ниже описано, как мы используем Vega Stack в нашем отделе. Впрочем, открытая архитектура системы позволяет использовать и другие workflows.

1. Так как мы работаем в Python, как правило все начинается в Jupyter — создаем чарт с помощью pdvega (удобна как plug-n-play для обычной визуализации pandas) и Altair. Впрочем, чем дальше мы используем vega, тем чаще соблазн использовать уже готовые графики, слегка их отредактировав. В редком случае интересные графики находит Voyager — в этом случае их можно сразу экспортировать, или воспроизвести в Altair.
2. График сохраняем в json. Альтаир позволяет сохранить данные как часть specs, или отдельно как json или csv (нам этот вариант кажется лучше).
3. В принципе можно перенести specs ручками на S3 и посмотреть как это выглядит. Обычно все-же приходится доводить график в онлайн-редакторе или внутри jupyterlab.
4. Если хочется чего-то, что vega-lite не поддерживает, переведем specs в Vega — это может сделать и Altair, но на практике проще использовать онлайн-редактор.

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

• Вместо переноса ручками, мы используем boto3 — чарты автоматически переносятся на тестовый S3 вместе с данными.
• Наш кастомный апп поддерживает заголовки, подзаголовки и подстрочные заметки — их (да и что угодно еще) можно хранить в специальном разделе спецификаций “usermeta”. Для простоты все эти навороты генерирует отдельная функция на python. На всякий случай все что мы поддерживаем добавлено в jsonschema для валидации. Кстати, в будущем мы рассчитываем поддерживать и d3-annotations.
• при импорте хелперов Альтаир автоматически загружает конфигурацию (стиль) — напрямую из репозитория аппа, так что графики выглядят одинаково в Jupyter и в вебе. При необходимости уже опубликованный на S3 чарт можно встроить в Jupyter через Iframe.
• Самое приятное — объекты Altair легко кастомизировать. Для карт мы настроили кастомный объект с уже прикрепленными границами — аналитику не нужно знать тонкости GIS и вообще задумываться о геоданных — лишь подклеить собственно метрики.

В результате, создание простой визуализации занимает пару минут (быстрее чем в Tableau); При этом мы можем генерировать и сложные визуализации — типа визуализаций сетей или интерактивных карт.

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

Минусы

При всех плюсах, стоит отметить и несколько проблем/недостатков, с которыми я столкнулся ( и которые, надеюсь, будут устранены):

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

2) Пока Vega не поддерживает одну из наиболее приятных фич D3 — транзит (анимацию) объектов при изменении данных — маркеры просто обновят свое положение. Впрочем, это обещают исправить в будущем.

3) Responsive layout возможен, но не имеет решения “из коробки”. Для составных визуализаций добиться pixel-perfect поведения не совсем тривиально.

4) Vega позволяет создавать достаточно сложные, составные визуализации, однако сама спецификация при этом быстро становится нечитаемой. Я надеюсь что в будущем появится инструмент отображения спецификации как графа (a-la impure/grasshopper3d/vvvv) — и буду рад поучаствовать в разработке!

С чего начать изучение?

• Как мне кажется, для начала лучше всего подойдут эти, очень короткие уроки по vega.
• Для Vega-lite есть прекрасный tutorial вот тут.
• Следом, если вы работаете на R/Python, посмотрите в сторону Altair; Есть прекрасный tutorial с Pycon 2018;
• Если вам нужно уговорить ну очень занятого пользователя python — покажите ему pdvega; Библиотека не только “копирует” поведение pd.plot, но и позволяет получить удобную интерактивность “бесплатно”.
• Для более глубокого погружения, посмотрите например вот это видео.
• Сообщество так-же готово помочь новоприбывшим в специальном канале slack.