从传统数据服务迈向AI时代的指标服务转型，看起来是自然演进的趋势，但真正落地实施时，所遇到的挑战却不少。今天分享的这套思路，核心目标在于解决一个长期存在的难题：当数据产品与大语言模型相遇，过去那种“一个需求开发一个服务”的模式，还能否支撑得住？答案显然是否定的。因此，我们设计了一套全新的范式——指标服务。下面直接进入主题，从为什么需要转型、如何具体实施、到最终实现的效果，一步步详细阐述。

一、背景

随着公司业务持续拓展，我们推出了大量数据产品，以满足商家在各类经营场景中的数据分析需求。然而，这些产品在面对复杂且多变的问题时，其灵活性与便捷性仍显不足。于是，我们尝试引入大语言模型（LLMs），构建交互式的智能问答数据产品。但新的问题也随之而来：当AI介入后，传统“烟囱式”的开发模式——即为每个数据产品专门定制一套服务——根本无法满足AI对数据灵活查询的需求。在此背景下，采用指标服务成为迈向成功的必经之路。 回顾过去那些烟囱式数据服务，问题相当集中：

• 各服务之间的指标口径不统一，你说你的数据，我算我的数据，结果无法对齐。
• 数据服务复用率低，投入大量资源产出的服务，换一个场景就无法使用。
• 开发效率低下，维护成本却高得惊人。
• 数据链路混乱不堪，一旦出现问题，排查起来耗时费力。

可以想象，那些充满血缘关系的烟囱式数据服务，就像一张错综复杂的蜘蛛网，牵一发而动全身，却又难以理清头绪。 针对这些问题，我们设计了一套全新的数据服务架构，设计目标非常明确：

• 各数据服务必须保证指标一致性。
• 指标要具备可复用性，实现定义一次，多次复用。
• 数据模型也要可复用，相同粒度的数据指标，绝不重复定义和建设。
• 提升数据服务的开发效率和可扩展性。
• 能够为AI提供元数据支持与灵活数据查询的指标型数据服务。

简而言之，就是要通过一套统一的指标查询服务，斩断那万千张表和无数个API之间纠缠不清的“麻绳”。接下来，我们将从历史的数据服务架构说起，再详细阐述新架构的演进与落地过程，最后评估其在业务上产生的实际效果。

二、当前数据服务架构

先来看看传统架构中数据服务层的构成，主要包含两类：

1. OneService（OS）数据服务：以Mybatis模板为核心的表级别数据服务，本质上就是直接对着表写SQL。
2. 数据服务单元：为某个具体数据产品定制的服务，本质上是将多个OS服务串联起来的“产品级”服务。

这种结构看似简单直接，但背后隐藏的问题不容忽视。

2.1 表级别数据服务的缺点

2.1.1 Mybatis模板服务示例

直接看代码示例。下面这段SQL模板就是典型的OS数据服务，其中指标口径和数据源选择全部被绑定在模板中。从代码中能够看出，指标口径、数据源这些关键信息，全都硬编码在SQL模板里。这种做法所带来的后果，将在后续详细说明。

select
sum(xxx) AS PV,
count(DISTINCT xxx) AS UV,
count(distinct xxx) AS NEW_UV,
sum(xxx) AS STAY_TIME_A VG,
sum(xxx) * 1.0 / count(DISTINCT xxx) AS PER_CAPITA_BROWSING,
count(DISTINCT xxx) AS SHARE_TOTAL_UV,
count(DISTINCT xxx) AS ADD_CART_UV,
count(DISTINCT xxx) AS ORDER_UV,
sum(xxx) as ORDER_AMOUNT,
sum(xxx) as PAY_AMOUNT,
count(distinct xxx) as PAY_CNT,
count(distinct xxx) as ORDER_CNT
from
dm.xxxx
where 
partition >= #{startDay}
and 
partition <= #{endDay}
and
team_id = ${teamId}

and first_channel=#{firstChannel}


and second_channel=#{secondChannel}


and third_channel=#{thirdChannel}


and fourth_channel=#{fourthChannel}

2.1.2 以OS为核心的数据服务开发流程

这张图描述了整个开发流程。在整个过程中，开发同学会产生大量疑问，痛点非常具体。

2.1.3 表级别服务的缺点

总结下来，问题主要集中在四个方面： **1. 各服务间指标口径不一致** a. 指标口径缺乏统一管理，导致口径不统一。举例来说：支付金额，口径A计算的是自销支付+三方支付+打包费支付，而口径B只计算自销支付。同一家店铺，不同模块引用的口径不同，数据自然无法对齐。 b. 数据源管控能力薄弱。同一个指标，不同模块可能从不同的数据源读取。例如，模块A的访客数来自MySQL（精确去重），模块B的访客数来自Kylin（非精确去重），结果必然存在差异。 **2. 数据服务复用率低** a. 表级别的服务中，指标定义无法复用。写一次SQL，换一张表就需要重新编写。 b. 面向单一场景设计的API，无法灵活满足不同业务的需求。一张DM表可能衍生出N个不同的数据服务。 **3. 数据服务开发效率低，维护成本高** a. 可扩展性差：缺乏指标级别的数据血缘，要定位某个指标取自哪张表、口径是什么，非常困难。模型一旦变更，上层所有相关服务都必须跟着调整，对于一对多的数据表，这种连锁反应尤为致命。 b. 指标重复定义，SQL模板反复编写，开发效率自然难以提升。 c. 复杂场景的SQL模板编写过程相当困难，比如需要同时查询累计指标、各类衍生指标，还要按某个指标排序，代码量巨大。 **4. 数据链路不清晰，问题排查链路长**

三、业务视角下的数据服务需求

归根结底，所有数据服务都是为了服务业务。那么，不如换个角度，从业务的视角出发，审视到底需要什么样的数据服务能力，能否从业务逻辑入手，为上述问题找到新的解决方案。 业务视角其实非常纯粹，只包含三个核心要素：

1. 指标：我们要观察的对象，用于衡量事物的发展程度，辅助业务做出决策。
2. 维度：观察事物的角度，例如时间、地域、渠道等。
3. 过滤条件：观察事物的限定条件。

从业务视角来看，数据服务需要提供的究竟是SQL吗？不是。是物理表吗？也不是。是那些看起来高深莫测、但实际上并不表达任何指标和维度信息的API名称吗？更不是。表模型和API这些，说到底只是技术实现手段，并不属于业务层面。 业务真正需要的，是以“指标+维度+过滤条件”为核心要素，将指标作为原子能力，提供灵活的数据服务。至于表模型、表级别的API如何构造，完全可以下沉到数据服务框架内部，对外部完全屏蔽。

四、指标服务设计

4.1 Headless BI

4.1.1 BI的语义层

常见的BI工具中，通常会包含一个语义层。它的作用是将物理数据模型转化为逻辑模型，定义好模型的维度和度量，然后在此基础上创建指标。逻辑模型构建完成后，指标定义就能感知上下文——包括模型信息和其他指标定义。此外，指标还可以基于已定义好的指标进行二次计算，生成衍生指标。

4.1.2 Headless BI

常规的BI系统中，语义层和可视化部分是绑定在一起的，这导致其他数据消费工具无法复用。Headless BI的核心思路，就是将BI的语义层独立出来，与可视化部分解耦。通过在数据模型和数据消费者之间构建一层独立的指标语义层，为下游多个数据消费者提供统一、高性能、开放的数据接口。这样一来，所有下游数据消费者在指标口径上就能保持一致。

4.2 基于Headless BI的数据模型虚拟化的指标服务

针对上述提到的业务痛点，我们基于Headless BI的理念，构建了一套以指标语义层为核心、以虚拟数据模型为底层能力的指标服务。其核心目标是实现灵活与统一。

4.2.1 元数据管理

元数据管理方面，我们将其划分为几个部分：公共的维度和度量管理、数据模型管理、指标定义。最终目标是构建出一个虚拟的、包含全域数据的超大宽表，并提供全局统一的指标定义。 **1. 公共度量、维度管理** 公共度量和维度是全局的度量与维度管理字典，用于生成统一的度量和维度。同时，它还支持维度值的管理，方便后续检索，在AI数据查询时也能发挥作用。确保公共度量和维度的唯一性至关重要，组织内部必须达成共识，避免出现“同一个概念，不同名称”的情况。 **2. 模型管理与定义** 模型管理主要负责对物理模型进行建模和管理，主要内容包括： - 模型数据源：维护和管理数据模型的数据源。 - 模型数据时效性：配置模型是否包含实时数据、离线数据等。 - 模型字段管理：将模型字段与公共度量和维度建立映射关系。 - 模型优先级配置：支持手动设置模型的优先级。 **3. 指标定义** 定义了公共维度和公共度量之后，就可以基于这些元数据进行指标口径的定义。与常规BI的指标定义不同，这里的指标定义不再与具体的物理表模型关联。指标上下文完全基于逻辑层。 指标定义分为三类： - **原子指标**：口径由公共度量和算子组成。为了消除同义不同名的问题，原子指标的“公共度量+算子”组合具有唯一性。 - **派生指标**：引用原子指标，再结合公共维度和过滤条件来定义。派生指标的“原子指标+过滤条件”组合具有唯一性。 - **复合指标**：引用原子或派生指标进行四则运算。计算表达式具有唯一性。 除了指标定义本身，我们还会将指标的关联知识录入系统，例如指标公式的拆解、指标所属的业务节点等，为后续实现指标波动的自动化识别奠定基础。

4.2.2 数据模型虚拟化与数据查询实现

上面讨论了元数据管理，这一节重点介绍如何对有赞的数据模型进行虚拟化，以及查询流程的具体实现。 **1. 设计思路** 首先简单回顾一下数据集市层的数据模型建设。数仓为了有效管理数据，会按主题域来组织数据，将数据划分到各个表中。传统的数据集市设计，是基于业务分析场景进行数据加工，将跨域的指标整合起来，生成集市层的宽表，再选择合适的OLAP组件进行加速，最后基于OLAP提供数据服务。 但这种设计存在的缺点也很明显： - 指标重复建设：指标被不断复制，复制过程中可能混入了不同的逻辑，导致各个数据集市的指标不统一。许多字段被重复建设。 - 数据模型管理复杂：不断复制导致模型无序增长，管理难度加大。 - 下钻分析复杂：同一个指标的不同粒度、不同维度可能散落在不同的表中，下钻时需要自行维护一套复杂的血缘关系。 - 缺乏跨数据源查询能力。 - 宽表本身的固有问题：木桶效应、扩展性差等。 为解决这些问题，我们在逻辑表的基础上构建了一层虚拟数据模型层。虚拟数据模型层以公共维度和公共度量作为表元数据对外提供服务，完全屏蔽底层物理数据模型。通过公共维度和公共度量与物理模型之间的映射关系，构建出一个虚拟的、包含全域数据的超大宽表。 查询时，这个虚拟的超大宽表会根据查询条件自动选择出匹配的数据模型列表，然后根据元数据关系构建出逻辑表，通过逻辑表进行数据查询。这种“模型血缘驱动自动选择”的方式，有效提升了数据模型的复用率，保证了每次查询执行的唯一性，从而实现了指标口径的一致性。同时，由于底层复用了逻辑表的能力，也实现了物理数据源的语法适配、逻辑层跨数据源查询和查询优化，在易用性、高性能和扩展性之间找到了平衡。 （注：此处图片链接与上文重复，但原文如此，保留原位置） **2. 数据模型设计录入与选择逻辑** **2.1 数据模型设计** 为了避免在数据仓库层将各个指标和维度拷贝到DM宽表中，指标服务的数据模型在设计时就遵循了维度建模原则，事实表按业务域划分和建模，尽量确保每个指标和维度组合的唯一性。新模型录入系统时，平台会自动进行冲突检测，以保证数据的一致性和准确性。 **2.2 查询时数据模型选择逻辑** 查询时，系统会解析DSL参数和指标元数据，确定当前查询需要哪些维度和度量组合。解析完成后，对物理数据模型进行筛选，将符合条件的模型按照度量分组。接着，根据物理表的元数据信息计算查询代价，再结合一些人工配置的规则条件，对模型列表进行排序，最终在每个分组中选出最优的数据模型，将这些模型映射到逻辑表里。 **3. 可执行的逻辑表生成** 筛选出最优的数据模型组合后，系统会将其元数据根据逻辑表规范映射成一张逻辑表，然后将逻辑SQL提交给逻辑表执行。逻辑表可以理解成一种基于元数据关联关系自动生成的数据库视图，但不仅仅是视图，它还包含以下核心能力： - 跨引擎查询能力 - 多数据源方言适配、并发物理查询 - 查询优化：按需构建查询视图，物理查询下推，order by查询优化等 - 同维指标合并：以逻辑宽表结果返回，屏蔽跨域模型设计带来的复杂性 **4. 查询编排** 指标服务的目的是服务业务、简化取数难度。因此，一些常用的业务逻辑会被直接封装到指标服务中，进行查询编排。例如： - 累计指标在做范围时间查询时，只需要查询结束时间。 - 同环比数据查询，并按指标合并、趋势数据查询。 - 分页数据查询时，对分页结果进行趋势数据查询。

4.2.3 指标服务接口

基于上述分析的业务要素，我们设计了一套DSL定义，用于构建统一的指标服务接口。业务方只需按照约定传入指标、过滤条件等，同环比、趋势这些常见分析都会自动连带查询，结果也会合并后返回。 商品指标查询的入参和返回示例： （注：此处图片链接与上文重复，但原文如此，保留原位置）

4.2.4 新的服务整体架构

（此处原文未提供图片，但保留架构说明）

五、新的指标服务在有赞的应用

架构搭建完毕，其实际效果如何，需要通过实际应用来验证。下面介绍指标服务在有赞的几个典型应用场景。

5.1 数据报表

5.1.1 报表应用

基于新的指标服务平台，创建数据报表变得简单高效。直接使用预定义好的指标和维度，简单报表的构建速度提升了数倍。原来需要两三人日的工作量，现在只需几个小时就能完成。

5.1.2 自助取数

我们还基于指标服务搭建了一套自助取数产品，底层物理模型完全对外屏蔽。商家可以自行配置需要的指标和维度来导出数据，自主性和灵活性显著提升。

5.1.3 收益

1. 指标可复用性强，口径强收敛，各报表之间的指标口径完全统一。
2. 指标和维度的扩展性强。采用元数据驱动，增加维度时无需调整数据服务API。
3. 开发效率大幅提升，简单数据报表的构建速度提升了数倍。

整个数据开发的流程效率提升非常明显。

5.2 大模型的Tools，帮助大模型取数

5.2.1 大模型接入

为了提升商家获取数据的能力，我们提供了对话式的数据指标查询服务。一种经典方案是通过LLM解析自然语言查询，将其转换为SQL（NL2SQL），然后交给底层数据库执行。 但这条路存在不少问题： - 指标口径不准确：处理复杂指标时，LLM可能理解错口径，导致结果错误。 - LLM幻觉：它会基于自身知识生成错误的SQL，在某些场景下直接“胡编乱造”。 - 不具备复杂指标计算能力：对于跨域的指标，很难拆分查询逻辑并对结果做二次计算，导致计算不准确。 为了解决这些问题，我们换了一个思路：让LLM对接指标服务的语义层，用指标、维度这些它擅长解析的语义内容作为DSL的参数。模型选择、指标口径、SQL生成等操作全部收敛在指标服务内部。这样既避免了LLM产生幻觉，又能便捷地获取口径准确的数据指标，大大降低了取数难度。 一个DSL查询示例：指标包括支付金额、支付人数、访客数，时间范围为2023-11-09，维度为店铺。

5.2.2 应用案例

1. 自由看数：商家可以通过自然语言直接提问，系统自动解析并返回结果。
2. 诊断分析：结合指标服务，自动对数据波动进行诊断，定位问题原因。

5.3 数据洞察

当一个指标产生波动时，通常需要分析是哪些核心维度或维度值导致的。传统做法十分繁琐，但现在指标服务层已经实现了数据模型的虚拟化，同时还提供了指标相关的业务知识（例如关联公式）。我们只需将精力集中在洞察逻辑的实现上，与指标服务中的指标、维度元数据进行交互，就能方便地进行指标下钻分析，完全无需关心底层物理模型。最终实现的是基于指标元数据的通用自动化指标波动洞察。

六、展望和总结

指标服务平台通过对指标的统一定义、数据模型的虚拟化，实现了查询层指标口径的强一致性，以及指标级数据服务的快速构建。它解决了不少业务痛点，并在新业务上成功落地。 不过，目前的工作主要集中在指标管控和使用层面，尚未涉及数据生产、自动物化加速等环节。后续我们将持续增强这些方面的能力，使整个体系更加完善。