一、电商指标体系建设背景

首先，在第一个章节中，会介绍电商业务的整体情况，在此基础上探讨为什么电商业务需要一个指标平台，其对电商业务的重要性，并将深入分析电商业务需要一个什么样的指标平台。

电商业务的发展经历了三个阶段：探索期、成长期和稳定期。

在探索期，我们迅速迭代，以业务为导向，主要目标是快速适配业务调整，寻找稳定的业务增长模式。进入成长期，我们开始注重数据生产的效率和质量，努力将数据沉淀成体系，规范化地、高效、高质量地为业务提供支持。这一时期，数据产品丰富多样，针对不同数据域和场景诞生了多种数据产品。目前，我们处于稳定期，核心追求是数据的多元化能力，期望每份数据能服务更多场景，并提供更规范、合理有效的数据方案。

在这三个时期中，如何在数据开发过程中追求更高的质量和效率，始终是我们最关注的课题。

在我们的电商业务中，数据仓库扮演着关键角色，服务于多种内部和外部业务系统。对内，数仓支持运营、分析、产品管理和 DA 等多个角色的需求，这些角色分布在不同的业务线，如供应链、商品、交易等十余个至二十个数据域。每个数据域不仅为下游的指标提供数据，还服务于各种内部数据产品、BI 分析工具、AB 实验和其他数据平台。

对外，数仓的应用更加广泛，服务于买家、卖家、主播审核等多种角色，并支持供应链广告等多个业务系统。这些系统又进一步对接更多数据产品和数据分析方式，例如上图中的电商罗盘。

我们的电商业务数据具有三大特点：一是内外用户的多角色性，内部有多个团队，外部服务数千万商家；二是产品形态的多样性，无论是内部还是外部，都有多种类型的数据产品；三是这些数据产品应用的场景极为丰富。

随着电商业务的不断发展，我们认识到提高数据质量和效率是关键挑战。在这个过程中，我们遇到了三个主要难点：

综上所述，指标管理的不统一、口径的不统一以及指标消费的不统一，构成了我们在电商业务中提高数据质量和效率的三大障碍。因此，我们的指标平台要想真正解决业务问题，就必须针对性地解决这三个问题。

为了解决上述三大问题，指标平台需要满足以下六大要求：

我们的目标是利用指标平台在电商业务中实现生产促进消费，消费再反馈促进生产的闭环能力。这样的良性循环将确保指标平台在电商业务中的价值，使其能够持续、有效地运转。

为了解决上述问题，我们设计了一个功能齐全的指标平台，其架构从基础元素层到指标定义、模型绑定，再到对下游的消费支持。在基础元素层，采用了业界通用的元素，如数据域、时间周期、修饰词等，这些是数据或指标管理方法论中的基础构件。

基于这些元素，构建了指标定义层，使用原子构建和衍生四则运算等标准方法。定义完成后，指标需要与模型绑定，这样就可以获取指标的取数信息。模型绑定后，便能够对接外部的 BI 平台或业务数据平台，进行指标的统一消费。

为了便于业务灵活便捷地消费数据，我们还提供了一种称为 MetricDSL 的统一数据服务接口。这个接口是指标平台与外部系统交互的重要工具，使得数据的获取和使用更加高效和精准。后文中将详细介绍这一功能。

在介绍了我们的业务背景、思考过程和解决方案之后，接下来将详细阐述我们在指标生产和管理方面的方法论。我们认为，指标管理的关键在于三个要素：指标的有效拆解、统一基础数据的建设，以及指标管理角色的明确划分。

指标拆解是指标管理的核心环节，我们基于七个基础元素：数据域、时间周期、修饰词、指标单位、业务过程、度量和数据类型来进行。例如，对于“支付订单金额”这个指标，我们会拆解出它所属的数据域（如交易域）、业务过程（支付动作）、度量（订单数）等信息，从而生成原子指标。进一步结合修饰词和时间周期，可以构建出衍生指标，如“最近一天直播载体支付订单金额”。

我们还有一个特殊的规则，即生成业务指标。这是通过去除衍生指标和复合指标中的时间周期，创建一个更易于业务理解的指标。这样做是为了降低业务对复杂指标的理解成本，并实现业务与数仓、技术侧在指标上的隔离，但实际上它们共享相同的底层指标。

通过这种拆解方法论，解决了两个主要问题：一是减少了指标与维度的重复建设，解决了指标命名不统一的问题；二是确保了所有指标的口径，包括衍生和复合指标，都直观且官方，从而降低了数仓和业务人员对指标的理解成本。

在确立了方法论之后，第二步同样至关重要，即构建统一的数据基础。我们的数仓建设过程经历了从基础期到成长期，再到成熟期的演变，面临着烟囱式开发的问题。特别是在电商这样数据量大且场景复杂的领域，统一的数据基础显得尤为重要。

我们的数仓分为三层：接入层、公共层和应用层。接入层，即 ODS 层，主要负责高效、准确地接入数据。公共层承载着 DIM、DWD 或 DWM 层的表或模型，其目的是抽象和沉淀通用逻辑，确保数仓的规范统一和稳定易用。应用层则直接服务于 BI 看板和具体的数据应用场景，对应于 DM 层或 APP 层，以及数据集。

基于这三层划分，我们实现了电商数据基础的构建。在此基础上，我们将指标平台的指标与不同层级的表或模型进行了绑定。接入层和公共层的表主要用于绑定原子指标，而应用层和公共层中用于实际取数和消费的表，则绑定指标平台维护的衍生指标。这些衍生指标可以通过复合构建生成对应的复合指标。

统一的数据基础建设解决了两个主要问题：一是减少了针对每个消费场景的烟囱式开发，提高了研发和数仓的整体生产效率；二是确保了数仓基建的清晰性和体系化运行。

在我们电商业务的实践中，指标拆解和数据基础建设的落地效果显著。目前，电商指标库涵盖了大约 15 个数据域，每个数据域包含不同的模块。指标库中现有原子指标 700 个，衍生和复合指标的数量则达到了数万个。这些衍生和复合指标进一步被抽象为业务指标，以便于不同角色的理解和使用。

从业务角度来看，业务人员主要关注的是业务指标，因为这些指标直接反映了业务的状态和趋势。而对于数仓或开发人员来说，他们则需要关注衍生和复合指标，因为这些指标是直接用于数据取数和处理的工具。通过这种方式，我们能够满足不同角色对数据的不同需求，同时也确保了数据的一致性和准确性。

在指标的生产和管理中，角色划分与职责明确至关重要。最初接触指标平台项目时，一个常见的问题是：这个指标平台到底属于谁？它仅仅是数仓的指标平台吗？随着电商指标管理体系项目的落地和深入思考，我们逐渐认识到指标平台不应仅限于数仓使用，而应定位为服务于数仓、业务、分析师、数据产品以及各业务线数仓和基础建设数仓的所有人员。

因此，指标平台的管理和服务对象应涵盖从生产到消费整个生命周期的所有角色。我们的平台功能设计旨在服务于从基建侧的数仓到实际业务团队、数据产品分析师等全链路的角色。我们的目标是通过全角色能力的管理，实现从生产到消费的完整循环，从而促进生产和消费的良性互动。

为了使概念更加具体，这里提供一个实际案例。在指标平台内部，有一个功能称为“指标需求登记”，它记录了从数据分析师或数据产品提出指标需求到数仓完成指标交付的全链路生命周期。

例如，分析师提出一个新指标需求以支持内部数据产品。他们需要在指标平台上进行登记，通过平台提供的工具完成需求登记。数仓的开发人员收到登记后，首先要检查该指标是否已存在。如果不存在，开发人员需要进行指标拆解，构建出新的指标，包括原子指标、修饰词等。接着，从基建侧开始，创建模型、表，并进行模型绑定，最终交付给数据产品或分析师。

在整个生命周期中，模型的绑定、指标分类归属、原子指标对应等每个阶段都与指标消费打通。这使得每个指标的消费过程都有迹可循，为未来实现全链路的数据追溯和优化提供了基础。

上面这张截图展示了我们产品功能的一个内部示例，详细记录了从需求登记、指标生产、审核，到消费和业务确认的完整过程。通过这个示例，我们可以清晰地看到数据从提出需求到最终应用的每一步流程。

接下来，将简要介绍我们内部如何实现指标消费与生产之间的无缝对接，即所谓的消费打通能力。

为了实现指标消费与生产之间的统一和一致性，需要建立一个统一的指标服务。在没有统一指标服务之前，我们面临了诸多挑战。数仓团队需要根据业务需求创建不同的 APP 层数据应用表，并维护对应的数据服务 API。每个应用表可能对应多个 API，口径和计算逻辑维护在 API 中，服务于 BI 看板、数据产品仪表盘等下游用数场景。

然而，这种模式存在多个问题：数据准确性难以保证，因为口径维护在不同的 API 中；口径变化时，API 难以迅速适应；复用性指标的开发和维护成本极高；新同学接手和理解成本高，因为复杂的指标口径维护在 API 中。

为了解决这些问题，我们转而构建一个指标服务，通过指标平台提供统一的数据服务出口。这样做不仅提高了效率，降低了开发成本，还降低了理解和学习成本。

通过图片展示，我们可以更直观地看到在统一指标服务建设之前和之后的情况。在建设之前，当有需求时，我们需要开发许多中间层的 ClickHouse 表，并在其上构建数据集和 API。这些 API 通常比较复杂且分散。在建设之后，所有的指标取数和服务资产都维护在指标平台上。指标平台提供 MetricDSL 这样的指标化服务能力，作为一个统一的数据服务接入层，服务于所有下游的数据产品和消费渠道。这种方式实现了整体统一的数据服务建设和接口。这种统一数据服务带来的价值包括：

为了实现统一的指标查询，我们梳理出了三个核心技术。首先是 MetricDSL，一种统一的指标查询语言。MetricDSL 支持多种查询类型，包括 OLAP 查询、明细查询、基于指标函数的查询，以及用户自定义的指标函数查询。其分析要素包括指标维度模型、过滤条件、时间范围，并能支持多指标查询、跨模型查询、跨数据源查询以及基于公共维度的查询。

通过 MetricDSL，我们能够提供给用户和下游消费场景更加灵活和多元化的查询能力。例如，以前我们通过编写 SQL 来查询指标，现在通过 MetricDSL 提供了一个通用化的接口，从而实现了统一查询语言的语义表述。

在实现统一指标查询语言后，我们需要对执行流程进行规范化。用户通过 MetricDSL 构建查询语义后，首先进入元信息处理层，包括校验层、元信息获取层和拆解层。元信息获取层涉及指标信息、模型信息和指标函数信息的获取。拆解层负责将用户传入的复合指标拆分为基础组件元素，并拆分指标引擎，如将指标底表对应于 ClickHouse 或 StarRocks，以及拆分相应的指标函数。

元信息处理完成后，进入物理执行模块，该模块进行 SQL 优化，将 MetricDSL 通过 AST 语法树分析转换为能被引擎执行的物理查询计划。接下来是数据处理阶段，为了兼容跨模型、跨数据源、跨集群的查询能力，我们会对不同模型或数据源的指标进行数据合并和内存计算。

最后，对用户查询的指标函数，如同环比等，在内存中进行计算，完成统一指标查询语言的完整执行流程。

在电商内部场景中，一个指标往往会绑定到多个不同的模型。例如，支付订单数指标可能涉及域外和域内场景，域内场景又可能绑定到不同层级的表，如 DWD、DWS、DM 和 APP 层，每个表支持不同的粒度和主键，以及维度。

为了满足用户的查询需求，我们支持将同一个指标绑定到多个模型上。从整体视角出发，当用户查询支付订单数支持哪些维度时，我们提供的是该指标在所有关联模型中支持的维度，而不是单个模型。这样，用户可以从整个指标和所有模型的视角进行分析，无需关心指标绑定在哪个模型上。

由于一个指标可以绑定到多个模型，智能路由成为必要。智能路由分为筛选和淘汰阶段，以及择优阶段。筛选阶段根据用户选择的指标维度、维度值和可累加性，删除不符合要求的表。择优阶段则根据主题优先、效率优先、同模型优先等规则，选择最适合用户场景的表。

在电商业务中，指标消费的过程涉及多个实际出口。首先，我们内部有一个指标字典或指标专题功能，旨在让业务同学能够基于指标平台快速构建属于自己的指标主题，无需逐个去数仓获取数据。他们可以直接通过构建的这些主题获取到相应的指标数据。

第二个重要的消费出口是基于指标的路由。以往，数仓交付的是表，下游用户只能从这些表中选择构建指标。现在，下游数据的消费从选表转变为选指标，用户无需关心指标属于哪个表。他们看到的是整个电商业务或特定分析主题下的所有指标，可以根据这些指标进行跨模型、跨数据源、跨数据域的整体分析。

这种基于指标的消费方式在 BI 分析看板中体现得尤为明显。下游的 BI 平台可选择的内容增多，用户不再局限于维护基于固定数据集的指标和维度配置。现在，他们可以基于一个分析主题，利用大量指标和维度的集合，快速构建仪表盘和看板。

此外，基于指标的消费方式还带来了一个优势，在以前的基于表或数据集的洞察分析中，我们只能分析某一维度或字段，例如，当我们分析国家占比时，只能看到指标整体上升时，哪些国家增长最为显著。现在，由于我们拥有了指标的血缘信息，比如一个复合指标，我们可以进行更深入的分析。例如，如果指标上升，我们可以分析是分子增加了还是分母减少了，甚至可以查看更详细的情况。基于指标构建的血缘，我们可以进行更深刻的洞察分析。

在完成电商指标体系建设后，我们通过具体数据来验证其成效，是否实现了预期的生产促进消费、消费促进生产的良性循环。我们从四个方面进行评估：指标的覆盖度、电商规范化指标的程度、用户的消费情况以及一致性问题是否得到解决。

为了衡量电商指标体系建设成效，我们设定了几个关键指标。首先，模型的绑定率达到了 83%，意味着电商维护的 1 万多个指标中有 83% 都进行了绑定。其次，我们关注所有电商视角指标的查询是否通过指标元数据或指标去除服务得到覆盖。目前的覆盖度为 70%，这是一个相对较高的数值。

第三个关键指标是公共层的沉淀率，即有多少指标沉淀到了公共层。通过这三个指标值，我们发现指标平台在电商领域解决了烟囱式开发和业务口径对齐的痛点，进一步实现了生产促进消费，一处生产多处消费的最终目标。

此外，我们还将关注点扩展到了外部场景，包括内部 BI 的数据打通、源数据取数，以及消费看板等核心业务场景。

展望未来，我们主要从三个智能化和大模型角度进行规划。首先，我们计划通过分析用户查询日志的热点，自动化生成对应的物化视图，以提升查询性能。其次，我们将实现智能化的建模，通过已维护模型的血缘推断新模型的指标和维度绑定关系，实现语义化的自动建模。我们还将致力于智能化的指标拆解，通过大模型的理解和生产血缘，实现自动化拆解，减轻数仓在指标生产上的负担。此外，我们计划利用大模型将高度规范化和高价值的指标信息进行整合，为未来的大模型理解指标语义提供支持。例如，当用户查询特定指标时，我们希望通过大模型将文本转换为 SQL，以提高查询的准确率。未来，大模型的找数场景将成为我们关注的重点。这些规划将有助于进一步提升电商业务的数据质量和效率。