导读 本文将分享沐瞳科技在指标管理及智能洞察方面的实践经验。
主要内容包括以下几大部分：1. 指标管理
2. 指标生产消费
3. 智能洞察
4. 指标治理
5. Q&A
分享嘉宾｜HelenMa 上海沐瞳信息科技有限公司 数据仓库负责人
编辑整理｜张俊光
内容校对｜李瑶
出品社区｜DataFun
指标管理
沐瞳指标管理中的痛点可以归纳为四大方面，即找数难、效率低、质量差和 ROI 低。
在页面上看到的数据，其背后的口径往往不得而知。想要验证这些数据的准确性时，既不清楚数据来自哪个表，也不了解取数的具体逻辑。各业务团队会自行加工指标，采用各自的口径，并且由于我们主要使用 Leap 和风神等工具，导致了数据入口不统一，数据分散在各个看板中，进一步增加了找数的难度。每当需要新增页面或指标时，涉及前端、后端、数仓等多个环节，所有相关角色都需要参与，导致需求周期长且开发效率低。同时，在业务需求对接时，缺乏统一的指标体系可供参考，需求描述往往很模糊，使得开发团队的理解成本增加、需求变更频繁，这也导致了受理周期变长、开发效率跟不上。虽然能够看到数据，但数据的准确性难以保证，在不同平台上看到的数据可能不一致，存在同名不同义或者同义不同名的情况。由于我们目前在 AWS 上运行，其成本相较于自建集群略高，尤其是计算费用，因此我们在进行项目开发和指标迭代时会密切关注成本账单。历史上曾出现资源耗尽导致风神等系统崩溃的情况，这主要是因为各个业务团队都在处理相同的数据集，但各自独立地进行数据加工和硬编码开发，导致资源被大量消耗。更为关键的是，我们缺乏一个公共的数据集或统一的指标集合来供各个业务团队使用，这使得每个业务团队都需要开发自己的一套私有数据处理逻辑。此外，历史上各业务团队对于数据的使用和分析可能并不充分，这导致我们存储了大量的埋点和 ODS 表，但这些数据实际上可能并未被充分利用。例如，我们可能直接将业务 ODS 数据导入到 ClickHouse 中，或者通过 Impala 查询数据，虽然显示有热度，但这种热度往往是虚假的，因为真实情况可能是这些数据并没有多少人真正查看或使用。但即便如此，我们仍需为这些数据的存储和维护支付成本。因此，我们需要在保证业务数据需求得到满足的同时，更加关注数据处理链路的成本效益，寻求更为高效和经济的解决方案。2. 策略与功能布局
首先，我们将进行集中化的梳理工作，主要集中在产品数分和数仓方面，以建立并优化一二级指标体系。由于分析与业务紧密相关，我们将在此过程中发挥更积极的作用。此外，从平台层面出发，我们将制定并规范指标的业务定义和技术定义，确保指标开发的流程明确，不同业务和角色之间的协作顺畅。然而，集中化的梳理工作目前仍停留在文档和流程机制层面。为了实现物理上的管控，我们将进一步推动产品化功能的整合，将策略嵌入到开发的整个 workflow 和需求流程中。首要任务是确保指标能够清晰展现且易于使用，即加强指标管理。我们将统一管理指标的定义、术语规范以及对应的数据标准。接下来，我们将解决人力与需求匹配度不高、迭代效率低以及需求生命周期管理不善的问题。为此，我们将采取一系列措施，包括基础建模、数据集绑定接入、封装指标服务以及加工指标血缘等。这些举措旨在提高整体效率，并输出更贴近业务价值的指标。同时，我们注意到分析和算法团队以及运营人员在日常工作中存在大量低价值的例行分析报告。为此，我们将协助他们开发智能探查功能模块，减少人力占用，提升工作效率。此外，我们还将引入自助分析和指标关系模块，以进一步提升数据的使用效率和价值。在解决了指标可见性和易用性问题后，我们将转向指标的保障和成本控制。我们将统一管理数据资产，特别是针对 Leap 等工具的二次开发限制，我们将嵌入其元数据并自行扩展。并且整合数据专辑，构建资产健康度体系，确保数据资产的健康和稳定运行。最后，为了响应公司整体的服务满意度要求，我们将利用飞书服务台等工具，建立知识库并进行快速问答响应，确保在数据服务方面达到分钟级，甚至秒级的回复速度。这将有助于提升整体的数据服务质量和效率。3. 指标的命名规范
在指标管理方面，确保每个指标都能被清晰地识别和使用是至关重要的，首先要做的就是规范指标的命名。对于原子指标，我们主要遵循“业务过程+实体+度量”的命名方式。这种方式特别适用于轻度汇总层，聚焦于基础且直接反映业务实质的数据点。以我们日常工作中常见的游戏类分析为例，像“新增充值角色数”这样的指标，我们会直接将其作为原子指标进行处理，并加工后放入原子指标库中。当需要进一步扩展或衍生新的指标时，我们会通过调整统计周期或添加修饰词来实现。这些扩展和衍生指标通常会被放置在统计分析层（如 DM 层），而对于逻辑更为复杂、可能涉及多层复合类的指标大多放在 ADS 或 OLAP 层，以确保它们不会污染或干扰到通用的指标模型或数据模型。4. 指标的定义与管理
为了确保指标的一致性和准确性，我们要建立一系列标准化的管理机制。首先，面对指标口径不统一的问题，要采取统一管理的方式，从业务定义上进行收口，确保各个团队和部门对同一指标有统一的理解。然而，除了业务上的收口，我们还需要在物理层面进行收口，即绑定对应的数据集和技术定义，确保数据链路的一致性和准确性。在业务层面上，建立数据底座，包括词根管理、命名规则管理和模板等。由于不同数据的上报方式可能并不规范，且改造成本高昂，我们将预留一个原始字典，用于将历史存量数据通过标准字典进行映射，以确保整个数仓的加工和下游消费符合规范。在标准化的管理基础上，我们将进一步构建原子指标、衍生指标和复合指标等指标字典。这些字典将为我们提供清晰的指标定义和分类，方便团队成员在需要时快速找到并使用正确的指标。在指标管理的过程中，我们还会定义维度的元模型和指标的元模型，对一些重要的维度和指标进行细化的绑定，以便在后续提供指标服务时能够更高效地响应需求。通过这些措施，我们将能够建立起一套完整、准确、规范的指标管理体系，为公司的数据分析和决策提供有力支持。5. 指标的需求流程
在指标管理模块落地后，我们意识到这一流程并非固定不变，而是需要动态地融入整个需求链中。因此，我们着手构建了一套常态化的需求到指标管理的流程机制。其核心原则在于确保每个指标都有明确的责任人，因为缺乏责任人的指标管理往往容易出现问题。早期我们曾面临过这样的挑战：尽管拥有指标和核心指标，但当我们追溯至数据贴源层（如 ODS）时，发现这些层面往往缺乏明确的负责人。多方都可以将数据上报，而每次的变更操作和影响也缺乏明确的记录和跟踪。为了解决这个问题，我们采取了前置管理的策略。在业务需求阶段就明确业务背景和场景，并详细拆解了维度指标。进入需求分析阶段后，进一步确定数据源，并与产品和分析团队一起界定了指标的命名规范。这些规范都是提前与开发团队协商并约定的。在需求评审阶段，我们会提交与指标命名相关的元素，并通过产研联合的审批方式确保各方对指标的理解一致。只有需求被清晰、准确地定义，后续的开发工作才能高效进行。我们曾遇到过这样的问题：在需求对接阶段，大家对指标的理解不够深入，只是简单地讨论了一下。然而，当开发团队开始工作时，发现关于指标细节、数据源、口径定义和质量预期等方面的信息并不完整，就会导致开发过程中的循环往返和效率低下。为了避免这种情况，我们努力界定每个流程环节和角色的输出内容，并努力实现这些输出的标准化。一旦输出内容标准化后，开发团队就可以更加高效地遵循这些规范进行工作。这样做不仅减少了二义性和歧义的问题，还避免了循环往返的困扰。指标生产消费
基于指标管理，我们确实能够清晰地看到各项指标，接下来主要面临的问题是如何使这些指标能够被快速高效地利用，即提高指标生产效率和消费效率。
在标准化领域模型的构建过程中，我们首先会对基础数据进行基本的数据域划分。基于这些划分，进一步构建汇总层，以满足不同分析需求。例如，我们可能会设置分析层，以便更便捷地接入汇总数据。为了实现这些目标，整个指标平台需要进行数据集的绑定。数据集绑定过程涉及两个主要方面。对于在线业务，由于其对服务等级协议（SLA）的要求较高，接入的是实时更新的表。而对于分析型需求，特别是那些涉及多维下钻的场景，会更多使用宽表，SLA 就不会特别稳。基于不同的业务场景，接入的数据集类型各不相同，但我们会对这些数据集进行统一的分类和抽象处理。最终，这些标准化的领域模型将广泛应用于多个平台，如经营分析、标签平台、实验平台等，甚至可以直接同步至各种数据看板。在整个数据序列中，大家通常通过表、字段或指标等方式进行数据交互。然而，在前后端开发应用的实际交互中，它们使用的是一种基于请求的语言，其中包含了各种参数。当前效率低下的一个原因是大多采用定制开发，即每次都需要明确指定所需数据，然后将其呈现在页面上。为了改善这一问题，我们与前后端团队统一约定整个请求的 DSL（领域特定语言）。这种 DSL 将作为我们统一的数据交互语言，通过标准化的语义来减少误解和重复工作，也更易于通过大型模型进行转换和处理。
指标查询主要关注五个关键要素，即数据集、指标、维度、过滤条件和时间范围。当然，如果涉及到前端交互，还会包括筛选条件，即用户选择的筛选项。针对数据服务接口，一个查询请求 DSL 会包括：数据集：首先要确定查询的数据集，这是查询的起点。
指标和维度：例如，要查询的指标是“订单金额”，维度是“日期”等等。
过滤条件和时间范围：如时间范围。比如查询“菲律宾”的订单金额，并且限定在某一时间范围内。
存储引擎：查询的数据可能存储在特定的数据库或存储引擎中，如 StarRocks。
针对这样明确的语义是很容易结构化的。一旦请求 DSL 发过来，我们会通过查询服务来处理这个请求。查询服务的主要功能包括：执行计划：包括语法解析和模型匹配，根据场景需求选择合适的表和力度，进行模型择优，明确查询的执行计划。
OneSQL 拼接：每个查询 SQL 会建立一个 ATS 树，并进行剪枝优化，拼接出最终的SQL，还会利用物化视图来进行加速，最终给到引擎去执行。对于一些指标，尤其是原子指标，可能还需要进行二次计算。
合并与输出：最后，将处理后的查询结果合并并返回给调用方。
以上就是一个简单的原子指标查询的完整流程。通过明确的需求、优化的查询服务和精细化的执行计划，可以确保查询的高效性和准确性。智能洞察
随着整个体系的完善，我们期望的不只是工具和提效，而是希望能够更加贴近并赋能业务。针对当前分析中遇到的一些痛点问题，我们引入了智能洞察模块。这些问题通常可以通过数据化手段进行解决，因为它们往往具有一定的规律性。目前，我们面临的主要问题可以分为两类：第一类是确定性问题，即与过去相比，某些指标出现了大幅波动，可以通过量化的方式来呈现，并可以通过拆解找出其背后的因果关系；第二类是潜在型问题，即我们与未来目标之间的差距，或者按照当前趋势发展，未来可能会遇到的增长瓶颈，这类问题需要我们基于既定的分析框架，构建诊断模块，来预测和评估潜在的风险和机会，并决定是否需要进行干预。
我们目前主要依赖的工具是 Leap 和风神，这里以一个 DAU 拆解的案例来详细阐述我们的分析过程。这一案例中，基础数据在 Leap 平台上进行加工处理，数据集的一部分则被接入到风神系统中。针对 DAU 主要从维度和指标两个方面进行拆解。维度方面，常用的维度包括国家、渠道、机型、网络等，这些维度为我们提供了丰富的视角来观察 DAU 的变化。指标拆解方面，可以将 DAU 细分为新增用户、留存用户和回流用户等，可以采用加法拆解或漏斗模型拆解。加法拆解有助于我们理解 DAU 的构成比例，而漏斗拆解则关注用户从打开应用到完成特定任务的全流程，帮助我们分析用户流失的节点和原因。除此之外，还有其他一些因素，比如因为我们的主要业务位于东南亚地区，涉及多个国家，每个国家的大事件和节假日都有所不同，定期的赛事活动也会对流量产生显著影响。因此，在进行分析时，会综合考虑这些因素对 DAU 的影响。在智能洞察的结论中，首先会给出指标的波动情况，对比基期值和当期值的变化。接着是通过维度拆解进行根因定位，尝试找出影响 DAU 变化的关键因素。例如，在国家维度下，某个国家的 DAU 出现了异常波动，这可能与该国的运营问题、竞争对手抢占市场等因素有关。再接下来是对指标进行拆解，分析原子指标对整体指标波动的影响。在维度和指标都已拆解完后，如果仍未找到明显的变化原因，就会进一步考虑大事件的影响。我们会遍历所有可能的大事件，如 all star 活动、停电事件、暑假事件、政治性事件等，并评估它们与 DAU 波动之间的关联程度。根因定位主要采用离散度这一指标来评估。在通用的分析之后，会进行结构化的封装。为了更贴近业务，我们的智能洞察报告会以业务更熟悉的形式来输出。另外，指标的异动分析，也会通过图表的颜色形状大小来突出显示，从而方便业务更直观地洞察数据背后的问题。
在数仓模型的建设上，我们主要聚焦于分析性的宽表。在 ADS 层，我们构建了面向指标模块化的矩阵模型，以适应不同分析需求。同时，我们也设置了 OLAP 层，包括支持多维下钻的模型，以及衡量指标过程贡献的模型。还引入了一些特定的分析模型，如 Iceberg 类分析模型，以支持更为精细化的数据分析需求。基于这些模型，我们结合当前先进的工具能力，如异动检测、指标归因以及指标分析树，进行深入的洞察和总结报告的封装。对于指标管理，我们有大盘指标监控平台，该平台能够实时监控关键业务指标的变化。同时，我们也提供多维分析平台，协助用户从多个角度理解数据。结合之前提到的指标管理和地图功能，我们将这些工具和平台整合为一个整体，为用户提供一站式的数据分析和洞察服务。指标治理
在确保指标能够清晰展现且易于使用之后，接着重点关注的是指标质量和成本的问题，因此会进一步开展指标治理的工作。
在指标质量保障的事前阶段，我们注重建立明确的规范与机制。首先，我们设定了详细的需求准入规范，通过 Checklist 的形式确保每个指标需求都经过严格审查。其次，我们制定了指标接入规范，涵盖命名、接入流程等各个环节，确保指标的统一性和规范性。同时，我们还建立了严格的数据质量自测规范，包括冒烟测试、白盒测试、黑盒测试等，借助 Leap 等平台的数据探查和对比功能，以及 ChatGPT 等先进技术进行代码 bug 分析，确保数据质量符合标准。此外，我们还重视监控配置的标准规范建设。我们为不同数据等级设定了基线要求，并制定了详细的监控配置指导，确保每位开发人员都能按照统一的标准进行监控配置。同时，我们结合飞书等平台的流程接入能力，制定了明确的流程规范，通过触发通知机制和检测机制，确保流程的高效执行。在事中阶段，我们主要关注执行与签署环节。我们要求开发人员签署 SLA（服务等级协议），确保服务质量和性能满足要求。同时，我们利用数据血缘关系对整个上游节点进行保障，确保数据的准确性和可靠性。在监控方面，我们特别关注 P0 级任务，确保任务性能、运行时长以及队列资源等关键指标得到充分保障。对于重要指标或线上指标，还会实施资源隔离和预警机制，确保资源的有效利用和稳定性。在事后阶段，我们会定期监控指标的热度和 ROI（投资回报率），对于热度低或 ROI 较低的指标进行下线处理，以优化指标体系。同时，我们建立了双周治理机制，定期与业务团队沟通指标使用情况，确保指标与业务需求保持高度一致。此外，我们还通过反馈机制不断优化监控流程和规范，提升指标质量保障的效率和质量。
鉴于公司在 AWS 上运营的特殊环境，AWS 的高成本是我们必须正视的一个问题。为了更精准地管理成本，我们基于指标体系和关系图，结合当前的字段血缘和表血缘，深入探讨了如何更有效地管理和优化成本。首先，我们根据基线 SLA 签署数据、表热度数据以及业务需求，对数据和指标进行了细致的分类和分级。同时，还会考虑数据所在表的生命周期，以便更准确地估算每个字段的成本。AWS 的账单在字段层面无法提供如此精细的成本分析，所以我们通过为机器和业务场景打上标签，实现了更精确的成本分摊。在标签化方面，我们采用了两个维度：业务和技术组件。从业务角度看，我们根据项目的不同层级打上标签；从技术角度看，我们关注技术组件在项目中的使用频率和规模。这些标签不仅有助于我们识别高成本区域，还为后续的优化工作提供了依据。通过对机器和项目的标签化，我们能够生成统一的叶子节点账单，其中包含了各个节点的成本信息。这使得我们能够清晰地看到哪些组件或项目在成本上占据主导地位，进而采取针对性的优化措施。在指标加工链路中，从数据采集、加工到出仓的每个环节都会产生费用。通过深入分析这些费用，我们能够发现成本较高的环节，如存储、计算或传输等，进而采取针对性的优化，如集成优化、存储优化和计算优化等。最近，我们在进行字节迁移项目时，就采用了这种成本优化策略。通过对采集、存储和计算等环节的优化，我们成功将成本降低了一半。这充分证明了在指标链路成本管理中，通过精细化分析和优化，可以显著降低运营成本，提高 ROI。总之，通过深入分析和优化指标链路成本，我们能够更有效地管理 AWS 上的运营成本，提高公司的盈利能力。Q&A
A1：针对存量指标的治理，我们当前的策略主要是这样的：当某个存量指标名在生产环境中变得至关重要时，我们并不会轻易改动其生产链路，因为我们需要考虑到投产比。直接修改这些重要指标的成本通常较高，因此，我们更倾向于采取一种成本较低且风险较小的方法——为这些指标设置别名并进行映射。这样做可以确保生产环境的稳定性，同时满足新的需求或标准。关于这些规范是否会降低整体交付效率的问题，实际上在初期阶段，由于团队成员需要适应新的规范，可能会暂时降低交付效率。然而，一旦这些规范被纳入我们的工作流程，比如需求流程或开发流程中，人工介入的成本就会逐渐降低。在建表或接入数据集时，我们可以利用一些推荐机制来确保按照规范进行操作，并且直接继承相应的元数据，从而减少手动输入的需求。这样，随着时间的推移和团队的逐渐适应，规范不仅不会降低交付效率，反而能够确保数据的统一性和规范性，提高整体的工作效率。因此，在治理存量指标时，我们需要根据业务的实际需求来确定最痛的点，并采取相应的策略进行解决。无论是从成本账单的角度去拆分，还是从指标质量的角度去撬动，我们都应该考虑整个业务的 ROI 和收益。这样，我们才能确保存量指标的治理工作能够真正为业务带来价值。A2：在数据治理的实践中，数据的分类与分级是不可或缺的关键环节。首先，数据的分类需要遵循行业与国家标准，确保一级分类和二级分类的准确性与规范性。这一分类体系不仅与数据安全紧密相关，更是前台业务映射的基础。我们的数据分类方法基于安全分类的二级框架，进一步拆解业务主体和动作过程，形成业务易于理解的三级分类。通过这种方式，我们能够将业务分类映射到数据的数据域分类上，尽管两者的命名和数据项单元可能有所不同，但映射的方式确保了分类的一致性和准确性。在数据分级方面，我们针对重要的 top 资产进行了深入的分析。早期，我们采用人工方式逐个评估每个数据表的分级标准，主要考虑查询热度、数据血缘、SLA 和基线染色等因素。通过综合考量这些因素，我们能够准确地判断数据表在不同时间段的热度，以及热分区、冷分区、温分区的分布情况。基于这些分析，我们制定了一套规则来确定数据表的分级。对于 top 数据表，我们采用人工判定方式以确保准确性，并经过与业务部门的验证，证明判定准确率较高。而对于非 top 数据表，我们则采用批量处理方式。首先识别并排除无热度的“僵尸表”，将其置于最低等级或进行治理处理。对于剩余的数据表，我们根据 top 数据表的经验制定自动化规则进行分级。此外，我们还在探索更加智能化的数据分级方法。利用基线染色技术，我们可以分析数据表与基线表的关联程度、热度分区情况以及整个血缘关系网络的结构。基于这些信息，我们可以制定更加精细的分级规则。未来，随着数据训练数据的不断增加，我们计划采用如 XGBoost 等机器学习算法来实现自动化的数据分级。这将大大提高分级效率并降低人为误差。最后，在数据分类方面，我们也计划利用 ChatGPT 等自然语言处理技术来分析业务文档中的文本信息。通过维护分类和关键词的映射关系，并结合自动分词和维表映射技术，我们将实现自动化的数据分类方案，进一步推进数据治理工作的进程。
分享嘉宾
INTRODUCTION
HelenMa
上海沐瞳信息科技有限公司
数据仓库负责人
学历：华东理工大学 运筹学硕士
工作履历：
2023～至今，沐瞳；
2019-2023，哔哩哔哩，数仓开发；
2015-2019，美团点评，数仓开发；
2011-2015，新蛋网，数据挖掘。
点个在看你最好看
SPRING HAS ARRIVED