首页 > 代码库 > spark on alluxio和MR on alluxio测试(改进版)【转】

spark on alluxio和MR on alluxio测试(改进版)【转】

转自:http://kaimingwan.com/post/alluxio/spark-on-alluxiohe-mr-on-alluxioce-shi-gai-jin-ban

  • 1. 介绍
  • 2. 准备数据
    • 2.1 清空系统缓存
  • 3. MR测试
    • 3.1 MR without alluxio
    • 3.2 MR with alluxio
    • 3.3 问题补充
  • 4. spark测试
    • 4.1 spark without alluxio
    • 4.2 spark with alluxio
  • 5. 第一阶段实验总结
  • 6. IO实验
    • 6.1 任务负载
    • 6.2 从HDFS中读取10G文件
    • 6.3 从HDFS中读取10G文件
  • 7. 进一步尝试
    • 7.1 存储均衡处理
    • 7.2 使用MR JOB统计行数
    • 7.3 使用MR on alluxio统计行数
    • 7.4 总结

1. 介绍

之前我们进行过一次测试,见文章alluxio和spark以及mapreduce性能对比。但是由于硬件限制,alluxio的效果并没有体现出来。

本次我们将重新进行一番测试。我们采用的硬件配置如下所示:

注意注意!!!:最新的MR on alluxio测试请参考文章MapReduce on alluxio性能测试

ipcpu核数内存承担角色
10.8.12.16 Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz 40核 128GB namenode,alluxio-master,datanode,alluxio-worker,yarn manager
10.8.12.17 Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz 40核 128GB standby namenode,standby alluxio-master,datanode,alluxio-worker
10.8.12.18 Intel(R) Xeon(R) CPU E5-2650 v3 @ 2.30GHz 40核 128GB alluxio-master,datanode,alluxio-worker

2. 准备数据

准备10G的数据,用于MR和Spark来进行计算统计行数。

# 在alluxio上新建存放测试数据的目录
alluxio fs mkdir /linecount

# 按照块大小为64MB,生成10G的文本文件
dd if=/dev/urandom bs=64M count=160 of=10G.txt
#将测试文件放到alluxio内存空间
alluxio fs copyFromLocal 10G.txt /linecount
#再持久化到hdfs,持久化都会存放到HDFS的/alluxio目录下
alluxio fs persist /linecount/10G.txt

2.1 清空系统缓存

位了保证实验的准确性,我们在把数据load到HDFS和alluxio后,需要清下系统缓存确保实验准确性。在各个节点上执行以下操作。

sudo sh -c ‘free && sync && echo 3 > /proc/sys/vm/drop_caches && free‘

3. MR测试

3.1 MR without alluxio

因为之前我们已经编过程序了,我们改下访问路径直接拿来用即可。如果还不会的可以参考我的文章:alluxio和spark以及mapreduce性能对比

测试结果:

技术分享

耗时59秒,对10G文件进行行数统计(=。=# 机器配置牛逼就是diao)

3.2 MR with alluxio

跑一下测试:

技术分享

耗时59秒(多次实验的平均值基本在1分左右)

3.3 问题补充

进行实验的时候可能会有如下报错:

Diagnostics: org.apache.commons.codec.binary.Base64.encodeBase64String([B)Ljava/lang/String;

出现这个问题主要是由于alluxio源码编译的问题。关于这个请参考我的文章:alluxio1.2.0 for hadoop 2.7.2安装

PS: 这个问题反馈给作者后,在1.3的版本中已经修复,可以下载最新版本。

4. spark测试

4.1 spark without alluxio

这里需要注意的是,在运行spark job的时候,我们发现spark job实际比MR运行的要慢。当没有对spark进行任何调优,按照默认的设置在spark-shell运行同样的line-count的任务。我整整花了6分钟。

关于该问题的描述可以参看SF上我的提问。Why line count job runs slower in spark shell than a mapreduce job

简单调优后,对10G文件进行分析统计行数,耗时1分27秒(只是进行简单调优,虽然仍然没有MR快,但是已经比原来的6分钟好的多了)

4.2 spark with alluxio

耗时1分21秒

5. 第一阶段实验总结

alluxio并没有达到预期的效果,这是什么原因呢?让我们来分析下。

首先我们可以先看看官方进行的spark on alluxio和spark without alluxio的实验——Using Alluxio to Improve the Performance and Consistency of HDFS Clusters

可以发现,官方进行实验的时候的负载模拟,还是与真实环境相近的。即同时存在每周的分析JOB和每月的分析JOB。任务也可以分为I/O密集和CPU密集的任务。我们采用linecount来进行实验,没有达到预期效果,可能是以下原因:

首先可以肯定的是我们确实清除了缓存的数据,但是经过多次实验发现。使用alluxio和不使用alluxio所花时间基本是一致的。这也就是说,在使用alluxio的时候,程序可能还是去读取HDFS了,从而导致时间上没有本质的差别。具体是什么问题我们还需继续探究。

6. IO实验

alluxio最大的作用就是IO加速。按理说,之前的实验如果正常进行的话,读取数据和写出结果的IO时间,在使用alluxio之后必然都会大大减少,因为可以从内存中直接取数据。

为此,为了更加集中的研究问题症结所在,现在我们仅仅调用HDFS和ALLUXIO的IO接口来进行文件读取,验证是否在IO性能上alluxio能帮我改进性能。

6.1 任务负载

我们需要读取的数据仍然为随机生成的10G大文件。无论是从HDFS上读取还是从alluxio中读取,我们都采用单个线程来进行文件读取。实验分为两个大组做为对比实验。即从HDFS上读文件和从alluxio中读文件。每个大组内的实验分为2个任务类型:

6.2 从HDFS中读取10G文件

注意确保清空系统缓存,并且用free确认。

采用的代码如下,我们按照64MB一个批次来读取。

public class RWHDFSTest {
   public static void main(String[] args) throws IOException {

        //统计时间
        System.out.println("程序开始时间戳信息:"+new Date());
        final long startTime=System.currentTimeMillis();

        Configuration conf = initialConfig("KaimingWan", "hdfs://ns", "10.8.12.16");


        //设置需要访问的文件在HDFS上的URL
        String uri = "/alluxio/linecount/10G.txt";

        Path path = new Path(uri);

        normalFileReader(conf, path,uri);


        final long endTime=System.currentTimeMillis();
        float excTime=(float)(endTime-startTime)/1000;
        System.out.println("执行时间:"+excTime+"s");
        System.out.println("当前时间为:"+ new Date());


    }

        //读取任意格式数据
    public static void normalFileReader(Configuration conf,Path path,String uri)throws IOException {
        FileSystem fileSystem = FileSystem.get(URI.create(uri), conf);
        FSDataInputStream fsDataInputStream = fileSystem.open(path);

        //读取64MB字节读取
        byte[] buffer = new byte[67108864];
        //记录读取长度
        int len = fsDataInputStream.read(buffer);
        while (len != -1) {
            //System.out.write(buffer, 0, len);
            len = fsDataInputStream.read(buffer);
        }
    }
}

技术分享

6.3 从HDFS中读取10G文件

把上面的地址改成:alluxio://10.8.12.16:19998 再次运行

技术分享

发现耗时更久啦

7. 进一步尝试

再次猜测可能以下原因导致,再进一步进行测试。

  1. 远程提交代码运行MR JOB或者远程来操作HDFS都会有大量的IO时间浪费
  2. 同一个10G的文件的数据块全部分散在一个worker上,这导致跨worker的网络IO开销

7.1 存储均衡处理

为了保证实验结果有效性,先确保10G的数据块全部均匀分布在各个worker上。

# 如果从本地文件系统拷贝过去,可以使用命令:
alluxio fs -Dalluxio.user.file.write.location.policy.class=alluxio.client.file.policy.RoundRobinPolicy copyFromLocal 10G.txt /linecount/10G.txt
# 如果从UFS上拷贝过去,可以使用命令
alluxio fs -Dalluxio.user.file.write.location.policy.class=alluxio.client.file.policy.RoundRobinPolicy load /linecount/10G.txt

7.2 使用MR JOB统计行数

仍然确保每个节点上都清空系统缓存。将程序打包成JAR在master节点上提交, 耗时1分03秒

技术分享

7.3 使用MR on alluxio统计行数

结果耗时34秒

7.4 总结

在经过诸多“磨难”之后,总算是做出了符合预期的实验,即MR on alluxio能带来性能的提升。在此过程中,我还使用了iostat和nload工具来监控了磁盘IO和网络IO。最终发现MR on alluxio确实是从内存取数据。虽然通过负载均衡的放置数据,减少了网络IO开销,但是通过监控网络IO发现仍然存在大量的网络IO开销。因此alluxio所带来的性能提升比较小,按理说应该会有数倍以上的提升才是。

可见,要通过合理的设计和配置才能发挥alluxio的性能,否则甚至可能会做出使用alluxio性能反而更差的结果。后期针对网络IO流量过大的问题,还需再探究。想了解更多可以关注我后续的文章。

alluxio

spark on alluxio和MR on alluxio测试(改进版)【转】