Superset Admin

Приветствуем Вас в Мире Apache Superset BI: Лучшем Инструменте для Бизнес-Аналитики

2024-03-27T19:34:43.153Z

🚀 Переходите на Apache Superset: Лучший BI инструмент в России после ухода Power BI! 📊💡
👉 https://t.me/apache_superset_bi 👈

WebSite: https://superset-bi.ru

Вступление:

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

Описание Преимуществ Apache Superset BI:

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

Применение Apache Superset BI в Реальном Мире:

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

Заключение:

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

🚀 Переходите на Apache Superset: Лучший BI инструмент в России после ухода Power BI! 📊💡

2024-03-27T19:30:38.317Z

🚀 Объявляем! 🚀

Пришло время обновить свои инструменты бизнес-аналитики! 📊 Если вы ищете лучший альтернативный BI инструмент в России для перехода с ушедшего с рынка Power BI, то ваш выбор должен быть Apache Superset! 💡

🌟 Почему Apache Superset?

Открытый исходный код: Apache Superset - это инструмент с открытым исходным кодом, что означает, что вы получаете полную гибкость и контроль над вашими данными и аналитическими инструментами.
Богатый набор возможностей: С Apache Superset вы получаете доступ к широкому спектру визуализаций, интеграции с различными источниками данных, а также возможность создания интерактивных дашбордов и отчетов.
Активное сообщество: Вас ждет огромное сообщество пользователей и разработчиков Apache Superset, готовых поделиться знаниями, решить ваши вопросы и поддержать вас на пути к успешному использованию инструмента.
Легкость в использовании: Apache Superset предлагает интуитивно понятный пользовательский интерфейс, что делает работу с данными и создание визуализаций быстрым и удобным процессом.

🌐 Не упустите возможность обновить свои инструменты бизнес-аналитики и перейти на Apache Superset - лучший выбор для вашего бизнеса! Присоединяйтесь к сообществу Apache Superset уже сегодня и дайте вашему бизнесу мощный инструмент для анализа данных! 🚀💼

#apachesuperset

#бизнесаналитика

#анализданных

#bi

#открытыйисходныйкод

#инновации

Присоединяйтесь к нам, чтобы быть в курсе всего, что касается Apache Superset и бизнес-аналитики! Просто перейдите по ссылке:

https://t.me/apache_superset_bi

APACHE SUPERSET КАНАЛ ПРО ВНЕДРЕНИЕ BI ИНСТРУМЕНТА В РОССИИ

👉 https://t.me/apache_superset_bi 👈

Yandex Datalens и Apache Superset

2024-03-27T19:23:50.600Z

DataLens: Инновационный Сервис для Бизнес-Аналитики

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

Знакомство с DataLens

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

Ключевые Компоненты DataLens

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

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

Но есть другой, намного удобнее инструмент - APACHE SUPESET

DataLens vs. Apache Superset: Как сравнить два инструмента бизнес-аналитики

Помимо DataLens, существует еще один известный open source инструмент для бизнес-аналитики - Apache Superset. В последнее время Apache Superset набирает популярность благодаря своей гибкости, мощным возможностям и открытому исходному коду. Давайте рассмотрим некоторые аспекты, в которых Apache Superset может превзойти DataLens, и почему читателям стоит обратить внимание на этот инновационный инструмент.

1. Гибкость и Расширяемость

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

2. Богатый Набор Визуализаций

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

3. Активное Сообщество и Поддержка

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

Попробуйте Apache Superset уже сегодня!

Если вы ищете мощный и гибкий инструмент для бизнес-аналитики, то Apache Superset - отличный выбор. Его открытый исходный код, богатый набор визуализаций и активное сообщество делают его идеальным решением для различных потребностей аналитики данных. Перейдите на сайт superset-bi.ru и попробуйте Apache Superset уже сегодня!

🚀 Присоединяйтесь к нашему телеграм-каналу "Apache Superset BI"!

Вы интересуетесь инструментами бизнес-аналитики? Хотите быть в курсе последних новостей, обновлений и полезных советов по использованию Apache Superset? Тогда наш телеграм-канал для вас!

📊 В "Apache Superset BI" вы найдете:

🔍 Обзоры новых функций и возможностей Apache Superset. 📈 Практические советы и руководства по использованию инструментов бизнес-аналитики. 💡 Статьи и рекомендации от экспертов в области аналитики данных. 🔄 Обсуждения и деловые истории успеха от пользователей Apache Superset.

Присоединяйтесь к нам, чтобы быть в курсе всего, что касается Apache Superset и бизнес-аналитики! Просто перейдите по ссылке: https://t.me/apache_superset_bi

Присоединяйтесь прямо сейчас и станьте частью нашего сообщества! 📊🚀

Как мы создавали внутреннее хранилище данных в ClickHouse

2024-02-10T06:38:11.602Z

Перевод статьи: https://clickhouse.com/blog/building-a-data-warehouse-with-clickhouse

Подписывайтесь на телеграм канал Apache Superset: https://t.me/apache_superset_bi

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

Конечно, внутри нашей команды мы придерживаемся такого же подхода. Разработка и эксплуатация нашей облачной базы данных генерирует огромный объем данных, которые можно использовать для планирования мощности, ценообразования, лучшего понимания потребностей наших клиентов и финансовой отчетности. Десятки источников данных, сотни терабайт и около сотни BI-пользователей и специальных пользователей… И угадайте, что для этого мы используем ClickHouse Cloud :)

В этом посте я расскажу, как устроено наше внутреннее хранилище данных (DWH), какой стек мы используем и как наше хранилище данных будет развиваться в ближайшие несколько месяцев.

Требования и источники данных

Мы запустили ClickHouse Cloud в режиме Private Preview в мае 2022 года и в то же время поняли, что хотим лучше понимать наших клиентов: как они используют наш сервис, с какими трудностями они сталкиваются, как мы можем им помочь и как мы можем сделать наши цены доступны и разумны для них. Для этого нам нужно было собирать и обрабатывать данные из нескольких внутренних источников данных: плоскости данных, которая отвечает за работу модулей базы данных клиента, плоскости управления, которая отвечает за пользовательский интерфейс и операции с базой данных, а также AWS Billing, которая дает нам точные затраты на выполнение рабочих нагрузок клиентов.

Был короткий период времени, когда наш вице-президент по продуктам Таня Брагин ежедневно вручную анализировала рабочие нагрузки наших клиентов в Excel, используя поиск. Мне, как бывшему архитектору СХД, было обидно, что ей пришлось так бороться, и в результате родилась первая концепция внутренней СХД.

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

Команда продукта

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

Операционная группа

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

Отдел продаж

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

Инженерная команда

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

Группа поддержки

Просмотр конкретной настройки клиента: услуги, использование, объем данных и т. д.

Маркетинговая команда

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

Команда экономии затрат

Анализ затрат CSP и активная оптимизация наших обязательств CSP.

команда CI-CD

Отслеживание затрат CI-CD

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

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

Учитывая наши основные цели, мы сделали несколько предположений:

На нынешнем этапе достаточно детализации наших данных в один час. Это означает, что мы можем собирать и хранить агрегаты за каждый час.
На данный момент нам не нужно использовать подход CDC (или «сбор измененных данных»), поскольку он делает инфраструктуру СХД намного дороже. Традиционная прямая загрузка/ETL должна удовлетворить наши потребности. Если эти источники данных подлежат обновлению, мы можем выполнить полную перезагрузку данных.
Поскольку у нас есть отличная масштабируемая и быстрая база данных, нам не нужно выполнять преобразования ETL за пределами базы данных. Вместо этого мы используем ClickHouse напрямую для выполнения преобразований с помощью SQL. Это прекрасно работает.
В ClickHouse мы по своей природе являемся открытым исходным кодом, поэтому мы хотим, чтобы весь наш стек содержал только компоненты с открытым исходным кодом. Мы также любим вносить свой вклад.
Поскольку у нас очень разные типы источников данных, нам понадобится несколько инструментов и подходов для извлечения данных из этих источников. В то же время нам необходимо стандартизированное промежуточное хранилище.

Однако одно из других наших первоначальных предположений оказалось неверным. Мы предполагали, что, поскольку наша структура данных не такая сложная, нам будет достаточно иметь в СХД всего два логических слоя — необработанный слой и слой «киоска данных». Это была ошибка. На самом деле нам нужен был третий промежуточный уровень, хранящий внутренние бизнес-объекты. Мы объясним это ниже.

Архитектура

В результате мы получили следующую архитектуру:

На высоком уровне наш стек можно описать так:

ClickHouse Cloud как основная база данных
Airflow как планировщик (инструмент планирования с открытым исходным кодом)
AWS S3 как промежуточное хранилище для данных RAW
Superset как внутренний инструмент BI и AD-HOC

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

Для плоскости управления, плоскости данных, сегмента и AWS CUR мы используем встроенные функции источника данных для экспорта данных.
Для выставления счетов GCP мы используем экспортные запросы BigQuery для экспорта данных в GCS, откуда они могут быть получены табличной функцией ClickHouse S3.
Для Salesforce мы используем AWS AppFlow.
Для захвата данных из M3ter мы написали собственное приложение. Изначально он был написан на Kotlin, позже мы перенесли его на Python.
Для Galaxy (который представлен кластером ClickHouse Cloud) мы используем табличную функцию ClickHouse S3 для экспорта данных в S3.
Для Marketo мы используем Fivetran.
Наконец, поскольку цены AWS и GCP меняются очень редко, мы решили не автоматизировать их загрузку, а создали несколько скриптов, которые помогут нам вручную обновлять цены CSP при необходимости.

Для больших таблиц фактов мы собираем почасовые приращения. Для словарей и таблиц, которые могут получать не только новые строки, но и обновления, мы используем подход «замены» (т.е. каждый час загружаем всю таблицу).
Как только почасовые данные собираются в корзине S3, мы используем табличную функцию ClickHouse s3 для импорта данных в базу данных ClickHouse. Табличная функция S3 масштабируется по репликам и отлично работает с большими объемами данных.
Из корзины S3 данные вставляются в слой RAW в базе данных. Этот слой имеет ту же структуру таблицы, что и источники.
После серии преобразований, выполняемых Airflow (включая соединения), данные из необработанных таблиц вставляются в таблицы MART — эти таблицы представляют бизнес-объекты и удовлетворяют потребности наших внутренних заинтересованных сторон.При выполнении преобразований используется множество временных таблиц. Фактически, большинство преобразованных результатов сначала записываются в промежуточную таблицу, а только потом вставляются в целевую таблицу. Хотя такой подход вносит некоторую сложность, он также дает нам необходимую гибкость повторного использования данных приращения. Это позволяет использовать одну часть приращения несколько раз без ее пересчета или повторного сканирования целевой таблицы. Промежуточные таблицы имеют уникальные имена для каждого запуска Airflow DAG (направленные ациклические графы).
Наконец, инструмент Superset BI позволяет нашим внутренним пользователям запрашивать таблицы MART, а также строить диаграммы и информационные панели:

Пример панели управления Superset. Примечание: в целях иллюстрации представлены примерные данные с поддельными номерами.

Идемпотентность

Большинство таблиц, которые мы используем в ClickHouse, используют движки ReplicationReplacingMergeTree . Этот движок позволяет нам не заботиться о дубликатах в таблицах — записи с одинаковым ключом будут удалены, и сохранится только последняя запись. Это также означает, что мы можем вставлять данные за один конкретный час столько раз, сколько потребуется — сохранится только одна последняя версия каждой строки. Мы также используем функцию ClickHouse « FINAL », когда таблица используется в дальнейших преобразованиях для достижения согласованности, поэтому, например, функция sum()не вычисляет строку дважды.

В сочетании с заданиями/DAG Airflow, которые допускают многократное выполнение в течение одного и того же периода, наш конвейер полностью идемпотентен и может безопасно выполняться повторно, не приводя к дублированию. Более подробная информация о конструкции внутреннего воздушного потока будет представлена ниже.

Последовательность

По умолчанию ClickHouse обеспечивает итоговую согласованность. Это означает, что если вы успешно запустите запрос на вставку, это не гарантирует, что новые данные будут во всех репликах ClickHouse. Этого достаточно для аналитики в реальном времени, но неприемлемо для сценария СХД. Представьте, например, что вы вставляете данные в промежуточную таблицу. Вставка успешно завершается, и ваш процесс ELT начинает выполнять следующий запрос, который читает из промежуточной таблицы… и вы получаете только частичные данные.

Однако ClickHouse предлагает другой режим для случаев использования, когда согласованность важнее, чем мгновенная доступность вставленных данных на первом узле. Чтобы гарантировать, что запрос на вставку не вернет «успех», пока все реплики не получат данные, мы запускаем все запросы на вставку с настройкой insert_quorum=3(у нас в кластере три узла). Мы не используем настройку «авто», потому что при выходе из строя одного узла (например, при выполнении обновления ClickHouse) два оставшихся узла все равно смогут принимать вставки. Как только перезапущенный узел станет доступен, вставленные данные в этом узле могут отсутствовать в течение некоторого времени. Поэтому для нас лучше получить ошибку ( Number of alive replicas (2) is less than requested quorum (3/3).. (TOO_FEW_LIVE_REPLICAS) при вставке данных менее чем в три реплики. Поскольку перезапуски из-за обновлений происходят довольно быстро, запросы обычно завершаются успешно, если Airflow повторяет попытку после ошибки.

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

Проектирование внутренней инфраструктуры

Учитывая наш масштаб, нам нужно, чтобы наша инфраструктура СХД была простой, удобной в эксплуатации и легко масштабируемой. После запуска внутреннего PoC непосредственно на AWS EC2 мы перенесли все компоненты нашей инфраструктуры в Docker.

У нас есть отдельные машины для веб-сервера Airflow, рабочего процесса Airflow и Superset. Все компоненты упакованы в Docker-контейнеры.
На машинах Airflow мы дополнительно каждые 5 секунд запускаем контейнер, который синхронизирует репозиторий, содержащий код наших DAG, запросы ELT и некоторые файлы конфигурации, с папкой, расположенной на машинах.
Мы используем панели мониторинга и функции оповещений Superset, поэтому у нас есть планировщик и рабочие контейнеры для Superset.
Все компоненты Airflow и Superset синхронизируются через экземпляр Redis, который работает на отдельной машине. Redis хранит состояние выполнения заданий и рабочий код для Airflow, кэшированные результаты запросов для Superset и некоторую другую служебную информацию.
Мы используем AWS RDS для PostgreSQL в качестве внутренней базы данных для Airflow и Superset.
У нас есть две среды, работающие независимо друг от друга с собственными экземплярами ClickHouse Cloud, Airflow и Superset, установленными в разных регионах.
Хотя одна среда называется Preprod, а другая — Prod, мы сохраняем целостность Preprod, чтобы иметь возможность переключиться, если Prod недоступен.

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

Разработчик создает ветку из ветки разработки или производства.
Разработчик вносит изменения
Разработчик создает PR в ветку Preprod
После рассмотрения и утверждения запроса на запрос изменения передаются в экземпляр Preprod Airflow, где они тестируются.
Как только изменения будут готовы к выпуску в рабочую версию, выполняется PR из Preprod в ветку Prod.

Внутренняя конструкция воздушного потока

Изначально мы думали о создании сложной системы DAG со множеством зависимостей. К сожалению, ни один из существующих вариантов механики зависимостей DAG не может работать с нужной архитектурой (что является довольно распространенной проблемой в Airflow):

Airflow не позволяет именам наборов данных изменяться при выполнении. Поэтому недавно представленные наборы данных не могут использовать временные имена. Если мы используем статическое имя набора данных, нисходящий DAG будет запущен только один раз для последнего приращения.
Триггеры могут работать на нас, но их использование слишком усложнит нашу настройку. Наличие 10–20 групп DAG с триггерами выглядит как кошмар зависимостей с операционной точки зрения.

Таким образом, мы получили следующую структуру:

Отдельные DAG для загрузки данных из источника данных в S3 (например, M3ter -> S3)
Одна огромная основная группа обеспечения доступности баз данных, которая выполняет все преобразования при доставке данных в S3.

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

Безопасность

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

Основные правила

Разные данные должны быть доступны разным пользователям в соответствии с ролевой моделью компании, и это должно происходить автоматически.
Разделение разрешений должно выполняться на уровне базы данных (не на стороне BI!)
Ограничения доступа к сети должны быть представлены на всех уровнях (от использования Okta для инструмента BI до IP-фильтрации).

Выполнение

Мы используем группы Google для контроля разрешений внутренних пользователей. Это позволяет нам использовать существующие внутренние группы компании, а также позволяет владельцам групп (которыми может быть нетехнический человек, не интересующийся SQL) контролировать доступ к различным данным. Группы могут быть вложенными. Например:

general_data@clickhouse.com

company@clickhouse.com

financial_data@clickhouse.com

hr_data@clickhouse.com

Для сопоставления групп Google с точными разрешениями мы используем системную таблицу, которая соединяет:

Название группы Google
Имя базы данных
Имя таблицы
Массив столбцов
Фильтр (например, «где организация='clickhouse'»)
Тип доступа (ВЫБРАТЬ, ВСТАВИТЬ)

У нас также есть скрипт, который делает следующее:

Получает рекурсивный список групп и пользователей.
Создает (фактически заменяет) этих пользователей в базе данных с уникальным паролем.
Создает роли, соответствующие группам Google.
Назначает роли пользователям
Предоставляет разрешения ролям в соответствии с таблицей разрешений с предложением «WITH REPLACE OPTION» — это удалит все остальные разрешения, которые по какой-то причине можно было сделать вручную.

На стороне Superset мы используем функцию DB_CONNECTION_MUTATOR для замены имени пользователя базы данных на пользователя Superset при отправке запроса в БД. У нас также включен Google Oauth в Superset. Это означает, что в DB_CONNECTION_MUTATOR у нас есть все необходимое для подключения Superset с нужным именем пользователя и паролем:

def DB_CONNECTION_MUTATOR(uri, params, username, security_manager, source):
    # Only enable mutator on clickhouse cloud endpoints
    if not uri.host.lower().endswith("clickhouse.cloud"):
        return uri, params
    user = security_manager.find_user(username=username)
    
    generated_username = str(user.email).split('@')[0] + '--' + str(user.username)
    uri.username = generated_username
    # Password generation logic - hidden in this example
    uri.password = ...
    return uri, params

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

Пользователи ClickHouse Cloud могут попросить нас удалить все их личные данные, включая имя, адрес электронной почты и другую информацию. Разумеется, в этом случае мы также удаляем эту информацию из СХД. Самое крутое здесь то, что нам не нужно запускать какие-либо обновления или удаления в таблицах ClickHouse. Поскольку наш движок оставляет только одну последнюю запись для каждого значения ключа, все, что нам нужно сделать, это вставить новую версию строки с данными удаленных пользователей. Для исчезновения старых строк потребуется несколько часов, но стандарты GDPR дают вам от 3 до 30 дней на удаление данных в зависимости от сценария. Итак, полный алгоритм:

Найдите в одной из исходных систем специальный флаг, согласно которому этот идентификатор следует замаскировать/удалить.
Выбрать все записи из таблицы с этим идентификатором
Маскировать обязательные поля
Вставьте данные обратно в таблицу
Запустите команду «оптимизировать таблицу… окончательная», чтобы убедиться, что старые записи удалены с диска.
Когда приходит новое почасовое приращение, мы выполняем объединение со списком удаленных идентификаторов. Это означает, что если по какой-либо причине информация PII пользователя еще не была полностью удалена, мы автоматически замаскируем эти данные.

Улучшения и планы на будущее

Хотя в целом мы удовлетворены нашей СХД, есть некоторые вещи, которые мы планируем изменить в ближайшие месяцы:

Третий логический уровень

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

DBT

Airflow — хороший планировщик, но нам нужен инструмент, который позаботится о многих других вещах: при необходимости полная перезагрузка витрин данных, контроль качества, описание и документирование данных и другие. Для этого мы планируем интегрировать Airflow с DBT. Поскольку мы запускаем всю нашу инфраструктуру данных в контейнерах Docker, довольно легко создать отдельный контейнер DBT для наших нужд, который будет запускаться DAG Airflow.

Соглашения об именах

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

Ресурсы

ClickHouse — относительно молодая компания, поэтому наша команда DWH относительно небольшая и насчитывает всего 3 человека:

Data Engineer — строит и поддерживает инфраструктуру.
Аналитик продукта — помогает пользователям получать ценную информацию, строить диаграммы и понимать данные.
Руководитель группы — тратит только ~30 % времени на задачи СХД.

Что касается инфраструктуры, мы используем две среды с отдельными сервисами ClickHouse Cloud. У каждого сервиса есть 3 узла (они же реплики, но все реплики принимают запросы). Использование памяти для наших сервисов ClickHouse составляет ~200 Гб. Хотя мы не платим за эти услуги, поскольку являемся частью команды ClickHouse Cloud, мы изучили цены и производительность конкурентов и полагаем, что другая облачная аналитическая база данных в нашем случае будет намного дороже.

Кроме того, наша инфраструктура включает в себя 8 машин EC2 и корзину S3 с необработанными данными. В общей сложности эти услуги стоят около ~$1500 в месяц.

Общие результаты

Наша СХД работает уже не один год. У нас более 70 активных пользователей в месяц, сотни информационных панелей и тысячи диаграмм. Всего пользователи выполняют около 40 000 запросов в день. На этой диаграмме показано количество запросов в день с разбивкой по пользователям. Исключены пользователи системы и ELT:

Да, наши пользователи работают и по выходным.

Мы храним ~115 ТБ несжатых данных в ~150 таблицах, но из-за эффективного сжатия ClickHouse реальный размер хранимых данных составляет всего ~13 ТБ.

Неделя за неделей растет объем данных в нашем СХД. Февральский всплеск представляет собой внутренний эксперимент, требующий дублирования всех данных.

Краткое содержание

За год мы развернули СХД на основе технологии с открытым исходным кодом, которая обеспечивает удобство, которое нравится нашим пользователям. Хотя наш СХД упрощает работу с данными, мы также видим множество улучшений и изменений, которые нам необходимо внести, чтобы двигаться вперед. Мы считаем, что использование ClickHouse Cloud доказывает, что его можно использовать для создания надежного хранилища данных.

Подписывайтесь на телеграм канал Apache Superset: https://t.me/apache_superset_bi

Enhancing Security and User Experience: Customizing Login in Apache Superset with Token

2023-06-29T10:39:17.488Z

Source Article on Medium: https://medium.com/@mert1943992/enhancing-security-and-user-experience-customizing-login-in-apache-superset-with-token-204b95386b8a

What is Superset?

Apache Superset is an open-source business intelligence (BI) platform that allows users to easily explore and visualize data, build dashboards, and create interactive reports.

With Superset, users can connect to various data sources, such as relational databases, NoSQL databases, cloud storage solutions, and more, to analyze and visualize data. It supports various visualization types, including bar charts, line charts, scatter plots, histograms, maps, and more. Users can also create custom charts using Python or SQL.

Superset also includes data exploration, SQL query generation, and data slicing and dicing. It has a user-friendly interface that allows users to quickly drag and drop data to create interactive dashboards and reports.

Superset is highly customizable and can be extended through custom plugins and integrations. It also supports integration with popular authentication providers and supports role-based access control for data and dashboard sharing.

Customize Config

To customize the configuration of Apache Superset, you can modify its configuration files to tailor the behavior and appearance of the application. By adding the volume to run the command you can customize the config file. In the superset_config.py, the below definitions are added to override login methods.

# other configs
from custom_security import CustomSecurityManager
CUSTOM_SECURITY_MANAGER = CustomSecurityManager
# other configs

Example Project

To better understand, an example project is explained. For redirect assuming that the token is generated from another project. The token should write into a database. An example table can have columns like below.

The main project should insert a token before redirecting the user to the Apache superset. The consumed column should be false in the insertion to prevent second use.

Custom Security

Apache Superset supports integration with external authentication and authorization providers. Users can customize the authentication and authorization logic to meet their specific requirements. For creating a custom login custom_security.py file was created. In the example, the Oracle database is used.

from flask import redirect, g, flash, request
from flask_appbuilder.security.views import UserDBModelView, AuthDBView
from superset.security import SupersetSecurityManager
from flask_appbuilder.security.views import expose
from flask_appbuilder.security.manager import BaseSecurityManager
from flask_login import login_user, logout_user
from datetime import datetime
import cx_Oracle

class SupersetAuth:
    def __init__(self, id, token, username, consumed, creationDate, expirationDate, consumedDate, userId):
        self.id = id
        self.token = token
        self.username = username
        self.consumed = consumed
        self.creationDate = creationDate
        self.expirationDate = expirationDate
        self.consumedDate = consumedDate
        self.userId = userId


class CustomAuthDBView(AuthDBView):
    login_template = 'appbuilder/general/security/login_db.html'

    @expose('/login/', methods=['GET', 'POST'])
    def login(self):
        authsuccess = False
        usernameFromPath = ''
        token = ''
        redirect_url = self.appbuilder.get_url_for_index

        if request.args.get('redirect') is not None:
            redirect_url = request.args.get('redirect')
        if request.args.get('username') is not None:
            usernameFromPath = request.args.get('username')
            user = self.appbuilder.sm.find_user(username=usernameFromPath)
        if request.args.get('token') is not None:
            token = request.args.get('token')

        if usernameFromPath != '':
            try:
                connection = cx_Oracle.connect('username', 'password', 'host:port/schema', encoding="UTF-8")
                connection.autocommit = True
                cursor = connection.cursor()
                cursor.execute('select * from superset_auth where token=:tokenToDb', tokenToDb=token)
                fromDb = cursor.fetchone()
                if fromDb:
                    supersetAuth = SupersetAuth(*fromDb)
                    today = datetime.today()
                    if supersetAuth.consumed == 1:
                        flash('InvalidToken', 'warning')
                        return super().login()
                    if supersetAuth.expirationDate > today and supersetAuth.username == usernameFromPath:
                        statement = "update superset_auth set consumed=:consumed, consumed_time=:consumedTime where id=:id"
                        cursor.execute(statement, {'consumed': True, 'consumedTime': today, 'id': supersetAuth.id})
                        authsuccess = True
            except cx_Oracle.Error as error:
                print(error)
            finally:
                if connection:
                    cursor.close()
                    connection.close()

        if g.user is not None and g.user.is_authenticated and not authsuccess:
            return redirect(redirect_url)

        if authsuccess:
            login_user(user, remember=False)
            return redirect(redirect_url)
        else:
            flash('Auto Login Failed', 'warning')
            return super().login()


class CustomSecurityManager(SupersetSecurityManager):
    authdbview = CustomAuthDBView

    def __init__(self, appbuilder):
        super().__init__(appbuilder)

Installation of Superset

Assuming that custom_security.py and superset_config.py are located in /DATA/etc/superset in your machine.

docker run - detach -v DATA/etc/superset:/etc/superset –name superset -p 8088:8088 amancevice/superset

This command creates a Docker container named “superset” and maps the container’s port 8088 to the host machine’s port 8088, which is the default port used by Superset. You can use a different port number if needed.

To start superset enter the container and run the below commands on bash.

docker exec -it superset /bin/bash
superset fab create-admin --username admin --firstname admin --lastname admin --email admin@testmail.com --password Admin1234!
superset db upgrade
superset load_examples
superset init

Your superset will be ready to use in a little while.

Usage of Custom Login

After the token is generated, url should be like this.
http://host:port/login?username=username&token=tokenSuperset will automatically log the user into the system and inform the database that the token has been used.
You can also log in to the system with a Username and Password.

Conclusion

Superset is an advanced data visualization tool and is preferred by many people and institutions because it is free. When integrating the superset into existing UI projects, it may be necessary to customize the login methods. In the example we gave in this article, we have seen how to log in to the system automatically using Tokens. By changing the rewritten config file, it can be provided to serve different scenarios.

Как создать пользователя при авторизации через keycloak в Apache Superset

2022-08-26T11:20:46.300Z

Автоматическое создание пользователя

В данном примере приведен скрипт из config файла, который автоматически создает пользователя при авторизации через keycloak. Кейс не полный, это лишь отрывок кода, но возможно кому-то поможет.

configOverrides:
  enable_remote_user: |
    from flask_appbuilder.security.manager import AUTH_REMOTE_USER
    from superset.security import SupersetSecurityManager
    from flask import redirect, g, flash, request, session
    from flask_appbuilder._compat import as_unicode
    from flask_appbuilder.security.views import expose, AuthRemoteUserView
    from flask_appbuilder.security.forms import LoginForm_db
    from flask_login import login_user

    class CustomRemoteUserView(AuthRemoteUserView):
        login_template = "appbuilder/general/security/login_db.html"

        @expose('/login/', methods=["GET", "POST"])
        def login(self):
            if g.user is not None and g.user.is_authenticated:
                return redirect(self.appbuilder.get_url_for_index)

            username = request.headers.get('X-Auth-Username', None)
            if username:
                user = self.appbuilder.sm.auth_user_remote_user(username)
                if user is None:
                    first_name = request.headers.get('X-Auth-Given-Name', '')
                    last_name = request.headers.get('X-Auth-Family-Name', '')
                    email = username
                    user_role = self.appbuilder.sm.find_role(AUTH_NEW_USER_ROLE)
                    user = self.appbuilder.sm.add_user(username, first_name, last_name, email, user_role)

                login_user(user)
                return redirect(self.appbuilder.get_url_for_index)
            else:
                form = LoginForm_db()
                if form.validate_on_submit():
                    user = self.appbuilder.sm.auth_user_db(
                        form.username.data, form.password.data
                    )
                    if not user:
                        flash(as_unicode(self.invalid_login_message), 'warning')
                        return redirect(self.appbuilder.get_url_for_login)
                    login_user(user, remember=False)
                    return redirect(self.appbuilder.get_url_for_index)
                return self.render_template(
                    self.login_template, title=self.title, form=form, appbuilder=self.appbuilder
                )

    class CustomSecurityManager(SupersetSecurityManager):
        authremoteuserview = CustomRemoteUserView

    ENABLE_PROXY_FIX = True
    AUTH_TYPE = AUTH_REMOTE_USER
    CUSTOM_SECURITY_MANAGER = CustomSecurityManager
    AUTH_USER_REGISTRATION = False
    AUTH_NEW_USER_ROLE = 'Public'

    # Workaround as defult config from chart not set redis password for celery brokers
    class CustomCeleryConfig(object):
      BROKER_URL = f"redis://:{env('REDIS_PASSWORD')}@{env('REDIS_HOST')}:{env('REDIS_PORT')}/0"
      CELERY_IMPORTS = ('superset.sql_lab', )
      CELERY_RESULT_BACKEND = f"redis://:{env('REDIS_PASSWORD')}@{env('REDIS_HOST')}:{env('REDIS_PORT')}/0"
      CELERY_ANNOTATIONS = {'tasks.add': {'rate_limit': '10/s'}}

    CELERY_CONFIG = CustomCeleryConfig
    RESULTS_BACKEND = RedisCache(
          host=env('REDIS_HOST'),
          port=env('REDIS_PORT'),
          password=env('REDIS_PASSWORD'),
          key_prefix='superset_results'
    )

Using OpenIDKeycloak with Superset

https://www.anycodings.com/1questions/1028410/using-openidkeycloak-with-superset

Если вдруг статья не откроется - ниже копия.

Questions : Using OpenIDKeycloak with Superset

I want to use keycloak to authenticate my anycodings_apache-superset users in our Superset environment.

Superset is using flask-openid, as anycodings_apache-superset implemented in flask-security:

To enable a different user authentication anycodings_apache-superset than the regular one (database), you need to anycodings_apache-superset override the AUTH_TYPE parameter in your anycodings_apache-superset superset_config.py file. You will also need anycodings_apache-superset to provide a reference to your anycodings_apache-superset openid-connect realm and enable user anycodings_apache-superset registration. As I understand, it should anycodings_apache-superset look something like this:

from flask_appbuilder.security.manager import AUTH_OID
AUTH_TYPE = AUTH_OID
OPENID_PROVIDERS = [
    { 'name':'keycloak', 'url':'http://localhost:8080/auth/realms/superset' }
]
AUTH_USER_REGISTRATION = True
AUTH_USER_REGISTRATION_ROLE = 'Gamma'

With this configuration, the login page anycodings_apache-superset changes to a prompt where the user can anycodings_apache-superset select the desired OpenID provider (in our anycodings_apache-superset case keycloak). We also have two buttons, anycodings_apache-superset one to sign in (for existing users) and one anycodings_apache-superset to register as a new user.

I would expect that either of these buttons anycodings_apache-superset would take me to my keycloak login page. anycodings_apache-superset However, this does not happen. Instead, I am anycodings_apache-superset redirected right back to the login page.

In the case where I press the registration anycodings_apache-superset button, I get a message that says 'Not anycodings_apache-superset possible to register you at the moment, try anycodings_apache-superset again later'. When I press the sign in anycodings_apache-superset button, no message is displayed. The anycodings_apache-superset Superset logs show the request that loads anycodings_apache-superset the login page, but no requests to keycloak. anycodings_apache-superset I have tried the same using the Google anycodings_apache-superset OpenID provider, which works just fine.

Since I am seeing no requests to keycloak, anycodings_apache-superset this makes me think that I am either missing anycodings_apache-superset a configuration setting somewhere, or that I anycodings_apache-superset am using the wrong settings. Could you anycodings_apache-superset please help me figure out which settings I anycodings_apache-superset should be using?

PYTHON OPENID-CONNECT KEYCLOAK FLASK-SECURITY APACHE-SUPERSET

Total Answers 3

Answers 1 : of Using OpenIDKeycloak with Superset

Update 03-02-2020

@s.j.meyer has written an updated guide anycodings_python which works with Superset 0.28.1 and up. anycodings_python I haven't tried it myself, but thanks anycodings_python @nawazxy for confirming this solution anycodings_python works.

I managed to solve my own question. The anycodings_python main problem was caused by a wrong anycodings_python assumption I made regarding the anycodings_python flask-openid plugin that superset is anycodings_python using. This plugin actually supports anycodings_python OpenID 2.x, but not OpenID-Connect anycodings_python (which is the version implemented by anycodings_python Keycloak).

As a workaround, I decided to switch to anycodings_python the flask-oidc plugin. Switching to a anycodings_python new authentication provider actually anycodings_python requires some digging work. To integrate anycodings_python the plugin, I had to follow these steps:

Configue flask-oidc for keycloak

Unfortunately, flask-oidc does not anycodings_python support the configuration format anycodings_python generated by Keycloak. Instead, your anycodings_python configuration should look something like anycodings_python this:

{
    "web": {
        "realm_public_key": "<YOUR_REALM_PUBLIC_KEY>",
        "issuer": "http://<YOUR_DOMAIN>/auth/realms/<YOUR_REALM_ID>",
        "auth_uri": "http://<YOUR_DOMAIN>/auth/realms/<YOUR_REALM_ID>/protocol/openid-connect/auth",
        "client_id": "<YOUR_CLIENT_ID>",
        "client_secret": "<YOUR_SECRET_KEY>",
        "redirect_urls": [
            "http://<YOUR_DOMAIN>/*"
        ],
        "userinfo_uri": "http://<YOUR_DOMAIN>/auth/realms/<YOUR_REALM_ID>/protocol/openid-connect/userinfo",
        "token_uri": "http://<YOUR_DOMAIN>/auth/realms/<YOUR_REALM_ID>/protocol/openid-connect/token",
        "token_introspection_uri": "http://<YOUR_DOMAIN>/auth/realms/<YOUR_REALM_ID>/protocol/openid-connect/token/introspect"
    }
}

Flask-oidc expects the configuration to anycodings_python be in a file. I have stored mine in anycodings_python client_secret.json. You can configure anycodings_python the path to the configuration file in anycodings_python your superset_config.py.

Extend the Security Manager

Firstly, you will want to make sure that anycodings_python flask stops using flask-openid ad starts anycodings_python using flask-oidc instead. To do so, you anycodings_python will need to create your own security anycodings_python manager that configures flask-oidc as anycodings_python its authentication provider. I have anycodings_python implemented my security manager like anycodings_python this:

from flask_appbuilder.security.manager import AUTH_OID
from flask_appbuilder.security.sqla.manager import SecurityManager
from flask_oidc import OpenIDConnect
    
class OIDCSecurityManager(SecurityManager):

def __init__(self,appbuilder):
    super(OIDCSecurityManager, self).__init__(appbuilder)
    if self.auth_type == AUTH_OID:
        self.oid = OpenIDConnect(self.appbuilder.get_app)
    self.authoidview = AuthOIDCView

To enable OpenID in Superset, you would anycodings_python previously have had to set the anycodings_python authentication type to AUTH_OID. My anycodings_python security manager still executes all the anycodings_python behaviour of the super class, but anycodings_python overrides the oid attribute with the anycodings_python OpenIDConnect object. Further, it anycodings_python replaces the default OpenID anycodings_python authentication view with a custom one. I anycodings_python have implemented mine like this:

from flask_appbuilder.security.views import AuthOIDView
from flask_login import login_user
from urllib import quote

class AuthOIDCView(AuthOIDView):

@expose('/login/', methods=['GET', 'POST'])
def login(self, flag=True):
    
    sm = self.appbuilder.sm
    oidc = sm.oid

    @self.appbuilder.sm.oid.require_login
    def handle_login(): 
        user = sm.auth_user_oid(oidc.user_getfield('email'))
        
        if user is None:
            info = oidc.user_getinfo(['preferred_username', 'given_name', 'family_name', 'email'])
            user = sm.add_user(info.get('preferred_username'), info.get('given_name'), info.get('family_name'), info.get('email'), sm.find_role('Gamma')) 
        
        login_user(user, remember=False)
        return redirect(self.appbuilder.get_url_for_index)  
   
return handle_login()  

@expose('/logout/', methods=['GET', 'POST'])
def logout(self):
    
    oidc = self.appbuilder.sm.oid
    
    oidc.logout()
    super(AuthOIDCView, self).logout()        
    redirect_url = request.url_root.strip('/') + self.appbuilder.get_url_for_login
    
    return redirect(oidc.client_secrets.get('issuer') + '/protocol/openid-connect/logout?redirect_uri=' + quote(redirect_url))

My view overrides the behaviours at the anycodings_python /login and /logout endpoints. On login, anycodings_python the handle_login method is run. It anycodings_python requires the user to be authenticated by anycodings_python the OIDC provider. In our case, this anycodings_python means the user will first be redirected anycodings_python to Keycloak to log in.

On authentication, the user is anycodings_python redirected back to Superset. Next, we anycodings_python look up whether we recognize the user. anycodings_python If not, we create the user based on anycodings_python their OIDC user info. Finally, we log anycodings_python the user into Superset and redirect them anycodings_python to the landing page.

On logout, we will need to invalidate anycodings_python these cookies:

The superset session
The OIDC token
The cookies set by Keycloak

By default, Superset will only take care anycodings_python of the first. The extended logout method anycodings_python takes care of all three points.

Configure Superset

Finally, we need to add some parameters anycodings_python to our superset_config.py. This is how anycodings_python I've configured mine:

'''
AUTHENTICATION
'''
AUTH_TYPE = AUTH_OID
OIDC_CLIENT_SECRETS = 'client_secret.json'
OIDC_ID_TOKEN_COOKIE_SECURE = False
OIDC_REQUIRE_VERIFIED_EMAIL = False
CUSTOM_SECURITY_MANAGER = OIDCSecurityManager
AUTH_USER_REGISTRATION = True
AUTH_USER_REGISTRATION_ROLE = 'Gamma'

Answers 2 : of Using OpenIDKeycloak with Superset

I had some trouble with the OIDC anycodings_python library, so I configured it a bit anycodings_python differently -

In Keycloak, I created a new client with anycodings_python standard flow and confidential access. I anycodings_python also added a roles token claim in the anycodings_python mapper, so I could map "Client Roles" to anycodings_python Superset Roles.

For Superset, I mount the custom anycodings_python configuration files to my container [k8s anycodings_python in my case].

/app/pythonpath/custom_sso_security_manager.py

import logging
import os
import json
from superset.security import SupersetSecurityManager


logger = logging.getLogger('oauth_login')

class CustomSsoSecurityManager(SupersetSecurityManager):

    def oauth_user_info(self, provider, response=None):
        logging.debug("Oauth2 provider: {0}.".format(provider))

        logging.debug("Oauth2 oauth_remotes provider: {0}.".format(self.appbuilder.sm.oauth_remotes[provider]))

        if provider == 'keycloak':
            # Get the user info using the access token
            res = self.appbuilder.sm.oauth_remotes[provider].get(os.getenv('KEYCLOAK_BASE_URL') + '/userinfo')

            logger.info(f"userinfo response:")
            for attr, value in vars(res).items():
                print(attr, '=', value)

            if res.status_code != 200:
                logger.error('Failed to obtain user info: %s', res._content)
                return

            #dict_str = res._content.decode("UTF-8")
            me = json.loads(res._content)

            logger.debug(" user_data: %s", me)
            return {
                'username' : me['preferred_username'],
                'name' : me['name'],
                'email' : me['email'],
                'first_name': me['given_name'],
                'last_name': me['family_name'],
                'roles': me['roles'],
                'is_active': True,
            }

    def auth_user_oauth(self, userinfo):
        user = super(CustomSsoSecurityManager, self).auth_user_oauth(userinfo)
        roles = [self.find_role(x) for x in userinfo['roles']]
        roles = [x for x in roles if x is not None]
        user.roles = roles
        logger.debug(' Update <User: %s> role to %s', user.username, roles)
        self.update_user(user)  # update user roles
        return user

and in anycodings_python /app/pythonpath/superset_config.py I anycodings_python added some configs -

from flask_appbuilder.security.manager import AUTH_OAUTH, AUTH_REMOTE_USER

from custom_sso_security_manager import CustomSsoSecurityManager
CUSTOM_SECURITY_MANAGER = CustomSsoSecurityManager

oauthSecretPair = env('OAUTH_CLIENT_ID') + ':' + env('OAUTH_CLIENT_SECRET')

AUTH_TYPE = AUTH_OAUTH

OAUTH_PROVIDERS = [
    {   'name':'keycloak',
        'token_key':'access_token', # Name of the token in the response of access_token_url
        'icon':'fa-address-card',   # Icon for the provider
        'remote_app': {
            'api_base_url': env('KEYCLOAK_BASE_URL', 'http://CHANGEME'),
            'client_id':env('OAUTH_CLIENT_ID'),  # Client Id (Identify Superset application)
            'client_secret':env('OAUTH_CLIENT_SECRET'), # Secret for this Client Id (Identify Superset application)
            'client_kwargs':{
                'scope': 'profile'               # Scope for the Authorization
            },
            'request_token_url':None,
            'access_token_url': env('KEYCLOAK_BASE_URL', 'http://CHANGEME') + '/token',
            'authorize_url': env('KEYCLOAK_BASE_URL', 'http://CHANGEME') + '/auth',
        }
    }
]

# Will allow user self registration, allowing to create Flask users from Authorized User
AUTH_USER_REGISTRATION = True

# The default user self registration role
AUTH_USER_REGISTRATION_ROLE = "Gamma"

# This will make sure the redirect_uri is properly computed, even with SSL offloading
ENABLE_PROXY_FIX = True

There are a few env parameters that anycodings_python these configs expect -

KEYCLOAK_BASE_URL
OAUTH_CLIENT_ID
OAUTH_CLIENT_SECRET

Answers 3 : of Using OpenIDKeycloak with Superset

I tried to follow the tips based on the anycodings_python comments in this post, but even so, anycodings_python there were still other doubts along the anycodings_python process, and I managed to solve the anycodings_python problem and it works perfectly, I would anycodings_python like to share the code to solve the anycodings_python problem superset-keycloak. This aprouch anycodings_python use docker to deploy the superset anycodings_python application.