合作机构:阿里云 / 腾讯云 / 亚马逊云 / DreamHost / NameSilo / INWX / GODADDY / 百度统计
腾讯 PCG 内容与平台事业群,包括大家所熟知的 QQ、腾讯视频、腾讯新闻、阅文集团,以及腾讯音乐等业务。在没有治理平台之前,数据治理是运动式的,有两个比较大的难点:
数据治理的困境,可以从面向的不同用户的不同场景来看:
综上,原数据治理多为运动式、脉冲式的,成本高、效率低,需要新的数据治理解决方案,优化数据治理任务。
对于管理者,数据可用性差,成本日益增长,治理任务难推进。我们希望通过提供一套整体的解决方案,把一些日常的治理策略平台化和工具化,将经验沉淀下来。具体来说,提供三个功能:
对于数据生产者,数据治理推进难有三个原因:
我们为数据生产者提供平台,以降低数据治理门槛,一站式完成治理执行。例如对于某表,生命周期是 180 天,但我们发现,该表只用到最近 7 天,大部分时间都是浪费的,那么可以一键推送治理,修改生命周期,降低存储。对于某些做备份的任务,通过提供一系列和各个系统交互的接口,可以一键完成数据备份,从而降低数据治理的门槛。
基于一站式数据治理平台,我们建立了一个“长效”治理的方法论体系。
从用户角色层看,支持数据管理者和数据 owner 两种用户角色。
对于数据管理者。我们为其提供多领域、多维度的视角,提供资产盘点和元仓建设两类解决方案。
为支持资产盘点和元仓建设,从产品架构层,还抽象出了资产分,通过对用户下各类资产的打分和汇总,来代表用户所有资产的大致水平,资产分可以汇总到组织甚至业务 BG 粒度。资产分可以汇总用户资产的健康度、水位。
后面会介绍数据治理引擎,对所有资产不合理的地方进行抽象,得到一些治理项。这些治理项本身又是和资产分析挂钩的,如果资产项治理得好,资产分就会越来越高,如果长久不处理,那资产分可能会停止甚至会下降。通过资产分,管理者更易定KPI,也方便执行。
如上图,数据治理平台整体产品架构的演进过程,包括三个步骤:
以上对数据治理的现状、困难以及解决的路径进行了概要的介绍。接下来介绍实现数据治理的一些关键工作。
在元仓建设层,我们专注于特征挖掘,这里包括三个方面:
如上图,资源整合自下而上,依次包括数据源、基础层、资产层、应用层。
数据源层:包括任务调度平台 US 和 VENUS、报表平台 data talk 和 data insight、以及一些数据链路加工平台、业务数据库,以及实验信息、临时查询等生产工具。为了保证数据准确和及时,大多数据是近实时的,通过消息队列获取,离线也每天同步并进行整合。
基础层:获取所有数据后,会进行标准化治理。
资产层:重点考虑数据热度以及数据间的依赖关系,包括数据链路血缘、任务间依赖、宽表、出入库模型等。
应用层:最后通过应用层,实现数据的高质量交付。这里,一方面,需要全面梳理以发现数据治理的机会和价值。另一方面,也要保证整体产出的时效性以及质量。
应用层有个重点是成本分摊,即对每个细粒度的资源,都和成本进行关联。如一个表等,我们可以知道它的存储成本、计算成本。任何一种资源包括队列、埋点、上报等,都和成本关联,就可以清楚地知道,进行数据治理,可以带来多少成本收益。
上图表示了大部分数据的加工流程:从前端埋点到上报,经过消息队列,离线、实时加工任务,到最终展现。我们对整个过程方案中所有的中间件实体进行抽象,挖掘出实体关联的可治理属性,包括成本、用量等,形成一个大图。
形成血缘大图后,通过图算法,可以做很多工作。比如,发现无用的数据看板,并顺着图,发现看板上游无用的节点,一直往前走,直到埋点上报表层。这样就可以一起处理,节省成本。
数据治理平台的血缘解析模型,也就是 SQL 解析模块。支持 4 种脚本类型:
我们通过血缘解析引擎,定义了增强型的语法结构,屏蔽不同 SQL 脚本的差异性,对外提供统一视图。
其中,基础语法结构,包括实体、逻辑、模型三部分。
有了上面的语法结构,就能够做一些深层次的特征挖掘。如两个 SQL 是否相似,只是一个比另一个多几个字段;或者某个表,很多字段下游根本没有引用,那么可以做冷字段处理。
血缘解析模块支持表级和字段级血缘解析,也可以自定义解析配置。用户可以使用一些接口,根据提供的模型,直接解析所需内容。我们也提供了协议解析模块的SDK,可以从 maven 库引入使用。
元仓建设中最关键的是挖掘治理特征,但治理特征和治理项之间有一定的 gap。
下面,我们从简单的治理项讲起,根据特征通过简单的规则就可以实现治理。例如:
更复杂的一些挖掘特征,可能需图算法来处理。比如重复计算,如何判断两个 SQL 相似?通过血缘分析,也可以发现跨层依赖、穿透等违反开发规范的情况。
在这一章节中,我们通过元仓建设和血缘分析,发现一些治理特征,为进一步形成治理项提供了基础。
下面介绍资产分体系,从五个维度对所有资产进行细粒度的刻画。
通过这 5 个维度可以看出,资产分,不仅考虑了成本,也考虑了规范和安全方面情况。
资产分基于扣分规则来生成。使用的特征包括前面几个维度的一些细则,比如:安全字段没有加固,扣 10 分;表注释不规范,扣几分。对每个维度,不同特征的治理项都做了扣分,汇总后,分数越高,说明资产的质量越高。若分数较低,就需要推动去做治理。
如何根据特征生成治理项,并最终生成资产分?这里依赖特征中间层以及生成治理项的规则引擎。
针对特征,我们构建了标准化结构化的治理中间层,包括对象、维度、特征三个要素。其中,特征有两类:
特征和治理项之间还有 gap。比如说近多少天无人,近 3 天无人访问,这是个特征,但它不一定是个治理项。有的业务近一天不访问,就需要治理,有的业务 90 天没人访问也无所谓,不需处理。再比如队列使用率 80% 就一定治理吗?不一定。
所以,需要把特征转化成治理项。可以通过引入规则引擎,采用界面的方法,生成一些业务自定义的治理项。
上图展示了治理引擎数据的全流程。
首先,治理项规则引擎接收治理对象的特征和一些定性结论,根据配置文件,将这些特征识别成治理项;然后,打分规则引擎根据治理项打分,根据另外一个配置文件,计算出在各分类下分值;最后,将这个分值推送给用户,同时治理项的明细和个人及组织绑定,打包成治理方案推送给管理者及一线数据 owner。
下面,我们介绍一下一站式治理平台的具体实现,主要包括以下功能:
从管理员的视角,按 HR 系统的架构,进行资产归属,将所有数据归属到个人,方便管理。并看清当前业务的资产现状,资产分,资产率,以及资源的明细。通过这些,来帮助管理层发现大数据的问题及治理机会。
平台内置了 100+ 治理项,覆盖从埋点到应用的整个环节,并可以根据不同的粒度自定义治理项,定制治理方案。管理者可一键催办,让一线的数据 owner 去执行对应的治理方案。
平台为数据 owner 提供一站式的治理工作台,对于一些基本操作,比如删表等,提供一键性的操作。用户,不仅包括数据开发者,也包括运营或产品同学,都可以看到自己的数据资产明细,包括资产分、排名、数量等。
无论是管理者还是数据 Owner,通过平台可以了解一段时间的治理效果,成本节省了多少,资产分提升了多少。每个月都会向组织和个人推送治理报告。
TOP