SBB Cargo – Data Lake

Das Silo-Problem

In modernen Unternehmen sind Daten allgegenwärtig und stammen aus einer Vielzahl unterschiedlicher Quellen, wie zum Beispiel:

– Unternehmenswebsite(s)

– Unternehmens-App(s)

– IoT-Geräte

–  CRMs

– Soziale Medien

– Bestands- und Logistiktools (wie SAP)

– Data Warehouses

– Interne Berichte

– Vertriebskanäle

Was auch immer

Das Hauptproblem eines solchen Szenarios besteht darin, dass jede dieser Daten in sogenannten „vertikalen Silos“ gespeichert wird und diese Silos nicht für den datenübergreifenden Austausch ausgelegt sind.

Dieses Grundproblem führt zu vielen weiteren Schwierigkeiten:

– Der Versuch, diese Daten mit Aggregationstools und siloübergreifend zu analysieren, erfordert viel fehleranfällige und mühsame Handarbeit, einschliesslich Datenexport, Datenextraktion und Tabellenkalkulations-„Mambo-Jambos“: Innerhalb weniger Jahre verfügen Unternehmen schliesslich über eine Reihe von handgefertigten Tools.

– Solche selbst entwickelten Tools sind sehr anfällig und stark von der Person abhängig, die sie ursprünglich implementiert hat, was ihre Wartung zu einem Albtraum macht.

– Wenn es um Daten geht, ist unklar, was die „einzige Quelle der Wahrheit“ ist.

– Noch unklarer ist, wo sich die Daten befinden, insbesondere in mittelgrossen bis grossen Unternehmen.

– Rohdaten (unbearbeitete Daten) fehlen oft.

Der Data Lake 

Eine Möglichkeit, das Problem der „vertikalen Silos“ zu lösen, ist der Aufbau eines Data Lake. Dies ist ein Ort, an dem Daten aus verschiedenen Quellen auf einheitliche Weise gespeichert und abgerufen werden können. Die Daten werden in ihrem natürlichen/Rohformat gespeichert, was eine spätere Datenbearbeitung ermöglicht. Manchmal werden auch transformierte Daten im Data Lake gespeichert; diese sind für Aufgaben wie Berichterstellung, Visualisierung, erweiterte Analysen und maschinelles Lernen erforderlich.

In der Regel wird die „Herkunft“ der Daten (woher die Daten stammen, wann sie erfasst und bearbeitet wurden und von wem/was) zusammen mit den Datensätzen gespeichert (als Metadaten oder auf eine leicht durchsuchbare Weise).

Was ist eine Datenpipeline? 

Um einen Data Lake zu „befüllen“, müssen Worker bereitgestellt werden, die Daten aus Quellen (Silos) erfassen. Jeder Worker ist für eine bestimmte Datenquelle zuständig und mit Diensten verbunden, die eine weitere Datenanalyse nahezu in Echtzeit ermöglichen. Diese Kombination aus Funktionen (Worker + Dienste) wird gemeinhin als „Datenpipelines“ bezeichnet. Analog zu Wasserpumpen und -rohren werden Daten aus Quellen extrahiert („gepumpt“) und „fliessen“ durch Dienste, bis sie in Data Lakes oder spezifischen Speicher-/Datenbanklösungen landen.

Der Aufbau eines Data Lake und die Befüllung von Datenpipelines kann erreicht werden durch:

a) On-Prem-Dienste
b) Cloud-basierte, selbstverwaltete Dienste
c) Cloud-basierte, vollständig verwaltete Dienste
d) Cloud-basierte serverlose Infrastruktur

Der Aufwand für den Betrieb der genannten Architekturen nimmt von a) bis d) deutlich ab.

Bei a) liegt der gesamte Betriebsaufwand beim IT-Team, einschliesslich der Hardwareverwaltung.
Bei d) muss sich das IT-Team ausschliesslich auf Folgendes konzentrieren:

– Entwicklung der Anwendungslogik (Worker-Logik)
– Einsatz der richtigen Tools für die jeweilige Aufgabe und Nutzung ihrer APIs unter Beachtung bewährter Sicherheitspraktiken.

Da Data Lakes viele bewegliche Teile und unterschiedliche Technologien beinhalten, ist der vollständige Umstieg auf Serverless eine Option, die es wert ist, in Betracht gezogen zu werden, um die betriebliche Komplexität zu reduzieren.

Die in dieser Implementierung verwendeten Dienste sind:

– AWS Lambda als Recheninfrastruktur zur Ausführung von Data-Sourcing-Workern und Transformation-Workern

– AWS Kinesis Stream / Firehose als Anbieter von Datenstromdiensten

– Amazon S3 als Speichersystem für den Data Lake

– AWS KMS als Verschlüsselungsdienst

– AWS System Manager Parameter Store als Repository für Geheimnisse

– AWS IAM zur Definition von Richtlinien und Rollen

Lassen Sie uns kurz auf jede Komponente eingehen, um die Logik hinter den architektonischen Entscheidungen zu analysieren.

Data Sourcing Worker => AWS Lambda:

Dieser Worker muss eine Verbindung zum Silo/Dienst herstellen und Daten daraus extrahieren. Je nach Art der Daten und ihrer Verwendung könnte dieser Worker mehrmals täglich oder kontinuierlich ausgeführt werden. In einer serverlosen Umgebung auf AWS stehen folgende Optionen zur Auswahl:

Lambda (geplante Ausführung)

Ein auf ECS bereitgestellter Container, der Fargate als Recheninfrastruktur nutzt (kontinuierliche Ausführung)

Wir haben uns für Lambda entschieden, da der Kunde eine Datenpipeline-Architektur wünschte, die mit unterschiedlichen Datenfrequenzen umgehen kann; für nahezu kontinuierliche Datenströme bietet eine kurze Aufrufrate in Verbindung mit kleinen Datensätzen pro Ausführung eine gute Lösung, um eine einfache Lambda-Funktion anstelle eines komplizierteren containerisierten Workers zu verwenden, wobei auch die architektonische Konsistenz bei diskreten Datenströmen gewahrt bleibt.

Transformations-Worker => AWS Lambda:

Dieser Worker transformiert Daten nach bestimmten Kriterien, die von der jeweiligen Datenquelle abhängen. Lambda ist die empfohlene Lösung für den Einsatz zusammen mit AWS Kinesis Firehose. Ein Eingabeereignis wird von Kinesis mit Rohdaten aus der Quelle generiert, Lambda verarbeitet und transformiert die Daten gemäss der durch Code implementierten Logik, und die transformierten Daten werden an Kinesis Firehose zurückgesendet, damit sie dort gespeichert werden können.

Stream-Service => Kinesis Stream / Firehose:

Streams sind besonders nützlich bei der Datenerfassung, da sie Eingabedaten für einen konfigurierbaren Zeitraum puffern und eine pluggbare Architektur ermöglichen, um Daten im Batch-Modus und/oder nahezu in Echtzeit zu verarbeiten, zu analysieren und zu nutzen. Kinesis Firehose ist ein serverloser, verwalteter Datenstromdienst, dessen Zweck darin besteht, Daten kontinuierlich an einen bestimmten Zieltyp zu übertragen. In diesem speziellen Fall ist das Ziel ein S3-Bucket. Wie Kinesis Stream kann Firehose Ereignisse generieren, die an die darin fliessenden Daten angehängt werden. Diese Ereignisse können verwendet werden, um Code über Lambda auszuführen oder komplexe Aufgaben mithilfe von AWS Step-Functions oder anderen AWS-Diensten auszulösen.

Data Lake => Amazon S3:

Unbegrenzte Speicherkapazität, konfigurierbare Lebenszyklusrichtlinien und benutzerdefinierte Metadaten sind ideal für den Aufbau eines Data Lake. Amazon S3 bietet all dies zusammen mit einer leistungsstarken API und einer nahtlosen Integration mit anderen AWS-Diensten wie Firehose. Der Data Lake kann aus einem einzelnen Bucket oder aus mehreren bestehen (Rohdaten, transformierte Daten, aggregierte Daten…)

Sicherheit 1 => KMS:

Daten während der Übertragung und im Ruhezustand werden mithilfe von KMS mit CMKs (Customer Master Keys) mit begrenztem Geltungsbereich verschlüsselt

Sicherheit 2 => Lambda-spezifische Rolle und Richtlinien:

Lambda-Funktionen werden mit eingeschränkten Berechtigungen ausgeführt, die durch IAM-Richtliniendokumente festgelegt sind, die einer bestimmten Rolle zugeordnet sind, welche wiederum der Lambda-Funktion zugewiesen ist.

Sicherheit 3 => Geheimnisse:

Zur Speicherung von Geheimnissen und dienstweiten Parametern wird der Parameter Store verwendet. Geheimnisse werden als Secure-Strings gespeichert und mit KMS unter Verwendung eines dedizierten CMK verschlüsselt

Bei AWS dreht sich alles um Auswahlmöglichkeiten, daher gibt es Dienste, mit denen sich jede der zuvor genannten Architekturen aufbauen lässt. Kunden können von einer vollständig lokalen Lösung (Miete von Bare-Metal-Maschinen) bis hin zu einer vollständig serverlosen, ereignisgesteuerten Infrastruktur wechseln. Und selbst in einem serverlosen Szenario stehen mehrere Optionen zur Auswahl.