动手点关注干货不迷路??
基于字节跳动分布式治理的理念,数据平台数据治理团队自研了 SLA 保障平台,目前已在字节内部得到广泛使用,并支持了绝大部分数据团队的 SLA 治理需求,每天保障的 SLA 链路数量过千,解决了数据 SLA 难对齐、难保障、难管理的问题。
一、背景介绍
SLA(Service Level Agreement):服务级别协议,对互联网公司来说是网站服务可用性的保证。数据 SLA,即数据可用性保证,一般以数据产出时间作为 SLA。
在海量数据任务开发场景中,因业务多样化、数据量大、数据任务复杂等问题,导致数据任务链路依赖复杂、链路长、跨团队节点依赖多,因此,在实际开发运维过程中,任务负责人为保证自身数据准时产出,会遇到如下困难:
-
沟通成本高:任务负责人尝试与上游任务负责人约定 SLA,但由于上游任务数多(可至上千个),且跨越多个团队,沟通成本非常高
-
权责不清晰:由于链路复杂,如何制定 SLA?谁来负责保障 SLA?
-
运维压力大:无法及时发现上游任务延迟,导致下游任务负责人承担绝大部分运维压力,且运维效果较差,往往发现延迟已经错过了补救的时间。
为解决上述问题,字节跳动数据平台通过自研的 SLA 保障平台,规范并推进各业务团队进行任务链路治理,有效保障数据的 SLA,数据 SLA 达标率达到 99.1%。
理想的一组任务的完成时间与对应 SLA 之间的关系如下图所示,即各个任务及其上游任务都在对应的 SLA 之前完成,这也是平台的治理目标。
二、应用场景
SLA 保障平台除了解决上文的困难外,对不同的用户还有以下使用场景:
-
数据业务方:“我们团队的业务很依赖一份重要数据,希望能对其进行保障,希望上游能承诺 SLA”
-
数据负责人:“我们团队有很多对外承诺 SLA 的数据,希望能有一个平台对 SLA 进行集中管理,并能提供一些统计大盘、风险分析等内容”
-
数据治理方:“我们希望能提升团队内核心数据的数据质量,对齐进行 SLA 管理,及时发现风险,并进行事故复盘和改进,最终不断优化数据质量”
根据以上不同角色需求,SLA 保障平台提出自身解决方案。针对团队数据治理需求,平台提供完善的治理看板能力;针对任务链路复杂导致的 SLA 难达成,平台通过各项优化,简化了 SLA 达成流程;针对下游任务运维压力大的问题,平台优化通知体系,及时播报 SLA 状态。
那么,SLA 保障平台有哪些核心模块?平台是如何运转的呢?
三、核心概念介绍
3.1 角色:
目前 SLA 保障平台的核心角色有三类,分别是:
-
申报人:即 SLA 提申报的人,一般是数据业务方,其提申报的目的是保障业务数据的 SLA;
-
管理员:满足数据治理方的需求设置的角色,负责申报的审核、批准、管理、统计、登记、复盘等,其目的是不断优化所属团队的数据质量。
-
任务负责人:即待保障 SLA 数据链路中的任务 owner,负责确定及签署所负责任务的 SLA,平台会按照其签署的 SLA 进行保障;
3.2 任务:
即产出数据的任务,通过数据任务的元信息,可构建整条数据生产链路的完整 DAG。在本平台中,所涉及的任务元信息一般需要包含以