数据中台选型必读（一）：元数据管理是数据使用与共享的根基

在上个系列：数据中台的前世今生中，我们介绍了随着时代发展，为解决呈指数增长的数据分析需求而出现的一系列技术和产品，从数据仓库、数据湖到大数据平台再到数据中台。

而数据中台的核心，就是解决数据孤岛问题，强调数据统一管理和避免重复造轮子，是对数据服务的共享以及复用。

某数据中台架构

架构数据中台，就要确保全域指标业务口径一致。因此，首先就需要梳理原先口径不一致的、重复的指标，从而整合成一个统一的指标字典。

这项工程的前提——厘清这些指标的业务口径、数据来源和计算逻辑，而关于指标的一切信息，就是元数据（Metadata），它也被形象地称为“描述数据的数据”。

01

元数据及其分类

“173、185、90、87...”看到这样一串数字，大家会想到什么？

“身高”、“体重”还是公司员工的“代号”？当没有一个描述和定义的时候，数据会变得没有意义。而元数据就是描述数据的数据，就类似一列数据的列名一样。

在数据中台领域中，一般将元数据划为三类：数据字典、数据血缘和数据特征。

数据字典：诸如表名、注释信息、表的产出任务、表字段信息、含义和字段类型等，描述数据的结构信息（如图）；

数据字典

数据血缘关系：描述表的继承关系，由哪些表经过哪些计算任务得到的。数据血缘一般会帮我们做影响分析和故障溯源。

比如有一天，你的老板看到某个指标的数据违反常识，让你去排查这个指标计算是否正确，你首先需要找到这个指标所在的表，然后顺着这个表的上游表逐个去排查校验数据，才能找到异常数据的根源。

数据特征：数据的属性，比如存储空间大小、访问热度、主题域、分层、表关联指标等（如图）。

数据特征

在实际的业务场景中，元数据的种类非常多，因此，为了管理这些元数据，此时必须要构建一个元数据中心。

02

元数据管理——Metacat

当前，业界已经存在很多元数据管理产品，我们先通过这些产品了解元数据管理，再看如何搭建数据中台的元数据中心。

Metacat擅长管理数据字典，Apache Atlas擅长于管理数据血缘，在这里，我们重点介绍这两款产品。

元数据管理概念图

Netflix拥有自创的大数据平台，其大数据平台的核心架构涉及三项关键服务：执行服务（Genie）、元数据服务和事件服务。

多年前，当Netflix使用Pig作为ETL 语言，Hive作为专用查询语言时，发现由于Pig本身并不具备元数据系统，因此，考虑是否需要构建一个可以在两者之间进行互操作的方案。

于是，在这样的背景下，Metacat诞生了。

这个系统本质上是数据源可扩展的集成式设计（如图）：充当了所有数据存储的元数据访问层，是各种计算引擎可以用来访问不同数据集的集中式服务。

数据源可扩展的集成式设计

这样的理念和架构，正好印证了Metacat的三个主要目标：

元数据系统的联合视图

用于数据集元数据的统一API

数据集的任意业务和用户元数据存储

在实际的场景中，公司普遍存在大量多源异构的数据，其数据源包括Hive、MySQL、Oracle、Greenplum等。

支持不同数据源，建立一个可扩展的、统一的元数据层非常重要的，否则公司的元数据是缺失的。

从上面Metacat的架构图中，可以看到：Metacat的设计非常巧妙，它并没有单独再保存一份元数据，而是采取直连数据源拉取的方式。

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

03

Apache Atlas

Apache Atlas本质上是一个可扩展的核心基础治理服务集，使企业能够有效地和高效地满足 Hadoop中的合规性要求，并允许与整个企业数据生态系统的集成。

这里重点了解实时数据血缘采集的架构设计，血缘采集，一般可以通过三种方式：

第一，通过静态解析 SQL，获得输入表和输出表；

第二，通过实时抓取正在执行的 SQL，解析执行计划，获取输入表和输出表；

第三，通过任务日志解析的方式，获取执行后的 SQL 输入表和输出表。

第一种方式，面临准确性的问题，因为任务没有执行，这个SQL对不对都是一个问题；第三种方式，血缘虽然是执行后产生的，可以确保是准确的，但是时效性比较差，通常要分析大量的任务日志数据。

因此，第二种方式，相对是比较理想的实现方式，Atlas也正是通过这种方式实现元数据的血缘采集（如图）。

Apache Atlas产品架构

对于Hive计算引擎，Atlas通过Hook方式，实时地捕捉任务执行计划，获取输入表和输出表，推送给Kafka。