Pro Tableau. Визуальная аналитика для бизнеса

1 Star2 Stars (4 votes, average: 4,50 out of 5)
Загрузка...

1

В этой статье пойдёт речь об отличном инструменте для анализа данных — Tableau. Если быть точнее, это не просто инструмент, это — BI платформа, которая, согласно ежегодному авторитетному исследованию Gartner Magic Quadrant for Business Intelligence and Analytics Platforms, является одним из лидеров рынка платформ для бизнес-аналитики. Приведу несколько примеров использования Tableau:

  • Анализ небольшого (до 1 Гб) набора данных на своём компьютере. Источники данных: структурированные файлы, базы данных, различные сервисы (Google Analytics, Amazon,…) и пр. Для этого можно использовать приложение Tableau Desktop.
  • Инфографика для журналистов. Результаты работы можно опубликовать в публичном облаке Tableau Public. Вот интересный пример.
  • Курсовые и дипломные работы по анализу данных для студентов – Tableau Desktop. Этот инструмент не бесплатный, но существует бесплатная лицензия на 1 год для студентов.
  • Корпоративная аналитическая система с использованием Tableau Server или Tableau Online. Интерактивные дэшборды для большинства пользователей и adhoc (selfservice BI) для продвинутых аналитиков.

Я со своими коллегами занимаюсь разработкой и внедрением отчётно-аналитических систем и хранилищ данных для крупных организаций (банки и промышленные предприятия), поэтому статья эта будет больше интересна тем, кто разрабатывает или внедряет корпоративные решения либо планирует этим заняться у себя в организации. К слову, мы для своих прикладных решений используем не только Tableau, но и другие BI платформы (например, Oracle BI). Также стоит отметить, что Tableau – это наш никем не навязанный выбор и при выборе мы детально изучали около десятка других BI продуктов (Qlik Sense, Qlik View, MS BI, Microstrategy и др.).

Я не буду описывать здесь базовые вещи, для этого есть хорошие видеоматериалы. Далее следуют практические советы по использованию Tableau, которые, надеюсь, кому-то пригодятся.

DWH. To be or not to be?!

Сейчас компании-интеграторы очень активно продвигают Tableau и другие похожие продукты (например, Qlik), часто предлагая быстрое внедрение, что естественно не предполагает разработку единого хранилища данных (DWH). Приходят к «Бизнесу», делают небольшой пилотный проект, после чего бизнес-пользователи атакуют ИТ подразделение с требованием поскорее эту «красоту» внедрить. Как временное решение — это вариант, но если думать на перспективу, то аналитику и отчётность в более-менее крупной организации с множеством источников данных однозначно правильнее внедрять на базе хранилища. Тем более, DWH тоже можно внедрять поэтапно с параллельным запуском аналитики.

Также часто встречается точка зрения, что инструменты класса Data Discovery (или modern BI platforms), к которому относится Tableau, не подходят для крупных централизованных аналитических систем. Ниже я приведу пару примеров в подтверждение того, что это не так и Tableau используется в очень масштабных системах.

Если хранилище, то на какой СУБД? На мой взгляд для аналитики идеально подходит хранилище на MPP (massively parallel processing) DB (Teradata, HP Vertica, Greenplum и др.). Мы для новых проектов выбрали HP Vertica, также связка Tableau + Vertica в последнее время стала очень популярна в России. Альтернатива — DWH на реляционной СУБД, мы используем Oracle (ниже подробнее про Oracle).

Отдельно упомяну вариант для очень больших объёмов данных – Apache KylinExtreme OLAP engine for Hadoop. Мы его пока не тестировали, но возможно кто-то в комментариях поделится впечатлениями.

Примеры масштабных внедрений Tableau в СНГ

  • Wargaming (разработчик – World of Tanks) – компания активно развивает много-терабайтное хранилище данных с использованием технологий Big Data (hadoop, kafka, oracle и др.), а для аналитики используется Tableau.
  • YOTA NETWORKS – ещё одно крупное хранилище на HP Vertica и аналитика на Tableau. Короткий комментарий от одного из участников проекта.

Уточню, что к этим проектам я отношения не имею.

Архитектура в части организации доступа к данным (extract vs live)

В Tableau существует 2 варианта подключения к источникам данных:

  • Extract – предварительное извлечение со сжатием всех данных из источника на диск и загрузка в оперативную память. Возможно инкрементальное обновление. Хорошо работает, когда данных не очень много (в пределах объёма оперативной памяти).
  • LiveTableau запрашивает из источника только те данные, которые запросил пользователь (например, генерируются SQL запросы в случае реляционной БД). Это предпочтительный вариант, когда у вас есть DWH с объёмом данных 1 Тб и выше. Но есть существенный нюанс – структуры хранения данных должны быть хорошо оптимизированы для быстрого чтения.

Так как наши решения базируются на DWH, то чаще всего мы используем Live режим. В 2-х словах опишу, что собой представляет хранилище данных в нашей реализации. Состоит оно из следующих основных слоёв:

  • Staging Layer – промежуточный накопитель исходной неочищенной информации из источников.
  • Detail Data Store (DDS) – консолидированная, преобразованная и очищенная детальная информация. Данные хранятся в нормализованном виде (3NF).
  • Access Layer (Data Marts) – детальные данные, производные расчётные показатели, некоторые агрегаты. Используются принципы dimensional modeling (Kimball approach). Основное требование – быстрое чтение данных для отчётов и аналитики.

Запросы Tableau идут на 3-й слой, где данные хранятся в таблицах измерений (dimensions) и фактов (facts/measures). Дополнительным преимуществом такого хранения данных является возможность быстрого описания физической модели данных в Tableau, так как Tableau тоже оперирует понятиями Dimensions & Measures. Называется эта физическая модель Data Source и выглядит примерно так:

2

Подходы по ускорению запросов на примере Oracle DB

Как было отмечено выше, режим Live предполагает, что структура хранения информации в БД должна быть хорошо оптимизирована, иначе запросы будут сильно тормозить. Можно конечно подключить Tableau и к OLTP системе, но будут проблемы с производительностью на значительных объёмах данных. Далее перечислены способы, как можно добиться требуемой производительности в случае использования в качестве источника DB Oracle:

  • Денормализация структуры данных. В итоге Вы получаете более простые и производительные SQL запросы. Как было отмечено выше, мы используем при проектировании Access Layer принципы dimensional modeling (Kimball approach).
  • Опция Oracle Partitioning. На мой взгляд крупное хранилище на Oracle и эта опция — вещи неразрывные. При этом важно помнить, что это платная опция, доступная только в Oracle Enterprise Edition. Суть проста – большие таблицы Вы разбиваете на секции (например, по дате записи), которые физически хранятся отдельно друг от друга и, когда запрашиваются данные за короткий период, сканируются только нужные секции.
  • Настройка параллельного выполнения запросов. Поясню на примере. У Вас есть большая таблица фактов с транзакциями, которая разбита помесячно на partitions. Вы для неё указываете степень параллелизма (ALTER TABLE <table_name> PARALLEL 8;). Какой-то помесячный график в Tableau требует просуммировать все операции из этой таблицы с группировкой по месяцам. В итоге такой запрос будет выполняться в несколько параллельных потоков, что значительно ускоряет запрос (но и требует больше ресурсов сервера). Эта возможность также доступна только в Oracle Enterprise Edition.
  • Materialized views. Если Ваши дэшборды по-прежнему долго формируются, рассмотрите вариант создания материализованных представлений для определённой группы похожих запросов. Materialized views – это технология, когда Oracle сохраняет и может автоматически инкрементально обновлять результаты определенных сложных запросов.
  • Опция Oracle InMemory. Ещё одна платная опция, которая появилась в версии 12.1.0.2. Опция позволяет для определённых таблиц указать, что данные будут дублироваться в оперативной памяти. При этом храниться в памяти они будут не построчно, как в самой таблице, а поколоночно (как например в Vertica), что как раз оптимально для аналитических запросов. Мы пока не используем эту возможность, так как она недавно появилась и на тестах не получили ожидаемого значительного ускорения, но опция многообещающая.

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

Оптимизация производительности на стороне Tableau

В дополнение к предыдущему пункту добавлю, что на стороне Tableau также существует немало возможностей по тонкой настройке производительность. Эти техники неплохо описаны в официальной документации, а также в многочисленных англоязычных блогах по Tableau. Отмечу, что порадовали мощные фичи в части производительности, появившиеся с версии 9.0, среди которых, например:

  • Parallel Queries – когда на дэшборде располагается несколько визуализаций (графиков/таблиц) запросы к данным могут выполняться параллельно;
  • Query Fusion – технология уменьшения количества запросов для сокращения времени загрузки визуализации;
  • External Query Caching – реализованы заметные улучшения по кэшированию результатов запросов.

Ещё в Tableau есть очень полезный инструмент, который помогает оптимизировать дэшборды: Help > Settings and Perfomance > Start/Stop Perfomance Recording. Инструмент позволяет проанализировать все этапы формирования дэшборда: посмотреть, какие запросы отправляются в БД; сколько времени они выполняются; какое время занимает прорисовка графиков и некоторые другие события. На картинке пример такого анализа, где сравнивается формирование 1-го дэшборда в разных версиях Tableau (демонстрируются улучшения 9-й версии):

3

Эффектная визуализация

На мой взгляд, намного приятнее и интереснее анализировать данные, когда инструмент предоставляет возможность создания эффектной, красивой и интерактивной визуализации. И Tableau как раз тот инструмент, который в этом очень хорош. К примеру, по версии ресурса InformationIsBeautiful.net Tableau Public вошёл в 3-ку лучших Free Dataviz Tool 2015 вместе с D3.js и R. Приведу ещё примеры наших дэшбордов.

Также стоит отметить, что Tableau позволяет интегрировать (встраивать) дэшборды в Ваши web приложения, что продемонстрировано в видео:

Ложка дегтя в бочке меда

Про многочисленные преимущества Tableau Вы можете прочитать самостоятельно, я же отмечу недостатки продукта, которые существенны для нас и которые, мы надеемся, будут устранены в будущих версиях:

  1. Отсутствие возможности «рисовать» отчёты строгой формы (pixel perfect reporting). Мы разрабатываем комплексные отчётно-аналитические решения и пока используем инструмент своей разработки для таких отчётов. Будет здорово, если кто-то поделится опытом использования хорошего opensource инструмента.
  2. Отсутствие локализации на русский язык (важно для некоторых наших клиентов).
  3. Tableau Server доступен только для Windows. Ждём версии для Linux.
  4. Визуализации и дэшборды можно создавать 2-мя способами: Tableau Desktop и через webbrowser в случае использования Tableau Server. Удобнее 1-й вариант, а хотелось более продвинутого интерфейса в «тонком» клиенте.

В заключение

Цель данной статьи не только в том, чтобы помочь кому-то полезным советом в использовании Tableau. Хотелось бы также услышать альтернативные мнения и Ваш опыт. Если будет интерес к данной теме, я и мои коллеги постараемся осветить эти и другие вопросы более подробно.

Спасибо за Ваше время!

Автор: Максим Крупенин, начальник управления BI и CRM-систем СООО «Системные технологии»

Автор публикации

не в сети 3 дня

Лариса Шурига

Комментарии: 16Публикации: 871Регистрация: 05-06-2014

Вам также может понравиться

Добавить комментарий

Ваш e-mail не будет опубликован.

закрыть

Поделиться

Отправить на почту
закрыть

Вход

закрыть

Регистрация

+ =
Авторизация
*
*

Login form protected by Login LockDown.


Регистрация
*
*
*
*
Генерация пароля