大数据面试-20210310

电玩女神 2022-10-05 10:48 124阅读 0赞

**目录**

基础题

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