数据中台实战(04)-打造高效数据中台，元数据中心是关键！

太过爱你忘了你带给我的痛 2024-03-17 21:48 45阅读 0赞

上文从宏观系统性了解数据中台建设的方法论、支撑技术和组织架构。

本文开始进入实现篇，微观带你具体分析数据中台的支撑技术，以电商场景为例，分别讲解元数据中心、指标管理、模型设计、数据质量等技术如何在企业落地。

### 1 元数据 ###

数据中台的构建，要确保全局指标的业务口径一致，要梳理原口径不一致、重复指标，整合成一个统一的指标字典。这工作前提，是搞清这些指标的业务口径、数据来源和计算逻辑。这些数据都是元数据。

如无这些元数据，就没法梳理指标，更谈不上构建一个统一指标体系。当你看到一个数700W，如你不知这数对应指标是日活，就无法理解这数据的业务含义，也就无法整合这些数据。所以你要掌握元数据的管理，才能构建数据中台。

那么问题来了：元数据中心应该包括哪些元数据呢？ 什么样的数据是元数据？

### 2 元数据的分类 ###

元数据划为三类：数据字典、数据血缘和数据特征。

#### 2.1 数据字典 ####

![ad44e2f8b3c44538beabdfd68bb4ffdf.png][]

dwd\_trd\_order\_df 是一张订单交易明细数据，任务flow\_dws\_trd\_sku\_1d 读取这张表，按照sku粒度，计算每日sku的交易金额和订单数量，输出轻度汇总表dws\_trd\_sku\_1d。

数据字典描述的是数据的结构信息，我们以dws\_trd\_sku\_1d为例，数据字典包括：

![ded499d681504c888585d5b899692fe6.png][]

#### 2.2 数据血缘 ####

一个表是直接通过哪些表加工而来，上例，dws\_trd\_sku\_1d通过dwd\_trd\_order\_df的数据计算而来，所以，dwd\_trd\_order\_df是dws\_trd\_sku\_1d的上游表。

数据血缘帮我们做影响分析和故障溯源。如有天，老板看到某指标数据违反常识，让你排查这指标计算是否正确，你先要找到这指标所在表，然后顺这表上游表逐个排查校验数据，才能找到异常数据根源。

#### 2.3 数据特征 ####

主要指数据的属性信息，以dws\_trd\_sku\_1d为例：

![img][]

元数据种类很多，为管理这些元数据，须构建元数据中心。

来看如何搭建一个元数据中心，打通企业的元数据。

### 3 元数据中心的业界标杆 ###

学习业界优秀产品：

*  Netflix的Metacat、Apache Atlas
 *  商业化产品Cloudera Navigator

来看Metacat和Atlas这两款产品：

*  一个擅长管理数据字典
 *  一个擅长管理数据血缘

了解这两款产品，更能深入理解元数据中心的设计。

#### 3.1 Metacat 多数据源集成型架构设计 ####

[Metacat][]，多数据源的可扩展架构设计，对数据字典管理很重要。

![6470d2105ab3432eac39eaa60a90d1a2.png][]

一般公司中，数据源类型非常多，如Hive、MySQL、Oracle、Greenplum。支持不同数据源，建立一个可扩展的、统一的元数据层很重要的，否则你的元数据是缺失的。

Metacat设计巧妙，没单独再存一份元数据，而是采取直连数据源拉的方式：

*  它不存在保存两份元数据一致性的问题
 *  这种架构设计很轻量化，每个数据源只要实现一个连接实现类，扩展成本低

我称为集成型设计。对希望构建元数据中心的企业很有借鉴意义。

#### 3.2 Apache Atlas 实时数据血缘采集 ####

[Apache Atlas][]，实时数据血缘采集的架构设计，它为解决血缘采集的准确性、时效性难题提供很多解决思路。

##### 3.2.1 血缘采集方式 #####

*  静态解析SQL，获得输入表和输出表
    
    面临准确性的问题，因为任务没有执行，这个SQL对不对都是一个问题
 *  实时抓取正在执行的SQL，解析执行计划
    
    比较理想的实现方式，而Atlas 就是这种实现。
 *  任务日志解析的方式，获取执行后的SQL
    
    血缘虽然是执行后产生的，可以确保是准确的，但是时效性比较差，通常要分析大量的任务日志数据。

![f78015319136449f83a56a4047c20bbd.png][]

对于Hive 计算引擎，Atlas 通过Hook方式，实时地捕捉任务执行计划，获取输入表和输出表，推送给Kafka，由一个Ingest 模块负责将血缘写入JanusGraph图数据库中。然后通过API的方式，基于图查询引擎，获取血缘关系。对于Spark，Atlas 提供了Listener的实现方式，此外Sqoop、Flink 也有对应的实现方式。

这两款产品在设计网易元数据中心时，给了很多灵感，下面我就带你了解一下网易元数据中心的设计，以便你掌握一个元数据中心在设计时应该考虑哪些点。

### 4 元数据中心设计实战 ###

#### 4.1 元数据中须实现的关键目标： ####

##### ① 多业务线、多租户支持 #####

在网易，电商、音乐都是不同的业务线，同一个业务线内，也分为算法、数仓、风控等多个租户，所以元数据中心必须支持多业务线、多租户。

##### ② 多数据源的支持 #####

元数据中心必须要能够支持不同类型的数据源（比如MySQL、Hive、Kudu等），同时还要支持相同数据源的多个集群。为了规范化管理，还需要考虑将半结构化的KV也纳入元数据中心的管理（比如Kafka、Redis、HBase等）。这些系统本身并没有表结构元数据，所以需要能够在元数据中心里定义Kafka每个Topic的每条记录JSON中的格式，每个字段代表什么含义。

##### ③ 数据血缘 #####

元数据中心需要支持数据血缘的实时采集和高性能的查询。同时，还必须支持字段级别的血缘。

什么是字段级别的血缘，我们来举个例子。

> insert overwrite table t2 select classid, count(userid) from t1 group  
> by classid;

t2表是由t1表的数据计算来的，所以t2和t1是表血缘上下游关系，t2的classid字段是由t1的classid字段产生的，count字段是由userid经过按照classid字段聚合计算得到的，所以t2表的classid与t1的classid存在字段血缘，t2表的count分别与t1表的classid和userid存在血缘关系。

![img][img 1]

字段血缘在做溯源的时候非常有用，因为大数据加工链路的下游是集市层，为了方便使用者使用，一般都是一些很宽的表（列很多的表，避免Join带来的性能损耗），这个表的上游可能是有几十个表产生的，如果不通过字段血缘限定溯源范围，就会导致搜索范围变得很大，无法快速地精准定位到有问题的表。

另外，数据血缘还必须要支持生命周期管理，已经下线的任务应该立即清理血缘，血缘要保留一段时间，如果没有继续被调度，过期的血缘关系应该予以清理。

##### ④ 与大数据平台集成 #####

元数据中心需与Ranger集成，实现基于tag的权限管理方式。在元数据中心中，可为表定义一组标签，Ranger可基于这标签，对拥有某个标签的一组表按相同权限授权。

这大幅提高权限管理效率。如对会员、交易、毛利、成本，可设定表的敏感等级，根据敏感等级，设定不同人的查看权限。

元数据中心作为基础元数据服务，包括自助取数分析系统，数据传输系统，数据服务，都应基于元数据中心提供的统一接口来获取元数据。

##### ⑤ 数据标签 #####

对表和表中的字段打标签，通过丰富的不同类型的标签，可完善数据中台数据的特征，如指标可作为一种类型的标签打在表上，主题域、分层信息都可作为不同类型的标签关联到表。

基于这几大因素设计的元数据中心：

![de9fb02b9be34d439384113ecf5545b4.png][]

这图按功能模块分为：

#### 4.2 数据血缘 ####

由采集端、MQ、消费端及血缘清理模块组成，基于Hive Hook，Spark Listener，Flink Hook ，可获取任务执行时输入表和输出表，推送给统一MQ（Kafka），然后消费端将血缘关系沉淀到图数据库。

图数据库选Neo4j，主要考虑性能快、部署轻量化、依赖模块少，开源Neo4j无高可用方案且不支持水平扩展，但因单业务活跃的表规模基本也就在几万，单机够用，高可用可双写来实现。

血缘还有个清理的模块，负责定时清理过期的血缘，一般把血缘的生命周期置7天。

#### 4.3 数据字典 ####

参考Metacat实现，由统一的Connector Mananger负责管理到各数据源的连接：

*  对Hive、MySQL，元数据中心不会保存系统元数据，而是直接连数据源实时获取
 *  对Kafka、HBase、Redis等KV，在元数据中心里内置一个元数据管理模块，可在这模块中定义Value的schema信息

#### 4.4 数据特征 ####

主要是：

*  标签的管理
 *  数据的访问热度信息

元数据中心内置不同类型的标签，同时允许用户自定义扩展标签类型。指标、分层信息、主题域信息都以标签形式存储在元数据中心的系统库，同时元数据中心允许用户基于标签类型和标签搜索表和字段。

元数据中心统一对外提供了API访问接口，数据传输、数据地图、数据服务等其他子系统都能通过API接口获取元数据。Ranger可基于元数据中心提供的API接口，获取标签对应的表，再根据标签更新表对应的权限，实现基于标签的权限控制。

元数据中心没有UI吗？用户咋用这元数据中心？

### 5 数据地图：元数据中心的界面 ###

数据地图，基于元数据中心构建的一站式企业数据资产目录，可看作元数据中心的界面。

数据开发、分析师、数据运营、算法工程师可在数据地图完成数据检索，解决很多难题：

*  不知道有啥数据
 *  到哪找数据
 *  如何准确理解数据

![3692c88ec0694eb5bab94b6e2f2a0f9a.png][]

数据地图提供多维度检索功能，使用者可按表名、列名、注释、主题域、分层、指标检索，结果按匹配相关度排序。考虑数据中台有一些表是数仓维护的表，有一些表数仓已不再维护，在结果排序时，增加了数仓维护的表优先展示的规则。数据地图还提供按主题域、业务过程导览，可帮助使用者快速了解当前哪些表可用。

![05d3816596844493bbf64d9999e43299.png][]

当使用者定位到某个表打开时，会进入详情页，详情页中会展示表的基础信息，字段信息、分区信息、产出信息以及数据血缘。数据血缘可帮助使用者了解该表的来源和去向，这表可能影响的下游应用和报表，这个表的数据来源。

![img][img 2]

数据地图同时提供数据预览功能，考虑安全，只允许预览10条数据，用于判断数据是否符合使用者的预期。数据地图提供的收藏功能， 方便使用者快速找到自己经常使用的表。当数据开发、分析师、数据运营找到自己需要的表时，在数据地图上可以直接发起申请对该表的权限申请。

数据地图对于提高数据发现的效率，实现非技术人员自助取数有重要作用。经过我的实践，数据地图是数据中台中使用频率最高的一个工具产品，在网易，每天都有500以上人在使用数据地图查找数据。

### 6 总结 ###

本文以元数据作为起点，学习到：

*  元数据包括数据字典、数据血缘和数据特征
 *  然后通过分析两个业界比较有影响力的元数据中心产品
 *  结合国内的数据中台实践，给出元数据中心设计的关键特性和技术实现架构
 *  最后介绍基于元数据中心之上的数据地图产品

最后强调：

*  元数据中心设计须注意扩展性，能支持多数据源，宜采用集成型设计
 *  数据血缘需支持字段级血缘，否则影响溯源范围和准确性
 *  数据地图提供一站式数据发现服务，解决检索数据，理解数据的“找数据的需求”

元数据中心是数据中台的基石，它提供了我们做数据治理的必须的数据支撑，在后续的章节中，我们将逐一介绍指标、模型、质量、成本、安全等的治理，都离不开元数据中心。

![aa168fe2b7e8427aab3c30c77e029739.png][]

### FAQ ###

血缘采集的三种方式，并推荐了通过实时采集，但其实静态解析血缘也有优势应用场景，你能想到有啥？

静态解析血缘通常用于分析和理解已有的代码或数据流程，可以帮助开发人员更好地理解代码的结构和依赖关系，从而更好地维护和更新代码。

静态解析血缘还可用于代码审计和安全分析，帮助检测潜在的漏洞和安全问题。

[ad44e2f8b3c44538beabdfd68bb4ffdf.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/bc967a5a6ac54875a0890f390824594b.png
[ded499d681504c888585d5b899692fe6.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/be85a05d70f4433fbd1d648912464e50.png
[img]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/74bb9f97b5fa44e99810169d8bc82348.png
[Metacat]: https://github.com/Netflix/metacat
[6470d2105ab3432eac39eaa60a90d1a2.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/14b65df76ccf400f9b8620d5988301a0.png
[Apache Atlas]: http://atlas.apache.org/
[f78015319136449f83a56a4047c20bbd.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/b1aa87d7302943b5870492935dc3cd4c.png
[img 1]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/66f7e412fe274a0392dbe809eba173d1.png
[de9fb02b9be34d439384113ecf5545b4.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/ca04f55ff61243af943c38d3c0db976f.png
[3692c88ec0694eb5bab94b6e2f2a0f9a.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/e8b22515796a4efd982834c139e892d7.png
[05d3816596844493bbf64d9999e43299.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/4eb756136f444a0483cd140cf9ac4800.png
[img 2]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/ae79421fabf4449dbfce58437a5903fb.png
[aa168fe2b7e8427aab3c30c77e029739.png]: https://image.dandelioncloud.cn/pgy_files/images/2024/03/14/8cdfefcd0c6a42cf8ef02578b4dc1d68.png