“双十一”电商大促脚步渐近，各大平台的战火又将燃起。随着数据量增大， 数仓规模可到EB级别，任务数达数万，面对大规模的数据处理任务，复杂的处理链路与层次结构，数据团队在 数据SLA、稳定性 等层面面临较大的压力。 一套有效、可靠的数据治理体系，是“双11”等业务关键场景中数据保障的基石。
本文来源于 火山引擎DataLeap 数据治理实践，将从 电商数据业务面临的挑战、稳定性体系化、成本治理体系化、工具效率体系化、总结与展望 几个方面，介绍一站式数据治理思路以及在电商平台中的应用实践。
/ 数据治理面临的问题 /
一些电商平台数据治理面临的问题，可以总结为如下五大方面：
第一，SLA质量问题。 这是数据治理面对的主线问题，随着业务不断发展和成熟，对于SLA稳定性、数据质量、口径一致性要求越来越高。
第二，模型稳定性不足。 因为该电商平台最初属于兴趣电商模式，很多模型都处于持续探索中，行业内没有一个成熟体系，业务频繁变动，历史模型设计不能灵活适配新业务需求，通常采用打补丁的形式解决，耦合比较严重，导致模型产出时效性差，消费成本高。
第三，资源成本失控。 从该电商平台基本数据的分析可以看出，业务数据膨胀速度非常快，大数据资源的成本占比很高，目前整个行业都在降本增效的背景下，企业对于成本优化的诉求会越来越高。
第四，治理效率低。 前期数据治理人力和资源成本都比较高、进度慢、很难达到预期。
第五，数据治理缺乏体系。 由于问题越来越复杂，单点难以解决，重复治理次数越来越多，很多治理动作缓解，并没有从根本上解决问题。
以上是一些电商平台数据治理初期面临的一些主要问题，也是每个数据团队都会遇到的普遍问题。
/ 超大规模数仓带来的挑战 /
2021年底至2022年初，一些头部电商平台规模逐渐成型，形成了超大规模数仓，相应的也对数据治理带来了一些挑战。
主要分为4个部分：
● 挑战一：劣化速度快。 每月净增多个任务，任务增速快，资源消耗呈指数级增长，其中核心的对立点是治理速度和劣化速度。
● 挑战二：治理资源少。 业务对数据要求非常高，而相关的治理资源有限。
●
挑战三：规范抽象难。 全域兴趣电商业务场景复杂，是一个新兴业务，规范抽象难以灵活的适应多变场景，越细致的规范在大规模的数仓场景越难以落地，如何平衡规范和灵活业务支持，是需要解决的一个挑战。一般我们可能不太会追求定制细致化的规范，而是采用循序渐进的方式去解决规范落地难的问题。
●
挑战四：优化难度高。 当 数据规模上升到一定量级，很多常规的优化手段无法实现，技术优化能力要求高，甚至有不少任务是一天分区几万亿行的数据运算，单stage的shuffle量达几百TB。
/ 电商平台数据治理顶层框架 /
对此火山引擎DataLeap对数据治理的整体建设思路： 建设体系化的治理策略，沉淀方法体系、价值体系、标准体系；从数据治理到数据管理+数据治理，实现标准化、数字化和产品化的全面体系。具体可分为几个域：
● 基础域 ，包括元数据数仓和治理度量体系。
● 过程域， 是治理的一个流程。
● 执行域， 包括数据成本治理、稳定性数据治理，数据治理工具等
● 目标域 ， 目标和度量体系相辅相成。
● 规范域 ， 包括研发规范、运维规范、资产管理规范、安全规范等
/ 打造体系化的数字治理架构，驱动分布式自主治理 /
电商业务的特色，是要做分布式自主治理，因为仅仅依赖治理团队推动非常困难，因此应该打造体系化的数据治理架构。关于体系化的数据治理架构定义，首先体系是一个科学术语，一般指一定范围或同类事物按照一定秩序和联系的组合整体，体系化数据治理是把某个方向治理形成一个整体有序的闭环框架，具备合理的顶层治理设计，有效的治理运营策略以及高效的底层技术支撑。体系化数据治理的三个体系包括：
● 稳定性体系
● 成本体系
● 效率工具体系
三者是互相支撑的关系，效率工具会去支撑稳定性和成本体系。
驱动分布式自助治理首先需要思考3个问题：
● 开发同学为什么要做数据治理？
一般情况下，会有一个内部驱动力和外部推动力，内部驱动力可能是进行优化或者SIO达不到要求等，外部推动力可能是健康分的排名等，综合起来变成了一个开发同学治理的驱动。
● 开发同学的治理工作量大不大？
这是关键问题，一是收益，二是成本。投入产出比是开发同学做治理的核心考虑点，工作量方面做到自动化数据治理
● 治理同学&上级协助推动工作量有多大？
数据治理会有一个自上而下的推动，上级会做整个团队治理进度的推动。如果自己推动或是上级协助推动工作量非常大，那么效果也会不好，所以需要将工作量降低，需要有一个有效精准衡量的北极星指标，这样会在整个推进过程中比较清晰直观地看到进度和效果。
/ 超大规模数仓的稳定性挑战 /
● 电商业务的 SLA 要求高。 例如某电商数据产品，该产品要求数据是9点产出，但是整个电商链路还会依赖短视频数仓、直播数仓，整个链路非常长，并且时间要求9点产出，中间的计算时间非常短。
● 新增&修改任务数量大。 会造成整个资源的波动，例如突然新上线几个特别大的任务，整个队列的资源就会极度紧张。
● 任务管理工作量大。 在几个万个任务的时候，需要匹配优先级，整个的管理工作量非常大。
● 任务的优先级灵活多变。 因为业务场景会比较复杂，没有固定的优先级，会出现灵活多变的情况。
● 堆资源暴力解决运行慢的问题。 由于业务压力比较大，通过堆资源的方式，对于资源利用率和资源使用情况来说是一个比较大的挑战。
● 调优能力要求高。
/ 基于业务应用场景的分级体系 /
业务应用场景的分级体系由三个部分组成，第一个是应用评级，例如某个产品、看板或某个业务线内部的数据产品，都会有一个应用评级，评级为超核心、核心、高优先。在评级的时候会跟应用做匹配，因为每个应用可能会有多个SLA时间。经过构建级别、应用、SLA分级这三个组成的分级体系，就可以生成应用标签，确定构建底层基础。有了不同的分级应用标签，那么接下来看一下如何利用这些标签。
/ 基于血缘能力的任务打标 /
基于血缘能力做任务打标，流程如下：
- 生成虚拟尾任务节点，挂载依赖模块；
- 基于血缘能力，在尾任务节点打上应用标签；
- 依赖强大的血缘能力，完成上游链路所有任务打标；
- 根据重要性迁移到核心队列资源保障；
- 每日通过血缘刷新链路标签；
- V2版血缘链路支持T+1和T+2的识别。
/ 业务应用与保障资源匹配关系 /
业务应用分解：
● P0级应用：对外数据应用、高层核心看板（驾驶舱）
● P1级应用：对内数据应用、核心看板应用、算法模型应用
● P2级应用：日常运营看板
队列资源金字塔分级：
● 核心：P0应用，AMD+SSD高性能计算机队列（150%+）
● 高优作业：P1应用，INTEL+SSD计算队列（100%）
● 普通作业：P2应用，混部计算队列（80%）
这样资源和应用可以建立比较好的匹配关系。
/ SLA申报保障流程 /
首先申报核心应用，然后数据治理团队做判断，对业务定级并进行技术评估，在业务定级时，主要评估业务的重要性。技术评估是必须要达到的，例如链路大任务评估（无超过一小时任务）、任务运行时长波动性评估（波动不能过大）、任务预设buffer评估、任务事故buffer评估。
如果这些要求都满足，就会分配尾任务，架设试运行基线，试运行一周，如果一周时间仍然满足基础的要求，就正式值班基线、全链路打标、稳定队列保障。最终试运行一个月，如果仍然达标符合要求，就由专业治理团队进行SLA等级评估，全链路SLA签署，最终达到线上持续的保障状态。
整个流程分为两部分，前面部分是自主治理，治理团队会提供一些通用方法。后面部分以治理团队为主做专业保障。整个逻辑是以治理团队专业保障为驱动力，加强准入流程，提升整个团队的治理稳定性意识，引导开发同学自主治理。
/ 二维分级模型和收益 /
传统的任务分级是单维度的，只从一个维度分级，是否能较好地识别某个应用/任务的重要性呢？
业务重要性和SLA稳定性并不是一个线性的关系，因此需要二维分级。比如数据产品，属于第一象限，业务重要性高，且SLA稳定性要求高，那么就要对其进行全流程重保，专家优化，分配高优资源，制订起夜值班，提供保障。而对于业务重要性高，但SLA稳定性要求不是很高的情况，则更倾向于白天去解决问题，有比较充足的时间，但要有质量审核。
整体收益包括：
● 之前比较散乱的SLA管理，面对几万任务优先级运维，当前只需要管理30+的核心应用标签流程，治理运维工作大大降低。
● 通过血缘反向递推，30+的核心应用覆盖了全链路35%的任务数，治理团队重点关注保障。
● 研发同学能够清晰地看到任务被哪些核心应用依赖，在变更时更好评估，提升变更质量。
● 通过开发平台的标签筛选能力，很灵活的匹配资源，T+2的血缘识别，更好地实现资源节约。
● 拓展能力：资损标签，运行时间，灾备降级等标签。
通过应用血缘标签和优先级二维分级法进行管理，在管理成本和灵活度上取得了一个比较好的平衡。
/ 业务高速增长的成本挑战 /
成本治理的挑战概括为4个方面：
● 第一，业务需求压力大。 在业务高速峰值增长和降本增效的背景下，怎样平衡业务需求和成本的增长，是一大挑战。
● 第二，成 本较高 。
● 第三，成本意识薄弱。 因为围绕业务推进业务价值，业务发展，对于成本的意识会比较薄弱。
● 第四，治理意愿低。 因为工作量和时间的问题，投入精力会比较少。
/ 建立数字化的成本模型，提升成本意识 /
为了提升成本意识，火山引擎DataLeap帮助一些电商平台建立了数字化的成本模型。以前在成本优化收益评估时，经常说优化具体数量是多少PB的存储资源，计算资源消耗减少量，减少存储TB数量，但对于不同组件资源的成本很难横向对齐。
通过对计算资源(yarn)、大数据存储(hdfs)、在线存储(ch/es/mysql)、其它资源成本(组件、应用)等资源进行量化整合归一化到真实的成本金额，计算单位成本，与业务挂钩，更直观，同时也可以横向对比。
这样可以量化研发同学的资产成本，提升成本意识；强化治理的收益，提升治理积极性。
/ 计算成本账单模型 /
计算成本是数据第一大成本，其特点包括，YARN按quota收费，无论使用率多少，成本不变；离线计算周期特性，凌晨高峰期，白天低谷；YARN有多种机型，cpu和内存共有6个计费项。
● 资源归一化模型
将6个计费项目按照费用比例，折算到一个计费项目(cpu)。
● 分级定价模型
分级系数：高峰期1.5，低谷期0.5，平峰期1；
队列系数：依据资源归一化模型系数；
定价：真实成本/总资源消耗=单价（按照季度调整单价）。
模型带来的收益包括：
● 明确计算资源成本单价。
● 较为清晰地看到子方向/个人的成本构成，鼓励自主治理。
● 计算成本模型能较好的引导治理方式。
治理方式：
①优化top任务，降低资源申请/提升利用率
②下线无效/低ROI任务
③任务编排，高峰期任务移到低谷期运行
④任务从高成本队列迁移到低成本队列
治理团队核心工作从推动研发同学治理，变成帮助研发同学，准确识别TOP治理收益，推荐最优治理策略。
/ 成本归因账单 /
建立清晰的成本制单和归因模型，让业务人员很容易进行成本诊断。通过周/月度账单功能帮助owner按周/月粒度感知成本变化情况和变化归因，以卡片方式推送用户。
● 帮助开发同学看清成本和治理目标；
● 支持开发同学自主分析成本变化原因，及时发现/预防成本恶化；
● 帮助开发同学拆解治理目标，规划可达成目标的治理路径；
● 建立成本心智，感知治理目标和实际治理收益的对比情况。
模型上线经过验证后，任务自主治理收益量提升了200%，占总体治理收益的65%。
/ 技术优化提升资源利用率 /
在技术方面火山引擎DataLeap研发人员做了如下一些优化：
● HBO：建设电商任务个性化的自动调参能力。
● Shuffle优化：针对shuffle阻塞问题，进行打散/限流优化。
● 读取模型优化：读取扫描万亿级别的大表的任务优化。
● 虚拟core精细化：cpu虚拟化，能精确到千分之一核，实现灵活分配。
● 超发能力：底层container超发，队列超发等技术。
最终收益价值：CPU利用率从60%提升到了78%，极大节省了资源成本，且在持续提升中。
/ 体系化定义治理生命周期 /
数据治理阶段有较多的划分方法，结合经验和该电商平台的实际情况，我们以数据开发流程的来划分事前、事中、事后。
● 事前预防： 通过系统化的方式，上线/调试前的检测；核心是通过工具化的方法事前预防各种问题的产生，主要围绕增量/变更任务。
● 事中监控： 任务日常运行，实时预警，同时也涵盖实时问题诊断和复盘；事中的治理都是有时效要求，必须在一定时间内(短期)完成。
● 事后优化： 深度分析现状，通常以专项的形式进行数据治理；事后的治理一般需要深度治理，组织专项制定计划，主要针对存量任务，因此周期一般较长，收益也比较清晰。
上图中右侧是治理生命周期中各个阶段的治理项。
/ 事前管控平台Code-CT /
事前的检查包括：队列检查、监控配置、SLA重评估、探查报告、质量规范、空值检查、调试规范、代码规范、参数规范、语法规范、逆向依赖、模型规范、旧表禁用、大表依赖。
● 质量提升、事故降低： 有效的避免数据事故以及报警，在实践中不断打磨，贴合抖音电商业务场景。
● 效率提升，常态治理： 一些基础规范无需推动治理，经过自然迭代，不符合规范的情况逐步降低。
● 插件配置，通用规则： 建立通用检测规则库，实现规则配置化。
这里有一些拓展，比如模型重构的时候，上线时通过旧表禁用，对下游切换效率带来比较大的帮助。
最终效果，该电商平台数据生效规则37个，Q1季度code-ct触发规则检测47985次，提醒6241次，拦截3897次，结合稳定性治理，夜间报警量下降80%。
/ 事中巡检、事件触发平台 /
事中的特点有两个，一个是触发式的实时巡检，一旦有异常及时发出，研发人员立刻接到通知处理，需要当天调度前处理完。另一个是调度前巡检，大部分规则在这个阶段生效，在22:00/23:00时间，进行跑批前巡检，规避第二天早上跑批风险，需要当天调度前处理完。
● 调度中： 主要依赖开发平台的基础能力。
● 调度后巡检： 扫描任务的运行状态，针对识别潜在oom、数据倾斜、异常运行时长隐患，进行预警，一般需要48小时处理完。
/ 事后一站式治理平台 /
事后治理主要聚焦在执行阶段的工具化，面向开发人员的一站式治理平台。它实现的功能包括：统一工作视图、统一操作入口、统一消息通知以及一键治理。工作视图和操作入口，能够降低成本，避免治理分散化。消息通知，主要是培养同学的治理意识和习惯。一键治理用于提高治理的效率，降低治理风险。
/ 治理项分级定义 /
P0治理项，核心事中的治理项目，特点是很强的时效性，短周期必须处理完成，一般当天处理或者48小时内，未处理有升级机制。属于常态化治理。
P1治理项，核心事后的治理项目，专项推进治理，以周期形式推进，符合研发同学集中治理的习惯，一般周期为2周或者1个月，核心关注治理完成率。属于周期式治理。
P2治理项目，支持灵活的治理项目，不强制要求治理周期，鼓励有意愿的同学主动治理；同时支持灵活自主治理，也能支持各种类型治理任务。属于灵活式治理。
/ 一键治理，提升治理效率 /
一键式治理主要有加入白名单和一键治理，希望所有的治理操作都能达到一键治理。基于pipeline流水线功能，通过调用数据产品API接口，提升治理效率。
举两个实例，第一个实例是任务下线，会先回收权限，观察三天，三天以后做任务正式下线，接着再观察7天，7天之后做表的删除动作，然后在回收站里再观察7天，最后对回收站进行彻底删除。研发人员只需要点一键治理，然后自动去做流程，如果有问题才会通知，如果没有问题就直接告知成功。
第二个实例是任务调优，我们首先具备诊断能力，做推荐参数，然后在测试工厂中验证，最后生成测试报告，如果符合预期，就可以一键代码上线。
一键治理是自动化治理的核心，治理团队致力于不断提升治理项的自动化水平，当前已经具备一定的代码生成能力，未来在治理和开发效率提升场景均有较大的前景。
/ 全生命周期联动 /
事前、事中、事后，它们是具有关联性的。事中治理，有巡检/事件触发平台。该电商平台希望把更多的规则沉淀到事前治理，因为这样治理成本是最低的。事中事后治理项融合，实现了一体化治理。事中治理的治理项一般都是p0的，和p1治理项集中在一站式治理平台上，形成整体的视图。在事中治理，会考核治理的完成率，对不符合预期的进行再调试，会采取一些策略，比如提醒、拦截以及升级审批等。
/ 治理心得 /
● 加强治理分析(2/8法则)
● 重视治理运营
● 关键指标驱动
● 先止损降低污染速度
● 适当接受先污染后治理
● 循序渐进，不追求一步到位
● 做好顶层设计
/ 跨团队学习（综合能力）/
能否将数据治理当成一个业务来运营？为了更好地完成治理工作，跨团队的学习是很重要的。
治理数据分析，通过借鉴数据科学的知识对治理进行数据分析，通过借鉴基础架构平台团队经验对成本治理模型进行思考。通过借鉴电商运营产品的经验建设一站式治理平台，例如成本账单的归因。hbo调优策略借鉴算法A/B实验，更好地评估调优策略效果。
/ 未来展望 /
● 设计新版本健康分模型，解决健康分通用问题(健康分版本问题、模型短板效应)
● 业务成本模型，成本分摊到业务上，结合资产消费情况，评估应用价值ROI。
● 数据安全体系化、数据质量体系化、数据开发流程体系化。
● 拥抱前沿技术大模型，Al辅助代码生成，自动代码优化等。
产品介绍
火山引擎大数据研发治理套件DataLeap
一站式数据中台套件，帮助用户快速完成数据集成、开发、运维、治理、资产、安全等全套数据中台建设，帮助数据团队有效的降低工作成本和数据维护成本、挖掘数据价值、为企业决策提供数据支撑。 后台回复数字“2”了解产品。
——相关阅读——
