企业官网建设流程全解析

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 # 结果：Metabase=117, Superset=153, 自研=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 二次开发。核心原因：

1. 中国地图硬需求排除了 Metabase
2. 开发资源有限排除了纯自研
3. Superset 的 RLS 权限满足了大部分需求，不足的部分通过二次开发补齐

落地路径分三个阶段：

阶段1：Superset 基础部署与配置（1周）

# Superset 定制部署配置 superset_config = { # 数据源配置：连接我们的 ClickHouse 和 PostgreSQL 'SQLALCHEMY_DATABASE_URI': 'clickhouse://user:pass@host: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 的拖拽查询功能。

四、踩坑记录与反思

坑1：Superset 大版本升级的 breaking change

我们部署的是 Superset 2.0，后来尝试升级到 3.0 时发现：权限模型 API 变了、看板导出格式变了、自定义插件接口变了。二次开发的代码全部需要适配。教训是：选型时要确认版本的升级节奏和兼容性承诺。Apache 项目的大版本升级 breaking change 是常态，不是例外。

坑2：二次开发的维护成本

我们给 Superset 做了 4 个自定义模块。每次 Superset 升级，这 4 个模块都要重新适配。算下来维护成本比预估高了 50%。如果当初选择纯自研，至少不用跟着别人的版本节奏走。

坑3：非技术人员的上手难度

Superset 的拖拽查询比 Metabase 复杂——这是上线后最直接的反馈。运营团队平均需要 2 次培训才能独立创建看板，而 Metabase 只需要 1 次。如果自助查询是核心需求，Metabase 的体验确实更好。

反思：选型决策的核心权衡

我们选了"中间路线"，但中间路线的代价是"两头都不极致"。比 Metabase 慢、比自研受限。如果重来一次，我会更认真地评估：到底哪些需求是"硬需求"（没有就不上线），哪些是"软需求"（可以后续迭代）。硬需求决定选型底线，软需求决定选型方向。

五、总结

BI 平台选型看似是技术决策，实际上是成本与需求的博弈。我们的最终选择——基于 Superset 二次开发——是在"中国地图硬需求"和"开发资源有限"两个约束下的最优解，但不是完美解。

回头看，最重要的经验是三点：

1. 选型前先量化需求优先级：我们最初把"自助查询"和"中国地图"放在同一优先级，但实际上中国地图是没它就不上线的硬需求，自助查询是上线后可以慢慢优化的软需求。区分硬软需求能让选型决策更清晰。

2. 二次开发的长期成本容易被低估：短期开发成本可以估算，但每次上游升级的适配成本是持续性的。评估时要把"未来3年的维护成本"纳入决策模型。

3. 技术选型不是一次性决策：我们现在是 Superset 二次开发，不代表未来不会迁移到自研。当业务规模从 200 看板增长到 1000 看板时，自研的性能上限优势会越来越明显。选型决策应该有演进路线图，而不是一步到位。