Katalog
concept#Daten#Integration#Architektur#Software-Engineering

Datenformat

Ein Datenformat definiert die strukturierte Darstellung von Informationen zur Speicherung und Übertragung zwischen Systemen.

Ein Data Format beschreibt die strukturierte Darstellung von Daten zur Speicherung, Übertragung und Interpretation zwischen Systemen.
Etabliert
Mittel

Klassifikation

  • Mittel
  • Technisch
  • Architektur
  • Fortgeschritten

Technischer Kontext

Nachrichtenbroker (z. B. Kafka, RabbitMQ)REST/HTTP-APIsData Lake / Objektstore (z. B. S3)

Prinzipien & Ziele

Explizite Schemadefinitionen für SchnittstellenVersionierung und rückwärtskompatible ÄnderungenMinimal notwendige Semantik statt impliziter Konventionen
Umsetzung
Unternehmen, Domäne, Team

Use Cases & Szenarien

Kompromisse

  • Inkompatible Schema-Änderungen führen zu Ausfällen
  • Falsche Wahl eines Binärformats erschwert Debugging
  • Fehlende Governance führt zu Wildwuchs an Formaten
  • Verwende formale Schemadefinitionen und CI-Validierung
  • Begrenze Breaking Changes durch kompatible Erweiterungen
  • Dokumentiere Semantik und Beispiel-Payloads

I/O & Ressourcen

  • Quellsysteme und Datenmodelle
  • Anforderungen an Kompatibilität und Performance
  • Verfügbare Bibliotheken und Laufzeitumgebungen
  • Definiertes Schema und Serialisierungsregeln
  • Implementierte Validierung und Tests
  • Governance- und Migrationsrichtlinien

Beschreibung

Ein Data Format beschreibt die strukturierte Darstellung von Daten zur Speicherung, Übertragung und Interpretation zwischen Systemen. Es definiert Syntax, Semantik, Typen und Serialisierungskonventionen sowie Standardvereinbarungen (z. B. JSON, XML, Avro). Es umfasst auch Versionierung, Schema-Evolution und normative Regeln für Kompatibilität, Validierung, Performance und Erweiterbarkeit.

✔

  • Verbesserte Interoperabilität zwischen Systemen
  • Erleichterte Validierung und Fehlererkennung
  • Bessere Kompression und Performance bei geeigneten Formaten

✖

  • Format-Entscheidungen können spätere Migration erschweren
  • Nicht alle Formate unterstützen komplexe Datentypen gleich gut
  • Overhead durch Metadaten oder Serialisierungsschritt

  • Schema-Kompatibilitätsrate

    Prozentsatz der Änderungen, die kompatibel mit bestehenden Konsumenten sind.

  • Payload-Größe

    Durchschnittliche Bytes pro Nachricht/Datensatz zur Abschätzung Bandbreite und Speicher.

  • Parsing-Latenz

    Zeitbedarf für Serialisierung/Deserialisierung im Pfad der Datenverarbeitung.

REST-API mit JSON Schema

Ein Service verwendet JSON Schema zur Validierung und Dokumentation seiner API-Payloads.

Event-Streaming mit Avro und Schema Registry

Ereignisse werden im Avro-Format serialisiert und über eine Registry versioniert.

Analytischer Data Lake mit Parquet

Batch-Daten werden als Parquet gespeichert, um Abfragen und Kompression zu optimieren.

1

Analyse der Anforderungen und bestehender Formate

2

Auswahl eines geeigneten Formats und Festlegung von Schemas

3

Einführung von Validierung, Registry und Dokumentation

⚠️ Technische Schulden & Engpässe

  • Veraltete Formatversionen ohne Migrationspfad
  • Fehlende zentrale Registry für Schemas
  • Ad-hoc Serialisierungsbibliotheken in Services
Serialisierung/DeserialisierungSchema-Registry-LatenzNetzwerk-Bandbreite
  • Verwendung von CSV für komplex verschachtelte Strukturen
  • Persistieren von Binär-JSON (BSON) ohne Kompatibilitätsregeln
  • Direktes Ändern von Produktiv-Schemas ohne Tests
  • Annahme, dass Textformate immer ausreichend sind
  • Unterschätzen der Kosten für Schema-Migration
  • Fehlende Überwachung von Inkompatibilitäten
Datenmodellierung und Schema-DesignKenntnisse zu Serialisierungsformaten (JSON, Avro, Parquet)Erfahrung mit Integrationsmustern und Governance
Interoperabilität zwischen heterogenen SystemenPerformance- und LatenzanforderungenLangfristige Wartbarkeit und Schema-Evolution
  • • Vorhandene Verbraucher erwarten festes Schema
  • • Regulatorische Vorgaben für Datenformate und Metadaten
  • • Legacy-Systeme unterstützen nur begrenzte Formate