百度案例：利用Alluxio实现安全的即插即用分布式文件系统

全文共3361字，预计学习时长7分钟

本文介绍了百度如何依靠开源项目Alluxio，在一个企业大数据分析解决项目Pingo中创建了一个安全、模块化和可扩展的分布式文件系统服务。

在这篇文章中，你将学习如何依靠Alluxio来实现一个统一的分布式文件系统服务，以及如何在Alluxio之上添加插件，这包括自定义身份验证方案和Alluxio文件上的用户函数UDF。

目标和挑战

Pingo是百度的产品，提供离线大数据分析解决方案，依靠Apache Spark作为资源调度、数据和元数据管理，以及工作流管理的计算引擎。Pingo不仅应用于百度的内部基础设施建设，还用于服务百度公共云和私有云的部署。

鉴于这些目标用例的需求，Pingo在设计上需要支持高效和统一的数据访问：无论数据是本地的还是远程的，结构化的还是非结构化的，存储在on-prem存储设备或云存储服务中。此外，由于企业需要处理大量的文件，在身份验证和授权方面的安全需求迫使Pingo做出更加复杂的设计。

Pingo利用Alluxio从各种存储解决方案里抽象出数据差异。Pingo还对Alluxio进行了改进，从而能够提供统一的身份验证管理，而不暴露原始存储系统的身份验证信息。

实施和定制

在Pingo中，文件系统管理服务(PFS)是基于Alluxio实现的。利用Alluxio提供的安装能力，PFS可以轻松地整合各种文件系统或对象存储，如HDFS、S3、百度对象存储(BOS)或Linux中的本地文件系统(详见第2.1节)。

将特定分布式文件系统使用统一的文件系统API安装到PFS后，用户只需使用Pingo的内置帐户和权限管理系统，就可以隐藏多样的特定分布式文件系统。Pingo还在Alluxio中添加了一个自定义ACL权限机制，用来帮助企业内大型团队的数据管理(参见2.2,2.3节)。

此外，产品中还配备了带有文件系统级权限检查的表级授权(第2.4节)，并且实现了基于PFS的文件化UDF管理机制(第2.5节)

支持新的文件系统类型

Pingo支持挂载BOS，这是百度公共云提供的对象存储服务。BOS提供了一个类似于AWSS3的接口，然而，在使用S3协议将BOS挂载到Alluxio时仍然存在一些问题。为了访问BOS中的文件，我们整合了BOSUnderFileSystem类，扩展了Allurxio现有的ObjectUnderFileSystem抽象类。

此外，还整合了另一个名为SshUnderFileSystem的下端存储系统，它通过基于Github的Alluxio、Alluxio扩展代码上使用的FTP（SSH文件传输协议）访问文件。

自定义身份验证

如前所述，Pingo已经内置UserService用于用户身份验证。我们扩展了Alluxio现有的身份验证机制，添加了一个新的，基于Pingo UserService的身份验证服务类型。具体而言，我们为alluxio.security.authentication.Authtype添加了一个枚举值PINGO。

在Alluxio Master端，我们添加了一个PingoAuthenticationProvider，它能将客户端发送的用户名和身份验证信息转发至Pingo的UserService。

细粒度授权

由于一些针对大数据工作负载的特殊需求，我们应用了一种新的机制来管理PFS中的ACL权限。我们发现无论是传统的Unix特权模型Unix privilege model(Linux中的默认特权模型)还是POSIX ACL privilege model都不能满足我们的需求。

以下面的需求为例:希望递归地授予用户“ua”和“ub”对目录/a/b/data中所有子路径的阅读访问权；无论在/a/b/data下新增多少子路径，用户“ua”和“ub”都可以自动获得阅读访问权。但是，如果管理员决定撤消对该目录下“ub”的阅读访问权限，那么他只需要在/a/b/data目录上更改权限级别即可。

有大数据平台工作经验的用户应该知道，一个文件夹中很容易塞满成千上万份文件甚至更多，而现有的授权系统还不能有效地解决这样数量级的文件。

PFS同时支持Unix特权模型和PFS独有的ACL特权模型。对于阅读和写入访问，PFS将首先遵循路径上任何存在的被定义ACL记录；否则，它将回退到Unix权限模型。对于管理访问，例如需要管理权限的Linux chmod命令，它则遵循ACL或Unix模型对访问请求进行身份验证。

ACL定义了三种类型的权限:阅读、写入和管理。Unix权限模型中的可执行权限合并为阅读权限（READ）。文件(剪辑)的ACL授权记录可以被引用如下:

Inherit: true/false

USER: uname_1 READ/WRITE/MANAGE

...

USER: uname_n READ/WRITE/MANAGE

GROUP: gname_1 READ/WRITE/MANAGE

...

GROUP: gname_n READ/WRITE/MANAGE

授权记录中的每个USER: uname_n READ/WRITE/MANAGE规则定义了用户是否可以读取、写入、管理文件或目录。本节前面提到的示例是通过继承属性（inherit attribute）解决的。

与Unix特权模型只在要访问的路径的最后一个级别进行身份验证不同，当继承为“正确”（True）时，只要有记录满足条件——从路径最后一级路径到根节点或继承“错误”（False）的任何节点，PFS就会授权访问。

集成表和文件权限

像Pingo这样的分析平台，和像MySQL这样的传统数据库之间一个有趣的区别是：在Pingo，工作台和文件都是可访问的，而在MySQL中，想要访问工作台只能通过客户端或JDBC在工作台上运行查询。访问实际存储数据的文件是没有意义的。在大数据系统中，工作台可以通过Spark这样的SQL引擎查询，但是原始文件也可以直接通过MapReduce或Dataframe查询。

这给访问控制带来了挑战:如果授权用户访问工作台T1，管理员可能只希望用户通过提供的SQL接口访问T1的数据，而不允许访问相应的分区文件。如果管理员撤销用户对T1的访问，用户将不再能够通过SQL或文件系统访问对应于T1工作台的文件数据。

在Pingo，连PFS和Pingo的帐户身份验证系统，用来实现权限代理机制，正如下面图2所示。最初创建工作台T1时，T1创建者的信息保存在了TMetaServer中。

执行查询时，用户首先完成T1的访问身份验证。通过身份验证之后，查询引擎可以获得与T1对应的PFS路径、创建者信息，以及身份验证信息，然后在PFS中对T1的创建者进行实际身份验证。这样，只要用户能够访问工作台，就可以读取工作台数据。

基于文件的UDF管理

UDF广泛应用于SQL查询引擎。用户通常需要首先上传一个jar文件，然后在SQL引擎中注册一个临时函数。这种使用UDF的方法不仅需要额外的步骤，而且很难管理和版本控制jar文件，因此，它通常会降低迭代的速度。

如图3所示，在PFS中实现了一个基于文件的UDF管理解决方案。UDF的创建者只需要将相应的jar文件上传到PFS中的指定目录。Alluxio Worker端将自动从jar文件中提取UDF信息并将其报告给Master端，根据文件名自动跟踪不同的UDF版本。用户在执行SQL时不需要注册UDF——他们只需要指定函数的名称或版本。

此方法类似于Linux管理“.so”文件(动态链接库)，但有更多好处:UDF变得非常容易使用，并且很容易在PFS中实现将权限管理作为文件系统ACL权限的一部分，它还允许小团队快速迭代和共享源代码。

结语

本文介绍了Pingo如何使用开源项目Alluxio构建其文件系统服务，以及如何实现自定义身份验证、细粒度授权、基于文件的UDF管理等附加功能。

留言 点赞 关注

我们一起分享AI学习与发展的干货

如需转载，请后台留言，遵守转载规范