Falls Sie den ersten Teil über die Grundlagen des High-Performance-Computing (HPC) noch nicht gelesen haben, schauen Sie doch gleich mal rein!
Während traditionelle Engineering-Simulationssoftware mechanische Ingenieure hervorragend bei der Vorbereitung, Ausführung und Analyse von Simulationsaufgaben unterstützt, fehlt ihr ein natives Design zur Verwaltung moderner Workflows und Datenpipelines für maschinelles Lernen (M.L.). Ein offenes Data-Lakehouse kann diese Lücke schließen und F&E-Ingenieuren robuste, zeitgenössische Fähigkeiten auf einer Plattform bieten, mit der die IT-Abteilung wahrscheinlich bereits vertraut ist.
Zu den wichtigsten Anwendungsfällen und Vorteilen eines offenen Data Lakehouse gehören:
Kosteneffiziente, kontrollierte Datenarchivierung: Bietet praktisch unbegrenzten, kostengünstigen Speicherplatz für die Archivierung jahrelanger Simulations-Snapshots (die von Solver-Sitzungen generierten Datensätze). Dieser Speicher wird in allen Engineering- und IT-Organisationen bzw. -Teams einheitlich verwaltet und geregelt. Entscheidend ist, dass für jeden Datensatz wichtige Metadaten und die Herkunftsdaten erhalten bleiben, wodurch er von einer undurchsichtigen Datei zu einer vertrauenswürdigen Ressource wird, die auch über den ursprünglichen Ersteller hinaus problemlos wiederverwendet werden kann.
Vereinfachter Zugriff auf Rechenressourcen: Entwickler können gemeinsam genutzte Notebooks und Apache Spark- oder Python Ray-Cluster einfach und schnell bereitstellen. Diese teilen sich oft die gleichen dedizierten GPU-Ressourcen, die vom Haupt-HPC-Cluster verwendet werden.
Schutz durch offene Standards: Ein offenes Data Lakehouse priorisiert offene Standards wie Apache Iceberg, Parquet und Python gegenüber proprietären Entwicklungsformaten. Das ist entscheidend, um das geistige Eigentum (IP) eines Unternehmens zu schützen und sicherzustellen, dass Simulationsdaten von jedem Tool sowohl jetzt als auch in Zukunft zugänglich und nutzbar bleiben, unabhängig von der sich entwickelnden IT-Infrastruktur oder der Anbieterstrategie des Unternehmens.
Ein PaaS-Erlebnis wie in der Cloud: Data Lakehouses, die als benutzerfreundliche Self-Service-PaaS-Stacks (Platform-as-a-Service) aufgebaut sind, vereinfachen die Nutzung komplexer Data-Engineering- und MLOps-Tools, überbrücken so effektiv die Wissenslücke zwischen Anwendern mit unterschiedlichem technischen Hintergrund und fördern einen produktiven Kompetenzaustausch.
Ein Data Lakehouse bietet zwar viele Vorteile, ist jedoch für stark regulierte Branchen (wie Luft- und Raumfahrt, Verteidigung, Energie und Automobilindustrie), in denen Souveränität eine unverzichtbare Voraussetzung ist, für sich genommen keine vollständige Lösung. Einfach ausgedrückt: Nicht jedes Data Lakehouse lässt sich unter Einhaltung der Vorschriften zur Datensouveränität bereitstellen und betreiben, und die Nutzung der öffentlichen Cloud birgt erhebliche Risiken für die Aufrechterhaltung einer strengen Kontrolle über firmeneigenes geistiges Eigentum.
Eine einzelne Momentaufnahme eines CFD-Projekts (Computational Fluid Dynamics) – wie etwa die Entwicklung eines neuen Motors – stellt beispielsweise den kompletten Entwurf seiner Leistung und seines Industriedesigns dar; dieser Datensatz ist das Kronjuwel eines Unternehmens. Es ist daher von entscheidender Bedeutung zu ermitteln, welche wichtigen nicht-funktionalen Fähigkeiten eines Data Lakehouse die absolute rechtliche Gewissheit der operativen Souveränität bieten können, die für die Speicherung solcher strategischer Werte erforderlich ist. Dies führt direkt zum Kern der Debatte um Datenresidenz vs. Datensouveränität.
Die traditionelle Definition von Souveränität als Tätigkeit im Heimatland eines Unternehmens ist ein veraltetes Konzept, ein Überbleibsel aus der Zeit vor der Cloud. Bisher wurde die Infrastruktur von Rechenzentren in der Regel von lokalem Personal verwaltet, wodurch sie naturgemäß der lokalen Gerichtsbarkeit und den rechtlichen Verpflichtungen des Unternehmens unterstand. Die Zunahme kommerzieller Cloud-Angebote und die Notwendigkeit für Anbieter, rund um die Uhr extrem hohe Service-Level-Ziele zu garantieren, haben jedoch den globalen Cloud-Betrieb per Remote-Zugriff vollständig ermöglicht. Durch diese Entwicklung ist es – zumindest in Regionen mit kommerziellen Standards – unmöglich, den Standort des Managementteams zu garantieren, wodurch die Verbindung zwischen „Datenstandort“ und echter „Souveränität“ unterbrochen wird.
Die zuverlässigste Architektur für die Handhabung und Verarbeitung wichtiger technischer Daten ist daher ein souveränes Data Lakehouse: ein offenes Data Lakehouse, das von Haus aus hybrid und Cloud-unabhängig ist.
Dieser Ansatz bietet die Geschwindigkeit und Einfachheit einer Cloud-ähnlichen PaaS-Erfahrung sowie eine von Grund auf gewährleistete Konformität. Dadurch kann ein Unternehmen nationale oder andere rechtliche Vorgaben erfüllen, die den Betrieb vollständig innerhalb einer souveränen, privaten und kontrollierten Umgebung (und mit entsprechendem Personal) vorschreiben würden.
Begriff |
Erklärung |
Wirtschaftliche Auswirkungen |
Datenresidenzeit |
Die Daten befinden sich physisch auf Hardware innerhalb der geopolitischen Grenzen eines bestimmten Landes. |
Erfüllt grundlegende lokale Compliance-Anforderungen, die nicht unbedingt mit der Sicherheit zusammenhängen, sondern hauptsächlich mit der Latenz zwischen den Daten selbst und den IT-Lösungen, die diesen speziellen Datensatz verwenden. |
Operative Souveränität |
Stellt sicher, dass sowohl die für die Verwaltung der Cloud-Infrastruktur zuständigen Mitarbeitenden (Cloud Ops) als auch der für den Anbieter geltende rechtliche Rahmen lokal angesiedelt sind und der richtigen staatlichen Aufsicht unterliegen. |
Beugt dem Risiko von Zugriffsanfragen ausländischer Regierungen vor, die den Anbieter rechtlich dazu zwingen könnten, vertrauliches geistiges Eigentum ohne Zustimmung des Unternehmens herauszugeben. |
Neben Sicherheit und der Einhaltung gesetzlicher Bestimmungen bietet eine souveräne Data-Lakehouse-Architektur einen weiteren entscheidenden Vorteil: ein planbares Kostenmanagement für die Implementierung von KI-Workflows.
Das Finanzmodell für den Betrieb von KI-Diensten in der Public Cloud ist von Natur aus variabel und verbrauchsbasiert, wobei die Kosten direkt an Nutzungsmetriken (wie GPU-Stunden, verarbeitete Token, Betriebsvolumen und gescannte Daten) verknüpft sind. Je mehr Teams, Projekte und Anwendungen die Cloud-Infrastruktur nutzen, desto stärker steigen die Kosten exponentiell. Dieses Modell ist besonders herausfordernd für anspruchsvolle Aufgaben wie das Training komplexer generativer KI-Modelle (GenAI) oder schwerer Autoencoder, die eine dedizierte, konstante und massive GPU-Nutzung erfordern, die oft schwer effizient zu teilen ist.
Die Umstellung auf ein souveränes Data Lakehouse, das in einem privaten oder kostengünstigen Colocation-Rechenzentrum bereitgestellt wird, ermöglicht einem Unternehmen vorhersehbare Ausgaben durch Folgendes:
Aufbau von Investitionen in Sachanlagen: Unternehmen investieren in feste, gemeinsam nutzbare Infrastruktur. Diese Konfiguration ermöglicht es mehreren Teams und Projekten, dieselben Ressourcen zu nutzen, wodurch die Grenzkosten für die Einleitung neuer F&E-Experimente effektiv auf nahezu null gesenkt werden.
Vermeidung von „Rechnungsschocks“: Diese Architektur beseitigt jegliches finanzielle Risiko, das mit unerwarteten, enormen Kosten verbunden ist, wie sie beispielsweise durch Inferenz mit hohem Datenvolumen, kontinuierliche iterative F&E-Trainingszyklen oder die in Public-Cloud-Zonen üblichen unerschwinglichen Datenübertragungsgebühren entstehen.
This may have been caused by one of the following: