线上Spark处理Bzip2引出Hadoop Bzip2线程安全问题

在线上Spark集群处理Hadoop Bzip2压缩文件时出现计算结果偏差,经过排查发现Bzip2Codec存在线程安全问题。在CBzip2InputStream的skipDecompression标志位为静态变量,导致多线程读取BZip2流时出现问题。解决方案是将skipDecompression改为非静态变量,并相应调整方法调用。问题修复后,处理Bzip2文件结果恢复正常。
摘要由CSDN通过智能技术生成

我们的Hadoop生产环境有两个版本,其中一个是1.0.3,为了支持日志压缩和split,我们添加了hadoop-1.2中关于Bzip2压缩的feature. 一切运行良好。

为了满足公司对迭代计算的需求(复杂HiveSQL,广告推荐算法,机器学习 etc), 我们构建了自己的Spark集群,最初是Standalone Mode,版本spark-0.9.1,支持Shark。

上线后,问题接踵而来,最为致命的是,shark在处理Hadooop bzip2文件时计算结果通常会有偏差,有时差的特别离谱(比如,用shark统计1个5kw行的日志,结果只有

3kw行).

显然shark+hive+spark+hadoop的某个环节出了bug。第一次面对这么复杂的系统,着实头疼。

于是,开始蛮干,部署shark+hive+spark+hadoop开发环境,debug,查看出问题的环节。(这个过程中把Spark-core的源码也缕了一遍),始终没有发现什么问题。

后来,参加了Spark技术大会,和同行交流的过程中,幡然悔悟: Spark的task是线程级并发的,而Hadoop MR的task是进程级并发的,那么,会不会是Bzip2存在线程安全问题呢?

回来后,查看Bzip2Codec相关的代码,终于发现了问题所在。(话说,凌晨3点,没有eclipse,用vim 改的), 迫不及待的重新编译Hadoop和Spark,测试,发现处理Bzip2结果OK了!


     CBzip2InputStream 有一个flag变量

  • 1
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值