Individuelle Worker-Konfiguration

DATAMIMIC führt alle Hintergrundarbeiten als Celery-Tasks aus. Jeder Task-Typ hat seine eigene Queue, und jeder Worker-Prozess verarbeitet eine konfigurierbare Menge an Queues. Diese Seite erklärt das Task-/Queue-Modell, listet alle unterstützten Tasks auf und zeigt, wie Du Queues den Workern zuordnest, damit kein Task-Typ unbearbeitet bleibt.

Wie das Task-Routing funktioniert

• Jeder Task-Typ ist genau einer Queue zugeordnet, die nach dem Task-Typ benannt ist — der Task data_source_scan wird zum Beispiel an die Queue data_source_scan geroutet.
• Ein Worker verarbeitet nur die Queues, die in seiner Umgebungsvariable WORKER_QUEUES stehen: eine durch Kommas getrennte Liste von Queue-Namen, ohne Leerzeichen.
• Ein Task, dessen Queue von keinem laufenden Worker verarbeitet wird, bleibt in der Warteschlange und läuft nie. Das Aufteilen der Arbeit auf mehrere Worker ist daher eine bewusste Routing-Entscheidung — jede Queue, die Du nutzen möchtest, muss in den WORKER_QUEUES mindestens eines laufenden Workers auftauchen.

Eigene Topologien müssen jede genutzte Queue abdecken

Das Standard-Deployment liefert Werte, die bereits alle Queues abdecken, und erfordert keine Anpassung. Wenn Du ein eigenes Worker-Layout definierst, stelle sicher, dass jeder Task-Typ, den Deine Nutzer auslösen können, abgedeckt ist — sonst laufen diese Tasks nie. In einem Release neu hinzugekommene Task-Typen (zum Beispiel die Workbench-Scan-Familie data_source_browse, data_source_scan und scan_result_generate_model in 3.5.0) müssen den WORKER_QUEUES eines bestehenden Workers hinzugefügt werden.

Unterstützte Tasks

Die Spalte Queue-Name ist exakt der Wert, den Du in WORKER_QUEUES einträgst. Das Label ist die Kurzform, die in der TaskView angezeigt wird. Scope ist einer von: project (von Nutzern ausgelöste, projektgebundene Arbeit), system (globale Wartung, ohne Projekt) oder backup_infrastructure (Backup/Restore, läuft außerhalb des Backup-Scopes).

Synthetische Datengenerierung

Queue-Name	Label	Scope	Beschreibung
standard	GEN-SDN	project	Standard-Generierungslauf (Soft-/Hard-Timeout ~15 Min).
infinite	GEN-INF	project	Langlaufende Generierung ohne Timeout.
timed_5min	GEN-5M	project	Generierung auf 5 Minuten begrenzt.
timed_30min	GEN-30M	project	Generierung auf 30 Minuten begrenzt.
timed_1hour	GEN-1H	project	Generierung auf 1 Stunde begrenzt.
timed_4hour	GEN-4H	project	Generierung auf 4 Stunden begrenzt.
timed_8hour	GEN-8H	project	Generierung auf 8 Stunden begrenzt.
timed_24hour	GEN-24H	project	Generierung auf 24 Stunden begrenzt.
cron	GEN-SCH	project	Geplanter (Cron-)Generierungslauf, ohne Timeout.

Modell- und Template-Generierung aus einer Quelle

Queue-Name	Label	Scope	Beschreibung
database_generate_model	DB-GEN-MOD	project	Erzeugt ein DATAMIMIC-Modell aus einer gescannten SQL-Datenbank.
database_generate_weighting	DB-GEN-WGT	project	Erzeugt die Verteilungsgewichtung für ein Datenbankmodell.
json_generate_model	JSON-GEN-MOD	project	Erzeugt ein Modell aus einem JSON-Beispiel.
json_generate_template	JSON-GEN-TMP	project	Erzeugt ein Template aus einem JSON-Beispiel.
xml_generate_model	XML-GEN-MOD	project	Erzeugt ein Modell aus einem XML-Beispiel.
xml_generate_template	XML-GEN-TMP	project	Erzeugt ein Template aus einem XML-Beispiel.
csv_generate_model	CSV-GEN-MOD	project	Erzeugt ein Modell aus einem CSV-Beispiel.

Data-Workbench-Scan-Familie

Queue-Name	Label	Scope	Beschreibung
db_metadata_scan	DB-META-SCAN	project	Scannt SQL-Datenbank-Metadaten (Workbench Database-Modus).
data_source_browse	DS-BROWSE	project	Durchsucht einen Datenquellen-Ort (Datenbanken, Collections, Verzeichnisse, Dateien).
data_source_scan	DS-SCAN	project	Scannt eine ausgewählte Tabelle, Collection oder ein Objekt in einen Snapshot.
scan_result_generate_model	SCAN-GEN-MOD	project	Erzeugt ein Modell aus einem persistierten Scan-Snapshot.

Verbindungen, Migration und Git

Queue-Name	Label	Scope	Beschreibung
healthcheck	CHK-ENV	project	Testet eine Umgebungsverbindung (SQL, MongoDB, Kafka, Object Storage).
gwa_migration	GWA-MIG	project	Migriert ein GWA-Projekt nach DATAMIMIC.
ama_migration	AMA-MIG	project	Migriert eine AMA/EDI-Definition nach DATAMIMIC.
project_git_push	GIT-PUSH	project	Pusht Projektänderungen ins konfigurierte Git-Remote.
project_git_update	GIT-UPDATE	project	Aktualisiert das Projekt aus seinem Git-Remote.

System, Wartung und Backup

Queue-Name	Label	Scope	Beschreibung
runtime_capabilities_fetch	RUNTIME-CAPS	system	Holt Runtime-Capability-Metadaten aus der Engine.
housekeeping	HOUSEKEEPING	system	Periodische interne Wartung.
clean_up_project_storage	CLEAN UP PROJECT STORAGE	project	Entfernt verwaisten Projektspeicher.
system_backup	SYSTEM_BACKUP	backup_infrastructure	Sichert die DATAMIMIC-Dateninstanz.
system_restore	SYSTEM_RESTORE	backup_infrastructure	Stellt die DATAMIMIC-Dateninstanz aus einem Backup wieder her.

Empfohlenes Worker-Layout

Ein praktikables Layout trennt kurze interaktive Generierung, langlaufende Generierung und operative/Quellen-Tasks auf drei Worker-Gruppen auf. Das entspricht den mit dem Helm-Chart ausgelieferten Werten:

celeryworker:
  install: true

  # Jeder Worker hört über WORKER_QUEUES auf eine bestimmte Menge an Queues.
  # Die Queue-Namen sind die von der Plattform definierten TaskType-Werte.
  workers:
    - name: operation-worker
      replicaCount: 1
      extraEnvs:
        WORKER_QUEUES: "healthcheck,housekeeping,clean_up_project_storage,runtime_capabilities_fetch,gwa_migration,ama_migration,project_git_push,project_git_update,db_metadata_scan,database_generate_model,database_generate_weighting,json_generate_model,json_generate_template,xml_generate_model,xml_generate_template,csv_generate_model,data_source_browse,data_source_scan,scan_result_generate_model"
      resources:
        limits:
          cpu: 300m
          memory: 500Mi
        requests:
          cpu: 100m
          memory: 256Mi
    - name: short-worker
      replicaCount: 1
      extraEnvs:
        WORKER_QUEUES: "standard,timed_5min,timed_30min,timed_1hour,cron"
      resources:
        limits:
          cpu: 1500m
          memory: 1.5Gi
        requests:
          cpu: 500m
          memory: 1Gi
    - name: long-worker
      replicaCount: 1
      extraEnvs:
        WORKER_QUEUES: "infinite,timed_4hour,timed_8hour,timed_24hour,system_backup,system_restore"
      resources:
        limits:
          cpu: 500m
          memory: 1Gi
        requests:
          cpu: 200m
          memory: 512Mi

database_generate_weighting einschließen

Die Queue database_generate_weighting (DB-GEN-WGT) muss überall dort verarbeitet werden, wo Datenbank-Modellgenerierung genutzt wird. Wenn Du eine ältere Referenz-values.yaml kopiert hast, prüfe, ob diese Queue auf einem Worker vorhanden ist — sonst werden Gewichtungs-Tasks zwar eingereiht, laufen aber nie.

Eine Queue zu einem Worker hinzufügen

1. Wähle die Worker-Gruppe, die den Task ausführen soll (kurz-interaktiv, langlaufend oder operativ).
2. Füge den Queue-Namen zu den WORKER_QUEUES dieses Workers hinzu — durch Kommas getrennt, ohne Leerzeichen.
3. Rolle den Worker aus, damit die neue Konfiguration wirksam wird.

Queue-Namen entsprechen immer dem Task-Typ-Wert (Spalte Queue-Name oben). Erfinde keine Queue-Namen; nur die von der Plattform definierten Werte werden geroutet.

Für Deployments ohne Helm (zum Beispiel Docker Compose) setze dieselbe Umgebungsvariable WORKER_QUEUES am Worker-Container oder in dessen .env-Datei.