从 Kafka 到 Pulsar的数据流演进之路笔记（二）| 青训营笔记
这是我参与「第四届青训营 -大数据场」笔记创作活动的第17天
三、Pulsar 详解
1. Pulsar 架构介绍
Pulsar客户端连接集群的两种方式：
- Pulsar Client -> Broker
- Pulsar Client -> Proxy
1.1 Pulsar Proxy
-
Pulsar Proxy的作用及应用场景
- 部分场景无法知道Broker地址，如云环境或者Kubernetes环境
- Proxy提供类似GateWay代理能力，解耦客户端和Broker，保障Broker安全
1.2 Pulsar Broker
-
Pulsar Broker无状态组件，负责运行两个模块
-
Http服务器
- 暴露了restful接口，提供生产者和消费者topic查找api
-
调度分发器
- 异步的tcp服务器，通过自定义二进制协议进行数据传输
-
-
Pulsar Broker 作为数据层代理
-
Bookie通讯
- 作为Ledger代理负责和Bookie进行通讯
-
流量代理
- 消息写入Ledger存储到 Bookie
- 消息缓存在堆外，负责快速响应
-
1.3 Pulsar Storage
-
Pulsar数据存储Segment在不同存储中的抽象
- 分布式Journal系统(Bookeeper)中为Journal/Ledger
- 分布式文件系统(GFS/HDFS)中为文件
- 普通磁盘中为文件
- 分布式 Blob存储中为Blob
- 分布式对象存储中为对象
-
定义好抽象之后，即可实现多介质存储
-
L1(缓存)：
- Broker使用堆外内存短暂存储消息
- 适用于Tail-Read读场景
-
L2(Bookkeeper)：
- Bookkeeper 使用Qurom写，能有效降低长尾，latency低
- 适用于Catch-Up较短时间内的较热数据
-
L3(S3等冷存)：
- 存储成本低，扩展性好
- 适用于Catch-Up长时间内的冷数据
1.4 Pulsar lO 连接器
- Pulsar lO 分为输入(Input)和输出（Output)两个模块，输入代表数据从哪里来，通过Source 实现数据输入。输出代表数据要往哪里去，通过Sink 实现数据输出。
- Pulsar提出了IO(也称为Pulsar Connector)，用于解决 Pulsar与周边系统的集成问题，帮助用户高效完成工作。
- 目前Pulsar lO支持非常多的连接集成操作：例如HDFS、Spark、Flink、Flume、ES、HBase等。
1.5 Pulsar Functions(轻量级计算框架)
- Pulsar Functions是一个轻量级计算框架，提供一个部署简单、运维简单、API简单的FAAS平台。
- Pulsar Functions提供基于事件的服务，支持有状态与无状态的多语言计算，是对复杂的大数据处理框架的有力补充。
- 使用Pulsar Functions，用户可以轻松地部署和管理function，通过function 从 Pulsar topic读取数据或者生产新数据到Pulsar topic。
2. Bookkeeper 介绍
2.1 Bookeeper 整体架构
2.2 Bookkeeper 基本概念
- Ledger：BK的一个基本存储单元，BK Client的读写操作都是以Ledger为粒度的
- Fragment：BK的最小分布单元(实际上也是物理上的最小存储单元)，也是 Ledger的组成单位，默认情况下一个Ledger会对应的一个Fragment(一个Ledger也可能由多个Fragment组成)
- Entry：每条日志都是一个 Entry，它代表一个 record，每条record都会有一个对应的entry id
2.3 新建 Ledger
- Ensemble：可以控制一个 Ledger 的读写带宽；
- Write Quorum：控制一条记录的复本数；
- Ack Quorum：写每条记录需要等待的 Ack 数 ，控制时延；
- 增加 Ensemble，可以增加读写带宽（增加了可写的机器数）；
- 减少 Ack Quorum，可以减长尾时延。
2.4 读/写一致性
- 写：每条记录会被 writer 赋予一个严格递增的 id，写成功更新Last-Add-Confirm指针。LAC 与 LAP（Pushed）差值为正在写数据
- 读：所有的 Reader 都可以安全读取 Entry ID 小于或者等于 LAC 的记录
2.5 读写分离
- 写入优化：写入时，不但会写入到Journal中还会写入到缓存(memtable)中，定期会做刷盘(刷盘前会做排序，通过聚合+排序优化读取性能)
- 读取优化：先读Memtable,没命中再通过索引读磁盘；Ledger Device中会维护一个索引结构，存储在RocksDB中，它会将(Ledgerld, Entryld) 映射到(EntryLogld,文件中的偏移量)
2.6 Bookkeeper with pulsar
- Partition<->Broker之间只是映射关系
- Broker在扩缩容的过程中只需要更改映射即可
3. Pulsar 功能介绍
3.1 生产模式
3.2 消费模式
3.2.1 Exclusive 消费模式
-
独占订阅(Stream流模型)
- 独占订阅中，在任何时间，一个消费者组(订阅)中有且只有一个消费者来消费Topic中的消息。
3.2.2 Failover 消费模式
-
故障切换(Stream流模型)
- 使用故障切换订阅，多个消费者(Consumer)可以附加到同一订阅。但是，一个订阅中的所有消费者，只会有一个消费者被选为该订阅的主消费者。其他消费者将被指定为故障转移消费者。
3.2.3 Shared 消费模式
-
共享订阅(Queue队列模型)
- 使用共享订阅，在同一个订阅背后，用户按照应用的需求挂载任意多的消费者。订阅中的所有消息以循环分发形式发送给订阅背后的多个消费者，并且一个消息仅传递给一个消费者。
3.2.4 Key_Shared 消费模式
-
按Key共享订阅(Queue队列模型)
- 使用共享订阅，在同一个订阅背后，用户按照应用的需求挂载任意多的消费者。订阅中的所有消息以key-hash发送给订阅背后的多个消费者，并且一个消息仅传递给一个消费者。
3.3 Pulsar 多租户
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
3.5 Pulsar GEO Relication
- 跨数据中心复制
- 消费其他地域数据
4. Pulsar HA & Scale-up
5. Pulsar vs Kafka
-
存储架构
- 存储计算分离之后带来的优劣势
- 多层架构，状态分离之后的优势
-
运维操作
- 应对突发流量变化，集群扩缩容是否便捷
- 运维任务是否影响可用性
- 集群部署是否灵活
-
功能特性
- 多语言&多协议
- 多租户管理
- 生产消费模式
-
生态集成
5.1 存储计算分离
-
分层架构优势
- 流量代理层和数据存储层解耦
- 流量代理层无状态,可快速扩缩容(k8s等弹性平台)
- 流量代理层可以对接海量的客户端连接
- 存储层负责数据存储，可以使用多级存储
-
计算层
- 对于写入的数据，可以做预处理，简单ETL
- 可以做数据缓存，应对高扇出度场景
- 无状态，扩缩容之后，能快速完成负载均衡Balance
-
存储层
- 按照数据冷热进行存储介质区分，降低成本
- 历史数据可海量保存，数据无价
- 可直接通过存储层接口读取数据，批式计算
四、课程总结
1. 消息队列概述
- 应用场景(从消息到消息、事件、流融合的处理平台)
- 主流消息队列
2. Kafka
- 集群架构、高可用、集群扩缩容、运维调优
3. Pulsar
- 集群架构、存储层分析、特性介绍、HA&集群扩缩容
4. 周边和生态
- SQL、IO、Schema
