BAT大数据面试题

1、kafka 的message 包括哪些信息

一个Kafka 的Message 由一个固定长度的 header 和一个变长的消息体 body 组成 header 部分由一个字节的 magic （文件格式）和四个字节的CRC32（用于判断body 消息体

是否正常）构成。当magic 的值为1的时候，会在magic 和crc32之间多一个字节的数据:

attributes （保存一些相关属性，比如是否压缩、压缩格式等等

）；如果magic 的值为

么不存在attributes 属性

body 是由N 个字节构成的一个消息体，包含了具体的

key/value 消息

2、怎么查看kafka 的offset

0.9版本以上，可以用最新的 Consumer client 客户端，有 consumer.seekToEnd （）

onsumer.position （）

可以用于得到当前最新的 offset :

3、hadoop 的 shuffle 过程

一、Map 端的 shuffle

Map 端会处理输入数据并产生中间结果，

这个中间结果

会写到本地磁盘， 而不是 每个Map 的输出会先写到内存缓冲区中，当写入的数据达到设定的阈值时，系统将会启动

在spill 写入之前，会先进行二次排序， 首先根据数据所属的

Partition 进行排序,

每个partition 中的数据再按key 来排序。partition 的目是将记录划分到不同的

Reducer

上去，以期望能够达到负载均衡， 以后的Reducer 就会根据partition 来读取自己对应的数 据。接着运行combiner （如果设置了的话），combiner 的本质也是一个 Reducer ，其目的

是对将要写入到磁盘上的文件先进行一次处理, 这样，写入到磁盘的数据量就会减少。 最后

0,那

HDFS 。 一个线程将缓冲区的数据写到磁盘，这个过程叫做

spill 。 然后

将数据写到本地磁盘产生spill文件（Spill文件保存在{mapred.local.dir} 指定的目录中,

Map任务结束后就会被删除）。

最后，每个Map任务可能产生多个spill文件，在每个Map任务完成前，会通过多路

归并算法将这些spill文件归并成一个文件。至此，Map的shuffle过程就结束了。

二、Reduce 端的shuffle

Reduce 端的shuffle 主要包括三个阶段，copy、sort(merge) 和reduce 。

首先要将Map端产生的输出文件拷贝到Reduce端，但每个Reducer如何知道自己

应该处理哪些数据呢？因为Map端进行partition 的时候，实际上就相当于指定了每个

Reducer要处理的数据（partition 就对应了Reducer），所以Reducer在拷贝数据的时候只

需拷贝与自己对应的partition 中的数据即可。每个Reducer会处理一个或者多个partition , 但需要先将自己对应的partition 中的数据从每个Map的输出结果中拷贝过来。

接下来就是sort 阶段，也成为merge阶段，因为这个阶段的主要工作是执行了归并排

序。从Map端拷贝到Reduce端的数据都是有序的，所以很适合归并排序。最终在Reduce

端生成一个较大的文件作为Reduce的输入。

最后就是Reduce过程了，在这个过程中产生了最终的输出结果，并将其写到HDFS

上

。

4、spark集群运算的模式

Sp ark有很多种模式，最简单就是单机本地模式，还有单机伪分布式模式，复杂的则运行

在集群中，目前能很好的运行在Yarn和Mesos中，当然Spark还有自带的Standalo

ne 模式，对于大多数情况

Standalone

模式就足够了，如果企业已经有 Yarn 或者Mes

OS 环境，也是很方便部署的。

standalone （集群模式）：典型的Mater/slave 模式，不过也能看出

Spark 支持 ZooKeeper 来实现 HA on yarn （集群模式）：运行在yarn 资源管理器框架之上，由 k 负责任务调度和计算

Spark 负责任务调度和计算

5、HDFS 读写数据的过程

读:

packet 为单位接收，现在本地缓存，然后写入目标文件

写:

1、根name node 通信请求上传文件，name node 检查目标文件是否已存在，父目录是否 存在

2、name node 返回是否可以上传

3、clie nt 请求第一个 block 该传输到哪些data node 服务器上

Master 是有单点故障的;

yarn 负责资源管理，Spar

on mesos （集群模式）：运行在 mesos 资源管理器框架之上, 由 mesos

负责资源管理,

on cloud （集群模式）：比如AWS

的EC2，使用这个模式能很方便的访问

Amazon 的 S

3;Spark 支持多种分布式存储系统:

HDFS 和 S3

1、跟name node 通信查询元数据, 找到文件块所在的

data node

服务器

2、挑选一台 data node （就近原则，然后随机）服务器，请求建立 socket

3、data node

开始发送数据（从磁盘里面读取数据放入流，以 packet 为单位来做校验）

4、客户端以

4、name node 返回 3 个data node 服务器ABC

5、client请求3台dn中的一台A上传数据（本质上是一个RPC调用，建立pipeline），

A收到请求会继续调用B，然后B调用C,将真个pipeline建立完成，逐级返回客户端

6、client开始往A上传第一个block （先从磁盘读取数据放到一个本地内存缓存），以

acket为单位，A收到一个packet就会传给B，B传给C ；A每传一个packet 会放入一个应答队列等待应答

7、当一个block 传输完成之后，clie nt再次请求name node 上传第二个block 的服务器。

6、RDD中reduceBykey 与groupByKey 哪个性能好，为什么

reduceByKey : reduceByKey 会在结果发送至reducer之前会对每个mapper在本地

进行merge ，有点类似于在Map Reduce 中的combi ner。这样做的好处在于，在map端

进行一次reduce之后，数据量会大幅度减小，从而减小传输，保证reduce端能够更快的

进行结果计算。

group ByKey : grou pByKey 会对每一个RDD中的value值进行聚合形成一个序列

（Iterator），此操作发生在reduce端，所以势必会将所有的数据通过网络进行传输, 造成不必要的浪费。同时如果数据量十分大，可能还会造成OutOfMemoryError 。

通过以上对比可以发现在进行大量数据的reduce操作时候建议使用reduceByKey。不仅

可以提高速度，还是可以防止使用grou pByKey 造成的内存溢出问题。

7、spark2.0 的了解

更简单：ANSI SQL与更合理的API

速度更快：用Spark作为编译器

更智能：Structured Stream ing

8、rdd 怎么分区宽依赖和窄依赖

宽依赖：父RDD的分区被子RDD的多个分区使用例如groupByKey 、reduceByKey 、sortByKey等操作会产生宽依赖，会产生shuffle

窄依赖：父RDD的每个分区都只被子RDD的一个分区使用例如map、filter、union等

操作会产生窄依赖

9、spark streaming 读取kafka 数据的两种方式

这两种方式分别是:

Receiver-base

使用Kafka的高层次Consumer API 来实现。receiver从Kafka中获取的数据都存储在

Sp ark Executor 的内存中，然后Spark Streami ng 启动的job会去处理那些数据。然而, 在默认的配置下，这种方式可能会因为底层的失败而丢失数据。如果要启用高可靠机制，让数据零丢失，就必须启用Sp ark Streami ng 的预写日志机制(Write Ahead Log ，WAL)。

该机制会同步地将接收到的Kafka数据写入分布式文件系统（比如HDFS ）上的预写日志

中。

所以，即使底层节点出现了失败，也可以使用预写日志中的数据进行恢

复。

Direct

Spark1.3中引入Direct方式，用来替代掉使用Receiver接收数据，这种方式会周期性地

查询Kafka，获得每个topic+partition 的最新的offset，从而定义每个batch的offset

的范围。当处理数据的job启动时，就会使用Kafka的简单consumer api 来获取Kafka 指定ofset范围的数据。

10、kafka的数据存在内存还是磁盘

Kafka最核心的思想是使用磁盘，而不是使用内存，可能所有人都会认为, 内存的速度一定比磁盘快，我也不例外。在看了Kafka的设计思想，查阅了相应资料再加上自己的测试后,

发现磁盘的顺序读写速度和内存持

平。

而且Linux对于磁盘的读写优化也比较多，包括read-ahead 和write-behind ，磁盘缓存等。如果在内存做这些操作的时候，一个是JAVA对象的内存开销很大，另一个是随着堆内

存数据的增多，JAVA的GC时间会变得很长，使用磁盘操作有以下几个好处:

磁盘缓存由Linux系统维护，减少了程序员的不少工作。

磁盘顺序读写速度超过内存随机读

写。

JVM的GC效率低，内存占用大。使用磁盘可以避免这一问题。

系统冷启动后，磁盘缓存依然可

用。

11、怎么解决kafka的数据丢失

P roducer 端:

宏观上看保证数据的可靠安全性，肯定是依据分区数做好数据备份，设立副本

数。

broker 端:

topic设置多分区，分区自适应所在机器，为了让各分区均匀分布在所在的broker 中，分区数要大于broker数。

分区是kafka进行并行读写的单位，是提升kafka速度的关键。

Con sumer 端

con sumer端丢失消息的情形比较简单：如果在消息处理完成前就提交了offset ，那么就有

可能造成数据的丢失。由于

Kafka con sumer

默认是自动提交位移的，所以在后台提交位

过http 进行数据传输的，这个是设置传输的并行线程数。

移前一定要保证消息被正常处理了，因此不建议采用很重的处理逻辑，如果处理耗时很长, 则建议把逻辑放到另一个线程中去做。为了避免数据丢失，现给出两点建议: en https://www.sodocs.net/doc/b45131577.html,mit=false 关闭自动提交位移 在消息被完整处理之后再手动提交位移 12、fsimage 和 edit 的区别？ 大家都知道name node 与seco ndary name node

的关系，当他们要进行数据同步时叫 做checkpoint 时就用到了 fsimage 与edit ，fsimage 是保存最新的元数据的信息，当 fsimage 数据到一定的大小事会去生成一个新的文件来保存元数据的信息, 这个新的文件就 是edit ，edit 会回滚最新的数据。 13、列举几个配置文件优化? 1)Core-site.xml 文件的优化 a 、fs.trash.interval ，默认值：0;说明： 这个是开启hdfs 文件删除自动转移到垃圾 箱的选项，值为垃圾箱文件清除时间。一般开启这个会比较好，以防错误删除重要文件。单 位是分钟。 b 、https://www.sodocs.net/doc/b45131577.html,node.handler.count ，默认值：10 ;说明：hadoop 系统里启动的任务线 程数，这里改为40 ,同样可以尝试该值大小对效率的影响变化进行最合适的值的设定。 c 、 mapreduce.tasktracker.http.threads

，默认值：40;说明：map 和reduce 是通