如何域名解析网站建设,重庆市建立网站的网络公司,四合一做网站,大型医疗网站建设文章目录Kafka 原理#xff0c;数据怎么平分到消费者生产者分区消费者分区Flume HDFS Sink 小文件处理Flink 与 Spark Streaming 的差异#xff0c;具体效果Spark 背压机制具体实现原理Yarn 调度策略Spark Streaming消费方式及区别Zookeeper 怎么避免脑裂#xff0c;什么是脑…
文章目录Kafka 原理数据怎么平分到消费者生产者分区消费者分区Flume HDFS Sink 小文件处理Flink 与 Spark Streaming 的差异具体效果Spark 背压机制具体实现原理Yarn 调度策略Spark Streaming消费方式及区别Zookeeper 怎么避免脑裂什么是脑裂讲一讲什么是 CAP 法则Zookeeper 符合了这个法则的哪两个Kafka 原理数据怎么平分到消费者
这里主要考的是kafka的分区分配策略
生产者分区
若指定分区号则直接发给对应分区若没有分区号则通过key的hashcode对分区数取模若也没有key则采取Sticky策略会随机选择一分区尽可能使用该分区待该分区batch已满或者已提交再随机选择一个分区与当前分区不同。
消费者分区
Kafka的分区分配策略 RoundRobin 针对所有topic的partition的。把消费者组订阅的所有topic的所有partition组成一个topicAndPartition列表按照topicAndPartition的hashcode排序对消费者组的所有消费者线程按照字母顺序排序然后通过轮询将topicAndPartition列表中的每一个分区发给每一个消费者消费。 Range 是kafka默认分区分配策略。针对每一个topic而言的。首先将分区按分区号排序然后将消费者按字母顺序排序单个topic内partition数除以消费者组内的消费者线程数决定每个消费者线程消费几个分区。如果除不尽前几个消费者会多消费一个分区。 Sticky 基础分配方式与RoundRobin一致但是在重分配时Sticky会尽可能保证与原分区策略一致。例如三个消费者中的一个挂了如果是RoundRobin会对所有存活的消费者消费的分区进行重分配如果是Sticky则只将宕机节点分配的分区重分配给存活的消费者。
Flume HDFS Sink 小文件处理
源码中如果滚动中的文件如果被监测到正在进行HDFS的副本复制就会自动产生一个文件不会等到设置的条件触发再产生文件。源码的判断机制是当前正在复制的块序号是否小于配置文件中读取的最小副本数numBlocks desiredBlocks。所以要想将这个触发条件关闭需要使这个不等式恒不成立我们不能修改hadoop的副本数而Flume给我们提供了一个参数minBlockReplicas1我们只需要将这个参数设为1就可以实现需求。
Flink 与 Spark Streaming 的差异具体效果
流和微批时间语义
Spark 背压机制具体实现原理
spark1.5之前如果用户要限制Receiver的接受速率只能通过配置参数spark.streaming.receiver.maxRate实现虽然这样可以控制接受速率防止OOM但也会引入其他问题当数据量小的时候处理速率高于maxRate这样就会导致资源利用率下降。所以从1.5开始spark实现了一个新功能可以通过动态控制接收速率来适配处理速率即背压机制(spark.streaming.backpressure.enabled默认false)根据JobSchedule反馈的执行信息来动态调整Receiver的接收速率。如果数据量稳定或数据量较小则无需开启背压因为背压机制也需要消耗计算资源。
Yarn 调度策略 FIFO调度器 单队列任务会被放入队列中先被获取先执行。 公平调度器 见面分一半。多队列不会预分资源。当单任务提交时若无其他任务运行则独享所有资源。其他队列有任务时与其他队列平分资源。当本队列有任务时与本队列任务平分本队列资源。队列内部也可以设置调度策略公平默认或者FIFO 容量调度器 对资源进行预分设置A队列执行大任务B队列执行小任务。大任务一般占用资源较多A分配80%资源B分配20%资源。各队列使用FIFO调度。要点预分队列预分资源。
Spark Streaming消费方式及区别
Receiver方式 这种方式使用的是Kafka的高阶API被动的接收Kafka的数据。Spark会启动Executor专门负责接收kafka的数据并将接收的数据保存在Executor的内存中当数据量激增时可能会导致Executor节点的OOM从而丢失数据等待计算任务的拉取。这种情况下如果Spark出错很可能导致数据丢失所以Receiver会开启WAL机制在Receiver接收Kafka的数据时会同时将数据写入hdfs的预写日志中。Direct方式 这种方式是Executor主动拉取kafka中的数据。通过周期性访问kafka来获取每个topicpartitoin的最小offset。处理数据的job启动后就会直接从kafka中获取对应offset范围的数据。
区别Receiver是使用Kafka高阶API被动的接收Kafka的数据offset由Kafka维护采用WAL实现可靠性Direct是使用Kafka简单API主动拉取由自己维护的offset范围的数据由Kafka实现可靠性性能更高。另外设置多个Receiver只能增加获取kafka数据的线程对处理RDD的线程没有影响只能通过多个stream进行unio实现。而Direct只需要创建有多个
Zookeeper 怎么避免脑裂什么是脑裂
脑裂是master-slaves结构中某个时刻有两个master对外提供服务。例如有俩个机房一个机房3个zk节点另一个机房2个zk节点集群中只有一个master对外提供读写服务。某个时刻两个机房间的连接断开了每一个机房都选举产生了一个master分别对外提供读写。当两个机房间的连接恢复后集群又合并到一起去此时数据该如何合并数据冲突如何解决等问题出现。这就是脑裂。 zk中避免脑裂的方式是过半选举机制。集群从配置文件中读取到集群总节点数若选举投票时某个节点的票数大于集群总结点数的一半时成功选举了反之继续选举流程。
讲一讲什么是 CAP 法则Zookeeper 符合了这个法则的哪两个
CAP原则又称CAP定理指的是一个分布式系统中一致性可用性分区容错性三者不可兼得。 一致性consistency在分布式系统中的所有数据备份在同一时刻是否同样的值。 可用性Available对任何非失败节点都应该在有限的时间内给出请求的回应。返回结果必须在合理的时间以内这个合理的时间是根据业务来定的如果超过业务规定的返回时间这个系统也就不满足可用性 分区容错性Partition Tolerance分布式系统在遇到某节点或网络分区故障的时候仍然能够对外提供满足一致性和可用性的服务。
当有数据写入一个多节点集群中时如果在节点同步时连接断开那么必然会有节点未同步成功。而此时如果要保证可用性那么各节点间的数据会不一致不满足一致性。而如果满足一致性即停止对外提供服务直到数据同步完成那么就不满足可用性了。所以一致性和可用性通常是不能同时满足的。 事实上作为分布式系统分区容错性是必须的而一致性和可用性是处于对立面的所以分布式系统一般是采用CP或者AP组合。zookeeper采用的是CP主要表现在leader选举时不对外提供服务。
