腾讯大数据多引擎一致元数据和权限控制的探求

一、腾讯大数据处置套件

TBDS的全称是腾讯大数据处置套件，它是一个基于Hadoop生态以及MPP生态的大数据平台。咱们关键有以下的四种运行场景：大数据的批流的处置，云原生的数据湖，湖仓一体，以及国产化的数据中台。

上方是咱们的一些客户，大家可以看到种类十分多，有金融类的、产业类的，还有传媒以及政府。不同用户的业务场景差异十分大，数据规模、集群规模的差异也十分大。他们关于大数据如何经常使用，关于数据服务的要求也十分的不一样。

下图是金融场景的一个典型的技术方案：业务数据经过实时链路和离线链路进入大数据平台。在大数据平台中有两种类型的集群。第一类是事情中心集群，也可以叫实时计算中心集群；经过Kafka、Flink数据处置之后再进入Hive和Elasticsearch，而后对中心的系统提供数据服务。另一类是离线计算集群，关键担任数据的批处置。

整个大数据平台是基于Hadoop生态搭建的；得益于Hadoop生态的兴盛，基本上每种特定的需求都可以找到适合的计算存储组件来满足。

除了Hadoop，咱们还提供基于MPP的技术方案，它关于中小体量的客户愈加适合。基于MPP的来搭建数据平台，实时链路以及离线链路的数据都进入MPP，然起初一致加工处置，最后也是由MPP一致对外提供数据服务。

Hadoop还是MPP？这两个生态之间的对比，其实业界曾经探讨十分多了。随着各自的开展，我置信相关的探讨也会不时继续下去。例如对Iceberg这样的数据湖表格局的支持，目前无论是Spark还是ClickHouse，都在做军备比赛，如今的论断过两三个月或者就过期了。

但是有一点是必需的，没有一个独自的生态，能够处置一切用户的一切疑问。这种状况会继续很长的一段期间。即使如今曾经是2024年了，很多客户他们的数据平台曾经继续树立了很长的一段期间，多种集群、多种类型、多种版本的大数据系统，它们的共存是咱们会经常遇到的一个疑问。所以肯定咱们会遇到这么一个疑问：如何来处置数据孤岛--不同的系统之间的数据该如何互通。

咱们都知道，假设是要做数据迁徙、做ETL，是一件老本十分高的事情。有的时刻可以接受，但有的时刻是很难去承当这样的老本的。

在这样一个一致的元数据服务的状况下，再加上支持如Iceberg这样的表格局，提供一致的元数据的格局，基本上疑问可以获取处置。这也是目前很多私有化场景下湖仓一体、湖上建仓的技术基础。

在上方的方案中，Hive Metastore是相对的中心，但是Hive Metastore自身还是有很多的局限性的。首先Hive Metastore是一个单纯的元数据技术和服务，基本上没有任何的控制才干。其次它的元数据模型齐全是相关型的数据库模型，关于像Message、Topic、文件，以及AI模型这类半结构化、非结构化的数据基本是不婚配的。而且它的服务设计也没有思考到要承当如此关键的义务，所以有很显著的单点瓶颈。

在一个多集群的场景上方，它的方案会十分的复杂，但至少它还是可以跑的。那么数据孤岛看上去是有方案了，但是权限怎样办？Hadoop，还有Hive Metastore，它自身也有一套比拟粗陋的权限模型，但是基本没有计算引擎来经常使用它，更别说MPP引擎了。

因此，假设没有一个一致的权限中心，单个资源的授权就须要在每一个子系统上方再重复地授权一遍，步骤十分繁琐，并且很容易出错。在Hadoop生态下，Ranger是一个权限中心，它的机制是有点像OPA （open policy agent），整个权限战略被Manager一致的控制，而后各个计算引擎经常使用各自的Plugin启动授权。但是它的权限模型存在肯定的疑问。最关键的疑问是它顶层设计的概念并不是以数据来划分的，而是以服务组件来划分的，不同的组件，假设要访问雷同的数据，那么须要重复的授权，而且这只是Hadoop生态的一个方案，MPP生态基本是没有权限控制。

咱们其实也看到干流的云厂商基本提供了相关的产品来处置数据孤岛以及权限孤岛的疑问。这样的处置方案普通都会被包装成为数据湖产品的一局部，例如AWS的Lake Formation，Databricks的Unity Catalog，此外Microsoft和Google也有自己的产品。但是关于这样的商业公司所主导的产品，他们也有自己的局限性。

首先是关于计算引擎的支持比拟少，也缺少私有云、尤其是非云化环境的部署方案。并且它们关于云厂商自身的依赖水平十分深。

因此，咱们须要一个愈加一致、愈加明晰、同时也愈加放开的产品，来更好地处置数据孤岛以及权限孤岛的疑问。腾讯云和Datastrato一同，基于Gravitino的开源社区来协作，宿愿能够处置这样的疑问。

我来便捷的引见一下Gravitino，它是一个经常使用Apache License v2.0容许证的开源一致元数据服务，片面支持私有云、私有云以及非云环境的部署。它可以为多种的数据源提供一致的元数据视图，并且提供了规范的SDK，可以放开的支持多种计算引擎的接入。

此外很关键的一点是，Gravitino提供了一个一致的、放开的权限管控机制。一致指的是一致的授权：关于一切的数据源，可以经常使用一致的模型和流程来启动授权；放开指的是放开的接入：关于数据源可以使关于各种计算引擎包括MPP，以及存储，都能接入这样的权限模型，成功权限的管控。

关于数据系统来说，它的权限设计至关关键。但是如今的大局部企业的数据系统有很多种类型，有MPP类型，也有一些在线的例如MySQL、PostgreSQL这样的数据库，以及Hadoop上的HDFS、Spark、Hive等的大数据组件。这些的数据系统带来了异构的数据栈，关于目前的一些权限的设计，就很难有一致的权限入口来做一致的控制。

关于企业来说，这样的状况关于它构建自己的数据生态带来了很大的不便。为此，在计算机系统里有这样一句话：没有任何疑问不是可以经过加一层来处置的。在去年的时刻，咱们公司开源了Gravitino这样一款元数据控制软件，用于处置这种跨数据栈的元数据控制。我为大家关键讲一下Gravitino的权限模型。

首先我引见一下权限模型，业界比拟经常出现的权限模型有ABAC、RBAC等等，但是目前还是以RBAC为主。Gravitino在这块儿也是驳回了RBAC的权限模型。

首先咱们可以看出这张图里有几个概念，第一个概念就是Metalake。第二个是Role，第三个是User。

关于Metalake来说，咱们可以把它看作是一个组织；普通来说，一个企业就是一个Metalake，它只要一个组织。在Metalkae上方会挂载Role以及User。

Role关键是咱们权限模型中用来控制权限的中心概念，它会绑定详细的一些权限。Role是实体的详细的某些权限的汇合。在实践的经常使用的环节中会把Role授权给User，Role和User是多对多的相关，可以去启动比拟灵敏的绑定。

讲完了权限模型，我引见一下一致权限的系统架构。Gravitino的权限大略可以分为两局部：第一局部是，它关于自身会有内建的鉴权，关键担任关于自身控制的一局部的元数据启动鉴权，比如说Metalake的一些鉴权，比如说自有的一些数据实体的鉴权。同时它还提供了弱小的插件机制，用来对接一些外部系统的权限。

目前权限插件会有四类，第一类是Native Catalog的权限插件，关键用于大数据生态的权限鉴权，这关键是思考了一些用户，他们不想引入相似于Ranger这种额外的大数据权限控制组件，启动简便的一些数据权限的控制。

第二类是正就像前面徐潇所说的，在大数据体系当中，Ranger是一个比拟干流的权限控制系统。这里会提供Ranger的Catalog的权限鉴权的插件，而后经过它来去对大数据的体系启动全体的权限管控。

第三类是关于MPP、数据库这类系统，它们普通会提供JDBC接口。咱们会对这样的系统来提供JDBC Catalog鉴权的插件，来对这样的系统启动权限的管控。

第四类是关于很多的云上的生态，比如AWS、Azure，它们会有像IAM这样的权限控制系统。关于这种咱们会提供云的Cloud Catalog的鉴权插件。

全体的来说，Gravitino是经过自建的鉴权机制，以及联合丰盛的外部鉴权插件机制，来成功对权限机制的一致。

在这个环节中Gravitino对外泄露RESTful的API接口，而后将用户的各种权限设置的恳求，经过自身的逻辑以及模型的转换，经过插件透传给下游的各种不同的数据生态，从而到达让Gravitino成为权限入口的成果。

接上去可以看这张图，来联合详细的例子给大家分享Gravitino的授权环节。

可以看到，左边是认证Server，会支持三种认证服务。第一种是OAuth的认证，第二种是Kerberos认证，Kerberos认证在大数据的生态用得会比拟多一点；第三种是IAM 认证，关于云的系统IAM会经常使用得比拟多。

全体会提供对用户的认证，而后是数据授权的环节。Gravitino在介入的环节中会有三个角色：第一个角色是Service Admin，它的职责其实比拟便捷，就是创立Metalake；第二个角色是MetalakeAdmin，关键对Metalake上方的Role的创立和控制，以及对各种权限的Role的创立，并把这些Role和详细的User启动绑定。第三个角色是普通User，他或者是新参与的User，担任详细的数据实体的创立，例如创立Catalog、数据库、表，而后读取这些表。

在这个环节中，咱们可以便捷来看一下便捷的创立Catalog和之后创立表的环节。第一步是Service Admin会去创立Metalake，之后Metalake admin会去创立Role，而后创立须要详细经常使用的User，而后去创立Catalog，而后放开了Catalog的Manager Role，去把Catalog Manager Role赋予给new user。New user就可以详细创立Catalog，例如可以创立Hive Catalog，创立MySQL Catalog。这个时刻Metalake admin可以去创立Hive的Schema Manager，把Schema Manager授予给new user，而后new user就可以创立Schema。之后Metalake admin可以创立Hive Table的Manager role，再把Hive Table的Manager role授予给new user，就可以详细去去创立Hive Table。

关于MySQL也是雷同的，会去创立Catalog、Table。当Hive catalog以及MySQLCatalog和HiveTable都创立完之后，详细的new user就可以读取这两个表。