Spark-ETL测试

Geotrellis-spark-etl测试

• 前提条件

   进行到这一阶段，我们假设你已经具备了基本的spark，scala开发的能力，对Geotrellis也已经并不陌生，至少我们假设你已经使用过它，实现了一些简单的示例。

   如果你没有具备以上条件，请自行参考相关资料，比如官方文档（强力推荐），同时我们也提供了《Geotrellis使用初探》，应该会对您有所帮助。

   在开始使用和实现Geotrellis-spark-etl之前，需要你具备以下条件：

1. 稳定的测试环境。笔者的测试环境是公司提供的一个小型的集群环境，采用CDH版本的Hadoop和spark，结合当前条件对集群的参数配置调试优化后，集群稳定运行达半年之久。

如图：

      2.影像数据。数据是必要的，没有数据，接下来的操作，测试无从谈起。我们的测试数据格式均为tif，而且规格基本相同，为tif模式。每块数据大小为78M。注意：如果你的单个数据块大小超过2G，请预先做切割处理。

      3.将Geotrellis官方的源码包编译打包成jar包，分发上传至集群。目前阶段，我们只是初步的验证测试，所以一下操作只在单节点进行（除了涉及spark计算）。关于Geotrellis的打包处理，我们在《Geotrellis使用初探》中有过介绍，在此不再赘述。

• 测试前准备

1. 创建目录

     输入以下命令：

#mkdir -p /home/tmp

#mkdir -p /home/tmp/json

#mkdir -p /home/tmp/tif

依次创建tmp,json,tif目录，用以存放测试文件，路径文件，测试数据等，如图：

     2.配置json文件

     测试所需的json配置随着需求，业务方向等因素的不同而改变，并非固定，所以在此仅仅以官方文档示例为演示。

输入文件：input.json配置：

此处path:必须与你实际的测试数据存放路径一致。

输出文件：output.json配置：

此处为运行提交spark应用，运行成功后的输出文件路径，注意：在节点处检查对应目录下是否有catalog文件，如有，则删除。

后端存储文件：backend-profiles.json配置：

目前为止，仅为测试，并没有连接任何数据库存储处理结果数据的需求，如果在生产环境中，需要保存数据切片，则参考Geotrellis官方文档给出的配置。

• 测试

1. --master local[*]模式

     Spark提交应用脚本：

spark2-submit \

--class geotrellis.spark.etl.MultibandIngest \

--master 'local[*]' \

--driver-memory 2g \

/home/tmp/geotrellis-spark-etl-assembly-2.0.0-M2.jar

--input "file:///home/tmp/json/input.json" \

--output "file:///home/tmp/json/output.json" \

--backend-profiles "file:///home/tmp/json/backend-profiles.json"

测试数据大小：78M

耗时：17Min

找到输出文件，如图;

查看输出，如图;

访问spark 的History Server所在节点的18089端口，如图：

可以查看应用的相关信息。

测试结果：

本次测试数据量分别为：78M，156M，780M，5.4G。

通过Spark-submit脚本提交应用后，任务运行时间分别为17Min,20Min,50Min，作业启动失败，报OOM。

通过查看spark 的History Server所在节点的18089端口，即可获取作业的详细信息，如图：

而得到的处理结果，数据量基本是double多一点，如图：

78M处理结果：

780M处理结果：

   2.--master yarn-client模式

Spark提交应用脚本：

spark2-submit \

--class geotrellis.spark.etl.MultibandIngest \

--master yarn-client --num-executors 10 --driver-memory 1g \

--driver-cores 1 --executor-memory 1g --executor-cores 1 \

/home/tmp/geotrellis-spark-etl-assembly-2.0.0-M2.jar

--input "file:///home/tmp/json/input.json" \

--output "file:///home/tmp/json/output.json" \

--backend-profiles "file:///home/tmp/json/backend-profiles.json"

测试数据大小：78M，

耗时：18MIn，如图：

找到输出文件：

查看结果：

测试结果：

78M处理结果：

780M处理结果：

   分布式处理结果分散在各个节点，总量也几乎是两倍多一点，由于搜集数据比较麻烦，而且当集群庞大时，也不可取，所以在这里不做展示。

耗时：24MIn

• 总结

• 根据上述测试过程和结果，我们可以看出，更大的内存和更多的计算核心对Spark应用会更有用处，Spark的架构允许线性伸缩，双倍的资源通常能使应用的运行时间减半。
• 采用本篇文档中的spark2-submit脚本提交应用时，yarn-client模式需要在此之前将测试的配置，文件和数据等同步到集群各节点（或者所使用的所有节点），并保证文件权限一致。
• 在脚本运行应用时，很可能会遇到Job aborted due to stage failure: Task 10 in stage 6.0 failed 4 times, most recent failure: Lost task 10.3 in stage 6.0 (TID 123, feiwei01, executor 12): java.io.IOException: Mkdirs failed to create directory file:/home/tmp/catalog/example/20/part-r-00010-520256382734这个错误信息，首先检查各节点的输出路径是否具有写权限；其次，应用本身受各种因素影响，自然会有失败的概率，可以多做尝试；最后，如果失败次数过多，检查配置，应用程序等，这就涉及到另外的方面，在此不做阐述。
• 本次脚本运行应用只是做初步的测试，只求应用可以运行，得到结果，并未做调优，优化考虑，集群资源也并未充分利用，所以，有待改进。
• 测试输出结果随着测试数据量增大，会分布式存储，散落在集群节点。但是，无论哪种方式，所得到的输出数据均为原数据的双倍多一点。