大数据-78 Kafka 集群模式 集群的应用场景与Kafka集群的搭建 三台云服务器

本文涉及的产品
云原生网关 MSE Higress,422元/月
云原生大数据计算服务 MaxCompute,5000CU*H 100GB 3个月
云原生大数据计算服务MaxCompute,500CU*H 100GB 3个月
简介: 大数据-78 Kafka 集群模式 集群的应用场景与Kafka集群的搭建 三台云服务器

点一下关注吧!!!非常感谢!!持续更新!!!

目前已经更新到了:

Hadoop(已更完)

HDFS(已更完)

MapReduce(已更完)

Hive(已更完)

Flume(已更完)

Sqoop(已更完)

Zookeeper(已更完)

HBase(已更完)

Redis (已更完)

Kafka(正在更新…)

章节内容

上节我们完成了如下的内容:


Kafka 延时队列

Kafka 重试队列

Kafka JavaAPI 实现 重试队列的操作

a932fe3805a26da88bb43e2a56dfea34_b60754598b1544a8b8f9bb5ece5ba5ba.png 应用场景

消息传递

Kafka可以很好的替代传统的邮件代理,消息代理的使用有很多种原因(将处理与数据生产者分离,缓冲未处理消息等)。与大多数邮件系统相比,Kafka具有更好的吞吐量,内置的分区,复制和容错功能,这使其成为大规模邮件处理应用程序的理想解决方案。


网站活动路由

Kafka最初的用例是能够将用户活动跟踪管道重建为一组实时的发布-订阅。这意味着将网站活动(页面浏览、搜索、其他操作等)发布到主题中心,每种活动类型只有一个主题。这些可用于一系列的用例的订阅,包括实时处理,实时监控,以及加载到Hadoop或脱机数据仓库系统中以进行脱机处理和报告。

活动跟踪通常量很大,因为每个用户页面视图都会生成许多活动消息。


监控指标

Kafka通常用于操作监控数据,这涉及汇总来自分布式应用程序的统计信息,以生成操作数据的集中。


日志汇总

许多人使用Kafka代替日志聚合解决方案,日志聚合通常从服务器收集物理日志文件,并将它们放在中央位置(也许是文件服务器或HDFS)以进行处理。Kafka提取文件的详细信息,并以日志的形式更清晰的抽象日志或事件数据,这允许较低的延迟的处理,并更容易支持多个数据源和分布式数据消耗。以日志为中心的系统(例如Scribe或Flume)相比,Kafka具有同样出色的性能,由于复制而提供的更强的耐用性保证以及更低的端到端的延迟。


流处理

Kafka的需要用户在由多个阶段组成的处理管道中处理数据,其中原始输入数据从Kafka主题中使用,然后进行汇总,充实或以其他方式转换为新主题,以供进一步使用或后续处理。例如,用于推荐新闻文章的处理管道可能会从RSS提要中检索文章内容,并将其发布到文章主题中。进一步的处理可能会使该内容规范化或重复数据删除,并将清晰后的文章内容发布到新主题中。最后的处理阶段可能会尝试向用户推荐此内容。这样的处理管道基于各个主题创建实时数据流的图形。

从0.10.0.0开始,一个轻量但功能强大的流处理库成为KafkaStreams可以在ApacheKafka中使用来执行上述数据处理。除了KafkaStreams之外,其他开源流处理工具还包括ApacheStorm和Apache Samza。


活动采集

事件源是一种应用程序,其中状态更改以时间顺序记录记录。Kafka对大量存储的日志数据的支持使其成为以这种样式构建的应用程序的绝佳后端。


提交日志

Kafka可以用作分布式系统的一种外部提交日志,该日志有助于在节点之间复制数据,并充当故障节点恢复其数据的重新同步机制。Kafka中的日志压缩功能有助于支持此用法。


集群搭建

集群设计

949de985d10b8baad4c5e3350c7be558_b7cc48c1087a45e7a66b854c002acc00.png 由于之前我们已经搭建过单机的Kafka,同时我们为了做之前的实验,一共搭建了两台Kafka的小集群(用作Broker宕机之后的分区、副本等内容的测试),这里我们将对一些部分进行简化。


机器详情

目前我们有三台云服务:


h121.wzk.icu

h122.wzk.icu

h123.wzk.icu

我们已经搭建好了,ZooKeeper的集群,如果你还没有搭建,需要回到之前的章节:ZooKeeper集群搭建。

这里开始,我们直接搭建Kafka的集群环境。

在 h121.wzk.icu 中,我我们已经有了:kafka_2.12-2.7.2 且是配置好的。

Kafka开源项目指南

文章已被社区收录

加入社区


大数据

同时被 2 个专栏收录

169 篇文章18 订阅

订阅专栏


Kafka

22 篇文章1 订阅

订阅专栏

点一下关注吧!!!非常感谢!!持续更新!!!

目前已经更新到了:

Hadoop(已更完)

HDFS(已更完)

MapReduce(已更完)

Hive(已更完)

Flume(已更完)

Sqoop(已更完)

Zookeeper(已更完)

HBase(已更完)

Redis (已更完)

Kafka(正在更新…)

章节内容

上节我们完成了如下的内容:


Kafka 延时队列

Kafka 重试队列

Kafka JavaAPI 实现 重试队列的操作



应用场景

消息传递

Kafka可以很好的替代传统的邮件代理,消息代理的使用有很多种原因(将处理与数据生产者分离,缓冲未处理消息等)。与大多数邮件系统相比,Kafka具有更好的吞吐量,内置的分区,复制和容错功能,这使其成为大规模邮件处理应用程序的理想解决方案。


网站活动路由

Kafka最初的用例是能够将用户活动跟踪管道重建为一组实时的发布-订阅。这意味着将网站活动(页面浏览、搜索、其他操作等)发布到主题中心,每种活动类型只有一个主题。这些可用于一系列的用例的订阅,包括实时处理,实时监控,以及加载到Hadoop或脱机数据仓库系统中以进行脱机处理和报告。

活动跟踪通常量很大,因为每个用户页面视图都会生成许多活动消息。


监控指标

Kafka通常用于操作监控数据,这涉及汇总来自分布式应用程序的统计信息,以生成操作数据的集中。


日志汇总

许多人使用Kafka代替日志聚合解决方案,日志聚合通常从服务器收集物理日志文件,并将它们放在中央位置(也许是文件服务器或HDFS)以进行处理。Kafka提取文件的详细信息,并以日志的形式更清晰的抽象日志或事件数据,这允许较低的延迟的处理,并更容易支持多个数据源和分布式数据消耗。以日志为中心的系统(例如Scribe或Flume)相比,Kafka具有同样出色的性能,由于复制而提供的更强的耐用性保证以及更低的端到端的延迟。


流处理

Kafka的需要用户在由多个阶段组成的处理管道中处理数据,其中原始输入数据从Kafka主题中使用,然后进行汇总,充实或以其他方式转换为新主题,以供进一步使用或后续处理。例如,用于推荐新闻文章的处理管道可能会从RSS提要中检索文章内容,并将其发布到文章主题中。进一步的处理可能会使该内容规范化或重复数据删除,并将清晰后的文章内容发布到新主题中。最后的处理阶段可能会尝试向用户推荐此内容。这样的处理管道基于各个主题创建实时数据流的图形。

从0.10.0.0开始,一个轻量但功能强大的流处理库成为KafkaStreams可以在ApacheKafka中使用来执行上述数据处理。除了KafkaStreams之外,其他开源流处理工具还包括ApacheStorm和Apache Samza。


活动采集

事件源是一种应用程序,其中状态更改以时间顺序记录记录。Kafka对大量存储的日志数据的支持使其成为以这种样式构建的应用程序的绝佳后端。


提交日志

Kafka可以用作分布式系统的一种外部提交日志,该日志有助于在节点之间复制数据,并充当故障节点恢复其数据的重新同步机制。Kafka中的日志压缩功能有助于支持此用法。


集群搭建

集群设计


由于之前我们已经搭建过单机的Kafka,同时我们为了做之前的实验,一共搭建了两台Kafka的小集群(用作Broker宕机之后的分区、副本等内容的测试),这里我们将对一些部分进行简化。


机器详情

目前我们有三台云服务:


h121.wzk.icu

h122.wzk.icu

h123.wzk.icu

我们已经搭建好了,ZooKeeper的集群,如果你还没有搭建,需要回到之前的章节:ZooKeeper集群搭建。

这里开始,我们直接搭建Kafka的集群环境。

在 h121.wzk.icu 中,我我们已经有了:kafka_2.12-2.7.2 且是配置好的。

e36e4aa20974d406b759be1decab9e48_9ea52655652c4e48b2196e22d323c918.png

我们借助之前Hadoop中编写的Shell工具来完成Kafka文件的分发(你也可以使用别的方法,比如压缩包等等)

rsync-script kafka_2.12-2.7.2/

h121

h122

h123

环境变量

我们在三台节点上,尽量配置好环境变量:

  • JDK
  • ZooKeeper
  • Kafka

修改配置

h121

vim /opt/servers/kafka_2.12-2.7.2/config/server.properties
• 1

修改如下内容:

# h121是0、h122是1、h123是2
broker.id=0

# 数据的存储目录
log.dirs=/opt/kafka-logs

# ZooKeeper 地址
zookeeper.connect=h121.wzk.icu:2181,h122.wzk.icu:2181,h123.wzk.icu:2181

对应的内容截图如下所示:

h122

# h121是0、h122是1、h123是2
broker.id=1

# 数据的存储目录
log.dirs=/opt/kafka-logs

# ZooKeeper 地址
zookeeper.connect=h121.wzk.icu:2181,h122.wzk.icu:2181,h123.wzk.icu:2181

h123

# h121是0、h122是1、h123是2
broker.id=3

# 数据的存储目录
log.dirs=/opt/kafka-logs

# ZooKeeper 地址
zookeeper.connect=h121.wzk.icu:2181,h122.wzk.icu:2181,h123.wzk.icu:2181

对应的截图如下图所示:

启动集群

在每台节点上都执行:

kafka-server-start.sh /opt/servers/kafka_2.12-2.7.2/config/server.properties

查看集群

我们需要进入ZooKeeper来启动服务:

zkCli.sh
# 进入ZK后,我们查看当中的信息
ls /brokers/ids

执行结果如下图所示:

第一次执行的时候,我的第三台没有配置好环境变量,启动失败了,第二次可以看到:【0,1,2】

h121

[zk: localhost:2181(CONNECTED) 2] get /brokers/ids/0
{"listener_security_protocol_map":{"PLAINTEXT":"PLAINTEXT"},"endpoints":["PLAINTEXT://h121.wzk.icu:9092"],"jmx_port":-1,"features":{},"host":"h121.wzk.icu","timestamp":"1722931444209","port":9092,"version":5}
[zk: localhost:2181(CONNECTED) 3]

h122

[zk: localhost:2181(CONNECTED) 3] get /brokers/ids/1
{"listener_security_protocol_map":{"PLAINTEXT":"PLAINTEXT"},"endpoints":["PLAINTEXT://h122.wz

h123

[zk: localhost:2181(CONNECTED) 4] get /brokers/ids/2
{"listener_security_protocol_map":{"PLAINTEXT":"PLAINTEXT"},"endpoints":["PLAINTEXT://h123.wzk

如下所示:

目录
相关文章
|
18天前
|
消息中间件 存储 监控
构建高可用性Apache Kafka集群:从理论到实践
【10月更文挑战第24天】随着大数据时代的到来,数据传输与处理的需求日益增长。Apache Kafka作为一个高性能的消息队列服务,因其出色的吞吐量、可扩展性和容错能力而受到广泛欢迎。然而,在构建大规模生产环境下的Kafka集群时,保证其高可用性是至关重要的。本文将从个人实践经验出发,详细介绍如何构建一个高可用性的Kafka集群,包括集群规划、节点配置以及故障恢复机制等方面。
51 4
|
16天前
|
SQL 存储 算法
基于对象 - 事件模式的数据计算问题
基于对象-事件模式的数据计算是商业中最常见的数据分析任务之一。对象如用户、账号、商品等,通过唯一ID记录其相关事件,如操作日志、交易记录等。这种模式下的统计任务包括无序计算(如交易次数、通话时长)和有序计算(如漏斗分析、连续交易检测)。尽管SQL在处理无序计算时表现尚可,但在有序计算中却显得力不从心,主要原因是其对跨行记录运算的支持较弱,且大表JOIN和大结果集GROUP BY的性能较差。相比之下,SPL语言通过强化离散性和有序集合的支持,能够高效地处理这类计算任务,避免了大表JOIN和复杂的GROUP BY操作,从而显著提升了计算效率。
|
16天前
|
消息中间件 存储 Prometheus
Kafka集群如何配置高可用性
Kafka集群如何配置高可用性
|
24天前
|
SQL 存储 算法
基于对象 - 事件模式的数据计算问题
基于对象-事件模式的数据计算是商业中最常见的数据分析任务之一。这种模式涉及对象(如用户、账户、商品等)及其相关的事件记录,通过这些事件数据可以进行各种统计分析,如漏斗分析、交易次数统计等。然而,SQL 在处理这类任务时表现不佳,特别是在有序计算方面。SPL 作为一种强化离散性和有序集合的语言,能够高效地处理这类计算,避免了大表 JOIN 和大结果集 GROUP BY 的性能瓶颈。通过按 ID 排序和分步计算,SPL 能够显著提高计算效率,并支持实时数据处理。
zdl
|
3天前
|
消息中间件 运维 大数据
大数据实时计算产品的对比测评:实时计算Flink版 VS 自建Flink集群
本文介绍了实时计算Flink版与自建Flink集群的对比,涵盖部署成本、性能表现、易用性和企业级能力等方面。实时计算Flink版作为全托管服务,显著降低了运维成本,提供了强大的集成能力和弹性扩展,特别适合中小型团队和业务波动大的场景。文中还提出了改进建议,并探讨了与其他产品的联动可能性。总结指出,实时计算Flink版在简化运维、降低成本和提升易用性方面表现出色,是大数据实时计算的优选方案。
zdl
17 0
|
1月前
|
分布式计算 大数据 分布式数据库
大数据-158 Apache Kylin 安装配置详解 集群模式启动(一)
大数据-158 Apache Kylin 安装配置详解 集群模式启动(一)
40 5
|
1月前
|
SQL 分布式计算 NoSQL
大数据-170 Elasticsearch 云服务器三节点集群搭建 测试运行
大数据-170 Elasticsearch 云服务器三节点集群搭建 测试运行
40 4
|
1月前
|
资源调度 大数据 分布式数据库
大数据-158 Apache Kylin 安装配置详解 集群模式启动(二)
大数据-158 Apache Kylin 安装配置详解 集群模式启动(二)
40 2
|
1月前
|
消息中间件 存储 运维
为什么说Kafka还不是完美的实时数据通道
【10月更文挑战第19天】Kafka 虽然作为数据通道被广泛应用,但在实时性、数据一致性、性能及管理方面存在局限。数据延迟受消息堆积和分区再平衡影响;数据一致性难以达到恰好一次;性能瓶颈在于网络和磁盘I/O;管理复杂性涉及集群配置与版本升级。
|
1月前
|
消息中间件 Java Kafka
Flink-04 Flink Java 3分钟上手 FlinkKafkaConsumer消费Kafka数据 进行计算SingleOutputStreamOperatorDataStreamSource
Flink-04 Flink Java 3分钟上手 FlinkKafkaConsumer消费Kafka数据 进行计算SingleOutputStreamOperatorDataStreamSource
45 1