Features¶

DATAMIMIC Features¶

DATAMIMIC kombiniert modellgetriebene Generierung mit deterministischer Reproduzierbarkeit (gleicher Seed → gleicher Content-Hash) in beiden Editionen. Die Enterprise Edition ergänzt auto-regressives ML, einen Rust-Schnellpfad, Kafka-Integration, erweitertes Datenquellen-Scanning, strukturiertes Logging und ausgebaute Fehlerbehandlung. Die folgenden Funktionen beschreiben, was jede Edition kann und wo sie sich unterscheiden.

Funktionen sind nach Edition gekennzeichnet:

(CE) — Community Edition, die Python-Bibliothek und datamimic-CLI. Enthält einige Funktionen, die in der EE nicht (oder weniger ausgeprägt) vorhanden sind (MCP-Support, umfangreichere demografische Profile).
(EE) — Enterprise Edition, die On-Prem-Plattform (Web-UI, REST-API, Scheduler, Worker, die die EE-Core-Engine kapseln, optional LSP). Ergänzt Rust-Schnellpfad, Kafka, erweitertes Datenquellen-Scanning und strukturiertes Logging.
(CE+EE) — DSL-Fähigkeit, die beide Editionen mitbringen.

Modellgetriebener Ansatz (CE+EE)¶

Der modellgetriebene Ansatz zentralisiert die Testdaten-Definition:

Eine Definitionsquelle: Datenmodelle sind Blaupausen für die Generierung. Änderungen an Schema, Generator oder Constraint werden einmal auf Modellebene vorgenommen und greifen für jedes Ausgabeformat.
Abstraktion über Datenformate: Autor:innen arbeiten mit Entitäten und Schlüsseln auf hoher Ebene, nicht mit formatspezifischen Strukturen. Dasselbe Modell liefert SQL-, JSON-, XML-, CSV- und EDIFACT-Ausgabe.
Anpassbar: Änderungen an Formaten, neue Datenquellen oder veränderte Beziehungen werden im Modell vorgenommen. Nachgelagerte Pipelines bleiben unberührt.
Konsistent und überprüfbar: Die Generierung folgt deklarierten Regeln und Constraints. Erneutes Ausführen eines seed-gesteuerten Modells erzeugt dieselbe Ausgabe — über Maschinen und Releases hinweg.

Komponierbare Modelle (CE+EE)¶

DATAMIMIC-Modelle sind auf Komposition ausgelegt, nicht auf monolithische Dateien:

<include> — Logik in mehrere Dateien (Konfigurations-.properties, Submodell-XML-Fragmente) aufteilen und im Haupt-Deskriptor zusammensetzen.
<param>-Deklarationen — wiederverwendbare Fragmente deklarieren ihre erwarteten Eingaben auf Wurzelebene und machen gemeinsam genutzte Modellkomponenten explizit.
<property>-Overlays unter <include> — aufrufende Stellen übergeben Werte pro Instanz (konstant oder per Skript), sodass dasselbe Fragment mehrere Geschäftsvarianten ohne Copy-Paste bedient.

Das ist das übliche Muster in Enterprise-Projekten. Siehe Release Notes zu 3.3.0 für die Include-Property- und Fragment-Param-Features.

Multi-Format-Output (CE+EE)¶

Ein Modell schreibt im selben Lauf nach SQL-Datenbanken, JSON, XML, CSV und EDIFACT — über mehrere <generate target="...">-Deklarationen. Kafka als Quelle und Ziel ist EE-exklusiv.

JSON- und XML-Verarbeitung (CE+EE)¶

Tief verschachtelte JSON- und XML-Strukturen werden erzeugt und transformiert, mit voller Kontrolle über Hierarchie, Typen und Arrays.

Verschachtelte Strukturen: JSON- und XML-Objekte mit verschachtelten Strukturen definieren — Objekte oder Elemente, die andere Objekte/Elemente, Arrays und gemischte Datentypen in einer Struktur enthalten.
Hierarchische Datenmodellierung: Komplexe Beziehungen zwischen Datenentitäten abbilden — nützlich für NoSQL-Datenbanken und XML-Schemata.
Tiefe Verschachtelung: Tief verschachtelte JSON-Objekte und XML-Elemente, um real verflochtene Datenszenarien abzubilden.
Anpassbarkeit: Jeder Aspekt der Struktur ist konfigurierbar — vom Layout bis zur Art, wie einzelne Werte erzeugt und formatiert werden.

Datenanonymisierung und -pseudonymisierung (CE+EE)¶

Feldbasiertes Masking, deklariert im Modell. Gleiche Seed- und Konfigurationsangaben reproduzieren dieselben maskierten Ausgaben über Läufe und Umgebungen hinweg.

MCP-Support (CE)¶

Die Community Edition liefert eine Integration mit dem Model Context Protocol (MCP) für LLM-gestützte Workflows auf der DSL. Die EE enthält diese Oberfläche aktuell nicht.

Demografische Profile (CE)¶

CE liefert umfangreichere demografische Profile ab Werk mit. Der Profil-Katalog ist auf DSL-Ebene geteilt; CE enthält heute schlicht mehr vorgefertigte Profile als EE.

Automatische PII-Erkennung (EE)¶

Beim Generieren eines DATAMIMIC-Modells aus Datenbank-Metadaten erkennt die Plattform Felder, die wahrscheinlich personenbezogene Daten (PII) enthalten, automatisch. Diese Felder werden im erzeugten Modell mit #SENSITIVE markiert und sind damit standardmäßig maskiert. Autor:innen prüfen und justieren, bevor synthetische Daten generiert oder exportiert werden.

Datenschutz-Ausrichtung (CE+EE)¶

Ausgerichtet auf DSGVO Art. 25 (Privacy by Design). Unterstützt BCBS-239-Lineage- und DORA-Nachvollziehbarkeitsanforderungen über Pro-Lauf-Task-IDs, Modell-Versionen und Content-Hashes.

ML-basierte Generierung, auto-regressiv (EE)¶

Auto-regressive ML-Generatoren auf Basis von TabularARGN (Apache 2.0). Modelle sind versioniert und qualitätsbewertet. ML-Ausgaben sind statistisch konsistent, aber nicht byte-identisch — byte-identische Ausgaben entstehen nur bei seed-gesteuerten regelbasierten Generatoren. ML-Generierung ist eine Enterprise-Edition-Fähigkeit; die Community Edition deckt regelbasierte Generierung ab.

Performance (EE)¶

Die Enterprise Edition läuft auf einem Verarbeitungskern aus Python mit Rust-Schnellpfad und wird produktiv eingesetzt, um Streaming-Zahlungsverkehrstransaktionen im Mehrmillionen-Maßstab zu anonymisieren. Die Community Edition läuft auf einem reinen Python-Kern und ist deutlich weniger optimiert — geeignet für einzelne Projekte, Skripte und CI-Nutzung, aber nicht auf dieselben Durchsatzziele ausgelegt.

Erweitertes Datenquellen-Scanning (EE)¶

Beim Lesen aus Quelldatenbanken nutzt EE Keyset-Paginierung mit einem worker-synchronisierten Manifest statt OFFSET / LIMIT-Abfragen. Das hält Multi-Worker-Scans konsistent, vermeidet Latenz- und Konsistenzkosten von Skip-and-Offset bei Skalierung und funktioniert unter Last. CE nutzt Standard-Skip/Offset-Paginierung in der Datenbank — ausreichend für kleine Datensätze, aber nicht auf gleiche Weise skalierbar.

Strukturiertes Logging und Fehlerbehandlung (EE)¶

Strukturierte Pro-Task-Logs, ein expliziter Fehlerkatalog und ausgebaute Recovery-Semantiken. CE bringt Python-Standard-Logging mit.

Audit-Nachweis pro Task (EE)¶

Jeder Worker-Task wird mit Task-ID, Eingaben, Status und strukturierten Pro-Task-Logs protokolliert. Bei gesetztem rngSeed im <setup> liefert ein erneuter Lauf des Modells deterministisch identische Ausgaben — über Maschinen und Releases hinweg. Das ist die Nachweisebene für Compliance- und Reproduzierbarkeits-Reviews.

Editor-Unterstützung — LSP v2 (EE, opt-in)¶

Kontextsensitive Vervollständigung in script=- und condition=-Attributen, inklusive sichtbarer Variablen, Skript-Symbolen im Projekt, .ent.csv-Spalten, mehrstufige Entity-Member sowie Fragment-Property-Inputs an <include>-Aufrufstellen. Pro Projekt unter Project Settings aktivierbar; siehe Experimental LSP.

Web-UI (EE)¶

Projekt-, Schedule- und Task-Management im Browser, inklusive Database View, Demo Store, Vorschauen sowie Pro-Task-Logs und -Artefakte.

Integrationsoberfläche¶

(CE) Python-API und datamimic-CLI für lokale Generierung und Scripting.
(EE) REST-API für CI/CD-Trigger (Worker führen die EE-Core-Engine aus und liefern Artefakte zurück); Helm-Chart für die Bereitstellung; Datenbank-Konnektoren für PostgreSQL, Oracle, MongoDB; Streaming via Apache Kafka; Template-Exporter für Industrie-Nachrichtenformate (SWIFT, PACS, HL7, EDIFACT).

Skaliert vom Einzelschema zur Enterprise-Plattform¶

(CE) Geeignet für einzelne Projekte, Skripte und CI-Nutzung der Python-Bibliothek.
(EE) Plattformweite Testdaten-Verwaltung über Teams hinweg; einsetzbar auf Docker, Podman, Kubernetes, OpenShift oder via Helm-Chart.

Generator-Bibliothek (CE+EE)¶

Eingebaute Generatoren für domänen-, demografie- und protokollspezifische Daten. Erweiterbar durch eigenen Python-Code.