简答题大大纲
Zookeeper选举机制的类型
Zookeeper选举机制有两种类型，分别为全新集群选举和非全新集群选举，下面分别对两种类型进行详细讲解
1、全新集群选举（考试重点）
全新集群选举是新搭建起来的，没有数据ID和逻辑时钟来影响集群的选举。假设，目前有5台服务器，他们的
编号分别是1
~
5，按编号依次启动Zookeeper服务。下面来讲解全新集群选举的过程。
步骤1：
服务器1启动，首先，会给自己投票；其次，发投票信息，由于其他机器还没有启动所以它无法接收到投票反馈信
息，因此服务器1的状态
一
直属于LOOKING状态。
步骤2：
服务器2启动，首先，会给自己投票；其次，在集群中启动Zookeeper服务的机器发起投票对比，这时它会与服务器
1交换结果，由于服务器2的编号大，所以服务器2胜出，此时服务器1会将票投给服务器2，但此时服务器2的投票数
并没有大于集群半数（2 < 5/2)，所以两个服务器的状态依然是LOOKING状态。
步骤3：
服务器3启动，首先，会给自己投票；其次，与之前启动的服务器1和服务器2交换信息，由于服务器3的编号最大，
所以服务器3胜出，那么服务器1和2会将票投给服务器3，此时投票数正好大于半数（3 > 5/2），所以服务器3成为
领导者状态，服务器1和2成为追随者状态。
步骤4：
服务器4启动，首先，会给自己投票；其次，与之前启动的服务器1、2和3交换信息，尽管服务器4的编号大，但是
服务器3已经胜出。所以服务器4只能成为追随者状态。
步骤5：
服务器5启动，同服务器4
一
样，均成为追随者状态。
2、非全新集群选举
对于正常运行的Zookeeper集群，
一
旦中途有服务器宕机，则需要重新选举时，选举的过程中就需要引人服务
器ID、数据ID和逻辑时钟。这是由于Zookeeper集群已经运行过
一
段时间，那么服务器中就会存在运行的数
据。下面来讲解非全新集群选举的过程
步骤1：
首先，统计逻辑时钟是否相同，逻辑时钟小，这说明途中可能存在宕机问题，因此数据不完整，那么该选举结果被
忽略，重新投票选举；
步骤2：
其次，统
一
逻辑时钟后，对比数据ID值，数据ID反映数据的新旧程度，因此数据ID大的胜出；步骤3：
如果逻辑时钟和数据ID都相同的情况下，那么比较服务器ID（编号），值大则胜出；
简单地讲，非全新集群选举时是优中选优，保证Leader是Zookeeper集群中数据最完整，最可靠的
一
台服务器
写出五个组件
Hadoop（也可以写HDFS、Mapreduce、Yarn。这里就包含了三点）
Hive
Flume
Sqoop
Hbase
Spark
Fink
ZooKeeper
Flume运行机制（8分）
Flume的核心是把数据从数据源（如Web Server） 通过数据采集器（Source）收集过来，再将收集的数据通过缓冲
通道（Channel）汇集到指定的接收器（Sink）。这里可以参考官方的架构图，具体展示Flume运行机制，如图
从图中可以看出，Flume基本架构中有
一
个Agent（代理），它是Flume的核心角色，Flume Agent是
一
个JVM进
程，它承载着数据从外部源流向下
一
个目标的3个核心组件；Source、Channel和Sink。对着3个重要组件进行说
明，具体如下：
Source（数据采集器）：用于源数据的采集（如图，从
一
个Web服务器采集源数据），然后将采集到的数据写入
到Channel中并流向Sink；
Channel（缓冲通道）：底层是
一
个缓冲队列，对Source中的数据进行缓存，将数据高效、准确地写入Sink，待数
据全部到达Sink后，Flume就会删除该缓存通道中的数据；
Sink（接收器）：接收并汇集流向Sink的所有数据，根据需求，可以直接进行集中式存储（如图，采用HDFS进
行存储），也可以作为数据源传入其他远程服务器或者Source中。在整个数据传输的过程中，Flume将 流动的数据封装到
一
个event（事件）中，它是Flume内部数据传输的基本
单元。
一
个完整的event包含headers和body，其中headers包含了
一
些标识信息，而body中就是Flume收集到的数
据信息。
Flume配置采集方案（12分）
因为Flume要采集数据的类型和源头多种多样，并且根据开发需求还要进行不同类型的数据传输和汇总。为此，
根据实际业务需求，Flume专门设计了匹配不同数据类型和传输要求的Flume Source、Flume Channel和Flume Sink。
为了正确地使用Flume对数据进行采集，就必须编写适合开发者需求的Flume采集方案，接下来就编写
一
个采集
netcat（用于TCP/UDP连接和监听的Linux工具，主要用于网络传输及调试领域）源数据的采集方案，如下：
接下来，先对文件编写的采集方案进行说明，具体如下：
1. 采集方案的名称可以自定义，但为了方便管理和使用，通常会根据数据源类型和收集的结果类型进行命名。如
netcat
-
logger.conf表示采集netcat类型数据源并最终作为logger日志信息收集
2. 采集方案文件的位置可以自定义存放、在使用的时候会要求指定配置方案的具体位置，为了更方便统
一
管理，通
常会将采集方案统
一
存放。在本案例中，会将所有自定义的采集方案文件保存在/export/servers/flume/conf目录
下。
3. 采集方案中的sources、channels、sinks是在具体编写时根据业务需求进行配置的，不能随意定义。Flume支持采
集的数据类型可以通过查看官网详细了解（地址http://flume.apache.org/FlumeUserGuide.html),同时针对不同的
sources type、channels type和sinks type需要编写不同的配置属性。
# 实例配置方案：单节点Flume配置
# 定义Agent中各个组件名称
# 其中该Agent名为 a1,source名为r1,sinks名为k1,channels名为c1
a1.sources
=r1
a1.sinks
=k1
a1.channels
=
c1
# 描述并配置sources组件（数据源类型，采集数据源的应用地址）
a1.sources.r1.type
=netcat
a1.sources.r1.bind
=localhost
a1.sources.r1.
port
=44444
# 描述并配置sinks组件（采集后的数据流出的类型）
a1.sinks.k1.type
=logger
# 描述并配置channels（缓存类型、内存缓存大小和事务缓存大小）
a1.channels.c1.type
=memory
a1.channels.c1.capacity
=1000
a1.channels.c1.transactionCapacity
=100
# 将source和sink通过同
一
个channel连接绑定
a1.sources.r1.channels
=
c1
a1.sinks.k1.channel=
c1Python API上传文件到HDFS
还有
一
个不知道是啥？
import pyhdfs
# 文件上传
def upload_file_to_hdfs(client,path_local,path_hdfs):
try:
client.copy_from_local(path_local,path_hdfs)
print(
"
success
"
)
except IOError:
print(
"
Error：查找文件或读取文件失败
"
)
else:
print(
"
writer success
"
)
Zookeeper选举机制的类型
Zookeeper选举机制有两种类型，分别为全新集群选举和非全新集群选举，下面分别对两种类型进行详细讲解
1、全新集群选举（考试重点）
全新集群选举是新搭建起来的，没有数据ID和逻辑时钟来影响集群的选举。假设，目前有5台服务器，他们的
编号分别是1
~
5，按编号依次启动Zookeeper服务。下面来讲解全新集群选举的过程。
步骤1：
服务器1启动，首先，会给自己投票；其次，发投票信息，由于其他机器还没有启动所以它无法接收到投票反馈信
息，因此服务器1的状态
一
直属于LOOKING状态。
步骤2：
服务器2启动，首先，会给自己投票；其次，在集群中启动Zookeeper服务的机器发起投票对比，这时它会与服务器
1交换结果，由于服务器2的编号大，所以服务器2胜出，此时服务器1会将票投给服务器2，但此时服务器2的投票数
并没有大于集群半数（2 < 5/2)，所以两个服务器的状态依然是LOOKING状态。
步骤3：
服务器3启动，首先，会给自己投票；其次，与之前启动的服务器1和服务器2交换信息，由于服务器3的编号最大，
所以服务器3胜出，那么服务器1和2会将票投给服务器3，此时投票数正好大于半数（3 > 5/2），所以服务器3成为
领导者状态，服务器1和2成为追随者状态。
步骤4：
服务器4启动，首先，会给自己投票；其次，与之前启动的服务器1、2和3交换信息，尽管服务器4的编号大，但是
服务器3已经胜出。所以服务器4只能成为追随者状态。
步骤5：
服务器5启动，同服务器4
一
样，均成为追随者状态。
2、非全新集群选举
对于正常运行的Zookeeper集群，
一
旦中途有服务器宕机，则需要重新选举时，选举的过程中就需要引人服务
器ID、数据ID和逻辑时钟。这是由于Zookeeper集群已经运行过
一
段时间，那么服务器中就会存在运行的数
据。下面来讲解非全新集群选举的过程
步骤1：
首先，统计逻辑时钟是否相同，逻辑时钟小，这说明途中可能存在宕机问题，因此数据不完整，那么该选举结果被
忽略，重新投票选举；
步骤2：
其次，统
一
逻辑时钟后，对比数据ID值，数据ID反映数据的新旧程度，因此数据ID大的胜出；步骤3：
如果逻辑时钟和数据ID都相同的情况下，那么比较服务器ID（编号），值大则胜出；
简单地讲，非全新集群选举时是优中选优，保证Leader是Zookeeper集群中数据最完整，最可靠的
一
台服务器
写出五个组件
Hadoop（也可以写HDFS、Mapreduce、Yarn。这里就包含了三点）
Hive
Flume
Sqoop
Hbase
Spark
Fink
ZooKeeper
Flume运行机制（8分）
Flume的核心是把数据从数据源（如Web Server） 通过数据采集器（Source）收集过来，再将收集的数据通过缓冲
通道（Channel）汇集到指定的接收器（Sink）。这里可以参考官方的架构图，具体展示Flume运行机制，如图
从图中可以看出，Flume基本架构中有
一
个Agent（代理），它是Flume的核心角色，Flume Agent是
一
个JVM进
程，它承载着数据从外部源流向下
一
个目标的3个核心组件；Source、Channel和Sink。对着3个重要组件进行说
明，具体如下：
Source（数据采集器）：用于源数据的采集（如图，从
一
个Web服务器采集源数据），然后将采集到的数据写入
到Channel中并流向Sink；
Channel（缓冲通道）：底层是
一
个缓冲队列，对Source中的数据进行缓存，将数据高效、准确地写入Sink，待数
据全部到达Sink后，Flume就会删除该缓存通道中的数据；
Sink（接收器）：接收并汇集流向Sink的所有数据，根据需求，可以直接进行集中式存储（如图，采用HDFS进
行存储），也可以作为数据源传入其他远程服务器或者Source中。在整个数据传输的过程中，Flume将 流动的数据封装到
一
个event（事件）中，它是Flume内部数据传输的基本
单元。
一
个完整的event包含headers和body，其中headers包含了
一
些标识信息，而body中就是Flume收集到的数
据信息。
Flume配置采集方案（12分）
因为Flume要采集数据的类型和源头多种多样，并且根据开发需求还要进行不同类型的数据传输和汇总。为此，
根据实际业务需求，Flume专门设计了匹配不同数据类型和传输要求的Flume Source、Flume Channel和Flume Sink。
为了正确地使用Flume对数据进行采集，就必须编写适合开发者需求的Flume采集方案，接下来就编写
一
个采集
netcat（用于TCP/UDP连接和监听的Linux工具，主要用于网络传输及调试领域）源数据的采集方案，如下：
接下来，先对文件编写的采集方案进行说明，具体如下：
1. 采集方案的名称可以自定义，但为了方便管理和使用，通常会根据数据源类型和收集的结果类型进行命名。如
netcat
-
logger.conf表示采集netcat类型数据源并最终作为logger日志信息收集
2. 采集方案文件的位置可以自定义存放、在使用的时候会要求指定配置方案的具体位置，为了更方便统
一
管理，通
常会将采集方案统
一
存放。在本案例中，会将所有自定义的采集方案文件保存在/export/servers/flume/conf目录
下。
3. 采集方案中的sources、channels、sinks是在具体编写时根据业务需求进行配置的，不能随意定义。Flume支持采
集的数据类型可以通过查看官网详细了解（地址http://flume.apache.org/FlumeUserGuide.html),同时针对不同的
sources type、channels type和sinks type需要编写不同的配置属性。
# 实例配置方案：单节点Flume配置
# 定义Agent中各个组件名称
# 其中该Agent名为 a1,source名为r1,sinks名为k1,channels名为c1
a1.sources
=r1
a1.sinks
=k1
a1.channels
=
c1
# 描述并配置sources组件（数据源类型，采集数据源的应用地址）
a1.sources.r1.type
=netcat
a1.sources.r1.bind
=localhost
a1.sources.r1.
port
=44444
# 描述并配置sinks组件（采集后的数据流出的类型）
a1.sinks.k1.type
=logger
# 描述并配置channels（缓存类型、内存缓存大小和事务缓存大小）
a1.channels.c1.type
=memory
a1.channels.c1.capacity
=1000
a1.channels.c1.transactionCapacity
=100
# 将source和sink通过同
一
个channel连接绑定
a1.sources.r1.channels
=
c1
a1.sinks.k1.channel=
c1Python API上传文件到HDFS
还有
一
个不知道是啥？
import pyhdfs
# 文件上传
def upload_file_to_hdfs(client,path_local,path_hdfs):
try:
client.copy_from_local(path_local,path_hdfs)
print(
"
success
"
)
except IOError:
print(
"
Error：查找文件或读取文件失败
"
)
else:
print(
"
writer success
"
)
