BI-Plattformen in der Cloud ermöglichen es Unternehmen, große Datenmengen schnell und effizient zu analysieren. Insbesondere in Public Clouds stehen diesen Vorteilen meist Datenschutzbedenken gegenüber. Dieser Vortrag zeigt, wie Datenschutzanforderungen erfüllt werden können, ohne dabei große Kompromisse eingehen zu müssen. Anhand eines Use Cases wird aufgezeigt, wie ein klassisches DWH an eine moderne BI-Plattform in der Cloud angebunden werden kann, ohne dabei Daten im Klartext außerhalb des Unternehmens speichern zu müssen.

Zielpublikum: Geschäftsführer, BI-Analysten, IT-Verantwortliche
Voraussetzungen: Grundlegendes Know-how über BI-Plattformen und Cloud-Systeme
Schwierigkeitsgrad: Einsteiger

Extended Abstract:
Die digitale Welt ist schnell. Unternehmen geraten schnell unter Druck, wenn sie nicht in der Lage sind, sich an schnell verändernde Marktanforderungen anzupassen. Es sind daher meist die Fachabteilungen, die ein modernes Business Intelligence (BI) Tool fordern, um Daten sammeln, analysieren und visualisieren zu können. Sie benötigen jene Informationen, um das Unternehmen steuern und richtige Entscheidungen treffen zu können.

IT-Abteilungen sind dann meist diejenigen, die mit den daraus resultierenden immer schneller wachsenden fachlichen Anforderungen konfrontiert werden und technische Lösungen dafür bereitstellen sollen. Dabei sind stetig wachsende Datenmengen ebenso eine wesentliche Herausforderung wie unterschiedliche Datenformate. Insbesondere die immer größer werdende Bedeutung von Echtzeitdaten aus Streams oder semi- & unstrukturierte Daten aus IoT-Geräten haben dem oftmals über mehrere Jahre hinweg entwickelten und gepflegten klassischen Data Warehouse seine Grenzen aufgezeigt.

Ein möglicher Ansatz, diesen Herausforderungen zu begegnen, ist der Gang zu einem der großen Public-Cloud-Anbieter. Während die Möglichkeiten hinsichtlich der Skalierung von Ressourcen dabei helfen, mit ständig steigenden Datenmengen umgehen zu können, helfen diverse Managed Services dabei, unterschiedlichste Datenformate verarbeiten und konsolidieren zu können.

Schnell zum K.O.-Kriterium wird hierbei oft der Datenschutz. Besonders dann, wenn personenbezogene Daten verarbeitet werden müssen und diese Deutschland oder sogar die EU verlassen könnten, wird es kompliziert. Die meisten großen Public-Cloud-Anbieter bieten zwar mittlerweile Lösungen wie ein garantiertes Hosting in Deutschland, betrachtet man diese Option jedoch näher, wird man oftmals schnell enttäuscht: Datenspeicherung in Deutschland ja, Datenverarbeitung in Deutschland nur teilweise. Manche Services sind mit einem garantierten Betrieb in Deutschland sogar gar nicht verfügbar. Der Netzwerktraffic und über welche Knoten dieser läuft und vor allem, in welchen Ländern sich die Knoten denn befinden, ist das nächste Thema, was beachtet werden muss. Zugegeben: Das Thema neigt dazu, schnell zu einer akademischen Diskussion zu werden.

Eine ganz andere Frage, die sich jedes Unternehmen aber erst mal grundsätzlich stellen muss, ist: Möchte ich das überhaupt? Möchte ich, dass unternehmenskritische Informationen außerhalb meines Einflussbereiches gespeichert werden? Auch diese Diskussion kann man schnell in eine akademische Richtung bringen: Werden Daten nicht eh schon aus der Hand gegeben, sobald ich nicht selbst entwickelte Software einsetze? Ob großer Cloud-Anbieter oder lokales Rechenzentrum, liegt dazwischen nicht oftmals eh schon das Internet?

In diesem Vortrag werden keine akademischen Diskussionen geführt. Anhand eines konkreten Use Case aus der Praxis zeigen wir, wie sich Daten in der Cloud speichern und verarbeiten lassen, ohne dabei die Daten aus der eigenen Hand zu geben. Wir zeigen, wie Datenschutzanforderungen erfüllt werden können, ohne dass Anwender auf Features einer modernen BI-Plattform in der Cloud verzichten müssen.

Im Use Case dient ein klassisches, lokal betriebenes Data Warehouse als Quelle. Welche Datenbank- und ETL-Software im Einsatz ist, spielt keine gesonderte Rolle. Es wird aufgezeigt, wie eine gesicherte Übertragung der Daten auf einen Managed Service in der Cloud erfolgen kann. Konkret wird hier eine Azure SQL Database auf Microsoft Azure verwendet. Die Daten werden auf der Azure SQL Database verschlüsselt - also nicht im Klartext - gespeichert. Dies kann für die ganze Datenbank, für einzelne Tabellen oder auf Spaltenebene pro Tabelle erfolgen. Die Entschlüsselung der Daten findet erst zur Laufzeit während des Zugriffs eines Anwenders aus Microsoft Power BI heraus statt.

Worauf es dabei zu achten gilt, ist wie die Infrastruktur auf Microsoft Azure dafür aufgesetzt werden muss. Welche Software-Features und Services genau zum Einsatz kommen, ist ebenfalls Bestandteil dieses Vortrages.

Um komplexe Metriken live bei Änderungen von Daten in einem Planungstool für den Anlagenbau anzeigen zu können, wurde eine 3-schichtige Architektur mit Datenbanktriggern entwickelt. Diese löst bestehende langsame Views ab, die zu langen Ladezeiten der UI führten. Eine Trennung von Datenselektion, Businesslogik und Schreibzugriff sorgt für strukturierten Code. Ebenso sorgt die exakte Selektion der Daten, die aktualisiert werden müssen, für effiziente Trigger. Probleme bei der Wartung werden über eine strukturierte Dokumentation gelöst.

Zielpublikum: Entwickler:innen, Datenbankentwickler:innen, Software-Architekt:innen
Voraussetzungen: Datenbankgrundlagen
Schwierigkeitsgrad: Einsteiger

Extended Abstract:
Bei der Entwicklung eines Planungstools für den Anlagenbau im Rahmen eines Kundenprojekts kam die Anforderung auf, dass komplexe Metriken basierend auf den aktuell eingegebenen Daten live aktualisiert werden. Im ersten Entwicklungsschritt wurde dies mithilfe von Datenbankviews umgesetzt. Steigende Datenmengen führten dazu, dass die Antwortzeiten der UI zu langsam wurden. Eine zeitlich versetzte Aktualisierung von vorberechneten Metriken war nicht möglich.

Als Lösung wurde eine 3-schichtige Architektur mit Datenbanktriggern implementiert. Die erste Schicht besteht aus den Triggern selbst, in denen bestimmt wird, was aktualisiert werden muss. Einerseits werden die Zeilen bestimmt, die aktualisiert werden müssen. Diese werden in einer In-Memory-Tabelle gespeichert. Andererseits werden auch die Spalten/Metriken bestimmt, die sich verändert haben können. Jede Metrik wird über eine Update-Prozedur repräsentiert. Die Trigger wählen also aus, welche Prozeduren aufgerufen werden müssen und welche Zeilen aktualisiert werden sollen. Durch die exakte Auswahl dessen, was aktualisiert werden muss, wird die Effizienz der Trigger verbessert.

Die Update-Prozeduren bilden die zweite Schicht und sind alle nach dem gleichen Prinzip aufgebaut. Sie erhalten als Eingabe die In-Memory-Tabelle mit den Ids der Zeilen, die aktualisiert werden müssen. Danach rufen sie die existierenden Views auf, in denen die Businesslogik abgebildet wurde, und aktualisieren die materialisierten Metriken für die selektierten Zeilen.

Die Wiederverwendung der existierenden Views ersparte bei der Entwicklung erheblich Zeit, da die komplexe Businesslogik nicht erneut implementiert werden musste. Die Trennung der Selektion der Zeilen im Trigger, der Schreibprozeduren und der Businesslogik verhindert Code-Duplikation. Der Grund dafür ist, dass Trigger auf unterschiedlichen Tabellen mit unterschiedlichen Selektionskriterien dieselbe Update-Prozedur aufrufen können. Aufgrund der Anzahl an Metriken und der Anzahl an Tabellen, die Einfluss auf die Metriken haben, wurde eine strukturierte Dokumentation eingeführt, um die Wartbarkeit zu gewährleisten.

Es wurde eine Performanceanalyse durchgeführt, inwieweit die Trigger den Lesezugriff durch Materialisierung der Daten beschleunigen und inwieweit die Trigger den Schreibzugriff verlangsamen. Die Trigger wurden so definiert, dass sie pro Statement ausgeführt werden, um Bulkoperationen effizient zu ermöglichen, da diese im System neben Einzeloperationen auch häufig vorkommen. Es stellte sich heraus, dass die Schreibprozesse im System während der Einführung der Trigger überarbeitet werden mussten. Die Schreibprozesse waren noch nicht dahingehend optimiert, dass sie mit möglichst wenig einzelnen Schreiboperationen arbeiteten. Es mussten also Schleifen im Code mit einzelnen Updates oder Inserts in Batch-Statements umgeschrieben werden.

This presentation will examine the creation of data products through ETL pipelines and the value they provide through insights. We'll focus on the advantages of test-driven development in ETL and how Azure DevOps and Databricks play key roles in the pipeline. We'll also cover the implementation of a Git-based CICD workflow to automate and guarantee the quality of the generated data products. By the end of the presentation, attendees will have a solid understanding of the benefits of test-driven development in ETL pipelines.

Target Audience: Data Engineer, Data Scientist
Prerequisites: Basic knowledge in ETL processes
Level: Basic

Extended Abstract:
In this presentation, we will discuss the process of generating data products through ETL pipelines to derive valuable insights. The use of test-driven development (TDD) will be a central theme, as we explore how this approach can help to ensure the accuracy and reliability of the data products generated. We will focus on the use of Azure DevOps and Databricks as key components in the pipeline, and how these technologies can be leveraged to provide efficient and streamlined data processing.

Additionally, we will explore the implementation of a Continuous Integration and Continuous Deployment (CICD) workflow using Git, which automates the development and deployment process, allowing for rapid iterations and reduced downtime. The use of Git also provides a reliable mechanism for version control and collaboration between team members.

One of the key highlights of the presentation will be the use of a test data generator powered by artificial intelligence. This tool will be used to generate realistic test data for use in the TDD process, ensuring that the pipeline code is thoroughly tested and ready for production deployment. This will be an important factor in ensuring the accuracy and reliability of the data products generated.

By the end of the presentation, attendees will have a comprehensive understanding of the benefits of TDD in ETL pipelines and how it can be used to produce high-quality data products that provide valuable insights. They will also gain an understanding of how Azure DevOps, Databricks, and Git can be used in conjunction with TDD to create a streamlined and efficient data processing workflow.

Die DEVK setzt seit 2019 das Bestandssystem IPM für das Sachgeschäft ein. Für das notwendige Reporting und Analysen haben wir uns für eine quellsystemnahe Auswertungslösung entschieden. Diese nutzt die Besonderheit des IPM-Datenmodells, keine Datensätze zu verändern oder zu löschen sowie die zentrale Historisierung des Systems. Der Vortrag berichtet von unserem Vorgehen zur Ermittlung von Delta-Zeitscheiben für die Bewirtschaftung, der zweizeitigen Zeitraumhistorisierung und den zusätzlichen Tabellen zur Vereinfachung von Auswertungen.

Zielpublikum: Data Engineer, Entscheider:innen
Voraussetzungen: Grundlegende Datenbankkenntnisse
Schwierigkeitsgrad: Einsteiger

Will man Daten unter Berücksichtigung einer zweizeitigen Historisierung mit Von- und Bis- Zeiträumen ablegen, kann man dies durch Hinzufügen der Historien-Felder an die Nutzdaten oder durch Auslagerung der Historieninformationen in einer separaten Tabelle erreichen. Der Vortrag gibt eine Einführung in die Grundlagen der bi-temporalen Historisierung und beleuchtet die Vor- und Nachteile beider Verfahren unter Berücksichtigung der Abfrageperformance unter Oracle.

Zielpublikum: Data Engineer, Data Scientist, Analyst:innen
Voraussetzungen: Grundlegende SQL-Kenntnisse
Schwierigkeitsgrad: Fortgeschritten