目录
2、HBase 的 rowkey 设计需要遵循什么原则,以及如何解决热点问题
3、早几年是有很多 elasticsearch /solr 为 mysql 或者 HBase 作二级索引,但是现在 elasticsearch 在不断的加大在大数据领域的支持,是否可以省去HBase呢
基础题
1、清楚描述 MapReduce 的 shuffle 过程
Map方法之后,数据首先进入到分区方法,把数据标记好分区,然后把数据发送到环形缓冲区;环形缓冲区默认大小100m,环形缓冲区达到80%时,进行溢写;溢写前对数据进行排序,排序按照对key的索引进行字典顺序排序,排序的手段快排;溢写产生大量溢写文件,需要对溢写文件进行归并排序;对溢写的文件也可以进行Combiner操作,前提是汇总操作,求平均值不行。最后将文件按照分区存储到磁盘,等待Reduce端拉取。
2、HBase 的 rowkey 设计需要遵循什么原则,以及如何解决热点问题
1、长度原则 :最大64K,在保证业务需求的前提下,建议越短越好,不要超过16个字节
2、散列原则 :将rowkey的高位作为散列字段,低位放时间字段,这样将提高数据均衡分布在每个RegionServer,以实现负载均衡的几率
3、唯一原则 : 必须在设计上保证其唯一性
热点问题:
概念:热点发生在大量的 client 直接访问集群的一个或极少数个节点(访问可能是读,写或者其他操作)。
如何解决:
① 哈希(随机数):将哈希值放在高位
② 反转:反转固定长度或者数字格式的数据(时间戳反转、手机号反转,订单号反转)
③ 加盐:本质时是加随机数,并且放在高位。
思考题
3、早几年是有很多 elasticsearch /solr 为 mysql 或者 HBase 作二级索引,但是现在 elasticsearch 在不断的加大在大数据领域的支持,是否可以省去HBase呢
首先,ES和hbase设计的出发点就不一样,
elasticsearch作为分布式全文检索引擎,支持复杂的查询条件,常用在需要高效检索的场景,在数据量不大的情况下,亦可做存储,但是数据大的情况下就不适合,因为数据很难取,只能用ES来搜,并且从存储成本来看,也是不如Hbase的。另外,ES是后来被慢慢增强其存储扩展性,所以拓展性方面不如Hbase来的灵活方便。并且es数据更新是对文档进行更新,需要先将es中的数据取出,设置更新字段后再写入es。
hbase作为hadoop生态圈的一员,运行在HDFS之上,先天具备海量数据存储的优势,设计出发点就是为了解决在海量数据的背景下做精准查询,快速返回。另外hbase是列存储的,可以方便地更新任意字段的值。但由于HBase通过 rowkey 对数据进行检索,而rowkey的长度又有所限制,所以对于多条件的复杂查询就显得很吃力,可以看得出来,这2个组件设计的着重点不同,现在常用的方案是将查询字段内容放在elasticsearch上存储查询,同时存储Hbase的rowKey信息.业务使用时,通过elasticsearch查询出Hbase的rowkey,再从Hbase读取出全部信息
总结:写多读少用hbase,读多写少用es
群友@兜兜转转总结:
hbase对比es的优势:
1. hbase的可扩展性好于es,通过支持一些开源的组件来丰富查询能力;
2. 在负载均衡这块,hbase提供的策略更符合实际的需求,而es相对简单;
3. 对于集群稳定性来说,es是计算和存储合一的设计,hbase则是计算和存储分离的设计。在海量数据的场景中,hbase的稳定性和成本控制更有优势;
4. 内存管理这块,hbase相对比较成熟,提供了几种缓存管理策略供用户选择。