2021年大数据Spark（四十二）：SparkStreaming的Kafka快速回顾与整合说明

目录

Kafka快速回顾

 消息队列&＃xff1a;

 发布/订阅模式&＃xff1a;

Kafka 重要概念&＃xff1a;

常用命令

整合说明

两种方式

两个版本API

在实际项目中&＃xff0c;无论使用Storm还是SparkStreaming与Flink&＃xff0c;主要从Kafka实时消费数据进行处理分析&＃xff0c;流式数据实时处理技术架构大致如下&＃xff1a;

技术栈&＃xff1a; Flume/SDK/Kafka Producer API  -> KafKa  —>  SparkStreaming/Flink/Storm&＃xff08;Hadoop YARN&＃xff09; -> Redis  -> UI

1&＃xff09;、阿里工具Canal&＃xff1a;监控MySQL数据库binlog文件&＃xff0c;将数据同步发送到Kafka Topic中https://github.com/alibaba/canalhttps://github.com/alibaba/canal/wiki/QuickStart2&＃xff09;、Maxwell&＃xff1a;实时读取MySQL二进制日志binlog&＃xff0c;并生成 JSON 格式的消息&＃xff0c;作为生产者发送给 Kafka&＃xff0c;Kinesis、RabbitMQ、Redis、Google Cloud Pub/Sub、文件或其它平台的应用程序。http://maxwells-daemon.io/https://github.com/zendesk/maxwell

扩展&＃xff1a;Kafka 相关常见面试题&＃xff1a;

1&＃xff09;、Kafka 集群大小&＃xff08;规模&＃xff09;&＃xff0c;Topic分区函数名及集群配置&＃xff1f;2&＃xff09;、Topic中数据如何管理&＃xff1f;数据删除策略是什么&＃xff1f;3&＃xff09;、如何消费Kafka数据&＃xff1f;4&＃xff09;、发送数据Kafka Topic中时&＃xff0c;如何保证数据发送成功&＃xff1f;

Apache Kafka&＃xff1a; 最原始功能【消息队列】&＃xff0c;缓冲数据&＃xff0c;具有发布订阅功能&＃xff08;类似微信公众号&＃xff09;。

Kafka快速回顾

Kafka 是一个分布式的基于发布/订阅模式的消息队列&＃xff08;Message Queue&＃xff09;&＃xff0c;主要应用与大数据实时处理领域。

 消息队列&＃xff1a;

Kafka 本质上是一个 MQ&＃xff08;Message Queue&＃xff09;&＃xff0c;使用消息队列的好处&＃xff1f;&＃xff08;面试会问&＃xff09;

• 解耦&＃xff1a;允许我们独立的扩展或修改队列两边的处理过程&＃xff1b;
• 可恢复性&＃xff1a;即使一个处理消息的进程挂掉&＃xff0c;加入队列中的消息仍可以在系统恢复后被处理&＃xff1b;
• 缓冲&＃xff1a;有助于解决生产消息和消费消息的处理速度不一致的情况&＃xff1b;
• 灵活性&峰值处理能力&＃xff1a;不会因为突发的超负荷的请求而完全崩溃&＃xff0c;消息队列能够使关键组件顶住突发的访问压力&＃xff1b;
• 异步通信&＃xff1a;消息队列允许用户把消息放入队列但不立即处理它&＃xff1b;

 发布/订阅模式&＃xff1a;

一对多&＃xff0c;生产者将消息发布到 Topic 中&＃xff0c;有多个消费者订阅该主题&＃xff0c;发布到 Topic 的消息会被所有订阅者消费&＃xff0c;被消费的数据不会立即从 Topic 清除。

Kafka 框架架构图如下所示&＃xff1a;

Kafka 存储的消息来自任意多被称为 Producer 生产者的进程&＃xff0c;数据从而可以被发布到不同的 Topic 主题下的不同 Partition 分区。在一个分区内&＃xff0c;这些消息被索引并连同时间戳存储在一起。其它被称为 Consumer 消费者的进程可以从分区订阅消息。Kafka 运行在一个由一台或多台服务器组成的集群上&＃xff0c;并且分区可以跨集群结点分布。

Kafka 重要概念&＃xff1a;

 1&＃xff09;、Producer&＃xff1a; 消息生产者&＃xff0c;向 Kafka Broker 发消息的客户端&＃xff1b;

 2&＃xff09;、Consumer&＃xff1a;消息消费者&＃xff0c;从 Kafka Broker 取消息的客户端&＃xff1b;

 3&＃xff09;、Consumer Group&＃xff1a;消费者组&＃xff08;CG&＃xff09;&＃xff0c;消费者组内每个消费者负责消费不同分区的数据&＃xff0c;提高消费能力。一个分区只能由组内一个消费者消费&＃xff0c;消费者组之间互不影响。所有的消费者都属于某个消费者组&＃xff0c;即消费者组是逻辑上的一个订阅者&＃xff1b;

 4&＃xff09;、Broker&＃xff1a;一台 Kafka 机器就是一个 Broker。一个集群由多个 Broker 组成。一个 Broker 可以容纳多个 Topic&＃xff1b;

 5&＃xff09;、Topic&＃xff1a;可以理解为一个队列&＃xff0c;Topic 将消息分类&＃xff0c;生产者和消费者面向的是同一个 Topic&＃xff1b;

 6&＃xff09;、Partition&＃xff1a;为了实现扩展性&＃xff0c;提高并发能力&＃xff0c;一个非常大的 Topic 可以分布到多个 Broker &＃xff08;即服务器&＃xff09;上&＃xff0c;一个 Topic 可以分为多个 Partition&＃xff0c;每个 Partition 是一个 有序的队列&＃xff1b;

 7&＃xff09;、Replica&＃xff1a;副本&＃xff0c;为实现备份的功能&＃xff0c;保证集群中的某个节点发生故障时&＃xff0c;该节点上的 Partition 数据不丢失&＃xff0c;且 Kafka 仍然能够继续工作&＃xff0c;Kafka 提供了副本机制&＃xff0c;一个 Topic 的每个分区都有若干个副本&＃xff0c;一个 Leader 和若干个 Follower&＃xff1b;

 8&＃xff09;、Leader&＃xff1a;每个分区多个副本的“主”副本&＃xff0c;生产者发送数据的对象&＃xff0c;以及消费者消费数据的对象&＃xff0c;都是 Leader&＃xff1b;

 9&＃xff09;、Follower&＃xff1a;每个分区多个副本的“从”副本&＃xff0c;实时从 Leader 中同步数据&＃xff0c;保持和 Leader 数据的同步。Leader 发生故障时&＃xff0c;某个 Follower 还会成为新的 Leader&＃xff1b;

 10&＃xff09;、Offset&＃xff1a;消费者消费的位置信息&＃xff0c;监控数据消费到什么位置&＃xff0c;当消费者挂掉再重新恢复的时候&＃xff0c;可以从消费位置继续消费&＃xff1b;

 11&＃xff09;、Zookeeper&＃xff1a;Kafka 集群能够正常工作&＃xff0c;需要依赖于 Zookeeper&＃xff0c;Zookeeper 帮助 Kafka 存储和管理集群信息&＃xff1b;

常用命令

#启动kafka/export/server/kafka/bin/kafka-server-start.sh -daemon /export/server/kafka/config/server.properties #停止kafka/export/server/kafka/bin/kafka-server-stop.sh #查看topic信息/export/server/kafka/bin/kafka-topics.sh --list --zookeeper node1:2181#创建topic/export/server/kafka/bin/kafka-topics.sh --create --zookeeper node1:2181 --replication-factor 1 --partitions 3 --topic test#查看某个topic信息/export/server/kafka/bin/kafka-topics.sh --describe --zookeeper node1:2181 --topic test#删除topic/export/server/kafka/bin/kafka-topics.sh --zookeeper node1:2181 --delete --topic test#启动生产者--控制台的生产者--一般用于测试/export/server/kafka/bin/kafka-console-producer.sh --broker-list node1:9092 --topic spark_kafka# 启动消费者--控制台的消费者/export/server/kafka/bin/kafka-console-consumer.sh --bootstrap-server node1:9092 --topic spark_kafka --from-beginning

整合说明

两种方式

Receiver-based Approach&＃xff1a;

1.KafkaUtils.createDstream基于接收器方式&＃xff0c;消费Kafka数据&＃xff0c;已淘汰&＃xff0c;企业中不再使用&＃xff1b;

2.Receiver作为常驻的Task运行在Executor等待数据&＃xff0c;但是一个Receiver效率低&＃xff0c;需要开启多个&＃xff0c;再手动合并数据(union)&＃xff0c;再进行处理&＃xff0c;很麻烦&＃xff1b;

3.Receiver那台机器挂了&＃xff0c;可能会丢失数据&＃xff0c;所以需要开启WAL(预写日志)保证数据安全&＃xff0c;那么效率又会降低&＃xff1b;

4.Receiver方式是通过zookeeper来连接kafka队列&＃xff0c;调用Kafka高阶API&＃xff0c;offset存储在zookeeper&＃xff0c;由Receiver维护&＃xff1b;

5.Spark在消费的时候为了保证数据不丢也会在Checkpoint中存一份offset&＃xff0c;可能会出现数据不一致&＃xff1b;

Direct Approach (No Receivers)&＃xff1a;

1.KafkaUtils.createDirectStream直连方式&＃xff0c;Streaming中每批次的每个job直接调用Simple Consumer API获取对应Topic数据&＃xff0c;此种方式使用最多&＃xff0c;面试时被问的最多&＃xff1b;

2.Direct方式是直接连接kafka分区来获取数据&＃xff0c;从每个分区直接读取数据大大提高并行能力

3.Direct方式调用Kafka低阶API(底层API)&＃xff0c;offset自己存储和维护&＃xff0c;默认由Spark维护在checkpoint中&＃xff0c;消除了与zk不一致的情况 &＃xff1b;

4.当然也可以自己手动维护&＃xff0c;把offset存在MySQL/Redis中&＃xff1b;

两个版本API

Spark Streaming与Kafka集成&＃xff0c;有两套API&＃xff0c;原因在于Kafka Consumer API有两套&＃xff0c;文档&＃xff1a;

http://spark.apache.org/docs/2.4.5/streaming-kafka-integration.html

1. Kafka 0.8.x版本 -早已淘汰

• 底层使用老的KafkaAPI:Old Kafka Consumer API
• 支持Receiver(已淘汰)和Direct模式&＃xff1a;

2.Kafka 0.10.x版本-开发中使用

• 底层使用新的KafkaAPI: New Kafka Consumer API
• 只支持Direct模式