@tonly 你把虚拟机调到2G内存试试吧，因为你的日志里显示你的executor的JVM需要XMX1024M，所以你的虚拟机最少要1G以上的内存。Spark集群内存调小是不行的，因为内存太小了，是启不来的。

@tonly 你虚拟机多大内存啊？

@tonly 你提交任务时查看一下集群上master日志看看有没有什么问题。

不是摒弃以前的方案，两者要结合使用

借助大数据平台来运算用户行为数据等海量日志数据。运算结果存到传统库中。大数据平台不能像以前做web开发那样直接连接，因为用户接受不了这样的响应速度。

好像是你的任务找不到你的节点位置，应该是你的本地spark配置缺少这样的信息

为啥不用spark mllib那？

你这台机器比别的机器的region少呗，hbase会让所有regionserver的region总量上平衡，但不是非得每个表都平均分配到每个region上。

@魏超 hbase的rowkey是按字典顺排的，这是基础问题，你这种需求得使用filter用startrow和endrow不好使。

@韦晓阳 你那么大的数据放到map里也不能毫秒级了吧，要是百万级的数据到可以试试，超过这个级别就用外部存储吧，hbase大批量读写的时候就不能毫秒级的了，nosql库复杂查询的能力差些，需要自己提前设计好满足所有查询条件的KV，storm不也支持窗口排序吗。大量数据一次性插入redis要使用pipeline的方式。你几千条、几万条的数据量不大插入redis挺快的。主要看redis存储的总量有多大，太大了性能指定会受影响，所以尽可能用节省内存的方式往redis里存数据，给redis开足够大的内存，让数据都缓存在内存里，这样性能才是最好的。

记住处部缓存吧，redis或者hbase都可以。话说这种需求用spark streaming多好

可以理解为如果在使用cogroup时给的partitioner与cogroup里的rdd使用的parttioner不同时就需要划分stage重新进行parttion运算，然后进行再次进行shuffle按新的partitioner算法汇总相同的key，如果给的partitioner与rdd的partitioner是相同的那就不用再次shuffle了，因为在完成cogroup所使用的rdd运算时相同key的数据已经跑到同一个executor中了。

这里看不出来具体啥毛病，你不妨去看一下ExecMapper.java的179行代码，看看报错原因。
从异常来看是hive和Elasticsearch的元信息不匹配，但具体原因建议看一下原代码吧。

Kudu对比hive性能要高很多且支持数据更新，还有一个好处是c++开发的相比java没有了GC延迟时间。在上层，可以用 Impala 查询，也可以使用其他的 SQL on Hadoop 进行查询，SparkSQL 之类的，能很好地融入 Hadoop 生态。而且接口和hbase很像也有scan等。如果你需要对实时数据做查询，如果需要快速地查询，那么 Kudu 无疑是一个好的选择。
Impala只是操作Kudu的一个终端吧，能操作Kudu的有挺多比如刚才说的spark-sql。好处就是都是Cloudera开发的Impala与Kudu兼容性比较好吧

你图上的结果是result.show()的？