apache superset что это

Будущее BI за открытым ПО

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

Основной причиной, почему я первоначально создал Apache Airflow и Apache Superset, когда работал в Airbnb в 2014-2017 годах, стала невозможность производителей программных продуктов:

поддерживать высокий темп инноваций в экосистеме данных;

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

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

Проблемы при использовании Tableau

Из-за запутанного повдения режима Live Mode в Tableau (не буду вдаваться в подробности) мы начали использовать Tableau Extracts. Но этот инструмент падал из-за объёма данных, с которым мы работали в Airbnb, создавая много проблем с неаддитивными метриками (например, уникальное количество пользователей), и вынуждая нас запутанным образом вычислять различные «группирующие наборы», что шло в разрез с некотороми парадигмами Tableau и только запутывало пользователей. Кроме того, мы имели ограниченное количество лицензий и на порядок большее количество сотрудников, которые нуждались в получении доступа к внутреннему пространству. И я уже не говорю о том, что ориентированный на использование Windows подход Tableau не работал в то время для компании, живущей в облаке.

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

Преимущества открытого ПО

Если бы меня попросили одним словом описать, почему сейчас самое подходящее время для использования BI с открытым исходным кодом, я бы назвал слово свобода. Из принципа свободы следует несколько более конкретных преимуществ для компании:

способоность изменять, расширять и интегрировать ПО;

предотвращение зависимости от конкретного вендора.

Изменение, расширение и интеграция

Перед Airbnb стояла задача интегрировать внутренние инструменты, такие как Dataportal и Minerva, с инструментом для создания дашбордов, чтобы обеспечить более простой доступ к данным для нетехнических пользователей (data democratization). Поскольку Superset имеет открытый исходный код и Airbnb активно участвует в этом проекте, они относительно легко смогли дополнить Superset собственными компонентами.

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

Внутри более широкого сообщества многие разработчики сообщают об использовании богатого REST API, предоставляемого Superset, что позволяет им программно полностью контролировать все части платформы. Учитывая факт, что почти всё, что делает пользователь в Superset, можно реализовать через API, открываются почти неограниченные возможности для автоматизации процессов в самом Superset и вокруг него.

Что касается интеграции, участники сообщества Superset добавили поддержку более 30 СУБД (и их число постоянно растёт!), предоставив код и соответствующую документацию. Поскольку главыне участники сообщества Superset сделали ставку на правильные компоненты с открытым исходным кодом (SQLAlchemy и Python DB-API 2.0), оно также развивается вместе с сообществом Python и в то же время помогает развиваться ему.

Поддержка сообщества

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

В основе сообщества лежат активные участники, которые обычно работают по принципу меритократии. Сообщества привлекают к себе внимание и таланты и предоставляют новичкам рекомендации, задают для них направление движения. А с появлением таких платформ, как Github, программное обеспечение стало уникальным в том смысле, что инженеры и разработчики со всего мира могут объединяться и работать вместе с минимальными препятствиями. Такие тенденции уже довольно хорошо изучены и рассматриваются как глобальный сдвиг в понимании о том, как люди сотрудничают для разработки современного ПО.

Помимо ПО, которое является основой проекта, участники сообщества вносят вклад в его развитие и многими другими способами. Вот некоторые примеры из них:

полная и актуальная документация;

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

отчёты об ошибках и устранении ошибок, вносящие вклад в стабильность и качество проекта;

постоянно растущие базы знаний и ответы на FAQ на таких площадках, как GitHub и StackOverflow;

обучающие видео и записи выступлений на конференциях в YouTube;

сообщество энтузиастов и экспертов в Slack, готовых быстро помочь решить проблему;

почтовые рассылки, в которых основные участники сообщества обсуждают глобальные проблемы и предлагают решения;

обратная связь как инструмент для внесения предложений и влияния на развитие продукта.

Отсутствие зависимости от вендора

Недавно Atlassian приобрела проприетарную BI-платформу Chart.io и начала сокращать её команду, а также объявила о своем намерении закрыть платформу. Теперь их клиенты должны быстро отреагировать и найти другие средства для аналитики, возможно, перестроив весь процесс анализа данных.

И это не новое явление. Учитывая то, насколько зрелым и динамичным является рынок BI, слияние ускоряется в течение последних нескольких лет:

Tableau был приобретён Salesforce

Looker был приобретён Google Cloud

Periscope был приобретён Sisense

Zoomdata был приобретён Logi Analytics

Например, если вы использовали Amazon Managed Workflows для Apache Airflow, и по каким-то причинам Amazon решила закрыть этот сервис (это просто предположение!), вы будете иметь несколько достойных путей решения проблемы:

выбрать и перейти к другому поставщику аналогичного сервиса: вероятнее всего, Astronomer или Google Cloud Composer;

нанять или проконсультироваться у эксперта по Airflow. Сообщество вырастило большое количество профессионалов, которые знают и любят Airflow и могут помочь вашей организации;

обучиться и использовать классные инструменты, предоставляемые сообществом, чтобы самостоятельно запускать программный код (Docker, Helm, k8s operator, …)

Заключение

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

Если говорить более конкретно о BI, то Apache Superset достиг такого уровня, когда выбор в его пользу при сравнении с другим проприетарным ПО становится очень убедительным. С момента своего создания в 2015 году на хакатоне Airbnb проект прошел очень долгий путь. Вот несколько последних значимых событий:

стал одним из самых популярных проектов с открытым исходным кодом и зарекомендовал себя как самая популярная BI-платформа с открытым исходным кодом;

стал признанным тысячами различных организаций, некоторые из которых можно посмотреть здесь;

разработка проекта ускоряется за счёт повышенного внимания пользователей к успешному продукту с открытым исходным кодом;

прошёл Apache Software Foundation (2020) как проект высшего уровня, что подтверждает надёжную и проверенную модель управления проектом и гарантирует определенную зрелость продукта.

В общем, Apache Superset предлагает сочетание функций и гарантий, уникальное для продукта BI с открытым исходным кодом. Чтобы узнать больше, посетите наше растущее сообщество и присоединяйтесь к нему!

Источник

Платформа данных в Леруа Мерлен. Part 2. Обновления 2021 года: Flink и Superset

Итак, в 2021 год мы вступили со следующей архитектурой:

У нас есть DWH, в который мы различными путями укладываем CDC поток с большого количества источников, который обрабатываем с помощью процедур, запускаемых через Airflow и формируем DDS и витрины. Также у нас есть DataLake на S3, в котором лежит сырьё.

Мы добавили возможность работать с CDC нереляционных баз, таких как Mongo (тоже с помощью Debezium выгружали их в Kafka), начали обрабатывать канонические объекты – это, по сути, такие структурированные данные по строго принятым в компании схемам. Также мы добавили возможность работать с event streams, такими как clickstreams с онлайн-площадок, или эвентами CDP (customer data platform). После этого мы собирали их в формат parquet с помощью NiFi и выгружали в Yandex Object Storage, после этого с помощью Spark парсили и загружали в GreenPlum (через PXF).

Точки роста

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

Пользовательский опыт

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

Боль пользователей была в необходимости создавать CDC на стороне источников, проливать данные в Kafka, коммитить в CI DDL GreenPlum’а, рисовать в NiFi ETL процессы. При этом, некоторые пользователи не умели даже работать с GIT’ом, не говоря уже о разработке в локальном докере, запуске тестов в пайплайнах, DAG’ах Airflow и прочем.

Время обработки запросов

«Вчера мой SQL запрос обрабатывался 30 секунд, а сегодня уже 10 минут» – с такими словами начали приходить пользователи. Причина была простая – несмотря на то что у GreenPlum есть разграничения ресурсов по ресурсным группам и очередям, пользовательские запросы все равно замедлялись под большой нагрузкой, когда на кластере работали тяжелые ETL-процессы.

Прямые запросы (DirectQuery)

Пользователи хотели получить возможность подключать свои BI-инструменты в режиме Direct Query. По сути, каждый дашборд может генерить свои запросы к источнику данных, а мы на GreenPlum ограничиваем количество подключений каждой учетки. В итоге их дашборды просто не прогружались. Можно было объяснять пользователям специфику работы GreenPlum, говорить, что это аналитическое хранилище, которое работает определенным образом. Но мы сами понимали, что платформе нужно развитие.

Административный опыт

У нас получилось достаточно ресурсоемкое решение – кластеру порой приходилось обрабатывать порядка 150 млн CDC-событий за запуск процедуры, а это занимало иногда до 4 часов. Время деградировало из-за накопленной истории. Партиционирование, конечно, помогало до определенного момента, когда количество тяжелых источников в платформе не стало исчисляться несколькими десятками.

Также из-за того, что пользователи могли ходить в ODS-слои и рассчитывать на них дашборды, нагрузка на кластер все больше и больше росла. Решением могло стать создание большого количества витрин. Но мы за подход Data mesh во всем бизнесе, мы не хотим становиться единым центром компетенций, а хотим, чтобы вся компания трансформировалась и развивалась в направлении работы с данными. Но при этом свободных рук дата-инженеров во всех направлениях (доменах) компании постоянно не хватало.

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

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

В итоге мы решили сфокусироваться на создании оперативной отчетности и контроле за действиями пользователей. Эти задачи мы решили с помощью 2х новых компонентов архитектуры.

Апдейты 2021

Операционная аналитика на Flink

В начале, чтобы удовлетворить самую большую потребность пользователей (в операционных данных), мы решили создать новый сервис, который назвали «Операционная аналитика». Построили мы его на базе Flink (фреймворк потоковой обработки данных). Начиная с версии 1.11 с июля 2020 года в нем появился функционал для работы с CDC потоками, как-раз генерируемых Debezium.

Также в версии 1.12 у Flink появилась возможность работать с CDC+Avro и со схемами, хранящимися в Confluent Schema Registry.

В результате выполнения простых запросов на потоке можно получать постоянно обновляющиеся counter’ы. Мы проверили этот формат работы, он показал прекрасные результаты, и то, что на GreenPlum считалось часами, мы могли уже считать на потоке с помощью Flink, еще и в режиме near-realtime. Кейс этот очень нужный, так как, например, показатели по товарообороту бизнес интересуют с минимальной задержкой.

При этом не все было так гладко. С какими трудностями мы столкнулись при работе Flink с построением операционной аналитики? Минусы операционной аналитики на Flink:

Один источник – один топик

У нас в Kafka данные хранятся таким образом: один источник – один топик. То есть по большому количеству таблиц в одном источнике используется один топик. И если нам необходимо в Flink посчитать данные только на одной таблице для одного источника, нам приходится читать весь поток по источнику.

Нет метаданных по Debezium

Следствие предыдущего минуса – в текущей версии Flink невозможно получить метаданные из полей Debezium. То есть невозможно сейчас точно определить имя таблицы, считав имя сообщения из Kafka CDC потока. Ждем фикс.

Ограничения генерации схем

Если вы работаете с данными в avro, но не используете schema registry, а храните схему в заголовках сообщений, на текущий момент Flink не может генерировать схему на основе этого заголовка – необходимо в таком случае схему задавать заранее.

Несмотря на эти недостатки, мы выявили для себя много плюсов операционной аналитики на Flink:

Near-realtime данные на CDC потоках

Скорость позволяет давать возможность пользователям производить обработку данных в режиме близкому к реальному времени.

Пользователи могут считать каунтеры, написав запросы на FlinkSQL – им не нужно изучать ни Scala, ни Java, никакие другие языки программирования, кроме SQL.

Flink – решение, которое существует на рынке давно. Возможность его кластеризации и контейнеризации позволяют нам строить отказоустойчивые HA-решения при правильном использовании savepoint’ов и checkpoint’ов.

В отличии от Спарка – у флика т.н. “true”-streaming, а не микро батчи, что как раз и позволяет ему работать с потоками CDC.

Поддержка Avro Confluent schema registry

Из коробки можно подключится к Confluent Schema Registry и забирать схемы сообщений из него:

Удобный и подробный мониторинг

Для отслеживания состояния джоб флинк предоставляет подробный интерфейс мониторинга (кмк более простой в освоении, чем интерфейс спарка):

UI monitoring

Большое число коннекторов.

За время существования Flink’а, для него было написано множество source и sink коннекторов, что позволяет реализовывать в своих ETL процессах интеграцию со множеством решений. Как пример можем привести clickhouse-sink коннектор, от коллег из ivi, который позволяет укладывать данные напрямую в CH.

Сравнивать Spark с Flink в контексте нашей задачи бессмысленно, т.к. killer-фичей для нас оказалась возможность работать с CDC потоками, чего не умеет делать спарк из коробки.

В итоге на данный момент мы имеем следующую структуру для near-realtime аналитики:

ETL для оперативных данных мы заменяем на Flink, развернув его в Kubernetes, данные по операционной аналитике мы загружаем в Yandex Object Storage с CH над ним.

Пользовательский опыт на Apache Superset

Мы внедрили Apache Superset – быстрый, легкий, интуитивно понятный веб-интерфейс для работы с данными и написания SQL-запросов. Он позволяет писать эти запросы к огромному количеству источников и визуализировать их в графиках и дашбордах.

Когда мы развернули его, мы нашли несколько недостатков:

С кодировкой UTF-8 русские символы неправильно кодировались при выгрузке в CSV, и отображались т.н. краказябры. В текущей версии (1.2.0) это уже исправлено.

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

Сложность подключения проприетарных источников

Проприетарные источники (Oracle, DB2) не так легко подключить, нужно ставить драйвера и пакеты. Например для Oracle в requirements-extra.txt:

Требуются частые обновления

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

Но плюсы перекрыли все эти недостатки:

Единая точка входа

У нас появилась единая точка входа в платформу, появился контроль за пользователями и количеством их подключений, за написанными запросами. Нам в этом помог функционал user impersonation – когда пользователь заходит в Superset со своей LDAP учеткой, он, авторизовавшись однажды, получает доступ ко всем источникам под своим юзером.

Нас интересовали в первую очередь GreenPlum, ClickHouse и Postgres. GP/PG работают из коробки, а для CH необходимо добавлять зависимости в requirements-extra.txt:

и настроить свои URL подключения к CH в формате:

Подробнее прочитать, как подключить Clickhouse к Supeset можно почитать тут. Но у него также есть коннекторы к Presto, Dremio, Druid, Hive, BigQuery, Vertica, Teradata, Exasol и прочим.

Удобная архитектура и интеграция с LDAP

Архитектура Superset нам оказалась понятной, масштабируемой, хорошо ложится k8s. LDAP подключается с добавлением в requirements-extra.txt

и в конфиг superset/config.py:

Начиная с версии 1.0.0 superset переехал на Apache Echarts c D3, появилось большое количество новых визуализаций. А кому не хватает встроенных, есть возможность создавать свои Viz плагины.

Интеграция с DataHub

Вот так выглядит пользовательский интерфейс (SQL Lab) для написания запросов в Superset:

интерфейс SQLlab

Он похож на обычные SQL IDE. Но, например, есть функционал для шаринга запроса, то есть пользователи могут сохранять запрос и делиться им с коллегами. Также есть выгрузка в csv, шедуллинг и множество других “плюшек”.

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

Admin interface

Как вишенка на торте – API у Superset позволяет нам как инженерам автоматизировать все обслуживание и применять CI/CD для пайпланинга выкатки и работы с ролями, пользователями и группами, чартами и дашбордами и т.д.

/swagger/v1

Мы также провели сравнение с конкурентами по критичным для нас показателям:

Источник

Русские Блоги

Конфигурация установки Superset и основное руководство пользователя

Ранее я изучал некоторые инструменты визуализации / среды с открытым исходным кодом, в том числе powerBI, Tableau и Superset.

Суммируйте и запишите конфигурацию установки Superset и основное использование.

1. Установка (CentOS & Win)

1.1 CentOS (См. Https://blog.csdn.net/qq273681448/article/details/75050513)

Зависимость базы данных

1.2 Windows(См. Https://zhuanlan.zhihu.com/p/36223295)

1.2.1 Установка виртуальной среды virtualenv (необходимо установить Python и настроить переменные среды)

1.2.2 Использование virtualenv. Сначала создайте каталог d: \ pycharm \ superset на диске D.

Интерфейс после активации выглядит так, как показано выше. Обратите внимание, что в левой части ввода командной строки есть метка (env), чтобы наши последующие операции вступили в силу в env и не повлияли на общую среду Pyhton.

1.2.4 Установка VS2015, 2017 вроде не работает.

1.2.5 Установить sasl. Без этого пакета установка суперсета может быть неудачной.ссылка на скачивание

1.2.6 После завершения предварительной установки начинается установка надмножества. (На этом шаге возникает проблема: pip install python-geohash хранит отчеты об ошибках и, наконец, удаляет VS2015, устанавливайте Microsoft Visual C ++ 14.0 решение ）

1.2.7 Используя браузер, откройте localhost: 8088, чтобы увидеть страницу входа.

1.2.8. Подключение к базе данных: mysql: // root: [email protected]/crawler? Charset = utf8. Обязательно установите пакет mysqlclient перед подключением к базе данных: pip install mysqlclient

База данных, поддерживаемая Superset:

2. Superset Basic Руководство пользователя

2.1 Создание источника данных

2.1.1 Подключение к новой базе данных

Нажмите знак плюс (+), чтобы добавить новый источник данных

2.1.2 Добавить таблицу данных

2.1.3 Просмотр и редактирование таблицы данных

2.2 Анализ данных анализа и визуального отображения

После того, как таблица определит поля измерения и индикаторы, вы сможете выполнить анализ данных и визуальное отображение таблицы.На странице таблицы списка щелкните имя таблицы для ввода.

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

2.2.1 Визуальный выбор типа диаграммы

Выберите тип диаграммы визуализации. Типы диаграмм, включенные в Superset, такие же, как и выше, включая гистограмму, круговую диаграмму, линейную диаграмму временного ряда, составную диаграмму, диаграмму, диаграмму горячих слов и т. Д.

2.2.2 Выбор временного диапазона данных

2.2.3 Выбор отображения размеров, выбор визуализации диаграммы

2.2.4 Редактирование координатной оси

2.2.5 Пользовательский запрос / фильтр

2.2.6 Запрос визуального хранения

2.2.7 Редактирование панели инструментов

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

2.2.8 Запрос на связывание с несколькими таблицами

В интерфейсе редактирования таблицы данных вы можете использовать операторы SQL для реализации запроса на сопоставление нескольких таблиц с помощью выражения базы данных.

Источник