快手数据中台建设-元数据平台化建设及应用场景

hadoop123 2021-01-13

1769

本文主要对快手元数据平台的发展过程及当前架构和相关的应用场景进行了介绍，分析了如何进行抽象及管理数十种的资产、过亿的实体规模的异构元数据，并通过找数、全链路血缘、数据治理平台等几个主要的应用场景，展示了元数据在大数据平台中发挥的作用和价值。

1.背景介绍

元数据是关于数据的组织、数据域及其关系的信息，简言之，元数据就是关于数据的数据。本文中主要讨论大数据生产过程中数据资产的元数据，例如：数据表、生产任务、关联关系、血缘关系等。

建设元数据平台过程中都有哪些挑战？

从早期到现在，元数据在快手数据平台的发展过程中扮演着重要的角色，元数据平台的建设在数据平台的各个发展阶段都有独特的状态，也面临着各种挑战需要解决：

端到端元数据集成：从数据采集，到ETL加工，再到各类数据消费终端，元数据的集成会涉及整个数据生产生命周期；
异构化的元数据及复杂的关系：面对数十个平台&系统、大规模的数据资产及关系，需要统一的流程规范保证接入元数据的效率和质量，以及通用的存储引擎对亿级别实体及关系进行存储；
如何发掘元数据价值：与业务团队、数据团队合作，在数据治理、模型价值评估等方面产生价值；

为什么要建设元数据平台？

大数据平台在不同的业务背景及发展阶段下会有不同的问题出现，在快手也在面对着各种各样的问题需要解决，其中有很多问题都需要完善的元数据体系，所以我们一直非常重视元数据的建设，文本从四个与元数据关系密切的问题出发，结合实际的应用场景介绍解决这些问题的思路：

怎样找到需要的数据：面对海量的数据资产，在数据加工和使用过程中如何快速找到所需要的数据？
如何梳理出上下游关系：随着业务快速发展，数据生产链路逐渐变长，生产关系越来越复杂，如何准确高效的梳理出数据间、任务间的血缘关系，识别出关键生产链路？
数据治理靠什么来驱动：如何驱动资源治理、规范治理等，以及如何衡量治理效果？
数据资产的管理问题：海量的数据资产的归属、分级分类，识别隐私数据等管理问题如何解决？

2.建设过程及现状

这部分主要介绍元数据平台的发展过程，我们是如何抽象和管理元数据的，以及当前元数据系统的架构。

元数据平台发展

快手数据平台的发展阶段归纳为三个阶段：早期阶段：2018年以前，场景简单；发展期阶段：2018年～2019年，业务快速膨胀；现状：2020年之后，资产量大，开发人员多，实时性要求高。在这三个阶段，元数据平台也有对应的发展状态，可以通过这张图片做一个概括：

早期阶段（2018年以前）

只有Hive一种引擎，主要使用HiveETL任务进行数据加工；
数据资产规模不大，有数千张Hive表，过千的生产任务；
通过PostHook消息将Hive的元数据同步到Mysql一份，提供简单的查询；

发展期阶段（2018年～2019年）

多种计算引擎加入，业务快速发展，表的数量、任务的数量迅速膨胀，找数、管理需求出现；
生产链路变长，资源有限，需要任务分级，人工维护合理的优先级非常困难，通过PostHook消息构建离线血缘关系识别核心生产链路；
建设元数据管理系统，引入了ES构建搜索索引，支持数据资产名，描述信息等的搜索；

现状（2020年之后）

自研平台纷纷登场，元数据台接入了超过十种数据资产，管理十万级别生产任务、几十万级别的表；
存储、计算资源紧张，建设元数据离线仓库支持数据治理等；
业务发展节奏加快，对实时性要求也变高了，提供基于SQL解析的实时全链路血缘构建及查询能力；
新人加入团队的速度非常夸张，需要知识沉淀，通过数据地图支持分类检索、案例分享等功能进行知识沉淀；

如何抽象和管理

我们对目前在快手大数据生产过程进行了一个梳理，绘制了这张图，图中绿色的点代表数据节点，蓝色的点代表生产任务，黄色的点代表逻辑资产。生产过程主要分为三个步骤，分别是：采集、加工、消费。可以看到涉及的数据资产种类还是非常多的，并且其间的关系也非常复杂；

想要管理众多元数据，需要一套通用的抽象方法和管理方法，我们对元数据进行了抽象，主要涉及以下关键概念：

概念	说明	举例
实体	某种元数据的一个实例，有唯一标识，包含一组属性	一张Hive表一个指标一个调度任务
属性	构成实体的基本单位，可以是简单类型，也可以是复杂类型，由属性名、值类型及属性值构成	表名指标类型安全等级
关系	两个实体间的关联关系，可以是物理关系，也可以是逻辑关系，由关系名和两个端点的唯一标识构成	库表关系任务输入&输出关系指标绑定关系
URN	三段式全局唯一标识，由公司域、资产域、唯一ID构成	ks:hive/table:database_name/table_name

对于每种类型的元数据，都有不同的属性，为了方便管理，我们按照元数据属性的来源及用途，对常见的元数据属性分成了四类：

分类	说明	举例
基础元数据	引擎或平台提供的基本信息，一般直接从平台接入	表名原始Comment
资产元数据	在生产过程中由开发者维护的资产画像信息	描述资产等级负责人信
安全元数据	安全相关元数据，来自安全中心	安全等级权限负责人是否包含隐私数据
衍生元数据	由基础、资产、安全等其他元数据属性通过计算而来的属性	数据量大小查询次数

当前系统架构

元数据系统整体分为接收层，服务层，存储层。左右两侧分别是我们的主要接入方和应用方，接入方主要包括了大数据引擎、管理工具、开发平台及工具，应用方主要包括数据地图、开发平台、治理平台等。

接入层：适配不同元数据生产方，转换成标准定义，输出全种类实体、关系变更消息；
服务层：基于存储层提供单点、复杂查询服务，基于分析引擎提供分析服务；
存储层：基于图模型的实体、关系的存储与查询，支持统计与分析能力；

我们面对的元数据一般来说是异构的，自定义元数据模型信息是元数据系统必备的一个能力，核心存储服务中的一个关键模块--类型系统，支持自定义元数据的类型，维护我们需要管理的元数据的元数据，并在类型转换，查询转换中起到了关键作用。

3.应用场景

找数

数据分析同学和数据开发同学经常要面对的几个问题：计算xxx的数据在那张表？有多个类似的数据应该用哪个？对于前面这些问题，我们一直在建设数据地图产品并且不断进行优化，目标就是帮助用户快速找到所需数据；在找数这个方向上，我们积累了针对不同使用者的工具，像搜索、分类检索、案例分享等，这里主要介绍跟元数据最密切的搜索；

结合了大数据生产的特点和常规搜索引擎的思路，我们构建了基于元数据系统的数据资产搜索能力；我们通过元数据系统对相关元数据信息进行采集，转换成标准的元数据变更消息，通过这个消息以数据资产的粒度实时构建用于搜索的元数据索引，索引中包含数据资产的几部分关键信息用于召回：

基础信息

库表字段名
指标维度名
创建和更新时间

描述信息

表中文名
表描述
字段描述

关系信息

生产任务关系
数据与其他资产的绑定关系

标签信息

内容标签
热度标签
用户自定义标签

有了索引之后，就可以根据搜索关键词从索引中召回相关的数据资产，并从内容的相关性度给了一个粗排序，接下来要做的是精排序，这里目前我们主要有三类排序规则：

元信息完善度：资产类元数据属性的填写完整度，主要会考虑一些关键信息是否完备；
依赖数量：下游依赖数量，需要根据数据血缘关系进行统计；
运营规则：是否新模型，是否临时表；

精排序后取top N的条目，再补充上其他需要展示的属性，就是最终的搜索结果了。同时我们也通过页面埋点、设置负反馈按钮等方式采集到一些数据，并计算成右面的三个指标来评估当前搜索结果的好坏：

0点击率：一定程度上可以反映用户没有找到想要结果的比例；
平均点击排名：反映排序结果的好坏；
负反馈率：主观对搜索结果不满意的比例；

目前元数据搜索已支持6种数据资产，每日搜索超过1万次；

全链路血缘

元数据中的血缘关系在数据生产加工、数据治理中也有广泛的应用场景。

上图是通过一个简单的例子介绍血缘是如何构建起来的。主要会使用到元数据中表示关系的属性，例如输入、输出、绑定、关联等；

为了构建全链路血缘，我们对整个数据平台生产的生产关系做了梳理，主要涉及到这几种生产过程：

原始数据通过数据同步任务同步到数据仓库中；
数据仓库中离线定时任务进行加工，也会有数据同步任务进行引擎间的同步；
应用系统通过数据同步、绑定等方式进行数据的消费；

为了收集众多种类的关系，需要对接不同的系统，我们将关系来源进行归纳，主要分为两种进行接入：

数据生产任务的生命周期事件：离线调度任务、数据同步任务等的上线、更新、下线等；
自建平台生产关系：指标模型管理平台、报表平台等自研平台主动上报的生产关系或关联关系；

接收到事件后会由血缘解析模块对事件进行解析，主要会通过SQL或者用户配置解析出任务的输入输出关系，如果是SQL类型的任务，还会更近一步基于逻辑执行计划解析出字段级别依赖。通过血缘解析服务解析后，将关系经过存储层存储到图引擎来提供查询。查询功能主要包括：数据血缘层级、任务血缘层级、生产任务关系、全量上/下游，目前血缘服务覆盖支持的使用场景：

血缘查询：在数据地图中对某个数据资产的上下游进行树形展开后的结果进行展示，帮助数据开发同学、数据分析同学高效的找出数据的来源，数据的依赖方；
优先级推导：基线系统根据生产任务所属基线的优先级进行上游任务的优先级推导，使用血缘关系作为推导的依据，以便保障核心链路的稳定产出；
下线检测：在下线数据表、下线任务前对是否含有下游进行检测；

数据治理平台

在数据治理这个场景中，通常我们要面对下面几个问题：

资源浪费严重，包括存储与计算资源；
产出不规范，包括生产脚本书写不规范、依赖层级不正确这些情况；
元数据缺失，缺少描述信息、分类信息，或者维护不及时，给使用数据的同学带来困扰；
重要数据产出质量缺乏监控，得不到保障；

平台团队与数据团队合作，分别在数据规范、模型设计、产品交付、资源利用四个方向制定了可量化的指标体系，对治理项进行不同维度的打分，再根据不同指标的权重进行汇总，给出一个方向的总分，来评估个人或者团队在各个方向上的规范程度，最终以榜单的形式进行展示，来促进数据开发持续提升数据规范性。这个过程，主要依靠元数据离线仓库进行量化指标的落地，从数据、任务、产品几个方面提供了多种元数据。目前相关产品第一个版本已经上线，包含了四个方向19个指标，内部代号为“观象台”，开始在数据团队内部开始推广试用。

其他应用场景

实际上除了这三方面，元数据系统还有很广泛的应用场景，由于篇幅关系对于其他几个应用场景只做一个简单了解：

元数据查询：开发平台、指标模型管理、BI工具等通过元数据服务查询库表信息；
资产管理：通过系统采集的元数据信息，对数据资产进行集中管理，设置生命周期、安全等级等关键属性；
影响分析：支持查询当前节点全部下游，支持变更通知模块根据影响范围进行变更消息的发送；
价值评估：数据资产价值评估模型通过元数据中心提供的丰富的元数据得以落地；

4.未来规划

更好的搜索体验：针对大数据生产场景，数据资产间存在各种关系，通过图引擎的查询能力加持搜索功能，提供更好的搜索体验；
高质量元数据：在接入更全面的元数据内容同时，不断提高元数据质量；
离线分析能力：基于新一代元数据存储引擎提供离线元数据分析能力，快速支持数据治理等场景；
更细粒度血缘：目前已经提供了字段血缘甚至亚字段血缘的解析能力，但是这部分的准确性及如何在实际场景中发挥价值还需要持续进行探索；

作者简介：

薛言，17年加入快手，在数据平台先后负责过多个平台和系统，目前负责元数据系统及元数据应用相关建设。

快手数据工厂团队介绍：

快手核心大数据中台团队，为全公司构建业界领先的智能大数据生产和服务平台，赋能全业务线提升公司数据创新效率。目前涉及方向包括数据开发工具链（数据开发平台、大规模工作流调度、全链路质检平台）、数据流工具链（异构数据交换和同步、实时开发平台）、数据服务工具链（智能指标模型平台、百万级并发数据服务化平台）、数据管治工具链（全链路元数据平台、数据治理平台、数据地图、数据安全平台）。目前在寻找各类技术方向的Java和数据平台研发工程师，欢迎有识之士加入我们！

数据库

文章转载自hadoop123，如果涉嫌侵权，请发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。