关于 Apache Pulsar

Apache Pulsar 是 Apache 软件基金会尖端项目,是下一代云原生分布式音讯流平台,集音讯、存储、轻量化函数式核算为一体,选用核算与存储别离架构规划,支撑多租户、耐久化存储、多机房跨区域数据仿制,具有强一致性、高吞吐、低延时及高可扩展性等流数据存储特性。
GitHub 地址:github.com/apache/puls…

本文始发于 InfoQ,原文链接:www.infoq.cn/article/m5N…

金山云日志服务介绍

金山云创立于 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 硬核干货资料!