字节在电商领域的数据治理体系和实践

导读 本文将为大家带来火山引擎 DataLeap 在电商平台的数据治理体系及实践，全文将分为5个板块:

1. 电商数据业务面临的挑战；

2. 稳定性体系化；

3. 成本治理体系化；

4. 工具效率体系化；

5. 总结与展望。

分享嘉宾｜李响 火山引擎 数据技术专家

编辑整理｜吴旺旺

内容校对｜李瑶

出品社区｜DataFun

---

01

电商数据业务面临的挑战

1.数据治理面临的问题

一些电商平台数据治理面临的问题，可以总结为如下五大方面：

第一是SLA质量问题。这是数据治理面对的主线问题，随着业务不断发展和成熟，对于SLA稳定性、数据质量、口径一致性要求越来越高。

第二，模型稳定性不足。因为该电商平台最初属于兴趣电商模式，很多模型都处于持续探索中，行业内没有一个成熟体系，业务频繁变动，历史模型设计不能灵活适配新业务需求，通常采用打补丁的形式解决，耦合比较严重，导致模型产出时效性差，消费成本高。

第三，资源成本失控。从该电商平台基本数据的分析可以看出，业务数据膨胀速度非常快，大数据资源的成本占比很高，目前整个行业都在降本增效的背景下，企业对于成本优化的诉求会越来越高。

第四，治理效率低。前期数据治理人力和资源成本都比较高、进度慢、很难达到预期。

第五，数据治理缺乏体系。由于问题越来越复杂，单点难以解决，重复治理次数越来越多，很多治理动作缓解，并没有从根本上解决问题。

以上是一些电商平台数据治理初期面临的一些主要问题，也是每个数据团队都会遇到的普遍问题。

2.超大规模数仓带来的挑战

2021年底至2022年初，一些头部电商平台规模逐渐成型，形成了超大规模数仓，相应的也对数据治理带来了一些挑战。

主要分为4个部分：

• 挑战一：劣化速度快。每月净增多个任务，任务增速快，资源消耗呈指数级增长，其中核心的对立点是治理速度和劣化速度。

• 挑战二：治理资源少。业务对数据要求非常高，而相关的治理资源有限。

• 挑战三：规范抽象难。全域兴趣电商业务场景复杂，是一个新兴业务，规范抽象难以灵活的适应多变场景，越细致的规范在大规模的数仓场景越难以落地，如何平衡规范和灵活业务支持，是需要解决的一个挑战。一般我们可能不太会追求定制细致化的规范，而是采用循序渐进的方式去解决规范落地难的问题。

• 挑战四：优化难度高。当数据规模上升到一定量级，很多常规的优化手段无法实现，技术优化能力要求高，甚至有不少任务是一天分区几万亿行的数据运算，单stage的shuffle量达几百TB。

3.电商平台数据治理顶层框架

对此火山引擎DataLeap对数据治理的整体建设思路：建设体系化的治理策略，沉淀方法体系、价值体系、标准体系；从数据治理到数据管理+数据治理，实现标准化、数字化和产品化的全面体系。具体可分为几个域：

• 基础域，包括元数据数仓和治理度量体系。

• 过程域，是治理的一个流程。

• 执行域，包括数据成本治理、稳定性数据治理，数据治理工具等。

• 目标域，目标和度量体系相辅相成。

• 规范域，包括研发规范、运维规范、资产管理规范、安全规范等。

4.打造体系化的数据治理架构，驱动分布式自主治理

电商业务的特色，是要做分布式自主治理，因为仅仅依赖治理团队推动非常困难，因此应该打造体系化的数据治理架构。关于体系化的数据治理架构定义，首先体系是一个科学术语，一般指一定范围或同类事物按照一定秩序和联系的组合整体，体系化数据治理是把某个方向治理形成一个整体有序的闭环框架，具备合理的顶层治理设计，有效的治理运营策略以及高效的底层技术支撑。体系化数据治理的三个体系包括：

• 稳定性体系

• 成本体系

• 效率工具体系

三者是互相支撑的关系，效率工具会去支撑稳定性和成本体系。

驱动分布式自助治理首先需要思考3个问题：

• 开发同学为什么要做数据治理？

一般情况下，会有一个内部驱动力和外部推动力，内部驱动力可能是进行优化或者SIO达不到要求等，外部推动力可能是健康分的排名等，综合起来变成了一个开发同学治理的驱动。

• 开发同学的治理工作量大不大？

这是关键问题，一是收益，二是成本。投入产出比是开发同学做治理的核心考虑点，工作量方面做到自动化数据治理。

• 治理同学&上级协助推动工作量有多大？

数据治理会有一个自上而下的推动，上级会做整个团队治理进度的推动。如果自己推动或是上级协助推动工作量非常大，那么效果也会不好，所以需要将工作量降低，需要有一个有效精准衡量的北极星指标，这样会在整个推进过程中比较清晰直观地看到进度和效果。

02

稳定性治理体系

1.超大规模数仓的稳定性挑战

• 电商业务的SLA要求高。例如某电商数据产品，该产品要求数据是9点产出，但是整个电商链路还会依赖短视频数仓、直播数仓，整个链路非常长，并且时间要求9点产出，中间的计算时间非常短。

• 新增&修改任务数量大。会造成整个资源的波动，例如突然新上线几个特别大的任务，整个队列的资源就会极度紧张。

• 任务管理工作量大。在几个万个任务的时候，需要匹配优先级，整个的管理工作量非常大。

• 任务的优先级灵活多变。因为业务场景会比较复杂，没有固定的优先级，会出现灵活多变的情况。

• 堆资源暴力解决运行慢的问题。由于业务压力比较大，通过堆资源的方式，对于资源利用率和资源使用情况来说是一个比较大的挑战。

• 调优能力要求高。

2.基于业务应用场景的分级体系

业务应用场景的分级体系由三个部分组成，第一个是应用评级，例如某个产品、看板或某个业务线内部的数据产品，都会有一个应用评级，评级为超核心、核心、高优先。在评级的时候会跟应用做匹配，因为每个应用可能会有多个SLA时间。经过构建级别、应用、SLA分级这三个组成的分级体系，就可以生成应用标签，确定构建底层基础。有了不同的分级应用标签，那么接下来看一下如何利用这些标签。

3.基于血缘能力的任务打标

基于血缘能力做任务打标，流程如下：

1. 生成虚拟尾任务节点，挂载依赖模块；

2. 基于血缘能力，在尾任务节点打上应用标签；

3. 依赖强大的血缘能力，完成上游链路所有任务打标；

4. 根据重要性迁移到核心队列资源保障；

5. 每日通过血缘刷新链路标签；

6. V2版血缘链路支持T+1和T+2的识别。

4.业务应用与保障资源匹配关系

业务应用分解：

• P0级应用：对外数据应用、高层核心看板（驾驶舱）

• P1级应用：对内数据应用、核心看板应用、算法模型应用

• P2级应用：日常运营看板

队列资源金字塔分级：

• 核心：P0应用，AMD+SSD高性能计算机队列（150%+）。

• 高优作业：P1应用，INTEL+SSD计算队列（100%）。

• 普通作业：P2应用，混部计算队列（80%）。

这样资源和应用可以建立比较好的匹配关系。

5.SLA申报保障流程

首先申报核心应用，然后数据治理团队做判断，对业务定级并进行技术评估，在业务定级时，主要评估业务的重要性。技术评估是必须要达到的，例如链路大任务评估（无超过一小时任务）、任务运行时长波动性评估（波动不能过大）、任务预设buffer评估、任务事故buffer评估。

如果这些要求都满足，就会分配尾任务，架设试运行基线，试运行一周，如果一周时间仍然满足基础的要求，就正式值班基线、全链路打标、稳定队列保障。最终试运行一个月，如果仍然达标符合要求，就由专业治理团队进行SLA等级评估，全链路SLA签署，最终达到线上持续的保障状态。

整个流程分为两部分，前面部分是自主治理，治理团队会提供一些通用方法。后面部分以治理团队为主做专业保障。整个逻辑是以治理团队专业保障为驱动力，加强准入流程，提升整个团队的治理稳定性意识，引导开发同学自主治理。

6.二维分级模型和收益

传统的任务分级是单维度的，只从一个维度分级，是否能较好地识别某个应用/任务的重要性呢？

业务重要性和SLA稳定性并不是一个线性的关系，因此需要二维分级。比如数据产品，属于第一象限，业务重要性高，且SLA稳定性要求高，那么就要对其进行全流程重保，专家优化，分配高优资源，制订起夜值班，提供保障。而对于业务重要性高，但SLA稳定性要求不是很高的情况，则更倾向于白天去解决问题，有比较充足的时间，但要有质量审核。

整体收益包括：

• 之前比较散乱的SLA管理，面对几万任务优先级运维，当前只需要管理30+的核心应用标签流程，治理运维工作大大降低。

• 通过血缘反向递推，30+的核心应用覆盖了全链路35%的任务数，治理团队重点关注保障。

• 研发同学能够清晰地看到任务被哪些核心应用依赖，在变更时更好评估，提升变更质量。

• 通过开发平台的标签筛选能力，很灵活的匹配资源，T+2的血缘识别，更好地实现资源节约。

• 拓展能力：资损标签，运行时间，灾备降级等标签。

通过应用血缘标签和优先级二维分级法进行管理，在管理成本和灵活度上取得了一个比较好的平衡。

03

成本治理体系化

1.业务高速增长的成本挑战

成本治理的挑战概括为4个方面：

• 第一，业务需求压力大。在业务高速峰值增长和降本增效的背景下，怎样平衡业务需求和成本的增长，是一大挑战。

• 第二，成本较高。

• 第三，成本意识薄弱。因为围绕业务推进业务价值，业务发展，对于成本的意识会比较薄弱。

• 第四，治理意愿低。因为工作量和时间的问题，投入精力会比较少。

2.建立数字化的成本模型，提升成本意识

为了提升成本意识，火山引擎DataLeap帮助一些电商平台建立了数字化的成本模型。以前在成本优化收益评估时，经常说优化具体数量是多少PB的存储资源，计算资源消耗减少量，减少存储TB数量，但对于不同组件资源的成本很难横向对齐。

通过对计算资源(yarn)、大数据存储(hdfs)、在线存储(ch/es/mysql)、其它资源成本(组件、应用)等资源进行量化整合归一化到真实的成本金额，计算单位成本，与业务挂钩，更直观，同时也可以横向对比。

这样可以量化研发同学的资产成本，提升成本意识；强化治理的收益，提升治理积极性。

3.计算成本账单模型

计算成本是数据第一大成本，其特点包括，YARN按quota收费，无论使用率多少，成本不变；离线计算周期特性，凌晨高峰期，白天低谷；YARN有多种机型，cpu和内存共有6个计费项。

• 资源归一化模型

将6个计费项目按照费用比例，折算到一个计费项目(cpu)。

• 分级定价模型

分级系数：高峰期1.5，低谷期0.5，平峰期1；

队列系数：依据资源归一化模型系数；

定价：真实成本/总资源消耗=单价（按照季度调整单价）。

模型带来的收益包括：

• 明确计算资源成本单价。

• 较为清晰地看到子方向/个人的成本构成，鼓励自主治理。

• 计算成本模型能较好的引导治理方式。

治理方式：

①优化top任务，降低资源申请/提升利用率

②下线无效/低ROI任务

③任务编排，高峰期任务移到低谷期运行

④任务从高成本队列迁移到低成本队列

治理团队核心工作从推动研发同学治理，变成帮助研发同学，准确识别TOP治理收益，推荐最优治理策略。

4.成本归因账单

建立清晰的成本制单和归因模型，让业务人员很容易进行成本诊断。通过周/月度账单功能帮助owner按周/月粒度感知成本变化情况和变化归因，以卡片方式推送用户。

• 帮助开发同学看清成本和治理目标；

• 支持开发同学自主分析成本变化原因，及时发现/预防成本恶化；

• 帮助开发同学拆解治理目标，规划可达成目标的治理路径；

• 建立成本心智，感知治理目标和实际治理收益的对比情况。

模型上线经过验证后，任务自主治理收益量提升了200%，占总体治理收益的65%。

5.技术优化提升资源利用率

在技术方面火山引擎DataLeap研发人员做了如下一些优化：

• HBO：建设电商任务个性化的自动调参能力。

• Shuffle优化：针对shuffle阻塞问题，进行打散/限流优化。

• 读取模型优化：读取扫描万亿级别的大表的任务优化。

• 虚拟core精细化：cpu虚拟化，能精确到千分之一核，实现灵活分配。

• 超发能力：底层container超发，队列超发等技术。

最终收益价值：CPU利用率从60%提升到了78%，极大节省了资源成本，且在持续提升中。

04

工具效率体系化

1.体系化定义治理生命周期

数据治理阶段有较多的划分方法，结合经验和该电商平台的实际情况，我们以数据开发流程的来划分事前、事中、事后。

• 事前预防：通过系统化的方式，上线/调试前的检测；核心是通过工具化的方法事前预防各种问题的产生，主要围绕增量/变更任务。

• 事中监控：任务日常运行，实时预警，同时也涵盖实时问题诊断和复盘；事中的治理都是有时效要求，必须在一定时间内(短期)完成。

• 事后优化：深度分析现状，通常以专项的形式进行数据治理；事后的治理一般需要深度治理，组织专项制定计划，主要针对存量任务，因此周期一般较长，收益也比较清晰。

上图中右侧是治理生命周期中各个阶段的治理项。

2.事前管控平台Code-CT

事前的检查包括：队列检查、监控配置、SLA重评估、探查报告、质量规范、空值检查、调试规范、代码规范、参数规范、语法规范、逆向依赖、模型规范、旧表禁用、大表依赖。

• 质量提升、事故降低：有效的避免数据事故以及报警，在实践中不断打磨，贴合抖音电商业务场景。

• 效率提升，常态治理：一些基础规范无需推动治理，经过自然迭代，不符合规范的情况逐步降低。

• 插件配置，通用规则：建立通用检测规则库，实现规则配置化。

这里有一些拓展，比如模型重构的时候，上线时通过旧表禁用，对下游切换效率带来比较大的帮助。

最终效果，该电商平台数据生效规则37个，Q1季度code-ct触发规则检测47985次，提醒6241次，拦截3897次，结合稳定性治理，夜间报警量下降80%。

3.事中巡检、事件触发平台

事中的特点有两个，一个是触发式的实时巡检，一旦有异常及时发出，研发人员立刻接到通知处理，需要当天调度前处理完。另一个是调度前巡检，大部分规则在这个阶段生效，在22:00/23:00时间，进行跑批前巡检，规避第二天早上跑批风险，需要当天调度前处理完。

• 调度中：主要依赖开发平台的基础能力。

• 调度后巡检：扫描任务的运行状态，针对识别潜在oom、数据倾斜、异常运行时长隐患，进行预警，一般需要48小时处理完。

4.事后一站式治理平台

事后治理主要聚焦在执行阶段的工具化，面向开发人员的一站式治理平台。它实现的功能包括：统一工作视图、统一操作入口、统一消息通知以及一键治理。工作视图和操作入口，能够降低成本，避免治理分散化。消息通知，主要是培养同学的治理意识和习惯。一键治理用于提高治理的效率，降低治理风险。

5.治理项分级定义

P0治理项，核心事中的治理项目，特点是很强的时效性，短周期必须处理完成，一般当天处理或者48小时内，未处理有升级机制。属于常态化治理。

P1治理项，核心事后的治理项目，专项推进治理，以周期形式推进，符合研发同学集中治理的习惯，一般周期为2周或者1个月，核心关注治理完成率。属于周期式治理。

P2治理项目，支持灵活的治理项目，不强制要求治理周期，鼓励有意愿的同学主动治理；同时支持灵活自主治理，也能支持各种类型治理任务。属于灵活式治理。

6.一键治理，提升治理效率提升

一键式治理主要有加入白名单和一键治理，希望所有的治理操作都能达到一键治理。基于pipeline流水线功能，通过调用数据产品API接口，提升治理效率。

举两个实例，第一个实例是任务下线，会先回收权限，观察三天，三天以后做任务正式下线，接着再观察7天，7天之后做表的删除动作，然后在回收站里再观察7天，最后对回收站进行彻底删除。研发人员只需要点一键治理，然后自动去做流程，如果有问题才会通知，如果没有问题就直接告知成功。

第二个实例是任务调优，我们首先具备诊断能力，做推荐参数，然后在测试工厂中验证，最后生成测试报告，如果符合预期，就可以一键代码上线。

一键治理是自动化治理的核心，治理团队致力于不断提升治理项的自动化水平，当前已经具备一定的代码生成能力，未来在治理和开发效率提升场景均有较大的前景。

7.全生命周期联动

事前、事中、事后，它们是具有关联性的。事中治理，有巡检/事件触发平台。该电商平台希望把更多的规则沉淀到事前治理，因为这样治理成本是最低的。事中事后治理项融合，实现了一体化治理。事中治理的治理项一般都是p0的，和p1治理项集中在一站式治理平台上，形成整体的视图。在事中治理，会考核治理的完成率，对不符合预期的进行再调试，会采取一些策略，比如提醒、拦截以及升级审批等。

05

总结与展望

1.治理心得

• 加强治理分析(2/8法则)

• 重视治理运营

• 关键指标驱动

• 先止损降低污染速度

• 适当接受先污染后治理

• 循序渐进，不追求一步到位

• 做好顶层设计

2.跨团队学习(综合能力)

能否将数据治理当成一个业务来运营？为了更好地完成治理工作，跨团队的学习是很重要的。

治理数据分析，通过借鉴数据科学的知识对治理进行数据分析，通过借鉴基础架构平台团队经验对成本治理模型进行思考。通过借鉴电商运营产品的经验建设一站式治理平台，例如成本账单的归因。hbo调优策略借鉴算法A/B实验，更好地评估调优策略效果。

3.未来展望

• 设计新版本健康分模型，解决健康分通用问题(健康分版本问题、模型短板效应)

• 业务成本模型，成本分摊到业务上，结合资产消费情况，评估应用价值ROI。

• 数据安全体系化、数据质量体系化、数据开发流程体系化。

• 拥抱前沿技术，如大语言模型。

以上就是本次分享的内容，谢谢大家。

分享嘉宾

INTRODUCTION

李响

火山引擎

数据技术专家

现负责抖音电商数据治理工作，超过10年的数据领域相关经验，有电商、银行、出行、互金多个行业数据领域经历，对于数据治理和数据体系有深入的研究和实践。

往期推荐

点个在看你最好看