spark
资源
spark的资源指的就是cpu core和物理内存。程序运行时，每个core对应一个线程。
application对资源采取声明式的独占，亦即，假设application A声称自己占用了10 cpu和5G内存，那么即使A并不真正使用这些资源，这些资源也不能为其他application所用。所以，如果我们不带参数的在standalone集群上启动spark-shell（默认占用所有资源），则随后用spark-submit提交application时就会遇到“资源不足”的错误。
并发
理解了spark的资源的概念，我们立刻意识到：spark的并发能力取决于资源的分配。假设总共有24个core，每个application只分配1个core，则并发度是24,亦即最多能同时跑24个application。
我们实际的测试中，10w级数据的计算1个core足矣，多了反而会有进程启停、数据传递等额外开销；但千万级的计算，则至少需要10个core，否则不能做到最快。
节点
master、worker、driver和executor节点。
每种节点都是一种进程类型。master、worker是spark启动伊始就有的，负责监听请求，是静态的管理进程。driver和executor则是实际执行任务的进程，只有当一个application到达spark时才会产生，一旦application结束，driver和executor也随之消失，因此是动态的执行进程。
application
application可分为多个job，每个job又可分为若干stage，每个stage分为若干task。
job是按RDD的action动作来划分的，action动作是要立即产生结果的，是严格的，对应的，transformation动作则可以推迟，是惰性的。
job划分stage的标准是看是否存在shuffle，也就是跨节点数据传输。
task是真正跑在线程里的逻辑，一般的，每个executor进程会起线程池来运行task。
sparkSQL
sparkSQL使用scala的parser combinator解析sql为logic plan，logic plan不会考虑数据的物理分布，所以对于一条sql，其logic plan必然是确定的；logic plan接下来会翻译为physic plan去执行，这时就要考虑数据的物理分布了，所以同一条sql，在不同的数据量下，可能会按不同的physic plan来执行。举个例子，对于小表的join操作，physic plan会做broadcast join，即将小表的数据广播到所有节点；但对于大表的join，physic plan则会做sort merge join。
兼论Hive
hive是一种更高层的计算框架，它负责将SQL转成诸如MR、Spark这样的底层计算框架。不过Hive-on-MR的效率实在不敢恭维，Hive2自己都不推荐使用，转而建议使用Hive-on-Spark或Hive-on-Tez。
上文已述及，Spark是不同于MR的计算框架，使用分布式内存来做计算，效率自然远胜。Tez则是MR的改进，合并裁剪了原始MR的一些步骤，因此据说效率相比原始MR有百倍提升。
Hive-on-Spark与SparkSQL倒是同一级的计算框架，只不过sparkSQL只能将SQL转成Spark底层计算，事实上SparkSQL的开发还先于Hive-on-Spark，后者的出现应该是为了保护已有的Hive技术投资。所以，如果我们在项目中已经引入了spark技术，其实没有必要再额外引入hive。