集羣環境配置
集羣環境如下圖：
配置信息：
master節點配置（spark-env.sh）：
計算節點：
jutai（192.168.1.210）配置（spark-env.sh）：（機器硬件爲：2個cpu，每個14核。128G內存，4T硬盤）
hpcc（192.168.1.213），dell2 (192.168.1.212:50010)配置：未設置！，默認.（機器爲4核cpu，空閒內存大概2.6G）
（啓動集羣（sbin/start-all.sh）的時候，會根據各個節點的spark-env.sh配置來初始化各個節點提供給整個集羣的資源，若沒有配置信息，則集羣會根據該節點的實際情況自動配置該節點提供給整個集羣的運行資源）
在該集羣上提交任務：
輸入數據：16G高程柵格數據+16G坡度柵格數據=32G
計算：對該數據進行reclassify計算
任務提交命令：
standalone集羣運行：
spark-submit --class com.xgrd.Classify --name China-Standalone --master spark://spark:7077 --executor-memory 8G --total-executor-cores 8 /home/xgrd_v1.0.0.jar -e hdfs://masters/user/lyc/ChinaElevation256/tileZip -s hdfs://masters/user/lyc/ChinaSlope256/tileZip -o hdfs://masters/user/lyc/ChinaHHHH -g
（提交任務時需要設置使用總核數，每個executor內存，設置好後，spark集羣會根據集羣中的資源情況分配運行命令所要求的資源數）
運行時間記錄：
- local運行時間：34分14秒 ，38分45秒（單線程）
- 4核executor 8G：15分鐘（啓動了2個work，每個work使用了2核、8G，2個executor）
- 4核executor 16G：15分鐘
- 4核executor 4G：16分鐘
- 4核executor 2G：17分鐘，4核executor 1G：17分鐘（由於dell2和hpcc能夠提供所需的資源，任務在這兩臺較差的節點上啓動，沒有在jutai上面啓動worker）
【關閉dell2和hpcc兩臺節點，再次運行4核executor 2G，時間還是爲17分鐘，與上次的區別在於啓動的兩個worker都在jutai上面，但運行時間沒有變化，說明在一臺機器上面的worker和在不同機器上的worker運行效果相同。並不存在同一機器上的多個worker運行任務會變快的情況】
- 8核executor 8G：8.6分鐘
- 8核executor 16G：9.4分鐘（啓動了4個worker，每個worker使用了2核、16G）
- 10核executor 4G：8.4分鐘
- 12核executor 4G：7.4分鐘
- 14核executor 4G：6.8分鐘
- 16核executor 8G：5.7分鐘 、5.9分鐘（啓動了8個worker，每個worker使用了2核、8G）
- 16核executor 16G：6分鐘
- 16核executor 4G：5.7分鐘 （啓動了8個worker，每個worker使用了2核、4G，8個executor）
- 16核executor 2G：5.9分鐘（啓動了8個worker（其中配置低的兩個內存爲2.6G的worker也投入使用），每個worker使用了2核、2G，8個executor）
- 16核executor 1G：6.0分鐘
- 16核executor 512M：6.5分鐘
- 18核executor 2G：7分鐘
- 32核executor 1G：5.9分鐘（啓動了全部的10個worker（8個2核1G，2個4核2G），共12個executor，實際啓動24核）
運行任務記錄：
實驗總結，該任務運行時間在內存足夠的情況下主要與分配的cpu核相關，1-16核間任務執行時間隨着核數的遞增而減少，時間減少幅度基本與cup核數增加的倍數相同，超過16核後，時間基本沒有什麼變化，表明此spark任務的並行度已經達到最大，此時硬件的增加不能加快任務的執行，優化只能從程序本身入手