Всем привет! Меня зовут Дима. Я BI Engineering Manager в inDriver. В компанию я пришел в марте 2020 года развивать направление Business Intelligence. О том, как это происходило и происходит сейчас, с какими вызовами приходится сталкиваться и какие у нас планы на будущее по этому направлению, читайте далее в этой статье. 

Содержание

С чего все начиналось

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

Подумав и пообщавшись с пользователями, было принято решение сохранить на текущем этапе оба сервиса, а BI-платформу внедрять в «конкурентной борьбе» с ними. Причин было несколько:

  1. Текущий объем, который насчитывал десятки используемых отчетов и дашбордов.

  2. Растущая потребность пользователей в новой отчетности, которая по своему функционалу превосходила возможности Grafana.

  3. Почти что полное отсутствие документации того, как сейчас собирается отчетность, дашборды, и рассчитываются метрики в них.

Сейчас, когда за тобой стоит целая команда BI-инженеров, а в разработке и поддержке витрин можно обратиться к дата-инженерам, я бы топил за перенос всех дашбордов из Grafana в Tableau (да, наш выбор пал на него) и за то, чтобы забыть про Grafana раз и навсегда. Скажу честно: не так сложно, на мой взгляд, конкурировать с инструментом или сервисом, как с человеческой привычкой. Однако, тогда штат моей команды был только в моем единственном лице. Вот и пришлось идти таким тернистым путем, который, помимо боли, позволил получить ценный опыт о выборе пользователя. Но об этом чуть позже.

Выбор инструмента

Как уже упомянул ранее, в качестве BI-инструмента я выбрал Tableau. Это один из лидеров рынка: удобный, гибкий и с кучей полезных возможностей. Как раз подходящий под задачи построения многофункциональных дашбордов для многочисленных команд бизнеса, продукта и развития self-service аналитики в компании. Можно уходить в многочасовые холивары по вопросу: «А почему Tableau? Ведь...». Я большую часть своего рабочего опыта пользовался именно им, и Tableau зарекомендовал себя как надежное решение. Я был уверен, что он справится с возложенной на него задачей. И не ошибся.

На тот момент в компании объем данных уже был, мягко скажем, немаленьким. Миллионы пользователей генерировали миллионы поездок, а их надо было где-то хранить и анализировать. Выбор пал на Clickhouse — оптимальное решение для чтения данных и их вставки при отсутствии ресурсов на администрирование, развертывание и поддержку кластера Hadoop.

Поселили мы его на одном, но жирном сервере. В него каждый день подгружались данные с бэкенда и еще пары сторонних источников. На том же сервере жили и аналитики, которые писали свои запросы к этой же базе. Тогда такое коммунальное сожительство не было проблемой, но это только тогда. Для оркестрации ETL-процессов, большую часть из которых составляло обновление витрин для отчетности, выбрали Apache Airflow. Резервно там же подняли PostgreSQL, если вдруг столкнемся с тем, что доступного функционала Tableau + Clickhouse будет не хватать. Например, работа со spatial data и ее чтение со стороны Tableau из базы. Итого, получилось:

  1. BI — Tableau.

  2. DWH — Clickhouse (reserve — PostgreSQL).

  3. Оркестратор — Apache Airflow.

Вооружившись этим арсеналом, был начат поход по различным командам с целью продемонстрировать преимущества Tableau перед Grafana и завоевать сердца пользователей.

Конкурентная борьба

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

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

  2. Обучение Tableau. Я провел несколько демо-дней, на которых обучал пользователей основному функционалу Tableau. Целью этого демо было не только показать пользователям, как пользоваться дашбордами, а также то, что Tableau — простой в изучении инструмент. А еще такие же дашборды можно построить самостоятельно (привет, self-service!). Если первая задача сразу давала положительный эффект, то на вторую требовалось гораздо больше времени и ресурсов, поэтому ее было решено отложить. Однако, она дала свои плоды в виде команды маркетинговых исследований, которая самостоятельно начала разрабатывать и внедрять дашборды по своему направлению работ.

  3. Документация, документация и еще раз документация. Документируется все: витрины, дашборды (вплоть до создания видеоинструкции), чтобы понимать, как считаются показатели, собираются и обновляются витрины, какие процессы есть, и как они проходят.

Все это дало свои плоды и количество пользователей, которые начали использовать Tableau и заказывать разработку дашбордов, возросло. Постепенно поток новых запросов был переведен полностью на сторону Tableau. И все равно мы сталкивались с сопротивлением. Были люди, которым оставалось проще и привычнее пользоваться Grafana. Интересная штука: использование Grafana заканчивалось тогда, когда пользователи находили 1-2 инсайта, которые полезны для их направления работ (пресловутый aha-moment). Очень просто интегрировались пользователи, которые до этого не пользовались Grafana. У них запускались новые продуктовые вертикали, отчетность которых сразу строилась на Tableau. Для них это был новый опыт, поэтому они сразу выбирали то, что было более функциональным и удобным.

Что сейчас и куда дальше

Сейчас у нас все продуктовые вертикали и команды, чья работа связана с анализом данных, имеют свои дашборды в Tableau. Для версионирования нашего кода мы используем Git с настроенным CI/CD, что позволяет удобно публиковать наши скрипты в продакшен. Для мониторинга работы наших сервисов мы используем (сюрприз!) Grafana. Постепенно переносим наши витрины в новое DWH — HDFS-кластер, поверх которого находится Presto SQL-engine. С ростом команд нам уже стало тесно на одной машине, поэтому хорошо, что теперь есть отдельный кластер. Для оркестрации по-прежнему используем Airflow, но пишем уже на PySpark. Дашборды в Grafana все еще живы, но сейчас у нас достаточно ресурсов, чтобы отказаться от этого легаси и пересобрать все в Tableau.

Мы тесно взаимодействуем с командой дата-инженеров, обогащая друг друга экспертизой, потребностями бизнеса, аналитикой, методиками расчета для построения витрин, которые максимально точно отвечают текущим потребностям в репортинге и анализе данных. BI-инженеры распределены по продуктовым вертикалям, являясь непосредственным участником ее команды. Это было сделано, чтобы лучше понимать то, что происходит в том или ином направлении бизнеса, помогать и развивать data-driven культуру, делиться экспертизой, полученной от своих коллег и других команд.

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

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

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

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

Комментарии (12)


  1. alexeyshulzhenko
    27.08.2021 17:18
    +1

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


    1. dima_vs Автор
      27.08.2021 22:42

      Не скажу, что это было просто, но вполне выполнимо. Если по пунктам:

      1) Установка ODBC-драйвера для Tableau Desktop и Tableau Server (Linux). Ставил тот, что лежит в репозитории Clickhouse. Набил шишек, но в итоге справился. Все описал в Confluence и теперь настройка всего окружения происходит быстро и без боли. В июле вот Altinity еще выкатили свою версию коннектора: https://docs.altinity.com/integrations/clickhouse-and-tableau/tableau-desktop-with-clickhouse/. Ее мы не тестили, тк хватает того, что есть + переезжаем на HDFS.

      2) Live connection или Extract. Выбрал второе. Почему? У Tableau сложности с использованием Clickhouse на live connection: часто возникают ошибки, связанные с разным типом данных во время выполнения join операций. Костыльно решаемо, но ради чего? Сервер нагружаем не мы одни. В extract грузим агрегаты для повышения производительности дашбордов. Создаются extract без проблем. И получается, что выбор был в пользу контроля над нагрузкой и надежностью.

      Если понадобится рассказать подробнее, то дайте знать. Распишу в лс =)


  1. Volrath
    27.08.2021 17:55
    +1

    Спасибо, хорошая статья. Имеем такой же стек (кликхаус в виде DWH, Airflow, только в конце используем PBI). Почему думаете в сторону HDFS и какую роль в архитектуре тогда видите для кликхауса? Только витрины для сложной аналитики?

    Хочется продолжения)


    1. dima_vs Автор
      27.08.2021 22:55

      Причин было несколько:

      1) Переезд в облака. Там проще масштабироваться. Гибкие возможности для оптимизации мощности и стоимости за счет кол-ва работающих одновременно нод.

      2) Драйвер Presto лучше взаимодействует с Tableau чем драйвер Clickhouse. На live connection и extract не встретили ошибок, которые произошли не по нашей вине. Тут получаем надежность.

      3) Нашей команде дата-инженеров такое решение удобнее в работе и в этих технологиях у них опыта больше чем с тем же Clickhouse.

      От Clickhouse хотим уйти совсем. При этом есть еще одна идея, которую очень хочется протестировать. И тут я бы взял паузу и рассказал уже про нее после проведения тестов =)


  1. densol92
    28.08.2021 16:57
    +1

    Все хорошо с табло, кроме цены. Сколько у вас в итоге стоит решение целиком(ресурсы +лицензии) и какой объём?


    1. dima_vs Автор
      29.08.2021 14:09

      Я разделю ответ на два пункта:

      1) Коммунальные ресурсы, то есть, которые мы делим с другими командами (тот же сервер, сначала, и далее кластер) - тут я не отвечу сходу. Мы эти ресурсы делили и делим с другими командами. Сейчас при переезде в облака уживаться стало комфортно и просто. Думаю, что к следующей статье я накоплю аналитику по этому вопросу и дам более точный ответ.

      2) Лицензии. Вот тут у меня больше деталей. Их может быть несколько типов https://www.tableau.com/pricing/teams-orgs (там же цены). Для старта мы взяли 100 viewers, 9 creators, 6 explorers. По опыту скажу, что лучше их покупать у дистрибьютеров, так как возможны более конкурентные условия. Важно понимать, кому из пользователей какой тип лицензии нужен. От этого тоже будет хорошая экономия. Этим летом мы достигли лимита по лицензиям и докупили еще. Помимо растущего кол-ва viewers со стартом программы обучения нам потребуется больше creators и explorers.


  1. Cekory
    29.08.2021 00:20
    +1

    А сколько занял процесс перехода по времени и по деньгам?


    1. dima_vs Автор
      29.08.2021 14:23

      Хороший вопрос)

      Тут я разделю на несколько этапов:

      1) с марта 2020 по август 2020 - период cusdev, демонстраций, первичного обучения и создания первых дашбордов. Здесь был, на мой взгляд, самый важный этап в получении доверия со стороны пользователей.

      2) сентябрь 2020 - декабрь 2020 - создание новых и ключевых дашбордов для бизнеса и продуктовой команды, по всем направлениям бизнеса и продуктовым вертикалям

      3) январь 2021 - по настоящее время - период активного роста по кол-ву пользователей, запросов, начало процесса распределения BI-инженеров по командам

      Закончился ли для меня этот процесс перехода полностью? Нет =) Почему? Потому что, на мой взгляд, он будет завершен окончательно после того, как мы полностью откажемся от Grafana.

      По стоимости посмотрите, пожалуйста, мой ответ на комментарии выше.


      1. Cekory
        29.08.2021 14:57
        +1

        Интересно, а платить за "100 viewers, 9 creators, 6 explorers" с какого этапа стали? Это в районе 2000 долларов в месяц, не такая уж маленькая сумма. Обычно руководство сложно убедить отдавать деньги, когда уже есть работающее бесплатное решение, пусть и не такое хорошее (Grafana). Все-таки задачи решаются, зачем что-то платить. Или было понимание, что с графаной трудно?


        1. dima_vs Автор
          29.08.2021 16:34

          Тут исходили из следующего:

          1) Функционал Tableau как bi-инструмента шире чем у Grafana. Грубо говоря Tableau лучше ответит на вопрос "почему?"

          2) Развитие self-service аналитики. Tableau как инструмент для self-service проще в освоении чем Grafana. При этом не забываем про наличие большего функционала.

          3) Скорость разработки. В Tableau многие вещи можно построить при помощи drag-and-drop. В Grafana построение дашборда сложнее для бизнес-пользователя и занимает дольше времени.

          4) Эффективность для бизнеса и продукта. Тут исходили из их потребностей, собрав которое было ясно, что нужен полноценный bi-инструмент


  1. DudinaAnna
    02.09.2021 15:17

    Начала читать статью и уже приготовилась писать вопрос, почему Tableau? Лично в работе сталкивалась только с Power BI, его вполне пока хватало.


    1. dima_vs Автор
      02.09.2021 15:28

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

      При этом еще раз хочу отметить, что Tableau - это один из лидеров рынка. Ровно таким же фаворитом считается и Power BI. Это важно, что выбранный вами инструмент справляется с поставленными задачами! Значит, на мой взгляд, для вашего сценария ваш выбор верный =)