大数据面试题

Hadoop
客户端向HDFS写数据的流程
- 客户端和name node通信，name node检查目标文件是否已存在，父目录是否存在,检查通过以后name node通知客户端可以写入

• 客户端向name node请求上传文件的第一个块(block1),询问name node应该把block1上传到哪些data node主机上。客户端每传一个block都要向name node请求

  • name node把3台data node服务器信息返回给客户端。基于可靠性的考虑，每个文件块都有副本，每个副本分别存放在不同的data node服务器上。副本存放的data node选择策略：首选在本地机架的一个节点上存放副本, 第二个副本在本地机架的另一个不同节点，第三个副本在不同机架的不同节点上

  • 正式上传之前，客户端请求与3台中的其中一台(dn1)建立传输通道，dn1又和dn2主机建立传输通道，dn2又和dn3建立传输通道

  • 整个传输通道建立完成后，客户端把block1从磁盘读出来放到本地缓存, 开始向dn1上传block1，上传时以package为单位进行传输，package默认大小64kb。dn1每收到一个package就会复制一份传给dn2，dn2再复制一份传给dn3。

  • 当block1传输完成后，客户端再次向name node申请上传此文件的第二个块block2

客户端从HDFS读数据的流程

• 客户端和name node通信，查询元数据，找到文件块存放的data node服务器信息
• 客户端收到name node返回的信息(例如block1存放在dn1和dn2上，block2在dn2和dn3上)，去找到相应的dn(按就近挑选dn原则，然后随机)，再请求和dn建立socket流
• socket流建立好以后，dn开始向客户端发送数据（从磁盘读取数据放入socket流）
• 客户端以packet为单位接收文件块，把各个块在本地合并成一个完整的文件

HBase
描述HBase的rowkey的设计原则?
Rowkey的长度原则
Rowkey是一个二进制码流,Rowkery的长度被很多开发者建议设计在10~100个字节,不过建议是越短越好，不要超过16 个字节。
原因如下:
(1)数据的持久化文件HFile中按照KeyValue存储的,如果Row\key字节过大,会极大影响Hfile的存储效率
(2)MemStore将缓存部分数据到内存,如果Rowkey过长内存利用效率降低,低，系统将无法缓存更多的数据，这会降低检索效率
Rowkey的散列原则:
如果Rowkey 是按时间戳的方式递增，不要将时间放在二进制码的前面，建议将Rowkey的高位作为散字段，由程序循环生成，低位放时间字段，这样将提高数据均衡分布在每个Regionserver 实现负载均衡的几率。如果没有散列字段，首字段直接是时间信息将产生所有新数据都在一个 RegionServer 上堆积的热点现象，这样在做数据检索的时候负载将会集中在个别RegionServer，降低查询效率。
Rowkey唯一原则:
必须在设计上保证其唯一性。

请描述如何解决Hbase中region太小和region太大带来的冲突.?
Region过大会发生多次compaction，将数据读一遍并重写一遍到hdfs 上，占用io，region过小会造成多次split，region 会下线，影响访问服务，调整hbase.hregion.max.filesize 为256m.

简述 HBASE中compact用途是什么，什么时候触发，分为哪两种,有什么区别，有哪些相关配置参数？
在hbase中每当有memstore数据flush到磁盘之后，就形成一个storefile，当storeFile的数量达到一定程度后，就需要将 storefile 文件来进行 compaction 操作。

Compact 的作用：
1>.合并文件
2>.清除过期，多余版本的数据
3>.提高读写数据的效率
HBase 中实现了两种 compaction 的方式：minor and major. 这两种 compaction 方式的区别是：
1、Minor 操作只用来做部分文件的合并操作以及包括 minVersion=0 并且设置 ttl 的过
期版本清理，不做任何删除数据、多版本数据的清理工作。
2、Major 操作是对 Region 下的HStore下的所有StoreFile执行合并操作，最终的结果是整理合并出一个文件。

HBase写入原理
1 客户端写入请求–>MemStore同时会写入Hlog，类似于Commit log，做数据恢复用

2 MemStore满足条件后刷入StoreFile

3 StoreFile满足条件后多个storeFile合并成一个大StoreFile

4 storeFile到一定大小后触发split，把当前region split成2个region，当前region下线，新region被HMater分配到HRegionServer上

HBase读数据原理
1 客户端请求到zookeeper，zookeeper根据先查询那台主机管理meta信息，把请求转发到该主机

2 hbase 查询-ROOT-和.META获取目标表对应的region，及region对应的regionServer地址，连接regionServer，查到数据

Meta表存储实际创建的表的region信息

因为meta数据特别多，也需要分region存储，所以root表就存储meta表的region信息。Zookeeper先读取zookeeper集群配置获取root表存储的regionServer地址。然后连接该地址访问root表获取目标业务表在meta中对应的region和地址，然后连接到该地址查询meta信息获取实际业务数据存储的region地址，然后连接该地址获取业务数据
Hbase认为root表不会特别大，所以没有分区，直接把root表存储的regionServer地址配置在zookeeper中。
hbase数据刷入物理表时会被顺序写入，在写入内存memstore时已经排序

Hbase客户端默认一次操作发送一次RPC请求到服务端，如果要使用缓冲区批量提交，可以设置自动刷新为false。Table.setAutoFlush(false);
void setWritaeBufferSize(long writeBufferSize) throws IOException可以设置缓冲区大小，默认为2M
也可以在Hbase-site.xml中设置hbase.client.write.buffer

hive
Hive的执行过程.
编译器将Hive SQL语句转换成一组操作符(Operator)
操作符是Hive的最小处理单元
每个操作符处理代表一道HDFS操作或MapReduce作业

操作符:
TableScanOperator 扫描Hive表数据
ReduceSinkOperator

HiveSQL的优化
Hive查询生成多个map reduce job，一个map reduce job又有map，reduce，spill，shuffle，sort等多个阶段，所以针对hive查询的优化可以大致分为针对MR中单个步骤的优化，针对MR全局的优化以及针对整个查询的优化。

* 脑裂（split-brain）*
指在一个高可用（HA）系统中，当联系着的两个节点断开联系时，本来为一个整体的系统，分裂为两个独立节点，这时两个节点开始争抢共享资源，结果会导致系统混乱，数据损坏。

解决问题:
共享存储的fencing，确保只有一个NN能写成功

Spark
性能优化
1、减少批数据的执行时间
在 Spark 中有几个优化可以减少批处理的时间：
1 1 数据接收的并行水平
通过网络(如 kafka，flume，socket 等)接收数据需要这些数据反序列化并被保存到
Spark 中。如果数据接收成为系统的瓶颈，就要考虑并行地接收数据。注意，每个输入
DStream 创建一个 receiver（运行在 worker 机器上）接收单个数据流。创建多个输入
DStream 并配置它们可以从源中接收不同分区的数据流，从而实现多数据流接收。例
如，接收两个 topic 数据的单个输入 DStream 可以被切分为两个 kafka 输入流，每个接
收一个 topic。这将在两个 worker 上运行两个 receiver，因此允许数据并行接收，提高
整体的吞吐量。多个 DStream 可以被合并生成单个 DStream，这样运用在单个输入
DStream 的 transformation 操作可以运用在合并的 DStream 上。
2 2 数据处理的并行水平
如果运行在计算 stage 上的并发任务数不足够大，就不会充分利用集群的资源。
默认的并发任务数通过配置属性来确定 spark.default.parallelism。
3 3 数据序列化
可以通过改变序列化格式来减少数据序列化的开销。在流式传输的情况下，有两
种类型的数据会被序列化：
 输入数据
 由流操作生成的持久 RDD
在上述两种情况下，使用 Kryo 序列化格式可以减少 CPU 和内存开销。
赵强老师直播课课件
赵强老师直播课课件
2、设置正确的批容量
为了 Spark Streaming 应用程序能够在集群中稳定运行，系统应该能够以足够的速度处
理接收的数据（即处理速度应该大于或等于接收数据的速度）。这可以通过流的网络 UI
观察得到。批处理时间应该小于批间隔时间。
根据流计算的性质，批间隔时间可能显著的影响数据处理速率，这个速率可以通过应
用程序维持。可以考虑 WordCountNetwork 这个例子，对于一个特定的数据处理速率，系
统可能可以每 2 秒打印一次单词计数（批间隔时间为 2 秒），但无法每 500 毫秒打印一次
单词计数。所以，为了在生产环境中维持期望的数据处理速率，就应该设置合适的批间隔
时间(即批数据的容量)。
找出正确的批容量的一个好的办法是用一个保守的批间隔时间（5-10,秒）和低数据速
率来测试你的应用程序。
3、内存调优
在这一节，我们重点介绍几个强烈推荐的自定义选项，它们可以减少 Spark Streaming
应用程序垃圾回收的相关暂停，获得更稳定的批处理时间。
 Default persistence level of DStreams ：和 RDDs 不同的是，默认的持久化级别是序
列 化 数 据 到 内 存 中 （ DStream 是 StorageLevel.MEMORY_ONLY_SER ， RDD 是
StorageLevel.MEMORY_ONLY）。即使保存数据为序列化形态会增加序列化/反序列
化的开销，但是可以明显的减少垃圾回收的暂停。
 Clearing persistent RDDs： ：默认情况下，通过 Spark 内置策略（LUR），Spark Streaming
生成的持久化 RDD 将会从内存中清理掉。如果 spark.cleaner.ttl 已经设置了，比这
个时间存在更老的持久化 RDD 将会被定时的清理掉。正如前面提到的那样，这个
值需要根据 Spark Streaming 应用程序的操作小心设置。然而，可以设置配置选项
spark.streaming.unpersist 为 true 来更智能的去持久化（unpersist）RDD。这个配置
使系统找出那些不需要经常保有的 RDD，然后去持久化它们。这可以减少 Spark
RDD 的内存使用，也可能改善垃圾回收的行为。
 Concurrent garbage collector： ：使用并发的标记-清除垃圾回收可以进一步减少垃圾
回收的暂停时间。尽管并发的垃圾回收会减少系统的整体吞吐量，但是仍然推荐
使用它以获得更稳定的批处理时间。