把 BI 看板和数据查询收回自己服务器（Apache Superset）

数据团队大概都遇到过这种循环：业务方要一个看板，分析师把数据导出来做成表格，截图发过去，下周口径变了再重做一遍。商业 BI 产品能解决其中一部分问题，按席位计费的模式却常常先让预算卡住。Superset 给的是另一种做法，查询和展示都跑在自己部署的服务上，原始数据继续留在自己的数据库里。

Apache Superset 由 Python 编写，连接任何具备 Python DB-API driver 与 SQLAlchemy dialect 的 SQL 数据源，输入数据库连接加 SQL 语句或界面拖拽，输出图表、仪表盘与可嵌入的页面。

它需要自己部署。仓库根目录放着 Dockerfile、INSTALL.md、Makefile，发布列表里全是 superset-helm-chart 系列，说明 Kubernetes 环境通常走 Helm 这条路。同一套系统会服务三类人：分析师在无代码界面里搭图，数据工程同学在 SQL Lab 里写查询，运维和管理员负责安装、配数据源、发权限。项目托管在 Apache 软件基金会，仓库地址是 https://github.com/apache/superset，采用 Apache-2.0 许可证，主要语言是 Python，TypeScript 占 43.2%。

主要功能

README 把能力写成了一份清单，按实际能操作的东西拆开来看是这样。

• 无代码图表构建：在 Explore 界面里选数据集，拖拽维度和指标生成图表，整个过程不需要写 SQL。这条排在 README 功能清单的第一位。
• SQL Lab：基于 Web 的 SQL 编辑器，用来写查询、看结果、把查询结果保存成数据集，供图表复用。README 里对应的截图标题是 “Powerful SQL Editor”。
• 轻量语义层：定义自定义维度和指标，让同一套口径在多个图表之间复用，README 用的说法是 lightweight semantic layer。
• 数据源接入：任何具备 Python DB-API driver 与 SQLAlchemy dialect 的 SQL 数据源都能接。README 列出的支持对象包括 Amazon Athena、Amazon Redshift、Apache Doris、Apache Druid、Apache Hive、Apache Impala、Apache Kylin、Apache Pinot、Apache Spark SQL、ClickHouse、CockroachDB、CrateDB、Databend、Azure Data Explorer、Azure Synapse、Cloudflare D1 等。
• 可视化类型：README 说覆盖范围从简单柱状图一直到地理空间可视化。
• 缓存层：一套轻量、可配置的缓存，用来降低数据库压力。
• 权限与认证：安全角色和认证方式都可以配置。Issue 列表里能看到行级安全方案 SIP-29 已经被处理。
• API：README 提到提供 API 用于程序化定制，具体端点清单在 developer docs 里，仓库节选没有展开。

安装方面，仓库提供的是 Dockerfile、INSTALL.md、Makefile 三类入口，正式发行走 superset-helm-chart 仓库包。实测命令仓库里没有说明这一步，README 只把读者引向 superset.apache.org 上的 User Guide、Administrator Guide、Developer Guide 三份文档。后端是 Flask（根目录有 .flaskenv），前端是 TypeScript 与 React，跑起来要同时管这两端和元数据库，仓库节选里没有给出可以直接复制的启动命令。

同类 BI 工具横向对照

下面两个项目与 Superset 做的是同一件事，放在一起看能更快判断位置。

Superset 在这组对比里最明显的短板是重。仓库体积 1222301 KB，部署要同时管 Flask 后端、前端资源、元数据库和缓存，升级还得按 UPDATING.md 逐版本比对；Issue 里那条从 3.1.0 升到 3.1.1 之后嵌入仪表盘直接报错，就是升级代价的一个例子。如果团队没有专职运维，只需要几张固定看板，去用表里那两个更轻的同类项目更划算。它的优势反过来也在这里：数据源覆盖面和可嵌入能力是另外两个项目在 README 里没有承诺过的。

它的实际表现

下面是仓库当前能查到的量化指标，全部来自仓库事实表。

• Star：75010
• Fork：18422
• Watcher：1539
• 开放 Issue：522
• 仓库体积：1222301 KB
• 创建时间：2015-07-22
• 最近一次提交：2026-10-03
• 主要语言：Python 53.5%，TypeScript 43.2%，HTML 2.3%
• 许可证：Apache-2.0
• 最近一次发布：superset-helm-chart-0.22.8（2026-09-10）；此前依次为 0.22.7（2026-09-05）、0.22.6（2026-08-14）、0.22.5（2026-08-10）、0.22.4（2026-07-28）

这些数字说明什么

75010 个 star、18422 个 fork、1539 个 watcher，放在开源 BI 这个类目里属于第一梯队的关注度，选型时不太需要担心项目突然没人管。

最近一次提交是 2026-10-03，仓库推送时间在 2026-10-02，说明主干还在持续接收代码。

创建时间 2015-07-22，最近提交 2026-10-03，一个跨了这么长时间的仓库还能保持提交，项目寿命这一项不用太担心。它的维护者背后是 Apache 软件基金会，许可证是 Apache-2.0，商用条款相对宽松。

Helm chart 从 2026-07-28 的 0.22.4 到 2026-09-10 的 0.22.8，两个多月发了五个版本，容器化部署路线的迭代节奏不慢。

522 个开放 Issue 是另一个方向的信号。放在 75010 星的量级上看不算失控，但也说明历史包袱和待办是真实存在的，提 Issue 之前最好先搜一遍。

数据看不到的部分

Star 数衡量的是有多少人点过收藏，衡量不了代码质量，也衡量不了这套系统装起来顺不顺。1222301 KB 的仓库体积本身就在提示，读源码熟悉它是一件成本很高的事。

522 个开放 Issue 只能看到总量，看不到里面的构成。事实表里能逐条看到的是按评论数排序的 15 条，其中 14 条标记为已解决，只有 SIP-116（简化时间范围过滤）还挂着待解决。这个分布看起来不错，但它是按评论热度抽出来的样本，不能代表剩下那 500 多个。

数字也看不出文档是否过期。事实表里能确认的只有 README 指向三份文档站点，以及根目录存在一份 267.2 KB 的 UPDATING.md，具体内容是否跟得上当前版本，需要自己去看。

短期热度是另一个盲区。这个仓库从 2015 年活到现在，基本排除了短期炒作的可能，但热度与稳定性反过来又会掩盖一件事：功能多、数据源广，同时意味着容易踩到只跟某个数据库驱动相关的问题。Issue 里那条 “ModuleNotFoundError: No module named 'sqlglot'”，以及默认账号 admin/admin 登录失败被反复讨论，都属于这类与实际部署环境强绑定的坑。

所以值不值得试

值得试的情形：团队已经有自己的数据库和基本的运维能力，要服务多个业务方，眼睛盯着的是把 BI 从按席位付费换成自建；或者需要接的数据源比较冷门，只要求它有 Python DB-API driver 和 SQLAlchemy dialect。

值得试的另一种情形：看板要嵌进自己的产品页面里，Issue 里 SIP-63、行级安全 SIP-29 这类提案的落地情况说明这套能力是被认真维护的。

先别急的情形：团队里没有能长期维护一套 Web 服务的人。Superset 要同时管后端、前端、元数据库和缓存，升级路径还得逐版本读 UPDATING.md，人手不够时这套成本会超过收益。

先别急的另一种情形：需求只是几张固定报表，或者只想用托管服务、不想碰服务器。这类场景下，表里列出的同类轻量项目，或者继续用现成的商业工具，都比自建 Superset 更合适。

焚评：这个项目的量化评分

本项目的选题来自 焚.com（一个按公开公式给 GitHub 项目打分的站）。焚评当前总分 9.9 分（满分 10）。下表是各维度的得分：

评分口径、权重与计算方式见焚.com 的评分方法页；数据随 GitHub 指标刷新，具体数值以焚.com 当前页面为准。本文正文为诀.com 独立撰写，评分数据由焚.com 授权引用。