Blog

Die Europäische Zentralbank (EZB) sowie viele andere Aufsichtsbehörden erkannten in der Analyse der Ursachen der Finanzkrise 2008 unter anderem große Defizite in der IT und Datenarchitektur der Institute. Diese Defizite führten dazu, dass Risikobewertungen nicht schnell und präzise genug und nicht vollständig durchgeführt werden konnten. Kurz gesprochen: Risiken konnten weder im angemessenen Maße berichtet noch kontrolliert werden. Aus dieser Lehre heraus wurde von dem Baseler Ausschuss für Bankenaufsicht (engl. Basel Committee on Banking Supervision, kurz BCBS) der vielseits durch die Presse bekannte Standard 239 veröffentlicht, auch bekannt als „Principles for effective risk data aggregation and risk reporting“ bzw. als AT 4.3.4 der MaRisk.

Immer neue Datenquellen und Anwendungsgebiete sorgen auch weiterhin für den stetigen Ausbau von Datenhaltungssystemen, wie DWH, Data Lake oder Analytics Platform. Mit den erweiterten Anforderungen müssen auch die Datenbewirtschaftungsprozesse Schritt halten. Nicht selten wachsen kleine BI-Anwendungen zu großen Initiativen, an denen mehrere Entwicklerteams beteiligt sind. In vielen Branchen müssen Anpassungen schneller vorgenommen werden als jemals zuvor, was die Lage zusätzlich verschärft. Den Teams wird dadurch eine kurze Reaktionszeit sowie eine hohe Flexibilität abverlangt, die jedoch nicht zuletzt von der Infrastruktur getragen werden muss.

Immer noch das Problem: Ordner oder Laufwerke katalogisieren

Im letzten Eintrag haben wir in einer Lösung von weniger als zehn Zeilen mit einer rekursiven Funktion die Möglichkeit geschaffen, Ordner zu scannen und die Dateien nach Änderungsdatum und Dateigröße auswertbar zu machen.

Aufbauend auf diesem Beispiel möchte ich die Latte nochmal etwas höher legen und noch bessere Alternativen aufzeigen.

Das Problem: Ordner oder Laufwerke katalogisieren

Vor kurzem wurde mir von Kollegen im Projekt die Frage gestellt, ob man mit Python nicht den Inhalt von Laufwerken katalogisieren könne. Natürlich geht das, und der Aufwand hierfür ist so überschaubar, dass ich hier das Beispiel nutzen möchte, um die wichtigsten Best-Practice-Empfehlungen für das Arbeiten mit Laufwerkspfaden zu erläutern.

Was leistet Snowflake als Cloud-DB?

Snowflake ist eine native Cloud-DB und läuft auf AWS und inzwischen auch auf Azure. Die Internetverbindung vom Client zur Cloud und die Daten innerhalb der DB sind verschlüsselt. Dabei kann es während der Ausführung beliebig und automatisch hochskalieren und am Ende wieder herunterschalten. Da für das (Speicher-)Volumen und die Ausführungszeit gezahlt wird, können so durch die geringen Zeiten Kosten gespart werden. Eine ausführliche Online-Dokumentation ist unter folgender URL verfügbar: https://docs.snowflake.net/manuals/index.html

Man muss übrigens kein AWS-Kunde sein, um Snowflake verwenden zu können. Snowflake selbst bietet als Cloud-DB-Service keine eigenen ETL-Tools an, sondern überlässt dies den Herstellern von ETL-, Reporting- oder Self-Service-BI-Tools. Diese bieten meist native Treiber und Connections an, um ihre Tools mit Snowflake verwenden zu können. Soll im Unternehmen kein separates ETL-Tool eingesetzt werden, gibt es verschiedene Möglichkeiten, die Daten zu laden und die ETL-Strecken zu realisieren. Das Umsetzen der Logik in SQL und die Orchestrierung über Python ist dabei ein möglicher Weg.

Dieser Blogbeitrag beantwortet zwei Fragebereiche:

1. Für wen ist ein Recommendation System relevant? Warum?
2. Welche grundsätzlichen Varianten gibt es? Wie aufwändig ist eine dementsprechende Implementierung?

Große Teile an bisher manueller Programmierung können durch DWA-Tools abgelöst oder zumindest stark vereinfacht werden. Welche Teile der Entwicklung dabei genau automatisiert werden können, kann von Tool zu Tool stark differieren. So gibt es Ansätze von reinen Code-Generatoren, mithilfe derer Datenbankstrukturen und ETL-/ELT-Prozesse automatisch generiert werden können („design-time“). Auf der anderen Seite existieren umfangreiche Integrationssuiten, die den gesamten DWH-Lebenszyklus, von der Bereitstellung der Daten in den Quellen bis hin zu den Data Marts, generieren, aber auch verwalten können („run-time“).

Bei der Entwicklung gibt es eine Reihe von Aufgaben, bei denen ein DWA-Tool unterstützen kann. Im Folgenden wird insbesondere auf die Bereiche Reverse Engineering und Kompatibilität, Analyse, Implementierung und Rahmenbedingungen eingegangen.

Durch die verstärkte Nutzung des Internets und des Smartphones ändert sich zunehmend auch das Konsumentenverhalten der User. Mit zunehmender Digitalisierung der Kanäle und Touchpoints ist der Kunde heute besser denn je informiert und damit schwerer zu fassen. Das Konsumentenverhalten auch digital einzufangen, auszuwerten und zu verstehen, dazu muss der Marketingverantwortliche heute zielgenaue Segmente bilden und eine darauf abgestimmte Strategie für potentielle Customer Touchpoints erstellen, um den Kunden auf dem richtigen Kanal zum richtigen Zeitpunkt mit dem richtigen Angebot anzusprechen und ihn auf der anderen Seite nicht mit E-Mails oder Push-Nachrichten zu überfluten.

Gerade im Umfeld von HCM und den Infotyp-Tabellen werden häufig Fullloads für eine Versorgung eines SAP BW genutzt, da eine eindeutige Erkennung von Änderungen (CRUD – Create, Read, Update und Delete) im Quellsystem nicht möglich ist. Zum Beispiel sind Termine (Infotyp 0019) nicht mit einer vollständigen Gültigkeit versehen, sodass bei einer Löschung kein neuer Datensatz erstellt wird, der diesen Zeitraum überschreibt. Im Quellsystem könnte der Einsatz vom SLT/RS (SAP Landscape Transformation/Replication Server) mit seiner Trigger-basierten Erkennung von Änderungen auf Datenbankebene jede einzelne Anpassung an den Daten überwachen. Allerdings ist ein Einsatz aufgrund der verhältnismäßig geringen Datenmenge nicht unbedingt notwendig und auch eine Änderungsverfolgung wäre an dieser Stelle „übertrieben“. (Bitte beachten Sie, dass der SLT/RS zum Teil in aktuellen SAP-BW-Lizenzpaketen mit enthalten ist und somit häufig genutzt werden kann, jedoch eine Installation auf dem Quellsystem benötigt.)

Im ersten Teil dieses Blogs ging es darum, möglichst einfach eine CSV-Datei nach Avro zu serialisieren und das Ergebnis in Kafka abzulegen, wobei das Schema in der Schema-Registry registriert werden sollte.

Ein wichtiger Baustein für ein Planungssystem ist der Umgang mit dem Thema Intercompany (IC). IC tritt immer dann auf, wenn unterschiedliche Wirtschaftseinheiten eines Unternehmensverbundes untereinander Waren oder Dienstleistungen austauschen. Die daraus resultierenden Aufwände und Erträge, aber auch Forderungen und Verbindlichkeiten müssen transparent und gegeneinander abgrenzbar sein. Da die Planung durch eine Vielzahl von Planungsteilnehmern durchgeführt wird, ist die IC-Abstimmung und auch die darauffolgende IC-Eliminierung nicht trivial.

Auch in modernen Umgebungen ist CSV noch ein häufig anzutreffendes Austauschformat, da viele bestehende Systeme mit moderneren Alternativen nicht umgehen können. Zur Weiterverarbeitung in einer Big-Data-Umgebung sind jedoch andere Formate besser geeignet. Im Zusammenhang mit Kafka ist das vor allem Avro. Avro bietet ein platzsparendes Datenformat mit vielen Features, in dem das Datenschema ebenfalls mit übertragen wird. Um die Handhabung zu verbessern, kann zudem das Schema in einem Schema-Repository registriert werden.