导读 在传统的大数据元数据管理系统中，以 HiveMetaStore 为核心的架构存在诸多问题和挑战。随着数据湖大规模应用、AI 数据大量增长、数据安全与数据治理被更加被重视，我们难以基于原有的架构或组件实现一套统一的元数据管理系统，进而解决数据孤岛、统一权限，多维度数据治理等问题。因此，在 B 站 我们引入了 Gravitino，本次分享将介绍 Gravitino 在 b 站的最佳实践。其中包括了统一了多种数据源的元数据视图，统一跨数据源任务的 schema 信息，并且基于其中的 Fileset 概念对非结构化数据进行管理与数据治理，取得了可观的收益。
1. 元数据管理痛点剖析
2. Apache Gravitino 背景概览
3. Apache Gravitino 生产实践
4. Apache Gravitino 规划展望
分享嘉宾｜李天航 上海市哔哩哔哩科技有限公司 大数据开发工程师
编辑整理｜雷雪
内容校对｜李瑶
出品社区｜DataFun
元数据管理痛点剖析
![]()
上图左侧是我们在引入 Gravitino 之前的数据系统架构图。我们的元数据使用方主要包括我们最大的业务方数据平台，以及其它一些数据服务，如 SQL Scan，用于对 SQL 进行预检查，以及 SDM 数据智能编排服务等。除此之外，其它一些引擎也需要获取、增加、删除和查询元数据信息。业务侧耦合度过高：元数据的使用方调用异构数据源的方式多种多样。
数据治理能力有限：没有提供中心化的元数据管理服务，因此无法提供统一的审计、权限管理和调度能力。
对于半结构化和非结构化数据缺乏有效的管理，例如 Kafka 的 schema 和 HDFS 的文件等，还没有进行系统的管理。
跨源数据 schema 的维护成本较高。
Apache Gravitino 背景概览
1. 元数据管理中心化
![]()
基于以上痛点，我们想要引入一个中心化的元数据管理组件。需要实现以下几点，以达到理想的效果：（1）解耦元数据的使用方和各种组件，以降低元数据的使用成本。（2）跨源数据，我们需要维护一套统一的 Schema，以降低跨源数据的使用成本。这主要针对Kafka 消息主题消息的方案。（3）我们希望基于统一的元数据管理中心，提供统一的审计 TTL 特性和非结构化数据处理能力，例如 HDFS 的 TTL 和 EC。通过这种方式，我们可以实现数据治理并降低成本。（5）建立一个统一的权限管控机制，提高数据安全性。2. 元数据管理组件对比
![]()
我们调研了主流的开源元数据管理组件，包括 Metacat、WaggleDance 和 Open Metadata。这些组件存在以下缺点：它们对多引擎的支持有限，功能相对单一，仅提供了基本的元数据功能，难以扩展，社区活跃度有限，可能没有大版本更新和迭代计划。3. What is Gravitino？
![]()
基于以上调研，我们发现了 Apache Gravitino。它是一个高性能的元数据管理平台，可以处理不同类型的元数据和来自不同来源的数据信息。此外，它还提供 AI 数据资产管理能力。以下是 Gravitino 的整体架构图，它满足了我们对统一元数据的期望。![]()
第一层是数据应用层，包括数据平台、B 站等数据应用组件以及引擎，都通过这一层接入。第二层是接口层，目前 Gravitino 提供了 REST 统一接口，对外提供元数据的访问能力，并且还提供了 Thrift 和 JDBC 接口，供引擎进行具体接入。第三层是 Gravitino 的核心组件，其数据分类基于 Catalog 进行管理。不同数据源具有不同的 Catalog。整个层级架构基于 MetalLake Catalog Schema 和 Table 的概念。Schema 是我们通常理解中的数据库概念。对于 FileSet，文件管理也基于 Catalog。例如，Hive 是一个 Hive 的 Catalog，而 FileSet 则是我们所说的 HDFS 文件，它则是 FileSetCatalog。最底层是连接层，它连接了不同的数据源。例如，对于 Hive 表，其背后是 Hive MetaStore；对于 Iceberg 表，则是提供的统一 REST Catalog。此外，Gravitino 内部还维护了一套自己的存储系统。不过，需要注意的是，Gravitino 本身并不存储元数据，这部分主要用于维护 Gravitino 内部的一些数据，如 Catalog 和 Meter Lake 等信息。虽然它还处于项目早期阶段，但我们提到的很多问题都能得到社区的积极回应，而且越来越多的开发者加入了 Gravitino 的开发。4. Gravitino FileSet
![]()
FileSet 是一个包含多个 HDFS 文件的目录和集合，可以理解为一个文件集。用户使用 FileSet 来管理非表格数据，特别是在生产环境中，主要是 HDFS 文件。FileSet 映射到文件系统上的具体目录，从右图中可以看出，它遵循了 Gravitino 的标准架构，包括 MetaLake、Catalog、Schema 和具体 FileSet。每个 FileSet 都有具体的 HDFS 存储路径，还包括其他维护的 FileSet 元数据信息，如大小、文件数量、创建时间等。Gravitino 管理的 FileSet 将非表数据结构和表结构数据以统一的资产方式进行管理。用户可以通过 FileSet 轻松访问文件和目录，无需通过实际物理路径访问数据文件集。Apache Gravitino 生产实践
接下来，我们将介绍在 B 站上引入 Apache
Gravitino 的具体生产实践及其带来的收益。1. OneMeta：统一的元数据管理服务
![]()
首先，我们基于 Gravitino 搭建了一个内部组件 OneMeta。它对外提供了统一的元数据管理服务，底层仍然基于 Gravitino 实现。因此，当谈到 OneMeta 时，可以理解为与 Gravitino 等价。我们主要在 Gravitino 的 REST 和 REST 层接口上进行了扩展，并满足了用户的定制化需求。第二部分是 catalog 的扩展，包括定制化接口和下钻功能。实现了社区尚未提供的接口，例如根据用户的筛选条件筛选分区并加载文件及其具体元数据信息。此外，我们还支持批量查询等接口。虽然社区目前只支持管理到 FileSet 这一层级，但我们在此层级上做了下钻，支持浏览 FileSet 下子目录下的文件信息。第三点是我们降低了代码的侵入性，便于同步社区最新的代码。2. 元数据管理架构演进
![]()
第一个实践是基于 Gravitino 进行的元数据管理架构的演进。我们将 Gravitino 集成到 OneMeta 服务中，数据平台和其他数据组件，都通过 OneMeta 来进行统一的元数据管理服务，从而解耦了业务方的复杂依赖，降低了元数据的使用成本。第二点是我们提供元数据服务，解决了由于引擎和数据源之间的差异导致的元数据不一致问题。我们曾在生产中遇到过一些案例，例如，用户使用 Iceberg 表，其中一部分元数据信息存储在 Hive 元数据仓库中，而另一部分则由 Iceberg 自己维护。因此，用户需要从两个不同的地方获取两份数据。现在，用户只需从一个地方获取相应的元数据信息即可，还能避免数据不一致的问题。第三点是解决了 Hive MetaStore 造成的性能瓶颈。当删除大表时，如分区数过多，有些表会无法删除；二是在线上遇到几十万张、几十万个分区的表时，直接使用 metastore API 删除会失败。我们的解决方案是先将所有分区删除，然后再删除整个表。
对于我们使用的元数据平台，每天都会用定时任务发起 getTable 请求获取线上全量表的数据结构。Gravitino 在对 Hive MetaStore 的连接上中有池化和并发处理，连接 Hive
MetaStore 的速度非常快。我们的数据平台替换为从 Onemeta 获取元数据后，接口响应时间大约降低了70%。
3. 跨数据源 Schema 管理现状
![]()
在引入 OneMeta(Gravitino)前，用户可以通过两种方式管理跨数据源 Schema：使用 memory-catalog，需要手动编写 DDL 进行加载，并指定具体的 schema 形态和 Kafka 连接信息；使用 keeper-Catalog，可以加载缓存在上层的元数据信息。但存在缺陷，如用户需要注明 Kafka 的集群链接、schema 维护成本较高，并且整个系统也产生了反向依赖，还容易出现上下游 schema 不一致的情况，导致任务无法成功运行。![]()
我们希望用户不再需要手动编写 DDL 和指定 Kafka 的连接信息，只需指定一个具体的 Kafka topic name 即可启动 Flink 任务。Flink 会在启动时通过 catalog 向 meta 读取相关信息。4. 跨数据源 Schema 管理优化
![]()
我们将以 PB 为例，介绍如何进行基于 Gravitino 的 Kafka 去 DDL 生产实践。目前，我们在生产中支持 Kafka 的消息格式，包括 JSON、分隔符和 PB。以 PB 为例，我们实现了基于 PB 打包编译全闭环的跨域 schema 管理。具体流程是：（1）用户上传 PB 文件至 PB manager 编译，产物信息传给 OneMeta。OneMeta 则存储在 Kafka Schema Registery。（2）Flink 启动新任务时，需要根据 topic name 获取该 topic 的具体 schema 信息，OneMeta 从 KSR 存储中获取具体产物信息并返回给 Flink。（3）Flink 使用类加载器进行解析编译好的 schema。![]()
（1）实现了中心化的 Kafka 原始信息管理，避免了数据不一致性的问题；（3）降低了任务维护成本，提高了 Flink 任务的上线效率。![]()
B 站内部 HDFS 文件治理数据量达到了 EB 级别，其中非表路径占总存储的 30%。在 AI 商业场景下，HDFS 存储量的增长较高，存在大量未被规范管理的 HDFS 路径。用户需要将 Airflow 原来的路径管理逻辑迁移到我们的大数据平台上。目前我们对 Hive 路径进行了 EC 和 TTL 操作，非表路径存在大量 EC 和 TTL 治理需求。6. Fileset 文件管理
![]()
FileSet 是文件集的概念，是我们内部大数据平台管理页面的基础。这个页面直接面向各种数据分析、AI 和商业数据分析师使用。图中是基于 FileSet 的管理页面，用户不断向下点击以获取子目录或子目录下的特定文件，支持对 FileSet 等进行模糊查询等功能。![]()
我们已经使用 Fileset 将 HDFS 文件管理起来，因此我们希望能够基于 FileSet 对 HDFS 进行具体文件治理，以达到降本增效的效果并获得收益。以下是基于 FileSet 文件治理的主要流程图。FileSet 文件治理主要分为两个部分，即 EC 和 TTL，它们的实现逻辑和架构都类似。（2）通过 OneMeta 对相应 FileSet 进行 TTL 和 EC 打标；（3）SDM（智能数据管理）读取 OneMeta tag，向 HDFS Server 发送 TTL 和 EC 指令；目前我们正在推进和建设 HDFS EC，预计可以减少约 100PB 的存储成本。对于基于 FileSet 对 HDFS 文件进行的 TTL，我们可以减少约 300PB 的存储成本。![]()
接下将介绍 FileSet 在 AI 文件管理中的具体应用，这里的 VIEWFS 对应的是 Gravitino 社区的 GVFS 概念。FileSet 不仅可以通过前端页面让用户进行管控，还支持用户通过 Spark JAR、Spark SQL 和 Python 客户端进行操作。例如，在 Spark 下，我们可以直接在 Spark 代码中读取和写入 FileSet。用户可以直接使用这种格式，无需引入任何外部依赖或升级 HDFS Client。具体的实现方法将在后续章节中详细介绍，只需将原来依赖的 HDFS 物理路径替换为 FileSet 即可。对于 Python 客户端，不需要引入任何依赖，只需修改写法即可。用户从物理路径切换到推荐的文件系统非常便捷，一旦接入 FileSet，元数据信息就能得到更好的维护。此外，FileSet 还提供了文件交接和其他信息查看等便利功能。7. GVFS 技术实现
![]()
在 HDFS Client 中内置 NNproxy，当用户传入 gvfs:// 时，根据 Mapping Cache 获取映射关系。解耦用户与 hdfs 实际路径，用户使用 VIEWFS 功能无需添加对应依赖，无需升级对应 HDFS Client 版本。所有需要使用 HDFS 或 FileSet 的用户，他们可以直接将原来的 HDFS 路径书写成我们推荐的格式。HDFS client 会将对应的 FileSet 格式路由到 Nproxy 上，并定时地加载 meta 信息。用户就不需要升级 HDFS client，也不需要添加其他依赖，就能实现从原来的输入物理路径到直接输入 FileSet。Apache Gravitino 规划展望
![]()
最后介绍一下 Apache Gravitino 的规划与展望。基于 Gravitino 进行统一权限管理，
完善 AI 场景下的元数据治理。
希望为 UDF 数据提供数据资源管理的能力。
打造更完善的数据血缘。
将更多的内部数据源接入 Gravitino，实现统一管理。
李天航，Bilibili 大数据开发工程师，Apache Gravitino contributor，专注于大数据场景下的元数据管理 & Spark 计算引擎优化。
