Datenmanagement ist einer der Königsdisziplinen der IT. Immer mehr Unternehmen setzen dabei auf Datenpipelines, um das Potenzial ihrer Daten möglichst schnell entfalten zu können und die Wünsche ihrer Kunden zu erfüllen.
In meinem Blogbeitrag „Was ist eine Datenpipeline?“ habe ich den Begriff und die Bedeutung einer Datenpipeline von der theoretischen Seite betrachtet. Nochmals zusammengefasst, geht es dabei um das Prozessmanagement von Daten. Im zweiten Teil des Glossar-Beitrags „Wie funktioniert eine Datapipeline?“ haben wir auch die Funktionsweise einer Datenpipeline ausführlich betrachtet.
Datenpipelines sind somit nichts weiter als automatisierte oder automatisierbare Prozesse (siehe auch Blogbeitrag), bei denen Daten von einem Ort zu einem anderen bewegt werden. Genauer betrachtet, können neben der Gewinnung und Bereinigung auch die Bereitstellung der Daten komplett automatisiert werden.
Datenpipelines bestehen im Wesentlichen aus drei Stufen:
Die Verantwortung der Datenpipelines liegt je nach Organisationsstruktur und Größe eines Unternehmens entweder bei Data Engineers oder Data Scientists.
Als Zielsystem wird oftmals ein Datenpool definiert. Das kann beispielsweise ein Data Warehouse, aber auch ein Data Lake sein, und je nachdem, welchen Zweck die Datenpipeline erfüllen soll, kann es sein, dass bei den anschließenden Analysen der Daten keinerlei Rückschlüsse auf real existierende Personen erlaubt sind. An dieser Stelle können Lösungen, wie beispielsweise Libelle DataMasking ins Spiel kommen, um Daten durch Anonymisierung oder Pseudonymisierung zu verfremden. Der Vorteil unserer Lösung ist, dass sie sich sehr einfach in bereits bestehende Prozesse integrieren lässt.
Wie diese Integration vonstattengehen kann, möchte ich an zwei Praxisbeispielen erläutern.
In dem ersten Projekt gibt es zwei komplett unterschiedliche Datenquellen, die Basis für eine Datenpipeline sind. Auf der einen Seite steht ein SAP-System als erstes System in der Prozesskette. Auf der anderen Seite gibt es eine Applikation, die nicht SAP-spezifisch ist. Auch wenn die Daten aus unterschiedlichen Quellen stammen, sind sie in sich konsistent und erfüllen bestimmte Kriterien.
Für die oben erwähnte Stufe 2 werden die Daten aus dem SAP-System über eine definierte Schnittstelle extrahiert und in eine zwischengeschaltete Datenbank importiert, in der sie für die weitere Verarbeitung bearbeitet werden.
Im Fall der Nicht-SAP-spezifischen Applikation werden die Daten für Stufe 2 aus dem Tool extrahiert bzw. exportiert, hier in strukturierte Textdateien.
In dieser zweiten Stufe, in der die Daten aus beiden Quellen transformiert werden müssen, ist einer der Zwischenschritte die zwingend erforderliche Anonymisierung der Daten unter Zuhilfenahme von Libelle DataMasking, weil der Personenkreis, der mit diesen Daten schlussendlich arbeiten soll, keine Echtdaten sehen darf.
Wie erwähnt, werden die aus SAP stammenden Daten zunächst in eine weitere Datenbank geladen, in der sie zur Weiterverarbeitung aufbereitet werden. Nach der Aufbereitung erfolgt die Anonymisierung für bestimmte Eigenschaften der Daten.
Nach dem Export der Daten aus der Nicht-SAP-Applikation werden diese Dateien sofort anonymisiert, und zwar so, dass das Verhältnis zu den SAP-basierten Daten gewahrt, sprich, dass die Konsistenz der Daten erhalten bleibt.
Der abschließende Schritt in der 2. Stufe ist der Weitertransport bzw. Transfer der nun verfremdeten Daten in das Zielsystem. In dem Projekt handelt es sich dabei um ein Data Warehouse, mit dessen Hilfe die Daten analysiert werden können. Genauso gut ist es aber auch möglich, diese Daten für Testzwecke zu nutzen.
Ganz anders ist das Vorgehen in dem zweiten Projekt. Bei der Datenpipeline, die dort vorzufinden ist, handelt es sich um eine Stapelverarbeitungspipeline, die hochgradig automatisiert abläuft.
Das Quellsystem ist eine produktive Datenbank. Im zweiten Schritt der Pipeline, dem Verarbeiten und Transformieren der Daten, wird diese Datenbank zunächst geklont. Bereits dieser Schritt erfolgt skriptgesteuert vollautomatisiert und einem festgelegten Zeitpunkt außerhalb der regulären Geschäfts- und Arbeitszeiten.
Aufgrund interner Vorgaben sind die Datenanalysten, die letzten Endes mit den Daten arbeiten sollen, nicht berechtigt, Echtdaten zu sehen. Aus diesem Grund erfolgt unmittelbar nach Fertigstellung des Klons das Anonymisieren der Daten mit Libelle DataMasking. Auch dieser Teilschritt ist vollumfänglich automatisiert und erfolgt skriptgesteuert außerhalb der Geschäftszeiten. Bei der Einrichtung der Datenpipeline wurden die zu anonymisierenden Daten einmalig festgelegt. Beim automatisierten Antriggern der Anonymisierung ist daher die Nutzung des browserbasierten Frontends nicht notwendig.
In Schritt 3 werden die Daten zum zuständigen Fachbereich für den vorgesehenen Zweck zur Verfügung stellt.
Beide Beispiele zeigen, wie einfach sich Libelle DataMasking in bestehende Abläufe integrieren lässt. Insbesondere das zweite Beispiel zeigt auch, dass die automatisierte Datenpipeline durch Libelle DataMasking nicht ins Stocken gerät, sondern weiterhin reibungslos funktioniert.