Tableau

У каждого бизнеса возникает потребность в качественной аналитике данных и ее визуализации. Еще один важный фактор, который следует учитывать это простота использования для бизнес-пользователя. Инструмент не должен требовать дополнительных затрат на обучение сотрудников на начальном этапе. Одним из таких решений является Tableau.

Сервис Работа.ру выбрал Tableau для многофакторного анализа данных. Мы поговорили с Алёной Артемьевой, директором по аналитике сервиса Работа.ру и узнали как изменилась аналитика после внедренного командой BI GlowByte решения.

Q: Как возникла потребность в решении BI?

Алёна Артемьева: В конце прошлого года команда сервиса Работа.ру начала стремительно расти. Именно тогда возросла потребность в качественной и понятной для всех аналитике со стороны самых разных подразделений и руководства компании. Мы осознали необходимость создания единого и удобного для всех пространства аналитических материалов (ad hoc исследований и регулярных отчетов) и начали активно двигаться в этом направлении.

Q: На основании каких критериев выполнялся поиск BI-решения и кто принимал участие в оценке?

АА: Важнее всего для нас были следующие критерии:

• наличие автономного сервера для хранения данных;
• стоимость лицензий;
• наличие десктоп-клиента Windows/iOS;
• наличие mobile-клиента Android/iOS;
• наличие веб-клиента;
• возможность интеграции в приложение/портал;
• возможность использования скриптов;
• простота/сложность инфраструктурной поддержки и необходимость / отсутствие необходимости поиска специалистов для этого;
• распространенность BI-решений среди пользователей;
• отзывы пользователей BI-решений.

Q: Кто принимал участие в оценке:

АА: Это была совместная работа команд аналитиков и ML Работы.ру.

Q: К какой функциональной области относится решение?

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

Q: Какую проблему (задачи) решали?

АА: Tableau помог нам решить несколько ключевых задач:

• Повысить скорость обработки данных.
• Отойти от ручного создания и обновления отчетности.
• Повысить прозрачность данных.
• Повысить доступность данных для всех ключевых сотрудников.
• Получить возможность оперативно реагировать на изменения и принимать решения на основе данных.
• Получить возможность более подробно анализировать продукт и искать точки роста.

Q: Что было до Tableau? Какие технологии использовали?

АА: Ранее мы, как и многие компании, для визуализации ключевых показателей активно использовали Google Sheets и Excel, а также собственные разработки. Но постепенно мы поняли, что такой формат нам не подходит. В первую очередь из-за низкой скорости обработки данных, а также из-за ограниченных возможностей визуализации, проблем с безопасностью, необходимости постоянной обработки большого количества данных вручную и нерационального использования времени сотрудников, высокой вероятности ошибки и проблем с обеспечением общего доступа к отчетам (последнее наиболее актуально для отчетов в Excel). Также в них невозможно обрабатывать большие массивы данных.

Q: Как происходило внедрение решения?

АА: Мы начали с того, что самостоятельно раскатили серверную часть и начали делать отчеты, соединяя данные из витрин с подготовленными данными на PostgreSQL. Через несколько месяцев передали сервер на поддержку в инфраструктуру.

Q: Какие департаменты первыми подключились к проекту, было ли это сложно?

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

Q: Кто участвовал в команде внедрения?

АА: В основном это была команда ML.

Q: Требовалась ли подготовка сотрудников?

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

Q: Какова сложность освоения?

АА: Для нас всё прошло относительно легко, а платформа оказалась интуитивно понятна всем.

Q: Как быстро получили первый результат?

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

Q: Какие показатели по итогам проекта уже есть?

АА: Мы уже реализовали более 130 отчетов по различным направлениям и в несколько раз повысили скорость подготовки данных. Это оказалось важно и для специалистов нашего PR-подразделения, так как теперь мы можем быстро отвечать на большинство актуальных запросов от СМИ, выпускать объемные исследования по рынку труда в целом и по отдельным отраслям, а также готовить ситуативную аналитику.

Q: Как планируете развивать систему? Какие отделы будут вовлечены в проект?

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

Инструменты Business Intelligence (BI) за последние несколько лет проникли почти во все виды бизнеса, а изучению данных уделяется все больше внимания и выделяется больше ресурсов. Если говорить об IT-компаниях, то здесь, наверное, большинству понятно предназначение Business Intelligence и то, какую ценность для компании представляет анализ внутренних данных.



В Playrix на подготовку и анализ данных выделяется значительное количество ресурсов, мы стараемся использовать передовые технологии и серьёзно подходим к обучению сотрудников. Компания входит в топ-3 разработчиков мобильных игр в мире, поэтому мы стараемся держать соответствующий уровень в анализе данных и конкретно в Business Intelligence. Ежедневно в наши игры играют более 27 млн пользователей, и эта цифра может дать примерное представление об объемах данных, генерируемых мобильными устройствами каждый день. Кроме этого, данные забираются из десятков сервисов в различных форматах, после чего они агрегируются и загружаются в наши хранилища. В качестве Data Lake мы работаем с AWS S3, а Data Warehouse на AWS Redshift и PostgreSQL применяется ограниченно. Эти базы данных мы используем для аналитики. Redshift быстрее, но дороже, поэтому там мы храним самые востребованные данные. PostgreSQL дешевле и медленнее, там хранятся либо небольшие объемы данных, либо данные, скорость чтения которых некритична. Для предагрегированных данных используем Hadoop кластер и Impala.

Основным инструментом BI в Playrix является Tableau. Этот продукт достаточно хорошо известен в мире, имеет широкие возможности для анализа и визуализации данных, работы с различными источниками. Кроме того, для простых задач анализа не приходится писать код, поэтому можно обучить пользователей разных отделов самостоятельно анализировать свои бизнес-данные. Сам вендор инструмента Tableau Software также позиционирует свой продукт как инструмент для самостоятельного анализа данных, то есть для Self-Service.

Есть два основных подхода анализа данных в BI:

1. Reporting Factory. В этом подходе есть отдел и/или люди, разрабатывающие отчеты для бизнес-пользователей.
2. Self-Service. В этом подходе бизнес-пользователи делают отчеты и строят аналитику своих процессов самостоятельно.

Первый подход традиционный, и в большинстве компаний работает такая фабрика производства отчетов в масштабах всего предприятия. Второй подход относительно новый, особенно для России. Хорош он тем, что данные исследуют сами бизнес-пользователи они намного лучше знают свои локальные процессы. Это помогает разгружать разработчиков, избавлять их от необходимости каждый раз погружаться в особенности процессов команд и заниматься созданием самых простых отчетов. Это помогает решить, наверное, самую большую проблему проблему преодоления пропасти между бизнес-пользователями и разработчиками. Ведь основная проблема подхода Reporting Factory как раз в том, что большая часть отчетов может остаться невостребованной только из-за того, что программисты-разработчики неверно понимают проблемы бизнес-пользователей и, соответственно, создают ненужные отчеты, которые либо переделываются потом, либо просто не используются.

В Playrix изначально разработкой отчетов в компании занимались программисты и аналитики, то есть специалисты, ежедневно работающие с данными. Но компания развивается очень стремительно, и по мере роста потребностей пользователей в отчетах разработчики отчетов перестали успевать в срок решать все задачи по их созданию и поддержке. Тогда и встал вопрос либо о расширении группы разработки BI, либо о передаче компетенций в другие отделы. Направление Self Service нам казалось перспективным, поэтому мы решили научить бизнес-пользователей самостоятельно создавать свои проекты и анализировать данные.

В Playrix подразделение Business Intelligence (BI Team) работает над задачами:

1. Сбора, подготовки и хранения данных.
2. Разработки внутренних сервисов аналитики.
3. Интеграции с внешними сервисами.
4. Разработки web-интерфейсов.
5. Разработки отчетности в Tableau.

Мы занимаемся автоматизацией внутренних процессов и аналитики. Упрощенно нашу структуру можно представить при помощи схемы:


Мини-команды BI Team

Прямоугольниками здесь обозначены мини-команды. Слева команды бэка, справа команды фронта. Каждая из них обладает достаточными компетенциями для работы с задачами смежных команд и берут их на себя при перегруженности остальных команд.

В BI Team построен полный цикл разработки: от сбора требований до разворачивания на продуктовом окружении и последующей поддержки. В каждой мини-команде есть свой системный аналитик, разработчики и инженеры по тестированию. Они выполняют функцию Reporting Factory, подготавливая данные и отчеты для внутреннего использования.

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

Передача компетенций и запуск пилотного проекта

По нашему опыту работы и общения с другими компаниями основными проблемами при передаче data-компентенций бизнес-пользователям становятся:

1. Нежелание самих пользователей изучать новые инструменты и работать с данными.
2. Отсутствие поддержки со стороны менеджмента (инвестиции в обучение, лицензии и т.п.).

Поддержка со стороны менеджмента у нас колоссальная, более того, менеджмент и предложил внедрять Self-Service. Желание у пользователей изучать работу с данными и Tableau тоже есть это ребятам интересно, плюс анализ данных сейчас очень существенный скилл, который большинству точно пригодится в будущем.

Внедрение новой идеологии сразу во всей компании обычно требует много ресурсов и нервов, поэтому мы начали с пилота. Пилотный проект Self-Service запустили в отделе User Acquisition полтора года назад и в процессе пилота копили ошибки и опыт, чтобы передать их другим отделам в будущем.

Направление User Acquisition работает над задачами увеличения аудитории наших продуктов, анализирует пути закупки трафика и выбирает, в какие направления привлечения пользователей стоит инвестировать средства компании. Раньше для этого направления готовились отчеты командой BI, либо ребята сами обрабатывали выгрузки из базы при помощи Excel или Google Sheets. Но в динамичной среде развития такой анализ влечет задержки, а число анализируемых данных лимитировано возможностями этих инструментов.

На старте пилота мы провели базовое обучение сотрудников работе с Tableau, сделали первый общий источник данных таблицу в базе Redshift, в которой было более 500 млн строк и необходимые метрики. Следует отметить что Redshift это столбчатая (или колоночная) база данных, и эта база отдает данные намного быстрее реляционных БД. Пилотная таблица в Redshift была действительно большой для людей, которые никогда больше чем с 1 млн строк одновременно не работали. Но это был вызов для ребят, чтобы научиться работать с данными таких объемов.

Мы понимали, что проблемы с производительностью начнутся по мере усложнения этих отчетов. Доступа к самой БД пользователям мы не давали, но был реализован источник на сервере Tableau, подключенный в режиме live к таблице в Redshift. У пользователей были лицензии Creator, и они могли подключаться к этому источнику либо с сервера Tableau, разрабатывая отчеты там, либо с Tableau Desktop. Надо сказать, что при разработке отчетов в вебе (у Tableau есть режим web edit) на сервере есть некоторые ограничения. На Tableau Desktop же таких ограничений нет, поэтому мы преимущественно разрабатываем на Desktop. Кроме того, если анализ нужен только одному бизнес-пользователю, не обязательно такие проекты публиковать на сервере можно работать локально.

Обучение

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

Для всех пользователей, у которых есть лицензии Tableau, мы провели и записали получасовой вебинар по работе с сервером и дашбордами. В нем рассказали о проектах на сервере, работе с нативными контролами всех дашбордов это верхняя панель (refresh, pause, ). Об этом обязательно надо рассказывать всем пользователям Tableau, чтобы они полноценно могли работать с нативными возможностями и не делали запросы на разработку фич, которые повторяют работу нативных контролов.

Основным препятствием для освоения какого-то инструмента (да и вообще чего-то нового) обычно является страх того, что не получится разобраться и работать с этим функционалом. Поэтому обучение, пожалуй, является самым важным этапом внедрения подхода self-service BI. От него будет сильно зависеть результат внедрения этой модели приживется ли она в компании вообще и если да, то насколько быстро. На стартовых вебинарах как раз и надо снять барьеры использования Tableau.

Можно выделить две группы вебинаров, которые мы проводили для людей, не знакомых с работами баз данных:

1. Стартовый набор знаний новичка:
   
   
   • Подключение к данным, типы соединений, типы данных, базовые преобразования данных, нормализация данных (1 час).
   • Базовые визуализации, агрегация данных, базовые вычисления (1 час).
2. Сложные вычисления и базовые трюки/элементы, принятые в компании (2 часа).

В первом стартовом вебинаре мы рассматриваем все, что касается подключения к данным и преобразования данных в Tableau. Поскольку у людей обычно есть базовый уровень владения MS Excel, то здеcь важно объяснить, чем принципиально отличается работа в Excel от работы в Tableau. Это очень важный пункт, поскольку нужно переключить человека с логики таблиц с раскрашенными ячейками на логику нормализованных данных БД. На этом же вебинаре мы объясняем работу JOIN, UNION, PIVOT, также затрагиваем Blending. На первом вебинаре мы практически не затрагиваем визуализацию данных, его цель объяснить, как работать и преобразовывать свои данные для Tableau. Важно, чтобы люди понимали, что данные первичны и большинство проблем возникает на уровне данных, а не на уровне визуализаций.

Второй вебинар по Self-Service имеет целью рассказать о логике построения визуализаций в Tableau. Tableau сильно отличается от других BI инструментов именно тем, что имеет свой движок и свою логику. В других системах, например, в PowerBI, есть набор готовых визуалов (можно скачать дополнительные модули в магазине), но эти модули не кастомизируются. В Tableau же у вас есть фактически чистый лист, на котором можно строить все что угодно. Конечно же, в Tableau есть ShowMe меню базовых визуализаций, но все эти графики и диаграммы можно и нужно строить по логике работы Tableau. По нашему мнению, если хотите научить кого-то работать с Tableau, то не нужно использовать ShowMe для построения графиков большая их часть людям не пригодится на старте, а нужно учить именно логике построения визуализаций. Для бизнес-дашбордов достаточно знать, как построить:

1. Time Series. Line/Area Charts (линейные графики),
2. Bar Charts (столбчатые диаграммы),
3. Scatter Plots (диаграммы разброса),
4. Tables (таблицы).

Этого набора визуализаций вполне достаточно для самостоятельного анализа данных.

Time Series: в бизнесе применяются очень часто, поскольку интересно сравнивать метрики в различные периоды времени. У нас в динамике результаты бизнеса смотрят, наверное, все сотрудники компании. Bar Charts используем для сравнения метрик по категориям. Scatter Plots (диаграмма разброса) используются редко, обычно для нахождения корреляций между метриками. Таблицы: то, от чего в бизнес-дашбордах полностью избавиться не удается, но по возможности стараемся минимизировать их число. В таблицах собираем числовые значения метрик по категориям.

То есть мы отправляем людей в свободное плавание после 1 часа обучения работы с данными и 1 часа обучения базовым вычислениям и визуализациям. Далее ребята сами работают со своими данными некоторое время, сталкиваются с проблемами, накапливают опыт, просто набивают руку. Этот этап в среднем занимает 2-4 недели. Естественно, в этот период есть возможность проконсультироваться с командой BI Team, если что-то не получается.

После первого этапа у коллег возникает необходимость совершенствования навыков и изучения новых возможностей. Для этого мы подготовили вебинары углубленного обучения. В них мы показываем, как работать с функциями LOD, табличными функциями, скриптами Python для TabPy. Мы работаем с живыми данными компании, это всегда интереснее фейковых или данных базового датасета Tableau Superstore. В этих же вебинарах мы рассказываем об основных фичах и трюках Tableau, которые используются на продовых дашбордах, например:

1. Sheet Swapping (замена листов),
2. Агрегация графиков при помощи параметров,
3. Форматы дат и метрик,
4. Отбрасывание неполных периодов при недельных/месячных агрегациях.

Все эти трюки и фичи было принято использовать пару лет назад, поэтому в компании все к ним привыкли, и мы приняли их в стандартах разработки дашбордов. Скрипты Python мы используем для расчета некоторых внутренних метрик, все скрипты уже готовы, и для Self-Service надо понимать, как их вставлять в свои вычисления.

Таким образом, мы проводим только 4 часа вебинаров для старта Self-Service, и этого обычно достаточно, чтобы мотивированный человек начал работать с Tableau и самостоятельно анализировать данные. Кроме того, для дата-аналитиков у нас есть свои вебинары, они находятся в открытом доступе, можно знакомиться и с ними.

Разработка источников данных для Self-Service

После проведения пилотного проекта мы посчитали его успешным и расширили количество пользователей Self-Service. Одной из больших задач была подготовка источников данных для разных команд. Ребята в Self-Service могут работать с 200+ млн строк, поэтому команда Data Engineering должна была придумать, как реализовать такие источники данных. Для большинства аналитических задач мы используем Redshift из-за скорости чтения данных и удобства работы. Но выдавать доступ к базе каждому человеку из Self-Service было рискованно с точки зрения информационной безопасности.

Первой идеей было создание источников с живым подключением к БД, то есть на Tableau Server было опубликовано несколько источников, которые смотрели либо в таблицы, либо в подготовленные view Redshift. В этом случае мы не хранили данные на сервере Tableau, а пользователи через эти источники сами ходили со своих Tableau Desktop (клиентов) в базу. Это работает, когда таблицы небольшие (единицы миллионов) или запросы Tableau не слишком сложные. По мере развития ребята начали усложнять в Tableau свои дашборды, использовать LODы, кастомные сортировки, скрипты Python. Естественно, это привело к замедлению работы некоторых Self-Service дашбордов. Поэтому через несколько месяцев после старта Self-Service мы пересмотрели подход к работе с источниками.

В новом подходе, который мы применяем до сих пор, были реализованы опубликованные на Tableau Server экстракты. Надо сказать, что у Self-Service постоянно возникают новые задачи, и от них поступают запросы на добавление новых полей в источник, естественно, источники данных постоянно модифицируются. Мы выработали следующую стратегию работы с источниками:

1. По ТЗ на источник со стороны Self-Service собираются данные в таблицах баз данных.
2. Создается нематериализованное представление (view) в тестовой схеме БД Redshift.
3. Представление тестируется на корректность данных командой QA.
4. В случае положительного результата проверки представление поднимается на продовой схеме Redshift.
5. Команда Data Engineering берет view на поддержку подключаются скрипты анализа валидности данных, сигналы алармирования ETL, выдаются права на чтение команде Self-Service.
6. На Tableau Server публикуется источник (экстракт), подключенный к этому представлению.
7. Заводятся сигналы ETL на запуск экстракта.
8. Источник описывается в базе знаний.
9. Описание источника, вся информация для подключения и работы передается команде Self-Service.

Немного про пункт 7. Нативно Tableau позволяет создавать экстракты по расписанию с минимальной разницей в 5 минут. Если вы точно знаете, что ваши таблицы в БД обновляются всегда в 4 часа утра, то вам можно просто поставить экстракт на 5 часов утра, чтобы ваши данные собрались. Это покрывает ряд задач. В нашем случае таблицы собираются по данным от различных провайдеров в том числе. Соответственно, если один провайдер либо наш внутренний сервис не успели обновить свою часть данных, то вся таблица считается невалидной. То есть нельзя просто установить расписание на фиксированное время. Поэтому мы используем API Tableau для запуска экстрактов по готовности таблиц. Сигналы запусков экстрактов формирует наш сервис ETL после того, как убедится в том, что все новые данные пришли и они валидны.

Такой подход позволяет иметь в экстракте свежие валидные данные с минимальной задержкой.

Публикация дашбордов Self-Service на Tableau Server

Мы сознательно не ограничиваем людей в экспериментах со своими данными и позволяем публиковать свои воркбуки, делиться ими. Внутри каждой команды, если человек посчитает, что его дашборд полезен другим, либо дашборд нужен этому сотруднику на сервере, он может его опубликовать. Команда BI не вмешивается во внутренние эксперименты команд, соответственно, всю логику работы дашбордов и вычисления они прорабатывают сами. Есть cлучаи, когда из Self-Service вырастает интересный проект, который потом полностью передается на поддержку команды BI и переходит на прод. Это как раз и есть тот самый эффект Self-Service, когда люди, хорошо разбираясь в своих бизнеc-задачах, начинают работать со своими данными и формируют новую стратегию своей работы. Исходя из этого мы сделали следующую схему проектов на сервере:


Схема проектов на Tableau Server

Каждый пользователь с лицензией Creator может публиковать свои воркбуки на сервер либо делать анализ локально. Для Self-Service мы сделали свою песочницу (Sandbox) со своими группами проектов.

Сайты в Tableau идеологически разделены так, чтобы пользователи одного сайта не видели контент другого, поэтому мы разделили сервер на сайты по направлениям, которые не пересекаются: например, игровая аналитика и финансы. Мы используем групповой доступ. В каждом сайте есть проекты, в которых права на их воркбуки и источники наследуются. То есть группa пользователей Group 1 видит только свои воркбуки и источники данных. Исключением из этого правила является сайт Sandbox, который имеет еще и подпроекты. Sandbox мы используем для прототипирования, разработки новых дашбордов, их тестирования и для нужд Self-Service. Все, у кого есть доступ на публикацию в своем проекте Sandbox, могут публиковать свои прототипы.

Мониторинг источников и дашбордов на Tableau Server

Поскольку мы перенесли нагрузку запросов Self-Service дашбордов с базы на Tableau Server, работаем с большими источниками данных и не ограничиваем людей по запросам к опубликованным источникам, то появилась другая проблема мониторинг быстродействия таких дашбордов и мониторинг созданных источников.

Мониторинг быстродействия дашбордов и быстродействия серверов Tableau задача, с которой сталкиваются средние и большие компании, поэтому про быстродействие дашбордов и его тюнинг написано достаточно много статей. Мы пионерами в этой области не стали, наш мониторинг это несколько дашбордов на базе внутренней БД PostgreSQL Tableau Server. Этот мониторинг работает со всем контентом, но можно выделить дашборды Self-Service и посмотреть их быстродействие.

Проблемы оптимизации дашбордов команда BI Team решает периодически. Пользователи иногда приходят с вопросом Почему медленно работает дашборд?, и нам нужно понимать, что такое медленно с точки зрения пользователя и какие числовые критерии могут характеризовать это медленно. Чтобы не интервьюировать пользователя и не отнимать его рабочее время для подробного пересказа проблем, мы мониторим и анализируем http-запросы, находим самые медленные и выясняем причины. После чего оптимизируем дашборды, если это может привести к увеличению производительности. Понятно что при живом подключении к источникам будут задержки, связанные с формированием view в базе задержки получения данных. Есть еще сетевые задержки, которые исследуем с нашей командой поддержки всей IT инфраструктуры, но в этой статье на них мы останавливаться не будем.

Немного о http requests

Каждое взаимодействие пользователя с дашбордом в браузере инициирует свой http request, передаваемый на Tableau Server. Вся история таких запросов хранится во внутренней БД PostgreSQL Tableau Server, срок хранения по умолчанию 7 дней. Этот срок можно увеличить изменениями настроек Tableau Server, но мы не хотели увеличивать таблицу http-запросов, поэтому просто собираем инкрементальный экстракт, в который укладываются только свежие данные каждый день, старые при этом не затираются. Это хороший способ с минимумом ресурсов держать в экстракте на сервере исторические данные, которых уже нет в базе.

Каждый http request имеет свой тип (action_type). Например, _bootstrap первоначальная загрузка view, relative-date-filter фильтр дат (слайдер). По названию можно определить большинство типов, поэтому понятно, что каждый пользователь делает с дашбордом: кто-то больше смотрит тултипы, кто-то меняет параметры, кто-то делает свои custom_view, а кто-то выгружает данные.

Ниже показан наш сервисный дашборд, который позволяет определять медленные дашборды, медленные типы запросов и пользователей, которым приходится ждать.


Дашборд мониторинга http-запросов

Мониторинг VizQL-сессий

Когда открывается какой-то дашборд в браузере, на сервере Tableau запускается VizQL сессия, в рамках которой происходит отрисовка визуализаций, также выделяются ресурсы на поддержание сессии. Такие сессии отбрасываются через 30 минут простоя по умолчанию.

По мере увеличения пользователей на сервере и внедрения Self-Service мы получили несколько пожеланий для увеличения лимитов сессий VizQL. Проблема пользователей была в том, что они открывали дашборды, устанавливали фильтры, что-то смотрели и переходили к другим своим задачам вне Tableau Server, после какого-то времени они возвращались к открытым дашбордам, но они сбрасывались на дефолтный вид, и приходилось заново их настраивать. Наша задача была сделать работу пользователей более комфортной и убедиться, что нагрузка на сервер не возрастает критически.

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

vizqlserver.session.expiry.minimum 5

Number of minutes of idle time after which a VizQL session is eligible to be discarded if the VizQL process starts to run out of memory.

vizqlserver.session.expiry.timeout 30 Number of minutes of idle time after which a VizQL session is discarded.

Поэтому мы решили сделать мониторинг VizQL сессий и отслеживать:

1. Количество сессий,
2. Количество сессий на пользователя,
3. Среднюю длительность сессий,
4. Максимальную длительность сессий.

Кроме того, нам нужно было понимать, в какие дни и какие часы открывается самое большое количество сессий.

Получился такой дашборд:


Дашборд мониторинга VizQL сессий

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

vizqlserver.session.expiry.minimum 120vizqlserver.session.expiry.timeout 240

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

Тепловые карты этого дашборда также позволяют нам планировать сервисные работы в часы минимальной востребованности сервера.

Изменение нагрузки на кластер CPU и RAM мы мониторим в Zabbix и AWS console. Значительных изменений нагрузки в процессе увеличения таймаутов мы не зафиксировали.

Если говорить о том, что может сильно нагнуть ваш Tableau сервер, то это может быть, например, неоптимизированный дашборд. Постройте, к примеру, в Tableau таблицу в десяток тысяч строк по категориям и id каких-нибудь событий, а в Measure используйте LOD вычисления на уровне id. С высокой вероятностью отображение таблицы на сервере не отработает, и вы получите вылет с Unexpected Error, поскольку все LODы в минимальной грануляции будут очень сильно потреблять память, и очень скоро процесс упрется в 100% потребления памяти.

Этот пример здесь приведен для того, чтобы было понятно, что один неоптимальный дашборд может съедать все ресурсы сервера, а даже 100 VizQL сессий оптимальных дашбордов не будут потреблять столько ресурсов.

Мониторинг источников данных сервера

Выше мы отмечали, что для Self-Service мы подготовили и опубликовали на сервере несколько источников данных. Все источники экстракты данных. Опубликованные источники сохраняются на сервере, и к ним предоставляется доступ ребятам, которые работают с Tableau Desktop.

В Tableau есть возможность помечать источники как сертифицированные. Так делает команда BI, когда готовит источники данных для Self-Service. Это гарантирует, что сам источник был протестирован.

Опубликованные источники могут достигать 200 млн строк и 100 полей. Для Self-Service это очень большой объем, поскольку не так много компаний имеет источники таких объемов для самостоятельной аналитики.

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

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


Дашборд мониторинга источников

Итог

Мы используем подход Self-Service 1,5 года. За это время 50 пользователей стали самостоятельно работать с данными. Это снизило нагрузку на BI Team и позволило ребятам не ждать, пока BI Team дойдет до конкретно их задачи по разработке дашборда. Примерно 5 месяцев назад мы стали подключать другие направления к самостоятельной аналитике.

В наших планах проведение обучения по data literacy и лучшим практикам визуализаций.

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

Мы хотим рассказать вам о том, как мы помогли нашей BI-команде организовать автоматический процесс доставления данных на Tableau-сервер из MongoDB, используя таблошный формат хранения данных hyper, а сам процесс настройки формирования данных осуществляется через простой веб-интерфейс.

В начале коротко расскажем, как выглядел процесс до и после того, как мы научили наш внутренний продукт А1 программно собирать датасорсы и публиковать их на Tableau Server. Затем подробнее разберем проблему BI-команды и найденное решение, а также заглянем под капот (здесь о создании .hyper файла, публикации файла на tableau-сервере и обновлении хайпера). Добро пожаловать под кат!



Мы в рекламной группе DAN много работаем с данными мониторинга рекламы от Mediascope, индустриального измерителя на медиарынке. Сценарии бывают разные: некоторые сотрудники выгружают сырые данные, другие пользуются готовыми предобработанными базами, а кто-то заказывает разработку автоматизированных дашбордов на этих данных. О последнем сценарии расскажем подробнее дашборды наши BI-разработчики собирают в Tableau, но прежде чем начать рисовать, им тоже необходимо привести данные к нужному удобному для разработки формату.

Жизненный путь данных от сырья до красивых автоматизированных графиков можно условно разбить на 4 шага:

1. Получение сырых данных
2. Чистка и доработка данных
3. Создание источников данных для Tableau
4. Разработка визуализаций

Было

До того, как мы научились программно генерировать источники данных для Tableau, процесс выглядел так:

1. Получение сырых данных
Пользователи формируют табличные-отчеты через внутренний инструмент А1. О нем мы подробнее расскажем далее.

2. Чистка и доработка данных
Возможность трансформации данных также заложена в инструмент А1, после чего очищенные данные можно выгрузить в xslx/csv и продолжить с ними работу вне инструмента. Тут стоит отметить, что некоторые пользователи ограничиваются 1ым пунктом и после выгрузки отчетов дорабатывают данные своими силами.

3. Создание источников данных для Tableau
Раньше заказчики дашбордов приходили с набором экселей, которые они сгенерировали на предыдущих пунктах. А BI-разработчики сводили эти эксели в единый датасорс (таблошный сленг) своими силами. Не всегда удавалось ограничиться только инструментами Tableau, часто писали скрипты на Python.

4. Разработка визуализаций
Наконец, вершина айсберга создание дашборда и публикация его на Tableau Server, где его увидит заказчик. На практике визуализация часто занимает меньше времени, чем сбор данных и настройка обновлений.

Боль копилась на третьем шаге, так как росло количество кастомных решений, которые было затратно поддерживать и реализовывать. Также регулярно просачивались ошибки в данных со второго шага промежуточный эксель между двух систем (А1 и Tableau) прямо-таки подталкивал пользователя: давай поправь что-нибудь ручками, никто не заметит.

Стало

Основной задачей было исключить эксели между 2 и 3 шагом. В итоге мы научили А1 собирать датасорсы и публиковать их на Tableau Server. Вот что получилось:

Сейчас шаги с 1 по 3 происходят в А1, на выходе BI-команда получает опубликованный на Tableau Server датасорс для разработки визуализаций. Связующим звеном стал Hyper API, о котором дальше и пойдет речь.

Результаты

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

Освободили время BI команды. Раньше было мало шаблонных решений и много кастомизаций. Чаще всего под каждый проект дописывали обработку на Python. В редких случаях, где обработка не нужна была, работали сразу в Tableau Desktop (основной инструмент разработки).
Сейчас подготовка датасорса это: накликать нужные поля в интерфейсе А1, отметить, какие из них разворачиваем в строки (если это необходимо) и опционально заранее определить тип полей.

Не нагружаем Tableau Server обновлением громоздких датасорсов обновление происходит силами А1, а на сервер закачивается уже готовый hyper.

*Бонус стимулируем пользователей работать внутри А1. Если раньше некоторые пользователи после выгрузки сырых отчетов, дорабатывали их вручную вне инструмента, то теперь, так как весь процесс с 1 по 3 шаг происходит в А1, пользователям проще настраивать процесс чистки там же.

Проблема и решение

Немного о А1

Прежде чем мы начнем рассказывать про наше решение, нужно рассказать о нашем внутреннем продукте А1, к которому прикрутили генерацию датасорсов.

А1 это внутренний продукт компании, который призван упростить рабочий процесс сотрудникам, у которых основная работа заключается в следующем:

• Забирать данные из программных продуктов компании MediaScope
• Приводить эти данные (чистить) в удобный для аналитиков-предметников вид
• По необходимости подготавливать данные для создания дашбордов (об этом мы сегодня и поговорим)

После того, как пользователь завершает чистку данных, они хранятся в системе А1. В нашей терминологии это называется Контейнером. Контейнер это обычный документ в MongoDB, который нам и надо передавать на Tableau-сервер.

Проблема BI-команды

Нашей команде BI-разработчиков нужно было как-то получать данные из А1, которые хранились в MongoDB, и на основе полученных данных строить дашборды. В первую очередь мы попробовали забирать данные из MongoDB штатными средствами табло, но проблему это не решало:

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

Что мы придумали

Было принято решение попробовать решить данную задачу своим велосипедом, используя библиотеку Tableau Hyper API. Данная библиотека позволяет создавать файл в формате .hyper, в который легко складывать данные, а потом использовать как источник данных для создания дашборда на табло сервере.

Как описывают хайпер сами разработчики табло:

Hyper это высокопроизводительный in-memory механизм обработки данных, который помогает клиентам быстро анализировать большие или комплексные датасеты, эффективно оценивая запросы в базу данных. Основанная на платформе Tableau, Hyper использует собственные методы динамической генерации кода и передовые технологии параллелизма, позволяющие достигать высокой производительности при создании экстрактов и выполнение запросов.

Примерный процесс работы в нашей программе выглядит следующим образом:

• Пользователь выбирает контейнеры и нужные колонки
• Система выдергивает из контейнеров данные
• По полученным данным система определяет типы колонок
• Инициализируется создание хайпера и вставка в него данных
• Загружается хайпер на табло-сервер
• BI-разработчики видят хайпер на сервере и создает на его основе дашборд

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

• Система скачает с табло-сервера хайпер
• Заберет из MongoDB свежие данные и обновит хайпер
• После система загружает на сервер новый хайпер с перезаписью существующего
• Пользователю достаточно просто нажать на кнопку Refresh, чтобы в дашборде отобразилась актуальная информация

Что видит пользователь

Как уже говорилось ранее, А1 является веб-приложением. Для создания сервиса генерации хайпера на фронте мы использовали Vue.js и Vuetify.

Интерфейс приложения разделен на три экрана.


На первом экране пользователь выбирает нужные контейнеры и колонки.

Если включена опция Unpivot, то в хайпере будут созданы две дополнительные колонки: variable- наименования колонок, которые выбираются столбцом Metrics и values- значения из этих колонок.

Столбец Dimension добавляет в хайпер колонку с одноименной выбранной колонкой. Количество выбранных колонок Dimensions и их названия должны быть одинаковые во всех контейнерах, чтобы не нарушилась целостность таблицы в хайпере, поэтому присутствует столбец Имя hyper, который позволяет указать имя выбранной колонке, если в контейнерах они называются по-разному.

На этом процесс настройки хайпера заканчивается. Пользователю достаточно перейти на второй экран, нажать Создать hyper и наблюдать за ходом событий в логах.



На третьем экране находятся дополнительные настройки:

• Можно включить игнорирование обновлений, если нам не нужно, чтобы система автоматически обновляла хайпер
• Можно указать email, на который отправлять отчеты об обновлениях
• Можно руками указать тип данных для колонки values (используется только при unpivot режиме): float, string или автоматически определять системой (про типы поговорим дальше)
• Также можно указать типы данных для выбранных колонок у контейнеров.

Что под капотом

А1 написан на Python. Для работы с данными мы используем Pandas, а сами данные мы сериализуем из pandas в pickle и храним в MongoDB GridFS.

Когда поступает команда на создание хайпера, система выполняет следующие операции:

• Выгружает из MongoDB все необходимые контейнеры и десиреализует данные в датайфремы pandas
• Производит подготовку данных: оставляет в датафреймах только нужные колонки, дает им новые имена, при необходимости разворачивает таблицы через pandas.melt
• Если пользователь выставил тип данных у колонок, то произвести конвертацию данных либо во float32, либо в string
• После всех подготовительных работ с данными система через hyper api создает файл и через tabcmd отправляет файл на табло-сервер.

Стоит немного поговорить о типах данных у колонок. Одной из особенностей хранения данных в контейнерах А1 является то, что пользователи не заморачиваются над тем, какие типы назначать колонкам, за них это прекрасно делает pandas: система спокойно справляется с ситуациями, когда в колонке присутствуют числа и строковые значения. Однако хайперу это не нравится: если сказать ему, что колонка должна иметь тип int, то система ругнется при попытке вставить что угодно кроме целого числа. Поэтому было принято решение использовать в хайперах только два типа данных: string и float.

Итак, с общим принципом работы мы разобрались, давайте поговорим уже про саму работу с hyper.

Создание .hyper файла

Для работы с Hyper API понадобится установить библиотеку, скачать ее можно с официально сайта тут. Там же есть неплохие примеры, как работать с этим инструментом. Мы же кратко укажем основные моменты.

Сам файл хайпера из себя представляет эдакую базу данных, чем-то напоминает SQLite.Через api можно обращаться к данным, используя like SQL синтаксис:

f"SELECT {escape_name('Customer ID')} FROM {escape_name('Customer')}"

Поскольку система у нас написана на Python, то и библиотеку мы будем использовать для соответствующего языка. При создании файла мы должны указать имя схемы, имя таблицы и колонки с типами. Имя схемы и таблицы должны называться Extract, поскольку именно в эту схему с таблицей залезает Tableau Server, чтобы вытащить данные для книжек.

with HyperProcess(Telemetry.SEND_USAGE_DATA_TO_TABLEAU) as hyper:    with Connection(        hyper.endpoint, self.fullpath_hyper, CreateMode.CREATE_AND_REPLACE    ) as connection:        connection.catalog.create_schema("Extract")        main_table = TableName("Extract", "Extract")        example_table = TableDefinition(main_table)

После создания таблицы нам нужно создать колонки и задать типы. Как мы уже говорили ранее, данные у нас имеют только два типа (float или string), поэтому отталкиваясь от того, какой тип стоит у колонок в датафрейме, такой мы и выставляем для колонок:

for column in dataframe.columns:    if dataframe[column].dtype.name in ("category", "object"):        example_table.add_column(TableDefinition.Column(column, SqlType.text()))    elif dataframe[column].dtype.name in ("float32"):        example_table.add_column(            TableDefinition.Column(column, SqlType.double())        )    connection.catalog.create_table(example_table)

После создания таблицы можно и вставить данные:

with Inserter(connection, example_table) as inserter:    for val in dataframe.values:        inserter.add_row(val.tolist())    inserter.execute()

Здесь мы построчно бежим по датафрейму и накапливаем список значениями через inserter.add_row(). На самом деле в апи хайпера есть функция add_rows(), которая принимает список списков и вставляет уже значения. Почему не было так сделано? Ради экономии оперативной памяти: для того чтобы предоставить список списков значений из датафрейма, нужно попросить pandas сделать values.tolist(). А когда у тебя 150 млн строк данных, получается очень дорогая операция для оперативки, при этом на производительности это никак не сказывается (во всяком случае, не было замечено, что из-за итерационного перебора строк как-то просела скорость создания хайпера). Плюс ко всему, add_rows() работает как синтаксический сахар: на деле он принимает список списков и так же итерационно добавляет данные.

На этом создание нашего хайпера заканчивается. Дальше нам нужно опубликовать его на сервере.

Публикация файла на tableau-сервере

Для обращения к tableau-серверу мы будем использовать утилиту tabcmd это консольная утилита, позволяющая подключаться к серверу и выполнять административные функции создавать пользователей, группы, книжки и прочее.

Запускать команду tabcmd будем через питоновский subprocess.Popen:

popen = subprocess.Popen(    f'/opt/tableau/tabcmd/bin/tabcmd publish "{fullpath_hyper}" -n "{filename}" -o -r "A1_test" '    '-s http://tableau.domain.com -u "username" -p "password" --no-certcheck',    shell=True,    stderr=subprocess.PIPE,    stdout=subprocess.PIPE,)return_code = popen.wait()if return_code:    error = str(popen.communicate()[1])    return f"Ошибка сервера во время публикации файла. {error}"

Мы передаем tabcmd следующую команду и ключи:

• publish: залить файл на сервер
• -n (--name): какое имя файла будет на сервере
• -o (--overwrite): если присутствует файл с таким именем, то перезаписать
• -r A1_test (--project): положить файл в папку (он же проект)
• -s (--server): адрес tableau-сервера
• -u -p: логин и пароль для авторизации на сервере
• --no-certcheck: игнорировать проверку SSL-сертификата

Обновление хайпера

Как создавать новый хайпер мы разобрались, но что делать, когда хайпер состоит из десятка контейнеров и в один из них поступили новые данные? Будем обновлять хайпер.

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

Чтобы понимать, какие данные из какого контейнера лежат в хайпере, система при создании хайпера также создает дополнительную колонку container_id. При таком подходе обновление становится очень простым:

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

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

Для того, чтобы забрать файл, мы используем tabcmd:

popen = subprocess.Popen(    f'/opt/tableau/tabcmd/bin/tabcmd get "datasources/{filename_tdsx}" '    f'-s http://tableau.domain.com -u "username" -p "password" '    f'--no-certcheck -f "{fullpath_tdsx}"',    shell=True,    stderr=subprocess.PIPE,    stdout=subprocess.PIPE,)return_code = popen.wait()if return_code:    error = str(popen.communicate()[1])    return f"Ошибка. {error}"

Тут используем следующую команду и ключи:

• get: забрать с сервера файл. Если на сервере лежит файл test.hyper, то обращаться надо к файлу test.tdsx, а лежат они все в директории datasource (я не смог нагуглить, почему такая особенность работы в табло, если знаете, поделитесь в комментариях )
• -f (--filename): полный путь, включая имя файла и его расширение, куда надо сохранить файл

После того, как файл будет скачен, его надо разархивировать через zipfile:

with zipfile.ZipFile(fullpath_tdsx, "r") as zip_ref:    zip_ref.extractall(path)

После разархивации хайпер будет лежать в директории ./Data/Extracts.

Теперь, когда у нас есть актуальная версия файла, мы можем удалить из него ненужные строки:

table_name = TableName("Extract", "Extract")with HyperProcess(Telemetry.SEND_USAGE_DATA_TO_TABLEAU) as hyper:    with Connection(hyper.endpoint, self.fullpath_hyper) as connection:        connection.execute_query(            f"DELETE FROM {table_name} WHERE "            f'{escape_name("container_id")}={container_id}'        ).close()

Ну а вставка и публикация файла были уже описаны выше.

Заключение

Что в итоге? Проделав работу по внедрению генерации hyper-файлов и автоматической доставки их на tableau-сервер, мы в разы снизили нагрузку на BI-команду, данные в дашборде обновлять стало проще и, самое главное, быстрее. Само знакомство с hyper api не было болезненным, документация неплохо написана, а сама интеграция технологии в нашу систему прошла легко.

Благодарим за внимание! Если у вас есть вопросы или замечания, пожалуйста, оставляйте их в комментариях.

Статья написана совместно с Василием Лавровым (VasilyFromOpenSpace) Старшим разработчиком бизнес-аналитики