Apache Pulsar与Spark集成连接器：模式、差异及数据丢失问询

1. 连接器采用的接收模式 #

• org.apache.pulsar:pulsar-spark：基于Receiver-Based Approach，依赖Spark Streaming的Receiver组件建立长连接拉取Pulsar消息，由Spark的ReceiverTracker负责消息的接收与分发。
• io.streamnative.connectors:pulsar-spark-connector_2.12：采用Direct Approach，直接与Pulsar Broker交互获取消息，无需经过Receiver中间层，消息的消费进度由连接器直接管理。

2. 两款连接器的核心差异 #

• 维护主体与版本定位：前者是Apache Pulsar官方维护的早期适配组件，主要针对Spark 2.x版本；后者由StreamNative维护，主打Spark 3.x及以上版本的适配，是新一代的Pulsar-Spark集成方案。
• 架构与性能：Receiver-Based模式存在单点瓶颈风险，且需要额外资源维护Receiver；Direct Approach支持更高的并行度，消息处理延迟更低，资源利用率更优。
• 功能支持：后者支持Pulsar Schema Registry、事务消息、灵活的消息回溯等新特性，同时对Spark Structured Streaming的集成更完善；前者仅支持基础的Spark Streaming消息消费，功能相对有限。
• 容错机制：前者依赖Spark的WAL机制保障容错；后者直接基于Pulsar的cursor与Spark的checkpointing实现更可靠的容错逻辑。

3. 批次失败时的数据丢失风险 #

• org.apache.pulsar:pulsar-spark：
  • 若开启Spark的Write Ahead Log（WAL）机制，Receiver会先将消息写入WAL再交给处理逻辑，批次失败重启后可从WAL恢复数据，无丢失风险；
  • 未开启WAL时，Receiver故障可能导致未完成处理的消息丢失。
• io.streamnative.connectors:pulsar-spark-connector_2.12：
  • 只要正确配置了Spark的checkpointing，作业失败重启会从上次提交的Pulsar cursor位置继续消费，不会出现数据丢失；
  • 若未配置checkpointing，可能会出现重复消费，但不会丢失数据（因为未提交的cursor会保留未处理消息的位置）。

内容的提问来源于stack exchange，提问作者best wishes