从 Kafka 到 Pulsar的数据流演进之路 | 青训营笔记

Rainbow_Sea
249 阅读13分钟

这是我参与「第四届青训营 」笔记创作活动的的第12天

今天是大数据专场基础班的第十二次课，主要内容是从 Kafka 到 Pulsar的数据流演进之路，主要分为下面四个板块。

一、 消息队列概述

1. 消息队列的应用场景

image.png

1.1 MQ消息通道

image.png

1.2 EventBridge数据总线

  • 事件源: 将云服务、自定义应用、SaaS应用等应用程序产生的事件消息发布到事件集
  • 事件集: 存诸接收到的事件消息，并根据事件规则将事件消息路由到事件目标
  • 事件目标: 消费事件消息

image.png

1.3 Data Platform流数据平台

  1. 提供批/流数据处理能力
  2. 各类组件提供各类Connect
  3. 提供Streaming/Function能力
  4. 根据数据schema灵活的进行数据预处理

image.png

2. 主流消息队列的相关介绍

image.png

二、 Kafka 详解

1. Kafka架构介绍

image.png

1.1 zookeeper

  • 选举机制: Paxos机制
  • 提供一致性:
    • 写入(强一致性)
    • 读取(会话一致性)
  • 提供可用性:
    • 一半以上节点存活即可读写
  • 提供功能:
    • watch机制
    • 持久/临时节点能力

image.png

  • Kafka存储数据:

  1. Broker Meta信息(l临时节点)

  2. Controller信息(临时节点)

  3. Topic信息(持久节点)

  4. Config 信息(持久节点)

1.2 Broker

image.png

  • Broker角色
    • 若干个 Broker节点组成 Kafka集群
    • Broker作为消息的接收模块，使用 React 网络模型进行消息数据的接收
    • Broker作为消息的持久化模块，进行消息的副本复制以及持久化
    • Broker作为高可用模块，通过副本间的Failover进行高可用保证

1.3.1 Controller 选举

  • Controller选举
    • Broker启动会尝试去水k中注册controller节点
    • 注册上 controller节点的 broker即为controller
    • 其余broker 会watch controller节点，节点出现异常则进行重新注册

image.png

1.3.2 Controller作用

  • Controller作用
    • Broker重启/宕机时，负责副本的Failover切换
    • Topic创建/删除时，负责Topic meta信息广播
    • 集群扩缩容时，进行状态控制
    • Partition/Replica状态机维护

image.png

1.4 Coordinator

  • Coordinator介绍
    • 负责topic-partition <-> consumer的负载均衡
    • 根据不同的场景提供不同的分配策略
      • Dynamic Membership Protocol
      • Static Membership Protocol
      • lncremental Cooperative Rebalance

image.png

2. Kafka高可用

  • Kafka高可用
    • 副本同步机制
      • 提供Isr副本复制机制，提供热备功能
      • 写入端提供ack=0,-1,1机制，控制副本同步强弱
    • 副本切换机制
      • 提供clean/unclean副本选举机制

image.png

2.1 Kafka副本ISR机制

  • AR
    • Assign Replica，已经分配的所有副本
  • OSR
    • Out Sync Replica
    • 很久没有同步数据的副本
  • ISR
    • 一直都在同步数据的副本
    • 可以作为热备进行切换的副本
    • min.insync.replicas最少isr数量配置

image.png

2.2 Kafka写入Ack机制

  • Ack = 1
    • Leader副本写入成功，Producer即认为写成功
  • Ack = 0
    • OneWay模式
    • Producer '发送后即为成功
  • Ack= -1
    • ISR中所有副本都成功，Producer 才认为写成功

2.3.1 Kafka副本同步

  • LEO
    • Log End Offset，日志最末尾的数据
  • Hw
    • ISR中最小的LEO作为Hw
    • HW的消息为Consumer可见的消息

image.png

2.3.2 Kafka副本选举

  • Clean选举
    • 优先选取Isr 中的副本作为leader
    • 如果 Isr中无可用副本，则partition不可用
  • Unclean选举
    • 优先选取Isr中的副本作为leader
    • 如果Isr中无可用副本，则选择其他存活副本

image.png

3. Kafka集群扩缩容

3.1 Kafka集群扩缩容

  • Kafka集群扩缩容之后的目标
    • Topic维度
      • partition在各个 broker之间分布是均匀的
      • 同一个partition的replica不会分布在一台broker
    • Broker 维度
      • Broker之间replica的数量是均匀的

image.png

3.2 Kafka集群扩容步骤

  • 扩容Broker节点
    • Leader副本写入成功，Producer 即认为写成功
  • 计算均衡的 Replica分布拓扑
    • 保证Topic的partition在 broker间分布均匀
    • 保证 Broker之间Replica分布均匀
  • Controller负责新的副本分布元数据广播
    • Controller将新的leaderlfollower 信息广播给broker
  • Broker负责新副本的数据同步
    • Broker上有需要同步数据的副本则进行数据同步

3.3 Kafka集群缩容步骤

  • 计算均衡的Replica分布拓扑
    • 保证Topic的partition在broker间分布均匀
    • 保证 Broker之间Replica分布均匀
  • Controller负责新的副本分布元数据广播
    • Controller将新的leaderlfollower信息广播给broker
  • Broker负责新副本的数据同步
    • Broker上有需要同步数据的副本则进行数据同步
  • 下线缩容的 Broker节点
    • 数据同步完毕之后下线缩容的 Broker节点

3.4 Kafka集群扩缩容问题

  • 扩缩容时间长
    • 涉及到数据迁移，在生产环境中一次扩缩容可能要迁移TB甚至PB的数据
  • 扩缩容期间集群不稳定
    • 保证数据的完整性，往往会从最老的数据进行同步，这样会导致集群时刻处于从磁盘读取数据的状态，disk/net/cpu负载都会比较高
  • 扩缩容期间无法执行其他操作
    • 在一次扩缩容操作结束之前，无法进行其他运维操作(扩缩容)

4. Kafka未来演进之路

image.png

4.1 Kafka去除zk依赖

  • 依赖ZooKeeper存在问题
    • 元数据存取困难
      • 元数据的存取过于困难，每次重新选举的controler需要把整个集群的元数据重新restore，非常的耗时且影响集群的可用性
    • 元数据更新网络开销大
      • 整个元数据的更新操作也是以全量推的方式进行，网络的开销也会非常大
    • 强耦合违背软件设计原则
      • Zookeeper对于运维来说，维护Zookeeper也需要一定的开销，并且kafka强耦合与zk也并不好，还得时刻担心zk的宕机问题，违背软件设计的高内聚，低耦合的原则
    • 网络分区复杂度高
      • Zookeeper本身并不能兼顾到broker与broker之间通信的状态，这就会导致网络分区的复杂度成几何倍数增长
    • 并发访问zk问题多
      • Zookeeper本身并不能兼顾到broker与broker之间通信的状态，这就会导致网络分区的复杂度成几何倍数增长

4.2 Kafka依赖KRaft

  • Process.Roles = Broker
    • 服务器在KRaft模式下充当Broker
  • Process.Roles = Controller
    • 服务器在KRaft模式下充当Controller
  • Process.Roles = Broker,Controller
    • 服务器在KRaft模式下充当Broker和Controller
  • Process.Roles = null
    • 那么集群就假定是运行在ZooKeeper模式下

image.png

image.png

5. Kafka运维/调优经验介绍

image.png

5.1 Kafka单机吞吐

  • Kafka Version
    • 2.3.1
  • 机器配置
    • 40C500GB12*1TB 25GB
  • 写入配置
    • Ack = -1, replica = 3, in_sync_replica = 3
    • 单条消息5KB
  • 吞吐
    • 单机150MB/S

5.2 Kafka集群参数配置

  • zookeeper.session.timeout.ms = 30000
  • log.segment.bytes = 536870912
  • log.retention.hours = 36
  • log.retention.bytes = 274877906944
  • num.network.threads = 32
  • num.io.threads = 200
  • auto.create.topics.enable = false
  • auto.leader.rebalance.enable = false
  • unclean.leader.election.enable = false
  • advertised.listeners = SASL_PLAINTEXT://:,PLAINTEXT://:
  • security.inter.broker.protocol = SASL_PLAINTEXT

5.3 扩缩容优化

  • 目标
    • Topic-Partition均匀分布在 Broker间
    • Broker 间的 Replica是均匀的

image.png

5.4 指标可视化

image.png

三、 Pulsar详解

1.Pulsar架构介绍

image.png

1.1 Pulsar Proxy

  • Pulsar客户端连接集群的两种方式
    • Pulsar Client -> Broker
    • Pulsar Client -> Proxy
  • Pulsar Proxy的作用及应用场景
    • 部分场景无法知道 Broker地址，如云环境或者Kubernetes环境
    • Proxy提供类似GateWay代理能力，解耦客户端和Broker，保障Broker安全

image.png

1.2 Pulsar Broker

  • Pulsar Broker 无状态组件，负责运行两个模块
    • Http服务器
      • 暴露了restful接口，提供生产者和消费者topic查找api
    • 调度分发器
      • 异步的tcp服务器，通过自定义进制协议进行数据传输
  • Pulsar Broker 作为数据层代理
    • Bookie通讯
    • 作为Ledger代理负责和Bookie进行通讯
  • 流量代理
    • 消息写入Ledger存诸到Bookie
    • 消息缓存在堆外，负责快速响应

image.png

1.3 Pulsar Storage

  • Pulsar 数据存储Segment在不同存储中的抽象
    • 分布式Journal系统(Bookeeper)中为Journal/Ledger
    • 分布式文件系统(GFS/HDFS)中为文件
    • 普通磁盘中为文件
    • 分布式 Blob存储中为Blob
    • 分布式对象存储中为对象
  • 定义好抽象之后，即可实现多介质存储

image.png

1.4 Pulsar IO 连接器

  • Pulsar lO分为输入(Input)和输出(Output)两个模块，输入代表数据从哪里来，通过Source 实现数据输入。输出代表数据要往哪里去，通过Sink 实现数据输出
  • Pulsar提出了IO(也称为Pulsar Connector)，用于解决 Pulsar与周边系统的集成问 题，帮助用户高效完成工作
  • 目前Pulsar IO支持非常多的连接集成操作:例如HDFS、Spark、Flink、Flume、ES、HBase等

image.png

1.5 Pulsar Functions(轻量级计算框架)

  • Pulsar Functions是一个轻量级计算框架，提供一个部署简单、运维简单、API简单的FAAS平台
  • Pulsar Functions提供基于事件的服务，支持有状态与无状态的多语言计算，是对复杂的大数据处理框架的有力补充
  • 使用Pulsar Functions，用户可以轻松地部署和管理function，通过function 从 Pulsar topic读取数据或者生产新数据到 Pulsar topic

image.png

2.Bookkeepr介绍

2.1 Bookeeper整体架构

image.png

image.png

2.2 Bookkeeper基本概念

  • Ledger: BK的一个基本存储单元，BK Client的读写操作都是以Ledger为粒度的
  • Fragment: BK的最小分布单元(实际上也是物理上的最小存储单元)，也是 Ledger 的组成单位，默认情况下一个Ledger会对应的一个Fragment(一个Ledger也可能由多个Fragment组成)
  • Entry:每条日志都是一个Entry，它代表一个record，每条record都会有一个对应的entry id

image.png

2.3.1 Bookkeeper 新建Ledger

  • Ensemble size(E):一个 Ledger所涉及的Bookie集合
  • Write Quorum Size(Qw):副本数
  • Ack Quorum Size(Qa):写请求成功需要满足的副本数

image.png

2.3.2 Bookkeeper Ledger分布

  • 从 Bookie Pool挑选 Bookies构成Ensemble
  • Write Quorum Size决定发送给哪些Bookies
  • Ack Quorum Size决定收到几个Ack 即为成功

image.png

2.4.1 Bookkeeper读写分离

  • 写入优化:
    • 写入时，不但会写入到Journal中还会写入到缓存(memtable)中，定期会做刷盘(刷盘前会做排序，通过聚合+排序优化读取性能)
  • 读取优化:
    • 先读Memtable,没命中再通过索引读磁盘
    • Ledger Device中会维护一个索引结构，存储在RocksDB中，它会将(Ledgerld，Entryld)映射到(EntryLogld，文件中的偏移量)

image.png

2.4.2 Bookkeeper 写一致性

  • LastAddPushed
  • LastAddConfirmed
  • Fencing避免脑裂

image.png

2.4.3 Bookkeeper读─致性

  • 所有的Reader都可以安全读取 Entry ID小于或者等于LAC的记录，从而保证reader不会读取未确认的数据，从而保证了reader之间的一致性

2.5 Bookkeeper with pulsar

  • Topic-Partition:
    • Topic由多个partition组成
    • Partition由多个segment组成
    • Segment对应Ledger
  • 可以发现:
    • Partition <-> Broker 之间只是映射关系
    • Broker在扩缩容的过程中只需要更改映射即可

image.png

3. Pulsar特性介绍

image.png

3.1 Pulsar生产模式

image.png

3.2 Pulsar消费模式

  • Exclusive
  • Failover
  • Shared
  • Key_Shared

image.png

3.2.1 Exclusive消费模式

  • 独占订阅(Stream流模型)
    • 独占订阅中，在任何时间，一个消费者组(订阅)中有且只有一个消费者来消费Topic中的消息

image.png

3.2.2 Failover消费模式

  • 故障切换(Stream流模型)
  • 使用故障切换订阅，多个消费者(Consumer)可以附加到同一订阅。但是，一个订阅中的所有消费者，只会有一个消费者被选为该订阅的主消费者。其他消费者将被指定为故障转移消费者

image.png

3.2.3 Shared消费模式

  • 共享订阅(Queue队列模型)
    • 使用共享订阅，在同一个订阅背后，用户按照应用的需求挂载任意多的消费者。订阅中的所有消息以循环分发形式发送给订阅背后的多个消费者，并且一个消息仅传递给一个消费者

image.png

3.2.4 Key Shared消费模式

  • 按Key共享订阅(Queue队列模型)
    • 使用共享订阅，在同一个订阅背后，用户按照应用的需求挂载任意多的消费者。订阅中的所有消息以key-hash发送给订阅背后的多个消费者，并且一个消息仅传递给一个消费者

image.png

3.3 Pulsar 多租户

  • Pulsar多租户体现在Url中
    • persistent://tenant/namespace/topic

3.4 Pulsar Plugin

  • 当前支持 Plugin类型
    • KOP (Kafka on Pulsar)
    • ROP (RocketMQ on Pulsar)
    • AOP (AMQP on Pulsar)
    • Mop (MQTT on Pulsar)
  • 实现Plugin需要支持的功能
    • 路由查询
    • Message Protocol
    • Offset & Msgld

image.png

3.5 Pulsar GEO Relication

  • 跨数据中心复制
  • 消费其他地域数据

image.png

4.集群HA &Scale-up

4.1 Pulsar HA & Scale-up

  • Topic<-> Bundle完成映射
  • Bundle 分配给Broker

image.png

4.2 Pulsar HA & Scale-up

  • Lookup Topic
  • Lookup Result
  • Establish TCP Connection

image.png

5.Pulsar vs Kafka

image.png

  • 存储架构
    • 存储计算分离之后带来的优劣势
    • 多层架构，状态分离之后的优势
  • 运维操作
    • 应对突发流量变化，集群扩缩容是否便捷
    • 运维任务是否影响可用性
    • 集群部署是否灵活
  • 功能特性
    • 多语言&多协议
    • 多租户管理
    • 生产消费模式
  • 生态集成

5.1 存储计算分离

  • 分层架构优势
    • 流量代理层和数据存储层解耦
    • 流量代理层无状态，可快速扩缩容(k8s等弹性平台)
    • 流量代理层可以对接海量的客户端连接
    • 存储层负责数据存储，可以使用多级存储
  • 计算层
    • 对于写入的数据，可以做预处理，简单ETL
    • 可以做数据缓存，应对高扇出度场景
    • 无状态，扩缩容之后，能快速完成负载均衡 Balance
  • 存储层
    • 按照数据冷热进行存储介质区分，降低成本
    • 历史数据可海量保存，数据无价
    • 可直接通过存储层接口读取数据，批式计算

image.png

四、 周边和生态

1. 周边生态概览

image.png

2. Pulsar SQL

image.png

3. Kafka Schema

  • 向Kafka发送数据时，需要先向Schema Registry注册schema,然后序列化发送到Kafka里
  • Schema Registry server为每个注册的schema提供一个全局唯一ID，分配的ID保证单调递增，但不—定是连续的
  • 当我们需要从 Kafka消费数据时，消费者在反序列化前，会先判断schema是否在本地内存中，如果不在本地内存中，则需要从Schema Registry 中获取schema，否则，无需获取

五、 课堂总结

  • 消息队列概述
    • 应用场景(从消息到消息、事件、流融合的处理平台).主流消息队列
  • Kafka
    • 集群架构、高可用、集群扩缩容、运维调优
  • Pulsar
    • 集群架构、存储层分析、特性介绍、HA&集群扩缩容
  • 周边和生态
    • SQL、IO、Schema

引用参考

内容主要参考了鲁仕林老师在「从 Kafka 到 Pulsar的数据流演进之路」课程里所教授的内容，同时也参考了学员手册里第三节的内容，图片来自于老师的PPT，链接如下：

  1. 【大数据专场 学习资料四】第四届字节跳动青训营 - 掘金 (juejin.cn)
  2. 从 Kafka 到 Pulsar- 数据流演进之路 - 鲁仕林 - ppt.pptx - 飞书文档 (feishu.cn)
avatar
文章
阅读
粉丝