Data Platform & Data Management

Mehr als ein Jahr nach der Einführung der Datenschutz-Grundverordnung (DSGVO) fällt es vielen Unternehmen noch immer schwer, die Themen Data Warehouse (DWH) und Datenschutz unter einen Hut zu bringen. Die in den Unternehmen vorherrschende kundenzentrierte Datenmodellierung ist hierbei eine besondere Herausforderung. Sie führt bei vielen Anforderungen der DSGVO zu großen Problemen in nahezu allen datengetriebenen Prozessen. Doch warum ist es so schwer, die beiden Themen miteinander zu vereinen?

Ausgangssituation

Um ein wirksames Customer Relationship Management einsetzen zu können, ist es, besonders im Bereich des Kampagnenmanagements, von großer Bedeutung,  aussagekräftiges Wissen über die eigenen Kunden und Kundenstrukturen zu haben. Persönliche Informationen über Kunden, Ereignisse und Veränderungen in Kundensituation und -verhalten in einem CRM-System können als Anlass für eine auftretende Kommunikation genutzt werden. Mit Hilfe dieser vorhandenen Daten wird eine personalisierte Interaktion mit dem Kunden, wie Angebote und Services, ermöglicht.

Viele Unternehmen beginnen derzeit, erste Erfahrungen mit dem Einsatz von Big-Data-Methoden zu machen. Diese Methoden versprechen, aus großen Mengen an meist unstrukturierten Daten in kürzester Zeit mittels statistischer Methoden zusätzliches Wissen über die Kunden zu generieren. Häufig werden dazu automatisch generierte Daten eingesetzt, wie zum Beispiel Logfiles oder auch Clickstreams, die aus der Nutzung der Webseite, eines Webshops oder den Daten aus sozialen Netzen erhoben werden. Dieses Wissen kann wertvoll für CRM-Aktivitäten eingesetzt werden. Dabei stellt sich die Frage der Bedeutung von Datenqualität bei Einsatz von Big-Data-Methoden. Denn: Die Analyse und damit das generierte Wissen kann nur so gut sein wie die Qualität der dazu verwendeten Daten.

Die Rolle des Kunden

Die zentrale Rolle des Kunden für die Unternehmensausrichtung wird in der Wissenschaft seit Jahrzehnten diskutiert:

"It costs much more to acquire a customer than it does to keep a customer. That is why a sale to a customer is good, but a relationship with a customer is great." [1]

"Personal data are the fuel of the modern economy." [2]

"In a global information-based economy, data about customers are one of the most important sources for competitive advantage." [3]

Noch einmal möchte ich mich mit dem Thema Speichernutzung auseinandersetzen. In anderen Blogartikeln wie „SAP HANA – kein Speicher mehr? Bewusster Early Unload!“ ist bereits die Relevanz der korrekten Einstellung der SAP-BW-Objekte für die vorgesehene Nutzung aufgezeigt worden. Zusammengefasst: Immer alles frühzeitig aus dem Speicher schieben, was nicht immer und sofort für Abfragen benötigt wird. Gesteuert wird dies über die „Early Unload Priority“, die in der HANA-Datenbank auf Tabellenebene gesetzt wird. Da diese Einstellungen nicht im ABAP-Transportwesen (CTS) enthalten sind, muss der Entwickler oder der Betrieb sicherstellen, dass diese Einstellung immer korrekt gesetzt ist. Ansonsten liegen nur für das Staging benötigte Daten aus dem „Data Acquisition Layer“ sehr performant im RAM, was unnötig teuer ist und das System belastet.

Nach jahrelanger Arbeit an der Entwicklung von ETL-Anwendungen kann ich sagen, dass sie üblicherweise schlechter als Transaktionssysteme geprüft werden.

In diesem Beitrag wird es nun um die Protegrity-Plattform im Detail und das Zusammenspiel mit Exasol gehen. Die Protegrity-Plattform hat den Anspruch, einen weitreichenden Schutz der Daten entlang verschiedener Applikationen und Datenspeicher End2End zu realisieren.

Part 1: Anpassung der Gültigkeit des Datensatzes

Der Oracle Data Integrator (ODI) bietet eine eingebaute Lösung, um Daten mit der SCD-Methodik (Slowly Changing Dimension) zu historisieren. Bei näherer Betrachtung und der praktischen Beladung einer Integrationsmenge in eine Zieltabelle mithilfe des Integration Knowledge Modules (IKM) SCD fällt auf, dass der ODI gewisse "Default Values" für das Gültigkeitsende des Datensatzes verwendet.

In Zeiten der Digitalisierung ist es besonders wichtig, auf verlässliche Datenbanken zurückgreifen zu können, um Fehlerquellen auszuschließen und zielstrebiges und exaktes Arbeiten zu ermöglichen. Die Staging-Area stellt für diese Art von Anforderungen in der heutigen Zeit eine Lösung bereit. Designer und Architekten unterschätzen häufig die Notwendigkeit einer Staging-Area in der Datenbanklandschaft, da sie dies für eine Verschwendung von Platz, Leistung und Entwicklungszeit halten. Sicher ist für den Aufbau von Staging Platz und Anstrengung erforderlich, doch diese zahlt sich über den gesamten Lebenszyklus der Datenbank aus.

In Teil 1 & Teil 2 dieser Blogreihe haben wir gezeigt, wie man einen AWS Data Lake aufbaut und Daten in ein Data Lakehouse importiert. Im dritten und letzten Teil erklären wir, wie man in einem Lakehouse das „Recht auf Vergessenwerden“gemäß DSGVO implementiert und durchsetzt. Wir werden sowohl den Data Lake als auch das Date Warehouse, deren Aufbau wir in den vorherigen Blogbeiträgen beschrieben haben, mit der Ausübung dieses Rechts konform machen. Doch zunächst einmal gilt es zu klären, was man überhaupt unter dem Recht auf Vergessenwerden versteht.