引言

大家好，时隔两个多月，数睿通2.0数据中台迎来了本次更新，年后这段时间事情比较多，所以造成了更新的迟滞，还望大家理解，平台会一直更新迭代下去，在此感谢大家一直以来的支持与关注。

此外，数睿通智库平台也决定开放源码，目前问答对和文档也已支持批量导入，后续会继续迭代更新，增强平台智能体的稳定性和可用性。

好了，下面我们来看一下本次数睿通2.0更新的数据指标相关功能吧。

数据指标概述

如果说数据中台的前半段，更多是在解决“数据从哪里来、如何治理、如何加工”的问题，那么走到业务使用这一层，就一定会遇到另一个更现实的问题：

这些数据，最终要沉淀成什么样的业务指标？

过去很多项目里，指标建设往往分散在报表、SQL、临时口径文档、业务人员和开发人员的反复沟通中。大家都知道“指标体系很重要”，但真正落地时，又很容易变成一件成本很高、协作链路很长的事情。

这次数睿通 2.0 围绕“数据指标”做了一轮比较完整的补充：新增指标管理、指标模型、宽表生成、刷新调度、执行记录，并接入 AI 创建能力，希望让指标从“口径讨论”更顺畅地走向“可管理、可执行、可复用”的数据资产。

为什么要做指标模块

数据平台里不缺数据，也不缺加工任务，但真正支撑业务分析和经营决策的，往往是一个个稳定的指标。

比如人数、订单数、销售额、转化率、同比增长率、留存率，这些看起来简单的词，背后都包含了明确的数据来源、统计口径、过滤条件、维度映射和计算逻辑。

如果这些内容只存在于 SQL 里，后续就会遇到几个问题：

• 指标口径不容易统一，不同报表可能各算各的；
• 指标变更没有沉淀，后续维护成本高；
• 复合指标依赖关系不清晰，出问题时不好追踪；
• 宽表生成和调度执行需要开发介入，业务响应不够快；
• 新建指标配置项较多，使用门槛偏高。

所以这次更新的核心目标不是简单加一个表单，而是把指标从“临时计算逻辑”升级成平台中的一类标准资产。

指标模块的整体设计

这套指标能力可以分成两层：

第一层是指标定义。它描述一个指标本身如何计算，例如来源表或 View SQL、聚合字段、聚合方式、过滤条件、数据类型、单位、小数位和可用维度。

第二层是指标模型。它负责把多个指标放到同一张分析宽表中，定义宽表维度、指标列表、可选表关联关系，并最终生成宽表和写入结果数据。

这套设计里有一个很重要的原则：

一张指标模型宽表使用一组统一维度粒度。

比如某个指标模型的宽表维度是“性别 + 学历”，那么进入这张宽表的每个基础指标，都会按“性别 + 学历”这个粒度进行聚合，最后生成一张可以直接被 BI、报表或接口消费的指标宽表。

这也意味着，指标模型不是把不同粒度的指标随意拼在一起，而是先把口径和粒度统一下来，再生成稳定的数据结果。

数据指标：沉淀可复用的计算口径

新的指标管理能力，主要用于沉淀指标本身的定义。

基础指标描述的是“从哪里取数、怎么聚合”。例如：

• 从人员表中按 COUNT(1) 统计人数；
• 从订单表中按 SUM(order_amount) 统计销售额；
• 从访问日志中按 COUNT(DISTINCT user_id) 统计去重访问人数。

基础指标支持配置数据来源类型：

• 数据表：直接选择平台中的数据表，字段列表可自动获取；
• View SQL：填写一段查询 SQL，系统通过 SQL 元数据解析返回字段，再作为指标来源使用。

这样设计的好处是，基础指标既可以基于标准物理表创建，也可以基于已经整理好的查询视图创建。对于一些需要先做简单筛选、字段转换或轻量关联的数据场景，View SQL 会更加灵活。

基础指标还可以维护过滤条件和维度信息。过滤条件用于定义指标口径，例如只统计有效订单、只统计在职人员、只统计某个业务状态的数据。维度信息则用于说明这个指标可以按哪些字段拆分统计，例如性别、学历、地区、时间等。

复合指标：让指标之间形成清晰依赖

除了基础指标，这次也补充了复合指标。

复合指标不直接从数据表聚合，而是基于已有指标继续计算。例如：

• 转化率 = 转化人数 / 访问人数；
• 客单价 = 销售额 / 订单数；
• 完成率 = 已完成数量 / 总数量。

这里没有把复合指标做成一段随意输入的文本公式，而是让公式节点引用已有指标。这样做的好处是：指标之间的依赖关系更清晰，后续无论是生成模型、排查结果，还是持续扩展指标体系，都有更明确的基础。

在指标模型执行时，系统会解析复合指标引用了哪些基础指标。如果复合指标依赖的基础指标没有被显式选择，运行时也会自动把依赖指标加入计算过程，先算基础指标，再在基础指标结果上计算复合指标。

指标模型：把指标生成真正可用的宽表

只有指标定义还不够，业务最终需要的是可以查询、可以分析、可以被报表消费的数据结果。

因此这次同步补充了“指标模型”能力。指标模型可以理解为指标结果的组织方式：选择一组指标，配置统一宽表维度、刷新方式、调度方式，最终生成一张面向分析使用的指标宽表。

一个指标模型主要包含三类核心配置：

• 宽表维度定义：决定最终宽表每一行代表什么统计粒度；
• 指标及维度配置：决定哪些指标进入宽表，以及指标自身维度如何映射到宽表维度；
• 表关联关系：当维度字段或指标字段分散在多张表中时，用 join 把它们组织成统一查询来源。

比如我们希望生成一张“性别 + 学历”的人员统计宽表，最终结果可能是：

性别	学历	人数	证件去重人数
男	本科	120	118
男	硕士	36	36
女	本科	98	97

这张表背后的模型配置就是：宽表维度为 sex + edu_level，指标包括人数、证件去重人数，系统按这组维度聚合后写入宽表。

宽表维度：指标模型的统计粒度

宽表维度是指标模型里最关键的配置之一，它决定了最终宽表的主粒度。

例如宽表维度配置为：

英文字段名	显示名称	来源表	来源字段
sex	性别	可空	可空
edu_level	学历	ods_people	edu_level

其中 sourceTable/sourceColumn 是可选的。它们的作用是明确告诉系统：这个宽表维度应该从哪个来源、哪个字段取值。

如果不配置来源，系统会按以下顺序自动解析：

1. 先看指标模型里的维度映射；
2. 再看指标自身定义的维度；
3. 最后尝试使用同名字段兜底。

如果配置了来源，系统会优先使用指定来源字段，并在启用或执行前校验字段是否存在。这样可以避免模型执行到一半才发现字段不对。

这个规则解决了一个很常见的问题：不同指标可能只显式定义了部分维度，但模型宽表需要统一维度。只要来源表里确实存在对应字段，系统就可以自动补齐；如果不存在，就会提前给出明确错误。

表关联：把分散字段整理到统一查询来源

很多业务数据不会天然长在一张表里。

事实数据可能在订单表、人员表、日志表中；维度名称、分类信息、组织信息可能在维表或业务主表中。指标模型里的 join 配置，就是用来把这些分散字段整理到一个统一查询来源中。

例如人员表里只有学历 ID，学历名称在维表中：

[
  {
    "from": "ods_people",
    "to": "dim_edu",
    "fromColumn": "edu_id",
    "toColumn": "id",
    "joinType": "LEFT"
  }
]

系统生成 SQL 时，会形成类似：

ods_people j0
LEFT JOIN dim_edu j1 ON j0.edu_id = j1.id

这时宽表维度可以配置为从 dim_edu.edu_level 取值，指标仍然按统一宽表维度进行聚合。

需要注意的是，join 的作用不是允许每个指标保留不同粒度，而是为统一宽表粒度准备可取数的 joined source。也就是说：

宽表维度 = 模型统一统计粒度
tableJoins = 为统一粒度准备可取数来源
指标 = 在统一粒度上聚合出来的数值列

目前 View SQL 指标也可以参与 join。配置时，系统会使用 v_指标字段名 作为这个 SQL 来源的逻辑名称，例如指标字段名为 people_view_count，则 join 来源可以填写 v_people_view_count。后端会把该指标的 View SQL 包装成子查询参与关联。

SQL 生成逻辑：先聚合，再合并

指标模型最终会生成可执行 SQL。整体逻辑可以概括为：先按宽表维度聚合基础指标，再把多个指标结果合并成宽表结果。

以“性别 + 学历”维度统计人数为例，基础指标会生成类似：

SELECT
  src.sex AS sex,
  src.edu_level AS edu_level,
  COUNT(1) AS people_count
FROM ods_people src
GROUP BY src.sex, src.edu_level

如果配置了表关联，并且学历来自维表，则会生成类似：

SELECT
  j0.sex AS sex,
  j1.edu_level AS edu_level,
  COUNT(1) AS people_count
FROM ods_people j0
LEFT JOIN dim_edu j1 ON j0.edu_id = j1.id
GROUP BY j0.sex, j1.edu_level

当一个模型里有多个基础指标时，系统会按以下方式处理：

1. 每个基础指标先按宽表维度聚合；
2. 同来源、同维度、同过滤条件的指标会合并到一个聚合子查询里，减少重复扫描；
3. 不同来源、不同维度表达式或不同过滤条件的指标，会拆成多组聚合子查询；
4. 系统收集所有指标出现过的维度组合；
5. 再按宽表维度 LEFT JOIN 合并各指标结果；
6. 缺失指标值使用 COALESCE 补为 0。

这样既保证了结果口径稳定，也兼顾了一定的 SQL 执行效率。

更贴近实际业务的刷新方式

在真实的数据场景里，不同模型的刷新诉求并不一样。

有些指标宽表适合直接覆盖，例如每日重新生成一份结果；有些则更适合按照维度字段进行更新，例如同一个业务对象的指标值发生变化时，只更新对应记录；还有一些历史追踪类场景，则可能需要保留变化过程。

这次指标模型支持多种刷新方式：

• 覆盖：先删除宽表数据，再插入本次计算结果；
• 追加：直接插入本次计算结果；
• 更新：按宽表维度作为 key，删除已有 key 后插入新结果；
• 拉链表：按宽表维度维护 start_time/end_time/is_current 技术字段，保留变化过程。

调度方面，模型支持一次性执行和周期性调度。一次性模型启用后可以立即执行；周期性模型会校验 cron 表达式，并发布到调度系统中定期运行。

启用前校验：让错误尽量早出现

指标模型属于数据生产链路的一部分，因此不能只做到“能保存”，更要尽量保证“能执行”。

这次设计中，启用或执行前会做一系列校验，包括：

• 宽表维度不能为空；
• 指标列表不能为空；
• 字段名必须是合法标识符；
• 宽表维度字段不能重复；
• 指标输出字段不能重复；
• join 表名、字段名和 join 类型必须合法；
• 宽表维度显式指定的来源必须能在 join 链路中找到；
• 宽表维度来源字段必须存在；
• 复合指标引用的指标必须存在，且不能循环依赖；
• 已存在宽表时，会校验字段数量、顺序、名称、类型和精度。

这些校验可以把很多问题提前暴露出来，避免模型运行到 SQL 执行阶段才失败。

AI 建指标：降低配置门槛

这次更新里另一个比较值得期待的点，是指标和指标模型支持 AI 创建。

指标配置本身字段不少，尤其当涉及数据来源、统计字段、过滤条件、复合指标公式、模型维度、宽表名称等内容时，直接让用户从空表单开始填，门槛确实不低。

因此我们增加了 AI 创建入口：用户可以用自然语言描述想要的指标，例如“根据人员表统计不同学历的人数，字段名使用 edu_level_count”。系统会把创建指标所需的结构、规则和字段上下文整理成提示信息交给 AI，AI 返回结构化结果后，前端再解析并回显到创建页面。

为了让 AI 更稳定，这次没有把所有表、所有字段、所有指标一次性都塞给模型，而是按场景收集必要上下文：

• 创建基础指标时，用户先选择数据表或 View SQL，系统只把当前来源字段发给 AI；
• 创建复合指标时，用户先选择参与计算的候选指标，AI 只能引用这些指标；
• 创建指标模型时，用户先选择候选指标，AI 基于这些指标生成模型草稿；
• 所有生成结果都必须返回结构化 JSON，再由前端回显给用户确认。

这里的 AI 不是直接越过用户完成所有操作，而是先做“草稿生成”和“配置辅助”：

• 用户负责表达业务需求；
• AI 负责整理成平台可以识别的配置草稿；
• 前端负责回显和校验；
• 最终仍由用户确认后保存。

这样设计会更稳妥，也更符合数据平台的使用习惯。AI 可以提高效率，但关键配置仍然需要可见、可检查、可确认。

字段预览：让 AI 上下文对用户可见

在基础指标 AI 创建中，字段上下文非常关键。

如果用户选择数据表，系统会自动加载表字段；如果用户填写 View SQL，则可以点击“获取字段”解析 SQL 返回列。字段获取成功后，页面会展示字段名、字段注释和字段类型，让用户明确知道 AI 接下来会基于哪些字段生成草稿。

这个小交互很重要。它不是简单地告诉用户“字段获取成功”，而是把 AI 的上下文透明展示出来：用户可以检查字段是否符合预期，再决定是否生成草稿。

执行记录：让模型运行过程更透明

指标模型一旦进入调度或手动执行阶段，用户最关心的就不只是“有没有执行”，还包括：

• 什么时候开始执行；
• 执行是否成功；
• 生成了多少条宽表数据；
• 使用了什么刷新方式；
• 是手动执行还是周期调度；
• 失败时大概是什么原因。

因此我们也补充了指标模型执行记录能力。后续模型运行的过程可以被追踪，问题排查也会更直接。

对于数据平台来说，透明度很重要。配置做得再漂亮，如果执行过程不可见，用户依然会缺少信任感。执行记录就是为了让这条链路更完整。

本次也修复了几个体验问题

除了指标模块相关能力，本次版本还处理了一些使用过程中反馈的问题：

• 修复 API Token 有效期控制不生效的问题，让接口访问控制更加符合配置预期；
• 优化 BI 复制链接地址缺少 IP 和端口的问题，分享和访问体验更完整；
• 优化任务链取消执行偶尔无效的问题，让任务控制更加稳定。

这些问题不算“显眼的大功能”，但它们会直接影响日常使用体验。平台型产品的迭代，很多时候就是在这些细节里一点点变扎实。

写在最后

这次数睿通 2.0 的更新，重点不是把指标模块做成一个孤立功能，而是希望它成为数据中台链路中的一环：

从数据接入、数据开发、数据治理，到指标沉淀、模型生成、调度执行，再到 BI 分析和业务应用，平台需要把这些环节逐步连起来。

这套指标能力的定位也比较明确：它不是一个“任意指标、任意维度、任意条件实时查询”的万能指标平台，而是一套更偏生产侧的指标宽表生成能力。它帮助用户把稳定口径沉淀下来，按统一维度生成结果，再供后续报表、BI 和业务应用使用。

AI 创建指标也是一个开始。我们不会把它包装成“万能替代人工”的能力，而是希望它先在合适的位置发挥价值：降低配置门槛、辅助理解需求、生成结构化草稿、减少重复操作。

后续数睿通 2.0 还会持续更新迭代，逐步与 AI 能力结合，围绕数据开发、数据治理、指标体系、智能分析等方向继续完善，努力打造一个更实用、更稳、更贴近业务的数据智能中台。

感兴趣的朋友请关注公众号 螺旋编程极客 获取更多信息，我们一起成长，一起进步。