Apache Superset 被Airbnb等企业使用，使用 Kubernetes 作为 Superset 的 PaaS，每天为 600 多名活跃用户提供查看超过 10 万张图表的服务。
- 使用云原生CloudNative架构Web 服务器（Gunicorn、Nginx、Apache）
- 元数据数据库引擎（MySQL、PostgreSQL、MariaDB）
- 消息队列（Redis、 RabbitMQ、SQS）
- 结果后端（S3、Redis、Memcached等）
- 缓存层（Memcached、Redis）
为了支持 Airbnb 的规模，我们在 Superset 内部和周围构建了几个自定义功能。这些配置选项、日常离线作业和仓库优化是扩展 Superset 的关键。
缓存预热作业
在 Airbnb 每天查看的所有仪表板中，90% 的仪表板被多次查看。再加上目前大多数新数据每天只通过我们的 ETL（提取、转换、加载）作业登陆一次，这意味着每天缓存仪表板图表的结果可以显着提高大多数用户的性能。使用Apache Airflow ，我们实施了一种有效的离线缓存预热策略，专注于预热最近查看的仪表板，从而使 Presto 支持的图表的缓存命中率达到 86%。由于 Superset 在 Redis * 中本机支持缓存图表请求，我们能够在非工作时间以编程方式加载流行的仪表板，从而减少我们的查询引擎 Presto 和Apache Druid的负载 ，在高峰时段。这将缓存图表加载时间从未缓存时的 30 多秒缩短到 4 秒以下。
域分片
在 Superset 中加载仪表板时，会同时触发仪表板上每个可见图表的单个请求。尽管这在请求快速且仪表板很小的情况下有效，但由于仪表板包含许多图表，我们很快就会遇到浏览器设置问题。大多数现代浏览器将向单个域（即 Superset API）发出的并发请求数限制为 6 个，从而导致大型仪表板速度变慢的瓶颈。为了处理这个问题，我们构建了SUPERSET_WEBSERVER_DOMAINS配置选项。通过设置此选项，管理员可以允许尽可能多的并发仪表板查询，因为他们的数据库引擎可以支持（可能需要有效的缓存来确保引擎不会过载）。我们将四个不同的子域路由到我们的 Web 服务器，在单个仪表板上支持多达 24 个并发查询。此功能是允许用户构建复杂仪表板和提高性能的关键。
数据库引擎负载管理
虽然 Superset 允许进行很多本机优化，但一些性能和稳定性改进只能在数据库引擎级别完成。由于复杂的业务需求和我们数据集的大小，许多仪表板触发的查询平均需要 25 秒才能执行。因此，我们采取了以下步骤来确保我们的数据库引擎集群不会过载：
- 根据重要性路由查询：我们将查询路由到不同的集群（使用DB_CONNECTION_MUTATOR配置）以避免资源争用；优化的仪表板查询被发送到一个集群，而临时 SQL 实验室和探索查询被发送到另一个集群。
- 限制每个用户的并发：我们限制每个用户在我们的数据库引擎上同时运行三个查询。虽然这可能看起来很小，但考虑到前面提到的缓存预热作业，它实际上已经足够了。在理想情况下，实际上很少有查询进入我们的数据库引擎，并且缓存有效地返回结果而不是重新运行查询。
- 限制大型查询：我们将可以运行的查询大小限制为一定的内存大小或分区数。这鼓励用户创建合理复杂的有效查询。