腾讯大数据TBDS 8月重磅推出了的新一代元数据湖管理系统，提供面向大数据湖仓分析、AI智能的统一元数据管理和治理。翻译一下就是：元数据管理的边界，我们给扩展以及统一了！
01、元数据管理发展阶段
大数据发展多年以来，在元数据上整体可以分成三个阶段。
第一阶段是以Hive Metastore为代表的元数据服务，主要提供存储和访问Hive库表等的元数据信息，是首个Hadoop开源的元数据管理服务，几乎成了事实标准，以至于后续的计算引擎如Spark、Impala、Trino等都默认遵循Hive Metastore的标准访问。但是随着数据规模的增长和对数据访问效率的要求越来越高，它缺乏多Catalog的支持以及几乎没有元数据治理能力的劣势凸显。
于是后来出现了支持多Catalog数据源的第二个阶段，以Trino/Spark的Catalog以及Starrocks/Doris Muti-Catalog等为代表，它相比Hive Metastore支持多个Hive数据源以及其他数据源，是计算引擎跨源计算的基础，打破了数据孤岛足以应对数据规模的持续增加和跨集群跨源数据联动。但是缺点是它们的Muti-Catalog服务都是在各自组件里的，不是像Hive Metastore一样是一个独立的服务，不能提供给外部其他引擎使用。随着AI大模型的发展，对模型特征向量化数据的管理要求越来越高，它们也缺乏对非结构化数据的支持。
第三个阶段可以叫做Unified Data Catalog（统一数据目录），处于刚刚起步阶段，以Unity Catalog和Gravitino为代表，面向结构化数据和非结构化数据、开放性、跨云跨地域的统一元数据服务。它完整支持AI使用的这种非结构化、半结构化向量数据及大数据Hive生态、数据湖表格式、Hdfs文件系统/对象存储等数据和传统数据库、数仓这种支持Jdbc访问的结构化数据的统一管理和治理以及数据血缘，支持多种计算引擎生态，并且基于此提供统一权限、统一Catalog模型、开放API的数据服务。
所以在Data+AI 时代，面对AI非结构化数据和大数据的融合，以及更复杂跨源数据治理能力的诉求，TBDS开发了第三阶段的全新一代统一元数据湖系统。
02、新一代元数据湖管理方案
TBDS全新元数据湖系统按照分层主要有统一接入服务层、统一Lakehouse治理层、统一元数据权限层、统一Catalog模型连接层。我们引入了Gravitino并且基于它在数据治理、数据权限等能力上做了大量的TBDS已有能力的合入优化，形成一个闭环、完整的系统。
统一接入服务对外提供开放标准的API接口给用户或引擎对元数据湖的各种操作，提供JDBC、REST API和Thrift协议三种方式访问元数据。JDBC通常适合给用户想通过sql语句直接操作统一元数据信息，如show tables；REST API是给上游希望获取元数据信息的开发人员，如WebUI页面管理服务；Thrift是给引擎以Connector连接器的方式访问元数据，如Spark计算引擎在Connector里以Thrift协议获取统一元数据目录给计算引擎进行下一步计算。
统一Lakehouse治理专注元数据的组织效率，对数据进行规划、合并、生命周期管理、血缘分析、容灾备份等以确保数据的质量，提供数据发现与探索和AI智能助手的能力给用户智能找数、识数、用户体验。还有一些数据冷热温度、小文件合并治理、数据血缘等能力也都是这一层提供。
统一元数据权限面对多种数据源的原有的权限系统如Ranger、RBAC、IAM等设计了插件机制可以开放的接入各种外部权限系统，对外提供了统一的权限模型定义和使用方式，完成统一管控。并且提供了数据审计、数据加密、数据脱敏的统一能力。
统一Catalog模型连接面对多种数据源元数据系统设计了统一的Catalog模型描述Hive元数据、文件系统元数据、消息队列Topic元数据、JDBC元数据、AI模型元数据等信息；为了让下面的数据源组件能识别统一Catalog模型，针对不同数据源提供了Catalog Connector连接器，兼容包括库表、函数、视图、ScanBuilder、WriterBuilder等接口实现。在这一层既实现了多种数据源元数据的统一管理，又可以支持下层数据源的快速联邦分析。
通过全新统一元数据湖系统TBDS对结构化、半结构化、非结构化数据的全面管理，实现企业对Data+AI数据家底的全面盘点，为用户屏蔽了不同结构数据源组件的技术差异，对外提供统一的元数据能力。特别在大数据结构化数据更好实现了湖仓元数据的统一和联动。
03、统一元数据权限
在Hadoop体系的优化
我们通过统一元数据系统的统一权限插件完成了不同数据源权限的管理。接下来详细介绍我们在Hadoop体系下的权限优化。
对于Hadoop体系下计算引擎的数据权限底层基本都是通过Ranger来实现授权和鉴权，但是Ranger的权限设计是基于组件（Service）做区分，不同引擎组件（Service）即使都共用同一个Hive的元数据库表，也要在Ranger上为每个不同的计算引擎创建相同语义的权限策略和Ranger Plugin插件，Ranger Plugin会定时同步该组件的全量策略到本地内存构建策略树进行本地鉴权，授权通过Ranger Plugin代理请求发送到Ranger Admin。
随着计算引擎越来越多以及策略数日积月累的增长，在这种架构下带来的问题越来越影响性能和用户使用效率：
【1】用户会基于不同的细分场景选择不同计算引擎，TBDS版本里基于Hive库表的计算引擎就有Hive、Spark、Trino、Impala等，不同计算引擎上用到相同的Hive表需要在Ranger上为每个组件创建相同的库表权限，增加了用户在权限配置成本和理解，增加了复杂性且难以管理。
【2】随着库表及策略数持续增加，Ranger Plugin占用本地内存也持续增加，TBDS的生产经验值是100万策略情况下消耗的内存在10～20G左右。对于Spark Cluster模式来说每个Spark作业都会起一个Spark Driver，每个Spark Driver都会有一个Spark Ranger Plugin。大集群大量Spark批作业并行运算情况下仅仅Spark Driver上对集群的内存消耗都非常大，不仅造成大量集群内存计算资源的浪费，而且Spark Driver还容易OOM，导致任务不稳定。
TBDS基于元数据的统一权限
数据权限本质上是对数据的各种资源（文件/路径、catalog、database、table、column等）的访问控制信息描述，既然元数据的资源在元数据系统上已经用一种通用的entity模型来表达描述，权限作为资源的附属属性也同样可以。我们的方案是实现一个新的统一的统一元数据 Ranger Plugin来做统一权限。
实现统一元数据 Ranger Plugin主要要做下面的设计：
【1】实现Ranger Service Def的定义描述：里面包括Service有哪些资源的定义（如catalog、database/schema、table、column、udf等）、多个资源之间依赖关系的定义、对资源的访问动作（如select、insert、delete、use等）、访问资源的连接信息定义、还有脱敏、行过滤等一些配置信息。前面提到了Ranger的权限在最初架构设计上是以Service（组件）做区分，我们沿用Ranger这种设计，只是在理念上把统一元数据当作一种特别的Service来承载，在资源定义这里我们基于统一元数据定义的Hive Catalog通用元数据的entity模型来定义共用的资源，这些有了后，多种计算引擎常见的资源的权限都可以描述表示。但是还有一些资源是不属于统一元数据定义的，比如Trino引擎有自己特有的sessionproperty、trinouser资源，如果不定义这些资源，在Trino执行和这些资源有关的sql语句时权限就会管控不住。最终我们再融入各个引擎独有的资源（较少），形成一个统一的ranger-servicedef.json定义描述。
【2】实现Ranger Plugin Agent的代码实现。下图是Ranger在Plugin在代码设计上的关系图，可以看到每个组件自己定义了组件做权限控制ACL的接口和抽象授权/鉴权方法，Ranger实现了Plugin的底层Common通用鉴权通道（实现从Ranger Admin定时同步所有策略到本地内存构建内存策略树结构，并且提供了通用的RangerAccessRequest请求体到策略树鉴权和授权的方法），Plugin Agent这部分就起到了承上启下的作用，需要在Agent里按组件定义接口和抽象方法实现具体逻辑，具体逻辑概括起来就是把不同组件定义的不同资源访问结构转换成Plugin Common提供的RangerAccessRequest的过程。
由于每个组件定义的接口和抽象方案差别巨大，我们的设计是抽象出同一个通用的工厂类UnifiedMetaAuthFactory来implements实现所有引擎的自己定义鉴权/授权方法具体逻辑。
最终在TBDS上在数据权限、数据脱敏、数据过滤等能力上达到统一，都共用这一个Ranger Service，下面是TBDS里的使用入口和实现页面。
TBDS轻量级Ranger Plugin Proxy代理
Ranger Plugin定时同步全量策略到本地内存，最大的优势就是本地内存鉴权，鉴权的时候不需要再去Ranger Admin，纯内存计算速度快，Ranger Admin的访问压力从用户sql触发变成定时器触发，极大降低了Ranger Admin的请求量，保证了Ranger的稳定性和能提供更大性能能力。另外即使Ranger服务挂掉，Plugin本地除了内存策略树还有策略的持久化Cache文件可以兜底使用，在服务可靠性上做到了高内聚低耦合。从Ranger的角度看这种架构非常好，但在大数据集群跑作业的全局视野下，出现了上面Spark作业遇到的资源浪费和容易OOM的问题。但是如果退回到把鉴权请求都打到Ranger Admin，Ranger Admin 内部也会缓存DB存储的策略，这些缓存的更新都会进行加锁操作，因为有写策略请求会更新缓存，在流量增大的时候，锁冲突会非常严重，这时Ranger admin的性能会降低很大，带来的Ranger压力问题会更大。因此这些能力我们都要保证：
● Ranger Admin请求访问压力可控，不随着用户请求触发
● 引擎组件本地鉴权速度要快
● 引擎组件内存和集群计算内存资源不会随着作业数而指数增加。
我们的优化思路是实现一个轻量级的Plugin Proxy代理服务，这个Proxy服务对外提供和Ranger Admin鉴权/授权完全一致的REST API接口，内部鉴权/授权逻辑参考Ranger Plugin的机制，定时从Ranger Admin同步全量的策略到Proxy本地内存，以Cache文件作为兜底。Proxy服务对于鉴权请求在本地处理不会穿透到Ranger Admin，授权写/更新策略请求转发给Ranger Admin处理，和Plugin的处理方式一样。因此Proxy服务基本没有太多业务逻辑，只做定时同步构建内存策略树和接收REST请求本地内存鉴权，相比有很多锁操作有状态的Ranger Admin来说Proxy是一个非常轻量级无状态的服务，可以平行无限扩展分摊压力。
在Ranger Plugin上我们把本地鉴权相关的逻辑都做个开关拦截，通过网络HTTP的方式把鉴权请求发送Proxy服务。
因为Proxy服务逻辑简单本地鉴权给Plugin的回包响应速度也非常快，同时Proxy服务性能很高也可以平时扩展来解决大量用户sql请求带来的访问压力问题，组件Plugin本地不再内存缓存全量策略也解决了内存增长带来的问题。下面是最终的Ranger统一权限架构图。
除此之外我们在Ranger上还做了一些其他性能的优化，让TBDS的Ranger性能达到极致。经过生产数据的统计和多次压测，在百万以上策略的情况下，每秒500个并发同时请求读写策略，Ranger的读策略请求平均响应时间为500ms左右，写/更新策略请求平均响应时间为1200ms左右，Plugin/Proxy同步到最新策略的时间间隔为：
● 优化Ranger Admin写策略afterCompletion里的事务机制
● Ranger Plugin/Proxy同步全量策略写本地Cache文件逻辑，同步写改成异步写
● Ranger Admin更新缓存的锁粒度，部分逻辑拆成小锁
● 内存策略树里一些数据结构由List改成Set，大幅降低查找的时间复杂度
左右，经过测试比社区最新Ranger2.5稳定版平均要快3～5倍。其他主要优化有：
04、总结
TBDS新一代元数据系统通过新的元数据系统打破数据孤岛，实现多种计算引擎的联邦计算，企业成本大幅下降。并且在数据湖、AI场景实现元数据统一管理和自动化数据治理，在保证数据智能高效访问的同时还提供基于Ranger深度开发优化的统一权限安全能力，让数据更可感、可控、易用。我们未来会在统一元数据血缘和支持更多的计算引擎计算以及大数据和AI场景结合上做更多功能，让数据和算力更智能、高效、紧密。
