BI 平台技术选型复盘：Metabase vs Superset vs 自研的决策

BI 平台技术选型复盘Metabase vs Superset vs 自研的决策一、背景与痛点去年团队面临一个关键决策我们的数据分析平台到底用什么 BI 工具当时的情况是——分析师用 Excel 手工做报表产品经理用 Google Sheets 跟数据运营团队自己写 SQL 从数据库里拉数字。整个公司没有一个统一的看数入口。管理层给了我们一个需求清单10 个业务部门预计 200 看板需要权限隔离每个部门只看自己的数据需要自助查询非技术人员也能拖拽分析需要中国地图可视化区域分析是核心需求预算有限优先开源方案我们评估了三个方向Metabase轻量开源、Apache Superset重量开源、自研基于 React ECharts。这篇复盘记录了我们如何一步步做选型决策以及最终选择背后的逻辑。二、三方案深度对比我们花了两周时间做详细的技术评估从功能、性能、运维、开发成本四个维度逐一对比。维度1功能覆盖度# 三个方案的功能覆盖度量化评估 feature_matrix { 功能维度: [ 基础图表类型, 高级图表类型, 地图可视化, 自助拖拽查询, SQL查询编辑器, 权限管理, 数据源连接器, 告警通知, 看板分享, 嵌入式集成, 定制化能力, 移动端适配 ], Metabase: [ 4, 2, 1, 5, 3, 3, 4, 2, 4, 3, 1, 3 ], Superset: [ 5, 4, 3, 3, 5, 4, 5, 3, 4, 2, 3, 2 ], 自研: [ 3, 5, 5, 3, 4, 5, 3, 5, 5, 5, 5, 4 ] } # 评分规则1-5分5完全满足1基本不支持 # 计算总分 total_scores {} for solution in [Metabase, Superset, 自研]: scores feature_matrix[solution] # 权重地图5x、权限5x、自助查询4x、其余3x反映我们的核心需求 weights [3, 3, 5, 4, 3, 5, 3, 3, 3, 3, 3, 3] weighted_total sum(s * w for s, w in zip(scores, weights)) total_scores[solution] weighted_total # 结果Metabase117, Superset153, 自研154 # 自研和Superset在加权总分上几乎持平关键功能差异分析中国地图Metabase 原生不支持中国省级地图这是致命短板。Superset 支持但需要手动配置 GeoJSON自研用 ECharts 可以直接用中国地图组件。权限管理Metabase 的权限模型简单但不够精细——只有可以看/不能看的粒度。Superset 支持行列级权限RLS自研可以做到字段级。自助查询Metabase 的问答式查询体验最好非技术人员上手最快。Superset 的拖拽稍微复杂自研需要专门开发查询UI。维度2性能与运维# 性能与运维成本对比 perf_ops_comparison { 指标: [ 看板加载速度(首个), 看板加载速度(复杂), 并发用户承载, 部署难度, 运维人力, 升级兼容性, 社区活跃度 ], Metabase: [ 2-3秒, 5-8秒, 100-200, 极简(Docker一键), 0.5人, 高(API稳定), 中等(7k stars) ], Superset: [ 3-5秒, 8-15秒, 200-500, 中等(需Python环境), 1人, 中(大版本有breaking change), 高(60k stars) ], 自研: [ 1-2秒, 3-5秒, 500, 复杂(前后端数据库), 2人, 完全可控, 无(自己维护) ] } # 关键发现 # 1. Metabase部署最简单但复杂看板性能不佳 # 2. Superset大版本升级经常有breaking change我们测试时从1.3升到2.0就踩了坑 # 3. 自研性能上限最高但开发和运维成本也最高维度3开发与集成成本# 开发成本估算人月 development_cost { Metabase: { 基础部署: 0.5, # Docker拉起来就完事 权限定制: 2, # Metabase权限粒度不够需要hack 地图插件开发: 3, # 中国地图需要完全自开发 数据源接入: 1, # 原生支持主流数据源 看板搭建: 1, # 非技术人员可以自助搭建 总计: 7.5 }, Superset: { 基础部署: 1.5, # Python环境依赖管理 权限配置: 1, # RLS原生支持配置即可 地图配置: 1.5, # 需配置GeoJSON但框架支持 数据源接入: 0.5, # 支持几乎所有数据源 看板搭建: 2, # 学习曲线比Metabase陡 总计: 6.5 }, 自研: { 基础框架搭建: 3, # React前端API后端数据库设计 权限系统开发: 2, # 从零开发字段级权限 图表引擎开发: 3, # ECharts封装拖拽交互 查询编辑器开发: 2, # SQL编辑器自然语言查询 数据源适配: 1.5, # 需自开发各数据源连接器 看板搭建: 2, # 需前端开发每个看板 总计: 11.5 } }三、最终决策与落地路径经过两周评估我们选了方案G基于 Superset 二次开发。核心原因中国地图硬需求排除了 Metabase开发资源有限排除了纯自研Superset 的 RLS 权限满足了大部分需求不足的部分通过二次开发补齐落地路径分三个阶段阶段1Superset 基础部署与配置1周# Superset 定制部署配置 superset_config { # 数据源配置连接我们的 ClickHouse 和 PostgreSQL SQLALCHEMY_DATABASE_URI: clickhouse://user:passhost:8123/default, # 缓存配置看板查询结果缓存减少重复查询压力 CACHE_CONFIG: { CACHE_TYPE: redis, CACHE_DEFAULT_TIMEOUT: 300, # 缓存5分钟 CACHE_KEY_PREFIX: superset_, }, # 权限配置启用行列级安全策略 ENABLE_ROW_LEVEL_SECURITY: True, # 性能配置限制查询返回行数防止慢查询拖垮系统 SUPERSET_WEBSERVER_MAX_ROW_LIMIT: 100000, SUPERSET_WEBSERVER_TIMEOUT: 60, # 查询超时60秒 # 功能开关关闭不需要的功能减少复杂度 ENABLE_JAVASCRIPT_CONTROLS: False, # 禁止自定义JS安全考虑 DASHBOARD_AUTO_REFRESH_MODE: fetch, # 自动刷新模式 } # 中国地图 GeoJSON 配置加载省级和市级地图数据 china_geojson_config { province_geojson: /data/china_province.json, city_geojson: /data/china_city.json, map_style: { fill_color: #4dabf7, stroke_color: #ffffff, highlight_color: #51cf66, } }阶段2二次开发补齐短板3周# Superset 二次开发的核心模块 # 模块1字段级权限扩展 class FieldLevelSecurity: 扩展Superset的权限模型支持字段级数据脱敏和隐藏 def __init__(self, superset_app): self.app superset_app def apply_field_masking(self, user_role: str, dataset_id: int) - dict: 根据用户角色对不同字段应用脱敏规则 # 定义各角色的字段可见性配置 field_permissions { finance_view: { visible: [revenue, cost, profit_margin], masked: {phone: 脱敏, email: 脱敏}, hidden: [user_raw_id, internal_cost_detail] }, operation_view: { visible: [order_count, conversion_rate, avg_price], masked: {phone: 脱敏, address: 脱敏}, hidden: [profit_margin, cost_detail] }, admin: { visible: all, masked: {}, hidden: [] } } # 获取当前角色的权限配置 perm field_permissions.get(user_role, field_permissions[operation_view]) if perm[visible] all: return {action: show_all, masked_fields: perm[masked]} return { action: filter_fields, visible_fields: perm[visible], masked_fields: perm[masked], hidden_fields: perm[hidden] } # 模块2自定义中国地图可视化组件 class ChinaMapVisualization: 基于 ECharts 的中国地图可视化替代 Superset 原生的 deck.gl 地图 def render_province_map(self, data: list, metric: str) - dict: 渲染省级热力地图 echarts_option { title: {text: f{metric} - 各省分布}, visualMap: { min: min(d[value] for d in data), max: max(d[value] for d in data), left: left, top: bottom, text: [高, 低], inRange: {color: [#e3f2fd, #4dabf7, #1a73e8]} }, series: [{ type: map, map: china, data: data, # [{name: 广东, value: 1234}, ...] roam: True, # 支持缩放和拖拽 label: {show: True}, emphasis: { label: {show: True}, itemStyle: {areaColor: #51cf66} } }] } return echarts_option阶段3培训推广与看板迁移2周把现有的 Excel 报表和 Google Sheets 逐步迁移到 Superset 看板。培训的重点是让非技术人员学会用 Superset 的拖拽查询功能。四、踩坑记录与反思坑1Superset 大版本升级的 breaking change我们部署的是 Superset 2.0后来尝试升级到 3.0 时发现权限模型 API 变了、看板导出格式变了、自定义插件接口变了。二次开发的代码全部需要适配。教训是选型时要确认版本的升级节奏和兼容性承诺。Apache 项目的大版本升级 breaking change 是常态不是例外。坑2二次开发的维护成本我们给 Superset 做了 4 个自定义模块。每次 Superset 升级这 4 个模块都要重新适配。算下来维护成本比预估高了 50%。如果当初选择纯自研至少不用跟着别人的版本节奏走。坑3非技术人员的上手难度Superset 的拖拽查询比 Metabase 复杂——这是上线后最直接的反馈。运营团队平均需要 2 次培训才能独立创建看板而 Metabase 只需要 1 次。如果自助查询是核心需求Metabase 的体验确实更好。反思选型决策的核心权衡决策因素MetabaseSuperset二次开发自研快速上线最快中最慢功能上限低中高最高维护成本低中(跟着上游升级)高(全部自己维护)定制灵活性低中最高中国地图不支持需二次开发原生支持我们选了中间路线但中间路线的代价是两头都不极致。比 Metabase 慢、比自研受限。如果重来一次我会更认真地评估到底哪些需求是硬需求没有就不上线哪些是软需求可以后续迭代。硬需求决定选型底线软需求决定选型方向。五、总结BI 平台选型看似是技术决策实际上是成本与需求的博弈。我们的最终选择——基于 Superset 二次开发——是在中国地图硬需求和开发资源有限两个约束下的最优解但不是完美解。回头看最重要的经验是三点选型前先量化需求优先级我们最初把自助查询和中国地图放在同一优先级但实际上中国地图是没它就不上线的硬需求自助查询是上线后可以慢慢优化的软需求。区分硬软需求能让选型决策更清晰。二次开发的长期成本容易被低估短期开发成本可以估算但每次上游升级的适配成本是持续性的。评估时要把未来3年的维护成本纳入决策模型。技术选型不是一次性决策我们现在是 Superset 二次开发不代表未来不会迁移到自研。当业务规模从 200 看板增长到 1000 看板时自研的性能上限优势会越来越明显。选型决策应该有演进路线图而不是一步到位。