前提条件
进行到这一阶段，我们假设你已经具备了基本的spark，scala开发的能力，对Geotrellis也已经并不陌生，至少我们假设你已经使用过它，实现了一些简单的示例。
如果你没有具备以上条件，请自行参考相关资料，比如官方文档（强力推荐），同时我们也提供了《Geotrellis使用初探》，应该会对您有所帮助。
在开始使用和实现Geotrellis-spark-etl之前，需要你具备以下条件：
稳定的测试环境。笔者的测试环境是公司提供的一个小型的集群环境，采用CDH版本的Hadoop和spark，结合当前条件对集群的参数配置调试优化后，集群稳定运行达半年之久。如图：
2.影像数据。数据是必要的，没有数据，接下来的操作，测试无从谈起。我们的测试数据格式均为tif，而且规格基本相同，为tif模式。每块数据大小为78M。注意：如果你的单个数据块大小超过2G，请预先做切割处理。
3.将Geotrellis官方的源码包编译打包成jar包，分发上传至集群。目前阶段，我们只是初步的验证测试，所以一下操作只在单节点进行（除了涉及spark计算）。关于Geotrellis的打包处理，我们在《Geotrellis使用初探》中有过介绍，在此不再赘述。
测试前准备 创建目录输入以下命令：
#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官方文档给出的配置。
测试 --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这个错误信息，首先检查各节点的输出路径是否具有写权限；其次，应用本身受各种因素影响，自然会有失败的概率，可以多做尝试；最后，如果失败次数过多，检查配置，应用程序等，这就涉及到另外的方面，在此不做阐述。本次脚本运行应用只是做初步的测试，只求应用可以运行，得到结果，并未做调优，优化考虑，集群资源也并未充分利用，所以，有待改进。测试输出结果随着测试数据量增大，会分布式存储，散落在集群节点。但是，无论哪种方式，所得到的输出数据均为原数据的双倍多一点。