1 度量平台是做什么的

　　度量平台的核心在于系统化地收集研发过程中的关键数据，并以直观的方式展示，帮助使用者更好地理解和分析团队的交付价值、效率和质量。平台不仅提供了可信赖的观测体系，还致力于发现团队潜在问题，并为业务改进提供依据和支持。

　　虽然关于度量指标构建和指标设计原则的文章已有很多，但针对度量平台系统落地的实践经验却不多见。本文将分享转转在度量平台技术建设方面的实际做法和积累的经验。

　　2 度量平台的技术建设历程

　　2.1 度量平台V0.1 2019~2022

　　19年开始建设,收集需求、bug、项目延期，上线等数据产出指标辅助使用者分析研发效率，度量平台V0.1架构图如图2.1-1　　

图2.1-1 度量平台V0.1架构图

　　在此阶段，平台进行了简单的投入和维护，但并未持续进行更新和优化。

　　2.2 度量平台V0.5 2022~2023

　　随着公司发展到一定阶段，对度量平台的需求日益增强，识别并优化研发效能瓶颈成为重要目标。尽管原有度量平台仍能正常运作，但随着业务的不断扩展，现有系统的局限性逐渐显现，例如：

　　查询指标数据耗时较长

　　指标准确性较低，排查困难

　　生产指标慢

　　基于以上背景，我们在2022年决定重构度量平台，以适应公司战略需求和提升整体效率。

　　2.2.1 重构思路

　　数据模型与业务逻辑分离

　　原系统中，数据模型与业务逻辑紧密耦合，导致每次业务变动都需要大量代码调整。此外，原系统没有充分存储详细的业务明细数据，导致在指标计算出现偏差时，很难追溯并排查问题的根源。重构时，我们不仅将数据模型与业务逻辑解耦，还确保每个数据明细都有完整的记录，使得数据的组织与管理更加独立灵活，能够适应不同场景下的需求变化，并提供更好的问题追溯能力。

　　重新设计数据模型： 按照星型和雪花型模式，系统中的数据表结构被重新划分为四类表：

　　明细表：存储最原始、最细粒度的数据，如单个需求、工时、bug 等。这些表记录了详细的事务数据，保持高精度和完整性。

　　维度表：用于存放与业务实体相关的属性信息，如项目、人员、模块等，帮助为明细数据添加上下文。

　　桥接表：处理多对多的复杂关联关系。例如需求与多个人员或项目的关联关系，可以通过桥接表来拆解，简化查询和数据整合。

　　汇总表：通过定时任务聚合明细数据，生成多层次的统计指标，便于快速查询和展示，减少了实时计算的压力。　　

图2.2.1-1 度量平台处理数据流程

　　如图2.2.1-1 所示，基础明细数据在写入后，代码被用作“胶水”来处理这些库表的连接与逻辑处理。

　　重构后的度量平台V0.5架构图如下，和V0.1相比增加了数据依赖管理和指标预计算，但是生产指标方式并无变化。

　　下图2.2.1-2是度量平台V0.5架构图　　

图2.2.1-2 度量平台V0.5架构图

　　2.2.2 基础数据治理

　　在数据模型与业务逻辑分离的基础上，我们在生成指标时发现原始数据无法直接使用。由于这次度量涉及众多全新指标，绝大多数基础数据均为首次应用，必须进行数据清洗和处理。为实现这一目标，我们投入了大量精力。以下将以项目流程数据为例，介绍具体的数据治理工作。

　　项目流程数据治理

　　转转采用TAPD（Tencent Agile Product Development）作为项目管理工具。然而，由于各团队设定的项目流程不尽相同，流程数据存在较大差异，无法直接应用于统一度量。

　　为了解决这一问题，我们采取了两方面的措施：

　　项目流程标准推广：与 PMO 和业务团队协作，明确并推广各团队需要度量的字段和规则，确保指标采集一致。

　　流程与研发规范统一：实现项目流程的研发一体化和平台化，将流程标准嵌入研发过程，以保证数据的统一性和采集效率。　　

图2.2.2-1 数据治理措施实施流程

　　上图展示了数据治理措施的实施流程，以下通过指标各阶段交付时长的示例来具体说明实施效果。

　　在转转中项目最小粒度为需求

　　在开发该指标时（需求全周期阶段占比：分析需求确认周期、需求等待周期、开发交付周期和测试交付周期的占比分布情况），我们发现开发交付周期偏长而测试交付周期偏短，与实际情况不符。进一步分析明细数据后发现，需求进入测试状态的时间通常早于项目排期。这一现象的主要原因在于开发和测试人员均有权限部署测试环境，一旦分支部署到测试环境，CICD平台便自动将需求状态从“开发中”更改为“测试中”，从而使度量数据与实际情况存在较大偏差，削弱了数据的度量意义。　　

图2.2.2-2 原CICD平台流程和需求状态的联动

　　发现此问题后，我们与 PMO 及业务团队合作，结合实际研发流程对 CICD 平台的流程进行了优化调整，确保项目规范与研发流程有机融合。

　　由于项目在 QA 正式介入后才进入测试周期，QA 的介入标志着测试周期的开始。基于这一点，我们对 CICD 平台的提测功能进行了强化，修改逻辑为：如果一个分支关联的需求指定测试资源为QA 测试，则在该分支部署至测试环境前，必须先经过提测流程，并由 QA 进行审核通过。此举确保测试环境不会被开发人员误操作，避免需求状态的错误变更。

　　从而实现两个关键目标：准确获取真实的提测时间点，并更清晰地区分开发与测试周期，从而更好地支持研发效能问题的深入分析。

　　新的流程如下图2.2.2-3　　

图2.2.2-3 新CICD平台流程和需求状态的联动

　　在基础数据治理中，我们力求实现「两个一」的目标，即一套标准、一个平台，从根本上提高数据的统一性和采集效率。

　　一套标准：我们通过制定并推广统一的流程标准，确保所有业务团队在项目流程和数据采集上保持一致。这样，不同团队的数据才具备可比性和观察价值，从而能够准确反映整体研发效能的情况。

　　一个平台：将这些标准内化到平台中，实现流程的自动化管理，减少甚至杜绝人工干预，以确保数据采集的统一性与一致性。平台自动采集的数据不仅降低了人为错误的可能性，也减轻了团队的负担，使数据治理更高效、稳定，为后续度量分析打下了坚实的数据基础。

　　结合上文的治理措施，我们通过对CICD平台的调整，将项目流程标准化、自动化，使各个项目的真实数据得以有效采集和管理。这样的数据治理体系，不仅为后续研发效能分析提供了可靠的基础数据，还让研发团队在无额外负担的前提下持续改进项目流程，从而全面支持公司数据驱动的研发提升目标。

　　2.2.3 达成效果

　　数据预计算，解决了查询慢问题

　　指标准确性及排查难度与原平台相比有显著提高，但整体效果未达到预期。计算逻辑依旧分布在代码中，依旧存在指标产出慢等问题

　　2.3 度量平台V1 2023~至今

　　在V0.5的建设中，我们将第T天的数据在T+1天进行计算，从而规避了实时计算带来的性能问题。这一策略有效缓解了查询速度慢的问题，但并未解决出数缓慢的根本问题。因此，我们将工作重心转向了数据建设，着力提升数据的处理效率。

　　经过调研，我们借助（DW/BI）重新建设度量平台的数据模块，目标是让数据准确可维护 & 一小时出数 & 方便使用者分析指标，实现“数据驱动研发效能提升”。其中，包含 3 个核心能力：

　　数据源统一：确保所有指标均来自统一的数据源，避免因数据源不一致而导致的计算差异，从而提高数据的准确性和可靠性。

　　SQL即指标：将SQL语句直接作为指标定义，以确保指标的可追溯性和透明性，同时简化维护流程。在依赖字段齐全的情况下，我们可以较为轻松地实现一小时出数的目标。然而，如果存在未管理的字段，出数速度仍会受限，主要原因在于加载数据源、数据处理等步骤会影响数据的可用性和处理效率。

　　高效交互设计让获取有效信息变得简单：通过小卡展示、图表联动、辅助字段、相关性分析和下钻分析等功能，用户可以根据需求查看指标在不同粒度上的数据构成，降低数据分析成本。

　　这三个核心能力相辅相成：首先，通过数据仓库建设实现数据源的统一，为准确的数据分析奠定基础；接着，利用 BI 系统的 SQL 即指标功能，简化和加速指标生成；最后，通过高效的交互设计直观展示数据，帮助用户快速获取有效信息。

　　下面将从三大核心能力的建设展开，详解一下。

　　3 度量平台V1

　　3.1 技术架构

　　现阶段度量平台都是离线数据处理，主要使用的产品和组件是Hive、StarRocks、Spark、58星河平台、58星火平台

　　度量平台V1技术架构，如下图3.1-1　　

图3.1-1 度量平台V1架构图

　　下面先简单介绍一下星河和星火，度量平台的（DW/BI）能力都是基于这两个平台

　　星河，是58集团大数据部自研的一套PaaS（Platform-as-a-Service）平台产品，为集团各个业务线提供数据接入与同步、数据开发、数据地图、数据质量、数据资产、数据生产、数据服务、指标管理、埋点管理等全方位的产品服务，一站式开发与运维管理界面，降低大数据使用门槛，为业务提效赋能。

　　星火是一款智能大数据敏捷BI平台，是一款具备数据分析能力的可视化产品，可以快速进行数据分析，零门槛、低代码，实现专业级数据加工处理，助力业务挖掘数据价值。

　　下面详细介绍一下度量平台是如何借助星河和星火的能力管理数据和建设指标。

　　3.2 数据源统一(数仓建设)

　　3.2.1 准备

　　自上而下，摸底排查

　　要实现数据源的统一，首先需要清楚目前已经使用的所有数据源，以及这些数据源中每个字段的具体作用，特别是它们在指标计算中的参与情况。因此，首先从平台中已有的度量指标入手，逐步拆解各个指标所依赖的数据源与字段，并整理出度量指标与数据源之间的关系矩阵。通过这种方式，可以清晰地标识出每个字段和指标之间的关联，从而帮助我们明确需要建设的数据源和字段。

　　例如，图3.2.1-1展示了度量指标与数据源矩阵，其中每个单元格的值为“1”表示该指标使用了相应的数据源字段。这种矩阵的梳理工作是数据源统一的基础，帮助我们准确识别和整理出关键数据源，为后续的数据源建设和需求处理打下坚实的基础。　

图3.2.1-1 度量指标&数据源矩阵

　　这一过程为后续的规范化工作和数据库设计提供了必要的信息支持，形成了从现有数据源到未来规范化数据源的桥梁。

　　规范库表，整装待发

　　在度量平台V0.5版本的设计中，已经对数据库表结构进行了初步整理，采用了星型模型和雪花型模型来组织库表关系，以便更好地支持度量指标的计算。然而，随着业务需求的增长和多张事实表的使用，这一初步设计已经不完全适应新的需求。因此，数据模型逐步演变为星座模型，允许不同的事实表共享公共的维度信息，从而提高数据的复用性和查询效率。

　　如图3.2.1-2所示，星座模型通过多张事实表和共享维度表的设计，使得数据组织更加灵活，同时也便于在后续数据分析过程中快速访问相关维度数据，避免了重复存储和维护的问题。　　

图3.2.1-2 星座模型

　　这一规范化过程不仅优化了数据库结构，而且为后续的数据源建设和指标计算奠定了基础，确保数据可以在更高效的环境中流动和处理。

　　3.2.2 维度建模

　　度量初期使用代码生成指标，现有的数据组织规范，不完全契合DW（数仓）体系，我们借助数仓工具箱中的维度建模四步走（如下图3.2.2-1）的建设思想，来确定库表是否符合DW规范。　　

图3.2.2-1 维度建模四步走

　　维度建模是数据仓库的基础，主要目标是确定数据仓库中的业务模型（如事实表和维度表），以及如何组织和存储数据。通过维度建模，定义了数据的结构和关系，是构建数据仓库的第一步。

　　因此，虽然上述四个步骤在网络上已有大量相关的讲述，但研发效能数据更侧重于结论性的数据，与常见的案例存在不同之处。以下将结合研发效能的数据特点，对每个步骤进行进一步的解释。

　　业务过程

　　业务过程是组织完成的操作型活动，例如，交易流程中的，订单创建、支付，取消支付等。简单来说需要我们选定上述过程对应的事实表并分析处理。

　　在分析研发效能数据时，我们可以根据主题来定义业务过程，例如，我们现在需要分析流动效率，主要目标是观察需求处于活跃工作状态的时间占总消耗时间的比例。可以按照以下步骤选择业务过程：

　　明确需求的生命周期：首先需要定义需求的各个状态，包括待办、进行中、评审、测试和完成等状态。将这些状态细分有助于精确衡量每个需求的时间消耗。

　　确定活跃工作状态：在流动效率的分析中，我们聚焦于需求的“活跃工作状态”，即需求在“进行中”及相关状态下的时间。这些状态反映了需求正在被处理的时段，代表了实际的工作投入。

　　计算总消耗时间：为了准确计算流动效率，除了活跃时间外，还需计算需求从创建到完成的总时间，包括等待时间、评审时间和测试时间等，全面评估需求的整体流转情况。

　　比较活跃时间与总时间：将活跃工作状态时间与总消耗时间对比，计算出流动效率指标。该比例反映了需求从生成到交付的过程中，实际工作时间所占的比重，从而帮助识别流程中的潜在瓶颈。

　　设置流动效率参考线：基于上述分析，设置一个流动效率的参考值，用于引导团队关注关键流程表现。这一参考线作为辅助线，有助于团队监测和评估流程改进情况，便于需求管理和交付效率的观察与优化。

　　声明粒度

　　声明粒度是维度建模中重要的步骤，粒度用于确定事实表中的一行数据代表什么。优秀实践是应该选择能够表达选择业务过程事务的最细粒度。 举个例子

　　定义流动效率的业务过程：流动效率关注需求的工作状态转换过程，特别是需求处于“活跃”状态的时间占比。通常定义的业务过程可以是需求从创建、通过不同状态（如待办、进行中、评审中）、直至完成的全流程。

　　过程数据的属性：对于流动效率的分析，我们需要跟踪每个需求在各个状态的停留时间、处理人、处理步骤、开始和结束时间等数据。需要特别关注每个需求在活跃状态的累计时长。

　　状态转换记录：为每个需求记录状态转换数据。对于每次状态变化，记录其转换时间及对应的处理人。这样可以得到需求在每个状态的停留时间段，并且可以按需求拆解每个状态的流转时长。

　　粒度设定：为更精准地度量流动效率，设定粒度为“需求-状态转换级别”，即每个需求的每次状态转换形成一条记录，记录需求从某一状态进入下一状态的具体时长。通过这种粒度，可以准确衡量需求在“活跃”状态的累计时长和总时长。

　　流动效率计算示例：在定义好粒度后，可以灵活进行各类分析，如计算某时间段内活跃状态时间在需求总耗时中的占比，或按处理人、部门等维度查看流动效率差异。这种细粒度数据支持下钻分析，帮助发现各个需求的流转瓶颈。

　　通过这种方式，将流动效率按“需求-状态转换”粒度分解，便于快速响应不同分析维度的查询需求，有效支持流动效率的多角度分析。

　　如下图3.2.2-2 最细粒度数据　　

图3.2.2-2 最细粒度数据

　　确定维度

　　维度用于描述最小粒度的事实，可以理解为事实的修饰符，回答“谁、什么、何处、何时、为何、如何”等问题。例如，需求优先级、关联需求对应的业务线等都可以作为维度。

　　确定事实

　　根据上述步骤确定需要计算出什么样的指标，例如计算出不同业务的产品需求流效率

　　通过维度建模的四个步骤，能够帮助我们明确数据仓库中事实表与维度表的结构，进而为研发效能分析提供清晰的数据基础。在实际应用中，虽然维度建模的基本框架是通用的，但研发效能数据的特殊性要求我们在业务过程选择、粒度设定及维度设计方面进行特定调整。通过这种方式，我们可以更好的对研发效能过程进行分解，精确度量研发过程，帮助团队发现潜在瓶颈并优化工作流程，从而提升整体的研发效能。

　　3.2.3 数仓分层

　　在维度建模之后，我们对数仓进行分层，以简化后续的数据管理难度，同时提高数仓的扩展性和稳定性。

　　转转数仓分层和主流建设思路一致，如下图3.2.3-1，　　

图3.2.3-1 主流数仓分层模型

　　度量平台数仓主要分四层

　　ODS（贴源层）： 这一层的数据与导入的业务数据基本一致，仅进行简单处理，如去除文本中的换行符和空格、格式标准化等，以确保数据质量和一致性。

　　DW（数据明细层）：在这一层，具有相同粒度的维度和事实数据会被整合到一张表中，通常称为“宽表”或“维度退化表”。

　　DWS（轻度汇总层）：在这一层，针对DW中的数据进行进一步处理，主要是根据时间维度生成周、月、季度和年度等汇总数据。经过汇总的数据会通过自然键（如时间戳）重新接入DW表。这一层可以被视为一个过渡层，旨在为后续的分析提供便利。如果数据结构较为简单，可能不需要专门建设该层，以避免不必要的复杂性。

　　ADS（应用数据层）：ADS并不是一个实体表，而是将DWS和DW中的数据导入到合适的OLAP引擎（如StarRocks）中，以便直接生成所需的指标。这种方式能够充分利用OLAP引擎的高效查询能力和分析功能，从而满足用户变化多样的查询诉求。如果业务比较简单也可以直接将数据汇总，导入mysql供用户查询。

　　以上文流动效率主题数据为例，度量平台数仓分层如下图3.2.3-2　　

图3.2.3-2 度量平台数仓分层模型

　　3.2.4 维表建设

　　在数仓架构中，除了ODS、DWD、DWS等层次外，另一个重要层级是DIM（维度层），如图3.2.3.1-1所示。DIM层用于存储业务维度信息，为DWD和DWS层提供支撑。维度数据可以在建模中与DWD、DWS合并或退化到事实表中，以便简化查询。下面是建设维度表的一些关键步骤和注意事项。

　　维度表建设流程

　　下面以需求维度表为例介绍一下

　　选择实体在设计需求的维度表时，首先要选择实体，也就是该维度表要描述的抽象对象。在软件开发过程中，需求作为一个核心业务实体，可以包含大量信息。需求可能会涉及多个维度，例如需求类型、需求优先级、需求状态、需求来源等。这些都是对需求进行抽象和描述的属性。同时，需求还会关联到业务流程中的其他参与者，如产品经理、开发人员、测试人员等，他们在需求的定义和实现中扮演重要角色。因此，在需求维表的设计过程中，需要结合具体的业务流程，选择适合的维度实体，确保维度表可以清晰地描述需求的不同特征和参与者的关系。

　　确定主维表确定需求的主维表，需要识别出维度表的主要数据来源。通常，需求的核心信息会存储在项目管理系统或需求管理系统中，如JIRA、TAPD等系统。这些系统通常包含需求的核心字段，如需求ID、需求名称、需求状态、创建时间、开发人员等，是维度表的主要数据来源。

　　确定辅维表辅维表的作用是补全主维表中需求实体的数据，并提供更多需求的属性描述。对于需求来说，除了主维表中的基本信息，还可以从辅维表中获取更多的辅助信息，如需求的关联人员（产品经理、开发人员、测试人员等）、需求的标签（如需求分类、所属项目，OKR等）等。这些辅维表可以包括人员信息表、需求分类表、需求项目表，需求业务表等，用来丰富需求维度表的属性。通过这些辅维表，需求维度表可以提供更加详细和多维度的数据支持，满足多样化的分析需求，并增强维度表的表现力和分析能力。

　　识别维度属性需求维度表中的属性可以分为“固化属性”和“动态属性”。固化属性是相对稳定的，如需求ID、需求名称、需求创建时间、需求类型等，这些属性不会频繁变化。而动态属性则是随着业务活动而变动的，如需求的当前状态，需求的进度等，这些属性可能会随着开发流程的推进而变化。由于固化属性和动态属性的变更周期不同，通常会在维度表的构建过程中将其拆分。这样可以更高效地管理和更新需求维度表，并为追溯历史需求数据提供合理的技术实现，确保数据分析的准确性和一致性。

　　如下图3.2.4-1为度量需求维度表

　　在数据仓库中，维度层（DIM）支持DWD和DWS层，存储业务维度信息。设计需求维度表时，需要选择合适的实体并识别主维表和辅维表，全面描述需求的各个维度，如类型、优先级、状态等。维度表包括固化属性和动态属性，分开管理以提高更新效率和数据一致性。辅维表丰富了属性，支持多维分析，最终将这些维度信息嵌入到DWD层，为数据仓库分析提供支持。

　　缓慢变化维（SCD）

　　上文提到，维度属性分为“固化属性”和“动态属性”，缓慢变化维（SCD）便是动态属性的典型。接下来我们将分享在维度表中处理缓慢变化维的实践经验，以保证数据在变化时的准确性和一致性。

　　缓慢变化维（SCD）与普通维度的主要区别在于其处理数据变化的方式和保留历史记录的需求。SCD用于管理那些在维度数据中会随着时间缓慢变化的信息，且需要保留这些变化的历史。

　　例如，由于业务需求的调整，支持A业务的研发人员可能会转向支持B业务，甚至同时支持C业务。当分析不同业务的人员投入和工作量产出时，SCD允许我们保留这些人员变动的历史，以确保分析的准确性和完整性。这对于多业务线的人员支持和资源分配分析非常重要，可以帮助企业从长期数据中提取出有价值的趋势和见解。

　　在Kimball的理论中，有三种缓慢变化的处理方式，分别是：

　　SCD 1（直接覆盖）：直接更新维表中相关的字段，不保留历史。适用于不需要追踪变化的情况。

　　SCD 2（新增行）：为每次变更新增一行记录，并加入有效时间或状态字段，适用于需要完整历史记录的情况。

　　SCD 3（新增字段）：通过新增字段保存最近一次的历史数据，适合只需要有限历史的情况。

　　如图3.2.4-2所示，我们通常通过新增一行记录来反映变更，这是度量中最常用的处理方式。对于这样的数据，我们通常会使用“开始日期”和“结束日期”字段来描述数据的生效区间。如果结束日期尚不存在，会将其设为9999-12-31。此方法不仅防止出现空值，还方便了后续使用BETWEEN进行区间查询。　　

图3.2.4-2 SCD 2（新增行）

　　3.3 SQL即指标

　　在数据仓库（DW）建设过程中，我们通过标准化的数据建模和清洗，将原始数据整合为结构化、高质量的分析数据集。

　　数据按照 DW 规范组织后，所有数据都以主题域为核心进行分层存储和管理，不同业务线的数据被统一映射到维度和事实表中，消除了数据孤岛和冗余问题。通过这种规范化的组织方式，数据的关联性更强，支持更复杂的多维度分析和指标计算。借助 BI 工具的快速分析和即席查询能力，业务指标能够实时生成和更新。

　　这种 BI 驱动的架构通过自动化的数据抽取和可视化配置，简化了数据处理过程，使业务用户在数据完备的基础上，迅速达成一小时出数的目标，从而支持高效的日常业务需求。

　　在这一架构支持下，度量平台能够高效、准确地管理和更新各类指标，为业务提供便捷的分析工具和决策支持。

　　3.3.1 可视化生成指标

　　以“流动效率”指标为例，展示如何借助 BI 平台快速生成指标。

　　数据集已经在前期准备好，接下来可以直接使用这些数据集。

　　基于星火平台的可视化能力，用户可以通过图形化界面直观地展示数据，轻松实现数据汇总、求和、占比分析，以及同比、环比等计算，满足各类数据分析需求。

　　星火搭建图表功能区如下图3.3-1　　

图3.3-1 星火搭建图表介绍

　　在星火平台中，用户通过拖拽数据集的字段即可轻松汇总数据，如下图所示的流动效率相关指标：

　　通过拖拽数据集对应的字段即可汇总数据，如下图3.3-2流动效率相关指标　　

图3.3-2 流动效率相关指标

　　部分指标较为复杂，如流效率指标涉及多个原子指标。因此星火平台还支持在数据源中自定义字段，即允许用户自定义 SQL 表达式，从而实现特定指标需求，并且允许自定义字段是可以嵌套使用，这方便将一个复杂指标分成多个小指标，方便维护和复用。　　

图3.3-3 创建自定义指标

　　这些自定义字段可以在同一数据集下供多个图表复用，确保在数据源层级上，所有使用该数据集的图表能够保持一致性，避免同名异义或异名同义的情况。

　　星火平台本质上是一个 SQL 查询引擎：用户设计的每一个可视化图表背后，实际上都是由 SQL 驱动的。

　　通过这一体系，度量平台成功实现了“SQL即指标”的能力，确保了每一个指标都可以通过 SQL 灵活定义，并在数据源层级上实现统一与复用。这不仅简化了指标管理，也提高了数据分析的灵活性和一致性。

　　3.4 高效交互设计

　　在前文中提到的星火平台中，度量平台主要利用其功能来维护数据集和自定义指标，而具体的数据展示和图表交互则是度量平台的核心任务，如下图3.4-1 度量平台处理星火数据流程图。　　

图3.4-1 度量平台处理星火数据流程图

　　度量平台的交互设计思路围绕主题域的定义展开，并进行层层分解，突出相关性分析和下钻功能。对于较复杂的主题域，会设计相关图例，并使图例中的元素与图表联动，以便用户更好地理解指标。这种设计不仅增强了数据的可读性，还帮助用户在分析过程中更直观地识别趋势和异常。

　　主题域则是围绕某一主题展开的所有相关数据和维度的集合，涵盖了从不同角度分析和度量该主题的各类信息。

　　以“流动效率”为例，主题是“流动效率分析”，它关注的是需求在不同工作状态下的时间分布，具体是活跃工作状态时间占总消耗时间的比例。而主题域则包括围绕流动效率展开的所有相关数据，比如需求的生命周期、不同工作状态的时间、需求的处理人、需求的优先级等，所有这些信息和维度共同支持对流动效率的深入分析。

　　简而言之，主题是分析的核心对象，而主题域是与该对象相关的数据和维度集合，帮助全面理解和度量主题的各个方面。

　　3.4.1 页面功能区　　

图3.4-2 度量平台页面功能区

　　上图3.4-2展示了流动效率相关指标的报表，页面主要由以下五个部分组成：

　　筛选区域：包含业务线和时间的筛选选项，用户可以根据需求灵活选择。

　　小卡区域：展示用户筛选的最近一个月的数据，为用户提供快速概览。

　　图例区域：考虑到流动效率主题域中五大流指标概念较多，设计该图例旨在帮助用户更直观地理解和分析数据。图例中的文本元素都是可以点击的

　　指标内容区域：通常拆分为两部分。左侧显示当前用户筛选业务的数据（4.1区域），右侧展示该业务的子业务数据（4.2区域），便于对比和分析。

　　导航栏区域：提供便捷的页面导航，帮助用户快速定位所需信息。

　　3.4.2 图表间交互

　　联动&下钻

　　度量平台支持配置同一页面的图表和其他任意图表联动，例如下图3.4-3流速率指标，由两部分组成，当前筛选业务和当前筛选业务的下级业务。　　

图3.4-3 图表联动

　　下面以流速率指标为例，详解一下，联动和下钻是如何辅助用户分析的。

　　度量图表的X轴通常是业务线与月份的组合，左侧图表显示用户当前筛选业务的数据趋势，右侧图表则默认展示该业务的子业务在最新一个月的数据。如果用户认为左侧数据趋势的有异常，其中某个月份波动最大，则可以鼠标点击该月份的点或者是坐标轴对应的位置，右侧图表会自动更新为用户所选择月份的数据，如图3.4-4。　　

图3.4-4 图表联动-选中月份

　　在确定异常数据所在月份后，用户可以进一步分析该月份子业务数据的构成，找出对父业务线数据的波动，贡献最大的子业务线，可以从上图3.4-4看出度量已经按贡献大小为用户排好序了，方便用户定位数据。

　　如果确认某个子业务线引起了波动，用户可以进一步下钻。如下图3.4-5 该图表配置了明细，用户可以直接点击明细，分析明细数据，定位异常数据。下图3.4-6 为具体月份和业务线的明细数据　　

图3.4-5 图表联动-明细　　

图3.4-6 图表联动-明细数据

　　具体的下钻维度是可配置的。这种逐层下钻的方式使用户能够一步步深入，最终定位到最细粒度的数据，从而确认异常数据的来源，并辅助用户进行深入分析。通过这种交互设计，度量平台不仅提高了数据分析的灵活性，还增强了用户对数据的理解与洞察能力。

　　相关性分析

　　层层下钻功能支持用户逐层分析指标数据，但有些指标的波动可能是由其他因素引起的，并不一定意味着异常。例如，某个业务团队的需求消化量减少，可能是因为该团队的人员临时支持了其他团队，或者最近承接的都是交付周期较长的大项目。

　　度量平台支持图表一次定义，到处使用，因此用户可以将与特定指标相关的图表集中展示。为此，度量平台支持用户自定义页面并会在配置的图表上以按钮的形式显示，如下图3.4-7 所示。　　

图3.4-7 相关性分析-关联按钮

　　该按钮可以跳转或者在当前页面以抽屉的形式打开。用户可以方便快速访问相关图表，如下图3.4-8 通过这个功能，用户能够更方便地进行数据之间的相关性分析，从而全面理解指标波动的原因。　　

图3.4-8 相关性分析-页面展示

　　4 总结

　　上文主要介绍了度量平台在数据准确性，快速出数，快速分析方面的各项努力。核心思路是通过数据仓库（DW）和商业智能（BI）系统有效管理数据及指标生成，这使得度量平台能够将工作重心集中在指标管理和图表交互上，从而大大解放了人力资源。

　　上文的解决方案可能不是最优的，只是转转在业务发展过程中，根据当前现状所选出的适合实现方式。现在这条路已成功铺就，支持了现阶段度量平台的发展：

　　十几个主题域的数据分析

　　管理了近千个图表

　　2000+ 派生指标&复合指标

　　如果业务希望建立研发效能平台但公司内尚未使用DW/BI系统，可以考虑一些开源项目。例如，开源BI工具Superset，Apache DevLake可以帮助可视化和分析数据，而开源数仓如Apache Druid、ClickHouse和Apache Pinot等则能高效存储和查询大规模数据。如果公司有采购预算，直接考虑商业化的BI和数仓产品也是一个不错的选择，这样能够获得更全面的支持和服务。

　　5 未来规划

　　提升后台配置和交互设计

　　当前平台的后台配置交互较为复杂，用户在配置和操作过程中存在一定上手难度。未来将对后台交互界面进行优化，增强操作指引，简化配置流程，降低用户的学习和使用成本。

　　降低用户上手成本

　　针对上手成本高的问题，未来规划会通过培训、操作指南等多种方式帮助用户快速熟悉平台功能，确保用户能够轻松掌握各项指标生成和分析操作。