导读
随着大数据技术的快速发展，携程作为旅游行业的领先企业，不断探索和优化大数据平台以提升数据处理和存储效率。本文将深入分享携程在Alluxio 技术应用方面的实践经验。
1.
携程大数据基础架构
2.
个性化透明访问底层存储系统
3.
实现自定义认证与支持多租户
4.
个性化全链路 CallerContext
5.
动态下发 Alluxio 客户端配置
6.
未来规划
7.
Q&A
分享嘉宾｜钱勇
携程数据基础架构组 大数据平台开发工程师
内容校对｜李瑶
出品社区｜
DataFun
携程大数据基础架构
携程大数据平台涵盖了调度平台、报表平台、实时查询、元数据管理、数据质量和数据传输等多个平台，
计算引擎支持
了
S
park
、Hive、Presto/Trino、
Kyuubi
和 StarRocks 等多种引擎。在我们的架构中，Alluxio 作为分布式缓存层来加速计算引擎的读取，具体
来
说
，
用户
从
Kyuubi
使
用
Spark
计算引擎
读取数据时，
利用
Alluxio
做数据缓存
，等到用户再次读取时，则会直接读取 Alluxio 内存中的数据，有效提升了数据读取效率。
个性化透明访问底层存储系统
在大数据生态中，Alluxio 在提升数据访问效率方面扮演着至关重要的角色。为了将 Alluxio 与携程现有的生态系统更好地结合，我们实现了一些自定义功能，首先是实现个性化透明访问底层存储系统。
1.
透明命名机制
Alluxio
提供了透明命名机制，确保了 Alluxio 和底层存储系统之间命名空间的一致性。这一机制的设计目的是为了使得用户在访问数据时能够无缝地从 HDFS 切换到 Alluxio，进而利用 Alluxio 的缓存功能来加速数据访问。然而，要实现这一点，客户端在使用时需要将 locationUrl 的 schema 从 hdfs:// 更改为 alluxio://，这一要求在实践中可能并不方便。
2.
实现企业级透明访问
为了解决这个问题，携程实现了企业级透明访问功能。具体包括：
-
自定义文件系统客户端：我们重新实现了一个自定义文件系统客户端，名为 TripCustomFileSystem，用于替代默认的文件系统客户端。
-
系统初始化：在 TripCustomFileSystem 中，初始化了外部 Hadoop 文件系统(mExternalHadoopFileSystem)和内部Alluxio 文件系统(mInternalAlluxioFileSystem)。
-
配置替换：通过配置 fs.hdfs.impl 为 TripCustomFileSystem，取代了DistributedFileSystem，实现了对 Alluxio 和 HDFS 的透明访问。
-
读取缓存开关：引入 alluxio.use.alluxio.for.read 开关，用于决定是否从Alluxio 读取缓存数据。
-
Fallback
机制：在 Alluxio 不可用时，支持 fallback 到原生 HDFS，
以满足携程的生态系统需求
。
3.
遇到的挑战与解决方案
在实现个性化透明访问的过程中，携程遇到了以下挑战：
-
挑战一：Spark Yarn client 模式下的 DelegationToken 问题。
解决方案：重写 TripCustomFileSystem 的 getDelegationToken 方法，直接使用 HDFS 的 DelegationToken。
-
挑战二：Alluxio 和 HDFS 的 ModificationTime 不一致问题。
最初的解决思路是调整 Alluxio 的 ModificationTime，但最终为了保证数据一致性，避免其他问题，我们选择在写操作时直接使用原生 HDFS，然后只利用 Alluxio 作为读缓存，来解决这个问题。
-
挑战三：
简单的 open 失败回切 HDFS 并不能在 Alluxio worker 全挂时 fallback
为了解决这一问题，我们决定在读操作前进行 worker 数量检查，如果全部挂掉，则直接抛出异常并回切到 HDFS。
4.
性能测试与总结
携程团队对是否使用 Alluxio 缓存的 SQL 进行了性能对比测试。结果显示，
加速收益
前三条 SQL 达到了 40% 到 50%，但是也有一些特别的情况提升并不明显，
甚至
是基本没有提升。
我们对具体的
SQL
任务分析总结，
在读取密集型的场景下使用 Alluxio 缓存后
SQL
性能有显著提升。然而，对于计算密集或数据量不大而计算复杂的 SQL 场景，性能提升不明显。这一发现对于我们如何更好地应用Alluxio 缓存有重要意义。
通过这一系列的实践与优化，Alluxio 不仅提高了数据访问的效率，还增强了大数据平台的整体性能和稳定性，使得在处理大规模数据时能够更加灵活和高效，也进一步提升了用户体验。
实现自定义认证与多租户
我们针对安全认证和支持多租户也进行了深入研究和实践。当前，社区版Alluxio 提供了三种安全认证方式：SIMPLE、NOSASL（无安全认证）、以及自定义的认证方式。
1.
安全认证方式
-
SIMPLE
：这是最基本的认证方式，要求客户端仅向服务端提供一个用户名。服务端接受这个用户名作为客户端的身份。然而，这种方式的安全性较低，因为任何人都可以伪装成任何用户。
-
NOSASL
：这种方式不进行任何安全认证，安全风险极高，因为客户端可以以任何用户的身份连接到 Alluxio 服务，而
服务端也不会对客户端的身份进行验证，存在明显的安全风险。
-
自定义认证：允许通过自定义认证机制来验证客户端的用户和密码是否匹配，提供了较高的安全性和灵活性。开发人员可以根据需求实现简单或复杂的认证逻辑，我们就是采取了自定义认证这种更灵活的方式。
2.
自定义认证实现
-
密码配置：引入了密码配置项，以支持认证过程中的密码验证。
-
认证接口实现：实现了 alluxio.security.authentication.Authenticatio-
nProvider
接口，使用 Cache 缓存用户信息和密码，以支持用户认证。
-
认证方法：在进行用户认证时，通过调用 authenticate 方法进行验证，确保了认证的安全性和有效性。
3.
支持多租户过程中遇到的问题
携程在支持多租户方面做了大量工作，同时也解决了社区版中存在的一些问题。例如，通过使用代理用户时出现的安全问题。我们此处使用 Alice 去代理其他用户(eg: Bob)。在 HDFS 的 audit.log 中，ugi 应该都是 Bob，
但是
有的记录显示为 Alice，有的显示为 Bob，造成了安全隐患。
携程的解决方案是在 new readHandler 时记录 userName，并在 onNext 方法中检查当前线程是否能获取到用户，如果不能，则使用记录的 userName，从而确保了用户身份的正确性和安全性。
4.
Kerberos
认证失效问题
另外，我们还解决了 Kerberos 认证失效的问题，这是因为在 HDFS-
Un
derFileSystem
中对 FileSystem 的缓存没有设置过期时间和更新策略。携程通过增加配置项和使用 expireAfterWrite 过期策略来刷新 FileSystem 中的票据，有效地解决了 Kerberos 认证失效问题。
通过这些改进，不仅增强了大数据平台的安全性，也为数据平台的稳定运行和数据安全提供了有力保障。这些实践不仅解决了携程面临的具体问题，也为 Alluxio 社区和使用 Alluxio 的其他企业提供了宝贵的经验和参考。
个性化全链路 CallerContext
在携程大数据平台的第三部分探索中，特别关注了如何增强数据访问的审计和追踪能力，实现了个性化全链路 CallerContext 功能。这一措施针对 Alluxio 在审计日志（master_audit.log）记录方面的现有功能进行了扩展和优化。
1.
现有审计记录的局限
Alluxio
原生支持的 master_audit.log 记录了一系列审计条目，如操作是否成功（Succeeded）、是否被允许（allowed）、用户组信息（ugi）、客户端 IP（ip）、执行的命令（cmd）、源文件或目录（src）、目标文件或目录（dst）以及权限（perm）。
这些条目大致与 HDFS 的审计日志对齐，提供了基础的审计功能。然而，却缺少了一个关键组成部分：CallerContext
的记录
。CallerContext 包含了更详细的客户端信息，对于追踪数据访问行为至关重要，因此我们实现了个性化全链路CallerContext 的功能。
2.
实现个性化全链路 CallerContext
我们在社区 PR16368 的基础上，进一步深化了对 CallerContext 的应用，
针对携程现有的数据生态，打通
了从 Alluxio C
lient
到 Alluxio Master，再到 HDFS 的 CallerContext 传递。
这一改进使得每一次数据访问都能够被详细记录，从而大大增强了数据访问的透明度和可追踪性。具体到携程的数据生态，这意味着从客户端对数据的写入请求，到数据通过Alluxio 缓存被处理，再到最终被写入 HDFS，整个过程的都能够通过CallerContext 准确地记录下来。这些记录不仅被写入 Alluxio的 master_audit.log，也会存储到 HDFS 的 audit.log，实现了数据访问行为的全面审计。
3.
审计日志的数据整合与应用
为了提高审计数据的可用性和分析效率，携程将 Alluxio 的审计日志与 HDFS 的审计日志进行了整合，并通过定时调度将这些数据落到 Hive 表中。这种做法使得审计数据不仅仅停留在日志文件中，而是转化为可查询、可分析的数据集，极大地方便了数据访问行为的查询和分析。
通过简单的 SQL 查询，携程的大数据团队能够迅速检索到特定文件的访问记录，包括谁访问了该文件、何时访问、以及进行了何种操作等。这种能力对于快速响应数据安全事件、排查数据访问问题、以及优化数据管理策略都具有重要价值。
4.
效果与影响
个性化全链路 CallerContext 的实现保障了携程大数据平台的数据治理能力。它不仅增强了对数据访问行为的监控和审计，还确保了数据的安全性和合规性。此外，这一改进也为数据访问和使用的透明度设立了新的标准，以建立起更加可信和可靠的数据生态环境。
Kyuubi
动态下发 Alluxio 客户端配置
第四部分是关注如何更灵活和有效地管理和下发 Alluxio 的客户端配置。这对于提高大数据作业的配置管理效率和用户体验是至关重要的一环。
1.
传统配置方法的局限性
一种是将配置添加到 ${SPARK_HOME}/conf/spark-defaults.conf 中,
另一种是将配置添加到 Hadoop 配置文件${SPARK_HOME}/conf/core-
这两种方法都属于全局配置，它们的主要缺点在于无法实现用户配置的隔离，导致不同用户之间的配置相互影响，管理上也不够灵活。
2.
动态下发配置的策略
针对这一局限性，携程采用了 Kyuubi 服务来动态下发 Alluxio 客户端配置。这一策略主要基于以下三点特性：
-
Spark
的配置支持：Spark 支持以"spark.hadoop."开头的配置，并且在处理时会自动去除这个前缀。这一特性使得在 Spark 作业中可以动态指定 Hadoop/Alluxio 的相关配置。
-
Alluxio
的配置合并机制：在 Alluxio 客户端初始化时，会合并 Hadoop 的配置属性（hadoopConfProperties），这为动态配置也提供了一定支持。
-
Kyuubi
的用户特有配置：Kyuubi 支持以___{username}___.{config key}的方式来为不同用户设置特有配置，实现了用户级别的隔离和定制。
基于这些特性，携程团队实现了一个更加灵活和高效的配置方式，即允许为不同的用户设置不同的配置默认值。具体来说，通过携程的配置服务 Qconfig 管理 kyuubi-ctrip.properties 文件，进而对 Alluxio 客户端配置的动态下发。
其效果如下：
这种方法不仅提高了配置管理的灵活性，而且也增强了大数据作业用户个性化的体验。
3.
效果与影响
采用 Kyuubi 动态下发 Alluxio 客户端配置的方法，携程成功解决了传统全局配置方法中存在的用户配置无法隔离问题，为不同用户提供了更加个性化和安全的数据处理环境。这种配置策略的实施，极大地提升了大数据作业的配置灵活性和可管理性。
此外，通过用户需求设置特定的 Alluxio 客户端配置，携程能够更加精细地控制和优化数据处理和存储的性能，进一步提高了大数据平台的整体效率和用户满意度。
06
未来规划
目前，我们
携程团队使用 Alluxio Cache 加速携程大数据读取速率，已经应用到 Adhoc 平台多个用户，部署了多个集群，效果可观。我们也正在积极探索更多的应用场景，以便更好地服务于更多用户
，包括以下几个方面：
1.
加速大数据读取
携程将继续探索更多应用 Alluxio Cache 的场景，以进一步加速大数据读取速率。通过应用到更多引擎和场景，为用户提供更加快速和高效的数据处理服务，从而提升整体的用户体验和满意度。
2.
探索 Alluxio Fuse
最近，
我们对 Alluxio Fuse 进行了探索，作为 Alluxio 的特性之一
，它允许 AI 应用直接访问 Alluxio Cache 中的数据，无需通过特定的 API 或协议。这意味着用户可以像操作本地文件一样方便地操作 Alluxio Cache 中的数据，可以极大地提升读取速率和便利性。初步结果表明，通过使用 Alluxio Fuse，数据读取速率有了一定的提升。
3.
扩大集群规模和用户覆盖
未来，我们团队计划进一步扩大集群规模，面向更多的用户提供服务。这不仅包括扩展现有的集群，也涉及到新集群的部署和优化。通过扩大服务范围，为更多的用户提供更快速、更高效的大数据读取服务。
同时，通过不断地技术创新和应用优化，携程希望构建一个更加高效、稳定和可靠的大数据生态，为用户提供卓越的数据处理和分析服务。
07
Q&A
