百度案例：利用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、S三、百度对象存储(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学习与发展的干货
欢迎关注全平台AI垂类自媒体 “读芯术”

（添加小编微信：dxsxbb，加入读者圈，一块儿讨论最新鲜的人工智能科技哦～）