数据产品工程化

我的理解

数据产品工程化关注的不是“做一张图”，而是图背后的口径、权限、查询性能、联动协议、异常兜底、调度稳定性和用户能否理解结果。

很多人把“数据产品”等同于“数据看板”，做完一张图就以为交付了。但真正做过长期维护的人都知道，看板只是冰山一角。水面下是指标口径、权限模型、查询引擎、前端协议、调度系统、异常兜底和发布验证。这些做不好，看板上线两周就会变成“图不准、数不对、没人信”。

从看板到产品的六个跨越

把一次性看板变成长期可维护产品，需要跨越六个工程化门槛。每跨过一个，维护成本就降一档，用户信任就涨一截。

• 口径工程化：指标从 Excel 注释变成结构化定义，绑定唯一 ID
• 服务工程化：图表从直连数据库变成走服务层，统一权限和缓存
• 协议工程化：前后端从耦合渲染变成协议驱动，组件白名单可控
• 权限工程化：从硬编码过滤变成组织树驱动的行级权限
• 调度工程化：从手动刷新变成任务编排，失败可重试可告警
• 发布工程化：从改完就上线变成灰度验证加回滚预案

为什么 AI 时代更需要工程化

AI 问数让数据消费门槛大幅降低，但也让工程化欠债暴露得更快。没有口径定义，AI 会瞎猜；没有权限模型，AI 会越权；没有服务层，AI 会直连数据库写低效 SQL。所以 AI 不是替代工程化，而是倒逼工程化做得更扎实。

1. 先把指标口径从 Excel 注释抽成结构化定义，每个指标绑定唯一 targetId。
2. 再建服务层隔离前端和数据库，图表不再直连而是走统一查询接口。
3. 然后定前后端协议，图表组件按 schema 渲染，新增图表类型不用改前端代码。
4. 接着把权限从硬编码过滤改成组织树驱动的行级权限，新增角色不用改 SQL。
5. 再把调度从手动刷新改成任务编排系统，失败自动重试并告警。
6. 最后建立灰度发布和回滚预案，改口径先灰度 10% 用户验证再全量。

type MetricDefinition = {
  targetId: string;           // 唯一标识
  name: string;               // 业务名称
  formula: {                  // 精确公式
    numerator: string;
    denominator: string;
  };
  scope: {                    // 统计范围
    orgLevel: 'project' | 'region' | 'group';
    timeBoundary: 'billing' | 'calendar' | 'rolling';
  };
  exceptions: {               // 异常处理规则
    nullValue: 'skip' | 'zero' | 'error';
    negativeValue: 'abs' | 'skip' | 'error';
  };
};