元数据是用来描述数据的数据。请参见图2 。从抽象来看，包括分为实体、实体的属性以及实体与实体之间的关系三个方面来进行分类。实体主要指表元数据和作业元数据，来自于工程师在ETL的实际工作中所涉及到的系统。如：Hive、Doris、Kudu、MQ、ES、Iceberg，即传统的数仓及上下游。

比如：实体包含了技术元数据和生产元数据。其中技术元数据用于支撑数据资产管理的资产地图；生产元数据，主要是作业的一些调度信息和运行信息，用于支撑数据资产管理的数据质量和成本治理的服务。

实体的属性，包含业务元数据和衍生元数据。

业务元数据包括数仓分层、数据分类、指标关联、应用信息、隐私分级等内容。内容来源于建模规范、业务、指标系统、BI看板、数据报表，以及来自于业务的隐私分级定义等。业务元数据用于支撑资产管理的资产价值、安全治理以及规范治理。

衍生元数据包含元数据的存储计量和访问计量。存储计量是服务于存储层面的成本治理；访问计量用于描述数据的使用情况，从技术角度去衡量资产的价值。衍生元数据来源于ETL工作中涉及的HDFS-Image、Doris、Kudu、MQ、ES以及HDFS-Log、SQL-Log。

描述实体的关系，包括血缘元数据，用于描述元数据之间的关联关系，用于支撑数据资产管理中的影响分析和资产地图服务。

图 2 元数据分类

小米元数据平台的技术架构如图3所示，整体架构与Apache的Atlas非常相似。

整体上可以划分为三层。最上层是数据采集的源头，以及最终数据支撑的应用，包括Metadata Source、Lineage Source、Log Source和应用Application。中间层是集成层，集成层是由Metacat、MQ以及API层组成。最底层是核心的存储层。

最上层的Metadata Source用于对表元数据采集。最早只限于Hive表，后来实现了全域元数据的采集。主要包括ETL整个生产链路及上下游的全链路。比如：元数据采自于业务的Mysql数据库。其中消息队列采用了小米自研的Talos，简单说实现了数据集成与分发的总线。而下游元数据的采集由Hive、Doris、ES、Kudu等实现。

图 3 元数据平台技术架构 

Lineage Source实现血缘信息采集。血缘元数据是来自于从各个计算引擎。通常血缘元数据是通过SQL的查询入口或者调度入口去采集。由于小米的业务特别多，且部门各自独立，因此入口也特别多，很难通过常规的入口采集的方式提升数据采集覆盖率。考虑到各部门的计算引擎都是在部门的计算平台进行维护，从而可以在引擎侧打点，实现血缘元数据的采集。同时结合SQL入口对SQL的审计日志做补充，两者的数据进行合并，得到较为满意的血缘元数据采集及采集覆盖率。

Lineage Source中的DataHub是小米内部的数据集成平台，包括离线整理集成和实时集成。DataHub集成平台也有上下游的血缘关系，也进行血缘元数据的采集。

日志层面调度日志、计量日志以及运行日志。这些日志跟质量建设和访问相关。Application应用，包含数据平台的上层应用、数据地图、成本治理、规范治理等内容。

在中间层的Metacat，是在采集诸多原图的元数据时，提供一个统一元数据的视角。所以通过基于Metacat进行二次定制开发，实现内部的各个系统的适配。元数据的采集统一通过Metacat实现，包括T+1和增量变更，都要通过Metacat来实现。因此，Metacat与Messaging连接起来，Metacat把每天增量变更送到Messaging。之后包含血缘信息的日志通过Messaging送到数据总线，使下游层面可以使用这些数据，通过API为上层应用提供数据服务和支撑。

最底层的存储部分，基本信息都存储在Mysql中；T+1的快照存储在Hive中；血缘图关系存储在JanusGraph。元数据的检索，包括权限的检索过滤、审计检索等都放在ElasticSearch。 

元数据平台进化过程中，关键的演化点之一是全域元数据。之前提到元数据都是基于Hive进行管理，显然只能看到Hive层的数据，无法知道产生的Hive表，到下游后最终有没有被使用。举例来说，有一堆数据给上层应用，用于看板或者指标，产生了一张Doris表；但对应的看板可能并没有人看，所以可以通过倒推，把链路中的这一条链路进行优化或者治理。而实现这样的场景，就需要打通全链路，包括看板信息，搜索等，都需要全域元数据进行支撑。此时就需要进行域拓展。以Hive为中心去看上下游，包括上游的业务数据库、Messaging，下游的Doris、Kudu、ES，包括内部重构传统Hive 数仓的Iceberg，都要采集元数据。在实现全域的过程中，同时打开统一元数据的Hive Metastore，实现统一的表数据视角和管理。请参见图4。

图 4 实现全域元数据

关键的演化点之二是实时血缘。如前所述，小米入口非常多，血缘关系采集很难实现面面俱到。最早采用解析HDFS日志的办法，存在血缘很难正确解析的问题。例如：读一个表，可能会有很多open操作，这些Open操作很难对应表和表之间的关系，就会带来血缘关系不准的问题。早期的解决方案是找出所有的读和写操作后，做一个笛卡尔乘积，但这样就会产生大量不存在的血缘。

以上这些痛点严重影响了上层的数据治理，影响了解决问题的溯源过程。此外解析日志，由于只能T+1，认知量也比较大；而如果出现一个流式数据，就根本无法解析。这些都与通过SQL解析、能确定血缘的情况完全不同。

所以在进化版的新版方案中，考虑到 了入口问题和引擎接入的改造成本问题。方案最终采用实时引擎MQ埋点的方案。同时各个引擎本身要去执行这个SQL，比如Hive、Flink、Spark等，包括Presto、Distcp。因为需要执行这种操作，本身就需要去解析执行计划。而Spark、Flink也都支持对这些操作。通过对血缘关系的解析进行了内部改造（请参见图5），整体运行流畅。同时结合SQL Proxy Log去做血缘关系整合，从而实现血缘关系的精准解析。

图 5 元数据实时血缘

关键的演化点之三是精准计量。精准计量目前还不能做到完全精准的计量，但是解决了计量的零和一的问题。在最早的入口问题中，计量不准就无法对数据的冷热程度进行判断。比如用户操作Hive表，会有各种各样的形式，通过各种各样的SQL。

尤其研发的种查询需求就很难应对。比如：Spark SQL分为常驻服务和非常驻服务，都是为了解决Spark SQL作业执行的启动问题。非常驻服务与Hive  SQL一样，每次都要有一个启动过程。常驻服务则可以及时响应SQL需求，直接执行，减少了几分钟的启动过程，其查询过程能够快速响应。还有Flink SQL、Beeline、Flink  Jar和Spark Jar，包括Distcp想去覆盖这些入口的计量，访问情况的确定也是解析HDFS日志。通过这些日志解析血缘存在的问题，就是在Hive  Jar的层面，无法确定上层谁提交的访问。

计量部分现阶段解决了零和一的问题。简单的说当数据被访问后，能基本保证打上数据访问的标记。同时，通过与HDFS日志提供的足够信息、进行精准的统计和整理，并结合顶层的SQL审计进行修正后，可以得到具体被访问次数的精准计量。请参见图6。

图 6 元数据精准计量

下面在元数据平台建设的基础上，讲述小米元数据应用在以下四个方面的进展：