【携程】-Alluxio在携程大数据平台的探索与优化.pdf

《【携程】-Alluxio在携程大数据平台的探索与优化.pdf》由会员分享，可在线阅读，更多相关《【携程】-Alluxio在携程大数据平台的探索与优化.pdf（27页珍藏版）》请在三个皮匠报告上搜索。

1、Alluxio 在携程大数据平台的探索与优化钱勇携程数据基础架构组目录 1 个性化透明访问 2 实现自定义认证与多租户 3 个性化全链路 CallerContext 4 动态下发 Alluxio 客户端配置 5 未来规划携程大数据基础架构个性化透明访问底层存储系统PART 1透明命名机制Alluxio 提供了透明命名机制，保证了Alluxio 和底层存储系统命名空间身份一致性。但客户端使用需要将 locationUrl 的 schema 从 hdfs:/改为 alluxio:/才可以访问表，使用起来不够便捷。实现透明访问 重新实现一个自定义的文件系统客户端 TripCustomFileSyst

2、em 初始化 mExternalHadoopFileSystem 和 mInternalAlluxioFileSystem 配置 fs.hdfs.impl 为 TripCustomFileSystem，替换 DistributedFileSystem 增加 alluxio.use.alluxio.for.read 开关决定是否从 Alluxio 读 Cache 支持在 Alluxio 不可用时 fallback 到原生 HDFS,以满足携程的生态系统需求alluxio.use.alluxio.for.read=true spark.hadoop.fs.hdfs.impl=alluxio.had

3、oop.TripCustomFileSystem遇到的挑战挑战一：Spark Yarn client 模式下 DelegationToken 问题解决：重写 TripCustomFileSystem 的 getDelegationToken 方法，直接使用 HDFS 的 DelegationTokenpublic Token getDelegationToken(String renewer)throws IOException return mExternalHadoopFileSystem.getDelegationToken(renewer);挑战二：Alluxio 和 HDFS 的 M

4、odificationTime 不一致导致 NM 下载资源失败解决：“写”操作使用原生 HDFS，以避免 ModificationTime 不一致return mExternalHadoopFileSystem.create(f,permission,overwrite,bufferSize,replication,blockSize,progress);遇到的挑战挑战三：简单的 open 失败回切 HDFS 并不能在 Alluxio worker 全挂时 fallback解决方案：在 read 之前获取文件状态时，做 worker 数量检查，若 worker 全部挂掉 直接抛出异常，回切到

5、HDFS if(mFileSystemMaster.getWorkerInfoList().isEmpty()throw new UnavailableException(The workers list is empty,no available Alluxioworker);遇到的挑战SQL 测试效果总结：Alluxio 在某些重点是读取的 SQL 情况下效果更好，但对于重点是计算、数据量不大却计算复杂的场景效果一般。我们选取了多个不同类型的线上真实 SQL，分别使用和不使用 Alluxio 缓存两种情况进行对比，得出以下结果：实现自定义认证、支持多租户PART 2安全认证SIMPLE:最

6、基本的认证模式。客户端只需向 Alluxio 服务端提供用户名，服务端会接受这个用户名并用它来识别客户端的身份，安全性较低，因为任何人都伪装成任何用户。NOSASL:不进行任何安全认证。客户端可以以任何用户的身份连接到 Alluxio 服务，而服务端也不会对客户端的身份进行验证，存在明显的安全风险。CUSTOM:可以自定义自己的认证方式。通过指定自定义的安全认证实现类，验证客户端用户和密码是否匹配，用户可以根据自己的需求实现认证逻辑，提供了极大的灵活性。实现自定义认证 增加 alluxio.security.login.password 实现 Alluxio.security.authenti