大数据整理

Combiner 将有相同key的 key/value 对加起来，减少溢写spill到磁盘的数据量。Combiner的适用场景：由于Combiner的输出是Reducer的输入，Combiner绝不能改变最终的计算结果。故大多数情况下，combiner适用于输入输出的key/value类型完全一致，且不影响最终结果的场景（比如累加、最大值等……）。

Merge
map 很大时，每次溢写会产生一个 spill_file，这样会有多个 spill_file，而最终的输出只有一个文件，在最终输出之前会对多个中间过程多次产生的溢写文件 spill_file 进行合并，此过程就是 merge。

merge 就是把相同 key 的结果加起来。（当然，如果设置过combiner，也会使用combiner来合并相同的key）

Reduce Shuffle

reduce shuffle

在 reduce task 之前，不断拉取当前 job 里每个 maptask 的最终结果，然后对从不同地方拉取过来的数据不断地做 merge ，也最终形成一个文件作为 reduce task 的输入文件。

copy
Reduce进程启动一些数据copy线程(Fetcher)，通过HTTP方式请求map task所在的TaskTracker获取map task的输出文件。因为maptask早已结束，这些文件就归TaskTracker管理在本地磁盘中。
merge
Copy 过来的数据会先放入内存缓冲区中，这里的缓冲区大小要比 map 端的更为灵活，它基于 JVM 的 heap size 设置，因为 Shuffle 阶段 Reducer 不运行，所以应该把绝大部分的内存都给 Shuffle 用。这里需要强调的是，merge 有三种形式：1)内存到内存 2)内存到磁盘 3)磁盘到磁盘。默认情况下第一种形式不启用，让人比较困惑，是吧。当内存中的数据量到达一定阈值，就启动内存到磁盘的 merge 。与 map 端类似，这也是溢写的过程，这个过程中如果你设置有Combiner，也是会启用的，然后在磁盘中生成了众多的溢写文件。第二种merge方式一直在运行，直到没有 map 端的数据时才结束，然后启动第三种磁盘到磁盘的 merge 方式生成最终的那个文件。
reducer的输入
merge 的最后会生成一个文件，大多数情况下存在于磁盘中，但是需要将其放入内存中。当reducer 输入文件已定，整个 Shuffle 阶段才算结束。然后就是 Reducer 执行，把结果放到 HDFS 上。

Shuffle的调优：https://blog.csdn.net/u014374284/article/details/49205885

一个通用的原则是给shuffle过程分配尽可能大的内存。
Hadoop默认使用4KB作为缓冲，这个算是很小的，可以通过io.file.buffer.size来调高缓冲池大小。
在map端，避免写入多个spill文件可能达到最好的性能，一个spill文件是最好的。通过估计map的输出大小，设置合理的mapreduce.task.io.sort.*属性，使得spill文件数量最小。
在reduce端，如果能够让所有数据都保存在内存中，可以达到最佳的性能。通常情况下，内存都保留给reduce函数，但是如果reduce函数对内存需求不是很高，将mapreduce.reduce.merge.inmem.threshold（触发合并的map输出文件数）设为0，mapreduce.reduce.input.buffer.percent（用于保存map输出文件的堆内存比例）设为1.0，可以达到很好的性能提升。

1.4 YARN架构组成

参考资料：https://blog.csdn.net/liuxinghao/article/details/74939382

YARN是主/从架构，YARN主要的组件包括ResourceManager、NodeManager、ApplicationMaster和Container。

ResourceManager负责整个集群的资源管理和分配，包括处理客户端请求、启动和监控ApplicationMaster、监控NodeManager、资源的分配和调度。由两个主要组件组成：Scheduler和ApplicationsManager。Scheduler是一个单纯的调度器，ApplicationsManager负责监控功能或跟踪应用程序状态。

NodeManager负责每台机器中容器代理、资源监控（cpu，内存，磁盘，网络），并将这些情况报告给ResourceManager。

每个应用程序都会有一个ApplicationMaster，协调来自ResourceManager的资源。并通过NodeManager监控容器和资源使用（包括内存、CPU等）

Container是一个动态资源分配单位，将诸如内存、cpu、磁盘、网络等资源封装在一起，从而限定每个任务使用的资源量。

工作流程：

Client向向ResourceManager提交应用程序。
ResourceManager为该应用程序分配第一个Container，并与对应NodeManager通信，要求它在这个Container中启动应用程序的ApplicationMaster。
ApplicationMaster向ResourceManager注册自己。
ApplicationMaster向ResourceManager申请资源。
申请资源成功后，由ApplicationMaster进行初始化，然后与NodeManager通信。
Container向ApplicationMaster汇报自己的进度和状态信息，以便ApplicationMaster掌握任务运行状态。
应用运行结束后，ApplicationMaster向ResourceManager注销自己，允许其所属的Container回收。

1.5 Hadoop2有哪些改进？

参考资料：https://blog.csdn.net/u012050154/article/details/52353545

1）提出HDFS Federation（联邦），它让多个NameNode分管不同的目录进而实现访问隔离和横向扩展，同时彻底解决了NameNode单点故障问题。

2）使用Yarn框架, 将JobTracker中的资源管理和作业控制分开，分别由ResourceManager（负责所有应用程序的资源分配）和ApplicationMaster（负责管理一个应用程序）实现。减小了JobTracker的负载，同时Yarn是一个通用的资源管理框架，比如Flink也可以跑在Yarn中。

1.6 Mapreduce的容错性是怎样实现的？

三种错误：节点失效，通信异常，数据损失。

TaskTracker 周期性的向 JobTracker 汇报心跳，如果一定的时间内没有汇报这个心跳，JobTracker 就认为该TaskTracker 挂掉了，它就会把上面所有任务调度到其它TaskTracker（节点）上运行。
1.0JobTracker 存在单点故障，在2.0里面这个问题已经得到了解决。
MapTask和ReduceTask 也可能运行挂掉。TaskTracker 就会把每个MapTask和ReduceTask的运行状态回报给JobTracker，JobTracker 一旦发现某个Task挂掉了，它就会通过调度器把该Task调度到其它节点上。

参考资料：漫画Hadoop：https://www.jianshu.com/p/a0f170436cbe

1.7 实操性测试

1）你是怎么将一条数据上传到HDFS中，如何从HDFS中下载数据呢？

hadoop fs -put input /hbase

hadoop fs -cat /hbase/output/part-r-00000

2）怎么打包？

jar -cvf wordcount.jar classes

3）一个简单的Mapreduce程序由哪些部分组成？

一个Mapper，一个Reducer和一个Main。

1.8 写数据的时候Datanode怎么知道将数据写到哪？

此后client端和NameNode分配的多个DataNode构成pipeline管道，client端向输出流对象中写数据。client每向第一个DataNode写入一个packet，这个packet便会直接在pipeline里传给第二个、第三个…DataNode。

1.9 你知道数据倾斜吗？如何避免数据倾斜？

参考资料：https://www.cnblogs.com/dummyly/p/10099924.html

就是大量的相同key被partition分配到一个分区里，map /reduce程序执行时，reduce节点大部分执行完毕，但是有一个或者几个reduce节点运行很慢，导致整个程序的处理时间很长，这是因为某一个key的条数比其他key多很多（有时是百倍或者千倍之多），这条key所在的reduce节点所处理的数据量比其他节点就大很多，从而导致某几个节点迟迟运行不完。

1.增加jvm内存。

2.增加reduce的个数。

3.重新设计key,有一种方案是在map阶段时给key加上一个随机数。

4.使用combinner合并。

2.Elasticsearch

2.0 良心总结

1）7个经典面试题：https://mp.weixin.qq.com/s/iay2B4XGl5MuEqRBWqoipA

2）不会跪搓衣板系列：https://mp.weixin.qq.com/s/y8DNnj4fjiS3Gqz2DFik8w

2.1Lucene简介和索引原理

参考资料：https://blog.csdn.net/lfdns/article/details/78799238

一个索引文件结构：词典、倒排表、正向文件、列式存储DocValues。

è¿éåå¾çæè¿°

2.1.1 Lucene现在采用的数据结构为FST，它的特点就是：

　　1）词查找复杂度为O(len(str))

　　2）共享前缀、节省空间

　　3）内存存放前缀索引、磁盘存放后缀词块

2.1.2 构建FST：

Lucene会将解析出来的文档单词预先排序。
构建一颗词典树，同时构建两个链表，tip表用来存放共享前缀。tim表用来存放后缀。当所有的前缀都读取完毕时，我们将该前缀写入tip表，然后记录其后缀在tim表中的位置，同时将后缀存储在tim表中。

2.1.3 Lucene检索过程:

1）内存加载tip文件，通过FST匹配前缀找到后缀词块位置。

　2）根据词块位置，读取磁盘中tim文件中后缀块并找到后缀和相应的倒排表位置信息。

3）根据倒排表位置去doc文件中加载倒排表。

2. 2 Elasticsearch的优化策略

参考资料：https://blog.51cto.com/13527416/2132270

1）索引效率优化：批量提交，优化硬件，增加 Refresh 时间间隔，减少副本数量。

2）查询效率优化：带 routing 查询，Filter VS Query，避免大翻页的出现。

3）JVM 配置优化：不要超过32G，50％的可用内存作为 Elasticsearch 的堆内存。同时最大堆和最小堆内存值要相等。

2.3 Elasticsearch的写流程？

数据写入流程：https://blog.csdn.net/laoyang360/article/details/84727820

步骤1：新document首先写入内存Buffer缓存中。

步骤2：每隔一段时间，执行“commitpoint”操作，buffer写入新Segment中。

步骤3：新segment写入文件系统缓存 filesystem cache。

步骤4：文件系统缓存中的index segment被fsync强制刷到磁盘上，确保物理写入。

此时，新segment被打开供search操作。

步骤5：清空内存buffer，可以接收新的文档写入。

es写入数据过程：https://mp.weixin.qq.com/s/OmreAfTLsCmxjeiEqyJP7w

客户端选择一个 node 发送请求过去，这个 node 就是 coordinating node（协调节点）。
coordinating node 对 document 进行路由，将请求转发给对应的 node（有 primary shard）。
实际的 node 上的 primary shard 处理请求，然后将数据同步到 replica node。
coordinating node 如果发现 primary node 和所有 replica node 都搞定之后，就返回响应结果给客户端。

2.4 Elasticsearch的读流程？

参考资料：https://mp.weixin.qq.com/s/OmreAfTLsCmxjeiEqyJP7w

es 读数据过程

可以通过 doc id 来查询，会根据 doc id 进行 hash，判断出来当时把 doc id 分配到了哪个 shard 上面去，从那个 shard 去查询。

客户端发送请求到任意一个 node，成为 coordinate node。
coordinate node 对 doc id 进行哈希路由，将请求转发到对应的 node，此时会使用 round-robin随机轮询算法，在 primary shard 以及其所有 replica 中随机选择一个，让读请求负载均衡。
接收请求的 node 返回 document 给 coordinate node。
coordinate node 返回 document 给客户端。

es 搜索数据过程

es 最强大的是做全文检索，就是比如你有三条数据：

java真好玩儿啊java好难学啊j2ee特别牛

你根据 java 关键词来搜索，将包含 java的 document 给搜索出来。es 就会给你返回：java真好玩儿啊，java好难学啊。

客户端发送请求到一个 coordinate node。
协调节点将搜索请求转发到所有的 shard 对应的 primary shard 或 replica shard，都可以。
query phase：每个 shard 将自己的搜索结果（其实就是一些 doc id）返回给协调节点，由协调节点进行数据的合并、排序、分页等操作，产出最终结果。
fetch phase：接着由协调节点根据 doc id 去各个节点上拉取实际的 document 数据，最终返回给客户端。

2.5.脑裂现象是啥？产生脑裂的原因有哪些？如何避免？

参考资料：https://segmentfault.com/a/1190000004504225

脑裂是指集群中出现多个master,导致数据不一致的现象。产生脑裂的原因有网络通信故障，节点负载，内存回收。

选举触发：config目录中的elasticsearch.yml中更改一个参数就是 discovery.zen.minimum_master_nodes一个基本的原则是这里需要设置成 N/2+1。

调大响应时间：我们可以调的另一个参数是 discovery.zen.ping.timeout，它的默认值是3秒并且它用来决定一个节点在假设集群中的另一个节点响应失败的情况时等待多久。

角色分离：防止主节点的假死发生。

2.6.translog 日志文件的作用是什么？

参考资料：https://mp.weixin.qq.com/s/OmreAfTLsCmxjeiEqyJP7w

你执行 commit 操作之前，数据要么是停留在 buffer 中，要么是停留在 os cache 中无论是 buffer 还是 os cache 都是内存，一旦这台机器死了，内存中的数据就全丢了。所以需要将数据对应的操作写入一个专门的日志文件 translog 中一旦此时机器宕机，再次重启的时候，es 会自动读取 translog 日志文件中的数据，恢复到内存 buffer 和 os cache 中去。

总结：

1）三阶段，第一阶段会写入内存buffer，然后将数据写入translog os cache和segment file os cache，最后再写入磁盘，写入磁盘有两种方式，一种是fsync生成segement file,另一种是每隔5s写到translog中。

2）三个时间，每隔1s将内存中的数据刷到os cache中，每隔5s将translog os cache数据刷到translog文件中。每隔30分钟translog强制刷盘，生成一个新的translog文件。

2.7.如何理解Elasticsearch是近实时搜索的？

为了提高索引性能，Elasticsearch 在写入数据时候，采用延迟写入的策略，即数据先写到内存中，当超过默认 1 秒（index.refresh_interval）会进行一次refresh操作，就是将内存中 segment 数据刷新到操作系统中，数据写入 segment file 之后，同时就建立好了倒排索引，此时我们才能将数据搜索出来，所以这就是为什么 Elasticsearch 提供的是近实时搜索功能，这样避免了比较损耗性能io操作。

3.Flink

3.0 良心总结

1）宇宙至强学习资料：https://mp.weixin.qq.com/s/13w43iYT3-riIj757HPGxw

2）Flink深度灵魂200问：https://mp.weixin.qq.com/s/ok-YwuVbwAVtJz7hUCiZxg

3）Flink面试灵魂40问：https://mp.weixin.qq.com/s/n5TBjZ2Lf6kxTh2m7-r01g

3.1 Checkpoint的作用？

参考资料：https://mp.weixin.qq.com/s/ZbDzxDgd9phmNIVhNhXImw

CheckPoint是通过给程序快照的方式使得将历史某些时刻的状态保存下来，当任务挂掉之后，默认从最近一次保存的完整快照处进行恢复任务。barrier从Source Task处生成，一直流到Sink Task，期间所有的Task只要碰到barrier，就会触发自身进行快照，也会暂停处理数据，barrier n 处做的快照就是指从Job开始到处理到 barrier n所有的状态数据，也就是保证之前的状态是正确的。

#执行过程

1、JobManager端的 CheckPointCoordinator向所有SourceTask发送CheckPointTrigger，Source Task会在数据流中安插CheckPoint barrier

2、当task收到所有的barrier后，向自己的下游继续传递barrier，然后自身执行快照，并将自己的状态异步写入到持久化存储中

增量CheckPoint只是把最新的一部分更新写入到外部存储为了下游尽快做CheckPoint，所以会先发送barrier到下游，自身再同步进行快照。

3、当task完成备份后，会将备份数据的地址（state handle）通知给JobManager的CheckPointCoordinator如果CheckPoint的持续时长超过了CheckPoint设定的超时时间，CheckPointCoordinator 还没有收集完所有的 State Handle，CheckPointCoordinator就会认为本次CheckPoint失败，会把这次CheckPoint产生的所有状态数据全部删除。

4、最后 CheckPoint Coordinator 会把整个 StateHandle 封装成 completed CheckPoint Meta，写入到hdfs。

3.2 怎么理解Barrier对齐就实现了exactly once?

参考资料：https://mp.weixin.qq.com/s/ZbDzxDgd9phmNIVhNhXImw

Barrier从Source Task处生成，一直流到Sink Task，期间所有的Task只要碰到barrier，就会触发自身进行快照,保存到相应状态后端。Barrier对齐指的就是不同的流在收到Barrier时，不会继续对流进行处理，而是先将其放到输入缓存当中，当所有这个Barrier相关的流被处理后同时进行处理。Operator实例必须有多个输入流才会出现barrier对齐。

一旦Operator从输入流接收到CheckPoint barrier n，它就不能处理来自该流的任何数据记录，直到它从其他所有输入接收到barrier n为止。否则，它会混合属于快照n的记录和属于快照n + 1的记录
接收到barrier n的流暂时被搁置。从这些流接收的记录不会被处理，而是放入输入缓冲区。
上图中第2个图，虽然数字流对应的barrier已经到达了，但是barrier之后的1、2、3这些数据只能放到buffer中，等待字母流的barrier到达
一旦最后所有输入流都接收到barrier n，Operator就会把缓冲区中pending 的输出数据发出去，然后把CheckPoint barrier n接着往下游发送
这里还会对自身进行快照
之后，Operator将继续处理来自所有输入流的记录，在处理来自流的记录之前先处理来自输入缓冲区的记录。

barrier不对齐就是指当还有其他流的barrier还没到达时，为了不影响性能，也不用理会，直接处理barrier之后的数据。CheckPoint的目的就是为了保存快照，如果不对齐，那么在chk-100快照之前，已经处理了一些chk-100 对应的offset之后的数据，当程序从chk-100恢复任务时，chk-100对应的offset之后的数据还会被处理一次，所以就出现了重复消费。

3.3 Flink的窗口机制是什么？

参考资料：https://mp.weixin.qq.com/s/OJnLsU0eHQtD_ZHohQy1ew

窗口机制是为了处理流数据的无界性，窗口的本质就是一定量数据的集合，窗口就是对某一段数据进行触发，窗口大小是数据的缓存长度，过老的数据会被丢弃。window可以分为两类，一种叫做countwindow，另一种叫做timewindow。

3.4 Watermark是啥？

参考资料：https://www.jianshu.com/p/2e87abfe89ff

watermark本质上相当于是一个延迟触发机制, 延迟的目的是为了等待可能还有更早的数据的到来，watermark是用来处理乱序事件的，而正确的处理乱序事件，通常用watermark结合window来实现。

3.5 简单讲一下Flink的基本原理？

Flink是一个同时支持批处理和流处理的大数据框架，它能保证精确一致性，又能有不错的性能。

Flink的基本架构，包含两种类型的处理器，JobManager与TaskManager。本质上是两个JVM的进程，JobManager相当于Master,负责资源申请和任务分发,TaskManager相当于Executor，主要负责任务的执行。Taskmanager需要通过注册的方式在Jobmanager中进行注册。

下面可以简单讲一下Flink的任务调度原理。每一个Flink程序会被抽象为一个数据流图，Client会通过Actor System将抽象好的流图发送给Jobmanager，通过检测数据流图算子之间的分区是否有变化来划分task，然后将task分发给不同的slot，程序的执行过程就是流通过不同的算子进行转换。

算子可以分为3类，一类是source operator用来获取资源，Transformation operator用来进行流的转换，sink operator用来进行结果输出。

Slot就是将JVM内存进行等分，只分配内存，不划分CPU。slot数是支持的最大并行度，并行度参数决定最终的并行情况。

3.6 stream在operator之间的传输形式有哪些？

1）one-to-one：维护操作前后分区的个数以及元素的顺序。

2) redistribute：原来在同一分区的数据被分到不同的分区当中，数据被打散了。

3）对于两个算子之间属于one2one的关系时，可以将其组合在一起，放到一个task之间进行执行。只有对于会引起redistribute的算子才将其放到不同的task中进行执行。

3.7 Flink创建执行环境的方式有哪些？

1）getExecutionEnviroment,会查询运行的方式决定返回什么样的运行环境。

2) createLocalEnviroment，创建一个本地的执行环境。

3）createRemoteEnviroment，创建一个远端的执行环境。

3.8 Flink创建数据源有哪几种方式？

1）readTextFile(path),一列一列读取文本文件，并将结果作为String返回

2）readFile(fileInputFormat,path)

3）基于集合的数据源

4）基于socket的数据源

5）可以从kafka获取数据

3.9 Flink的Sink方式有哪些？

1）writeAsText

2) writeAsCsv

3) print/printToErr，直接将结果打印出来

4）writeUsingOutFormat(自定义对象到字节的转换）

5）writeToSocket,以socket的形式发送。

3.10 Flink常见的算子有哪些？

1）Map，为每一条数据返回一个对象。

2) FlatMap，将每条数据的结果统计后，只返回一个对象。

3) Filter，按指定条件过滤掉。

4) Connect + CoMap/CoFlatmap。

5) Split + Select，将流按条件分割后，可以进行选择。

6）Union，将两个流合并为一个流。

7）KeyBy,将具有相同关键字的聚合在一起，放到同一个分区里面。

8）Reduce,进行聚合操作，需要先加窗口才可以。

9) Fold

10) Aggregation

3.11 你知道Spark吗？

参考资料：https://www.infoq.cn/article/spark-vs-flink

Spark也是常见的一种流数据处理框架，但是我们项目中选择的是Flink作为解决方案，所以了解的不是很深入。目前一线的互联网公司都在基于Flink搭建实时处理引擎，这里我可以简单对比一下Spark和Flink。首先Spark和Flink都同时支持流处理和批处理，但是原理是不一样的，Spark是通过Spark Streaming和Spark Pool+SQL两套技术体系分别实现了流处理和批处理。而Flink将批处理和流处理统一成流处理，然后通过DataStream API和DataSet API两个API来进行调用。其次两个的数据模型是不一样的，Spark 的数据模型是弹性分布式数据集 RDD。Spark 用 RDD 上的变换（算子）来描述数据处理。每个算子（如 map，filter，join）生成一个新的 RDD。所有的算子组成一个有向无环图（DAG）。Flink 的基本数据模型是数据流，及事件（Event）的序列。Flink 用数据流上的变换（算子）来描述数据处理。每个算子生成一个新的数据流。最后，在 DAG 的执行上，Spark 和 Flink 有一个比较显著的区别。在 Flink 的流执行模式中，一个事件在一个节点处理完后的输出就可以发到下一个节点立即处理。这样执行引擎并不会引入额外的延迟。此外Flink提供丰富的窗口函数和状态支持，这也是当时让我们决定使用Flink的重要原因。

为啥我对这个比较了解，因为当时在做技术选型的时候有去对比研究过。

4. Kafka

4.0 良心总结

1）32道常见面试题：https://mp.weixin.qq.com/s/nc3vAYjoDmLxg-aPq1HHxw

4.1 Kafka的基本原理？

参考资料：https://www.cnblogs.com/luxiaoxun/p/5492646.html

Apache Kafka是分布式发布-订阅消息系统。Kafka是一种快速、可扩展的、设计内在就是分布式的，分区的和可复制的提交日志服务。

它的架构包括以下组件：

话题（Topic）：是特定类型的消息流。消息是字节的有效负载（Payload），话题是消息的分类名或种子（Feed）名。

生产者（Producer）：是能够发布消息到话题的任何对象。

服务代理（Broker）：已发布的消息保存在一组服务器中，它们被称为代理（Broker）或Kafka集群。Kafka broker是无状态的。这意味着消费者必须维护已消费的状态信息。

消费者（Consumer）：可以订阅一个或多个话题，并从Broker拉数据，从而消费这些已发布的消息。

4.2 Kafka存储策略

参考资料：https://www.cnblogs.com/luxiaoxun/p/5492646.html

1）kafka以topic来进行消息管理，每个topic包含多个partition，每个partition对应一个逻辑log，有多个segment组成。

2）每个segment中存储多条消息（见下图），消息id由其逻辑位置决定，即从消息id可直接定位到消息的存储位置，避免id到位置的额外映射。

3）每个part在内存中对应一个index，记录每个segment中的第一条消息偏移。

4）发布者发到某个topic的消息会被均匀的分布到多个partition上（或根据用户指定的路由规则进行分布），broker收到发布消息往对应partition的最后一个segment上添加该消息，当某个segment上的消息条数达到配置值或消息发布时间超过阈值时，segment上的消息会被flush到磁盘，只有flush到磁盘上的消息订阅者才能订阅到，segment达到一定的大小后将不会再往该segment写数据，broker会创建新的segment。

4.3 消息传输的三种策略

参考资料：https://www.cnblogs.com/luxiaoxun/p/5492646.html

At most once—Messages may be lost but are never redelivered.

At least once—Messages are never lost but may be redelivered.

Exactly once—this is what people actually want, each message is delivered once and only once.

Producer：有个”acks“配置可以控制接收的leader的在什么情况下就回应producer消息写入成功。

读取消息，处理消息，写log。如果消息处理成功，写log失败，则消息会被处理两次，对应”At least once“。Kafka默认保证at-least-once delivery。

4.4 Kafa的消息格式

参考资料：https://blog.csdn.net/u013256816/article/details/80300225

4.5 Rebalance机制

参考资料：点击

触发分配的条件：有成员离开组，通过心跳检测失效就会进入到PreparingRebalance状态，当从Group Leader中接收到分配方案后就开始进行重新分配，然后进入stable状态。新版本新增了group.initial.rebalance.delay.ms参数。空消费组接受到成员加入请求时，不立即转化到PreparingRebalance状态来开启reblance。实现机制是在coordinator底层新增一个group状态。

4.6 broker的消息存储

Kafka的消息以二进制的方式紧凑地存储，节省了很大空间此外消息存在ByteBuffer而不是堆，这样broker进程挂掉时，数据不会丢失，同时避免了gc问题通过零拷贝和顺序寻址，让消息存储和读取速度都非常快处理fetch请求的时候通过zero-copy 加快速度

4.7broker状态数据

Controller所在的broker ID，集群中所有broker的信息，集群中所有分区的信息，所谓分区信息指的是分区的leader、ISR和AR信息以及当前处于offline状态的副本集合。

4.8 broker负载均衡

将所有Broker（假设共n个Broker）和待分配的Partition排序将第i个Partition分配到第（i mod n）个Broker上将第i个Partition的第j个Replica分配到第（(i + j) mod n）个Broker上。

4.9 Kafka高可用

参考资料：https://blog.csdn.net/qq_37502106/article/details/80271800

leader会维护一个与其基本保持同步的Replica列表，该列表称为ISR(in-sync Replica)，每个Partition都会有一个ISR，而且是由leader动态维护。kafka不是完全同步，也不是完全异步，是一种ISR机制：
1. leader会维护一个与其基本保持同步的Replica列表，该列表称为ISR(in-sync Replica)，每个Partition都会有一个ISR，而且是由leader动态维护
2. 如果一个flower比一个leader落后太多，或者超过一定时间未发起数据复制请求，则leader将其重ISR中移除
3. 当ISR中所有Replica都向Leader发送ACK时，leader才commit

4.10 Kafka的副本复制

参考资料：https://www.iteblog.com/archives/2556.html

Kafka 主题中的每个分区都有一个预写日志（write-ahead log），我们写入 Kafka 的消息就存储在这里面。这里面的每条消息都有一个唯一的偏移量，用于标识它在当前分区日志中的位置。

Kafka 的复制是以分区为粒度的，分区的预写日志被复制到 n 个服务器。在 n 个副本中，一个副本作为 leader，其他副本成为 followers。顾名思义，producer 只能往 leader 分区上写数据（读也只能从 leader 分区上进行），followers 只按顺序从 leader 上复制日志。

每个分区的 leader 会维护一个 in-sync replica（同步副本列表，又称 ISR）。当 producer 往 broker 发送消息，消息先写入到对应 leader 分区上，然后复制到这个分区的所有副本中。只有将消息成功复制到所有同步副本（ISR）后，这条消息才算被提交。

4.11 kafka怎么实现数据不丢失

参考资料：https://blog.csdn.net/qq_41455420/article/details/79372696

1.生产者数据的不丢失

kafka的ack机制：在kafka发送数据的时候，每次发送消息都会有一个确认反馈机制，确保消息正常的能够被收到。

2.消费者数据的不丢失

通过offset commit 来保证数据的不丢失，kafka自己记录了每次消费的offset数值，下次继续消费的时候，接着上次的offset进行消费即可。

4.12 如何理解Kafka的中的topic?

参考资料：https://blog.csdn.net/Dongguabai/article/details/86536894

Kafka 中，Topic 是一个存储消息的逻辑概念，可以认为是一个消息集合。每条消息发送到 Kafka 集群的消息都有一个类别。物理上来说，不同的 Topic 的消息是分开存储的，每个 Topic 可以有多个生产者向它发送消息，也可以有多个消费者去消费其中的消息。

5. Spark

参考良心总结资料：https://cloud.tencent.com/developer/article/1434860

Jeff_Scott

关注

0
点赞
踩
2

收藏

觉得还不错? 一键收藏
0
评论
大数据整理

Table of Contents0.良心总结1.Hadoop1.0 良心总结1.1 HDFS读写流程1.2 Mapreduced架构及通信1.3 Shuffle过程1.4 YARN架构组成1.5 Hadoop2有哪些改进？1.6 Mapreduce的容错性是怎样实现的？1.7 实操性测试1.8 写数据的时候Datanode怎么知道将数据写到哪？...
复制链接

扫一扫

专栏目录