Data Platform & Data Management

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.

Auf Grundlage unseres vorherigen Blogbeitrags sollten sich unsere transformierten Daten nun im Data Lake befinden und im Glue-Datenkalalog zur Verfügung stehen. Im zweiten Artikel unserer Blogreihe klären wir nun, was AWS Lake Formation ist und wie Du es nutzen kannst, um unbefugten Datenzugriff zu verhindern.

Diese komplette und schrittweise schnelle Demo zeigt Ihnen, wie man eine existierende Datenquelle intern mit einer modernen Cloud-Warehouse-Lösung wie Snowflake verbindet:  

• Einfach
• Schnell
• Sicher und
• ohne eine einzige Codezeile schreiben zu müssen.