离线和实时在携程大数据中都占据重要地位,为了解决资源竞争带来的问题,我们将部分实时作业单独建立集群,同时带来了新的问题,跨集群读写数据.同时,部分作业需要准时实时的离线查询,这给当前的框架带来挑战.本次分享介绍了如何引入Alluxio来解决这些问题进行了探讨,并分享碰到的一些问题和踩过的坑.

注脚

1.Alluxio 在 携程大数据平台中的实践 郭建华 携程大数据平台研发工程师

2.个人简介 研究生期间有两年的 Spark 研究经验 两年的大数据平台离线相关系统的研发 目前主要专注于 Spark Sql 的 Bug fix 和调优

3.提 纲 携 程大数据平台介绍 存在的问题 Alluxio 作为解决方案 踩过的 坑

4.携程大数据平台简介

5.携 程大数据平台 - 总体架构 资源部署和运维监控 自动运维系统 大数 据 框架设施监控 大数 据业务监控 实时框架 开发平台 Zeus 查询平台 ART 机器学习 算法平台 ( 基 于 Spark MLlib ) 实时数据平台 Muise JStorm Spark Streaming Flink Hermes Kafka Hadoop Hive Spark HBase Presto Kylin Alluxio 调度系统 主数据系统 传输系统 数据质量系统 报 表系统 Adhoc 查询

6.携 程大数据平台 - 平台规模 1600+ 节点 5 万作业 30 万 Application/ 天 90PB / 100PB 元数 据 :ns1: 7 亿 ns2: 1.5 亿 日增 200TB 440 账户, 1000+ 开发人员 Spark:hive 1:2 13+ 集群 JStorm : 150+ 节点 350+ Application Spark Streaming: 50+ 节点 150+ Application Flink : 10+ 节点 20+ Application 离线计算 实时 计算

7.存 在的问题

8.存 在的问题 1. 主 机 群与 Spark Streaming 互相影响 ● NameNode 和 RM 增加功能或者调整配置 , 需要停机维护 ● NameNode 晚上 10 点清理 Trash 数据 , 半小时基本上不工作 ● Spark Streaming 长时间占用资源 , 影响用户队列的资源使用 ● 高峰期 Spark Streaming 重启获取不到资源 措施 : 为 Spark Streaming 搭建一套独立集群

9.存 在的问题 2. 跨集群访问 ● 首先保证 Kerberos 认证同 KDC ● 跨集群读写有两种方式 : read( hdfs ://ns/xxx) 、 save( hdfs ://ns/xxx): RDD 和 DStream spark.sql (“insert tableName ”)

10.存 在的问题 2.1 read 、 save() ● Spark 配置 : spark.yarn.access.namenodes or spark.yarn.access.hadoopFileSystems ● 客户端对 ns-prod 和 ns 进行 配置 , 分别指向主集群和实时集群 ● ResourceManager 也需要添加两个集群的 ns 信息

11.存 在的问题 2.2 spark.sql (“hive insert into or overwrite sql ”) ● 各个集群都是使用 ns 来作为 namespace 名称 , Hive 表的 namespace 是固定的 ns 1. 修改客户端 hdfs-site.xml , 主集群使用 ns, 而实时改成其他名称 2. spark- defaults.conf 中相关的配置也需要进行修改 3. fs.defaultFS 也要修改 ,yarn 、 spark 根据这个配置来创建很多临时路径 技术上可行 , 但是配置乱 , 而且很麻烦

12.存 在的问题 3.NameNode 压力过大 ● metadata 压力过大 ● RPC 压力过大

13.存 在的问题 3.1 metaData 压力过大 ● Federation, 将 yarn, Spark 的日志和中间结果都保存到了 ns2 ● 开发 merge 小 文件程序 (6.7 亿文件 ) , Hive 设置分区 ttl , 清理 过期的分区 (77PB) ● 监控 tmp 表的最近读写,删除长时间未读写的表 (50 万 ) 仍然存在大量不受监控小文件 :

14.存 在的问题 3.1 metaData 压力过 大 ● 再深入的分析 , 发现里面存在大量的 Spark streaming 落地的文件 Streaming 落地的文件两大特点 : 1. 单个文件容量小 , 文件数多 2. 落地的文件或者文件夹时间上很有规律并且密度很高 . Streaming 作业落地文件数多且分散 , 不好监管

15.存 在的问题 3.2 RPC 压力过大 ● 我们将 yarn app log 、 jobhistory 、 yarn-staging- dir 、 spark.yarn.stagingDir 、 spark.history.fs.logDirectory spark.eventLog.dir 、 spark.yarn.archive 迁移到 ns2 来减少 ns1 的 RPC 压力 ● Mover 、 Balancer 中的所有 RPC 请求迁移到了 Standby 节点 ● 还能做的很多

16.存 在的问题 总 结 Spark 跨集群读写可行,但配置乱且麻烦 Streaming 产生的大量小文件,不容易监控 NN RPC 压力 大,还 能优化的工作很多

17.Alluxio

18.引入 Alluxio 流程架构 图 RT HDFS Prod HDFS Alluxio Spark SQL Spark Streaming Kafka hermes qmq mysql 、 ES etl 、 report

19.Alluxio 如何解决问题 1. 跨集群访问问题 ● Alluxio 提供 unified namespace 功能 , 只需要通过简单的 mount 命令 , 实现 mount 多个集群 ● Spark 通过 Alluxio 来读取数据 , 不用关心数据源来自哪个集群 ● 引入 alluxio client jar, 配置 fs.alluxio.impl 指定到 alluxio 的 FileSystem a lluxio :// master:port / data1 data2 adhoc report art Hdfs ://ns2/ art admin admin Hdfs ://ns1/ adhoc report mount mount

20.Alluxio 如何解决问题 2. Streaming 小文件问题 ● Alluxio 提供 TTL 功能,及时 清理 Streaming 生成的文件 ,减少元 数据 ● Alluxio 不使用 HDFS 的 Super 用户 ● 在 HDFS 上创建一个 777 路径 , mount 该路径 , 所有需要落地到 HDFS 的 Streaming 作业 , 都必须写到该路径 , 小文件监管容易 .

21.Alluxio 如何解决问题 3. NameNode RPC 压力 ● Cache 部分热点数据,多作业从 Alluxio 读数据 , 缓解 NameNode RPC 压力 ● 同时 , Alluxio 能够提升 Spark Sql 的执行效率 工具 : hive- testbench ( https:// github.com/gjhkael/hive-testbench) 环境 : Spark2.2.0 on yarn, 5 台 nodemanager , hive 表 :20GB 数据 运行实例 : spark.executor.memory 8g spark.executor.cores 4 spark.executor.instances 5

22.Alluxio 如何解决问题 3. Spark Sql 测试结果 性能提升 : 1.5 倍 query3 query43 query55 query58 query73 query82 HDFS 29 .441 31.116 34.71 68.412 19.98 28.438 Alluxio 23.267 12.431 12.097 45.339 17.342 8.416

23.Alluxio 使用情况 Alluxio1.4 规模 : 2 master + 4Worker 400GB Mem 800GB HDD

24.踩过的坑

25.踩 过的坑 1. 安全隐患问题 ● Alluxio1.4 读写数据没有实现 impersonate, 所以需要 HDFS 的 Super 权限 ● alluxio.security.login.username 指定用户 措施: ● Alluxio 使用普通 HDFS 用户 ● 手动建立一个权限为 777 的 HDFS 路径, mount 该路径来作为持久化路径

26.踩 过的坑 2. TTL 不完善、不支持 Free 策 略 ● 1.4 版本的 Alluxio 只支持指定文件设置 TTL ● 大部 分 Streaming 作业只需要保留近几天的数据 , 需要支持文件夹设置 TTL ● 有些作业只处理近几天数据 , 但是数据需要长时间持久化 , 过期的数据可以 Free 掉 措施: ● 开发基于 Path 的 TTL 支持 , 并贡献给社区 ● 添加 Free 的删除策略功能 , 并贡献给社区 TtlAction DELETE, FREE ; CreateFileOptions SetAttributeOptions

27.踩 过的坑 3. 数据不一致问题 ● Alluxio 本身不会检测底层文件系统的文件状态 ● 当 HDFS 数据已经 Load 到 Alluxio 后,对 HDFS 文 件进行了修改 措施 : ● 开发 makeConsistency 脚本 , 对不一致数据进行修复 , 并贡献给社区 比较策略:文件名、文件大小、修改时间

28.后 续展望 整合 Presto ,加快 Adhoc 和报表系统的响应时间。 继续参与社区的发展

29.Q&A Thanks

user picture
  • Alluxio
  • Alluxio,世界上第一个将分离的异构存储整合到统一平台,并提供近乎内存访问速度的中间件,广泛用于企业和混合云的商业数据分析加速。

相关Slides

  • 本PPT解释了作为支持交易型分布式数据库系统的TiDB核心产品架构及其主要组件,包括TiDB,TiKV,Placement Driver,TiSpark,TheFlash,Tool,TiDB-operator for k8s等,对其基本作用进行阐述,并对其中的核心组件TiKV重点分析,解释了基本数据组织方式,执行方式,数据管理,水平扩展和负载均衡,以及分布式一致性等基本问题。最好对其分析引擎TiSpark也进行了简要功能说明。

  • 介绍了ES的基本结构,功能和原理,重点分析了在实际生产环境中各种运维和监控的指标,以及各种调优经验和配置参数,还有运维自动化的方法论探讨,可以作为ES在实际生产环境中的最佳实践部署和运维监控案例,也可以帮助ES平台维护者理解并思考如何提供更好的ES服务及运维保障。

  • Adaptive Execution @ Spark + AI Summit Europe 2018 Video @ https://databricks.com/session/spark-sql-adaptive-execution-unleashes-the-power-of-cluster-in-large-scale-2

  • Apache Spark作为分布式内存计算引擎,内存使用的优化对于性能提升至关重要,Intel的Optane(傲腾)技术,让内存和SSD之间架设了个新的数据缓存/存储层,并通过PMDK等特殊的API绕过文件系统,系统调用,内存拷贝等一系列额外操作,让性能有极大的提升。Intel开源的OAP(Optimized Analytics Package)for Apache Spark项目,也是基于这个前体,构建即席查询引擎,以及在机器学习算法诸如KMeans算法上也获得了不错的性能回报。