TBDS Metaservice 引领新时代的元数据管理创新

本文共计4848字 预计阅读时长15分钟

随着大数据生态的不断发展，大数据要承接的业务也越来越多样化。从传统的数据仓库到数据湖，再到Data+AI，大数据的边界一再拓展，同时大数据内各个存储、计算组件模块也在不断地推陈出新。

如何能在湖、仓、AI等场景中对不同的存储组件做统一，对多样的计算组件提供相同的服务呢？答案就是我们需要一个开放统一的元数据服务，在规范元数据访问标准的同时，解耦各个大数据组件之间的依赖。所有的组件都使用相同的元数据标准，大数据平台可以成为一个真正按需组合集成的高效系统。

旧元数据服务遇到的新挑战

Hive Metastore 是 Apache Hive 的一个关键组件，它提供了一个集中式的元数据存储，Metastore 使得 Hive 能够像传统的关系型数据库一样，支持复杂的查询和数据分析。而且随着大数据生态系统的不断发展，越来越多的计算引擎，比如Spark、Flink、Presto、Impala开始兼容并采用 Hive Metastore 作为其元数据服务核心，通过与 Hive Metastore 的集成，这些计算引擎能够共享和访问统一的元数据，从而实现跨平台的数据查询和分析。

这种兼容性和集成带来了多个好处，比如元数据的统一管理、对不同引擎提供一致的元数据服务等等，然而随着数据湖和 AI 场景在数据领域的迅猛发展，Hive Metastore 面临着一系列新的问题和挑战。

1) 性能方面，由于 Hive Metastore 数据模型严格遵守数据库三范式，并未充分考虑高并发场景下的优化。当表和分区数量非常庞大时，Hive Metastore 简单的索引不足以应对复杂的查询需求，非常容易遇到性能瓶颈。

2) 扩展性方面，AI 应用通常需要管理和访问大量的非结构化数据、非关系型数据。当前的 Hive Metastore 在 API 语义层面难以支持。

3) 兼容性方面，Hive Metastore 主要设计用于支持 Hive 表格式，对于其他新兴的表格式（如Iceberg、Paimon、Hudi 等）的支持和优化不足（比如饱受诟病的 Iceberg 表加锁问题），这种兼容性问题会导致在多表格式环境中进行数据管理和查询时出现困难，限制了数据湖的灵活性和可操作性。

为了应对 Hive Metastore 的局限性，业界进行了多方面的尝试、改进或替换，比如：

1) 通过引入分布式存储和缓存机制，提升元数据查询的速度；通过优化元数据存储结构，减少存储空间占用；通过增强兼容性，确保与新兴数据处理工具的无缝集成；

2) AWS Glue 在完全兼容 Hive Metastore 接口的基础上，增加了更多高阶功能；

3) 而 Databricks 的Unity Catalog 和 Snowflake 的 Polaris 则选择直接抛弃 Hive Metastore，从头搭建了新型的元数据管理服务。

然而深度优化还是没解决对数据湖、AI 场景的支持，而新的元数据服务对现有业务也会带来非常大的冲击，面对这样的问题，我们发现最后很多用户将不得不同时运行两套，甚至多套元数据服务，付出巨大的运维和管理成本。

更强大的元数据：

TBDS Metaservice

腾讯云 TBDS团队与 Apache Gravitino 社区深度合作，共同打造了TBDS Metaservice。作为 Apache Gravitino 社区的核心贡献者，腾讯云TBDS 团队拥有社区 PMC（由项目关键人员组成的团队）和多名 Committer（对代码库有合入权限的开发者），将开源技术与腾讯云的实践相结合，为业界提供了一个新的元数据开放标准与高性能的元数据服务，比 Hive Metastore 更高效、更可靠，更适用于数据湖和 AI 场景。TBDS Metaservice 是基于 Apache License 2.0 协议的商业版产品，兼容 Hive Metastore，同时在性能和功能上进行了显著提升，让客户最大限度利用存量技术资产。

TBDS MetaService 架构概述

TBDS Metaservice 提供了统一的元数据模型、开放 API 和 Engine Connector Frameworks，能够支持不同的表格式、计算引擎，三方管理平台的接入。通过在 TBDS Metaservice 中创建不同类型的 Catalog，用户可以统一管理 Hive、Hudi、Paimon、Iceberg 等多种表格式，并将其提供给计算引擎和管理平台使用。

这套开放元数据 API 和 Engine Connector Framework 有着良好的开放性和兼容性。经过简单的集成开发，不同的计算引擎和数据表格式都可以应用。

Catalog 是统一元数据模型和 API 核心的概念。

首先，不同的数据源需要有不同的连接信息和连接器，Catalog 负责管理这些连接信息，并和底层的数据源进行交互。

其次，面对多种多样的数据源，数据结构各不相同，数据层级也互有区别。不同的 Catalog 类型可以承接不同的数据类型；同时通过一致的 Catalog 接口，用户可以统一管理使用元数据。

TBDS MetaService 核心能力

1.Iceberg Rest Catalog Server 原生支持

Iceberg Rest Catalog Server 可谓是数据湖原生的元数据服务，所有的能力设计均为数据湖场景打造，Snowflake 的 Polaris 就是它的一种实现。TBDS Metaservice 完整实现了 Iceberg Rest Catalog API，确保与 Iceberg 规范的完全兼容。通过 Iceberg Rest Catalog API，TBDS Metaservice 提供了一个统一的接口，使得不同计算引擎能够一致地访问和管理 Iceberg 表。计算引擎可以通过这些 API 进行 Iceberg 表的创建、查询、更新、删除，管理操作。

相较于 Hive Metastore 的上百个接口，Iceberg Rest Catalog API 只需要不到 30 个接口就能实现所有的元数据功能。无论是服务端的开发维护优化，还是客户端的使用，都更简单清晰。并且相较于 Hive Metastore 的 Thrift 协议，Iceberg Rest Catalog API 使用更为通用简单的 HTTP 协议，开发者和使用者的调试运维更为便捷。

2. 灵活 MetaBackend 选择与性能增强

在 TBDS Metaservice 中提供了丰富的CatalogBackend（后端目录系统）选项，HiveCatalogBackend 利用 Hive Metastore 作为元数据存储。这种方式兼容之前的 Hive Metastore 体系，确保现有的 Hive 元数据可以无缝迁移和使用。

JdbcCatalogBackend 利用关系型数据库（RDBMS）作为元数据存储。通过 JDBC 连接，TBDS Metaservice 可以直接利用 RDBMS 存储元数据，摆脱 Hive Metastore 数据模型带来的影响，获得更好的性能和更简单的系统架构。用户可以根据具体需求选择最合适的 CatalogBackend 选项。

由于 Hive Metastore 的存储模型采取了三范式。表的外键很多，每次元数据的查询都需要进行大量的 join 操作才能获取完整的元数据。而 JDBC Catalog 只需要两张表就能保存必要的元数据索引，配合服务端元数据缓存，查询效率大为提高。

想要更直观地了解 HiveCatalogBackend 和 JdbcCatalogBackend 间的性能对比，可以参考下面这张图：

可以看到，数据显示在所有并发线程数下，JdbcCatalogBackend 的延迟都显著低于 HiveCatalogBackend。随着并发线程数的增加，HiveCatalogBackend 的延迟增长较快，而 JdbcCatalogBackend 的延迟增长相对较慢，展现出更好的扩展性。对于高并发和低延迟需求的场景，JdbcCatalogBackend 是更优的选择，不仅能够提供更低的延迟，还能在高并发情况下保持较好的性能。

3. 完善的 Metrics 收集统计

由于所有的元数据访问入口的统一，用户可以简单快捷地获取关于元数据使用的全面监控统计信息，通过这些统计信息掌握各类表的使用情况，识别出性能瓶颈。从而进行针对性的优化，提高数据处理的效率和系统的稳定性。这些性能指标和统计信息包括但不限于查询响应时间、元数据访问频率、系统资源使用情况等。通过这些数据，用户可以全面了解系统的运行状态和性能瓶颈。此外，利用指标采集接口，用户和第三方工具能够访问以及分析收集到的性能数据，将性能数据集成到现有的监控和分析平台中，实现更全面的系统监控和性能优化。

TBDS MetaService 落地场景

1. 多集群与多版本管理

在大数据环境中，通常会有多个集群，每个集群可能有独立的 Hive Metastore 服务。TBDS Metaservice 通过统一代理这些不同的 Hive Metastore 服务，实现了跨集群的元数据管理。不同的 Hive Metastore 服务可以注册为不同的 Catalog，TBDS Metaservice 通过这些 Catalog 进行统一管理和访问，一旦注册完成，用户和应用程序可以通过 TBDS Metaservice 统一访问这些 Catalog，而不需要关心底层的 Hive Metastore 实例。这样的代理模式不强制迁移同步元数据，Hive Metastore 可以作为唯一真实的元数据来源。在真实的生产业务中，可以最大限度的减少元数据同步过程中带来的元数据不一致风险。

另外，用户的数据平台可能会因为历史原因或业务需求，使用不同版本的 Hive Metastore。这种多版本共存的情况往往导致开发和运维团队需要为每个版本编写不同的接口和适配逻辑，增加了系统的复杂性和维护成本。TBDS Metaservice 的统一接口设计，允许用户和应用程序使用相同的 API 访问不同版本的 Hive Metastore，大大降低运维效率。

通过 TBDS Metaservice，用户可以在不改变现有业务逻辑的情况下，平滑地过渡到新的 Metastore 版本。其他直接依赖 Hive Metastore 的计算引擎和大数据服务不受 TBDS Metaservice 链路的影响。这意味着，企业可以在后台进行版本升级和迁移，而不需要对前端应用和服务进行修改。这种透明的代理机制确保了系统的稳定性和业务的连续性。

同时，目前业界已经有的大量针对 Hive Metastore 的优化方案，如缓存机制、索引优化、并发处理等。TBDS Metaservice 可以直接继承和应用这些成熟的优化方案，提升其性能和可靠性，在高并发访问、大规模元数据管理等场景下表现出色，满足用户需求。

2. Hive Metastore 平滑迁移

TBDS Metaservice 提供了一种从 Hive Metastore 平滑迁移到更现代化的元数据管理系统的解决方案。业务可以分阶段平滑将 Hive Metastore 元数据迁移至 Iceberg Rest Catalog Server 中。整个过程对正常的生产链路没有侵入和干扰。

在 Delegate 阶段，Iceberg Rest Catalog Server 完全代理 Hive Metastore。原有的依赖 Hive Metastore 的数据链路不受影响。同时用户可以单独验证 Iceberg Rest Catalog Server 的服务各项功能是否正常。

在 Switch 阶段，计算引擎（如 Spark、Trino、Flink 等）开始通过 Iceberg Rest Catalog Server 访问元数据，而不再直接访问 Hive Metastore。此时，Iceberg Rest Catalog Server 已经完全接管了元数据的管理和访问工作。

在 Prepare 阶段，用户开始进行元数据重新注册的准备。包括对准备数据库实例，网络策略，容量模型评估以及数据一致性的检查等。

最后是 Migrate 阶段。Iceberg Rest Catalog Server 将原有的元数据信息重新注册。整个注册过程非常轻量快速，元数据不会被修改和迁移。

通过分阶段的迁移策略，TBDS Metaservice 能够在不影响现有系统正常运行的情况下，逐步完成元数据的迁移工作。这种方式不仅提高了迁移的安全性和可靠性，还大大降低了迁移过程中的风险。

3. 异构数据源的统一权限模型

TBDS Metaservice 不仅支持 Hive Metastore，还支持Kafka、Doris、MySQL、PostgreSQL 等多种异构数据源。每种数据源都可以通过注册成为一个 Catalog 进行管理。通过 Catalog 机制，用户不仅仅能对不同数据源统一管理和访问，还可以在相同的模型中对不同的数据源进行授权。TBDS Metaservice 的 Privilege Push-down 机制将统一权限模型映射成为具体数据源的权限模型，并下推到数据源上。

例如，同样是进行库表授权，对于 Hive Catalog 的库表，TBDS Metaservice 会将元数据模型上的 Privilege 转换为 Apache Ranger 中的 Policy，并将其写入 Ranger Server 中。对于 Mysql 的库表，则直接将对应权限写入 Mysql 服务中。

4. AI 场景元数据管理

Fileset Catalog 是 TBDS Metaservice 的核心组件，专门负责管理和组织非关系型数据。通过 Fileset，TBDS Metaservice 能够高效地处理和管理各种 AI 元数据，包括模型文件、训练数据等。这种管理方式不仅提高了数据的组织性，还增强了对数据的访问和控制能力。

例如，在一个 AI 模型训练项目中，用户需要频繁地访问和更新训练数据集和模型文件。传统的文件管理方式可能会导致数据分散、版本混乱等问题，比如多种存储共存的场景。Kafka 集群，Hadoop 集群，以及对象存储格子布保存不同性质的数据。通过 Fileset Catalog，用户可以将这些数据统一管理，通过同一个接口访问所有数据，而不需要关心数据的具体存储位置。这种统一的管理方式，不仅提高了数据的可用性，还降低了数据管理的复杂性。

此外，TBDS Metaservice 支持与多种数据处理和机器学习框架的无缝集成。Spark、PyTorch、TensorFlow 和 RAY 等框架可以通过 Python Client 与 Fileset Catalog 交互，访问和管理数据。这使得 AI 模型训练、数据清理等工作流能够无缝集成和运行。在用户需要切换不同的框架，以完成数据预处理、模型训练和评估等任务。

TBDS MetaService 在某大型银行湖仓一体项目中的实践

该银行是金融行业内的标杆客户，在数据仓库，数据中台领域长时间投入了大量资源进行建设。基于腾讯云 TBDS 先进的“存算分离，湖仓一体，统一云数据湖”的理念，TBDS 和客户共同重构了全行的技术底座，在兼容老业务的基础上，彻底升级了客户的大数据体系。

TBDS Metaservice 完全统一了客户的元数据管理界面，纳管行内已有大数据集群和数仓集群，形成统一元数据视图。基于统一元数据视图，业务元数据服务可以对全行数据资产进行有效的管理，在合规层面，也能真正落地统一权限管控机制。同时利用 TBDS Metaservice 的多引擎支持，TBDS 的湖仓一体架构可以使得一套数据在多种场景下被不同的引擎进行不同的处理，这即降低了数据传输复制的开销，同时也增强了数据的安全性。

得益于 TBDS Metaservice 对 Iceberg 等数据湖表格式的良好支持，以及对于旧 Hive 表的完全兼容。客户可以从容不迫地逐步升级业务模式，按照客户自身的节奏完成离线跑批到实时入湖业务的升级。

总结和展望

通过 TBDS Metaservice，用户既可以利用现有的技术资产，进一步提升既有平台的价值；同时能将平台升级成为满足大数据新时代需求的新形态。未来，随着数据处理需求的不断演进，TBDS Metaservice 将继续引领元数据管理的创新，为企业提供更高效、更灵活的解决方案。

全面提升引擎效率

在直接使用 Hive Metastore 的场景下，当用户向引擎提交查询时，引擎会调用 Iceberg 的 HiveMetaStore Catalog 实现来加载表的元数据。通过表的元数据和查询条件，计算引擎筛选出需要扫描的数据文件（Iceberg Table Scan），然后进行下一步处理。

Iceberg Rest Catalog API 提供了 Server-side Plan API ，可以将 Iceberg Table Scan 的执行过程从引擎侧转移到元数据服务端，跨引擎的提升计算效率，这将为整个系统带来全方位的提升：

1. 节约了引擎从元数据服务拉取完整的元数据信息的时间。在处理大表时，表的元数据信息可能非常庞大，避免这项开销可以有效地提升计算效率。
2. 节约了引擎执行 Iceberg Table Scan 的时间。Server-side Plan API 直接返回下一步计算的数据文件信息，引擎可以直接获取数据执行后续操作。
3. 对于重复查询或者类似的查询，利用服务端缓存提升性能。
4. 由于是标准 Iceberg Rest Catalog API 的一部分，所有引擎不需要付出多于的开发改造成本即可获得性能提升。

TBDS Metaservice 正在积极跟进这一功能，在未来的版本中将会实现 Server-side Plan 能力，全面提升引擎效率。

AI 大模型元数据管理

随着大模型（LLMs）的迅猛发展，AI 大模型在大数据领域的应用也逐步浮现出来。当前大模型的能力越来越强，但是我们可以看到，并没有一个统一的预训练后的大模型能完美地执行所有任务。用户往往需要对模型进行 Post- training 以及 Prompt engineering 对模型进行进一步的 Fine tuning。以及基于业务上下文自行训练一些垂直领域的小模型，来处理具有特殊领域知识的任务。这对于模型本身的元数据管理也提出了进一步的需求。在未来的版本中，针对 AI 大模型的元数据管理使用的需求，TBDS Metaservice 将提供相应功能，帮助用户在更好地管理和使用 AI 大模型。

END