StatisticalAnomalyDetection@1

Der Node StatisticalAnomalyDetection@1 wird verwendet, um mithilfe verschiedener statistischer Methoden Anomalien in numerischen Datenströmen zu erkennen.

Adapter-Voraussetzungen

Mesh Adapter

Node-Konfiguration

Für die Felder path, targetPath, targetValueWriteMode und targetValueKind siehe Überblick.

transformations:
- type: StatisticalAnomalyDetection@1
  path: $.Items[*]  # Path to array of items to analyze
  targetPath: $.anomalies  # Path where anomaly results will be stored
  resetStatistics: false  # Reset statistics on each run (true = stateless, false = stateful)
  detectors:
    - path: $.Attributes.GrossTotal  # JSONPath to the numeric value to monitor
      groupByPath: $.Attributes.Issuer.Attributes.CompanyName  # Optional: Group statistics by this path
      contextPath: $.Attributes.DocumentNumber  # Optional: Include context in anomaly results
      method: PercentChange  # Detection method: ZScore, Iqr, PercentChange, MovingAverage
      threshold: 50.0  # Threshold for anomaly detection (interpretation depends on method)
      minSamples: 2  # Minimum samples required before detection starts
      maxSamples: 1000  # Maximum samples to keep in memory (0 = unlimited)
      windowSize: 10  # Window size for moving average method

Erkennungsmethoden

Z-Score-Methode

Die Z-Score-Methode erkennt Anomalien, indem sie misst, um wie viele Standardabweichungen ein Datenpunkt vom Mittelwert der Verteilung abweicht. Sie setzt voraus, dass die Daten einer Normalverteilung folgen.

Funktionsweise:

Berechnet den Mittelwert (μ) und die Standardabweichung (σ) aus den gesammelten Stichproben
Berechnet für jeden neuen Wert Z-Score = |Wert − μ| / σ
Werte, die den Schwellenwert überschreiten, werden als Anomalien markiert

Parameter:

threshold: Anzahl der Standardabweichungen (z. B. 3.0 für die 3σ-Regel)
- 2.0 = ~95 % der normalen Daten (5 % Ausreißer erwartet)
- 3.0 = ~99,7 % der normalen Daten (0,3 % Ausreißer erwartet)
- 4.0 = ~99,99 % der normalen Daten (nur sehr seltene Ausreißer)
minSamples: Empfohlenes Minimum 30 für statistische Aussagekraft

Wann verwenden:

Daten folgen einer Normal-/Gauß-Verteilung
Konsistente, stabile Prozesse
Qualitätskontrolle in der Fertigung
Überwachung der Server-Antwortzeit

Weiterführende Literatur:

IQR-Methode (Interquartilsabstand)

Die IQR-Methode verwendet Quartile zur Erkennung von Ausreißern, wodurch sie robust gegenüber Extremwerten und für nicht normalverteilte Daten geeignet ist.

Funktionsweise:

Berechnet Q1 (25. Perzentil) und Q3 (75. Perzentil)
Berechnet IQR = Q3 − Q1
Definiert Grenzen: Untere = Q1 − (threshold × IQR), Obere = Q3 + (threshold × IQR)
Werte außerhalb dieser Grenzen sind Anomalien

Parameter:

threshold: IQR-Multiplikator
- 1.5 = Standard-Ausreißererkennung (Tukey-Methode)
- 3.0 = Erkennung extremer Ausreißer
- Benutzerdefinierte Werte für domänenspezifische Anforderungen
minSamples: Empfohlenes Minimum 10-20 für stabile Quartile

Wann verwenden:

Schiefe oder nicht normalverteilte Verteilungen
Daten mit natürlichen Ausreißern
Finanzdatenanalyse
Metriken zum Kundenverhalten

Weiterführende Literatur:

Percent-Change-Methode

Erkennt Anomalien anhand der prozentualen Änderung gegenüber dem vorherigen Wert, ideal zur Erkennung plötzlicher Sprünge oder Einbrüche in sequenziellen Daten.

Funktionsweise:

Berechnet: Änderung = |aktueller_Wert − letzter_Wert| / |letzter_Wert| × 100
Markiert als Anomalie, wenn die Änderung den Schwellenprozentsatz überschreitet
Einfach, aber effektiv für die Trendüberwachung

Parameter:

threshold: Maximal zulässige prozentuale Änderung
- 10.0 = 10 % Änderung löst Anomalie aus
- 50.0 = 50 % Änderung löst Anomalie aus
- 100.0 = Verdopplung/Halbierung löst Anomalie aus
minSamples: Funktioniert bereits mit nur 1 vorherigen Stichprobe

Wann verwenden:

Überwachung von Aktienkursen
Verfolgung des Verkaufsvolumens
Analyse von Verkehrsmustern
Überwachung der Ressourcenauslastung

Hinweis: Nicht geeignet für Werte, die null oder nahe null sein können (Divisionsprobleme).

Moving-Average-Methode

Erkennt Anomalien durch Vergleich von Werten mit einem gleitenden Durchschnitt und identifiziert so effektiv Abweichungen von jüngsten Trends.

Funktionsweise:

Führt ein gleitendes Fenster jüngster Werte
Berechnet den Mittelwert des Fensters (gleitender Durchschnitt)
Berechnet die Abweichung: |Wert − gleitender_Durchschnitt| / gleitender_Durchschnitt × 100
Markiert eine Anomalie, wenn die Abweichung den Schwellenwert überschreitet

Parameter:

threshold: Maximale prozentuale Abweichung vom gleitenden Durchschnitt
- 10.0 = 10 % Abweichung vom Durchschnitt
- 25.0 = 25 % Abweichung vom Durchschnitt
windowSize: Anzahl der jüngsten Werte für die Durchschnittsberechnung
- Kleiner (5-10): Reagiert schneller auf Änderungen
- Größer (20-50): Stabiler, weniger empfindlich gegenüber Rauschen
minSamples: Muss mindestens gleich windowSize sein

Wann verwenden:

Trendbehaftete Daten mit saisonalen Mustern
Analyse des Netzwerkverkehrs
Temperaturüberwachung
Geschäftsmetriken mit wöchentlichen/täglichen Zyklen

Weiterführende Literatur:

Ausgabeformat

Der Node erzeugt am Zielpfad ein Array der Anomalieergebnisse. Jedes Anomalie-Objekt enthält die folgenden Felder:

Ausgabefelder

Feld	Typ	Beschreibung
`path`	string	Der überwachte JSONPath (aus der Detector-Konfiguration)
`value`	number	Der tatsächliche numerische Wert, der die Anomalie ausgelöst hat
`isAnomaly`	boolean	In der Ausgabe stets `true` (Nicht-Anomalien sind nicht enthalten)
`score`	number	Schweregrad-Score der Anomalie. Die Interpretation hängt von der Methode ab: • Z-Score: Anzahl der Standardabweichungen vom Mittelwert • IQR: Abstand von den Grenzen geteilt durch IQR • PercentChange: Tatsächliche prozentuale Änderung • MovingAverage: Prozentuale Abweichung vom Durchschnitt
`method`	string	Verwendete Erkennungsmethode: `"ZScore"`, `"Iqr"`, `"PercentChange"` oder `"MovingAverage"`
`reason`	string	Menschenlesbare Erklärung, warum die Anomalie erkannt wurde, inklusive berechneter Werte und Schwellenwerte
`context`	any	Zusätzliche Kontextdaten aus `contextPath` (falls konfiguriert). Kann je nach Quelldaten ein beliebiger JSON-Typ sein

Beispielausgabe

[
  {
    "path": "$.Attributes.GrossTotal",
    "value": 2880,
    "isAnomaly": true,
    "score": 900.0,
    "method": "PercentChange",
    "reason": "Change: 900.00% (threshold: 50.0%)",
    "context": "Document-5"
  },
  {
    "path": "$.Attributes.Temperature",
    "value": 45.2,
    "isAnomaly": true,
    "score": 3.5,
    "method": "ZScore",
    "reason": "Z-Score: 3.50 (threshold: 3.0)",
    "context": "Sensor-A1"
  },
  {
    "path": "$.Attributes.ResponseTime",
    "value": 1250,
    "isAnomaly": true,
    "score": 2.1,
    "method": "Iqr",
    "reason": "Value outside IQR bounds [150.00, 850.00]",
    "context": "Server-02"
  },
  {
    "path": "$.Attributes.Traffic",
    "value": 15000,
    "isAnomaly": true,
    "score": 35.5,
    "method": "MovingAverage",
    "reason": "Deviation from MA: 35.50% (threshold: 25.0%)",
    "context": "2024-01-15T10:00:00"
  }
]

Interpretation des Scores

Die Interpretation des Felds score hängt von der Erkennungsmethode ab:

Methode	Score-Interpretation	Typische Anomalie-Schwellenwerte
ZScore	Standardabweichungen vom Mittelwert	> 2.0 gering, > 3.0 stark, > 4.0 extrem
Iqr	Vielfaches des IQR-Abstands von den Grenzen	> 0 Ausreißer, > 1.0 starker Ausreißer
PercentChange	Tatsächliche prozentuale Änderung	Abhängig von der Domäne (z. B. > 50 % bei Preisen)
MovingAverage	Prozentuale Abweichung vom Durchschnitt	> 20 % geringe, > 50 % starke Abweichung

Ausgabeverhalten

Leeres Array: Im aktuellen Batch wurden keine Anomalien erkannt
Zustandsbehafteter Modus (resetStatistics: false): Statistiken akkumulieren über Läufe hinweg und verbessern die Genauigkeit im Laufe der Zeit
Zustandsloser Modus (resetStatistics: true): Jeder Lauf beginnt neu, geeignet für unabhängige Batches
Gruppierung: Bei Verwendung von groupByPath werden für jede Gruppe separate Statistiken geführt

Beispiele

Beispiel 1: Anomalien bei Rechnungsbeträgen je Aussteller erkennen

transformations:
- type: StatisticalAnomalyDetection@1
  path: $.documents.Items[*]
  targetPath: $.invoiceAnomalies
  resetStatistics: false
  detectors:
    - path: $.Attributes.GrossTotal
      groupByPath: $.Attributes.Issuer.Attributes.CompanyName
      contextPath: $.Attributes.DocumentNumber
      method: PercentChange
      threshold: 50.0
      minSamples: 2

Beispiel 2: Konfiguration mit mehreren Detektoren

transformations:
- type: StatisticalAnomalyDetection@1
  path: $.measurements[*]
  targetPath: $.detectedAnomalies
  detectors:
    # Detect sudden temperature spikes
    - path: $.temperature
      method: ZScore
      threshold: 3.0
      minSamples: 10
    # Detect pressure changes
    - path: $.pressure
      method: PercentChange
      threshold: 20.0
      minSamples: 1
    # Detect flow rate deviations from moving average
    - path: $.flowRate
      method: MovingAverage
      threshold: 15.0
      windowSize: 20
      minSamples: 20

Beispiel 3: Zustandslose Anomalieerkennung

transformations:
- type: StatisticalAnomalyDetection@1
  path: $.sensorData[*]
  targetPath: $.alerts
  resetStatistics: true  # Each run starts with fresh statistics
  detectors:
    - path: $.value
      method: Iqr
      threshold: 1.5
      minSamples: 5
      maxSamples: 100  # Keep only last 100 samples in memory

Beispiel 4: Finanzüberwachung mit IQR

transformations:
- type: StatisticalAnomalyDetection@1
  path: $.transactions[*]
  targetPath: $.suspiciousTransactions
  resetStatistics: false
  detectors:
    - path: $.amount
      groupByPath: $.accountType  # Separate statistics per account type
      contextPath: $.transactionId
      method: Iqr
      threshold: 3.0  # Detect extreme outliers only
      minSamples: 20
      maxSamples: 500  # Sliding window of 500 transactions

Hinweise

Zustandsbehaftet vs. zustandslos: Ist resetStatistics auf false gesetzt, hält der Node Statistiken über Pipeline-Läufe hinweg vor und kann so aus historischen Daten lernen. Bei true beginnt jeder Lauf neu.
GroupBy: Der Parameter groupByPath ermöglicht eine getrennte statistische Verfolgung für verschiedene Gruppen (z. B. pro Kunde, pro Sensor).
Speicherverwaltung: Verwenden Sie maxSamples, um den Speicherverbrauch bei langlaufenden Pipelines zu begrenzen. Ältere Stichproben werden nach dem FIFO-Prinzip entfernt.
Kontextdaten: Der Parameter contextPath fügt den Anomalieergebnissen zusätzliche Informationen für besseres Debugging und bessere Analyse hinzu.
Leitfaden zur Methodenauswahl:
- Verwenden Sie Z-Score für normalverteilte Daten mit stabilen Mustern
- Verwenden Sie IQR für schiefe Daten oder wenn eine robuste Ausreißererkennung benötigt wird
- Verwenden Sie PercentChange, um plötzliche Änderungen in sequenziellen Daten zu erkennen
- Verwenden Sie MovingAverage für trendbehaftete Daten mit erwarteten Schwankungen
Mindeststichproben: Jede Methode benötigt für eine zuverlässige Erkennung unterschiedlich viele Mindeststichproben. Z-Score benötigt mehr Stichproben (30+) für statistische Aussagekraft, während PercentChange bereits mit nur 1 vorherigen Wert funktioniert.

Adapter-Voraussetzungen​

Node-Konfiguration​

Erkennungsmethoden​

Z-Score-Methode​

IQR-Methode (Interquartilsabstand)​

Percent-Change-Methode​

Moving-Average-Methode​

Ausgabeformat​

Ausgabefelder​

Beispielausgabe​

Interpretation des Scores​

Ausgabeverhalten​

Beispiele​

Beispiel 1: Anomalien bei Rechnungsbeträgen je Aussteller erkennen​

Beispiel 2: Konfiguration mit mehreren Detektoren​

Beispiel 3: Zustandslose Anomalieerkennung​

Beispiel 4: Finanzüberwachung mit IQR​

Hinweise​

Adapter-Voraussetzungen

Node-Konfiguration

Erkennungsmethoden

Z-Score-Methode

IQR-Methode (Interquartilsabstand)

Percent-Change-Methode

Moving-Average-Methode

Ausgabeformat

Ausgabefelder

Beispielausgabe

Interpretation des Scores

Ausgabeverhalten

Beispiele

Beispiel 1: Anomalien bei Rechnungsbeträgen je Aussteller erkennen

Beispiel 2: Konfiguration mit mehreren Detektoren

Beispiel 3: Zustandslose Anomalieerkennung

Beispiel 4: Finanzüberwachung mit IQR

Hinweise