翼支付数据治理实践之元数据管理

这个主要是想给大家解释下数据治理与元数据的整体关系，这里引用华为的一个数据治理之道：“清洁的数据成就卓越运营，智慧数据驱动有效增长”，这说明了企业为什么要做数据治理。在当下数字经济蓬勃发展的过程中，各个企业都投入很大的精力去做这些事情。数据治理最核心的目标就是得到“清洁”的数据，元数据是数据治理的一个基础设施，在整个数据治理过程中起到了非常核心的作用。

首先企业数据治理一般要面临的问题，也就是数据治理要去解决的问题有这些：

• 数据质量和数据实效不高：这也是数据的使用方经常吐槽数据部门的一个核心问题。

• 核心数据的识别困难、数据一致性表差：例如各个不同系统得到的指标，不同的部门得到指标口径可能都存在一些差异。

• 数据治理前清后乱：前期刚把数据治理好，之后新增的数据又开始把所有的数据搞乱，难以持续维持。

• 数据安全风险居高不下：整个国家的法律法规在不断完善这一块，对企业来讲还是面临着不少风险。

• 数据开发烟卤化严重，基础数据面临多次重复建设：重复劳动导致大量的成本浪费。

以上这些都是企业数据治理过程中要去解决的问题，那么元数据在治理数据过程中要解决什么样的问题？我们最终把企业的数据治理抽象总结出四个方向的问题：成本、效率、质量、安全。

• 在成本和效率方面，通过资产元数据识别数据表的价值，根据数据血缘识别任务链路，推进核心任务、低价值任务的等级制度。针对核心的任务做必要的保障，针对一些低价值的任务，推进任务进行下线或者降低它的资源使用。

• 在数据质量方面，可以通过主数据治理及数据质量的提升来提升数据的一致性。

• 数据安全方面，可以通过数据分类分级和数据安全治理来降低产生和大数据侧数据存储、传输及使用方面一些安全风险。

以上是整个数据治理和元数据之间的关系。

02

元数据治理体系

这部分主要从以下四个方面来介绍：如何去做核心数据的保障、主数据的治理、数据规范体系建立、整体产品的架构。

1. 核心数据保障

核心数据保障主要是解决数据质量和时效不高的问题，现在每个企业的数据体量是相当大，要在海量的数据里面保障核心数据的一个实效性。每个公司资源有限的情况下，不可能保证所有的任务都会得到保障，所以要优先使核心任务得到保障。怎么去保障核心数据识别，以及后续的保障措施流程？翼支付是通过以下四个步骤来逐步推进完成的：

    ①项目空间的管理：支持多租户的资源分配，控制每个空间的队列资源以及优先级，还有任务最早的启动时间来保障整个任务的有序进行。

    ②队列的划分：一般划分为核心、重要和一般三个队列，核心队列由数仓统一管控，而事业群只能去调整自己的任务为重要和一般两种队列。

    ③资源策略：在五点之前所有资源优先提供给核心队列进行供应，因为作为电信旗下一家子公司，有一些像集团上报的数据有非常高的时效性要求，这种核心任务会优先给他分配资源。在五点之后会按照任务的优先级以及任务的依赖进行资源分配。这是整体的一个资源分配方案。

2. 主数据治理

主要是为了解决一些核心数据识别困难以及数据一致性差的问题，在翼支付我们希望是通过主数据的治理能实现同源的多用，因为主数据一般只有一个核心的数据源，然后多个系统进行的引用，来保障数据的源头的一致。再加上主数据又是核心数据，我们要对它进行数据质量的提升，来逐步建立起主数据的权威。主数据的治理也是分四个步骤：

    ①主数据定义和识别：由数据部门统一来确定唯一的数据源，它是唯一的来源也是最权威的来源。

    ②质量管控和提升：确定了主数据之后，要对它进行数据质量的稽核，来提升这个主数据的数据质量。如果源头的数据质量有问题的话，那我们在下游使用问题肯定会更大，所以要确保主数据和源头的系统数据是一致的。

    ③主数据集成和服务：把控以上两步之后就会进行主数据的集成和服务，会推进各个业务系统进行主数据的应用和消费的改造过程。

    ④主数据服务和消费：建立起主数据之后，要确保后面的新增系统以及存量系统要按照我们的要求，根据流程进行改造。如果新增的话，不允许自建主数据，必须引用主数据的数据，it协同实现数据的集成和服务链路打通。

3. 数据规范体系建立

数据治理投入的成本比较高，如果没有规范的约束的话，经常会出现数据治理的“前清后乱”——前面治理完，后面数据又全部乱掉了，整个数据治理难以维持。还有就是如何保障数据安全，需要有一些数据安全相关的规范。所以基于这个背景，我们构建了整个的数据规范体系。

翼支付整个的数据链从生产系统模块中的DB库抽到大数据的数仓模块；最先到达ODS层再依次到DWD层、DWS层、DWM层，数仓将数据整合和治理之后，再提供给业务团队进行报表展示、业务分析和数据探索的业务应用、数据消费。这是整个数据链路过程。

一般数据治理的核心肯定在数仓和消费端，但是如果要保证数据整个的完备和避免数据“前清后乱”，在生产的源头系统也要对它有相应的约束，整个数据规范体系是针对整个生产链路，从生产系统->大数据侧->消费系统应用都要求统一进行规范。这个规范可以分两个大的方向：

第一个是基础的数据规范，包括主数据的标准、元数据的标准，还有数据开发规范。

第二个方面是我们数据安全的规范，它最核心的是依赖于我们数据的分类、分级标准。在这基础上有了数据安全的规范，包括我们数据的存储使用还有传输相关的一些要求、数据权限的管控的一些要求。制定了相应的规范之后，确保规范执行落地，需要有一套强有力的数据质量稽核和通报机制。

• 数据质量稽核：就是要在各个数据里面，通过it的形式加人工抽查的形式去审核数据有没有按照要求来实施。

• 通报机制：则根据各个公司的不同形式来保障；同时也对其他部门有一些约束。这个数据规范不能只是针对数据侧的一个数据规范。

要保证整体的数据的“清洁”，还要从数据生成源头做质量把控，坚持生产源头治理并行，从三个方向来做：

    ①数据安全治理（存储、传输、使用）。

    ②生产元数据治理（库表字段命名规范统一），不能统一的话，那生产侧也要有一套相应的规范，而不是让我们的开发人员随意去命名他的库表。

    ③主数据的识别和应用，主数据在数仓的应用是一方面，更多的时候在生产的各个应用系统之间也是会广泛的应用，所以这个要提前去抓。

4. 产品架构

前面给大家介绍了元数据的治理体系，要支持这个治理体系的落地需要我们产品能力的支持。以元数据为基础的整体架构视图给大家简单讲解一下，它总共分为三层：

• 最上面一层是数据消费层，主要是把我们治理好的“清洁”数据提供给需求方实现数据应用报表的可知化和自助分析。

• 中间一层是数据治理体系层，就包括前面给大家介绍的数据规范体系、基础数据治理、主数据治理、数据安全治理、数据质量提升的一些策略。

• 最下面一层是数据平台层，要保障上层数据治理体系的落地，也需要产品工具进行协同，产品工具最核心的一部分就是元数据平台。它主要提供两种能力：一个是面向我们的数据人员提供了一些产品功能：数据目录、元数据查询、血源分析、元数据注册，让数据人员更好去解读我们的数据；二是管理和服务，因为除了我们元数据平台以外，像数据资产平台、核心的数据开发平台、数据总线等也是要基于我们元数据平台，由元数据提供血缘、权限、元数据查询等服务。

元数据平台技术介绍

1. 元数据设计理念

谷歌在2003年和2004年先后发布了被称为大数据三架马车的三篇重要论文，分别是MapReduce、GFS、BigTable；正是谷歌的“三架马车”掀开大数据时代的序幕，而在2016年谷歌也发表了一篇论文《Goods：Organizing Google’s Datasets》[1]，从多个方面介绍了谷歌内部的一个元数据管理系统 Goods。

Goods的架构如上图所示，数据存入到他的Catalog中，并以此为基础对外提供查询、监控、血缘关系、展示等服务。

Goods的数据类别如表所示：包括了基础元数据、基于内容的元数据、血缘数据等。

通过这篇论文我们总结了以下几点：

    ①Goods 是一个 post-hoc 系统，也就是事后处理系统，所谓事后处理系统就是指在用户创建和更新数据以后再采集元数据，不干扰用户的正常使用。但是论文在feature work中也提到了，他希望在将来用户在创建和更新数据的同时就能够将元数据进行注册。

    ②Goods 使用了 BigTable 作为元数据的存储介质，BigTable 的开源实现就是HBase，为什么使用 BigTable？因为它一个非常重要的特性：“blind writes”，所谓“blind writes”即不区分insert和update，可以直接将数据进行写入并且带有时间戳的属性，这样就极大地缩短了元数据的同步时间。

    ③Goods有大量的批处理任务，包括离线的采集元数据信息以及离线的处理元数据信息。

    ④构建评分机制，对用户的搜索结果进行排序；谷歌评分机制相对比较完善，表的属性、所属的类别、血缘关系、用户评分多个维度对搜索结果进行一个排序。

2. 架构设计

我们以这篇论文为设计基础，结合公司的实际情况，并在落地过程中也参考了业内的多个开源平台，如上图所示就是翼支付元数据平台架构图，主要分为三层：

①存储层

利用了不同的存储系统存储不同的数据，首先利用HBase存储各类元数据信息；利用Elasticsearch存储索引信息用于搜索；利用图数据库存储血缘关系信息。

②服务层

用存储的各类数据信息提供服务，比如在元数据平台上进行表的查询，还有表和字段的血缘关系的展示和分析。同时给外部平台包括ETL平台、BI平台、AI平台提供元数据的查询服务。

③接收层

适配不同的数据源，从数据源中采集元数据信息并进行处理。

3. 元数据模型

元数据主要包括四类：

①基础元数据

主要包括表名、类型、大小、文件数、最近一次修改时间等，这些元数据通常是从数据源直接获取，直接写入到HBase当中。

②资产元数据

主要包括表的一些业务描述，所属的业务域、层级、表的owner等，通常是由开发者在生产过程中手动维护。

③安全元数据

主要包括权限信息、分类分级、是否包含隐私数据等，这些数据通常是根据相关法律法规以及公司的规范由表的数据内容决定。

④血缘元数据

包含上游表、下游表，通常是由数据同步和数据加工任务产生。

除了这4大类数据以外，我们还有一些衍生的元数据：包括查询次数、变更记录等等。

4. 元数据采集

元数据的采集平台会适配不同的数据源，开发不同的采集插件，采集插件采集元数据后会推入到消息队列中，由下游的 Metadata Processor 服务进行处理。Metedata processor 服务接收到消息后会直接写入到 HBase 中，并对元数据进行比较，判断是否有增加或删除；如果有，就将相应的变动推入到消息队列中，下游的 Metadata Change Processor 服务接受到消息后会更新到 Elasticsearch 中相应的索引。

5. 全链路血缘

全链路的字段级血缘，就像前面所说，血缘数据通常是由数据同步任务和数据加工任务产生，对于数据同步任务可以由相关的平台直接将相关的血缘信息推到消息队列当中，平台接收到消息后进行处理并存入到图数据库中。而对于数据加工任务，我们采用了 hook 的机制对计算引擎的执行计划进行分析，从而获取到字段的血缘关系，并推送到消息队列中进行处理。

未来展望

主要是三个方面来规划：

第一个是支持多源异构数据的管理，现阶段大部分都是基于结构化的数据，包括我们的数据源也是 Hive、ClickHouse 这种存储结构化数据的数据源，除了结构化数据以外我们公司未来会有更多的非结构化的数据，比如说图片、声音、文本，而这些数据通常会存储在分布式存储系统（譬如Ceph）中，这些分布式存储系统的元数据也需要进行管理。

第二个是多集群跨dc的容灾，作为存储了数据的元数据平台，要考虑自身的一个容灾的问题，然后进行架构升级。

第三个是智能推荐，除了表的搜索以外，还要通过推荐让用户更快更好更方便地找到自己想要的一些表。

[1] Alon Halevy, Flip Korn, Natalya F. Noy, Christopher Olston, Neoklis Polyzotis, Sudip Roy, & Steven Euijong Whang (2016). Goods: Organizing Google’s Datasets international conference on management of data. 

05

Q&A环节

Q1：核心数据是指的主数据吗？

A1：核心数据跟主数据是有差别的，核心数据这个定义是按业务来定义。我们在生产使用过程中是按最后业务方来定义的，比如我们某个部门经营的核心 kpi 的一个指标，这个指标表对业务来说是他非常核心的数据。把这个业务的核心指标的结果表就是可以定位一个核心数据。那我们在做这个链路保障的时候，就要把这个指标表对应以及上游的所有链路数据纳入核心数据来做优先级的调控，这是针对核心数据。主数据的定义是在多个系统跨系统引用，多个系统都要用到相同的一份数据；比如我们的员工数据，那我们可能在各个的数据平台的系统里面都要用到这个员工数据，那这个员工数据它本身就是主数据，它跟核心数据是从两个维度去表达的。我解释的不知道能不能解答这个同学的问题。

Q2：任务整个链路的优先级指的是离线处理、实时处理、资源分配都是优先其他的任务处理吗？

A2：这个任务优先级是针对主要以离线任务为主，因为实时任务其实没有优先级的概念，它是所谓的只要数据来了之后就会立马进行计算，所以它没有优先级的概念；它的资源是一直要保留资源一直计算的。而针对离线任务，因为我们不同的任务节点之间，它是有依赖关系的，所以优先级主要是针对离线任务这个板块。

Q3：整个核心任务的识别是自动的吗？

A3：核心任务的识别不是自动的，核心任务分两个角度来讲；第一个是哪些表、哪些的结果任务需要优先保障，这个是由业务提报过来；由大数据数仓同学审核之后才能生效的，这是一个人为的流程管控；但比如一个指标的结果表作为一个核心的任务节点了，再把当前的节点和上游所有节点任务的调成高优先级，这个调整的过程是自动的。但前面识别出哪些是核心的数据，这个不是自动的。

Q4：数据安全治理主要包括哪些内容？

A4：数据安全治理可能各家公司不一样，就讲一下翼支付的实际吧。数据安全治理我们包含数据安全规范的一个建立，数据存储加密改造就包含一些敏感性的加密存储，还有一些数据运营的管理；包括数据的使用下载，像数据下载这种就是非常高危的一个操作。我们会建立一个统一的下载中心，所有的平台的数据下载都要走这个平台进行下载，在这个台上会做好数据的管控、安全审计。当然有些公司还有第四个板块就是合作数据的一个管控，要跟第三方进行的数据合作，这个数据它是不是合规的，在这个层面如果也要公司有的话，它属于数据融通的一个过程，也是有安全和合规的一些要求的。一般是会从这四个方向去做那个数据安全的治理。

Q5：元数据采集使用的是 logstash 吗？

A5：logstash 就是类似于一种实时采集的时候使用，比如元数据发生变动，这里其实主要是分成两部分：第一个部分是离线采集，其实是一个跑批的过程。那么以 HIVE 为例，我们的跑批可能是指以一个比较长的时间里面去批量地采集 HIVE Metadata 的 mysql 数据库里面的数据信息进行一个存储。然后那个 logstash 是属于比如说实时更新，那么它的元数据有实时更新变动的话，那我们会接收到这相应的数据，然后去作为一个实时更新。所以其实采集分为两部分：一个是实时采集，一个是离线采集；然后我们离线采集使用的是直接去读元数据库进行采集；然后那个实时采集这边是类似于就像你说的 logstash，因为 logstash 比如像是 mysql、oracle。然后像 HIVE 其实它是有 HIVE Metadata 的服务通知机制去实现代替了。

Q6：原数据是具体怎么存在 Hbase 的？表结构如何设计的？

A6：这个其实我可以建议他去了解一下 Hbase 的一个相关原理，因为其实Hbase 是一个 k-v 形式的一个存储，它不是一个关系型存储数据库，它是有一个 CF（column family） 的概念，在 column family 的下面还有一个 column qualifier，Hbase 除了在那个 ppt 里面讲到了一个“盲写”的特性，可以不管是 insert 和 update 就直接写入了一个特性以外；还有个特性可以通过数据的插入直接去更新 column qualifier。也就说如果像类似于 mysql，我要去新增一个字段去更改表结构，做DDL操作去更新。但是 Hbase 是不需要的，它里面的 column qualifier 是取决于你的数据，也就说你数据里面有这个 column qualifir，它就会自动去帮你添加，不需要特别的去设计他的表结构。也就是说只要设计好 cf，那么 cf 下面的一些表的一些字段信息是取决于我们的插入的数据，这取决于元数据平台的具体设计了。这个也是 Hbase 的一个比较好的特性。

今天的分享就到这里，谢谢大家。