腾讯 PCG 数据治理体系

大数据
本次分享题目为腾讯 PCG 数据治理体系。腾讯 PCG 内容与平台事业群,包括大家所熟知的 QQ、腾讯视频、腾讯新闻、阅文集团,以及腾讯音乐等业务。

一、数据治理的概况和解法

腾讯 PCG 内容与平台事业群,包括大家所熟知的 QQ、腾讯视频、腾讯新闻、阅文集团,以及腾讯音乐等业务。在没有治理平台之前,数据治理是运动式的,有两个比较大的难点:

  • 数据量大且复杂。每天大概有万亿级别的数据增量,而且数据的格式多样化,覆盖文本、图文、长短视频与语音等各种结构化、非结构化数据。
  • 数据技术架构复杂。腾讯内部有多个业务,每个业务又有很多产品线,每个产品线用的技术架构又不尽相同。调度系统有用 Venus 的,也有用 US 的;数据治理脚本开发有用 pySQL 或 pySpark 的,也有用 Hive 的,还有用内部 SQL 脚本的。

数据治理的困境,可以从面向的不同用户的不同场景来看:

  • 管理层。作为业务负责人,需要控制成本、减少浪费,需要持续关注成本的变化,对未来做预估。为了把成本压下来,需要跟团队开很多次会议,定目标、过进展、报风险。但由于缺乏数据的深度治理和挖掘,以及数据治理平台,对数据治理任务的选择,难易、风险评估等,缺少定性、定量的方法。
  • 数据管理者。作为一线数据 leader,定下了目标,怎么定策略、如何推进,也有难度。对于数据治理的整体链路,各个结点(如埋点、传输、计算等)的情况,也缺少及时准确的信息。数据治理任务推进困难。
  • 一线数据人。作为数据生产者,每天需求已经很多了,还要关注老板定的成本目标。不断地分析哪里可优化,性能满不满足要求,如何优化。简单的治理可以做,复杂的涉及面广的就难以实施。

图片

综上,原数据治理多为运动式、脉冲式的,成本高、效率低,需要新的数据治理解决方案,优化数据治理任务。

对于管理者,数据可用性差,成本日益增长,治理任务难推进。我们希望通过提供一套整体的解决方案,把一些日常的治理策略平台化和工具化,将经验沉淀下来。具体来说,提供三个功能:

  • 帮助管理者看清楚大盘,了解资源利用率,发现治理机会;
  • 辅助管理者去制定治理策略,并向相关人员推送,推进执行;
  • 对数据治理的效果进行复盘,并辅助管理者推进迭代和优化,将运动式治理变成常态化治理。

对于数据生产者,数据治理推进难有三个原因:

  • 治理能力参差不齐,治理门槛相对较高。
  • 降本提效背景下,需要高效完成治理。
  • 个人治理效果难衡量,治理积极性差。

我们为数据生产者提供平台,以降低数据治理门槛,一站式完成治理执行。例如对于某表,生命周期是 180 天,但我们发现,该表只用到最近 7 天,大部分时间都是浪费的,那么可以一键推送治理,修改生命周期,降低存储。对于某些做备份的任务,通过提供一系列和各个系统交互的接口,可以一键完成数据备份,从而降低数据治理的门槛。

图片

基于一站式数据治理平台,我们建立了一个“长效”治理的方法论体系。

从用户角色层看,支持数据管理者和数据 owner 两种用户角色。

对于数据管理者。我们为其提供多领域、多维度的视角,提供资产盘点和元仓建设两类解决方案。

  • 资产盘点:比如通过对各组织的中间件、存储、队列等,提供各种维度下的资产详情,来帮助管理者看清楚资产的分布,进而辅助他进行下一步的治理。
  • 基于元仓建设,我们抽象出很多治理策略来提供治理服务。

为支持资产盘点和元仓建设,从产品架构层,还抽象出了资产分,通过对用户下各类资产的打分和汇总,来代表用户所有资产的大致水平,资产分可以汇总到组织甚至业务 BG 粒度。资产分可以汇总用户资产的健康度、水位。

后面会介绍数据治理引擎,对所有资产不合理的地方进行抽象,得到一些治理项。这些治理项本身又是和资产分析挂钩的,如果资产项治理得好,资产分就会越来越高,如果长久不处理,那资产分可能会停止甚至会下降。通过资产分,管理者更易定KPI,也方便执行。

图片

如上图,数据治理平台整体产品架构的演进过程,包括三个步骤:

  • 第一步,实现治理工具化。比如,先盘点所有离线表资产情况,然后生成治理项并制定治理方案,再将方案发给数据 owner 进行执行,最后对治理效果进行复盘,最后再重复这个流程。
  • 第二步,大数据全链路治理。对于一些中间环节,第一步已成功,就可以对其它治理对象应用这个模式。我们最早做的数据表,后面对整个数据生产链路里面的每一个环节,包括埋点上报、数仓加工、对外服务整个流程里的中间节点,都按照这个模式进行治理。如,埋点这里的治理项包括:参数空值率、参数异常率、事件重复率、事件丢失率等,并最终形成资产分。
  • 第三步,业务自定义治理。通过支持个性化治理,提升产品通用性。

以上对数据治理的现状、困难以及解决的路径进行了概要的介绍。接下来介绍实现数据治理的一些关键工作。

二、腾讯 PCG 元仓建设:专注特征挖掘、构建治理引擎基石

在元仓建设层,我们专注于特征挖掘,这里包括三个方面:

  • 全链路的数据整合清洗
  • 全链路的血缘构建
  • 基于血缘数据的治理特征挖掘

图片

1、资源整合

如上图,资源整合自下而上,依次包括数据源、基础层、资产层、应用层。

数据源层:包括任务调度平台 US 和 VENUS、报表平台 data talk 和 data insight、以及一些数据链路加工平台、业务数据库,以及实验信息、临时查询等生产工具。为了保证数据准确和及时,大多数据是近实时的,通过消息队列获取,离线也每天同步并进行整合。

基础层:获取所有数据后,会进行标准化治理。

资产层:重点考虑数据热度以及数据间的依赖关系,包括数据链路血缘、任务间依赖、宽表、出入库模型等。

应用层:最后通过应用层,实现数据的高质量交付。这里,一方面,需要全面梳理以发现数据治理的机会和价值。另一方面,也要保证整体产出的时效性以及质量。

应用层有个重点是成本分摊,即对每个细粒度的资源,都和成本进行关联。如一个表等,我们可以知道它的存储成本、计算成本。任何一种资源包括队列、埋点、上报等,都和成本关联,就可以清楚地知道,进行数据治理,可以带来多少成本收益。

2、全链路实时血缘

图片

上图表示了大部分数据的加工流程:从前端埋点到上报,经过消息队列,离线、实时加工任务,到最终展现。我们对整个过程方案中所有的中间件实体进行抽象,挖掘出实体关联的可治理属性,包括成本、用量等,形成一个大图。

形成血缘大图后,通过图算法,可以做很多工作。比如,发现无用的数据看板,并顺着图,发现看板上游无用的节点,一直往前走,直到埋点上报表层。这样就可以一起处理,节省成本。

图片

数据治理平台的血缘解析模型,也就是 SQL 解析模块。支持 4 种脚本类型:

  • SuperSQL,腾讯内部的查询语句,屏蔽了多种常用 SQL 之间的差异性,使用 Calcite 定制解析。
  • Thive,为了解决早期版本的性能问题内部定制的 Hive 版本,定制化 Antlr3 解析。
  • Hive,原生 Antlr3/4 解析。
  • Spark 脚本,主要指 Spark SQL,Antlr4 解析。

我们通过血缘解析引擎,定义了增强型的语法结构,屏蔽不同 SQL 脚本的差异性,对外提供统一视图。

其中,基础语法结构,包括实体、逻辑、模型三部分。

  • 实体,是指 SQL 读了哪些表,有哪些字段。
  • 逻辑,是指表之间是如何关联,字段如何筛选,加工逻辑是什么,以及针对 UDF 定义的关系。
  • 模型,主要是从语义层面分析,这个 SQL 是干什么的。

有了上面的语法结构,就能够做一些深层次的特征挖掘。如两个 SQL 是否相似,只是一个比另一个多几个字段;或者某个表,很多字段下游根本没有引用,那么可以做冷字段处理。

血缘解析模块支持表级和字段级血缘解析,也可以自定义解析配置。用户可以使用一些接口,根据提供的模型,直接解析所需内容。我们也提供了协议解析模块的SDK,可以从 maven 库引入使用。

3、治理特征挖掘

图片

元仓建设中最关键的是挖掘治理特征,但治理特征和治理项之间有一定的 gap。

下面,我们从简单的治理项讲起,根据特征通过简单的规则就可以实现治理。例如:

  • 表热度。可以用三种不同的原数据,一是查看表是否被任务调度系统的任务使用;二是这个表有没有被临时查询,是否经常被使用;三是扫描表底层文件的读取,是否被使用。通过这些数据,计算出表热度,并根据表热度生成一系列的治理项。
  • 字段热度。同样的,根据血缘模块直接生成。

更复杂的一些挖掘特征,可能需图算法来处理。比如重复计算,如何判断两个 SQL 相似?通过血缘分析,也可以发现跨层依赖、穿透等违反开发规范的情况。

在这一章节中,我们通过元仓建设和血缘分析,发现一些治理特征,为进一步形成治理项提供了基础。

三、资产分体系:开放、可持续迭代的资产分体系

1、资产分-衡量数据资产健康度的核心指标

下面介绍资产分体系,从五个维度对所有资产进行细粒度的刻画。

图片

  • 规范分。包括命名规范:是否遵循标准的市场分层,是否有业务语义等;注释规范;依赖规范等。
  • 成本分。包括计算成本和存储成本。
  • 安全分。包括归属合规:是否存在有离职或者转岗的同学,或者权限不合格的情况;安全等级;敏感字段加固:有没有敏感字段直接是裸数据。
  • 质量分。
  • 应用分。

通过这 5 个维度可以看出,资产分,不仅考虑了成本,也考虑了规范和安全方面情况。

2、特征工程&扣分规则

图片

资产分基于扣分规则来生成。使用的特征包括前面几个维度的一些细则,比如:安全字段没有加固,扣 10 分;表注释不规范,扣几分。对每个维度,不同特征的治理项都做了扣分,汇总后,分数越高,说明资产的质量越高。若分数较低,就需要推动去做治理。

3、引入规则引擎、低 ETL 代码

如何根据特征生成治理项,并最终生成资产分?这里依赖特征中间层以及生成治理项的规则引擎。

针对特征,我们构建了标准化结构化的治理中间层,包括对象、维度、特征三个要素。其中,特征有两类:

  • 直接特征:经过复杂算法加工出来的定性的结论。如是否存在跨层依赖,是否重复计算;
  • 间接特征:可供进一步挖掘的特征。比如:近 XX 天无人访问,队列使用率 X% 等。

图片

特征和治理项之间还有 gap。比如说近多少天无人,近 3 天无人访问,这是个特征,但它不一定是个治理项。有的业务近一天不访问,就需要治理,有的业务 90 天没人访问也无所谓,不需处理。再比如队列使用率 80% 就一定治理吗?不一定。

所以,需要把特征转化成治理项。可以通过引入规则引擎,采用界面的方法,生成一些业务自定义的治理项。

  • 通过将各治理项归属到资产分的五个分类里,可以得出整个资产分的值。
  • 通过标准化治理分层,利用中间层,将产品方案和前端元数据解耦;也就是对于其它公司,若已有元仓,只需要将这些特征灌到治理中间层,不需任何改动,就可以直接生成一套数据。

4、治理引擎数据全流程

图片

上图展示了治理引擎数据的全流程。

首先,治理项规则引擎接收治理对象的特征和一些定性结论,根据配置文件,将这些特征识别成治理项;然后,打分规则引擎根据治理项打分,根据另外一个配置文件,计算出在各分类下分值;最后,将这个分值推送给用户,同时治理项的明细和个人及组织绑定,打包成治理方案推送给管理者及一线数据 owner。

四、治理工作台:一站式治理平台

下面,我们介绍一下一站式治理平台的具体实现,主要包括以下功能:

1、看清业务资产及成本现状

从管理员的视角,按 HR 系统的架构,进行资产归属,将所有数据归属到个人,方便管理。并看清当前业务的资产现状,资产分,资产率,以及资源的明细。通过这些,来帮助管理层发现大数据的问题及治理机会。

2、管理者制定治理方案

图片

平台内置了 100+ 治理项,覆盖从埋点到应用的整个环节,并可以根据不同的粒度自定义治理项,定制治理方案。管理者可一键催办,让一线的数据 owner 去执行对应的治理方案。

3、数据 Owner 执行治理

图片

平台为数据 owner 提供一站式的治理工作台,对于一些基本操作,比如删表等,提供一键性的操作。用户,不仅包括数据开发者,也包括运营或产品同学,都可以看到自己的数据资产明细,包括资产分、排名、数量等。

4、治理效果复盘

图片

无论是管理者还是数据 Owner,通过平台可以了解一段时间的治理效果,成本节省了多少,资产分提升了多少。每个月都会向组织和个人推送治理报告。

责任编辑:姜华 来源: DataFunTalk
相关推荐

2022-11-10 20:43:57

数据治理数据湖

2023-01-31 15:27:13

数据治理数据管理

2023-04-10 07:34:30

2020-08-31 16:19:26

IT治理建立绩效体系

2022-10-13 09:38:01

数据建设

2022-05-13 11:24:09

数据美团

2022-03-30 17:13:23

慢 SQL字节查询

2022-08-31 12:48:34

腾讯大数据

2022-03-15 10:00:00

美团数据治理

2018-08-31 19:36:03

2022-03-10 10:06:57

数据治理美团体系化建模

2015-09-28 15:20:49

2023-04-14 15:50:29

元数据数据治理

2013-01-06 17:10:54

数据治理Informatica

2015-07-20 10:29:39

2020-05-27 10:13:27

网络安全技术

2017-08-07 10:04:49

数据数据治理数据管理
点赞
收藏

51CTO技术栈公众号