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

I. Вступление

Архитектура распределяет массы и объемы.
Вдохновение превращает инертный камень в драму.
Ле Корбюзье.

Введение (январь 2018)

Вот вы, например. Вы ведь думаете, что после смерти всё кончается, верно?

— Верно… — откликнулось несколько голосов в зале. [...]

— И ток не течет по воздуху. Верно?

— Верно…

— И без Windows или MacOS невозможно производить допечатную подготовку газеты?

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

Лет пятнадцать назад рекламное агентство, где я работал, начал поклёвывать жареный петух по поводу нелицензионного ПО. Шеф прикинул возможности и решил, что сможет выкроить из бюджета сумму на покупку пяти лицензий Windows+Office, одной 1С 7.7 и парочки Corel Draw. Работать при этом на 1С должны были 10 рекламных менеджеров, а Windows была совершенно необходима дизайнерам.

У нас был хороший админ; он тоже прикинул возможности, проконсультировался с коллегами и задумался: зачем конкретно менеджерам-продажниками нужна Windows?

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

Содержание

• Идея статьи
• Отличия бизнес-презентации от презентации для выступления
• 5 советов по созданию качественных бизнес-презентаций
  
  • Используйте интерактивную навигацию
  • 10 слайдов — оптимальное число для бизнес-презентации
  • Ориентация слайда 16:9, а не 4:3
  • Модульная сетка для бизнес-презентации
  • Тёмный фон в бизнес-презентациях: использовать или нет?
• Два особых вида бизнес-презентаций
  
  • Инвестиционная презентация проекта (pitch deck)
  • Коммерческое предложение
• Измеряем эффективность бизнес-презентации и считаем конверсию
• Подведение итогов

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

Получилось несколько интересных сюжетов. Первый из них — это развитие формата и тематики статей за 12 лет существования сайта. Например, достаточно показательна динамика некоторых тем. Продолжение — под катом.

Что мы получим после этой статьи:

Систему сбора и анализа логов на syslog-ng, elasticsearch в качестве хранилища данных, kibana и grafana в качестве систем визуализации данных, kibana для удобного поиска по логам, elasticalert для отправки уведомлений по событиям. Приготовьтесь, туториал объемный.

Какие логи будем собирать:

• все системные логи разложенные по индексам в зависимости от их facility(auth,syslog,messages и т.д.);
• логи nginx — access и error;
• логи pm2;
• и др.

Обоснование выбора системы

Почему я выбрал связку с syslog-ng в качестве отправителя, парсера и приемщика логов? Да потому что он очень быстрый, надежный, не требовательный к ресурсам(да да — logstash в качестве агентов на серверах и виртуальных машинах просто убожество в плане пожирания ресурсов и требованием java), с внятным синтаксисом конфигов(вы видели rsyslog? — это тихий ужас), с широкими возможностями — парсинг, фильтрация, большое количество хранилищ данных(postgresql,mysql,elasticsearch,files и т.д.), буферизация(upd не поддерживает буферизацию), сторонние модули и другие фишки.

Требования:

• Ubuntu 16.04 или debian 8-9;
• vm для развертывания;
• Прямые руки.

Приступим или добро пожаловать под кат

Этот пост — перевод трех частей серии Data acquisition in R из моего англоязычного блога. Исходная серия задумана в четырех частях, три из которых легли в основу данного поста: Использование подготовленных наборов данных; Доступ к популярным статистическим БД; Демографические данные; Демографические данные. В еще не написанной заключительной части речь пойдет об использовании пространственных данных.

R заточен под воспроизводимость результатов. Существует множество прекрасных решений, обеспечивающих сопоставимость версий системы и пакетов, помогающих применять принципы literate programming… Я же хочу показать, как можно легко и эффективно находить/скачивать/добывать данные, используя собственно R и документируя каждый шаг, что обеспечивает полную воспроизводимость всего процесса. Разумеется, я не ставлю перед собой задачи перечислить все возможные источники данных и фокусирую внимание в основном на демографических данных. Если ваши интересы лежат вне сферы статистики населения, стоит посмотреть в сторону великолепного проекта Open Data Task View.

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

В анкетных маркетинговых исследованиях довольно часто встречаются вопросы, в которых респонденты могут выбрать несколько подходящих вариантов из списка возможных ответов (check all that apply questions). Ответы респондентов на такие вопросы задают переменные с множественным откликом (multiple-response variables). Подходящие статистического методы для работы с multiple-response переменными не являются широко известными. В этой статье мы рассмотрим анализ таких переменных на примере данных об автомобильных рейтингах.

Является продолжением предыдущих публикаций.

Естественно, что название является потешным, но, как хорошо известно, в каждой шутке есть доля правды. Сама тема возникла, когда в очередной сотый раз пришлось слышать настойчивое пожелание о том, что необходим «гибкий конструктор отчетов/графиков». После определенного момента проще взять и сделать, чем в очередной раз объяснять, что tidyverse покрывает все необходимые потребности.

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

• интерфейс с большим-большим количеством менюшек и кнопочек, с множественными закулисными IF для управления взаимными состояниями этих элементов;
• «гибкий плоттер» с большим количеством вложенных IF для отрисовки графиков в соотвествии со скормленным данными и положением кнопочек-ползунков, выставленных в UI.

С одной стороны делать «Yet Another Tableau» совершенно неинтересно. С другой стороны, постановка в стиле «сделать так, чтобы все было, но ничего не надо делать» — типичная задача для ТРИЗ.

В целом, после непродолжительных размышений было выработано решение, которое почти удовлетворяет последней постановке. Само Shiny приложение пока под NDA, свободно публикуемый прототип приведен на картинке.

Две ключевых идеи по упрощению задачи следующие (ничего нового, все уже придумано до нас):

1. вместо статически заданного UI переходим к динамически генерируемому;
2. используем интерпретатор R не только для исходного кода, но и внутри самого кода.

Идея 1. Динамический web-интерфейс

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

Сделаем по-другому. Вместо UI элементов со сложным поведением раскидываем с помощью uiOutput placeholder-ы, в которые динамически рассчитываем и генерируем с помощью shiny::renderUI представление этого элемента. Все внешние параметры, требуемые для генерации элемента, трактуем как реактивные элементы (reactive). При этом все такие интерактивные элементы выступают в качестве «автономных агентов», которые смотрят на окружение и подстраиваются под него. Пользователь изменил состояние одного элемента — все зависимые стали пересчитывать по очереди свое состояние (мы явно не обрабатываем события, а используем реактивный подход shiny). При изменении их состояния могут возникнуть новые индуцированные изменения. И так, пока все не стабилизируется.

  observeEvent(input$gen_plot, { # код демонстрирует принцип

    escname <- function(x){
      # имена колонок надо закавычить
      # .....
    }

    point_code <- ""
    if(input$shape_type!="__NO_MAPPING__") {
      aes <- c("shape"=escname(input$aes_shape_col), "color"=escname(input$aes_color_col))
      point_code <- buildPointCode(fixed=c("shape"=input$shape_type, "color"=glue("'{input$plot_color}'")), aes=aes)
    }

    line_code <- ""
    if(input$line_type!="__NO_MAPPING__") {
      aes <- c("linetype"=escname(input$aes_linetype_col), "color"=escname(input$aes_color_col))
      line_code <- buildLineCode(fixed=c("linetype"=input$line_type, "color"=glue("'{input$plot_color}'")), aes=aes)
    }

    gcode <- glue("ggplot(data_df(), aes(x=`{input$x_axis_value}`, y=`{input$y_axis_value}`))\\
                  {point_code} {line_code} + xlab('{input$x_axis_label}')") %>%
      style_text(scope="spaces")

    plot_Rcode(gcode)
  })