大数据面试-20210310

目录

基础题

1、清楚描述 MapReduce 的 shuffle 过程

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相对比较成熟，提供了几种缓存管理策略供用户选择。