举例子说：脚本名称叫入参三个:
1
23运行123后$*为123（互相被引号包裹起来）$@为123（三个被包裹起来）$#为3（参数数量）
0是linux中shell脚本本身的名字则是还有其它的一些相似的来表示追加：
$1是传信给该shell脚本的第一个参数$2是传信给该shell脚本的第二个参数$@是传脚本的所有参数的列表$#是放出来脚本的参数个数
hbase通过预分区，一定判断rowkey的分布决定合理不的预分区方案，要决定的点除了region的个数、region的大小等
在hbaseshell中可以使用create建表时只写了表名和列族名，那就这张表将只能一个region，当一个region的大小达到阈值时会不自动print成两个，但explode能操作会受到资源消耗。region个数太少时，在数据量大、访问量大，或被批处理程序读写情况下性能很可能会不怎么好，但是夹杂大量生产读写冲来的gc可能会会使regionserver宕机，接着region被transit到其他节点上，将逐步搞垮hbase集群上的所有节点。
1、分配哪些资源？
executor、coreperexecutor、memoryperexecutor、drivermemory2、在哪分区分配这些资源？
在我们在生产环境中，并提交spark作业时，带的spark-approveshell脚本，里面调整按的参数/usr/sources/spark/bin/spark-submit--class--num-executors3配置executor的数量--executor-memory100m配置每个executor的内存大小--executor-cores3配置每个executor的cpucore数量--driver-memory100m配置driver的内存（影响比较大）/usr/local/sparktest-0.0.1-snapshot-jar-with-dependencies.jar3、可以调节到多大，算得大呢？
第一种，sparkstandalone，公司集群上，重新搭建了一套spark集群，你心里应该要明白每台机器还能够给你在用的，大致有多少内存，多少cpucore；那就，设置里的时候，就依据什么这个求实际的情况，去适当调节每个spark作业的资源分配。诸如你的每台机器能够给你不使用4g内存，2个cpucore；20台机器；executor，20；平均每个executor：4g内存，2个cpucore。第二种，yarn。资源队列。资源调度。肯定去查找，你的spark作业，要重新提交到的资源队列，hadoopsparkstorm每一个队列都是各自的资源（cpumem）也差不多有多少资源？500g内存，100个cpucore；executor，50；平均每个executor:10g内存，2个cpucore。spark-approve的时候怎么指定你资源队列？--confspark.yarn.queuedefault设置队列名称:spark.yarn.queuedefault一个原则，你能建议使用的资源有多大，就不要去功能调节到的最的大小（executor的数量，七八个到上百个很快；executor内存；executorcpucore）
