Apache Pulsar vs Kafka porównanie

Wybór platformy do streamingu danych to jedna z najważniejszych decyzji architektonicznych w nowoczesnych systemach. Przez lata Apache Kafka było praktycznie jedyną opcją dla enterprise message streaming. Ale od 2016 roku Apache Pulsar zyskuje coraz większą popularność, obiecując rozwiązanie problemów, które Kafka ma od lat. Czy warto przeskoczyć na Pulsar, czy zostać przy sprawdzonym Kafka?

Dlaczego porównanie ma sens w 2019 roku

W 2019 roku jesteśmy w kluczowym momencie – Kafka ma 10 lat i jest dojrzałą platformą z ogromnym ekosystemem, ale także z bagażem legacy rozwiązań. Pulsar ma 3 lata jako projekt Apache i wprowadza nowoczesne podejście do architektury. To idealny moment, żeby porównać oba rozwiązania zanim podjąć decyzję o długoterminowej strategii.

Architektura – fundamentalne różnice

Kafka: Broker-centric architecture

Kafka używa klasycznej architektury, gdzie broker jest odpowiedzialny za wszystko – przyjmowanie wiadomości, storage, replikację i serwowanie konsumentów:

# Kafka cluster - typowa konfiguracja 3 brokerów
kafka-broker-1: storage + compute + coordination
kafka-broker-2: storage + compute + coordination  
kafka-broker-3: storage + compute + coordination

Pulsar: Layered architecture

Pulsar rozdziela warstwy – brokery obsługują tylko compute, a storage jest w oddzielnych BookKeeper nodes:

# Pulsar cluster - separacja warstw
pulsar-broker-1: compute only (stateless)
pulsar-broker-2: compute only (stateless)
pulsar-broker-3: compute only (stateless)

bookkeeper-1: storage only
bookkeeper-2: storage only  
bookkeeper-3: storage only

Wydajność i throughput

Skalowalność i operacje

Kafka – challenges ze skalowaniem

Główne wyzwanie Kafka to rebalancing partycji. Dodanie nowego brokera wymaga ręcznego przeniesienia partycji:

# Kafka - dodanie nowego brokera
kafka-reassign-partitions.sh --zookeeper localhost:2181 \
  --reassignment-json-file reassign.json --execute

# Może trwać godziny dla dużych topicków

Pulsar – automatic load balancing

Pulsar automatycznie balansuje load między brokerami bez przestojów:

# Pulsar - nowy broker automatycznie przejmuje traffic
pulsar-admin brokers list
# Nowy broker pojawia się natychmiast w load balancing

Multi-tenancy i izolacja

Kafka – ograniczone wsparcie

Kafka ma podstawowe wsparcie dla multi-tenancy przez quota i ACLs, ale brakuje mu prawdziwej izolacji:

# Kafka quotas - ograniczone możliwości
kafka-configs.sh --zookeeper localhost:2181 --alter \
  --add-config 'producer_byte_rate=1024000' \
  --entity-type clients --entity-name tenant1

Pulsar – native multi-tenancy

Pulsar ma wbudowaną hierarchię: tenant → namespace → topic z pełną izolacją:

# Pulsar - kompletna izolacja tenantów
pulsar-admin tenants create company-a
pulsar-admin namespaces create company-a/production
pulsar-admin namespaces create company-a/staging

# Każdy tenant ma własne quotas, ACLs, geo-replication

Geo-replikacja i disaster recovery

Kafka – MirrorMaker challenges

Kafka używa MirrorMaker do replikacji między clusterami, ale ma ograniczenia:

# MirrorMaker - podstawowa replikacja
kafka-mirror-maker.sh --consumer.config consumer.properties \
  --producer.config producer.properties --whitelist '.*'

Pulsar – built-in geo-replication

Pulsar ma wbudowaną geo-replikację z guaranteed ordering:

# Pulsar geo-replication
pulsar-admin namespaces set-clusters company-a/production \
  --clusters us-east,us-west,eu-central

# Automatyczna replikacja z zachowaniem kolejności

Ecosystem i narzędzia

Kafka – dojrzały ekosystem

Kafka ma ogromny ekosystem buildowany przez 10 lat:

• Kafka Connect: 100+ gotowych connectorów
• Kafka Streams: mature stream processing
• KSQL: SQL for streaming data
• Schema Registry: Confluent i inne
• Monitoring: Kafka Manager, Kafdrop, Confluent Control Center

Pulsar – rozwijający się ekosystem

Pulsar ma podstawowe narzędzia, ale ekosystem jest jeszcze młody:

• Pulsar IO: ~30 connectorów (rosnące)
• Pulsar Functions: serverless compute
• Pulsar SQL: Presto integration
• Pulsar Manager: web UI do zarządzania
• BookKeeper: proven storage layer (używany przez DistributedLog)

Przypadki użycia – kiedy używać czego

Wybierz Kafka gdy:

Wybierz Pulsar gdy:

Deployment i operacje

Kafka deployment

# Kafka - typowa konfiguracja produkcyjna
# server.properties
num.network.threads=8
num.io.threads=16
socket.send.buffer.bytes=102400
socket.receive.buffer.bytes=102400
log.retention.hours=168
log.segment.bytes=1073741824
num.partitions=3
default.replication.factor=3

Pulsar deployment

# Pulsar - konfiguracja brokera
# broker.conf
zookeeperServers=zk1:2181,zk2:2181,zk3:2181
configurationStoreServers=zk1:2181,zk2:2181,zk3:2181
clusterName=pulsar-cluster
brokerServicePort=6650
webServicePort=8080
managedLedgerDefaultEnsembleSize=3
managedLedgerDefaultWriteQuorum=2
managedLedgerDefaultAckQuorum=2

Migracja i coexistence

Nie musisz wybierać jednego rozwiązania od razu. Możliwe strategie:

Stopniowa migracja

// Dual write pattern - pisz do obu systemów
@Service
public class EventPublisher {
    private final KafkaTemplate kafkaTemplate;
    private final PulsarTemplate