订阅更新

没买阿里OneData,自己怎么搭一套指标平台MVP?

指标管理手册 第 11 题 约 10 分钟读完

本文目录
  1. 先说结论
  2. 业务场景:元宇宙社交App的MVP搭建过程
  3. 模块一:指标字典 - 元数据存储
  4. 模块二:SQL生成器 - 核心引擎
  5. 模块三:BI对接(最容易被忽略但最关键)
  6. 模块四:MVP上线后的演进路径
  7. 方法五:关键避坑提醒
  8. 面试高频追问
  9. 实战踩坑:第一版Generator用纯字符串拼SQL,重构两次
  10. 总结

先说结论

指标平台的核心是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工具对接方式用户体验实施难度
TableauJDBC自定义视图,基于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年大数据老兵,聊技术、聊职场、聊成长

刷题进度保存在当前浏览器