Architekturskizze: Apache NiFi
Dieses Dokument beschreibt, wie die Anforderungen mit Apache NiFi architektonisch umgesetzt werden.
Siehe auch: Vergleich mit Redpanda Connect | Architekturskizze Redpanda Connect
Architekturübersicht
Kernprinzip: Ein NiFi-Cluster (StatefulSet) mit mehreren Nodes.
Pipelines werden als Process Groups innerhalb des Clusters modelliert. Isolation erfolgt über NiFi-interne Policies (RBAC), nicht über Container-Grenzen -- alle Process Groups teilen sich eine JVM.
NiFi-Konzepte
Process Groups
Eine Process Group ist NiFis zentrale Organisationseinheit -- vergleichbar mit einem Namespace oder Ordner. Sie kapselt eine Menge von Prozessoren, Connections und ggf. verschachtelte Sub-Process-Groups zu einer logischen Einheit.
Für Civitas bedeutet das: Jedes DataSet bekommt eine eigene Process Group. Innerhalb dieser Process Group liegen alle Prozessoren, die zu diesem DataSet gehören (MQTT-Consumer, Transformationen, SQL-Writer, etc.). Bei Bedarf können weitere Sub-Process-Groups genutzt werden, um Pipelines innerhalb eines Datasets zu trennen.
Eigenschaften:
- Zugriffssteuerung: Jede Process Group hat eigene Policies (View, Modify, Operate). Damit lässt sich steuern, welcher User/Gruppe welche Pipeline sehen, bearbeiten oder starten darf.
- Versionierung: Process Groups können über eine externe Registry versioniert werden (Import/Export als Flow-Snapshot via NiFi Registry oder JSON-Export).
- Verschachtelung: Process Groups können beliebig geschachtelt werden, z.B. eine übergeordnete Gruppe pro DataPool mit Sub-Groups pro DataSet.
- Input/Output Ports: Process Groups kommunizieren untereinander über explizite Input- und Output-Ports -- das macht Datenflüsse zwischen DataSets sichtbar und kontrollierbar.
Einschränkung: Process Groups sind eine logische Grenze, keine technische. Alle Process Groups laufen im selben JVM-Prozess, teilen sich Speicher und Thread-Pools. Es gibt keine Container- oder Prozess-Isolation zwischen ihnen.
FlowFiles
Ein FlowFile ist die Dateneinheit, die durch NiFi fließt. Es besteht aus:
- Content: Die eigentlichen Nutzdaten (z.B. ein JSON-Dokument, eine CSV-Zeile, ein Binär-Blob).
- Attributes: Key-Value-Metadaten (z.B.
filename,mqtt.topic,http.status.code, oder eigene Attribute).
Jeder Prozessor empfängt FlowFiles, verarbeitet sie und gibt neue FlowFiles aus. NiFi verwaltet den Content im Content Repository auf Disk, sodass auch große Payloads verarbeitet werden können, ohne den JVM-Heap zu belasten.
Controller Services
Controller Services sind gemeinsam genutzte Ressourcen wie Datenbankverbindungspools (DBCPConnectionPool), SSL-Kontexte oder Record-Reader/Writer. Sie werden auf Process-Group-Ebene definiert und stehen allen Prozessoren innerhalb dieser Gruppe zur Verfügung. Für Civitas relevant: Ein JDBC-Connection-Pool pro DataSet-Process-Group, der die Datenbankzugangsdaten kapselt.
Umsetzung der Anforderungen
Pipeline-Varianten
| Anforderung | Umsetzung |
|---|---|
| Cron/Scheduler | CRON-driven Scheduling Strategy auf Prozessoren (z.B. GenerateFlowFile oder ExecuteSQL mit CRON-Timer). |
| Ereignisgetriebene Verarbeitung (MQTT) | ConsumeMQTT-Prozessor subscribt auf Topics. Daten fließen als FlowFiles durch die Pipeline. |
| Ereignisgetriebene Verarbeitung (Webhook) | ListenHTTP-Prozessor empfängt POST-Requests und erzeugt FlowFiles. |
| HTTP-Endpunkte (Request/Response) | HandleHttpRequest + HandleHttpResponse-Prozessor-Paar für synchrones Request/Response. |
| Batch-Verarbeitung | ExecuteSQL + QueryDatabaseTable für Bulk-Reads, MergeContent für Batching. |
| Stream-Verarbeitung | Kontinuierlicher FlowFile-Fluss: Prozessoren verarbeiten FlowFiles sofort nach Eingang. |
Konnektoren
| Anforderung | Umsetzung |
|---|---|
| MQTT | ConsumeMQTT, PublishMQTT (v3.1.1 + v5) |
| HTTP | InvokeHTTP (ausgehend), ListenHTTP, HandleHttpRequest/Response (eingehend) |
| SQL | ExecuteSQL, QueryDatabaseTable, PutDatabaseRecord, PutSQL (JDBC: PostgreSQL, MySQL, MSSQL, etc.) |
| Dateien | GetFile, PutFile, FetchFile, diverse Record-Reader/Writer (CSV, JSON, Avro, Parquet) |
| S3 | ListS3, FetchS3Object, PutS3Object, DeleteS3Object (AWS SDK, kompatibel mit MinIO und anderen S3-kompatiblen Stores) |
| SFTP | ListSFTP, FetchSFTP, PutSFTP, GetSFTP (SSH-basierter Dateitransfer) |
Prozessoren
| Anforderung | Umsetzung |
|---|---|
| JSON-Transformation | JoltTransformJSON (deklaratives Mapping), EvaluateJsonPath, UpdateAttribute, ReplaceText |
| Mapping/Validierung | Record-basiertes Processing: ConvertRecord, ValidateRecord mit JSON Schema |
| Kontrollfluss | RouteOnAttribute, RouteOnContent (if/else), DistributeLoad (Fan-out), Funnels (Fan-in) |
| Persistierung | PutDatabaseRecord, PutSQL, InvokeHTTP, PublishMQTT |
| Fehlerbehandlung | Failure-Relationships auf Connections, Auto-Retry mit Penalty-Duration, Bulletin-Board für Alerts |
Performance & Skalierung
| Anforderung | Umsetzung |
|---|---|
| Horizontale Skalierung | NiFi-Cluster: mehrere Nodes als StatefulSet. Automatische Lastverteilung. |
| Vertikale Skalierung | JVM Heap und Thread-Pool-Konfiguration pro Node. |
| Ressourceneffizienz | Mindestens 2-4 GB RAM pro NiFi-Node (JVM). Ein 2-Node-Cluster benötigt 4-8 GB nur für NiFi, auch ohne Pipelines. |
| Hochfrequente Daten (0.5-1s) | Machbar, aber FlowFile-Overhead pro Nachricht. Für hohe Raten empfiehlt sich MergeContent (Micro-Batching). |
Security & Isolation
| Anforderung | Umsetzung |
|---|---|
| Pipeline-Isolation | Process Groups als logische Isolation. Alle Pipelines laufen in derselben JVM -- keine echte Prozess-Isolation. Memory-Isolation nur auf Applikationsebene. |
| Pipeline-to-Pipeline Isolation | Jedes DataSet wird als eigene Process Group mit eigenen Policies modelliert -- separate Security Domain. Pipelines innerhalb eines DataSets teilen sich eine Process Group und damit eine gemeinsame Domain. Datenflüsse zwischen DataSets sind nur über explizite Input/Output Ports möglich. |
| User-to-User Isolation | NiFi-interne Policies: Lese-/Schreib-/Execute-Rechte pro Process Group, pro User/Gruppe. |
| User-to-Platform Isolation | Policies verhindern Zugriff auf Root-Process-Group und System-Prozessoren. Einschränkung externer Verbindungen über Controller Services. |
| RBAC | Eingebaut: Feingranulare Policies auf Process Group, Processor, Connection, Controller Service-Ebene. User- und Group-Management via LDAP/OIDC. |
| Secrets | NiFi Sensitive Properties (verschlüsselt in Flow-Config), Parameter Contexts mit externen Secret Providern (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, GCP Secret Manager). Prozessoren referenzieren Secrets via #{parameter_name} -- der Klartext ist nie in der Flow-Definition sichtbar. |
Sicherheitshinweis: NiFi bietet starke logische Isolation (RBAC), aber keine Prozess-/Container-Isolation zwischen Pipelines. Ein bösartiger Prozessor (z.B. ExecuteScript) kann potenziell auf Speicher anderer Pipelines zugreifen. Mitigation: Prozessoren mit Code-Ausführung (ExecuteScript, ExecuteGroovyScript, ExecuteStreamCommand) werden per NiFi-Policy auf Root-Ebene auf Admin-Konten beschränkt. Verwaltende Nutzer erhalten nur Zugriff auf konfigurationsbasierte Prozessoren (JoltTransformJSON, RouteOnAttribute, etc.). Dies adressiert die Angreifer-Klasse "Authentifizierter Nutzer (verwaltend)" aus dem Threat Model.
Betrieb & Deployment
| Anforderung | Umsetzung |
|---|---|
| K8s ohne CRDs | Ja. NiFi als StatefulSet, kein Operator/CRD nötig. |
| Helm | Community Helm Charts verfügbar (z.B. cetic/nifi). Kein offizielles Apache Helm Chart. |
| Versionierung | Pipeline-Definitionen werden als Flow-Snapshots (JSON) in einer externen Registry versioniert. Der Configuration-Adapter importiert die aktuelle Version über die NiFi REST API. |
| Air-gapped | Container-Images vorab ladbar. Keine Runtime-Abhängigkeiten. NARs (Plugins) sind im Image enthalten. |
Eigenentwicklungsanteil
NiFi bringt als Plattform mehr mit als Redpanda Connect, erfordert aber andere Anpassungen:
| Komponente | Beschreibung | Aufwand |
|---|---|---|
| Configuration-Adapter | Adapter, der Civitas-Pipeline-Definitionen in NiFi Process Groups übersetzt (NiFi REST API als Backend). | mittel |
| RBAC-Mapping | Mapping von Civitas-Rollen/DataSet-Berechtigungen auf NiFi-Policies und -Gruppen (ebenfalls im CA). | gering |
| Monitoring-Integration | NiFi-Metriken (JMX/Prometheus Reporter) in Civitas-Monitoring integrieren. | gering |
| UI-Integration | Entscheidung: NiFi-UI einbetten (iFrame/SSO) oder eigenes UI + NiFi-REST-API? | variabel |
Risiken
| Risiko | Bewertung |
|---|---|
| Hoher Ressourcenbedarf | 4-8 GB RAM Baseline für einen 2-Node-Cluster (ohne Pipelines). Steigt mit Anzahl der Prozessoren. Widerspricht der Anforderung nach effizienter Ressourcennutzung bei ungenutzten Sandboxes. |
| Keine echte Pipeline-Isolation | Alle Pipelines teilen sich eine JVM. RBAC schützt auf Applikationsebene, aber kein Container-/Prozess-Grenze zwischen Pipelines. |
| UI-Abhängigkeit | NiFi bietet eine starke UI. Code basierte Bereitstellung von Pipelines ist versioniert über Registry möglich. Aufwand für eigenen Editor ist zu prüfen, da eine Modellierungs-UI zumindest für Experten existiert |
| Komplexität | Steile Lernkurve. NiFi-eigene Konzepte (FlowFiles, Provenance, Bulletin Board, Controller Services) erfordern Einarbeitung. |
| Helm-Chart-Qualität | Kein offizielles Apache Helm Chart. Community Charts variieren in Qualität und Aktualität. |