@魏超 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()的？

@luo6994658 你这种手动指定了相同的GID，老的组不也回收了吗，只是别一种方式覆盖了。还可以理解为老的组做为备份了，新的组删除了是不是这个GID就还给老的组了。所以你可以理解为存在的意义就是被当成备份了。

@luo6994658 是的，ly用户的组是1010，现在1010这个GID是ly1组的，所以不能删因为ly用户是在ly1组的，至于为什么又跑到ly1组了？而不是在原来的ly组了呢？你想想文件是不是从上往下读的，ly和ly1有相同的gid，那当然这个gid分给最后出现的了。也就是说虽然组ID在文件里能重复，但是最终一个组ID只能给一个组，给那个？给/etc/group中最后出现的那个。

@luo6994658 你可以看一下/etc/group和/etc/passwd这两个文件

@魏超 http://www.hainiubl.com/topics/124 你看一下这里面的pagefilter用法

:smile:

用scan方法啊，查出指定范围内的数据，或者查出多少条的

@BigTester 你可以参考一下这里 https://www.cloudera.com/documentation/enterprise/5-4-x/topics/admin_llama.html

@BigTester 可以啊，都是支持JDBC的