Chartbrew 介绍与选型指南

目标：回答「Chartbrew 是什么、能做什么、和同类 BI 工具相比该怎么选」，为是否引入 Chartbrew 提供决策依据。本文为认知篇，全部数据来自官方仓库、官方文档站与 GitHub/Docker Hub 公开信息联网实查（查询日期 2026-11-03），不含本地实测；部署与配置实操见 《Chartbrew Docker Compose 部署指南》 与 《Chartbrew 6.0.0 配置参数详解》。

一、环境信息（本文口径）

• 评估对象：Chartbrew（GitHub 仓库 chartbrew/chartbrew）
• 最新稳定版：v6.0.0（GitHub Releases，2026-11-02 发布，标记 Latest；上一版 v5.3.2 发布于 2026-09-20，查询日期 2026-11-03）
• 技术栈：Node.js 22 后端（官方镜像基于 node:22.23.4-slim）+ React/Vite 前端，元数据存储于 MySQL 或 PostgreSQL，队列与缓存依赖 Redis
• 许可证：FSL-1.1-MIT（Functional Source License v1.1，MIT 未来许可）+ 商业双许可（仓库 LICENSE.md，查询日期 2026-11-03）
• 社区规模：GitHub 星数约 4.1k（shields.io 徽章，2026-11-03）
• 官方交付物：Docker Hub 镜像 razvanilin/chartbrew（latest 即 6.0.0，共 42 个 tag）；注意 chartbrew/chartbrew 仓库在 Docker Hub 不存在（API 返回 404，2026-11-03 实查），选型时勿按 chartbrew/chartbrew 拉取镜像

二、软件概述

Chartbrew 是一款开源的低代码 BI（商业智能）与仪表盘平台：把「连接数据源 → 编写查询 → 拖拽出图 → 组合仪表盘 → 定时分享/告警」这条 BI 主线压缩到浏览器界面里完成，无需编写前端代码，也无需专职 BI 工程师。它与传统重型 BI 的差异化定位在于「开发者友好 + 数据源即插即用」：后端是纯 Node.js 技术栈，数据源以插件形式扩展，仪表盘可以直接架在业务库（MySQL/PostgreSQL 等）和 REST API 之上。

官方对产品的概括是 "Dashboards, reports, alerts & AI insights, simplified"（仪表盘、报表、告警与 AI 洞察的简化方案）。v6.0.0 是该项目的第 6 个大版本（v1 发布于 2020 年，大版本节奏约 1～1.5 年一版，查询日期 2026-11-03），本批次四篇文档均以 v6.0.0 为基准。

💡 技术拓展：「低代码 BI」按使用姿势大致分三类——

类型	代表	特点
自助分析型	Metabase、Superset	面向业务人员，可视化查询构建器 + SQL 编辑器
可观测面板型	Grafana	面向时序/运维数据源，面板即代码、告警内建
开发者嵌入型	Chartbrew、Evidence	面向开发者，强调 API 化、可嵌入、数据源插件扩展

Chartbrew 横跨第一、三类：界面自助程度接近 Metabase，而插件化数据源与 Data API/嵌入能力偏向开发者场景。

三、核心架构

依据官方文档站架构篇与仓库目录结构（2026-11-03 实查），Chartbrew 单实例由前后端两个应用与三类外部依赖构成：

浏览器 ──> 前端（React + Vite 构建产物，静态托管）
              │ REST API / Socket.IO
              ▼
         后端 server（Node.js + Express + Sequelize ORM）
              ├── 元数据库：MySQL 5+ 或 PostgreSQL 12.5+（连接凭证以 CB_ENCRYPTION_KEY 加密存储）
              ├── Redis：BullMQ 任务队列（图表刷新/仪表盘快照/数据集画像等 8 条队列）
              │          + Socket.IO Redis adapter（多进程消息广播）+ 运行时查询缓存
              ├── 数据源插件：server/sources/plugins 下 18 个内置插件
              └── Playwright/Chromium：图表图片渲染（用于邮件快照与图片导出）

要点解读：

1. Express + Sequelize：后端为单体 Node.js 应用，全部元数据（用户、团队、连接、数据集、图表、仪表盘、告警等）落在同一张关系库中，官方迁移脚本自动建表（v6.0.0 实测共 63 张表，见部署篇）。
2. BullMQ + Redis：v6 起 Redis 为硬性依赖（v5 时代可无 Redis 裸跑）。图表定时更新、仪表盘快照、数据集智能画像均为队列任务；队列面板 /apps/queues 内置 Bull Board 可视化。
3. Socket.IO + Redis adapter：查询结果实时推送给打开仪表盘的用户；多进程（cluster）部署时靠 Redis adapter 跨进程广播。
4. 数据源插件体系：按类别组织——数据库类（MySQL、PostgreSQL、RDS MySQL、RDS Postgres、Supabase DB、Timescale、ClickHouse、MongoDB、Firestore、Realtime DB）、API 类（REST API、Strapi）、分析/营销/支付/协作类（Google Analytics、Customer.io、Stripe、Stripe Legacy、Jira、MCP server），共 18 个（server/sources/plugins 目录清单，2026-11-03）。
5. 图片渲染链路：邮件告警与快照功能依赖 Playwright 驱动的 Chromium 把图表渲染成图片，这是官方镜像体积偏大（约 4.4 GB）的直接原因。

四、功能特性

以 v6.0.0 官方 Release 页（2026-11-02）归纳的核心能力：

五、快速开始（最小可用示例）

以下为官方文档 Run on Docker 页给出的最小 Compose 示例（2026-11-03 实查 docs.chartbrew.com，未含本地实测，完整带依赖链的实测部署见 《Chartbrew Docker Compose 部署指南》）：

services:
  db:
    image: mysql:8.4
    environment:
      MYSQL_DATABASE: chartbrew
      MYSQL_USER: chartbrew
      MYSQL_PASSWORD: q1w2e3r4
      MYSQL_ROOT_PASSWORD: q1w2e3r4
    volumes:
      - chartbrew-db:/var/lib/mysql

  redis:
    image: redis:7-alpine

  chartbrew:
    image: razvanilin/chartbrew:6.0.0
    env_file: .env
    ports:
      - 4018:4018   # 前端
      - 4019:4019   # API
    depends_on:
      - db
      - redis

volumes:
  chartbrew-db:

.env 最小集（官方模板关键项）：CB_DB_HOST=db、CB_DB_DIALECT=mysql、CB_REDIS_HOST=redis、VITE_APP_CLIENT_HOST/VITE_APP_API_HOST 指向对外访问地址。启动后访问前端端口，注册首个账号即可进入向导创建第一个连接与图表。

六、适用场景与限制

适合：

• 中小团队把已有业务库（MySQL/PostgreSQL/Mongo 等）快速做成共享仪表盘与周报，不愿引入重型 BI 运维成本；
• 需要「图表即 API」：用 Data API 把查询结果嵌入自有系统或脚本；
• Node.js 技术栈团队，希望数据源插件、告警逻辑可二开；
• 自托管数据分析 + AI 问数（Chart Studio / MCP）尝鲜，单机一台 2C4G 即可跑通全栈。

不适合/需注意：

• 许可证红线：FSL-1.1-MIT 允许自托管、修改、嵌入自有产品，但禁止把 Chartbrew 本身作为托管服务/转售（该场景需商业授权）；每个版本在发布 2 年后自动转为 MIT。对「拿 Chartbrew 卖 SaaS」的团队是一票否决项（LICENSE.md，2026-11-03）。
• 超大规模多维分析、亿级明细交互式透视不是它的强项（对比 Superset 的 Druid/ClickHouse 深度集成）。
• v6 起 Redis 为硬依赖，且官方镜像体积大（含 Chromium），磁盘与内存预算要留够。
• 官方形态为单实例应用（可 cluster 多进程），无内建高可用/多活方案，重资产依赖 MySQL 自身的备份与主从。

七、同类选型对比

量化维度取 2026-11-03 shields.io 星数徽章与各官方仓库 LICENSE/Releases 页实查：

选型建议（「如果…则…」）：

• 如果核心诉求是运维/时序监控大盘，选 Grafana，Chartbrew 的时序生态远不及它；
• 如果是集团级数据仓库多维分析、要求 Apache 协议与庞大社区，选 Superset；
• 如果面向非技术业务人员自助取数且接受 JVM 栈，Metabase 上手更平滑；
• 如果你的数据在业务库与 REST API、团队是 Node.js 栈、想要嵌入式分析与 AI 问数，且不做转售生意，Chartbrew 是四者中部署链路最轻、二次开发最顺的选择；
• 如果预算只允许一个 2C4G 的自托管实例且要「数据库+API 混合数据源 + 邮件周报」，Chartbrew 的默认组合最贴合。

八、参考链接

• 官网与文档：https://chartbrew.com / https://docs.chartbrew.com
• GitHub 仓库：https://github.com/chartbrew/chartbrew（Releases：v6.0.0，2026-11-02）
• LICENSE：https://github.com/chartbrew/chartbrew/blob/master/LICENSE.md（FSL-1.1-MIT）
• Docker Hub：https://hub.docker.com/r/razvanilin/chartbrew（官方镜像，latest=6.0.0）
• 平台内实操：《Chartbrew Docker Compose 部署指南》、《Chartbrew 6.0.0 配置参数详解》、《Chartbrew 6.0.0 常用 CLI 命令与运维实操》