六阶段面试题01

01.HDFS的写流程

详细步骤解析：

1、 client发起文件上传请求，通过RPC与NameNode建立通讯，NameNode检查目标文件是否已存在，父目录是否存在，返回是否可以上传；
2、 client请求第一个block该传输到哪些DataNode服务器上；

3、 NameNode根据配置文件中指定的备份数量及机架感知原理进行文件分配，返回可用的DataNode的地址如：A，B，C；

注：Hadoop在设计时考虑到数据的安全与高效，数据文件默认在HDFS上存放三份，存储策略为本地一份，同机架内其它某一节点上一份，不同机架的某一节点上一份。

4、 client请求3台DataNode中的一台A上传数据（本质上是一个RPC调用，建立pipeline），A收到请求会继续调用B，然后B调用C，将整个pipeline建立完成，后逐级返回client；

5、 client开始往A上传第一个block（先从磁盘读取数据放到一个本地内存缓存），以packet为单位（默认64K），A收到一个packet就会传给B，B传给C；A每传一个packet会放入一个应答队列等待应答。

6、 数据被分割成一个个packet数据包在pipeline上依次传输，在pipeline反方向上，逐个发送ack（命令正确应答），最终由pipeline中第一个DataNode节点A将pipelineack发送给client;

7、 当一个block传输完成之后，client再次请求NameNode上传第二个block到服务器。

02.Hive的内部组成模块，作用分别是什么

1．元数据：Metastore
元数据包括：表名、表所属的数据库（默认是default）、表的拥有者、列/分区字段、表的类型（是否是外部表）、表的数据所在目录等；
2．默认存储在自带的derby数据库中，推荐使用MySQL存储Metastore 元数据存储
（1）解析器（SQL Parser）：解析HQL语义
（2）编译器（Physical Plan）：将HQL根据语义转换成MR程序
（3）优化器（Query Optimizer）：对逻辑执行计划进行优化。（对MR程序进行优化）
（4）执行器（Execution）：把任务提交到hadoop集群

03.Hbase详细架构

1、HMaster

1. 监控RegionServer
2. 处理RegionServer故障转移
3. 处理元数据的变更
4. 处理region的分配或移除
5. 在空闲时间进行数据的负载均衡
6. 通过Zookeeper发布自己的位置给客户端

2、RegionServer

1. 负责存储HBase的实际数据
2. 处理分配给它的Region
3. 刷新缓存到HDFS
4. 维护HLog
5. 执行压缩
6. 负责处理Region分片

组件：
1) Write-Ahead logs
HBase的修改记录，当对HBase读写数据的时候，数据不是直接写进磁盘，它会在内存中保留一段时间（时间以及数据量阈值可以设定）。但把数据保存在内存中可能有更高的概率引起数据丢失，为了解决这个问题，数据会先写在一个叫做Write-Ahead logfile的文件中，然后再写入内存中。所以在系统出现故障的时候，数据可以通过这个日志文件重建。

2) HFile
这是在磁盘上保存原始数据的实际的物理文件，是实际的存储文件。

3) Store
HFile存储在Store中，一个Store对应HBase表中的一个列族。

4) MemStore
顾名思义，就是内存存储，位于内存中，用来保存当前的数据操作，所以当数据保存在WAL中之后，RegsionServer会在内存中存储键值对。

5) Region
Hbase表的分片，HBase表会根据RowKey值被切分成不同的region存储在RegionServer中，在一个RegionServer中可以有多个不同的region。

04.Kafka的架构

上图中一个topic配置了3个partition。Partition1有两个offset：0和1。Partition2有4个offset。Partition3有1个offset。副本的id和副本所在的机器的id恰好相同。

如果一个topic的副本数为3，那么Kafka将在集群中为每个partition创建3个相同的副本。集群中的每个broker存储一个或多个partition。多个producer和consumer可同时生产和消费数据。

1 broker
Kafka 集群包含一个或多个服务器，服务器节点称为broker。
broker存储topic的数据。如果某topic有N个partition，集群有N个broker，那么每个broker存储该topic的一个partition。
如果某topic有N个partition，集群有(N+M)个broker，那么其中有N个broker存储该topic的一个partition，剩下的M个broker不存储该topic的partition数据。
如果某topic有N个partition，集群中broker数目少于N个，那么一个broker存储该topic的一个或多个partition。在实际生产环境中，尽量避免这种情况的发生，这种情况容易导致Kafka集群数据不均衡。

2 Topic
每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。（物理上不同Topic的消息分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消费数据而不必关心数据存于何处）

3 Partition
topic中的数据分割为一个或多个partition。每个topic至少有一个partition。每个partition中的数据使用多个segment文件存储。partition中的数据是有序的，不同partition间的数据丢失了数据的顺序。如果topic有多个partition，消费数据时就不能保证数据的顺序。在需要严格保证消息的消费顺序的场景下，需要将partition数目设为1。

4 Producer
生产者即数据的发布者，该角色将消息发布到Kafka的topic中。broker接收到生产者发送的消息后，broker将该消息追加到当前用于追加数据的segment文件中。生产者发送的消息，存储到一个partition中，生产者也可以指定数据存储的partition。

5 Consumer
消费者可以从broker中读取数据。消费者可以消费多个topic中的数据。

6 Consumer Group
每个Consumer属于一个特定的Consumer Group（可为每个Consumer指定group name，若不指定group name则属于默认的group）。这是kafka用来实现一个topic消息的广播（发给所有的consumer）和单播（发给任意一个consumer）的手段。一个topic可以有多个CG。topic的消息会复制-给consumer。如果需要实现广播，只要每个consumer有一个独立的CG就可以了。要实现单播只要所有的consumer在同一个CG。用CG还可以将consumer进行自由的分组而不需要多次发送消息到不同的topic。

7 Leader
每个partition有多个副本，其中有且仅有一个作为Leader，Leader是当前负责数据的读写的partition。

8 Follower
Follower跟随Leader，所有写请求都通过Leader路由，数据变更会广播给所有Follower，Follower与Leader保持数据同步。如果Leader失效，则从Follower中选举出一个新的Leader。当Follower与Leader挂掉、卡住或者同步太慢，leader会把这个follower从“in sync replicas”（ISR）列表中删除，重新创建一个Follower。

05.Kafka分区和消费组内的消费者之间的关系有哪些情况？

Partition = 消费任务的并发度=刚刚好，每个任务读取一个partition数据
Partition > 消费任务的并发度=有部分消费任务读取多个分区的数据
Partition < 消费任务的并发度=有部分消费任务空闲(可以创建多于分区的消费者数量)

06.Kafka如何保证数据不丢失

1、生产者如何保证数据不丢失？？ 通过ack 机制确保数据不丢失。
2、kafka集群如何保证数据不丢失？？ 通过数据副本保证数据不丢失。
3、消费者如何保证数据不丢失？？ 通过维护数据的offset 保证数据不丢失。

07.Yarn的调度器有哪些？

1、FIFO Scheduler
FIFO是Hadoop设计之初提供的一个最简单的调度机制： 即先来先服务。所有应用程序被统一提交到一个队里中，Hadoop按照提交顺序依次运行这些作业。只有等先来的应用程序资源满足后，再开始为下一个应用程序进行调度运行和分配资源。

优点：
原理是和实现简单。也不需要任何单独的配置

缺点：
1， 无法提供QoS，只能对所有的任务按照同一优先级处理。
2， 无法适应多租户资源管理。先来的大应用程序把集群资源占满，导致其他用户的程序无法得到及时执行。
3， 应用程序并发运行程度低。

2、Capacity Scheduler
Capacity Scheduler容量调度是Yahoo!开发的多用户调度器它以对了为单位划分资源。每个队列可设定一定比例的资源最低保证和使用上限。每个用户也可设置一定的资源使用上限，以防资源滥用。并支持资源共享，将队列剩余资源共享给其他队列使用。
Capacity Scheduler是开源Hadoop的默认调度器。

3、Fair Scheduler
Fair Scheduler是Facebook开发的多用户调度器。设计目标是为所有的应用分配公平的资源（对公平的定义可以通过参数来设置）。公平不仅可以在队列中的应用体现，也可以在多个队列之间工作。

08.Flink time

Event Time：是事件创建的时间。它通常由事件中的时间戳描述，例如采集的日志数据中，每一条日志都会记录自己的生成时间，Flink 通过时间戳分配器访问事件时间戳。

Ingestion Time：是数据进入Flink 的时间。

Processing Time：是每一个执行基于时间操作的算子的本地系统时间，与机器相关，默认的时间属性就是Processing Time。

09.Flink 窗口

Window 可以分成两类：

1. CountWindow：按照指定的数据条数生成一个Window，与时间无关。
2. TimeWindow：按照时间生成Window。

对于TimeWindow，可以根据窗口实现原理的不同分成三类：滚动窗口（Tumbling Window）、滑动窗口（Sliding Window）和会话窗口（Session Window）。

10.Flink watermark 如何处理乱序数据

Watermark 是一种衡量 Event Time 进展的机制， 它是数据本身的一个隐藏属性， 数据本身携带着对应的 Watermark。

​ Watermark 是用于处理乱序事件的， 而正确的处理乱序事件， 通常用 Watermark 机制结合window 来实现。
​ 数据流中的 Watermark 用于表示 timestamp 小于 Watermark 的数据， 都已经到达了。 因此，window 的执行也是由 Watermark 触发的。
​ Watermark 可以理解成一个延迟触发机制， 我们可以设置 Watermark 的延时时长 t， 每次系统会校验已经到达的数据中最大的 maxEventTime， 然后认定 eventTime 小于 maxEventTime - t的所有数据都已经到达， 如果有窗口的停止时间等于 maxEventTime – t， 那么这个窗口被触发执行。