В этой статье пойдёт речь об отличном инструменте для анализа данных — 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. Интерактивные дэшборды для большинства пользователей и ad—hoc (self—service 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 Kylin — Extreme 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 – предварительное извлечение со сжатием всех данных из источника на диск и загрузка в оперативную память. Возможно инкрементальное обновление. Хорошо работает, когда данных не очень много (в пределах объёма оперативной памяти).
- Live – Tableau запрашивает из источника только те данные, которые запросил пользователь (например, генерируются 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 и выглядит примерно так:
Подходы по ускорению запросов на примере Oracle DB
Как было отмечено выше, режим Live предполагает, что структура хранения информации в БД должна быть хорошо оптимизирована, иначе запросы будут сильно тормозить. Можно конечно подключить Tableau и к OLTP системе, но будут проблемы с производительностью на значительных объёмах данных. Далее перечислены способы, как можно добиться требуемой производительности в случае использования в качестве источника DB Oracle:
- Денормализация структуры данных. В итоге Вы получаете более простые и производительные SQL запросы. Как было отмечено выше, мы используем при проектировании Access Layer принципы dimensional modeling (Kimball approach).
- Опция Oracle Partitioning. На мой взгляд крупное хранилище на Oracle и эта опция — вещи неразрывные. При этом важно помнить, что это платная опция, доступная только в Oracle Enterprise Edition. Суть проста – большие таблицы Вы разбиваете на секции (например, по дате записи), которые физически хранятся отдельно друг от друга и, когда запрашиваются данные за короткий период, сканируются только нужные секции.
-
Настройка параллельного выполнения запросов. Поясню на примере. У Вас есть большая таблица фактов с транзакциями, которая разбита помесячно на partitions. Вы для неё указываете степень параллелизма (ALTER TABLE
PARALLEL 8;). Какой-то помесячный график в Tableau требует просуммировать все операции из этой таблицы с группировкой по месяцам. В итоге такой запрос будет выполняться в несколько параллельных потоков, что значительно ускоряет запрос (но и требует больше ресурсов сервера). Эта возможность также доступна только в Oracle Enterprise Edition. - Materialized views. Если Ваши дэшборды по-прежнему долго формируются, рассмотрите вариант создания материализованных представлений для определённой группы похожих запросов. Materialized views – это технология, когда Oracle сохраняет и может автоматически инкрементально обновлять результаты определенных сложных запросов.
- Опция Oracle In—Memory. Ещё одна платная опция, которая появилась в версии 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-й версии):
Эффектная визуализация
На мой взгляд, намного приятнее и интереснее анализировать данные, когда инструмент предоставляет возможность создания эффектной, красивой и интерактивной визуализации. И Tableau как раз тот инструмент, который в этом очень хорош. К примеру, по версии ресурса InformationIsBeautiful.net Tableau Public вошёл в 3-ку лучших Free Dataviz Tool 2015 вместе с D3.js и R. Приведу ещё примеры наших дэшбордов.
Также стоит отметить, что Tableau позволяет интегрировать (встраивать) дэшборды в Ваши web приложения, что продемонстрировано в видео:
Ложка дегтя в бочке меда
Про многочисленные преимущества Tableau Вы можете прочитать самостоятельно, я же отмечу недостатки продукта, которые существенны для нас и которые, мы надеемся, будут устранены в будущих версиях:
- Отсутствие возможности «рисовать» отчёты строгой формы (pixel perfect reporting). Мы разрабатываем комплексные отчётно-аналитические решения и пока используем инструмент своей разработки для таких отчётов. Будет здорово, если кто-то поделится опытом использования хорошего open—source инструмента.
- Отсутствие локализации на русский язык (важно для некоторых наших клиентов).
- Tableau Server доступен только для Windows. Ждём версии для Linux.
- Визуализации и дэшборды можно создавать 2-мя способами: Tableau Desktop и через web—browser в случае использования Tableau Server. Удобнее 1-й вариант, а хотелось более продвинутого интерфейса в «тонком» клиенте.
В заключение
Цель данной статьи не только в том, чтобы помочь кому-то полезным советом в использовании Tableau. Хотелось бы также услышать альтернативные мнения и Ваш опыт. Если будет интерес к данной теме, я и мои коллеги постараемся осветить эти и другие вопросы более подробно.
Спасибо за Ваше время!
Автор: Максим Крупенин, начальник управления BI и CRM-систем СООО «Системные технологии»