Vergleich der verbleibenden Kandidaten
Nach der Ausschlussanalyse verbleiben Redpanda Connect und Apache NiFi als Kandidaten für die Pipeline Engine. Dieses Dokument vergleicht beide Lösungen systematisch gegen die Anforderungen.
Detaillierte Architekturskizzen: Redpanda Connect | Apache NiFi
Legende: ++ voll erfüllt | + erfüllt | o teilweise | - nicht erfüllt | -- kontraproduktiv
A) Funktionale Anforderungen
| Kriterium | Redpanda Connect | Apache NiFi |
|---|---|---|
| Cron / zeitgesteuerte Jobs | ++ (generate-Input mit Cron-Schedule) | ++ (CRON-driven Scheduling Processor) |
| Event-getriggerte Ausführung | ++ (Input-basiert, reagiert auf eingehende Nachrichten) | ++ (Event-Driven via ListenHTTP, ConsumeMQTT, etc.) |
| HTTP-Input / Webhooks | ++ (http_server Input, vollwertiger Request/Response) | ++ (ListenHTTP, HandleHttpRequest/Response) |
| MQTT-Input / MQTT-Output | ++ (mqtt Input/Output nativ) | ++ (ConsumeMQTT, PublishMQTT Prozessoren) |
| SQL-Input / SQL-Output | ++ (sql_select, sql_insert, sql_raw) | ++ (ExecuteSQL, PutDatabaseRecord, breite JDBC-Unterstützung) |
| Weitere Standard-Connectoren | ++ (>200 Konnektoren: Kafka, Redis, S3, GCP, Azure, etc.) | ++ (>300 Prozessoren: breitestes Ökosystem) |
| Datenrouting / Branching / Fan-out / Fan-in | ++ (switch, branch, workflow Prozessoren) | ++ (RouteOnAttribute, RouteOnContent, Funnels, Connections) |
| Transformationen (JSON, Mapping, Enrichment, Validierung) | ++ (Bloblang: mächtige Mapping-Sprache, JMESPath, JSON Schema) | + (JoltTransformJSON, EvaluateJsonPath, UpdateAttribute) |
| Stateful vs. stateless Verarbeitung | o (primär stateless; Cache-Prozessoren für einfachen State) | + (FlowFile-Attribute als State, verteilter Cache) |
| Replay / Backfill / Reprocessing | o (kein eingebauter Replay; manuell über erneuten Input) | + (Provenance-basierter Replay einzelner FlowFiles) |
| Retry / Dead-Letter / Fehlerbehandlung | ++ (retry, DLQ-Output, max_in_flight, Backoff-Config) | ++ (Penalty/Failure-Routing, Retry auf Connection-Level) |
| Batch und Streaming | ++ (Streaming-first, Batching über Windowing/Buffering) | ++ (Micro-Batch/Streaming, FlowFile-Batching, Backpressure) |
| Versionierung / Deploybarkeit | ++ (YAML-basiert, versionierbar in externer Registry) | + (NiFi Registry für Flow-Versionierung, JSON-Export) |
| Erweiterbarkeit um eigene Prozessoren | + (Custom Plugins in Go, WASM-Prozessoren) | + (Custom Processors in Java, NAR-Bundles) |
| Exactly-once & In-order Processing | o (at-least-once Standard; exactly-once nur mit Kafka) | o (at-least-once; exactly-once nur mit Transaktionsfähigen Quellen) |
B) Nicht-funktionale Anforderungen
| Kriterium | Redpanda Connect | Apache NiFi |
|---|---|---|
| Horizontale Skalierbarkeit | + (Worker-Pod-Pool mit HPA, Provisioner verteilt Pipelines) | + (NiFi Cluster mit eigener Leader Election) |
| High Availability | o (Stateless, HA über K8s-Replicas + Provisioner-Redistribution) | ++ (natives Clustering mit automatischer Leader Election) |
| Isolation der Ausführung | o (OS-Prozess-Isolation innerhalb shared Pods; schwächer als Container) | o (Process Groups, aber alles in einer JVM) |
| Ressourcenkontrolle / Limits | o (K8s Limits auf Pod-Ebene; pro-Prozess-Limits nur über cgroups/Supervisor) | o (Begrenzt: Thread-Pools, aber keine feingranulare Kontrolle) |
| Backpressure / Lastverhalten | + (max_in_flight, Buffering, Rate-Limiting) | ++ (Backpressure auf Connection-Level, Queue-Thresholds) |
| Beobachtbarkeit (Logs, Metriken, Traces) | ++ (Prometheus-Metriken, strukturierte Logs, OpenTelemetry) | + (Bulletin Board, Provenance, JMX-Metriken, Prometheus via Reporter) |
| Security / RBAC / Secrets | o (keine eigene RBAC; Secrets via Env-Vars/Vault) | ++ (eingebaute RBAC, Policy-basiert, User/Group-Management, native Integration von Vault o.ä.) |
| Kubernetes-native | ++ (einfacher Container, Helm Chart, kein Operator nötig) | ++ (Helm Chart, StatefulSet, kein CRD nötig) |
| On-Prem-Betrieb | ++ (Single Binary, minimale Abhängigkeiten) | ++ (Self-contained, Java Runtime) |
| Air-gapped / souveräner Betrieb | ++ (keine externen Abhängigkeiten zur Laufzeit) | ++ (keine externen Abhängigkeiten zur Laufzeit) |
| Erweiterbarkeit / Plugin-Modell | + (Go Plugins, WASM, Subprocess) | + (Java NAR Bundles) |
C) Developer- und Operator-Kriterien
| Kriterium | Redpanda Connect | Apache NiFi |
|---|---|---|
| YAML / Code-first | ++ (rein YAML + Bloblang) | + (Process Groups filebasiert, über Registry versionierbar) |
| Lernkurve | ++ (einfache Konzepte: Input > Pipeline > Output) | + (mächtig, aber steile Lernkurve) |
| Testbarkeit | ++ (Unit-Tests via CLI: rpk connect test) | o (schwierig, kein nativer Test-Modus) |
| Debugging | + (Logs, Tracing, lokale Ausführung) | + (Data Provenance, FlowFile-Inspektion im UI, Schrittweise Steuerung) |
| Reife des Betriebsmodells | + (wachsend, Redpanda als Company dahinter) | ++ (>10 Jahre, Apache Top-Level, viele Produktions-Referenzen) |
| Dokumentationsqualität | ++ (exzellente Docs, viele Beispiele) | + (umfangreich, aber teils veraltet/unübersichtlich) |
| K8s Namespace mit limitierten Rechten | ++ (einfaches Deployment, kein CRD, kein ClusterRole) | ++ (StatefulSet, kein CRD; Headless Service für Clustering) |
| Helm-Deployment | ++ (offizielles Helm Chart) | + (Community Helm Charts, kein offizielles Apache Chart) |
D) Community- und Reifegrad-Kriterien
| Kriterium | Redpanda Connect | Apache NiFi |
|---|---|---|
| GitHub Stars | ~8k (unter redpanda-data/connect) | ~5k (apache/nifi) |
| Contributor | ~200 (inkl. Benthos-Historie) | ~500+ (Apache Community) |
| Letzter Commit | aktiv (wöchentlich) | aktiv (wöchentlich) |
| Aktivität (12 Monate) | hoch | hoch |
| Release-Frequenz | monatlich | quartalsweise |
| Lizenzmodell | Apache 2.0 | Apache 2.0 |
| Projektreife / Governance | mittel (Redpanda Inc.) | hoch (Apache Foundation, >10 Jahre) |
| Community-Stärke | mittel-hoch (Slack, Docs, Tutorials) | hoch (großes Ökosystem, Konferenzen, Bücher) |
E) Performance- und Architektur-Kriterien
| Kriterium | Redpanda Connect | Apache NiFi |
|---|---|---|
| Eignung für hohe Eventraten | ++ (Go-basiert, geringer Overhead) | + (Java, höherer Overhead, aber optimierbar) |
| Eignung für niedrige Latenzen | ++ (Sub-Millisekunde möglich) | + (FlowFile-Overhead, typisch ms-Bereich) |
| Overhead pro Pipeline / Task | ++ (ca. 10-30 MB RAM pro Prozess, viele Prozesse pro Pod) | -- (4-8 GB RAM für die gesamte NiFi-Instanz) |
| Eignung für kleine Payloads | ++ (optimiert für Message-Processing) | + (FlowFile-Overhead, aber akzeptabel) |
| Eignung für große Payloads | + (Streaming-Modus für große Dateien) | ++ (Content Repository, Streaming, Backpressure) |
| Stateful Streaming | o (begrenzt, Cache-basiert) | + (verteilte Map-Caches, Stateful Processors) |
| Einfache Integrationsflüsse | ++ (perfekt geeignet, minimaler Boilerplate) | + (möglich, aber Overhead durch UI/Konfiguration) |
| Komplexe Datenströme | + (Workflows, Sub-Pipelines, aber limitiert) | ++ (beliebig komplexe Graphen, Process Groups) |
Zusammenfassung
| Dimension | Redpanda Connect | Apache NiFi |
|---|---|---|
| Stärken | Leichtgewichtig, Code-first, Bloblang, geringe Ressourcen pro Pipeline, exzellente Dev-Experience | Breiteste Konnektoren, eingebaute RBAC, Backpressure, Provenance, bewährt (>10 Jahre), HA-Clustering |
| Schwächen | Keine RBAC, keine UI, begrenzt stateful, Isolation nur auf Prozess-Ebene (shared Pod), hoher Eigenentwicklungsanteil (Provisioner + Supervisor) | Ressourcenhungrig (4-8 GB Baseline), steile Lernkurve, keine echte Pipeline-Isolation (shared JVM) |
| Bester Fit | Leichtgewichtige, hochperformante Integrationspipelines mit IoT/MQTT-Fokus und Code-first-Ansatz | Komplexe Datenflüsse mit Audit-Anforderungen, breiter Konnektivität und eingebauter Zugriffskontrolle |
| Eigenentwicklung | Hoch (Provisioner, Supervisor, RBAC) | Niedrig (Configuration-Adapter, RBAC-Mapping) |
Detaillierte Architekturskizzen: Redpanda Connect | Apache NiFi
Ausgeschlossene Optionen: ruled_out.md (inkl. Kestra -- Open-Core-Lizenz, RBAC/SSO nur in Enterprise)