对于 Apache Pulsar
Apache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。
GitHub 地址：http://github.com/apache/pulsar/

本文始发于 InfoQ，原文链接：https://www.infoq.cn/article/…

金山云日志服务介绍

金山云创建于 2012 年，是中国前三的互联网云服务商，2020 年 5 月在美国纳斯达克上市，业务范围遍布寰球多个国家和地区。成立 8 年以来，金山云始终保持以客户为核心的服务理念，提供平安、牢靠、稳固、高品质的云计算服务。

金山云曾经在北京、上海、广州、杭州、扬州、天津等国内地区，以及美国、俄罗斯、新加坡等国内区域设有绿色节能数据中心及经营机构。将来，金山云将继续立足外乡、放眼国内，通过构建寰球云计算网络，连通更多设施和人群，让云计算的价值惠及寰球。

金山云日志服务是针对日志类数据处理的一站式服务零碎，提供从日志采集、日志存储到日志检索剖析、实时生产、日志投递等多项服务，撑持着多个业务线的日志查问和监控业务，晋升金山云各个产品线的运维、经营效率，目前每天数据量级在 200 TB。

日志服务的性能个性

作为针对日志类数据处理的一站式服务零碎，金山云日志服务须要具备以下个性：

• 数据采集：基于 Logstash 和 Filebeat 进行定制开发，反对更多数据采集状态。
• 数据查问：反对 SQL 和 ElasticSearch Query String 语法。
• 数据生产：基于 Pulsar 对外部 socket 进行封装，有些产品线（想在控制台展现日志滚动的场景）能够通过整个日志服务的 websocket 协定实现；也能够通过裸露的 REST API 查问全副日志数据（即作为队列来应用）。
• 异样告警：在控制台检索数据后，把数据以及检索语法保留为告警项，反对配置整体的告警策略及告警形式。检索到异样后，后盾会通过启动相应的工作实现实时告警。
• 图表展现：将在控制台检索的语句和查问后果保留为图表（柱状图、折线图等），再次进入控制台时，点击仪表盘即可看到以后或之前保留过的所有查问语句和后果数据。
• 数据异构：能够自定义是否把日志投递到其余云端产品线中，比方将某几个日志的数据投递到对象存储中，从而实现一些其余操作（如把数据投递到 Hive 数仓，再进行剖析）。

为什么抉择 Pulsar

在调研过程中，咱们从根底性能和可靠性两方面比照了 RocketMQ、Kafka 和 Pulsar，并总结了三者的优缺点（比照后果见下表）。

咱们发现 Pulsar 非常适合利用于日志流解决。从 BookKeeper 层面来讲，Pulsar 就是日志流存储的组件。Pulsar 采纳云原生架构，日志流服务同样采纳云原生、无服务模式，所有服务都在云上实现。Pulsar 领有诸多灵便的企业级个性，比方反对多租户、反对租户存储配额、数据 ETL、整体数据负载平衡策略等；反对传输大量数据；针对音讯队列的监控比较完善等。上面我来具体介绍下咱们抉择 Pulsar 的一些个性。

计算与存储拆散

Pulsar 的 producer 和 consumer 都与 broker 相连接，broker 作为无状态服务，能够横向扩缩容，扩缩容时不会影响数据的整体生产和生产；broker 不存储数据，数据存储在 broker 的下一层（即 bookie）中，实现了计算与存储的拆散。

弹性程度扩缩容

对于云端产品而言，Pulsar 无需重均衡即可实现 broker 扩缩容。相比之下，Kafka 扩缩容前须要先进行重均衡操作，可能会导致集群负载较高，也会对整体服务产生影响。其次，Pulsar topic 分区也能够实现有限扩容，扩容之后，通过负载平衡策略主动均衡整个分片和流量。

Pulsar 多租户

Pulsar 原生反对多租户。在日志服务中也有租户的概念，每一条产品线（即每一个我的项目）属于一个租户，实现了产品线之间的数据隔离。Pulsar 集群反对数百万个 topic（在雅虎已有实际），整个 topic 也通过租户实现了隔离，在租户级别，Pulsar 实现了存储配额、音讯过期删除、隔离策略等优良个性，且反对独自的认证和受权机制。

负载平衡策略

Pulsar 在命名空间级别有 bundle 的概念，如果以后 broker 负载较高，bundle 会通过治理 topic 分区策略进行 bundle split 操作，主动将子分区平衡到其余负载较低的 broker 上。在创立 topic 时，Pulsar 也会主动把 topic 优先调配到以后负载较低的 broker 上。

Pulsar IO 模型

写入操作中，broker 并发向 BookKeeper 写入数据；当 bookie 向 broker 反馈数据写入胜利时，在 broker 层面，外部只保护一个队列。如果以后的生产模式是实时生产，则能够间接从 broker 获取数据，无需通过 bookie 查问，从而晋升音讯吞吐量。在追赶读场景中，查问历史数据才须要查问 bookie；追赶读还反对数据卸载性能，行将数据卸载到其余存储介质中（比方对象存储或 HDFS），实现冷存历史数据。

Topic 创立、生产与生产

在控制台创立 topic 后，将 topic 信息和租户信息记录到 etcd 和 MySQL 中，而后图示右侧的两类服务会监听 etcd，一类是 producer 类服务，监听创立或删除 topic 后的外部操作。另一类是 consumer 类服务，当监听到创立新 topic 操作后，对应的服务会连贯到 Pulsar topic，实时生产 topic 上的数据。而后 producer 开始接收数据，并判断应该向哪个 topic 写入数据，consumer 生产数据并在判断后写入，或转存再写入到其余 ES 或其余存储中。

Topic 逻辑形象

Pulsar 中有三个级别：topic、命名空间和租户。因为 Pulsar 目前不反对命名空间级别的正则生产模式，所以咱们须要把整体概念往上提一层，缩小后盾 Flink 的任务量，实现整个我的项目级别的生产。也就是说，在日志服务中，topic 对应 Pulsar 逻辑上的分片，命名空间对应 Pulsar 逻辑上的 topic。通过这一改变，咱们实现了两个性能，一是动静减少和缩小分片数量，二是在后盾启动的 Flink 工作能够生产单个我的项目级别的数据。

音讯订阅模型

Pulsar 提供四种音讯订阅模型：

1. 独占模式（Exclusive）：当有多个 consumer 应用同一个订阅名称订阅 topic 时，只有一个 consumer 能够生产数据。
2. 故障转移模式（Failover）：当多个 consumer 通过同一个订阅名称订阅 Pulsar topic 时，如果某一个 consumer 呈现故障或连贯中断，Pulsar 会主动切换到下一个 consumer，实现单点生产。
3. 共享模式（Shared）：利用比拟宽泛的一个模型，如果启动多个 consumer，但只通过一个订阅者订阅 topic 信息，Pulsar 会通过轮询形式顺次向 consumer 发送数据；如果某一个 consumer 宕机或连贯中断，则音讯会被轮询到下一个 consumer 中。LogHub 应用的就是共享订阅模型，整个 Hub 运行在容器中，能够依据整体负载或其余指标动静扩缩容生产端。
4. Key_Shared 音讯订阅模式：通过 Key 哈希形式保持数据生产的一致性。

Broker 故障复原

因为 broker 无状态，所以某一个 broker 宕机对整体的生产和生产没有任何影响，同时会有一个新 broker 负责 owner 角色，从 ZooKeeper 中获取 topic 元数据，并主动演进到新 owner 中，数据的存储层也不会发生变化。此外，无需拷贝 topic 内的数据，防止数据冗余。

Bookie 故障复原

Bookie 层应用分片存储信息。因为 bookie 自身有多正本机制，当某个 bookie 呈现故障时，零碎会从其余 bookie 读取对应分片的信息，并进行重均衡，因而整个 bookie 的写入不会受到影响，保障整个 topic 的可用性。

Pulsar 在日志服务中的利用

日志服务零碎的最底层是数据采集工具，咱们基于开源的数据采集工具（如 Logstash、Flume、Beats）进行了定制化开发。数据存储中日志池是一个逻辑概念，对应于 Pulsar 中的 topic。日志服务零碎的下层为查问剖析和业务利用，查问剖析指在日志服务的工作台进行检索剖析，或通过 SQL 语法进行查问；业务利用指在控制台定制仪表盘和图表，实现实时告警等。查问剖析和业务利用都反对数据转存，即把日志数据转存到存储介质或价格较低的存储设备中，如基于 KS3 的对象存储、ElasticSearch 集群或 Kafka。日志服务的产品性能详情如下图。

日志服务架构设计

咱们依据日志服务的产品功能设计了日志服务的分层架构（如下图）。最上层为数据采集端，负责采集日志类文本数据、TP/TCP 协定数据、MySQL 中的日志数据等，咱们自研的采集端开发工作仍在进行中。采集到的数据通过日志服务的数据入口发送到对应的 Pulsar topic 中。咱们将 Pulsar 集群利用于三大板块，一是通过 Flink-on-Pulsar 框架实现多维统计分析场景，因为有些业务线须要通过日志数据做多维度的聚合统计，产生指标后果类数据，再转存给业务线。二是将 Pulsar 集群利用于 LogHub（微服务化服务），次要生产 Pulsar topic 的数据，将数据间接写入到 ES，通过控制台即可查问整个日志流的数据，也能够做检索剖析。三是在管制台上应用 Pulsar Functions 设置一些算子或 ETL 逻辑，后盾通过 Pulsar Functions 模块做数据 ETL。咱们采纳 EalsticSearch 集群存储数据检索剖析后果，KS3、KMR、KES 对应于咱们外部的一些云端产品线，用于存储和计算。下层的数据输入局部能够分为两大模块，一是 Search API 模块，负责对外提供 API，通过调用 API 在控制台进行一些和日志严密耦合的动作；二是 Control API 模块，反对在控制台进行治理类操作，比方创立 topic、调整 topic 的分区数量、检索告警等。

日志服务的通信设计

从日志服务的产品架构来讲，整个服务采纳无状态运行模式，所以各类服务（特地是 producer 和 consumer 服务）通过 etcd 形式实现数据共享。也就是说，在控制台执行创立、更新、删除操作后，producer 和 consumer 就会感知到这些动作，从而进行相应的变动。此外，因为 producer 和 consumer 齐全在容器中运行，且服务自身无状态，因而能够进行动静扩缩容。日志服务的通信设计图如下。

日志流解决架构

依据日志流解决的需要，咱们设计了如下架构图。右边为数据采集端，采集端把数据发送给数据接收端（PutDatas），接收端再把数据发送给对应的 Pulsar topic。咱们将 Pulsar 次要利用于三个场景。

1. 在 Pulsar 上增加 Flink 程序，实现定制化的 ETL 多维分析、统计、聚合等操作。
2. 在 LogHub 应用 Pulsar 生产和存储数据。从 Pulsar 生产数据后，把采集到的日志数据写入到 ElasticSearch 集群。
3. 在 WebSocket 和 REST API 上应用 Pulsar。WebSocket 实现了在控制台查看实时滚动的日志，REST API 反对查问特定队列中的数据。同时咱们通过 Pulsar Functions 实现了一些简略的 ETL 解决，将解决后的数据转存到业务线的存储介质中（比方转存到数仓、Kafka 或 ElasticSearch 集群）。

将来布局

在 Pulsar 的撑持下，金山云日志服务始终运行良好。咱们期待日志服务能够反对更多功能，实现更多需要。在日志服务方面，咱们的布局如下：

• 新增程序生产能力（账单、审计场景可能须要程序生产能力）。
• 合并和决裂分区。
• 实现齐全容器化部署。目前日志服务的外部服务曾经实现了容器化操作，下一步咱们会集中实现所有 Pulsar 集群的容器化部署。

目前，日志服务撑持金山云外部产品线约 15 条（如下图），单条线上数据传输大略为 200 TB/ 天，topic 数量已超过 3 万个。当 AI 业务接入 Pulsar 当前，整体数据量和 topic 数量都会有大幅度晋升。

在测试和应用过程中，咱们对 Pulsar 有了更全面的理解，期待 Pulsar 能够反对更多个性，比方：去除对 ZooKeeper 的依赖。目前由 ZooKeeper 保护 Pulsar 的所有元数据，压力较大；且 Pulsar 的 topic 数量强制依赖 ZooKeeper 集群。如果将 Pulsar 元数据信息存储在 bookie 中，即可实现 topic 数量的有限减少。

主动扩缩容分区。日志类数据有顶峰和低谷，在顶峰时，把以后 topic 的分区数量主动进行扩容，晋升整体并发量；在低谷时，将分区数量进行缩容，加重集群资源的压力。

提供命名空间级别的正则匹配。在后盾的 Flink 工作中，不再监听命名空间级别的数据，升高 Flink 的后台任务量。

结 语

作为下一代云原生分布式音讯流平台，Apache Pulsar 有其独特的劣势，非常适合咱们的日志流解决场景。Pulsar 社区十分沉闷，有问必答。咱们在后期调研、后续测试和正式上线过程中，StreamNative 的小伙伴们给予了极大反对，帮忙咱们疾速推动业务上线。

目前，金山云日志服务中有 3 万多个 Pulsar topic，每天解决约 200 TB 数据，撑持 15 条产品线。自上线以来，Pulsar 运行状态稳固，大大节俭了咱们的开发和运维老本。咱们期待尽快实现 Pulsar 集群的容器化部署，也期待 Pulsar 能够去除对 ZooKeeper 的依赖，反对主动扩缩容分区。咱们违心和 Pulsar 社区的小伙伴们一起开发新性能，进一步放慢 Pulsar 的倒退。

作者简介
刘彬，金山云大数据高级开发工程师。

相干浏览

• 最佳实际|放弃 Ceph，Salesforce 应用 Apache BookKeeper 在云中实现最强存储
• 最佳实际|Apache Pulsar 在拉卡拉的技术实际
• 最佳实际|Apache Pulsar 在华为云物联网之旅

点击链接，获取 Apache Pulsar 硬核干货材料！