字节跳动一站式数据治理思考及实践

开发 架构
今天的分享主要分四个部分:机遇与挑战、数据治理思路、技术架构演进以及未来展望

一. 机遇与挑战

图片

数据治理工作有很多挑战,最主要的一点是落地比较困难。

首先,治理工作中与业务有一定的矛盾。

第二,治理涉及的组织和管理难度大。

第三,规范“人”的动作难度大,治理过程中,需要依靠人来推进和执行,人员能力参差不起,组织文化、目标也存在不对齐的情况。

第四,缺乏适配性强的产品工具。因为治理工作范围广,链路长,并且涉及跨部门、跨系统的目标对齐,需要一个完备的产品平台。

图片

下面结合字节的特点,介绍数据治理工作的机遇和挑战。

  • 字节文化

首先,字节业务多,多业务齐头并进发展,需要快速响应业务需求;

第二,字节的 OKR 文化,使得每个人都可以参与数据治理的规划和策略的制定,并且主动寻找实现路径,快速对齐;

第三,为追求高效治理,没有设立统一的数据治理委员会,而是各个部门根据各自的业务情况进行治理。

  • 业务第一

字节业务规模大,并且以数据作为驱动构建闭环的产品较多,导致数据质量对业务的影响非常大。

综上所述,数据治理在字节是挑战机遇与并存的工作。

二. 数据治理思路

2.1  新型数据治理 - 分布式数据自洽

图片

针对上述问题,提出了分布式数据自治的思路, 综合考虑治理收益、业务影响,执行效率。

首先,业务影响方面,为保证影响小,治理工作按照业务单元进行。一个业务单元可能是一个小团队或者小项目,作为数据治理的范围和目标。

第二,需要沉淀各业务线的治理经验,提升治理效率;通过产品辅助业务自驱,实现规则化、策略化、自动化治理。通过工具等平台能力,降低治理门槛。并且支持灵活的治理方式,如管理者视角,自上而下规划性治理,和一线执行者视角,自下而上推动治理。

第三,需要适配性强,建设产品来覆盖治理全链路。

实现多种场景中,产品都有能力覆盖,多个模块可以独立使用,按需组合;并且提供完整的开发能力,支持业务根据自身特点和发展阶段,自行接入。

2.2  集中式 VS 分布式

图片

分布式治理,与传统集中式治理相比,有很多优势。

  • 集中式治理,需要制定制度进行大范围组织,划分权责,定期抽查考核,建设周期长,适配能力弱,并且组织投入多。
  • 分布式自治,业务影响小;周期短,见效快;效率高,节省人力;便于算清对业务的收益,降低成本。

三. 技术架构演进

针对上述思路,平台工具如何支撑数据治理?

3.1  解决方案 - 一站式

图片

首先提出了一站式的解决方案。将治理划分为三层。

  • 第一层 - 视图层

从资产视角、管理者视角 、实施者视角 纵览数据治理的情况。

  • 第二层 - 方案层
  • 针对治理过程,提出了双路径。
  • 路径一【主动规划】规划式流程
  • 主要解决的问题是:确定目标后,如何推进执行。将治理目标,拆解成治理规则,进行诊断,根据诊断结果,执行治理。治理结束后,通过收益统计、改进计划等进行总结。
  • 路径二【系统发现】响应式流程

由系统发现的问题,通过高警等形式,通知到资产责任人,进行处理。通过根因分析等,进行总结。

  • 第三层 - 工具层

为上述两层,提供完备的治理工具。覆盖质量、安全、成本、稳定性、报警与起夜等场景,通过打通基础服务,赋能上述两条治理路径。

3.2  平台建设 - 治理方案 - 规划式流程

接下来将为大家介绍,在治理过程中,我们两条路径的具体建设过程。

图片

路径一:规划式治理

目标是资产清晰,规则丰富,动线完整,收益准确。

首先需要制定目标,包括健康分目标,以及降低存储、计算资源的目标。针对目标,建立治理方案,包括划分治理域,以及在治理域内通过规则,发现有问题的资产。建立方案后,由系统找到有存储、计算等问题的明细。对上述找到的问题进行分析,通过消息催办等方式,将问题下发到责任人,进行治理。系统会对治理的效果进行采集,反馈目标达成情况,并对一段时间内的治理结果进行验收和统计。

以上是规划式流程的主线思路 。

下面介绍如何实现规划式流程的几个目标。

3.2.1 资产清晰

图片

主要从治理全景和健康分两个方面对资产进行描述。

第一,治理全景。 从各个维度,通过明细、统计量,对团队或个人资产的具体情况进行描述。如各个表占了多少存储空间,计算资源使用情况,任务报警率、起夜率,数据及时性和质量等。

第二,对资产健康度进行衡量。 根据三个层级建立了健康分体系。第一层是根据治理的垂直方向划分,包括:存储健康分、计算健康分、质量健康分等。第二层在第一层的维度下,细化了问题大类。如存储方面,包括:无效存储、异常存储等;质量方面,包括:及时性、报警、元信息配置规范等。

在第二层的划分下,将具体问题通过标签定义,得到了第三层。比如无效存储方面,涉及了 TT 不合理、热度方面信息(xx 天无查询)等。

综上,主要通过健康度和治理全景将资产清晰地表述出来。通过元数据仓库,进行底层数据的建设。

3.2.2 规则丰富

目前平台具备了完备的治理规则,涵盖了存储、计算、质量、报警 4 大维度,50 多个规则。

其中包括全局规则,如:生命周期永久、近 7 天产出为空、暴力扫描任务等;也包括一些自定义的规则,如生命周期 xxxt 天,近 xxx 天产出为空等。同时还兼具了一些挖掘类规则,包括基于统计信息进行聚合后形成的规则,以及基于资产(包括库、表等)相似性,通过关联、排序来发现问题。

规则部分以及能力建设方面分为以下几部分:首先通过底层与平台基础组件打通,将数据收集上来,形成数据仓库的基础层;基于基础层对数据资产进行画像描述,进一步形成特征域,做特征挖掘和关联分析;然后将应用的数据,放到数据服务中,对外提供灵活的数据查询能力。

最上层为组合在线的规则引擎,将数据和规则进行联动,应用于规则建设。

3.2.3 动线完整

标出有问题的资产后,如何尽快完成治理,减少和业务的冲突,提高效率非常重要。

基于治理平台的能力,在各个垂直场景中,我们建设了比较完善的治理动线。

大致的思路是,把能力划分为几类:

  • 任务治理方面,和任务开发、任务运维平台打通,支持任务的关闭、调整、调参,链路优化等;
  • 库表规范方面,和元数据平台联动,实现表管理、库管理、资产移交、属性修改等;
  • 生命周期方面,通过治理平台,和底层的存储(包括 hdfs, hive 等组件)打通,形成闭环式的治理;
  • 在数据质量方面,包括 sla 的及时性,离线、实时数据的监控,会和具体的质量规则平台进行强联动,互相登记数据、进行 sla 的签署、和强跳转交互等。

以上是动线完整的部分,能够使用户在平台中,通过很低的操作成本,完成一站式的闭环治理。

3.2.4 收益准确

第四个是收益的准确部分。

我们做了治理后,付出的人里成本、精力、怎么知道是有效或者达标呢?如何衡量这一阶段的工作是有价值的,治理是有收益的?这就需要在平台建设上,准确度量收益。目前统一建设了基于事件中心的底层框架。总体来说,就是定义数据的消费模型,通过上面的一些消息通道,来定时收集各个平台操作的消息;同时定义了事件的 SDK, 并兼容 API 的方式,灵活对接上游不同的平台。

目前来说,我们和研发平台、元数据平台、质量平台等,大部分都是通过消息订阅和消费的方式,将治理的事件,接入到事件中心里,并将事件中心的离线数据 dump 到数据仓库,进行离线加工,同时我们会将最新的事件,注入在线的元数据服务中,来及时完成治理收益的计算。

3.2.5 技术架构

在规划式流程的技术方面,遵循的原则是:统一的数据查询、各种规则灵活组合,操作结耦,治理收益准确。

整体的平台后端,会负责分发和转换治理的各种逻辑,包括查数、设置目标、健康分的展示和透出,治理的操作等。

后端平台拿到消息后,会做具体事件的拆分。比如说看板类查数的部分,统一将需求发送到查询服务里,数据查询服务会对底层存储做适配,通过点查、list、聚合类的查询,根据底层选取的存储引擎的特点,解析后,选取不同的底层存储。

规则引擎服务部分,可以与数据查询服务联动。通过数据查询服务取到数据后,通过规则的定义形成标签,这个过程可以抽象成一个服务。这个服务对外可以提供对资产标签的描述,作为通用的能力。

在治理的具体实施部分,我们统一抽象成一个后台的模块。具体的实施,如设置消息、设置 ddl、进行删除等,统一由这个模块下发到组件层,进行操作,在组件层或其他平台进行了有效操作后,由事件的收集服务,将事件收集上来,写回到数据查询服务,形成治理收益的汇总。

3.3 平台建设 - 治理方案 - 响应式流程

第二条路径是响应式路径。主要做事后治理、问题总结、经验沉淀。

在这条路径里,大致分了几个部分,首先以报警、消息作为源头。包括 sla 破线告警,数据质量任务的报警,计算任务的报警等。

系统会将上述消息进行汇总,展示在治理平台中。治理平台可以对消息进行搜索,对问题进行归因,并做根因打标,把问题定位到组件、平台等问题上;再通过一些组织方式,比如通过系统来去找到组件方面的对接人,或通过组织会议,将问题提给相关的责任方,推动他们做一些有针对性的保障。做了以上推进后,我们会将系统中的问题描述、改进计划列出来,有针对性地对问题进行定义,以及分析该怎么做达到事后治理的目的。最后,在问题解决后,推动方案的分享、沉淀和复用。

3.3.1 技术架构

响应式治理的架构,和规划式治理类似,区别是里面消息服务的部分。这部分作为基础的能力,将大数据平台的各种产品,包括研发平台、质量平台等所有的消息,接到统一的服务中,所有消息的发出,都通过服务对外。这个消息服务成为所有报警消息的入口。通过它可以做一些升级策略,如消息聚合、加急等。此外,和规划式治理类似,后端平台控制响应式路径的逻辑,包括消息订阅、问题登记、总结复盘模块等。其他部分和规划式路径类似。

3.4 平台建设 - 开放接入

讲完两条路径,下面是一些实践中的解决思路。因为业务有各自发展的阶段,以及不同的治理目标。比如说,比较新兴的业务,现在主要关注的是sla的能力;一些成熟的业务,现在做的已经比较好了,要去做规范性。不同业务有不同的诉求。如何避免一刀切,让不同的业务用平台进行治理,开放能力非常重要。开放能力是说,要构建治理生态,业务可以自定义地接入治理规则,实施治理。

当前阶段,将治理分为了四个象限,横坐标为元数据部分,纵坐标为规则的部分。规则包括表达式和算法包等形式。系统提供的能力,主要在一象限:定义的标准的元数据,和统一的表达式,通过规则引擎直接适配。如果业务方有第三方元数据,来接入我们已定义好的规则,如图中第二象限的部分,需要定义第三方元数据的接入。接入的第三方元数据需要遵循接入的标准,通过规则引擎进行适配。规则部分如果要做升级,比如进行相似度计算等,不是在一维上对资产打标,不是纯表达式可以描述的规则,这种情况下将其定义为算法包或者逻辑单元。需要定义好输入输出的标准,通过调用包或者插件的方式,执行逻辑。第三方元数据和算法包的结合同理,定义好输入输出,并关注包的执行效率、时间等,就能满足整体的接入。

整体来说,将平台能力开放出去,让业务接入自己的规则和数据,需要定义好标准的元数据格式,比如:可以定义行是具体的资产,列是具体的 profile。业务方负责加工自己的接入部分,完成配置和数据映射,通过表达式或者算法包的计算后,定义统一的输出,就可以对接到系统。目前,系统支持对单资产打标(pointwise)和两个资产关联打标(pairwise)。

3.5 平台建设 - 智能化能力

接下来是近期在做的事情。平台工具侧做了很多能力上的建设,通过智能化的方式,进一步降低治理成本,提高治理效率。下面介绍几个有代表性的落地。

3.5.1 任务 SLA 签署推荐

在做 SLA 签署时候,任务上下游,可能存在几百上千个节点,怎样估计出应该在什么时间产出呢?我们目前是通过血缘关系,找到节点所在的关键路径,基于运行时间,进行权重的分配,来确保节点有相对合理的 SLA buffer。

推荐签署部分,目前已经有了专利,并有了一定的效果。现在在做第二期,基于运行失败概率分布的情况,来调整上游 buffer 压缩,下游 buffer 宽松的问题。

3.5.2 动态阈值监控

解决的问题是:数据量正常分布,但看起来异常化的情况。比如流量日志在假期或活动日,出现正常突增或突降的情况。

平时做质量监控时候,会用绝对值阈值来限定作报警范围,比如参考历史7天波动率等。这样,容易造成假期或活动日误报警,给值班人员造成不必要的打扰。动态阈值就是为了解决这个问题。主要思路是:基于数据的历史情况,归纳为几种分布。针对不同的分布,提供不同的预测方法,预测整个表在某一天应该是在什么量级,然后基于数据量级设置上下阈值,超出阈值再进行报警或者消息通知。

在数据分布方面,针对我们自己的业务,划分了几种典型的分布:数据量单调不减的,大部分为快照表或者全量表;日志类的表,长时间观察时,假期或活动日可能出现数据量突增或突降;维度表,数据量比较稳定,维度发生变化时,会反应出一定的问题;以及与维度表类似的一些波动比较小的分布。

基于不同的数据分布,目前采取了四种不同的预测方法:

移动平均法、指数平滑法、自回归法、同期检测法。针对不同的波动做拟合,目前得到了一定的验证。

3.5.3 有相似任务识别

由于业务庞大、开发人员多、任务量大,在开发任务时,并不知道是否线上已有类似的任务,跨团队情况更明显,因此详细任务的检测很有必要。

基本思路是将目标源代码和待检测源代码 sql 的 ast 序列化,然后进行向量化,对特征向量做余弦相似度计算,结果通过产品进行透出,再由业务进行标注,经过人工的确认分析,对任务进行合并或下线。

以上是我们在智能化方面的一些探索。

3.6 平台建设 - 架构总结

总结一下,平台总体架构分为三层:

  • 产品层,将管理者视角和执行者视角做了区分。具体治理时候,通过双路径的方式:做规划式治理时候,从目标制定、规则圈选、治理实施、到收益统计、经验总结;第二条路径是响应式治理。通过订阅消息、发现问题、实施治理、登记问题、复盘总结几个步骤进行治理。
  • 服务层,提供了整体的服务逻辑层,在下面拆分了不同的模块,特别是接入服务,提供了开放的能力。通过对任务执行、事件中心等不同模块进行拆解,方面我们针对各种不同的场景,提供灵活服务。
  • 数据组件层,作为基础建设层,包括元数据仓库的建设、大数据组件的适配。

四. 未来展望

未来展望主要由三个部分。

  • 体验打磨

平台建设阶段,已经建立了比较完善的能力,在内部得到了有效的使用。进一步,会更加贯彻双路径的建设,规划式路径上,使资产更清晰、规则更丰富,进一步打磨动线,并提高收益准确性。

响应式路径上,除了问题登记、归因、总结外,后面会主要针对总结归纳、经验沉淀进行建设,使经验更好地复用到其他业务方。

  • 开放能力

基于分布式自治的理念,目前没有采取一刀切的策略进行治理。大家可以自定义自己的目标,对齐自己的 SLA 等。后续会支持自定义健康分,不同业务可以自己定义健康分的组织形式和描述。第二点是自定义方案。我们会进一步打磨自定义规则的接入流程,并将规则能力进一步开放化,支持业务调用。业务拿到打标后的信息,可以做自己的资产分析。第三点是打通业务,进一步以业务视角看待问题,针对业务问题,做好平台建设。

  • 增强型数据治理

目前大部分是基于统计类规则,正在建设部分挖掘类规则。

后续会在智能化模型建设方面,做一些预测分析。

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

2021-06-11 13:56:27

大数据DataWorks数据开发

2021-08-06 09:33:57

数据湖DLF DDI

2023-04-10 18:36:30

得物API协作平台

2023-06-21 08:34:49

2022-06-16 11:18:45

实践构建开发

2023-10-26 06:59:58

FinOps云原生

2017-05-04 21:30:32

前端异常监控捕获方案

2009-10-23 09:42:24

2022-09-16 11:27:46

建设微服务

2009-07-30 21:16:29

布线服务电缆架设

2023-01-10 09:08:53

埋点数据数据处理

2021-09-06 11:15:05

数据治理字节跳动埋点

2014-01-13 09:00:54

PythonDjango

2011-06-21 14:35:27

2010-05-06 16:02:26

2013-10-24 17:35:01

云网络H3C电子政务

2012-04-09 17:36:38

华为智真

2009-07-27 11:37:04

网络拓扑摩卡

2021-12-07 10:04:34

Azure Kuber场景应用

2016-11-01 11:54:26

BI大数据
点赞
收藏

51CTO技术栈公众号