抖音电商数据治理体系和实践

抖音电商数据治理体系和实践 演讲人：李响火山引擎数据专家 Contents 目录 抖音电商数据简介稳定性体系化成本治理体系化工具效率体系化总结与展望 01抖音电商数据简介 EB级别 存储量 百万core 2020.6 计算资源 数万任务数 生产任务数 1000+ 2020.6 2020.7 2020.8 2020.9 2020.1 2020.11 2020.12 2021.1 2021.2 2021.3 2021.4 2021.5 2021.6 2021.7 2021.8 2021.9 2021.1 2021.11 2021.12 2022.1 2022.2 2022.3 2022.4 2022.5 2022.6 2022.7 2022.8 2022.9 2022.1 2022.11 2022.12 2023.1 2023.2 2023.3 2023.4 月新增任务数 生产任务数（20x） HDFS存储资源增速（40x） 2021.1 2021.12 2022.2 2022.4 2022.6 2022.8 2022.1 2022.12 2023.2 2023.4 20 6 20 8 20 1 2020.12 20 20 2 4 20 6 20 8 20 1 2021.12 20 20 2 4 20 6 20 8 20 1 2022.12 20 20 2 4 20. 20. 20. 21. 21. 21. 21. 21. 22. 22. 22. 22. 22. 23. 23. YARN计算资源增速（60x） 抖音电商爆发式增长，团队规模不断扩大，任务增速快，数据量级巨大，对于数据治理是新的挑战和命题。 2020.8 2020.1 2020.12 2021.2 2021.4 2021.6 2021.8 成本增速超业务增速 场景复杂、架构复杂、增长迅速、数据量大、任务数多 治理问题 SLA质量：质量问题是数据治理面对主线问题，随着业务不断发展和成熟，对于SLA稳定性、数据质量、口径一致性要求越来越高。 模型稳定性不足：业务频繁变动，历史模型设计不能灵活适配新业务，通常用打补丁的方式解决，耦合严重，导致模型产出时效性差，消费成本高。 资源成本失控：业务数据膨胀速度非常快，大数据资源的成本占比很高，降本增效的前提下，对于成本优化的诉求越来越高。 治理效率低：数据治理效率低，很多时候是堆人力在做，成本高进度慢，很难达到预期； 治理缺乏体系：问题越来越复杂，单点难解决，重复治理次数越来越多，很多治理动作是缓解，并没有从根本上解决问题。 以上问题基本上是每个数据团队都会遇到普遍的问题。 规模化的挑战 日新月异，逆水行舟，雪崩效应 挑战一、劣化速度快：任务&表的资产增速越来越快，消耗资源成指数级上升，治理速度vs劣化速度；很容易做了很多治理工作，一看整体健康度不升反降，“按下葫芦起了瓢”。 挑战二、治理资源少：电商开发同学的需求压力很大，在治理方向投入精力有限；研发团队规模大方向多，信息传递和执行力都有很大挑战，治理的同学的推动压力也非常大。 挑战三、规范抽象难：全域兴趣电商业务场景非常复杂，规范抽象难以灵活的适应多变场景，越细致的规范越难以落地；如何平衡规范和灵活业务支持，需要解决的一个挑战。 挑战四、优化难度高：数据规模上升到一个量级，很多常规手段无法实现，技术优化能力要求很高，有不少任务是一天分区几万亿行的数据运算，还有单stage的shuffle量达几百TB。 量变引起质变，传统的治理方法很难应对以上挑战 抖音电商数据治理的顶层框架 抖音电商数据的建设思路是：建设体系化的治理策略，沉淀方法体系、价值体系、标准体系；从数据治理->数据管理+数据治理，实现标准化、数字化和产品化的全面体系。 三大治理体系 质量 稳定性 体系 成本 体系 成本 效率 效率工具体系 打造体系化的数据治理架构，驱动分布式自主治理 什么是体系化数据治理？ 体系是一个科学术语，泛指一定范围内或同类事物按照一定的秩序和联系组合的整体。 体系化就是使事物成为体系的过程。 我们理解体系化数据治理是把某个方向治理形成一个整体有序组合的闭环框架；具备合理的顶层治理设计，有效的治理运营策略，高效的底层技术支撑。 驱动分布式自主治理先思考3个问题： 1、开发同学为什么要做数据治理？ 数据治理为什么难落地？ 内部驱动力+外部推动力 2、开发同学的治理工作量大不大？ 3、治理同学&上级协助推动工作量有多大？ 自动化数据治理 有效精准的北极星指标 开发者视角 治理视角 02稳定性治理体系化 电商业务的SLA要求高 新增&修改任务数量大 任务管理工作量极大 任务优先级灵活多变 堆资源暴力解决运行慢问题 调优能力要求高 光靠治理团队无法解决这些问题，怎样撬动杠杆分布式治理呢？ 构建级别+应用+SLA的分级体系，生成应用标签，确定构建底层基础。 应用评级 业务应用 SLA时间标签 应用A 9AM 超核心:应用A_9AM P0:超核心 超核心:应用A_10AM 应用B 10AM P1:核心 超核心:应用B_10AM 应用C 11AM 核心:应用C_11AM P2:高优 应用D 12AM 高优:应用D_12AM 打标流程 任务1任务2任务3任务4 T+2 T+2 T+1 T+1 1.生成虚拟尾任务节点，挂载依赖模块； 2.在尾任务节点打上应用标签； 全链路打标签 模块A模块B 3.依赖强大的血缘能力，完成上游链路所有任务打标； 4.根据重要性迁移到核心队列资源保障； 5.每日通过血缘刷新链路标签； 6.V2版血缘链路支持T+1和T+2的识别。 任务标签 T+2 超核心:应用A_9AM 尾任务 T+1 核心 【P0应用】AMD+SSD高性能计算队列 （150%+） 高优作业 普通作业 【P2应用】混部计算队列 （80%） 业务应用分级 队列资源金字塔分级 对外数据应用（罗盘）高层核心看板（驾驶舱） P0级应用 对内数据应用核心看板应用 算法模型应用 P1级应用 匹配 日常运营看板 P2级应用 全链路SLA签署 SLA等级评估 自主治理专业保障（治理团队） 评估 核心应用 试运行一周 运行一个月 通过 达标 达标 稳定队列保障 全链路打标 正式值班基线 试运行基线 尾任务 技术评估 业务定级 持续保障 业务定级： 评估业务重要性 如果SLA破线，影响大小 技术评估： 链路大任务评估（无超过1小时任务） 任务运行时长波动性评估 任务预警buffer评估 任务事故buffer评估 以治理团队专业保障为驱动力，加强准入流程，提升整个团队的治理稳定性意识，引导开发同学主动治理。 问题思考：传统的任务分级是单纬度；只从一个维度分级，是否能较好识别某个应用/任务的重要性？ SLA稳定性 收益 1、之前比较散乱的SLA管理，面对几万任务优先级运维，当前只需要管理30+ 例：公共看板 稳定资源自主优化标准监控 低 低优资源自主保障 例：个人看板 高例：数据产品 全流程重保专家优化高优资源起夜值班 高 质量审核日常值班 例：资损链路 低 业务重要性 的核心应用标签流程，治理运维工作大大降低。 2、通过血缘反向递推，30+的核心应用覆盖了全链路35%的任务数，治理团队重点关注保障。 3、对于研发同学来，能很清晰看到，任务被哪些核心应用依赖，在变更时候更好评估，提升变更质量。 4、通过开发平台的标签筛选能力，很灵活的匹配资源，T+2的血缘识别，更好的实现资源节约。 5、拓展能力：资损标签，运行时间，灾备降级等标签。 通过应用血缘标签和优先级二维分级法进行管理，在管理成本和灵活度取得一个比较好的平衡。 二维分级法（重要度） 03成本治理体系化 成本四大挑战 业务高速发展和降本增效背景下，如何平衡业务需求和成本的增长？ 业务需求压力大 成本失控 成本意识薄弱 治理意愿低 以前成本优化的收益评估时候，经常说优化xxPB的存储资源，计算资源消耗减少xx%/xxcore*h，ch减少存储 xxTB；但对于不同组件资源的成本很难横向对齐。 GMV单位金额成本 （北极星指标） 通过归一化到真实的成本金额，与业务 单位成本 挂钩，更直观，也可以横向对比。 计算资源 （yarn） 大数据存储 （hdfs） 在线存储 （ch/es/mysql） 其它资源成本 （组件、应用） 量化研发同学的资产成本，提升成本意识；强化治理的收益，提升治理积极性 收益 计算成本特点 计算成本是数据第一大成本 YARN按quota收费，无论使用率多少，成本不变。 离线计算周期特性，凌晨高峰期，白天低谷。 YARN有多种机型，cpu和内存共有6个计费项 明确计算资源成本单价。 较为清晰看到子方向/个人的成本构成，鼓励自主治理。 资源归一化模型 计算成本模型能较好的引导治理方式： 治理方式 将6个计费项目按照费用比例，折算到一个计费项目（cpu） 分级定价模型 分级系数：高峰期1.5，低谷期0.5，平峰期1 队列系数：依据资源归一化模型系数 ①优化top任务，降低资源申请/提升利用率 ②下线无效/低ROI任务 ③任务编排，高峰期任务移到低谷期运行 ④任务从高成本队列迁移到低成本队列 治理团队核心工作从推动研发同学治理，变成帮助研发同学，准确识 定价：真实成本/总资源消耗=单价 按照季度调整单价 别TOP治理收益，推荐最优治理策略。 计算费用净增长10000元/天 目标：8000元/天 进度：100%时间进度100% 治理工作台收益2000元/天 自主治理收益3000元/天 技术优化收益 1000元/天 存量任务费用12000元/天 新增任务费用4000元/天 建立清晰的成本账单和归因模型，让同学很容易诊断，为什么成本上涨了，为什么成本下降了？ 周/月度账单功能帮助owner按周/月粒度感知成本变化情况和变化归因，以飞书卡片方式推送用户。 帮助开发同学看清成本和治理目标 支持开发同学自主分析成本变化原因，及时发现/预防成本恶化； 帮助开发同学拆解治理目标，规划可达成目标的治理路径； 建立成本心智，感知治理目标和实际治理收益的对比情况； 任务自主治理收益量提升200%，占总体治理收益的65%。 HBO：建设电商任务个性化的自动调参能力。 Shuffle优化：针对shuffle阻塞问题，进行打散/限流优化。读取模型优化：读取扫描万亿级别的大表的任务优化。 虚拟core精细化：cpu虚拟化，能精确到千分之一核，实现灵活分配。 超发能力：底层container超发，队列超发等技术。 收益价值：CPU利用率从60%->78%，极大节省了资源成本，且在持续提升中。 04工具效率体系化 数据治理阶段有较多的划分方法，结合经验和抖音电商的实际情况，我们以数据开发流程的来划分事前、事中、事后。 事前预防：通过系统化的方式，上线/调试前的检测；核心是通过工具 化的方法事前预防各种问题的产生，主要围绕增量/变更任务。 事中监控：任务日常运行，实时预警，同时也涵盖实时问题诊断和复盘；事中的治理都是有时效要求，必须在一定时间内（短期）完成。 事后优化：深度分析现状，通常以专项的形式进行数据治理；事后的治理一般需要深度治理，组织专项制定计划，主要针对存量任务，因此周期一般较长，收益也比较清晰。 队列检查 运行规范 监控配置 SLA重评估 探查报告 质量规范 空值检查 Code-CT 调试规范 运行时长检 查 参数规范 代码规范 语法规范 逆向依赖 模型规范 旧表禁用 大表依赖 治理工具化体系——事前管控平台Code-CT 质量提升，事故降低：有效的避免数据事故以及报警，在实践中不断打磨，贴合抖音电商业