Redash 调研：28K Stars 的开源 SQL 协作 BI，35+ 数据源 + 告警 + 仪表盘一把梭

一个让产品 / 运营 / 分析师都能写 SQL、画图、订告警的浏览器 BI 工具。12 年迭代、BSD-2-Clause、被 Grafana 收购后仍在独立维护，是 ” 自托管 SQL 协作 BI” 的事实标准之一。

写在前面

数据团队每天都被一类需求包围：产品要看昨天的新增用户、运营要一张按渠道拆分的留存图、老板要把上周的 GMV 看板钉在会议室大屏上。

Superset 给的是 ” 分析师玩的花活 ”，Metabase 给的是 ” 老板拖两下的清爽 ”，而 Redash 卡在中间那个最实用的位置：让任何会写 SQL 的人 5 分钟搭一个可分享、可定时刷新、可告警的看板。

它不追求可视化多么惊艳、SQL 编辑器多么智能，它的核心承诺只有一条——“ 连接任何数据源，写 SQL，发个链接给同事，就这么简单 ”。12 年过去，这个定位依然成立。

一、它解决什么问题

一句话卖点：自托管 SQL 协作 BI 标准件，35+ 数据源 + 浏览器 SQL 编辑器 + 可分享仪表盘 + 条件告警。

二、核心能力：SQL 优先的浏览器 BI

2.1 35+ 数据源是它的护城河

Redash 内置的数据源覆盖了几乎所有常见场景，下表按类别整理（精选自 README 的完整列表）：

对比优势：Metabase 数据源 ~25 个、Superset 数据源 ~50+ 但配置繁琐。Redash 处于 ” 够用且不折腾 ” 的甜区——新增数据源只需写一个 query runner 类（Python）。

2.2 浏览器 SQL 编辑器

• Schema Browser：左侧自动列出当前数据源的所有表 / 字段，点击即插入
• Auto-complete：表名、字段名补全
• Snippets：把常用 SQL 片段（WITH 子查询、聚合模板）存成 snippet，跨数据源复用
• 参数化查询：{{param}} 语法，URL 传参实现 ” 同一查询不同筛选 ”
• 查询历史：每一次 Run 都存档，方便回溯

2.3 可视化 + Dashboard

• 拖拽式可视化：柱状 / 折线 / 饼图 / 箱线 / 地图 / 桑基 / 透视 / 箱线 /cohort 等 30+ 图表
• Dashboard 组合：把多个 Query 的可视化拖到一个 Dashboard，支持 grid 布局
• Public Link：每个 Query 和 Dashboard 都有可分享 URL，支持公开访问（无需登录）
• 定时刷新：按 cron 表达式自动跑查询，缓存结果到 PostgreSQL

2.4 告警（Alerts）

这是 Redash 的 杀手锏：

• 基于 Query 结果设阈值（如 SELECT count(*) FROM events WHERE ... > 100）
• 当结果满足条件 → 发通知
• 通知渠道：Email / Slack / Webhook / PagerDuty / HipChat
• 告警状态机：TRIGGERED / OK / UNKNOWN 三态
• 适用场景：DAU 跌破阈值 / 错误率飙升 / 订单金额异常 / 队列积压

对比：Metabase 的告警功能是 2020 年后才加的，体验不如 Redash 成熟。Superset 直到 3.0 才有原生告警。

三、生态扩展：API + Alert + Schedule

3.1 REST API

所有 UI 操作都有对应 API：

价值：可以把 Redash 嵌入到内部系统（如用后端调 API 创建 Query，前端 iframe 嵌 Dashboard），也可以做 ”Query 即服务 ”。

3.2 数据源扩展

新增数据源只需 3 步：

1. 实现 redash.query_runner.BaseQueryRunner 子类
2. 注册到 redash.settings.query_runners
3. 重启服务

社区贡献了大量 query runner（80+ 在 issues/discussions 里），覆盖 ClickHouse / Databend / DuckDB / RisingWave 等新数据库。

3.3 配套工具

• redashbot（doiken/redashbot）：Slack Bot，问 ”DAU 是多少 ” 机器人自动跑 Redash 截图给你
• AWS/GCE 镜像：官方提供一键部署镜像（适合不想碰 Docker 的人）
• Docker Compose：标准部署方式，5 分钟起一个实例

四、对比 Superset / Metabase / Lightdash

结论：

• 选 Redash —— 团队会 SQL、想要 ” 写一次 Query 全公司复用 ”、告警是关键需求
• 选 Superset —— 大厂、需要分析师深度探索、愿意吃 Apache 全家桶
• 选 Metabase —— 非技术用户多、要 ” 老板能自己拖 ”
• 选 Lightdash —— 已经上 dbt、要语义层统一

五、实战：3 步跑通

5.1 一键 Docker 部署

# 1. 拉官方 compose
git clone https://github.com/getredash/setup.git && cd setup

# 2. 改 cookie_secret 和 database password
echo "export REDASH_COOKIE_SECRET=$(openssl rand -hex 32)" >> .env
echo "export REDASH_DATABASE_PASSWORD=$(openssl rand -hex 16)" >> .env

# 3. 起来
docker-compose -f docker-compose.yml run --rm server create_db
docker-compose -f docker-compose.yml up -d

# 访问 http://localhost:5000

5.2 接 PostgreSQL + 跑第一个 Query

1. 登录 → 右上角 “+ New Data Source” → PostgreSQL → 填连接信息
2. “+ New Query” → 选数据源 → 写 SQL：
   sql
SELECT date_trunc('day', created_at) AS day,
count(*) AS new_users
FROM users
WHERE created_at > '{{start_date}}'
GROUP BY 1 ORDER BY 1;
3. 点 “Execute” → 切到 Visualization 选图表 → 保存为 Dashboard 一部分

5.3 加告警（DAU 跌破阈值）

1. 打开已保存的 Query → “Alerts” Tab → “Add Alert”
2. 选列（new_users）、条件（< 100）、触发时机（cron 0 9 * * *）
3. 通知渠道填 Email 或 Slack Webhook
4. 保存 → 第二天早上 9 点自动检查，跌破就发通知

六、风险与坑

七、总结

Redash 最适合的三个场景：

1. SQL-native 团队 —— 大家都会 SQL，只缺一个 ” 能分享 + 能告警 ” 的轻量 BI
2. 告警驱动运维 —— DAU、错误率、订单量等关键指标的阈值监控，比 Prometheus 友好
3. 多数据源 + 快速验证 —— 35+ 数据源覆盖主流数据库，5 分钟接一个

一句话建议：

如果你的团队 ” 会写 SQL 的人多、需要告警、不想折腾复杂 BI”，先用 Redash，它会在 1 周内成为内部最高频的 BI 工具；如果半年后撞到天花板（权限 / 血缘 / 可视化不够），再迁移到 Superset。

先试一周：Docker compose 跑起来 → 接 PostgreSQL → 跑 3 个核心指标 → 设 1 个告警。这一周你会知道它是不是你团队的 ” 标准 BI 答案 ”。

参考

• getredash/redash — GitHub 仓库
• Redash 官网 — 官方主页
• Redash 文档 — 完整文档
• Redash Release Notes — 版本更新日志
• Docker 安装教程 — 官方安装指南
• doiken/redashbot — Slack 机器人集成
• GitHub Issues — 797 个待解决 issue
• Superset / Metabase / Redash 对比 — 经典三方对比（中文）

研究文档（引用来源参考）

(no reference document available)