Ein militärischer und ein kommerzieller Data Lake teilen dieselbe Grundidee – kostengünstiger, skalierbarer Objektspeicher als Fundament für Analytik –, unterscheiden sich jedoch bei jeder betrieblich relevanten Randbedingung erheblich. Durchsetzung der Einstufung, Compartment-bezogener Zugriff, Air-Gap-Betrieb und einsatzkritische Abfrage-SLAs sind für einen Einsatz im Verteidigungsbereich keine Zusatzfunktionen; sie sind tragende Anforderungen, die jede Schicht der Architektur prägen – von der Benennung der Speicher-Buckets bis zur Konfiguration der Query-Engine. Eine Architektur, die sie erst im Nachhinein berücksichtigt – etwa indem sie bestehenden kommerziellen Data-Lake-Mustern ein Einstufungskennzeichen hinzufügt –, wird im besten Fall an Sicherheitsaudits scheitern und im schlimmsten Fall Compliance-Verstöße verursachen.
Dieser Artikel führt durch den vollständigen Entwurf eines produktiven militärischen Data Lake: die Speicherschicht, die Ingest-Pipeline aus C2-, ISR- und Logistikquellen, das Metadatenmanagement militärischer Datenkataloge, die Compartment-basierte Zugriffskontrolle und Muster für Analyse-Workloads. Jeder Abschnitt behandelt die Entwurfsentscheidungen, die ein einsatzfähig betreibbares System von einer Referenzarchitektur unterscheiden, die im Whitepaper korrekt aussieht, beim Kontakt mit realen eingestuften Daten jedoch versagt.
Was ein militärischer Data Lake leisten muss, ein kommerzieller jedoch nicht – Durchsetzung der Einstufung, Compartment-bezogener Zugriff, Air-Gap-Betrieb, einsatzkritische SLAs
Der grundlegendste Unterschied zwischen einem kommerziellen und einem militärischen Data Lake ist keine Technologieentscheidung – es ist ein Bedrohungsmodell. Ein kommerzieller Data Lake schützt vor externen Angreifern und vor Datenabfluss durch Insider. Ein militärischer Data Lake muss zusätzlich vor einem subtileren Fehlerfall schützen: Ein autorisierter Benutzer greift auf Daten zu, für die er freigegeben, aber im aktuellen Kontext nicht zur Einsicht berechtigt ist. Ein Analyst der Signalaufklärung mit Top-Secret-Freigabe darf einen Compartment-geschützten HUMINT-Datenbestand nicht abfragen können, sofern er nicht den spezifischen Compartment-Code besitzt. Ein Logistikoffizier mit Freigabe für Secret darf ISR-Erkenntnisse nicht einsehen können, selbst wenn diese ebenfalls als Secret eingestuft sind. Geheimhaltungsstufe und Compartment-Zugehörigkeit sind orthogonale Zugriffsdimensionen, und beide müssen auf jeder Schicht des Systems durchgesetzt werden.
Air-Gap-Betrieb beseitigt jede Abhängigkeit von Cloud-verwalteten Diensten. Es gibt kein verwaltetes Kafka, keinen in der Cloud gehosteten Katalog, keinen vom Hersteller betriebenen Schlüsselverwaltungsdienst. Jede Komponente – Objektspeicher, Streaming-Broker, Query-Engine, Metadatenkatalog, Hardware für die Schlüsselverwaltung – muss On-Premises aus Paketen bereitstellbar sein, die über zugelassene Medien in die Air-Gap-Umgebung übertragen werden können. Diese Einschränkung schließt Architekturen aus, die aus dem Internet erreichbare Update-Endpunkte, Lizenzvalidierungsserver oder Telemetrie-Erfassungsdienste voraussetzen. Sie bedeutet zugleich, dass das Betriebsteam den gesamten Upgrade- und Patch-Lebenszyklus jeder Komponente ohne herstellerverwalteten Weg selbst verantwortet.
Einsatzkritische SLAs gelten sowohl für die Aktualität der Daten als auch für die Abfragelatenz. Ein ISR-Fusionsanalyst, der die jüngste Sensordatenaufnahme abfragt, kann kein mehrstündiges Spark-Batch-Zeitfenster akzeptieren. Ein Logistikoffizier, der ein Nachschubmodell erstellt, benötigt Abfrageergebnisse in Minuten, nicht in Tagen. Diese Anforderungen erzwingen Architekturentscheidungen, die kommerzielle Data Lakes oft aufschieben: ständig laufende Query-Engines, die ihre Abfragepläne bereits anhand aktueller Katalogstatistiken kompiliert haben, Hot-Tier-Speicher für aktuelle Daten und Streaming-Ingest, der neue Daten innerhalb von Sekunden nach Eingang abfragbar macht – und nicht erst im nächsten Batch-Fenster. Vertiefende Hintergründe zu den grundlegenden Mustern, die in den hier beschriebenen Schichten zum Einsatz kommen, finden Sie in unserem Leitfaden zu Datenintegrationsmustern im Verteidigungsbereich.
Eine vierte Anforderung, die kommerzielle Data Lakes ebenfalls nur unzureichend bedienen, ist die domänenübergreifende Datenintegration – das Verknüpfen von C2-Trackdaten, ISR-Sensordaten, Logistikdatensätzen und geospatialen Referenzebenen in einer einzigen Abfrage über Einstufungsgrenzen hinweg (mit angemessenen Kontrollen). In einem kommerziellen Lake sind domänenübergreifende Joins eine Annehmlichkeit des Data Engineering. In einem militärischen Lake sind sie der zentrale analytische Anwendungsfall – und sie müssen möglich sein, ohne die Durchsetzung der Einstufung aufzuweichen. Die Query-Engine muss Tabellen aus unterschiedlichen Datendomänen verknüpfen können und dabei auf jede Seite des Joins transparent tabellenbezogene Einstufungsfilter anwenden.
Design der Speicherschicht – Objektspeicher (MinIO/Ceph für On-Premises), mehrstufige Speicherung (Hot/Warm/Cold), Objektbenennung und Partitionierung für militärische Datendomänen
Objektspeicher ist das Fundament jeder modernen Data-Lake-Architektur, und für militärische Air-Gap-Einsätze verengt sich die Auswahl auf zwei praxiserprobte Plattformen: MinIO und Ceph. MinIO implementiert die vollständige AWS-S3-API mit AES-256-Verschlüsselung ruhender Daten, IAM-Richtlinien je Bucket sowie Versionierung und Sperrung auf Objektebene – und das ganz ohne Cloud-Abhängigkeit. Auf moderner NVMe-Hardware übertrifft seine Leistung die kommerzieller Cloud-Objektspeicher bei sequenziellen Schreib-Workloads, dem vorherrschenden Muster bei der Aufnahme von Sensordaten. Ceph stellt über sein RADOS Gateway Objekt-, Block- und Dateispeicher aus einem einzigen Cluster bereit und eignet sich damit für Umgebungen, in denen dieselbe physische Speicherinfrastruktur sowohl die Objekt-Workloads des Data Lake als auch Blockvolumes für virtuelle Maschinen bedienen muss. Für einen dedizierten Data-Lake-Einsatz ist MinIO betrieblich einfacher; Ceph ist die richtige Wahl, wenn der Speicher-Cluster zusätzlich Block- und Dateischnittstellen bereitstellen muss.
Die Isolation nach Einstufung wird auf Bucket-Ebene umgesetzt, nicht auf Objektebene. Jede Geheimhaltungsstufe hat einen eigenen Bucket-Namensraum:
Die Zonenstruktur – Raw, Structured, Curated – gliedert die Daten innerhalb jeder Geheimhaltungsstufe nach Verarbeitungsstufe. Die Raw-Zone enthält die Daten exakt so, wie sie von den Quellsystemen empfangen wurden, im nativen Format (CoT-XML, NIEM-XML, binäre Sensor-Streams, CSV-Logistikexporte). Nach dem Schreiben wird in der Raw-Zone nichts mehr verändert; sie ist ein unveränderlicher Audit-Nachweis dessen, was empfangen wurde. Die Structured-Zone enthält die Daten nach der Normalisierung in Parquet mit dem Delta-Lake-Tabellenformat – Schema erzwungen, Felder auf kanonische Namen abgebildet, Provenienz-Metadaten angehängt. Die Curated-Zone enthält für Analysten aufbereitete Aggregate, vorab verknüpfte domänenübergreifende Sichten und Zusammenfassungstabellen, die schnelle interaktive Abfragen ermöglichen, ohne dass jeder Analyst dieselbe Join-Logik selbst umsetzen muss.
Das Design der Objektschlüssel für die Structured-Zone kodiert alle Partitionsdimensionen, die für ein effizientes Query-Pushdown erforderlich sind:
Die mehrstufige Speicherung wird über die Lifecycle-Richtlinien von MinIO gesteuert. Das Hot-Tier nutzt NVMe-basierte Knoten und hält die Daten der letzten 30 Tage vor – aktuell genug, dass Analysten sie häufig für die laufende operative Analyse abfragen. Nach 30 Tagen wechseln Objekte in das Warm-Tier auf hochdichten Festplatten, wo sie weiterhin abfragbar bleiben, jedoch mit höherer Latenz. Nach 180 Tagen wechseln Objekte in das Cold-Tier auf hochdichtem Archivspeicher mit konfigurierbarer Abruflatenz. Die Schwellenwerte der Stufen sind je Domäne und je Geheimhaltungsstufe konfigurierbar – ISR-Sensordaten aus aktiven Einsatzgebieten können einen früheren Übergang vom Warm- ins Cold-Tier aufweisen als Logistik-Archivdaten.
Architektur der Ingest-Pipeline – C2-System-Feeds (CoT/NIEM), Aufnahme von ISR-Sensordaten, ETL für Logistiksysteme, Streaming- und Batch-Ingest-Muster im Vergleich
Die Ingest-Schicht muss drei grundlegend verschiedene Datengeschwindigkeitsprofile gleichzeitig bewältigen: hochfrequente Streaming-Feeds aus C2- und ISR-Systemen, die Tausende Ereignisse pro Minute erzeugen; strukturierte Feeds mittlerer Frequenz aus Logistik- und Planungssystemen, die Hunderte Datensätze pro Stunde erzeugen; und niederfrequente Batch-Exporte aus Altsystemen, die tägliche oder wöchentliche Dateiabzüge liefern. Diese Profile erfordern unterschiedliche Ingest-Muster, die an der Grenze zur Landing Zone sauber zusammenspielen müssen.
Apache Kafka ist das Streaming-Rückgrat für Echtzeit-Feeds. Das Topic-Design folgt derselben auf die Einstufung bezogenen Konvention wie der Speicher – jedem Topic wird seine Geheimhaltungsstufe vorangestellt, und Kafka-ACLs beschränken den Zugriff von Producern und Consumern nach Geheimhaltungsstufe. Die Namenskonvention für Topics kodiert Quelltyp und Systemidentität:
CoT/NIEM-Adapterdienste abonnieren die rohen C2-Topics, parsen das XML, bilden die Felder auf das kanonische Ingest-Schema ab, hängen Provenienz-Metadaten an (Quellsystem-ID, Erhebungszeitstempel, Geheimhaltungsstufe, Ursprungseinheit) und veröffentlichen in das normalisierte Topic. Das CoT-Parsing muss sowohl Standard-CoT-Felder als auch die von bestimmten C2-Systemen genutzten Erweiterungen des Detail-Elements verarbeiten – der Adapter darf Erweiterungsinhalte nicht stillschweigend verwerfen; er muss bekannte Erweiterungen entweder auf kanonische Felder abbilden oder in einer strukturierten Erweiterungsspalte erhalten. NIEM-Adapter verarbeiten deutlich komplexere Schemas – durch das modulare Design von NIEM kann eine NIEM-Austauschinstanz Typen aus mehreren NIEM-Kern- und Domänenschemas referenzieren, und der Adapter muss vor der Feldabbildung alle Referenzen auflösen. Der Adapter gibt eine flache Struktur mit einer Zeile pro Meldung aus, die sich für die Parquet-Speicherung eignet.
ISR-Sensor-Ingest unterscheidet sich je nach Sensortyp. Videoanalyse-Feeds von UAVs erzeugen Detektionsereignis-Datensätze – Begrenzungsrahmen, Detektionsklasse, Konfidenzwert, Frame-Zeitstempel, Sensorposition – mit Raten, die bei einer Multi-Stream-Plattform 10.000 Datensätze pro Minute überschreiten können. Diese müssen über Kafka mit Avro- oder Protobuf-Schemaerzwingung auf Producer-Seite aufgenommen werden, nicht nur auf Consumer-Seite. SIGINT-Empfänger erzeugen Datensätze zu abgefangenen Emittern mit Frequenz, Modulation, Pulsparametern, Peilung und TDOA-Daten. Radar-Feeds erzeugen Track-Meldungen mit Position, Geschwindigkeit und Track-Qualitätsmetriken. Jeder Sensortyp hat einen eigenen Adapter, der sein natives Format auf das kanonische ISR-Beobachtungsschema normalisiert, bevor der Datensatz die Landing Zone erreicht. Eine ausführliche Darstellung der Architektur für Echtzeit-Intelligence-Fusion finden Sie in unserem ergänzenden Artikel zur Stream-Verarbeitung aus mehreren Quellen.
Logistik-ETL arbeitet in der Regel im Batch-Modus – die meisten Logistik-ERP-Systeme erzeugen periodische Exporte statt Echtzeit-Änderungsströmen. Die ETL-Pipeline extrahiert Daten aus der Exportschnittstelle des Quellsystems (SFTP-Dateiablage, Datenbankabfrage oder REST-API-Abruf), validiert das Schema, wendet das Feldmapping auf das kanonische Logistikschema an und schreibt Parquet-Dateien in die Raw Landing Zone. Ein Spark-Job verarbeitet die Rohdateien anschließend nach einem Zeitplan, der mit dem Exporttakt des Quellsystems synchronisiert ist, in die Structured-Zone. Für Logistiksysteme, die Change Data Capture (CDC) über Datenbank-Log-Streaming unterstützen, ist der Streaming-Pfad vorzuziehen – er verkürzt die Zeit zwischen einem Logistikereignis und seiner Verfügbarkeit für Analyseabfragen von Stunden auf Minuten.
Die Datenqualitätsvalidierung beim Ingest ist nicht optional – sie ist der Mechanismus, der verhindert, dass fehlerhafte Daten die Structured-Zone erreichen und die Analytik verfälschen. Jeder Ingest-Adapter muss mindestens Folgendes durchführen: Validierung der Schemakonformität, Prüfungen der Provenienz-Vollständigkeit, Prüfungen der zeitlichen Plausibilität (Ereigniszeitstempel innerhalb plausibler Grenzen) und bei Geodaten eine Validierung des Koordinatenbereichs. Validierungsfehler werden in eine Dead-Letter-Queue geleitet, und zwar mit dem vollständigen ursprünglichen Nachrichteninhalt und einem strukturierten Fehlerdatensatz, der die konkret fehlgeschlagene Prüfung benennt.
Metadatenkatalog und Data Discovery – Einstufungs- und Caveat-Kennzeichnung in Metadaten, Schema-Registry, Nachverfolgung der Data Lineage, Such- und Discovery-UX für Analysten
Der Metadatenkatalog ist die Komponente, die den Data Lake für Analysten nutzbar macht, die ihn nicht selbst gebaut haben. Ohne Katalog ist der Data Lake eine Sammlung undurchsichtiger Parquet-Dateien im Objektspeicher, die nur die Ingenieure abzufragen wissen, die die Ingest-Adapter geschrieben haben. Mit einem gut befüllten Katalog kann jeder Analyst mit entsprechender Freigabe verfügbare Datenbestände entdecken, deren Schemas und Provenienz verstehen und Abfragen darauf aufbauen – ohne für jede neue analytische Fragestellung technische Unterstützung zu benötigen. Der Leitfaden zum Metadatenmanagement militärischer Datenkataloge behandelt den Katalogentwurf im Detail; dieser Abschnitt widmet sich seiner Integration in die Data-Lake-Architektur.
Apache Atlas ist der praxiserprobte Open-Source-Katalog für Umgebungen, die erweiterbare Metadatentypen, Lineage-Nachverfolgung und die Integration mit Werkzeugen des Hadoop-Ökosystems benötigen. Das Typsystem von Atlas erlaubt es, benutzerdefinierte Entitätstypen für Metadaten als vollwertige Schemaobjekte zu definieren – und nicht als Freitext-Annotationen –, was für die verteidigungsspezifischen Felder unverzichtbar ist, die bei der Registrierung eines Datenbestands obligatorisch sein müssen:
- ClassificationLevel – Aufzählungstyp: UNCLASSIFIED, CONFIDENTIAL, SECRET, TOP_SECRET. Obligatorisch für jede Entität eines Datenbestands. Steuert das Routing in Speicher-Buckets und die Auswertung der Zugriffskontrollrichtlinien.
- CaveatCodes – mehrwertige Zeichenkettenliste. Erfasst anwendbare Caveats wie NOFORN, Compartment-Kennungen und Handhabungshinweise. Muss beim Ingest befüllt oder als ausdrücklich leere Angabe belassen werden – null ist nicht zulässig.
- DataOwnerUnit – Zeichenkettenverweis auf die für den Datenbestand verantwortliche Organisationseinheit. Dient dem Routing im Data Stewardship und der Festlegung des Ansprechpartners für Datenzugriffsanfragen.
- RetentionPolicy – Verweis auf die anwendbare Aufbewahrungsregel, die die maximale Aufbewahrungsdauer, das Verfahren zum sicheren Löschen und die Stelle festlegt, die den Aufbewahrungszeitraum genehmigt hat.
- OriginatingSystem – Kennung des Quellsystems, das die Daten erzeugt hat. Dient der Lineage-Rückverfolgung und der Rückmeldung von Datenqualitätsproblemen an den Betreiber des Quellsystems.
Die Integration einer Schema Registry mit Apache Kafka stellt sicher, dass das Schema jedes Topics registriert und versioniert ist, bevor ein Producer mit dem Schreiben beginnt. Die Confluent Schema Registry (On-Premises ohne Cloud-Anbindung betreibbar) erzwingt Kompatibilitätsregeln für Avro- oder Protobuf-Schemas – BACKWARD-Kompatibilität für konsumentenseitige Topics bedeutet, dass neue Schemaversionen optionale Felder hinzufügen können, ohne bestehende Consumer zu beeinträchtigen. Jede Schemaversion ist von der Atlas-Katalogentität des zugehörigen Datenbestands aus verlinkt und liefert so eine vollständige Historie, wie sich die Struktur des Datenbestands im Laufe der Zeit entwickelt hat.
Die Nachverfolgung der Data Lineage in Atlas erfasst die Transformationskette vom rohen Ingest bis zur kuratierten Analysetabelle. Der Atlas-Hook von Spark sendet automatisch Lineage-Ereignisse, wenn ein Spark-Job aus einem in Atlas registrierten Datenbestand liest und in einen anderen schreibt. Die Atlas-Integration von Trino erfordert einen benutzerdefinierten Event-Listener, der festhält, auf welche Quelltabellen zugegriffen wurde, um ein Abfrageergebnis zu erzeugen. Der Lineage-Graph, den Atlas aus diesen Ereignissen aufbaut, erlaubt es einem Analysten, jeden Wert in einer kuratierten Analysetabelle über jeden Transformationsschritt bis zum ursprünglichen Rohdatensatz in der Landing Zone und weiter bis zum Quellsystem und zum ursprünglichen Erhebungsereignis zurückzuverfolgen. Diese Kette ist betrieblich wichtig – Analysten müssen häufig beurteilen, ob sich ein analytisches Ergebnis auf eine verlässliche Quelle zurückführen lässt – und eine Compliance-Anforderung für eingestufte Daten.
Such- und Discovery-Funktionen für Analysten setzen voraus, dass sich der Katalog nach den Attributen abfragen lässt, die Analysten tatsächlich verwenden: Datendomäne (C2, ISR, Logistik, Geodaten), abgedeckter Zeitraum, Geheimhaltungsstufe und Caveats (gefiltert auf das, was der Benutzer sehen darf) sowie Stichwortsuche über Beschreibungen von Datenbeständen und Spaltennamen. Die Such-API von Atlas unterstützt alle diese Dimensionen, doch die Zugriffskontrollschicht muss sicherstellen, dass die Suchergebnisse des Katalogs selbst nach Freigabe und Compartment-Zugehörigkeit des Benutzers gefiltert werden – ein Analyst darf nicht die Existenz eines Compartment-geschützten Datenbestands entdecken können, auf den er nicht zugreifen darf, auch wenn der Katalogeintrag die Inhalte des Datenbestands nicht offenlegt.
Compartment-basierte Zugriffskontrolle – attributbasierte Zugriffskontrolle (ABAC) zur Durchsetzung von Compartments, Sicherheit auf Zeilen- und Spaltenebene in Query-Engines, Audit-Protokollierung
Zugriffskontrolle in einem militärischen Data Lake ist keine einzelne Richtlinie – sie ist ein mehrschichtiger Durchsetzungsstapel, in dem jede Schicht auffängt, was die darüberliegende übersehen könnte. Die Schichten sind: Bucket-Richtlinien auf Speicherebene (wer welche Buckets lesen und beschreiben darf), Sichtbarkeitsrichtlinien auf Katalogebene (wer welche Datenbestände entdecken darf), Zeilen- und Spaltensicherheit auf Ebene der Query-Engine (welche Zeilen und Spalten ein Benutzer innerhalb eines Datenbestands sehen darf, auf den er zugreifen darf) und Audit-Protokollierung (worauf zugegriffen wurde, durch wen, wann und was zurückgegeben wurde). Alle vier Schichten müssen gleichzeitig aktiv sein – jede einzeln betriebene Schicht bietet nur Teilschutz.
Die attributbasierte Zugriffskontrolle (ABAC) ist das richtige Modell für die Dimensionen Einstufung und Compartment, weil RBAC durch die Rollenexplosion im großen Maßstab nicht mehr beherrschbar ist. Eine ABAC-Richtlinie wertet den Zugriff aus, indem sie eine Richtlinienfunktion über Benutzerattribute und Ressourcenattribute berechnet:
OPA wird als Sidecar des Trino-Coordinators betrieben. Wenn ein Analyst eine SQL-Abfrage absendet, ruft das Zugriffskontroll-Plugin von Trino OPA für jeden Tabellenverweis in der Abfrage auf und übergibt dabei die Identitätsattribute des authentifizierten Benutzers (vom Identity Provider) und die Ressourcenattribute der Tabelle (aus dem Katalog). OPA liefert eine Zulassen-/Ablehnen-Entscheidung zurück und gibt für zugelassene Tabellen das Zeilenfilter-Prädikat und die Spaltenmasken-Definitionen zurück, die in der Sitzung dieses Benutzers auf die Tabelle anzuwenden sind. Trino fügt die Zeilenfilter und Spaltenmasken transparent ein – die Abfrage des Analysten läuft wie geschrieben, das Ergebnis enthält jedoch nur die Zeilen und Spalten, die der Analyst sehen darf.
Die Sicherheit auf Zeilenebene in Trino hängt an die WHERE-Klausel jeder Abfrage gegen eine geschützte Tabelle ein Prädikat an. Bei einer Tabelle mit Datensätzen mehrerer Geheimhaltungsstufen beschränkt der Zeilenfilter die Abfrage auf Zeilen, deren Geheimhaltungsstufe im autorisierten Bereich des Benutzers liegt. Die Spaltenmaskierung ersetzt die Werte von Spalten, die der Benutzer nicht vollständig sehen darf, durch NULL oder ein String-Literal – ein Feld mit einer Compartment-Kennung kann beispielsweise für Benutzer mit der entsprechenden Compartment-Berechtigung sichtbar und für Benutzer ohne diese auf NULL maskiert sein.
Die Audit-Protokollierung muss jedes Abfrageereignis mit ausreichender Detailtiefe erfassen, um zu rekonstruieren, was der Benutzer gesehen hat. Die Mindestfelder eines Audit-Eintrags sind: Identität des authentifizierten Benutzers (nicht nur der Benutzername, sondern die vollständigen Attribute des Identity Providers), Zeitstempel der Abfrageeinreichung, Abfragetext, Liste der abgerufenen Tabellen mit ihren Geheimhaltungsstufen, je Tabelle zurückgegebene Zeilenanzahl, alle angewendeten Zeilenfilter- oder Spaltenmasken-Richtlinien sowie der Abschlussstatus der Abfrage. Audit-Einträge müssen in einen Append-only-Objektspeicher mit aktiviertem Object Lock geschrieben werden, damit sie selbst von Speicheradministratoren nicht verändert oder gelöscht werden können. Der Speicher für das Audit-Protokoll muss auf der höchsten Geheimhaltungsstufe liegen, die in einer Abfrage vorkommen kann, damit Audit-Einträge nicht selbst zu einem stufenübergreifenden Datenkanal werden.
Muster für Abfrage- und Analyse-Workloads – Trino/Presto für Ad-hoc-SQL über Objektspeicher, Spark für Batch-Analytik, Notebook-Umgebungen für Analysten
Ein militärischer Data Lake bedient zwei unterschiedliche Abfrage-Workload-Profile, die verschiedene Ausführungs-Engines erfordern, welche auf unterschiedliche Kostenfunktionen optimiert sind. Ad-hoc-Abfragen von Analysten priorisieren niedrige Latenz – ein Analyst, der eine Zielbewertung erstellt, braucht eine Antwort in Sekunden bis Minuten, nicht in Stunden. Batch-Analyse-Jobs priorisieren den Durchsatz – eine Data-Engineering-Pipeline, die den gesamten historischen Bestand an Sensordatensätzen für eine Pattern-of-Life-Analyse verarbeitet, kann längere Laufzeiten akzeptieren, wenn sie genaue, umfassende Ergebnisse liefert. Der Einsatz von Trino und Spark auf demselben Objektspeicher bedient beide Profile ohne Kompromisse.
Trino ist die bevorzugte Ad-hoc-Query-Engine für SQL-Analytik auf dem Data Lake. Sie liest Parquet- und Delta-Lake-Dateien über ihren Hive-Connector direkt aus dem Objektspeicher – kein Ladeschritt, kein ETL in eine separate Datenbank. Die verteilte Abfrageausführung von Trino zerlegt die Abfrage in Fragmente, die parallel auf Worker-Knoten ausgeführt werden, wobei Zwischenergebnisse über das Netzwerk ausgetauscht werden. Bei typischen Analystenabfragen – Filtern aktueller Sensordatensätze, Verknüpfen von C2-Tracks mit geospatialen Referenzebenen, Aggregieren des Logistikverbrauchs nach Einheit und Zeitraum – liefert Trino Ergebnisse in Sekunden bis Minuten auf Datenbeständen, die Hunderte Gigabyte an Parquet-Dateien umfassen. Die wichtigsten Tuning-Parameter für einen militärischen Data Lake sind: die Konfiguration des Partition Pruning (Trino muss WHERE-Klausel-Prädikate auf Partitionsspalten bis zur Auflistung im Objektspeicher durchreichen, um vollständige Bucket-Scans zu vermeiden), die Häufigkeit der Statistikerhebung (der kostenbasierte Optimierer von Trino benötigt genaue Tabellenstatistiken, um effiziente Join-Pläne zu erzeugen) und die Speichergrenzen der Worker (große Join-Abfragen können den Speicher je Worker überschreiten; die Konfiguration von Spill-to-Disk verhindert Out-of-Memory-Fehler, geht aber zulasten einer höheren Abfragelatenz).
Apache Spark ist die Batch-Analytics-Engine für Workloads, die die Verarbeitung des vollständigen Datenbestands oder komplexe iterative Berechnungen erfordern. Die Delta-Lake-Integration von Spark bietet ACID-Schreibsemantik – Batch-Jobs können mit Exactly-once-Garantien in Delta-Lake-Tabellen schreiben, und gleichzeitig lesende Spark- und Trino-Prozesse sehen über das MVCC-Protokoll von Delta Lake jederzeit einen konsistenten Snapshot der Tabelle. Typische Spark-Workloads in einem militärischen Data Lake sind:
- Nächtliche ETL-Jobs, die die Dateien der Raw Landing Zone aus den vorangegangenen 24 Stunden in die Structured-Zone verarbeiten – Parsen, Validieren, Normalisieren und Schreiben von Parquet mit Partitionsmetadaten
- Pattern-of-Life-Analyse über Wochen oder Monate historischer Track-Daten – Erkennung regelmäßiger Bewegungsmuster, häufiger Co-Location-Ereignisse und von Verhaltensänderungen im Zeitverlauf
- Entity-Resolution-Batch-Jobs, die doppelte Datensätze über Quellen hinweg für die kuratierte Entity-Master-Tabelle konsolidieren
- Pipelines zur Aufbereitung von Trainingsdaten für ML-Modelle – Feature-Extraktion aus rohen Sensordaten, Zusammenführung von Labels, Export des Datenbestands in das vom Trainings-Framework erwartete Format
- Datenqualitäts-Sweeps, die ein statistisches Profiling über die gesamte Structured-Zone ausführen, um Schema-Drift, Anomalien in der Wertverteilung und Lücken in den Provenienz-Metadaten zu erkennen
JupyterHub stellt die Notebook-Umgebung für Analysten bereit. Notebooks verbinden sich mit Trino für SQL-Abfragen und mit Spark für die programmatische Datenverarbeitung und verbinden so die explorative Flexibilität von Python mit den strukturierten Abfragefähigkeiten beider Engines. In einem Einsatz mit eingestuften Daten muss der JupyterHub-Server innerhalb des passenden Netzsegments der jeweiligen Geheimhaltungsstufe isoliert sein – jede Geheimhaltungsstufe benötigt eine eigene JupyterHub-Instanz, die mit den Trino- und Spark-Clustern innerhalb dieser Stufe verbunden ist. Von Analysten erstellte Notebooks müssen in der Curated-Zone des Data Lake gespeichert werden (nicht auf der lokalen Festplatte des JupyterHub-Servers), damit sie denselben Aufbewahrungs- und Audit-Richtlinien unterliegen wie andere Inhalte des Data Lake. Vorgefertigte Notebook-Vorlagen für gängige domänenübergreifende Join-Muster – C2-Tracks verknüpft mit ISR-Sensordetektionen, Logistikverbrauch verknüpft mit Einsatzberichten – verkürzen die Zeit, die ein Analyst mit dem Schreiben von Standard-Abfragecode verbringen muss, bevor er seine analytische Fragestellung erreicht.
Datenqualität und Governance – Datenqualitätsprüfungen beim Ingest, Stammdatenmanagement für Entitätsreferenzen, Richtlinien zur Datenaufbewahrung und -vernichtung für eingestufte Daten
Data Governance in einem militärischen Data Lake ist keine Dokumentationsübung – sie ist eine operative Disziplin, die entscheidet, ob den vom Lake erzeugten Analysen für Entscheidungen vertraut werden kann. Ein Analyst, der feststellt, dass eine Zielbewertung auf Daten beruhte, die ihre Qualitätsprüfungen nicht bestanden haben, aber bis in die Curated-Zone durchgelassen wurden, hat das Vertrauen in die gesamte Analyseplattform verloren. Governance-Mechanismen müssen automatisch durchgesetzt werden und dürfen sich nicht darauf verlassen, dass Analysten den Zustand der Datenqualität kennen.
Datenqualitätsprüfungen beim Ingest (beschrieben im Abschnitt zur Ingest-Pipeline) sind die erste Governance-Schranke. Die zweite Schranke ist ein täglicher Datenqualitäts-Sweep über die Structured-Zone mit Apache Spark. Der Sweep führt einen konfigurierbaren Satz von Prüfungen für jeden registrierten Datenbestand aus:
- Vollständigkeitsprüfungen – Prozentsatz der Nicht-Null-Werte bei Pflichtfeldern; jeder Datenbestand, bei dem ein Pflichtfeld unter 95 % Vollständigkeit fällt, löst einen Alarm an den Data Steward aus
- Prüfungen der Wertverteilung – das statistische Profiling numerischer Spalten erkennt plötzliche Verschiebungen der Verteilung, die auf eine Fehlkalibrierung von Sensoren, Änderungen des Koordinatensystems oder ETL-Fehler hindeuten können
- Prüfungen der referenziellen Integrität – Fremdschlüsselbeziehungen zwischen Datenbeständen (z. B. müssen in Sensordatensätzen referenzierte Track-Entitäts-IDs im C2-Entity-Master vorhanden sein) werden täglich validiert, um verwaiste Referenzen zu erkennen, die durch Probleme bei der Ingest-Reihenfolge entstehen
- Aktualitätsprüfungen – jeder Datenbestand hat eine maximal erwartete Ingest-Latenz; Datenbestände, die innerhalb dieses Zeitfensters keine neuen Datensätze erhalten haben, lösen einen Alarm aus, der auf einen Ausfall des Quellsystems oder eine Netzwerkpartitionierung hindeuten kann
Das Stammdatenmanagement (Master Data Management, MDM) für Entitätsreferenzen ist der Governance-Mechanismus, der die Verbreitung inkonsistenter Entitätskennungen über Datendomänen hinweg verhindert. Im militärischen Kontext sind die wichtigsten Entitäten, die MDM erfordern: Einheiten und Verbände (mit ihren hierarchischen Beziehungen und ihrer aktuellen Einsatzgliederung), Ausrüstungsgegenstände (mit Modell, Variante und zugeordneter Einheit), geografische Objekte und Einrichtungen (mit eingestuften und nicht eingestuften Namen) sowie Personal (mit Freigabe- und Zuordnungsdatensätzen). Jeder dieser Entitätstypen benötigt in der Entity-Master-Tabelle einen Golden Record, der als maßgebliche Referenz für Joins über Datendomänen hinweg dient. Ohne einen gepflegten Entity Master erhalten Analysten, die ISR-Sensordatensätze mit C2-Einheitsdatensätzen verknüpfen, Join-Fehler oder fehlerhafte Ergebnisse, sobald dieselbe Einheit in verschiedenen Quellsystemen unter unterschiedlichen Kennungen geführt wird – ein häufiges Problem in militärischen Datenumgebungen mit mehreren Quellen.
Für Aufbewahrung und Vernichtung eingestufter Daten ist das kryptografische Löschen der Standardmechanismus. Der Datenverschlüsselungsschlüssel (DEK) jeder Geheimhaltungsstufe wird in einem Hardware-Sicherheitsmodul (HSM) gespeichert. Löst eine Aufbewahrungsrichtlinie die Vernichtung eines Datenbestands aus, zerstört das HSM den DEK der betroffenen Objekte, statt potenziell Petabytes an verschlüsselten Daten objektweise zu überschreiben. Nach der Zerstörung des DEK sind die verschlüsselten Objekte rechnerisch nicht wiederherstellbar – die Anforderung des sicheren Löschens ist erfüllt, ohne die betriebliche Last mehrfacher Überschreibverfahren im Petabyte-Maßstab. Der Löschdienst, der die DEK-Zerstörung ausführt, muss jedes Löschereignis in einem unveränderlichen Audit-Trail protokollieren, der Folgendes festhält:
- Die Kennung des betroffenen Datenbestands und das betroffene Präfix des Objektpfads
- Die Anzahl der Objekte, deren Verschlüsselungsschlüssel zerstört wurde
- Die Aufbewahrungsregel, die die Vernichtung ausgelöst hat (mit Regel-ID und Version)
- Die Identität des automatisierten Dienstes oder menschlichen Principals, der die Vernichtung autorisiert hat
- Ein kryptografischer Hash des DEK zum Zeitpunkt der Zerstörung (als Nachweis, dass der Schlüssel vor der Zerstörung existierte, ohne den Schlüssel selbst aufzubewahren)
- Der Zeitstempel der DEK-Zerstörung und der HSM-Attestierungsnachweis, der das Zerstörungsereignis bestätigt
Das Governance-Rahmenwerk ist nur wirksam, wenn seine Ergebnisse für die Personen sichtbar sind, die für die Datenqualität verantwortlich sind. Ein tägliches Governance-Dashboard – aufgebaut aus den Ergebnissen des Datenqualitäts-Sweeps, den Metriken zur Vollständigkeit der Katalogregistrierung, dem Compliance-Status der Aufbewahrungsrichtlinien und den Zusammenfassungen der Audit-Protokolle – gibt Data Stewards die nötige Sichtbarkeit, um Probleme zu erkennen und zu beheben, bevor sie sich auf die für Analysten bestimmten kuratierten Datenbestände ausbreiten. Das Dashboard selbst muss im passenden Netzsegment der jeweiligen Geheimhaltungsstufe betrieben werden, und seine Daten dürfen ausschließlich aus diesem Segment stammen – ein Governance-Dashboard für als Secret eingestufte Daten darf keine Metriken aus einer Monitoring-Infrastruktur der Stufe Unclassified beziehen. Governance als nachrangige Angelegenheit zu behandeln, die sich die Infrastruktur mit Diensten niedrigerer Geheimhaltungsstufe teilen darf, ist ein verbreiteter Architekturfehler, der sowohl ein Compliance-Risiko als auch einen operativen blinden Fleck für die Datenqualität der sensibelsten Inhalte des Lake schafft.