大数据开发面试题-附答案

大数据开发面试题-附答案

以下为面试过程中提问，岗位为大数据开发：

.自我介绍+项目介绍

.为ft么用kafka、sparkstreaming,hbase?有什么替

代方案吗？

.聊聊你觉得大数据的整个体系？

.你看过hdfs源码?nn的高可用说一下

.zookeeper简单介绍一下，为什么要用zk?zk的架

构？zab?

.hbase的架构，读写缓存？

.blockcache的底层实现？你提到了LRU那除了

LRU还可以有什么方案？

.聊聊sparkstreaming和flink?flink流批一体解释

一下？

.spark的几种shuffle说下？为什么要丢弃

hashshuffle?

.javagc可达性分析+垃圾回收器+垃圾回收算法+为什

么分代垃圾回收+调优

.数据库引擎，innodb索引实现+聚集和非聚集区别+为

什么用b+树不用hash

.聊聊tcp和udp的区别

.http知道吗？说一下

.http版本之间的比较

.让你设计一个hash表，怎么设计？

.时间不多了，手招一个二分查找

答案解析

本文首发公众号【五分钟学大数据】，可以搜索关

注下，超多大数据精品文章

1.自我介绍+项目介绍

自我介绍可以参考美团面试的这篇文章：美团优选大数据开

发岗面试题

2.为什么用kafka,sparkstreaming,hbase?有什么替代方案吗？

根据简历中写的项目，谈谈为什么用这几个框架，是公司大

数据平台历史选择还是更适合公司业务。

然后在说下每个框架的优点：

Kafka:

•高吞吐量、低延迟：kafka每秒可以处理几十万条消息，

它的延迟最低只有几毫秒；

•可扩展性：kafka集群支持热扩展;

•持久性、可靠性：消息被持久化到本地磁盘，并且支持

数据备份防止数据丢失；

•容错性：允许集群中节点故障（若副本数量为n,则允许

n-1个节点故障）；

•高并发：支持数千个客户端同时读写。

Kafka应用场景：

•日志收集：一个公司可以用Kafka可以收集各种服务

的log,通过kafka以统一接口服务的方式开放给各种

consumer;

•消息系统：解耦生产者和消费者、缓存消息等；

•用户活动跟踪：kafka经常被用来记录web用户或者

app用户的各种活动，如浏览网页、搜索、点击等活动，

这些活动信息被各个服务器发布到kafka的topic中，

然后消费者通过订阅这些topic来做实时的监控分析，

亦可保存到数据库；

・运营指标：kafka也经常用来记录运营监控数据。包括

收集各种分布式应用的数据，生产各种操作的集中反馈，

比如报警和报告；

•流式处理：比如和

sparkstreamingflinko

SparkStreaming优点:

有什么替代方案，就可以聊聊和这几个功能类似的框架，它

们的优缺点等，比如Apachekafka对应的ApachePulsar;

SparkStreaming对应的Flink;HBase对应的列式数据库

可以举几个例子,如Cassandra.MongoDB等。

3.聊聊你觉得大数据的整个体系？

这个是一个开放性题，把你知道的大数据框架都可以说下，

下面是我做的一个Apache大数据框架的集合图，当然也没

有包含全部，只是比较常见的几个：

禽五分钟学大数据

OQPQ2

KylinSqoop二）

Druid

Kafka

Hadoop

Kudu

HBase1Flume0

Impala

ZookeeperDorisAtlas

说的时候尽量按照它们的功能划分及时间先后顺序讲解。

4.你看过hdfs源码？nn的高可用说一下

一个NameNode有单点故障的问题,那就配置双

NameNode,配置有两个关键点,一是必须要保证这两个

NN的元数据信息必须要同步的，二是一个NN挂掉之后

另一个要立马补上。

•元数据信息同步在HA方案中采用的是〃共享存储〃。

每次写文件时，需要将日志同步写入共享存储，这个步骤

成功才能认定写文件成功。然后备份节点定期从共享存储

同步日志，以便进行主备切换。

.监控NN状态采用zookeeper,两个NN节点的状

态存放在ZK中，另外两个NN节点分别有一个进程监

控程序，实施读取ZK中有NN的状态，来判断当前的

NN是不是已经down机。如果standby的NN节

点的ZKFC发现主节点已经挂掉，那么就会强制给原本

的activeNN节点发送强制关闭请求，之后将备用的

设置为

NNactiveo

如果面试官再问HA中的共享存储是怎么实

现的知道吗？

可以进行解释下：NameNode共享存储方案有很

多，比如LinuxHA,VMwareFT,QJM等，目前

社区已经把由Clouderea公司实现的基于QJM

(QuorumJournalManager)的方案合并到

HDFS的trunk之中并且作为默认的共享存储

实现

基于QJM的共享存储系统主要用于保存

EditLog,并不保存FSImage文件。FSImage文

件还是在NameNode的本地磁盘上。QJM共享

存储的基本思想来自于Paxos算法，采用多个称

为JournalNode的节点组成的JournalNode

集群来存储EditLog。每个JournalNode保存

同样的EditLog副本。每次NameNode写

EditLog的时候，除了向本地磁盘写入EditLog

之外也会并行地向JournalNode集群之中的每

一个JournalNode发送写请求，只要大多数

(majority)的JournalNode节点返回成功就认

为向JournalNode集群写入EditLog成功。如

果有2N+1台JournalNode,那么根据大多数

的原则，最多可以容忍有N台JournalNode节

点挂掉

注：Hadoop3.x允许用户运行多个备用NameNode。例如，

通过配置三个NameNode和五个JournalNode,群集能

够容忍两个节点而不是一个节点的故障。

HDFS的其他内容可看之前写的这篇文章：HDFS分布式文

件系统详解

5.zookeeper简单介绍一下，为什么要用zk?zk的架构?zab?

zk介绍及功能：

Zookeeper是一个分布式协调服务的开源框架。主要用来

解决分布式集群中应用系统的一致性问题，例如怎样避免同

时操作同一数据造成脏读的问题。

ZooKeeper本质上是一个分布式的小文件存储系统。提供基

于类似于文件系统的目录树方式的数据存储，并且可以对树

中的节点进行有效管理。从而用来维护和监控你存储的数据

的状态变化。通过监控这些数据状态的变化，从而可以达到

基于数据的集群管理。诸如：统一命名服务（dubb。）、分

布式配置管理（solr的配置集中管理）、分布式消息队列

（sub/pub）.分布式锁、分布式协调等功能。

zk架构：

zk架构图：

Leader:

Zookeeper集群工作的核心；

事务请求（写操作）的唯一调度和处理者，保证

集群事务处理的顺序性；

集群内部各个服务器的调度者。

对于create,setData,delete等有写操作的

请求，则需要统一转发给leader处理，leader

需要决定编号、执行操作，这个过程称为一个事务。

Follower:

处理客户端非事务（读操作）请求，

转发事务请求给Leader;

参与集群Leader选举投票2n-l台可以做集群

投票。

此外，针对访问量比较大的zookeeper集群，还

可新增观察者角色。

Observer:

观察者角色，观察Zookeeper集群的最新状态变

化并将这些状态同步过来，其对于非事务请求可以

进行独立处理，对于事务请求，则会转发给

Leader服务器进行处理。

不会参与任何形式的投票只提供非事务服务，通常

用于在不影响集群事务处理能力的前提下提升集

群的非事务处理能力。

简答：说白了就是增加并发的读请求

ZAB协议全称:ZookeeperAtomicBroadcast（Zookeeper

原子广播协议）。

ZAB协议是专门为zookeeper实现分布式协调功能而设

计。zookeeper主要是根据ZAB协议是实现分布式系统数

据一致性。

zookeeper根据ZAB协议建立了主备模型完成

zookeeper集群中数据的同步。这里所说的主备系统架构模

型是指,在zookeeper集群中，只有一台leader负责处

理外部客户端的事物请求（或写操作），然后leader服务器

将客户端的写操作数据同步到所有的follower节点中。

6.HBase的架构，读写缓存？

HBase的架构可以看这篇文章，非常详细：HBase底层原

理详解

下面说下HBase的读写缓存：

HBase的RegionServer的缓存主要分为两个部分，分别

是MemStore和BlockCache,其中MemStore主要用于

写缓存，而BlockCache用于读缓存。

HBase执行写操作首先会将数据写入MemStore,并顺序

写入HLog,等满足一定条件后统一将MemStore中数据

刷新到磁盘,这种设计可以极大地提升HBase的写性能。

不仅如此，MemStore对于读性能也至关重要，假如没有

MemStore,读取刚写入的数据就需要从文件中通过10查

找，这种代价显然是昂贵的！

BlockCache称为读缓存，HBase会将一次文件查找的

Block块缓存到Cache中，以便后续同一请求或者邻近数

据查找请求，可以直接从内存中获取避免昂贵的I。操作。

7.BlockCache的底层实现？你提到了LRU那除了LRU还可以有什么方案？

我们知道缓存有三种不同的更新策略，分别是FIFO（先入先

出）、LRU（最近最少使用）和LFU（最近最不常使用）。

HBase的block默认使用的是LRU策略：

此外还有（此

LRUBIockCacheoBucketCache,SlabCache

缓存在0.98版本已经不被建议使用）

LRUBIockCache实现机制：

LRUBIockCache是HBase目前默认的BlockCache机

制，实现机制比较简单。它使用一个ConcurrentHashMap

管理BlockKey至!]Block的映射关系，缓存Block只需

要将BlockKey和对应的Block放入该HashMap中渣

询缓存就根据BlockKey从HashMap中获取即可。

同时该方案采用严格的LRU淘汰算法，当BlockCache

总量达到一定阈值之后就会启动淘汰机制，最近最少使用的

Block会被置换出来。在具体的实现细节方面，需要关注几

点：

缓存分层策略

HBase在LRU缓存基础上，采用了缓存分层设计，将整个

BlockCache分为三个音B分：single-access,mutil-access

和inMemory。

需要特别注意的是，HBase系统元数据存放在InMemory

区，因此设置数据属性InMemory=true需要非常谨慎，

确保此列族数据量很小且访问频繁，否则有可能会将

hbase.meta元数据挤出内存，严重影响所有业务性能。

LRU淘汰算法实现

系统在每次cacheblock时将BlockKey和Block放入

HashMap后都会检查BlockCache总量是否达到阈值，如

果达到阈值，就会唤醒淘汰线程对Map中的Block进行

淘汰。

系统设置三个MinMaxPriorityQueue队列，分别对应上述

三个分层，每个队列中的元素按照最近最少被使用排列，系

统会优先poll出最近最少使用的元素，将其对应的内存释

放。可见，三个分层中的Block会分别执行LRU淘汰算法

进行淘汰。

8.聊聊sparkstreaming和flink?flink流批一体解释一下？

Flink是标准的实时处理引擎，基于事件驱动。而Spark

Streaming是微批(Micro-Batch)的模型。

下面就分几个方面介绍两个框架的主要区别：

.架构模型：SparkStreaming在运行时的主要角色包

括：Master、Worker、Driver.Executor;Flink在运

行时主要包:、和

JobmanagerTaskmanagerSloto

.任务调度：SparkStreaming连续不断的生成微小的

数据批次，构建有向无环图DAG,SparkStreaming会

依次创

DStreamGraphxJobGeneratorxJobScheduler;

Flink根据用户提交的代码生成StreamGraph,经过优

化生成JobGr叩h,然后提交给JobManager进行处理，

JobManager会根据JobGraph生成

ExecutionGraph,ExecutionGraph是Flink调度最核

心的数据结构，JobManager根据ExecutionGraph对

Job进行调度。

.时间机制：SparkStreaming支持的时间机制有限，

只支持处理时间。Flink支持了流处理程序在时间上的三

个定义：处理时间、事件时间、注入时间。同时也支持

watermark机制来处理滞后数据。

.容错机制：对于SparkStreaming任务，我们可以设

置然后假如发生故障并重启，我们可以从

checkpointr

上次checkpoint之处恢复，但是这个行为只能使得数

据不丢失，可能会重复处理，不能做到恰好一次处理语

义。Flink则使用两阶段提交协议来解决这个问题。

Flink的两阶段提交协议具体可以看这篇文章：八张图搞懂

Flink端到端精准一次处理语义Exactly-once

9.spark的几种shuffle说下？为什么要丢弃hashshuffle?

前段时间刚写的，可以看下：Spark的两种核心Shuffle详

解

10.javagc可达性分析+垃圾回收器+垃圾回收算法+为什么分代垃圾回收+调优

JVM相关的面试题可看这篇文章，文中第四、五题和本问题

相关：精选大数据面试真题JVM专项

11.数据库引擎，innodb索引实现+聚集和非聚集区别+为什么用b+树不用hash

innodb索引实现：

innoDB使用的是聚集索引，将主键组织到一棵B+树中,而

行数据就储存在叶子节点上，若使用［whereid=14”这样的

条件查找主键，则按照B+树的检索算法即可查找到对应的叶

节点，之后获得行数据。若对Name列进行条件搜索，则需

要两个步骤：第一步在辅助索引B+树中检索Name,到达其

叶子节点获取对应的主键。

第二步使用主键在主索引B+树中再执行一次B+树检索操作，

最终到达叶子节点即可获取整行数据。

聚集索引和非聚集索引的区别：

•聚集索引一个表只能有一个，而非聚集索引一个表可以

存在多个。

•聚集索引存诸记录是物理上连续存在，而非聚集索引是

逻辑上的连续，物理存储并不连续。

•聚集索弓I：物理存储按照索引排序；聚集索引是一种索引

组织形式，索引的键值逻辑顺序决定了表数据行的物理存

储顺序。

•非聚集索引:物理存储不按照索引排序；非聚集索引则就

是普通索引了，仅仅只是对数据列创建相应的索引，不影

响整个表的物理存储顺序。

•索引是通过二叉树的数据结构来描述的，我们可以这么

理解聚簇索引：索引的叶节点就是数据节点。而非聚簇索

引的叶节点仍然是索引节点，只不过有一个指针指向对应

的数据块。

数据库索引使用B+树原因:

InnoDB采用B+树结构，是因为B+树能够很好地配合磁盘

的读写特性，减少单次查询的磁盘访问次数，降低10、提升

性能等。

数据库索引不适合用hash的原因：

.区间值难找。因为单个值计算会很快，而找区间值，比

如100<id<200就悲催了，需要遍历全部hash节点。

.排序难。通过hash算法，也就是压缩算法，可能会很

大的值和很小的值落在同一个hash桶里，比如一万个数

压缩成1000个数存到hash桶里，也就是会产生hash冲

突。

.不支持利用索引完成排序、以及like'xxx%'这样的

部分模糊查询。

.不支持联合索引的最左前缀匹配规则。

12.聊聊tcp和udp的区别

简单说下：

.TCP面向连接（如打电话要先拨号建立连接）；UDP

是无连接的，即发送数据之前不需要建立连接。

.TCP提供可靠的服务。也就是说，通过TCP连接传送的

数据，无差错，不丢失，不重复，且按序到达；UDP尽最

大努力交付，即不保证可靠交付。

Tcp通过校脸和，重传控制，序号标识，滑动窗口、

确认应答实现可靠传输。如丢包时的重发控制，还

可以对次序乱掉的分包进行顺序控制。

UDP具有较好的实时性，工作效率比TCP高，适用于

对高速传输和实时性有较高的通信或广播通信。

.每一条TCP连接只能是点到点的；UDP支持一对一，

一对多，多对一和多对多的交互通信。

.TCP对系统资源要求较多；UDP对系统资源要求较少。

13.http知道吗？说一下

超文本传输协议（缩写：HTTP）是一种用于分布式、协作式

和超媒体信息系统的应用层协议。HTTP是万维网的数据通信

的基础。

HTTP协议定义Web客户端如何从Web服务器请求Web页

面，以及服务器如何把Web页面传送给客户端。HTTP协议

采用了请求/响应模型。客户端向服务器发送一个请求报文，

请求报文包含请求的方法、URL、协议版本、请求头部和请

求数据。服务器以一个状态行作为响应，响应的内容包括协

议的版本、成功或者错误代码、服务器信息、响应头部和响

应数据。

以下是HTTP请求/响应的步骤：

.客户端连接到Web服务器：

一个HTTP客户端，通常是浏览器,与Web服务器的HTTP

端口（默认为80）建立一个TCP套接字连接。例如，

http:〃www.ba。

.发送HTTP清求：

通过TCP套接字,客户端向Web服务器发送一个文本的请

求报文，一个请求报文由请求行、请求头部、空行和请求数

据4部分组成。

.服务器接受请求并返回HTTP响应：

Web服务器解析请求，定位请求资源。服务器将资源复本写

到TCP套接字，由客户端读取。一个响应由状态行、响应头

部、空行和响应数据4部分组成。

.释放连接TCP连接：

若connection模式为close，则服务器主动关闭TCP连接，

客户端被动关闭连接，释放TCP连接;若connection模式为

keepalive,则该连接会保持一段时间，在该时间内可以继续

接收请求；

客户端浏览器解析HTML内容：

客户端浏览器首先解析状态行，查看表明请求是否成功的状

态代码。然后解析每一个响应头，响应头告知以下为若干字

节的HTML文档和文档的字符集。客户端浏览器读取响应数

据HTML,根据HTML的语法对其进行格式化，并在浏览器

窗口中显示。

14.http版本之间的比较

这道题字节经常问，需要记住：

http0.9:

最初的http版本,仅支持get方法」只能传输纯文本内容,

所以请求结束服务段会给客户端返回一个HTML格式的字符

串，然后由浏览器自己渲染。

http0.9是典型的无状态连接（无状态是指协议对于事务处理

没有记忆功能，对同一个url请求没有上下文关系，每次的

请求都是独立的，服务器中没有保存客户端的状态）

httpl.O:

这个版本后任何文件形式都可以被传输，本质上支持长连接，

但是默认还是短连接，增加了keep-alive关键字来由短链接

变成长连接。

HTTP的请求和回应格式也发生了变化，除了要传输的数据之

外，每次通信都包含头信息，用来描述一些信息。

还增加了状态码(statuscode)、多字符集支持、多部分发

送(multi-parttype)、权限(authorization)、缓存(cache)、

内容编码(contentencoding)等。

httpl.l:

HTTP1.1最大的变化就是引入了长链接，也就是TCP链接默

认是不关闭的可以被多个请求复用。客户端或者服务器如果

长时间发现对方没有活动就会关闭链接，但是规范的做法是

客户端在最后一个请求的时候要求服务器关闭链接。对于同

一个域名，目前浏览器支持建立6个长链接。

节约带宽，HTTP1.1支持只发送header头信息不带任何

body信息、，如果服务器认为客户端有权限请求指定数据那就

返回100,没有就返回401,当客户端收到100的时候可以

才把要请求的信息发给服务器。并且1」还支持了请求部分

内容，如果当前客户端已经有一部分资源了，只需要向服务

器请求另外的部分资源即可，这也是支持文件断点续传的基

础。

1.1版本中增加了host处理，在HTTP1.0中认为每台服务器

都绑定一个唯一的ip地址，因此在URL中并没有传递主机名，

但是随着虚拟机技术的发展，可能在一台物理机器上存在多

个虚拟主机，并且他们共享了一个ip地址，httpl.l中请求

消息和响应消息都支持host头域，如果不存在还会报出错误。

http2.0:

多路复用：在一个连接里面并发处理清求，不像httpl.l在

一个tcp连接中各个请求是串行的，花销很大。

在1.0版本后增加了header头信息12.0版本通过算法把

header进行了压缩这样数据体积就更小，在网络上传输就更

快。

服务端有了推送功能，将客户端感兴趣的东西推给客户端，

当客户端请求这些时，直接去缓存中取就行。

15.让你设计一个hash表，怎么设计？

可以把java的hashm叩的实现原理说下，因为这就是hash

表的经典设计！内容较多，并且网上资料很多，可以自己搜

索查看！

16.时间不多了，手措一个二分直找

二分查找图解：

10>8.与左追秃,mid也值均eft莅坡港碧奴半

二分查或式美•故俎有序

二分查我的史装

1.先找更中间值

1258102535642.然后洛中区值花查我值比皎

2.1月等.我出

2.2=|r-3>瓷左堡,宣左遂行遇去查或

leftmidright2.3中闾里<有我国自右芝行通去查式

史果存在值，犹返三对应的下标，否刻送叵7

1伙25,司石通五md镇宜当ngn追我忑芋再次原半

leftmidright

MM0我到，返回nid

二分查找：时间复杂度O(log2n);空间复杂度0(1)

defbinarySearch(arr:Array[Int],left:Int,right:Int,findVal:In