没买阿里OneData,自己怎么搭一套指标平台MVP?
本文目录
先说结论
指标平台的核心是5大模块:①指标字典(元数据)②SQL生成器(DSL→SQL)③血缘服务(影响分析)④调度+物化(指标→数据)⑤BI对接(API+SDK)。MVP阶段先做①②⑤,③④后期补。
MVP阶段3-6人月可上线:MySQL存元数据 + 简单前端CRUD + Python SQL Generator + 接BI(Tableau/Superset)的JDBC。不要追求大而全,先解决「指标定义有处可放」「SQL自动生成」这两件事。
自研 vs 买商业产品的选择标准:指标数量<500、业务线<5、团队<5人 → 自研MVP够用;指标>2000、跨多业务线、合规要求高 → 买阿里DataWorks/网易EasyData。中间状态最纠结,看团队预算。
先把这段讲顺;面试官追问时,再展开下面的原理和细节。
详细讲解
"我们公司没买阿里OneData/网易EasyData/字节DataFinder,能不能自己做一套?"——这是中小公司技术Leader面试时最爱问的题。这道题考的不是工具,而是你对指标平台核心能力的拆解。我在某元宇宙社交App从0搭过指标平台MVP,3个月上线、覆盖80%核心场景、团队投入1.5个研发——下面把这套方案拆给你看。能给出MVP+演进路线,就是Tech Lead的答题能力。
业务场景:元宇宙社交App的MVP搭建过程
我接手元宇宙社交App的数据平台时,公司ARR才千万级别,没钱买商业产品。但散在各处的指标已经3000+,急需治理。我用2周时间出了一份《指标平台MVP方案》,得到CEO批准后3个月上线了V1。
整体技术栈:MySQL(元数据)+ Spring Boot(API)+ Vue(前端)+ Python(SQL Generator)+ Airflow(调度)。总计1.5个研发投入(我兼半个,加一个全职后端、一个前端外包),3个月跑通核心闭环。
模块一:指标字典 - 元数据存储
最小可用元数据模型,3张表搞定:
-- 1. 主表:指标基本信息
CREATE TABLE metric (
metric_id VARCHAR(64) PRIMARY KEY,
metric_name_cn VARCHAR(128) NOT NULL,
metric_name_en VARCHAR(128) NOT NULL,
metric_type ENUM('atomic','derived','composite'),
business_domain VARCHAR(64),
formula TEXT,
source_table VARCHAR(128),
filter_logic TEXT,
owner_data VARCHAR(64),
owner_business VARCHAR(64),
status ENUM('draft','published','deprecated'),
version INT,
create_time DATETIME,
update_time DATETIME
);
-- 2. 维度表
CREATE TABLE dimension (
dim_id VARCHAR(64) PRIMARY KEY,
dim_name_cn VARCHAR(128),
dim_name_en VARCHAR(128),
source_table VARCHAR(128),
source_field VARCHAR(64)
);
-- 3. 指标-维度关联表(多对多)
CREATE TABLE metric_dim_rel (
metric_id VARCHAR(64),
dim_id VARCHAR(64),
is_default BOOLEAN, -- 是否默认切片
PRIMARY KEY (metric_id, dim_id)
);
3张表已经够覆盖80%场景。版本管理用version字段+update_time双字段(同metric_id多版本)。
模块二:SQL生成器 - 核心引擎
SQL Generator接收"指标ID + 维度列表 + 时间范围 + 过滤条件",输出可执行SQL。Python实现伪代码:
def generate_sql(metric_id, dimensions, time_range, filters=None):
# 1. 从字典读元数据
metric = metric_dao.get(metric_id)
dim_metas = [dim_dao.get(d) for d in dimensions]
# 2. 构建SELECT
select_clauses = [f'{d.source_field} AS {d.dim_name_en}' for d in dim_metas]
select_clauses.append(f'{metric.formula} AS {metric.metric_name_en}')
# 3. 构建FROM(智能选择物化层)
table = choose_best_table(metric, dim_metas, time_range)
# 优先选预聚合表,再选DWS主表,最后才是DWD
# 4. 构建WHERE
where = [
f"dt BETWEEN '{time_range.start}' AND '{time_range.end}'",
metric.filter_logic, # 字典里的过滤
]
if filters:
where.extend([build_filter(f) for f in filters]) # 用户自定义
# 5. 构建GROUP BY
group_by = [d.source_field for d in dim_metas]
sql = f"""
SELECT {', '.join(select_clauses)}
FROM {table}
WHERE {' AND '.join(where)}
GROUP BY {', '.join(group_by)}
"""
return sql
这套Generator的灵魂是choose_best_table——根据维度自动路由到最优表(参考第10题的查询分层)。这是指标平台"自动化"的关键。
模块三:BI对接(最容易被忽略但最关键)
指标平台搭好了不接BI = 没人用。MVP的接入方式:
| BI工具 | 对接方式 | 用户体验 | 实施难度 |
|---|---|---|---|
| Tableau | JDBC自定义视图,基于Generator | 拖拽即可 | 中 |
| Superset/Metabase | 封装SQLLab,预装常用指标 | 需写少量SQL | 低 |
| 自研报表 | 直接调Generator API | 完美 | 中 |
| Excel/Google Sheet | 提供API,用插件接入 | 差 | 低 |
元宇宙社交App选了Superset+自研报表的组合:Superset给数据分析师用(写SQL),自研报表给业务方用(拖拽)。两条线并行,覆盖了所有用户群。
模块四:MVP上线后的演进路径
V1上线后,按业务反馈和痛点逐步演进:
V1(M1-M3): 字典+Generator+BI接入 ✅ 解决「指标无处放」
V2(M4-M6): 加指标审批流+变更评审 ✅ 解决「口径冲突」
V3(M7-M9): 加血缘服务+影响分析 ✅ 解决「改一个炸一片」
V4(M10-M12): 加预聚合自动调度+物化视图管理 ✅ 解决「查询慢」
V5(次年Q1-Q2): 加自助探索+维度推荐 ✅ 解决「不会用」
V6(次年Q3+): 接入数据质量+SLA监控 ✅ 解决「数据不准」
元宇宙社交App做到V4的时候被收购了,整套系统继续在新东家用。1.5个研发投入12个月做出能匹敌商业产品80%能力的平台,ROI很高。
方法五:关键避坑提醒
MVP最容易翻车的5个坑:
坑1:一开始就做大而全。我见过团队第一版要做25个模块的,6个月没上线被砍。MVP的本质是先解决最痛的一个问题。
坑2:自己造UI而不复用开源。前端CRUD不要从0写,用低代码(如AmisJS、Form Render)配出来,能省2人月。
坑3:Generator逻辑全用if/else拼SQL。一定要用模板引擎(Jinja2/Handlebars),否则后期加场景代码爆炸。
坑4:和BI工具脱节。做完平台业务方还在BI里直接写SQL绕过——必须BI侧做硬约束(参考第3题的发布拦截)。
坑5:没Owner机制。元数据也是数据,没人维护就成垃圾场。每个指标必须有Owner、有过期机制(6个月不更新自动deprecated)。
面试高频追问
追问一:自研指标平台和买商业产品的核心差异?
商业产品(DataWorks、EasyData)的核心优势是「集成度+企业级能力」:开箱即用、和数仓+OLAP+调度无缝对接、有完善的权限/审计/合规。自研的优势是「灵活性+成本」:贴合业务定制、迭代快、不用按指标数收费。中型公司(500-2000指标)一般自研,超大公司或合规要求高(金融、医疗)一般买商业。我在元宇宙社交App选自研,在出海硬件品牌选了商业(阿里DataWorks),都是基于体量和合规需求。
追问二:MVP上线后业务不用怎么办?
三步走:①先抓CEO/CDO当用户——他们用了,下面就跟 ②选3-5个高频报表迁过来(用旧BI流量做对比,跑通后下线旧报表)③做"明星案例"——找一个用了平台后效率提升明显的业务方写case分享。元宇宙社交App我们用CEO周报当突破口,CEO开始问"为什么不用平台"之后用户增长就自然了。这是冷启动的政治学。
追问三:指标平台怎么保证生成的SQL高效?
3层保障:①查询路由到预聚合表(参考第10题)②生成的SQL走OLAP的最佳实践(如分区过滤、避免SELECT *、避免SkewJoin)③异常SQL拦截——超过30秒/扫描>1亿行的SQL自动取消,提示用户改维度。元宇宙社交App跑了一年,平均查询耗时2.3秒,超时率0.5%以内。这是平台和OLAP协同优化的成果。
实战踩坑:第一版Generator用纯字符串拼SQL,重构两次
V1的SQL Generator我图省事,用Python字符串f-string直接拼SQL。结果第3个月加「多表JOIN」时代码爆炸——10多种JOIN场景嵌套if/else,谁也读不懂、改不动。后来重构用Jinja2模板,再后来用SQLGlot做AST级别构建。
教训:SQL Generator必须用专业工具,不能字符串拼。Jinja2适合简单场景,SQLGlot/SQLFluff适合复杂场景(能做语义分析、优化、跨方言转换)。元宇宙社交App最终用SQLGlot,扩展性好得多。这是"早期偷懒后期还债"的经典教训。
总结
回答这道题的高分结构:先拆解能力(5大模块)→ 给MVP方案(3表+Generator+BI)→ 给演进路径(V1-V6)→ 给避坑(5个坑)。强调"MVP不是缩水版完整产品,是聚焦一个核心痛点的最小可用版"。能讲出团队投入(1.5人)、上线时间(3个月)、覆盖业务(80%)这些数字就是Tech Lead级别答题。
下一篇深入聊技术细节:指标怎么自动生成SQL?——指标平台的DSL设计要点
你们公司有指标平台吗?自研还是买的?评论区聊聊~
关注「Wood聊大数据」| 9年大数据老兵,聊技术、聊职场、聊成长