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