火山引擎 DataLeap:揭秘字节跳动业务背后的分布式数据治理思路

大数据
经过十多年的发展, 数据治理在传统行业以及新兴互联网公司都已经产生落地实践。字节跳动也在探索一种分布式的数据治理方式。本篇内容来源于 火山引擎 超话数据直播活动的回顾,将从以下四个部分展开分享:字节的挑战与实践,数据治理的发展与分布式,分布式自治架构,分布式自治核心能力。

字节的挑战与实践

首先来看一个问题:“一家公司,数据体系要怎么搭建?”

  • 方案一:整体规划,系统架构驱动
  • 方案二:问题出发,业务价值驱动

在字节跳动,我们选择的是方案二,即从业务遇到的问题出发,重视落地结果与业务过程,去解决实际的治理问题。

基于这个理念,在数据治理过程中,字节跳动也面临以下三个挑战与机遇:

业务特点:业务发展快、场景丰富、数据量大且形态各异。 业务的线上服务及创新,都对数据有较强的依赖,核心业务数据延迟,质量问题将直接影响业务表现及发展。

组织特点:扁平化的组织模式,分布式的组织管理。 无行政手段或强组织约束,也无全局治理委员会,且数据从采集到应用全部的生产流程,没有全局规范,业务团队需要自主制定策略并落地。

文化特点: OKR 拆解与对齐文化,业务团队有充足的目标定义与拆解权限,且任何人都可能有动机、有角色、甚至有权限去进行数据治理,导致数据治理的业务流程复杂

字节数据治理演进阶段

字节数据治理演进阶段分为 6 个阶段:

业务第一原则: 坚持业务第一原则,解决业务实际遇到的治理痛点

优先稳定建设: 优先解决交付稳定,保障数据链路与产出稳定,减少交付延迟

保障数据质量: 核心链路质量管控,配置强质量规则,自动熔断,避免全链路数据污染;加强事前检查,从源头加强质量控制;完善事后评估,为每一张表建立健康档案,持续改进。

关注数据安全: 冗余权限识别,消除授权风险;数据分类分级,风险定义与多策略控制,减少安全风险

重视成本优化: 基于多种规则的与完备的治理元数仓,提供低门槛的治理产品能力,快速优化存储

提高员工幸福感: 在帮助业务完成数据治理的后,还需要考虑团队的负载压力,报警治理,降低员工起夜率;归因分析,快速排查修复故障。

在这里,再介绍字节特色的“0987”量化数据服务标准。这四个数字分别指的是:稳定性 SLA 核心指标要达到 0 个事故,需求满足率要达到 90%,数仓构建覆盖 80% 的分析需求,同时用户满意度达到 70%。按照这个高标准来要求自己,同时这也是一种自监管的机制,能够有效的防止自嗨,脱离业务需求和价值。

字节的部分场景实践

下面通过两个例子为大家介绍数据治理在字节的场景实践。

案例一:

  • 问题:字节跳动内部 2019 年到 2020 年间,双月内事故数量较多,对业务造成一定影响,且收敛困难,每天都有告警、起夜、对正常开发进度造成影响。
  • 解决方案:采用了分布式用户自治的 SLA 治理,通过数据分级保障目标管理,在各业务内部进行【拉齐链路-数据分级-广泛共识-系统管理】的行动闭环,系统化保障目标传递和落地。
  • 效果:截止 2020 年中,事故以每双月 30% 环比下降,在 1 年内达到稳定性问题彻底收敛。

案例二:

  • 问题:抖音的实时数仓治理人员的精力分散,以被动的运动式、“救火”式的工作模式为主。协同效率低,人力投入巨大,缺少可持续性。
  • 解决方案:覆盖质量、成本、SLA、安全等治理方向,以业务评估体系,构建治理方案进行例行诊断,对存量问题进行识别和派发,形成一套【评估->识别->规划->执行->复盘】业务内部分布式自治的治理机制。
  • 效果:从 21 年至今,治理人员的精力彻底从”运动式“治理的模式中解放出来,更多精力会集中在监督执行与规则优化中,团队起夜率降低 30%。质量保障覆盖率达到 100%。双月存储优化均在 20+PB。

数据治理的发展与分布式

众所周知,有很多机构都分享了对数据治理的定义,这里简单分享一下

国际数据管理协会(DAMA):数据治理是对数据资产管理行使权力和控制的活动集合

IBM:数据治理是对企业中的数据可用性、相关性、 完整性和安全性的全面管理。它帮助组织管理 他们的信息知识和作为决策依据

维基百科对数据治理的定义:数据治理是一个涉及全体组织的数据管理概念,通过数据治理,确保在数据的整个生命周期中拥有高数据质量的能力,也是对业务目标的支持。数据治理的关键的重点领域包括可用性、一致性、数据完整性和数据安全性,也包括建立流程来确保整个企业实施有效数据管理。

在传统的数据治理方法论与定义中,注意到他有以下共性特点,同时也是现在大多数公司的实践路径,即:

图片

但是在实际的执行过程中,他需要以下几个前提和随之带来的落地难点

  1. 需要明确组织制度

梳理业务数据部门,设立公司级别数据治理委员会/部门,各业务分设执行部门,公司内各业务宣导讨论,统一制定公司数据治理规章制度

难点一:组织依赖重、建设周期长。需要招聘大量专业的治理专家或引入外部咨询机构,计划制定周期长;专设部门牵头,若无自顶向下的项目背景,业务协调对齐困难。

  1. 需要明确权责管理

梳理公司数据资产,迁移、拆分、业务改造。确保资产归属与治理权责明确,定期梳理资产类目,维护资产元数据的有效性,确保治理边界清晰

难点二:业务影响大,目标对齐难。需完成存量的资产归属划分、改造生产开发体系,对增量定期人力打标,确保资产归属与权责边界清晰,因可能业务系统改造,会对业务发展造成影响。

  1. 需要进行复盘抽查

管理组织定期检查各业务治理过程是否符合公司治理制度,定期检查各项治理结果是否落地,线下复盘与推动不符合预期的治理过程

难点三:沟通成本高,执行推动难。如何制定适用于不同业务特点与发展阶段的团队的治理评估体系,各团队是否认可评估标准。

为了解决以上三个问题,我们有些新的思考,即引入「分布式」的理念。

Governance 一词在根源上同 Government,1990 年代被经济学家和政治科学家重新创造,由联合国、世界货币组织和世界银行等机构进行传播。其核心有以下两种论述:

第一个论述:标准与规范。指的是一定范围内的一致的管理,统一的政策,某一责任区指导以及合适的监管和可问责机制。这种行政力的集中化管理存在一些问题,比如决策成本高,人力投入高、落地阻力大,精力消耗大。

第二个论述:过程与结果。指的是只要关注结果和产出以及业务内部实践,通过分布式协作让业务的治理结果、业务痛点和治理方式及手段在内部闭环,而不是由中台层面统一推动。

我们尝试从第二种论述,即重视过程落地和治理结果产出的出发,更快的落地产品,落地数据治理的产品解决方案

从集中式到分布式

基于分布式的数据自治的理念,我们来解决在落地执行上的两个最困难的点

一、组织制度分布式: 尝试将组织的强管理属性转换到监督属性,治理单元与制度设计回归到业务单元。好处是,不强依赖横向中心化组织,业务治理痛点闭环在业务单元,且业务基于自身发展阶段制定治理目标,ROI 论证回归业务。

二、权责验收分布式: 基于产品体系与落地解决方案,支持业务按需自驱,市场化执行,平台辅助与按需验收。好处是,无须长周期的资产类目梳理,业务系统改造,权责均由业务区分,基于业务单元与多维视角,按需验收治理结果,业务单元内对齐。

图片

如上图展示的饼图,对于一个公司的数据资产,传统来说,可以很清晰地按照业务边界来划分清楚。对于分布式数据治理,我们通常是由业务单元自行认领,业务单元 A 自行认领属于自己部分,业务单 B 也自行认领属于自己部分。认领就意味着,所有治理的动作包括结果,安全性、成本、质量、稳定都由认领业务单元负责。

当然,这样这样也可能存在两个问题,不过在分布式的理念中能够得到较好解决。

第一是认领范围重合:这种情况往往让业务在线下对齐是否需要去做改造和划分,各自拿到自身需要的治理结果,短期无须重人力投入,不追求绝对的边界划分。长期因不同治理验收需求或团队管理需求,自行进行资产归集和整理。达到动态的平衡状态。

第二是无人认领:针对长期无人认领的资产,我们可以基于每个业务的历史的规则和能力,形成一个治理的平均线,再从平台层面推动无人认领的资产治理,由于无人认领,这样的资产推动起来相对较快。

我们理解的分布式治理

定义:以业务单元为数据治理闭环单元,通过完善的产品工具,将管理视角转化为监督视角,解决数据治理落地痛点;各业务团队分布式自运行,整体上达到全局最优,从形态上,适配更多业务特性和发展阶段,从效果上,强推进重落实与结果。

字节跳动通常以业务单元作为一个数据治理闭环,即在业务单元内部完成数据稳定性、质量、存储、计算等治理。同时每个业务单元不是孤立的,也有相互协作,比如 A 业务单元的数据治理经验可以沉淀为治理模板,供后续其他业务使用。

图片

这样的分布式治理方式,有以下一些优势:

  • 影响小,依赖小。治理下放到各个业务中,各级业务乃至个人都能自驱治理,业务根据自身发展阶段灵活组合治理工具,无须对组织强依赖。
  • 周期短,见效快。业务自驱梳理核心数据及链路,跨团队对齐线上化、协议签署、过程追踪。治理周期显著缩短,很快就出成效,增强团队信心。
  • 效率高,省人力。SLA 治理提高跨团队协作效率,聚焦核心数据任务集中资源保障,集中精力,报警归因减少起夜,帮助企业节省年度人力消耗。
  • 算清帐,降成本。各业务口径的存储计算资源消耗、核算成本,制定降本目标并追踪落地;业务经验规则化、策略化、自动化、自驱化持续降本增效。

分布式自治架构

为达成业务分布式自治,产品需要对用户行为路径完全覆盖,对业务经验完全接受。平台提供完善的开放能力,协助业务进一步提效。

图片

产品体系

以上关于分布式的理解,下面将介绍字节分布式自治的产品体系。

图片

从治理门户来看,包括治理全景、工作台、规划、诊断、复盘等全流程治理环节。在治理场景中,提供数据质量安全、资源优化、报警、企业复盘管理等一系列垂直场景。在底层,包含数据全生命周期流程,从数据采集、数据传输、数据存储、数据处理、数据共享到数据销毁。

治理双路径

图片

为了把用户所有治理经验沉淀为平台能力,我们抽象了 2 种治理路径。

  • 第一种是规划式路径。这是一个比较常见的规划式路径,即从看板和报表出发,自上而下做规划。比如看板已经反映出成本增加、延时变长或者数据质量变差,团队管理者发起报告或事故,推动业务单元同事进行数据治理,最后进行复盘。
  • 第二种是响应式。比如生产者收到一个数据质量或延时的报警,随后快速定位原因并做改进计划。

为了更好把业务经验全部线上化,我们通常双路径并行使用。

规划式治理路径案例

图片

首先看通用模块资产视图,包括资产增量情况评估等,以及业务对于资产的评价,如健康分体系。我们通常根据资产情况去制定目标。如果发现问题之后,业务驱动制定目标,可能是降低存储。同时需要去应用一些业务规则,比如团队内部认为 TTL (数据生命周期)很重要,需要帮助识别出来的同时也需要设定一个诊断周期。在团队方案确认完之后,产品会做监督,包括定义提醒,同时也推动资产 owner 完成总结。

响应式治理路径案例

图片

例如,我们发现一些任务在深夜执行失败了,需要先做问题排查,发现问题是 HDFS 丢块导致。在传统情况下,解决方案是去检查 API 问题,再去拉相关人员,可能 2- 3 小时才能完成,最后配合监控并收归到 wiki 中。而在 DataLeap 数据治理产品里,可以直接实现归因打标等能力,最后快速复盘。

治理全规则

图片

如果要覆盖业务的全部属性,治理平台需要形成有效且全面的规则模板。目前,我们的规则模板包含两个部分:

第一是 规则引擎 ,具体包括业务输入、平台输入、推荐输入。

  • 业务输入:主要依据业务团队的治理经验以及行业经验。
  • 平台输入:平台会提供一些基础能力,如存储、计算、质量、报警等几个维度。截至目前已经提供了 80 多个规则。
  • 推荐输入:基于业务输入和平台输入,去做分析和挖掘,发现哪些规则用得多、哪些规则阈值更合理。

第二是治理数仓 ,具体包括行为数据、治理操作、效果数据。

  • 行为数据:包括用户规则配置等内容是否有重复以及带元素标签的资产数据等。
  • 治理操作:包括生命周期、任务关闭、数据删除、SLA 签署等。
  • 效果数据:包括操作收益、资产收益、指标收益等。

不同业务快速灵活接入治理规则

图片

分布式自治基础是要构建治理生态、建设开放平台,让不同业务能够快速、灵活接入。

为了让业务能快速介入,我们把数据分成了四种类型:表达式、三方元数据、标准元数据、算法包。针对不同的业务,根据当前的经验和能力,我们会提供不同的接入方式,让业务去更好把规则和能力去接入到我们的平台。

基于业务单元进行智能化提效

图片

在获取不同业务的规则和能力之后,我们需要再做平台能力沉淀,把好的规则和能力复用给更多业务。

Case 1:任务 SLA 签署推荐。基于运营时间做权重分配,保证下游任务运行完成,同时也会进行关键链路分析。这个规则目前在字节内部广泛使用。

Case 2:动态阈值监控。这是基于业务在报警阈值上的实践提取的规则。

Case 3:相似任务识别。通过序列化和向量化操作,去和底层 spark 引擎做配合。在业务内部应用覆盖 99%,且优化任务都千级以上,由此接入平台并推荐给其他业务。

分布式自治核心能力

治理全景 - 分布式验收

在分布式验收中,会区分为全员视角、团队视角和个人视角。全员视角可以看到公司级资产,包括整体的健康分体系以及核心指标。团队视角中,主要由业务自己梳理,包括内部的评价体系。

治理工作台 - 集中治理待办

图片

上图为个人工作台功能,主要为了把 SLA 保障、计算任务、数据存储等治理场景展示在一个页面,方便 owner 业务全局查看治理待办事项。

治理规划与诊断 - 权责与规划分布式

第一,支持自定义治理域,灵活自治,提供多种维度,自定义组合和圈选资产范围。

第二,支持创建治理方案,例行诊断:发起人基于业务需求,选择治理域,设计治理规则,发起存储/计算/质量等类型治理方案。例行诊断与推进实施。

第三,支持规则管理,提供 80+ 治理基础规则,支持自定义组合和配置规则与分享。

复盘管理

图片

复盘管理是一个通用模块。业务根据自身需要去识别任务是否需要复盘,或者仅仅做问题登记。除此之外,业务还可以用复盘管理能力做内部管理,比如查看、检索所有的事故复盘,查看每个事故发生的原因和改进计划。同时,也可了解归因分布情况,并帮助下一个值班同学快速反馈和定位问题。

SLA 治理

在字节跳动内部,SLA 不是平台级保障,而是源于业务团队内部。首先是业务按需申报,可能是 PM、运营或数据研发等任何角色,认为自身任务重要,填写背景、原因、等级、时间等信息之后,即可发起一个 SLA。发起之后,在团队内部进行审核,可能存在同一个团队多个高优任务的情况,这由团队内部自行调整优先级。同时,这个也是跨团队判断该任务重要性的标准。

之后是完成签署,签署也会在产品里面体现出来。每个节点时间都有实时监控,如果产生了延迟,会推动业务做复盘和登记。我们也提供基础的 DAG,包括申报业务单的查看,同时也可以让大家去查看每个等级的破线情况,以及团队对业务的服务情况。

数据安全

在数据安全层面,主要专注于清理冗余权限,完善分类分级。不同团队对冗余权限定义不同,有的 90 天无访问算冗余权限,有的 70 天,有的 7 天。因此我们提供自定义能力,由业务内部发起 review,完成冗余权限的识别和定义规则,识别之后复用诊断能力。

资源优化

基于每个团队实际执行情况,提炼出一些通用的规则。例如,某些规则可能有几十个业务在使用,近 90% 认为近 30 天无查询需要被识别出来,我们就会在平台中提供这类能力,方便新业务或者小白业务去使用。

报警归因

在报警归因方面,我们能提供所有报警明细,方便查看是否有重复规则,是否有高频报警规则,帮助用户发现无效报警和重复规则,降低告警量和跟起夜率。除此之外,我们也提供业务内部的归因登记和分析能力。

责任编辑:庞桂玉 来源: 字节跳动技术团队
相关推荐

2023-04-04 13:38:30

DataLeap数据血缘

2021-01-29 10:33:34

存储

2023-06-28 16:10:09

Dataleap数仓建设

2023-04-19 16:51:54

分布式Primus开源

2023-11-21 07:21:39

火山引擎计算治理自动化

2022-06-02 16:58:06

Ray机器学习字节

2015-05-18 09:59:48

ZooKeeper分布式计算Hadoop

2022-12-23 09:04:33

字节跳动数据治理架构

2022-11-24 10:01:10

架构分布式
点赞
收藏

51CTO技术栈公众号