数据湖统一元数据与权限

Posted 2022-09-10 阿里云云栖号

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了数据湖统一元数据与权限相关的知识，希望对你有一定的参考价值。

摘要：本文整理自阿里云数据湖构建与分析研发熊佳树在7月17日阿里云数据湖技术专场交流会的分享。本篇内容主要分为两个部分：
1.元数据与权限背景介绍
2.阿里云数据湖统一元数据服务
3.阿里云数据湖统一权限服务
4.数据湖元数据与权限展望

一、元数据与权限背景介绍

开源元数据体系由来、演进及问题

开源大数据体系是指以 Hadoop 为中心的生态系统，而目前 Hive 是开源数仓的事实标准。

关于大数据的由来和发展，要追溯到谷歌在2003 年发表的论文，论文中提出了 HDFS 和 MapReduce 两个组件。HDFS 组件最早用于解决网页存储问题，它可以部署在大量廉价的机器上，提供极佳的硬件容错能力以及存储的扩展性。MapReduce 的初衷是解决搜索引擎中大规模网页数据的并行化处理问题。同时它也是比较通用的并行处理框架，可用于处理很多大数据场景。

虽然 HDFS 和 MapReduce 很好地解决了大数据存储和大规模数据并行处理的问题，但依然存在几个缺点：

第一，编程门槛较高。传统的数仓工程师接触的编程接口一般是 SQL ，但 MapReduce 框架有一定的编程能力要求。

第二，HDFS 上存储的是文件和目录，并没有存储元数据，也无法进行查询。因此即使知道文件的结构，也无法对文件的内容方式变化进行管理，导致程序本身可能丧失稳定性。

基于以上痛点，以雅虎为代表的公司提出了 Apache Pig，提供 SQL-like 语言，该语言的编译器会把类 SQL 的数据分析请求转换为一系列经过优化处理的 MapReduce 运算，屏蔽了 MapReduce 细节，可以很轻松高效地处理数据；而以 Facebook 为代表的公司提出 Hive 的解决方案，在 HDFS 上提供了一层数据抽象，屏蔽了文件系统及编程模型的细节，极大降低了数仓开发人员的门槛。通过对数据及文件系统到元数据的抽象，能够非常方便地进行数据共享、检索以及查看数据变更历史。这一层的元数据抽象即如今大家所熟知的 Database、Table 、Partition和 Function ，同时在元数据上又衍生出了非常接近 SQL 语言的 HiveQL。同时后续的 Hive3.0 版本新增了 catalog 的功能，Hive4.0版本新增了 Connectors 功能。依托于元数据, 计算引擎可以很好地进行历史的追溯。除了追溯历史 schema 变更外，元数据还有一个重要功能是保护数据（不做不兼容的变更）。

Hive3.0实现的 catalog 功能，主要基于以下两个场景：

① 多个系统之间可能需要 MetaStore 元数据的 Namespace，期望能够达到一定的隔离。比如 Spark 有自己的 catalog ，Hive 也有自己的 catalog，不同的 catalog 上可以有不同的鉴权、运营策略。

② 可以对接外部系统的 catalog。

Hive4.0的 Connectors 主要是定义数据 DataSource，其他引擎对接 Hive 元数据后，即可通过该接口识别 DataSource 的信息，方便其他引擎做查询。

目前 Hive上几乎已经支持了 Hadoop 生态的所有计算引擎，因此它也已经成为开源数仓的事实标准。但它依然存在一些问题，比如虽然支持了 schema 的衍变，但是并不能通过 Time-Travel 的方式查询数据变化的历史快照，虽然有 ACID 新特性，但与 Hive 引擎的深度绑定导致无法很好地移植到其他引擎上。

另外， ACID 特性主要使用 rename 的方式做 isolation 隔离，在做文件 Compaction 及在存储分离等场景容易出现问题，比如 rename 过程在云存储上的性能问题。开源社区针对这些点衍化出了一些数据湖的格式，在不同程度上解决了 ACID 的问题。

数据湖格式拥有自己的元数据，同时会将自身的元数据注册到 Hive Metastore中。数据湖格式的元数据与 Hive 元数据形成补充，并没有脱离整体 Hive 元数据的视图，其他引擎依然可以通过 Hive Metastore 这一套元数据管理体系访问数据湖格式上的数据。

但 Hive Metastore 上并没有多租户的能力，同时受限于单个元数据库的能力瓶颈，有些公司会部署多套 Metastore，这很容易形成数据孤岛，所以也有一些公司提出了解决方案，比如 Waggle-Dance 及 Multiple Hive Metastore 方案等。另外因为 HiveMetaStore 使用 Thrift 协议的接口，所以内部引擎和自研引擎对接 Hive Metastore 时，必须对接 Metastore 的协议以及依赖相应的客户端，这种依赖还是比较重的。

另外，Metastore 在设计元数据存储时高度去冗余，因此会带来一些 Metadata Fetch 的性能问题。

开源的 Waggle-Dance 方案后端有多个 Metastore，每个 Metastore 有自己的 Database 存储。Waggle-Dance 模块实现了 Hive Metastore 后端完整的 Thrift 协议，能够无缝对接到其它引擎，解决现有的 Metastore 瓶颈问题，比如单个 DB 存储量、单个 Metastore 性能问题等。

但是 Waggle-Dance 解决多租户的方案存在命名冲突问题，需要提前做 Database 和 Metastore 的命名规划。因为 Waggle-Dance 路由的模块有一个 Database 到后端 Metastore 路由表。如果是 Hive 3.0，可以通过 catalog 这一层路由的映射设计来解决。

另外，Waggle-Dance 可能会带来 Thrift 接口协议的冲突，比如后端可能存在多个 Hive Metastore 的版本或有多个不同 client 的版本。因此中间层的路由组件可能需要兼容不同的版本，就可能会出现协议的兼容性问题。

权限控制体系介绍

除了元数据外，元数据和数据访问的安全性也非常重要。企业的数据安全性必须依赖于完善的权限体系。权限的基本三要素包括主体、客体和操作。ACL 建立在基础三要素之上，对应到元数据上为：某个人对某个表有什么样的操作权限。ACL 存在一定的缺陷，比如后续如果权限比较多会难以管理，因此又发展出 RBAC 和 PBAC 权限。

以入住酒店为例解释 ACL、RBAC 和 PBAC 三者的区别：比如住客入住酒店后会得到一把房门钥匙，得到进入某个房间的权限，即相当于 ACL ；而针对某一楼层有一个楼层管理员，可以管理所有房间，即相当于 RBAC，在 ACL 上面增加了一层用户的角色到权限的映射，有了角色之后很显然降低了权限管理成本；但是如果有比较特殊的需求，比如需要限制某一层的管理员只能在上午 7 点后才有权限进入房间，即需要 PBAC，它是基于策略的模型，在普通权限模型的基础之上支持了权限条件。

Hive 0.13 提出了 Hive Storage-Based Authorization，它是基于底层存储的鉴权。该权限策略的优点在于无论是 meta 操作还是底层文件存储操作，都可以获得统一的权限视图。但它是基于目录和底层文件的权限体系，因此无法很好地映射到 SQL 层面权限操作。同时，因为底层的权限是文件，所以无法在数据层面或字段级别做更细粒度的鉴权，因此它并不支持 Fine-grain control。

基于以上问题，社区提出了 Hive SQL-Standard Based Authorization，即基于 SQL 的标准化鉴权模型，能够在 SQL 层面支持 Grant 和 Revoke 控制指令。同时可以做相对细粒度的权限控制，比如可以将搜索上的很多操作映射到权限模型上。该模型实现了列级的访问控制，但没有实现行级的权限。

另外，Hive SQL-Standard Based Authorization 虽然具有 SQL 层面的权限，但并不包含存储系统的权限。因此做存储系统的访问或实操层面访问时，无法获得统一的权限视图。且该模式不支持数据湖格式。

后来，某商业公司推出了 Apache Ranger(Sentry)，面向所有大数据开源生态组件，对底层的文件系统 YARN、Hive、Spark、Kafka 提供了中心化的权限控制方案。同时支持在 SQL 层面进行 Grant、Revoke，比此前的模型增加了更细粒度的权限，比如行级过滤、列级权限控制，同时在权限上还具备 exception policy 及其他能力。

但 Apache Ranger 也存在一些问题。因为 PBAC 模型的权限是事先定好的，不依赖对象的存在与否。比如用户对某表有 select 权限，表被删除后又被重新建出，而该用户仍然拥有权限，这并不合理。另外，虽然 ranger 可以使用在很多大数据组件之上，但仅限于 Hive 的 HiveServer，而 Hive Metastore 上并没有权限控制，所以它面临的问题在于 Hive Metastore 提供的元数据访问接口和在之上提供的权限接口存在分离。

因此，总结来看，数据湖管理面临的挑战包含以下几个方面：

在元数据服务层面，开源版本没有多租户的能力，扩展性、稳定性以及性能方面都存在问题，对接多个计算引擎难度大。

数据安全层面，权限控制方案复杂，成熟度低，无法覆盖所有计算引擎，且为开放存储，权限难以控制。

数据治理层面，开源社区目前没有非常好的数据管理工具。无法很好地根据元数据分析现有的存储成本，也无法做很好的生命周期管理。虽然Hive4.0已经增加了一些特性，比如可以做 partition 的自动发现以及对 partition 做一定的生命周期管理，但整体上依然没有很好的治理手段。

查询性能层面，存储计算分离架构的读写性能受带宽控制，原始数据未经过优化因而查询性能低，且缺少索引、统计等加速手段。

阿里云针对上述问题和挑战，实现了一套面向数据湖领域的元数据、安全、治理、加速的解决方案：

全托管免运维的统一元数据中心

统一元数据中心脱胎于阿里云内部久经考验的元数据底座，无缝对接多种开源计算引擎和自研的内部引擎，同时依托于阿里云的数据湖构建与管理DLF产品提供了元数据的发现、迁移、备份的能力。

企业级权限控制

数据安全方面，支持阿里云账号系统，也可以兼容开源的 LDAP 账号体系；提供字段级别的读写权限控制和 Location 权限托管。引擎和应用甚至可以对接元数据 API 和权限 API ，实现自己的权限集成或元数据集成，从而使所有引擎及应用都可以实现对权限的统一控制。

智能数据管理与优化
- 精细化存储统计与分析
- 自动化数据冷热判断与分层
多重数据湖加速
- JindoFS 提供数据缓存加速
- 自动小文件合并、数据清理
- 自动Stats计算、查询优化
- 湖格式元数据服务化

二、阿里云数据湖统一元数据服务

阿里云上数据湖统一元数据服务架构

阿里云上数据湖统一元数据服务（DLF）提供了多租户、统一数据目录，支持多引擎的扩展与切换。兼容了 Hive2.X 与 Hive3.X 协议，能够实现无缝对接开源与自研的所有计算引擎。同时，所有 API 、SDK 和对接开源引擎的客户端已经在阿里云上开源，支持客户自研引擎、应用或系统集成。

另外，依托于底层存储的表格存储，面向海量结构化提供的 service 服务有着非常优秀的弹性伸缩能力，无需担心扩展问题。同时提供了高可用、免运维的能力。

此外，提供统一的权限控制，用户只需依靠权限的配置，无论在 EMR 引擎上、阿里云的自研引擎上，还是在 DataWorks 等数据开发平台上，都可以实现多引擎、多管理平台或多应用的统一权限管控。能够支持阿里云 RAM 以及开源 LDAP 账号体系。

统一元数据服务的最下层是数据湖存储，目前支持对象存储和文件存储。数据服务层提供了两个基础服务：第一层是 catalog ，负责管理元数据，包括 Catalog、Database、Function 和 Table；第二层是权限服务，包括 ACL 体系、RBAC 和 PBAC，TBAC 正在计划中（主要针对资源包）。

再上层对接阿里云网关认证体系，支持 RAM 的子账号鉴权以及权限策略，可以实现底层元数据 API 和权限 API ，之上提供了 SDK 插件体系。有的云厂商保留了所有组件，在 Hive Metastore 内部进行封装来实现开源的无缝对接。其优点在于只需改动 Hive Metastore，其他的引擎都能自动对接到 Hive Metastore 上。而阿里云没有选择 Hive Metastore 方案，主要出于以下几个考量：

首先，保留 Hive Metastore 会带来一定的成本，所有请求都需要进行转发，会导致性能损耗。同时， Hive Metastore 本身的稳定性会影响整体元数据服务的稳定性，而且随着用户集群流量的增大，Metastore 也需要扩容。因此阿里云选择了在轻量级 SDK 上实现 client 接口并直接嵌入到引擎中，实现开源引擎到 DLF 服务的对接。

阿里云自研的引擎 MaxCompute、Hologres 以及全托管的 OLAP 引擎也已经完全对接DLF。另外，用户的元数据管理应用或开发平台也可以对接 API。

很多用户内部的元数据管理应用通过 JDBC 的方式连接底层的 mysql ，而这也可能存在问题。比如底层元数据结构的升级会导致应用也需要改动。另一方面，直接对接JDBC接口查询底层数据，完全没有权限控制。但是如果对接 DLF API ，无论是 API 访问还是 EMR 访问，都会经过一层权限的控制体系，不会泄露权限。

阿里云上数据湖统一元数据基本功能及优化

阿里云提供了多租户和统一的数据目录，是以阿里云账号进行租户之间隔离的一种机制。阿里云账号下可以创建多个 catalog，提供了 table 级别的 schema 多版本，可以根据版本数据查询 table schema 的演变过程。同时阿里云内部各引擎通过支持 DLF，也同时实现了 Iceberg、Hudi、Delta 数据湖格式打通。

此外，在 catalog 上会按租户的元数据做分区，用户的存储不会打在同一个后端存储的热点分区上。同时，我们实现了 ID 化，方便后续进行软删除、异步删除等优化。同时，在很多请求上实现了异步化。

IO 方面也进行了部分优化。比如做 List partition 时，返回的是同一个表 partition 的所有元数据，而在大多数场景上 partition 元数据的 SD 都相同，因此完全可以基于相同的 SD 做共享，进行 partition SD 压缩，减少网络层的 IO 。

阿里云上数据湖统一元数据之稳定性机制

稳定性是另一个比较关键的问题。在云上需要对接所有租户，因此元数据服务的升级、灰度、自动恢复能力非常重要。自动恢复能力和弹性伸缩是云上的标配，都是基于资源调度系统实现。

稳定性机制的底层是阿里云 Table Store，上层是元数据服务。元数据服务有两个常驻集群A和B，互为主备关系。在做升级时，将备服务配置为灰度状态，前端网关根据服务的配置策略以及租户分桶策略采集流量，然后发到灰度服务上，观察灰度流量是否正常，如果正常则升级到主服务；如果出现问题，则根据配置回滚即可。

升级对用户侧、引擎侧完全无感知。即使是服务下线，也会等到主服务的流量归零才下线，这一层依赖于元数据自己的网关，因此可以实现得更为轻量，比如可以通过切断心跳的方式实现下线。

三、阿里云数据湖统一权限服务

实现数据湖统一权限服务，首先要解决两个问题：身份的问题、API 和引擎的访问权限一致性问题。

上图为数据湖统一权限架构图。底层为湖上数据及元数据，上层为数据湖统一鉴权服务，包括网关、用户模型转换、引擎的鉴权插件体系和 DLF 数据访问服务端鉴权。最上层是已经实现以及进行中的数据湖格式、开源引擎、数仓、数据湖构建平台以及应用。

目前，我们提供了 ACL 和 RBAC 和 PBAC 三种权限控制相结合的方式，ACL 和 Policy 互相补充。其中 ACL 模式依赖于授权的主体和客体，因此主客体必须存在，支持白名单授权。Policy 同时支持白名单和黑名单。

引擎侧与 API 侧如何实现统一的鉴权？

如果是用户持有 AK 或在外部操作上使用管理平台，则该层级全部通过 DLF SDK/API，在服务端元数据访问时会调用底下的鉴权引擎。

如果是 EMR 开源集群，用户通过 beeline 接口方式、通过 LDAP 认证，再通过 Spark ThriftServer 获取元数据。引擎会持有可信的身份，经过可信身份校验后引擎可以获取所有元数据，再由引擎负责用户模型的转换，获取用户的操作与身份，代理用户鉴权，将相应的鉴权请求发到服务端，调用同样的服务端鉴权逻辑，最终实现引擎侧和 API 层的统一鉴权。