Apache Pulsar 为滴滴大数据运维带来了哪些收益？

Apache Pulsar 是 Apache 软件基金会顶级项目，是下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体。该系统源于 Yahoo，最初在 Yahoo 内部开发和部署，支持 Yahoo 应用服务平台 140 万个主题，日处理超过 1000 亿条消息。Pulsar 于 2017 年由 Yahoo 开源并捐赠给 Apache 软件基金会进行孵化，2018 年成为 Apache 软件基金会顶级项目。

滴滴大数据于 2021 年 01 月开始调研 Pulsar ，建立内部 Pulsar 2.7 版本分支；并于 2021 年 08 月 04 日，正式上线了第一个 Pulsar 数据通道同步任务集群，主要为数据开发平台-同步中心产品提供服务，涉及 Log->ES、BamaiLog->ES、BamaiLog->CK、Log->HDFS 链路。截止目前，已稳定运行两年有余。

引入 Pulsar 的收益

滴滴大数据 DKafka 集群，基于社区 2.12-0.10.2.0 版本。在运维过程中，遇到了不少痛点，如磁盘 IO 不均、存储容量不均、CPU 利用率不均等负载不均问题，尤其是在高峰期出现瓶颈或故障发生后，想要快速扩容止损成为了一个棘手的问题。尽管团队已经在自动化运维方面做出了不少努力，比如实施了根据磁盘 IO 负载自动调整分区、批量自动迁移计划、以及存储自动负载均衡等措施，但仍需耗费大量的人力来维护这个重度运维的系统。

Pulsar 的出现，为滴滴大数据消息系统带来了新的可能性。特别是对于当前我们所遇到的痛点，Pulsar 提供了一些优雅的解决方案。

解决 SATA HDD 盘的磁盘 IO 瓶颈问题

DKafka 采用分段式 appendlog 顺序写入方式，将分区消息落盘。但是当 Broker 上有成百上千个 topic partition 时，由于需要切换分区消息写入到对应分区 log 文件，从磁盘角度看就变回了随机写入，磁盘读写性能将会随着 Broker 上 topic partition 数量的增加而降低，用户感知现象为生产/拉取耗时增涨。

DKafka 集群运维管理员接不完的 io 热点报警

Pulsar 存算分离架构，存储层 Bookie 在存储数据时，通过将不同分区的消息在内存中排序后定期顺序刷盘到同一个entrylog 文件中，再通过 rocksdb 索引组织 entrylog 中的消息与分区 segment 的映射关系，解决随机写入问题。因此 Pulsar 号称可以支持百万分区，不会因为随机写而导致性能急剧下降。

解决集群容量瓶颈问题

针对 DKafka 集群中存在的 IO 瓶颈问题，数据通道团队自2020年至2021年间对线上集群进行了 SSD 机型置换。然而，除部分集群间的数据同步极端场景外，如磁盘故障后拉起服务，仍可能出现大量消息落盘行为集中在一台硬盘上的情况。考虑到 SSD 成本较高，团队决定降低集群存储容量，导致集群不再满足原有的3副本36小时存储周期要求。经过调研用户需求，团队决定将副本数调整为2，并将存储周期改为24小时，以满足大多数用户的需求。对于仍需更长存储周期的用户，可由用户发起申请，SRE 协助单独调整存储周期。尽管如此，仍然存在大量的磁盘热点/单机热点，需要 DKafka 集群运维管理员进行负载均衡。

DKafka 集群中多块盘存储容量达到瓶颈

由于 Pulsar 存储层在存储数据时，一定是顺序存储的，所以 Pulsar 机型在选型时，可以选择大容量 SATA HDD 盘 + NVME 异构机型，NVME 盘主要作为存储层 journal 和存储层 index 即内嵌 rocksdb 的存储介质。参照原 DKafka 的全 SSD 数据盘机型，Pulsar 存储异构机型，在降低成本的情况下，还能延长存储周期，增加副本数。

解决缓存 / IO 未隔离问题

在使用 DKafka 的过程中，重置 topic 的消费组 offset 是常见操作，但这会导致磁盘读取增加，进而加重磁盘 IO 的工作负载。由于 DKafka 的 IO 没有隔离，因此读取操作也会影响写入，从而导致读写耗时显著增长。此外，集群的扩容、缩容以及磁盘故障后屏蔽故障盘数据目录再上线的操作，也会对 pagecache 系统页缓存造成污染，导致更多的读消息 cache miss࿰