本文介绍了百度如何在项目 Pingo（面向企业的大数据分析解决方案）中创建安全、模块化和可扩展的分布式文件系统服务，基于开源项目Alluxio。
在本文中，您将学习如何合并 Alluxio 以实现统一的分布式文件系统服务，以及如何在 Alluxio 之上添加扩展，包括自定义身份验证方案和 UDF（用户定义的函数）在 Alluxio 文件上。
您可能还喜欢：使用 Alluxio 进行分布式数据查询。
目标与挑战
Pingo 是百度的产品，提供离线大数据分析解决方案，Apache Spark 作为资源调度、数据和元数据管理以及工作流管理的计算引擎。Pingo 不仅用于百度的内部基础设施，还用于为百度公共云和私有云部署的用户提供服务。
由于这些目标用例，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 节），并实现了基于文件的 UDF 管理机制（第 2.5 节）
支持新的文件系统类型
Pingo 支持安装 BOS，这是百度公共云提供的对象存储服务但是，使用 S3 协议将 BOS 安装到 Alluxio 时仍然存在问题。为了访问 BOS 中的文件，我们实现了 BOSUnderFileSystem 该类，扩展了 Alluxio 的现有 ObjectUnderFileSystem 抽象类。
此外，我们还在调用下实现了另一个存储项， SshUnderFileSystem 通过 SFTP（SSH 文件传输协议）访问文件，这些存储在 Github 上的 Alluxio Alluxio 扩展代码库中可用。
自定义身份验证
如前所述，Pingo 内置了用于用户身份验证的用户服务。我们添加了基于 Pingo 用户服务的新身份验证服务类型，扩展了 Alluxio 中现有的身份验证机制。具体而言，我们为 添加了枚举 PINGO alluxio.security.authentication.AuthType 值。
在 Alluxio 主端，我们添加了 一 个 ， PingoAuthenticationProvider 用于将客户端发送的用户名和身份验证信息转发到 Pingo 的用户服务进行身份验证。
细粒度授权
由于一些专门针对大数据工作负载的要求，我们实现了一种管理 PFS 中 ACL 权限的新机制。我们发现，传统的Unix 特权模型（Linux中的默认特权模型）和POSIX ACL 特权模型都不能满足我们的要求。
以以下要求为例：我们希望以递归方式向用户”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/MANAGEUSER: uname_n READ/WRITE/MANAGE授权记录中的每个规则都定义用户是否可以读取、写入或管理文件或目录。本节前面提到的示例由 inherit 属性求解。
与 Unix 特权模型不同，身份验证仅在要访问的路径的最后一个级别进行身份验证，当为 inherit true 时，PFS 授权访问，只要有满足每个级别路径的授权记录中的条件的记录，根或任何节点的路径的最后一个级别 inherit 为 false访问实际存储数据的文件没有意义。在大数据系统中，可以通过 SQL 引擎（如 Spark）查询表，但也可以直接通过 MapReduce 或 Dataframe 查询原始文件。
这就带来了访问控制方面的挑战：如果用户被授权访问表 T1，则管理员可能仅希望用户通过提供的 SQL 接口访问 T1 的数据，而无需访问 T1 的相应分区文件的权限。如果管理员撤消用户对 T1 的访问权限，则用户将不再可以通过 SQL 或文件系统访问与 T1 表对应的文件数据。
在 Pingo 中，我们连接了 PFS 和 Pingo 的帐户身份验证系统，以实现权限代理机制，如下图 2 所示。最初创建表 T1 时，T1 的创建者信息将保存在 TMeta 服务器中。
执行查询时，用户首先完成 T1 的访问身份验证。通过身份验证后，查询引擎可以获取与 T1 对应的 PFS 路径和创建者信息和身份验证信息，然后在 PFS 中实际验证 T1 的创建者。这样，只要用户有权访问表，就可以读取表的数据。
基于文件的 UDF 管理
UDF被广泛应用于许多SQL查询引擎中。用户通常需要首先上载 jar 文件，然后在 SQL 引擎中注册临时函数。这种使用 UDF 的方法不仅需要额外的步骤，而且很难管理和版本控制 jar 文件;因此，它通常会减慢迭代速度。
我们在 PFS 中实现了基于文件的 UDF 管理解决方案，如图 3 所示。UDF 的创建者只需将相应的 jar 文件上载到 PFS 中的指定目录。Alluxio 辅助角色将自动从 jar 文件中提取 UDF 信息并将其报告给主服务器，并基于文件名自动跟踪不同的 UDF 版本。用户在执行 SQL 时不必注册 UDF， 他们只需要指定函数的名称或版本。
我们的方法类似于 Linux 管理”.so”文件（动态链接库）的方式，有几个优点：UDF 变得非常易于使用，并且很容易实现特权管理，作为 PFS 中文件系统 ACL 权限的一部分;它还使小团队能够快速迭代并共享源代码。
总结
在本文中，我们介绍了 Pingo 如何使用开源项目 Alluxio 构建其文件系统服务，并实现自定义身份验证、细粒度授权、基于文件的 UDF 管理等附加功能。