查看原文
其他

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

李响 DataFunSummit
2024-09-10

导读 本文将为大家带来火山引擎 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年的数据领域相关经验,有电商、银行、出行、互金多个行业数据领域经历,对于数据治理和数据体系有深入的研究和实践。

往期推荐


大数据分析平台之 OLAP 架构的最佳实践

数据分析及指标中台核心能力建设实践

大模型的高效训练和部署技术卷出新高度!

小米数据中台建设实践赋能业务增长!

360跨模态视频开放式标签挖掘技术实践分享

当因果推断遇上了医学研究

第三代指标平台:真正实现“管、研、用”一体化

企业如何构建指标平台并实现智能分析?

业务理解和逻辑推理是金融大模型运转的动力

度小满金融大模型技术创新与应用探索

阿里巴巴长文档推荐系统在企业数字化中的应用

重塑数据架构:云器Lakehouse如何简化组装式架构实现性能与成本的精益平衡

京东零售数据可视化平台产品实践与思考

模型与算法在石油产业链的优化应用实践

点个在看你最好看

继续滑动看下一个
DataFunSummit
向上滑动看下一个

您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存