基于JVM的大数据程序都很难避开资源管理或者内存管理这个问题
(a) JVM的内存overhead太大，1G的数据通常需要消耗5G的内存 -> Project Tungsten 正试图解决这个问题； (b) 不同的spark app之间缺乏有效的共享内存机制 -> Project Tachyon 在试图引入分布式的内存管理，这样不同的spark app可以共享缓存的数据
最明显的当然是内存需要太多，花钱太多。 还有部署麻烦，能否一键安装。 运行过程中不要老是oom。 能否自动调优等等
1. 不稳定，集群偶尔会挂掉。只适合做计算，不适合直接提供服务。 2. 数据的partition不够好，会导致集群中的各台机器上计算任务分配不平均。 3. 任务调度不够好。
Spark内存计算体现它可以将RDD常驻内存（内存不足也会溢写到磁盘的），这样可以减少磁盘IO。缺点的话我觉得在于1.资源调度方面，Spark和Hadoop不同，执行时采用的是多线程模式，Hadoop是多进程，多线程模式会减少启动时间，但也带来了无法细粒度资源分配的问题。但本质上讲其实这也不能算是Spark的缺点，只不过是tradeoff之后的结果而已。2.其实Spark这种利用内存计算的思想的分布式系统你想要最大发挥其性能优势的话对集群资源配置要求较高，比如内存（当然内存不足也能用），通俗地说就是比较烧钱。 Spark或者说基于JVM的大数据程序都很难避开资源管理或者内存管理这个坑，说到底，隔了一层JVM。 相对而言，kudu/impala在这方面就会有一些优势。 当然内存玩花的副作用就是玩不好，带来的问题要比JVM会麻烦的多的多。
