Whitepaper „Data-Management“: Wenn Daten auf Reisen gehen

Datenmanagement ist heutzutage ein komplexes Thema und schon lange nicht mehr nur die Aufgabe der Abteilung „EDV“. Unstrukturierte Daten von Sensoren, Maschinen und Anlagen haben einen langen Weg durch das Unternehmen, bevor sie Mehrwerte liefern.

Innovative, digitale Kundenservices erfordern neue Infrastrukturen und Cloudanwendungen in der Umsetzung. Wie Sie mit Ihren Daten auf Reisen gehen, ohne unnötige Risiken einzugehen, zeigt Ihnen das gut gelaunte Autorenteam in der praktischen Sommerausgabe dieses Whitepapers. Erfrischend geschrieben, konstruktiv beispielhaft und mit einer optischen Aufmachung, die auch am Strand einen guten Eindruck macht.

Die gut umgesetzte Idee der Autoren können Sie sich als Download oder sogar als Taschenbuch kostenlos zuschicken lassen. Auf der Website www.pack-die-daten-ein.de werden Sie fündig. Wer sich schnell auf die Datenreise begibt, wird belohnt. Das Autorenteam bedankt sich bei den ersten 25 Lesern für ihr Interesse mit einer Original OGIO-Reisetasche. Ob Download oder Taschenbuch, es ist ein sehr angenehmer Service und Bereicherung für die Sommerreise.

Whitepaper - Pack die Daten ein

Erstellen und benutzen einer Geodatenbank

In diesem Artikel soll es im Gegensatz zum vorherigen Artikel Alles über Geodaten weniger darum gehen, was man denn alles mit Geodaten machen kann, dafür aber mehr darum wie man dies anstellt. Es wird gezeigt, wie man aus dem öffentlich verfügbaren Datensatz des OpenStreetMap-Projekts eine Geodatenbank erstellt und einige Beispiele dafür gegeben, wie man diese abfragen und benutzen kann.

Wahl der Datenbank

Prinzipiell gibt es zwei große “geo-kompatible” OpenSource-Datenbanken bzw. “Datenbank-AddOn’s”: Spatialite, welches auf SQLite aufbaut, und PostGIS, das PostgreSQL verwendet.

PostGIS bietet zum Teil eine einfachere Syntax, welche manchmal weniger Tipparbeit verursacht. So kann man zum Beispiel um die Entfernung zwischen zwei Orten zu ermitteln einfach schreiben:

während dies in Spatialite “nur” mit einer normalen Funktion möglich ist:

Trotztdem wird in diesem Artikel Spatialite (also SQLite) verwendet, da dessen Einrichtung deutlich einfacher ist (schließlich sollen interessierte sich alle Ergebnisse des Artikels problemlos nachbauen können, ohne hierfür einen eigenen Datenbankserver aufsetzen zu müssen).

Der Hauptunterschied zwischen PostgreSQL und SQLite (eigentlich der Unterschied zwischen SQLite und den meissten anderen Datenbanken) ist, dass für PostgreSQL im Hintergrund ein Server laufen muss, an welchen die entsprechenden Queries gesendet werden, während SQLite ein “normales” Programm (also kein Client-Server-System) ist welches die Queries selber auswertet.

Hierdurch fällt beim Aufsetzen der Datenbank eine ganze Menge an Konfigurationsarbeit weg: Welche Benutzer gibt es bzw. akzeptiert der Server? Welcher Benutzer bekommt welche Rechte? Über welche Verbindung wird auf den Server zugegriffen? Wie wird die Sicherheit dieser Verbindung sichergestellt? …

Während all dies bei SQLite (und damit auch Spatialite) wegfällt und die Einrichtung der Datenbank eigentlich nur “installieren und fertig” ist, muss auf der anderen Seite aber auch gesagt werden dass SQLite nicht gut für Szenarien geeignet ist, in welchen viele Benutzer gleichzeitig (insbesondere schreibenden) Zugriff auf die Datenbank benötigen.

Benötigte Software und ein Beispieldatensatz

Was wird für diesen Artikel an Software benötigt?

SQLite3 als Datenbank

libspatialite als “Geoplugin” für SQLite

spatialite-tools zum erstellen der Datenbank aus dem OpenStreetMaps (*.osm.pbf) Format

python3, die beiden GeoModule spatialite, folium und cartopy, sowie die Module pandas und matplotlib (letztere gehören im Bereich der Datenauswertung mit Python sowieso zum Standart). Für pandas gibt es noch die Erweiterung geopandas sowie eine praktisch unüberschaubare Anzahl weiterer geographischer Module aber bereits mit den genannten lassen sich eine Menge interessanter Dinge herausfinden.

– und natürlich einen Geodatensatz: Zum Beispiel sind aus dem OpenStreetMap-Projekt extrahierte Datensätze hier zu finden.

Es ist ratsam, sich hier erst einmal einen kleinen Datensatz herunterzuladen (wie zum Beispiel einen der Stadtstaaten Bremen, Hamburg oder Berlin). Zum einen dauert die Konvertierung des .osm.pbf-Formats in eine Spatialite-Datenbank bei größeren Datensätzen unter Umständen sehr lange, zum anderen ist die fertige Datenbank um ein vielfaches größer als die stark gepackte Originaldatei (für “nur” Deutschland ist die fertige Datenbank bereits ca. 30 GB groß und man lässt die Konvertierung (zumindest am eigenen Laptop) am besten über Nacht laufen – willkommen im Bereich “BigData”).

Erstellen eine Geodatenbank aus OpenStreetMap-Daten

Nach dem Herunterladen eines Datensatzes der Wahl im *.osm.pbf-Format kann hieraus recht einfach mit folgendem Befehl aus dem Paket spatialite-tools die Datenbank erstellt werden:

Erkunden der erstellten Geodatenbank

Nach Ausführen des obigen Befehls sollte nun eine Datei mit dem gewählten Namen (im Beispiel bremen-latest.sqlite) im aktuellen Ordner vorhanden sein – dies ist bereits die fertige Datenbank. Zunächst sollte man mit dieser Datenbank erst einmal dasselbe machen, wie mit jeder anderen Datenbank auch: Sich erst einmal eine Weile hinsetzen und schauen was alles an Daten in der Datenbank vorhanden und vor allem wo diese Daten in der erstellten Tabellenstruktur zu finden sind. Auch wenn dieses Umschauen prinzipiell auch vollständig über die Shell oder in Python möglich ist, sind hier Programme mit graphischer Benutzeroberfläche (z. B. spatialite-gui oder QGIS) sehr hilfreich und sparen nicht nur eine Menge Zeit sondern vor allem auch Tipparbeit. Wer dies tut, wird feststellen, dass sich in der generierten Datenbank einige dutzend Tabellen mit Namen wie pt_addresses, ln_highway und pg_boundary befinden.

Die Benennung der Tabellen folgt dem Prinzip, dass pt_*-Tabellen Punkte im Geokoordinatensystem wie z. B. Adressen, Shops, Bäckereien und ähnliches enthalten. ln_*-Tabellen enthalten hingegen geographische Entitäten, welche sich als Linien darstellen lassen, wie beispielsweise Straßen, Hochspannungsleitungen, Schienen, ect. Zuletzt gibt es die pg_*-Tabellen welche Polygone – also Flächen einer bestimmten Form enthalten. Dazu zählen Landesgrenzen, Bundesländer, Inseln, Postleitzahlengebiete, Landnutzung, aber auch Gebäude, da auch diese jeweils eine Grundfläche besitzen. In dem genannten Datensatz sind die Grundflächen von Gebäuden – zumindest in Europa – nahezu vollständig. Aber auch der Rest der Welt ist für ein “Wikipedia der Kartographie” insbesondere in halbwegs besiedelten Gebieten bemerkenswert gut erfasst, auch wenn nicht unbedingt davon ausgegangen werden kann, dass abgelegenere Gegenden (z. B. irgendwo auf dem Land in Südamerika) jedes Gebäude eingezeichnet ist.

Verwenden der Erstellten Datenbank

Auf diese Datenbank kann nun entweder direkt aus der Shell über den Befehl

zugegriffen werden oder man nutzt das gleichnamige Python-Paket:

Nach Eingabe der obigen Befehle in eine Python-Konsole, ein Jupyter-Notebook oder ein anderes Programm, welches die Anbindung an den Python-Interpreter ermöglicht, können die von der Datenbank ausgegebenen Ergebnisse nun direkt in ein Pandas Data Frame hineingeladen und verwendet/ausgewertet/analysiert werden.

Im Grunde wird hierfür “normales SQL” verwendet, wie in anderen Datenbanken auch. Der folgende Beispiel gibt einfach die fünf ersten von der Datenbank gefundenen Adressen aus der Tabelle pt_addresses aus:

Link zur Ausgabe

Es wird dem Leser sicherlich aufgefallen sein, dass die Spalte “Geometry” (zumindest für das menschliche Auge) nicht besonders ansprechend sowie auch nicht informativ aussieht: Der Grund hierfür ist, dass diese Spalte die entsprechende Position im geographischen Koordinatensystem aus Gründen wie dem deutlich kleineren Speicherplatzbedarf sowie der damit einhergehenden Optimierung der Geschwindigkeit der Datenbank selber, in binärer Form gespeichert und ohne weitere Verarbeitung auch als solche ausgegeben wird.

Glücklicherweise stellt spatialite eine ganze Reihe von Funktionen zur Verarbeitung dieser geographischen Informationen bereit, von denen im folgenden einige beispielsweise vorgestellt werden:

Für einzelne Punkte im Koordinatensystem gibt es beispielsweise die Funktionen X(geometry) und Y(geometry), welche aus diesem “binären Wirrwarr” den Längen- bzw. Breitengrad des jeweiligen Punktes als lesbare Zahlen ausgibt.

Ändert man also das obige Query nun entsprechend ab, erhält man als Ausgabe folgendes Ergebnis in welchem die Geometry-Spalte der ausgegebenen Adressen in den zwei neuen Spalten Longitude und Latitude in lesbarer Form zu finden ist:

Link zur Tabelle

Eine weitere häufig verwendete Funktion von Spatialite ist die Distance-Funktion, welche die Distanz zwischen zwei Orten berechnet.

Das folgende Beispiel sucht in der Datenbank die 10 nächstgelegenen Bäckereien zu einer frei wählbaren Position aus der Datenbank und listet diese nach zunehmender Entfernung auf (Achtung – die frei wählbare Position im Beispiel liegt in München, wer die selbe Position z. B. mit dem Bremen-Datensatz verwendet, wird vermutlich etwas weiter laufen müssen…):

Link zur Ausgabe

Ein Anwendungsfall für eine solche Liste können zum Beispiel Programme/Apps wie maps.me oder Google-Maps sein, in denen User nach Bäckereien, Geldautomaten, Supermärkten oder Apotheken “in der Nähe” suchen können sollen.

Diese Liste enthält nun alle Informationen die grundsätzlich gebraucht werden, ist soweit auch informativ und wird in den meißten Fällen der Datenauswertung auch genau so gebraucht, jedoch ist diese für das Auge nicht besonders ansprechend.

Viel besser wäre es doch, die gefundenen Positionen auf einer interaktiven Karte einzuzeichnen:

Was kann man sonst interessantes mit der erstellten Datenbank und etwas Python machen? Wer in Deutschland ein wenig herumgekommen ist, dem ist eventuell aufgefallen, dass sich die Endungen von Ortsnamen stark unterscheiden: Um München gibt es Stadteile und Dörfer namens Garching, Freising, Aubing, ect., rund um Stuttgart enden alle möglichen Namen auf “ingen” (Plieningen, Vaihningen, Echterdingen …) und in Berlin gibt es Orte wie Pankow, Virchow sowie eine bunte Auswahl weiterer *ow’s.

Das folgende Query spuckt gibt alle “village’s”, “town’s” und “city’s” aus der Tabelle pt_place, also Dörfer und Städte, aus:

Link zur Ausgabe

Graphisch mit matplotlib und cartopy in ein Koordinatensystem eingetragen sieht diese Verteilung folgendermassen aus:

Die Grafik zeigt, dass stark unterschiedliche Vorkommen der verschiedenen Ortsendungen in Deutschland (Clustering). Über das genaue Zustandekommen dieser Verteilung kann ich hier nur spekulieren, jedoch wird diese vermutlich ähnlichen Prozessen unterliegen wie beispielsweise die Entwicklung von Dialekten.

Wer sich die Karte etwas genauer anschaut wird merken, dass die eingezeichneten Landesgrenzen und Küstenlinien nicht besonders genau sind. Hieran wird ein interessanter Effekt von häufig verwendeten geographischen Entitäten, nämlich Linien und Polygonen deutlich. Im Beispiel werden durch die beiden Zeilen

die bereits im Modul cartopy hinterlegten Daten verwendet. Genaue Verläufe von Küstenlinien und Landesgrenzen benötigen mit wachsender Genauigkeit hingegen sehr viel Speicherplatz, da mehr und mehr zu speichernde Punkte benötigt werden (genaueres siehe hier).

Schlussfolgerung

Man kann also bereits mit einigen Grundmodulen und öffentlich verfügbaren Datensätzen eine ganze Menge im Bereich der Geodaten erkunden und entdecken. Gleichzeitig steht, insbesondere für spezielle Probleme, eine große Bandbreite weiterer Software zur Verfügung, für welche dieser Artikel zwar einen Grundsätzlichen Einstieg geben kann, die jedoch den Rahmen dieses Artikels sprengen würden.

Interview: Does Business Intelligence benefit from Cloud Data Warehousing?

Interview with Ross Perez, Senior Director, Marketing EMEA at Snowflake

Read this article in German:
“Profitiert Business Intelligence vom Data Warehouse in der Cloud?”

Does Business Intelligence benefit from Cloud Data Warehousing?

Ross Perez is the Senior Director, Marketing EMEA at Snowflake. He leads the Snowflake marketing team in EMEA and is charged with starting the discussion about analytics, data, and cloud data warehousing across EMEA. Before Snowflake, Ross was a product marketer at Tableau Software where he founded the Iron Viz Championship, the world’s largest and longest running data visualization competition.

Data Science Blog: Ross, Business Intelligence (BI) is not really a new trend. In 2019/2020, making data available for the whole company should not be a big thing anymore. Would you agree?

BI is definitely an old trend, reporting has been around for 50 years. People are accustomed to seeing statistics and data for the company at large, and even their business units. However, using BI to deliver analytics to everyone in the organization and encouraging them to make decisions based on data for their specific area is relatively new. In a lot of the companies Snowflake works with, there is a huge new group of people who have recently received access to self-service BI and visualization tools like Tableau, Looker and Sigma, and they are just starting to find answers to their questions.

Data Science Blog: Up until today, BI was just about delivering dashboards for reporting to the business. The data warehouse (DWH) was something like the backend. Today we have increased demand for data transparency. How should companies deal with this demand?

Because more people in more departments are wanting access to data more frequently, the demand on backend systems like the data warehouse is skyrocketing. In many cases, companies have data warehouses that weren’t built to cope with this concurrent demand and that means that the experience is slow. End users have to wait a long time for their reports. That is where Snowflake comes in: since we can use the power of the cloud to spin up resources on demand, we can serve any number of concurrent users. Snowflake can also house unlimited amounts of data, of both structured and semi-structured formats.

Data Science Blog: Would you say the DWH is the key driver for becoming a data-driven organization? What else should be considered here?

Absolutely. Without having all of your data in a single, highly elastic, and flexible data warehouse, it can be a huge challenge to actually deliver insight to people in the organization.

Data Science Blog: So much for the theory, now let’s talk about specific use cases. In general, it matters a lot whether you are storing and analyzing e.g. financial data or machine data. What do we have to consider for both purposes?

Financial data and machine data do look very different, and often come in different formats. For instance, financial data is often in a standard relational format. Data like this needs to be able to be easily queried with standard SQL, something that many Hadoop and noSQL tools were unable to provide. Luckily, Snowflake is an ansi-standard SQL data warehouse so it can be used with this type of data quite seamlessly.

On the other hand, machine data is often semi-structured or even completely unstructured. This type of data is becoming significantly more common with the rise of IoT, but traditional data warehouses were very bad at dealing with it since they were optimized for relational data. Semi-structured data like JSON, Avro, XML, Orc and Parquet can be loaded into Snowflake for analysis quite seamlessly in its native format. This is important, because you don’t want to have to flatten the data to get any use from it.

Both types of data are important, and Snowflake is really the first data warehouse that can work with them both seamlessly.

Data Science Blog: Back to the common business use case: Creating sales or purchase reports for the business managers, based on data from ERP-systems such as Microsoft or SAP. Which architecture for the DWH could be the right one? How many and which database layers do you see as necessary?

The type of report largely does not matter, because in all cases you want a data warehouse that can support all of your data and serve all of your users. Ideally, you also want to be able to turn it off and on depending on demand. That means that you need a cloud-based architecture… and specifically Snowflake’s innovative architecture that separates storage and compute, making it possible to pay for exactly what you use.

Data Science Blog: Where would you implement the main part of the business logic for the report? In the DWH or in the reporting tool? Does it matter which reporting tool we choose?

The great thing is that you can choose either. Snowflake, as an ansi-Standard SQL data warehouse, can support a high degree of data modeling and business logic. But you can also utilize partners like Looker and Sigma who specialize in data modeling for BI. We think it’s best that the customer chooses what is right for them.

Data Science Blog: Snowflake enables organizations to store and manage their data in the cloud. Does it mean companies lose control over their storage and data management?

Customers have complete control over their data, and in fact Snowflake cannot see, alter or change any aspect of their data. The benefit of a cloud solution is that customers don’t have to manage the infrastructure or the tuning – they decide how they want to store and analyze their data and Snowflake takes care of the rest.

Data Science Blog: How big is the effort for smaller and medium sized companies to set up a DWH in the cloud? Does this have to be an expensive long-term project in every case?

The nice thing about Snowflake is that you can get started with a free trial in a few minutes. Now, moving from a traditional data warehouse to Snowflake can take some time, depending on the legacy technology that you are using. But Snowflake itself is quite easy to set up and very much compatible with historical tools making it relatively easy to move over.

OLAP-Würfel

Der OLAP-Würfel

Alles ist relativ! So auch die Anforderungen an Datenbanksysteme. Je nachdem welche Arbeitskollegen/innen dazu gefragt werden, können unterschiedliche Wünschen und Anforderungen an Datenbanksysteme dabei zu Tage kommen.

Die optimale Ausrichtung des Datenbanksystems auf seine spezielle Anwendung hin, setzt den Grundstein für eine performante und effizientes Informationssystem und sollte daher wohl überlegt sein. Eine klassische Unterscheidung für die Anwendung von Datenbanksystemen lässt sich hierbei zwischen OLTP (Online Transaction Processing) und OLAP (Online Analytical Processing) machen.

OLTP-Datenbanksysteme zeichnen sich insbesondere durch die direkte Verarbeitung bei hohem Durchsatz von Transaktionen, sowie den parallelen Zugriff auf Informationen aus und werden daher vor allem für die Erfassung von operativen Geschäftsfällen eingesetzt. Im Gegensatz zu OLTP-Systemen steht bei OLAP-Systemen die analytische Verarbeitung von großen Datenbeständen im Vordergrund. Die folgende Grafik veranschaulicht das Zusammenwirken von OLTP und OLAP.

Da OLAP-Systeme eine mehrdimensionale und subjektbezogen Datenstruktur aufweisen, können statistisch-analytische Verarbeitungen auf diese Datenmengen effizient angewandt werden. Basierend auf dem Sternen-Schema, werden in diesem Zusammenhang häufig sogenannte OLAP-Würfel (engl. „Cube“) verwendet, welcher die Grundlage für multidimensionale Analysen bildet. Im Folgenden werden wir den OLAP-Würfel etwas näher beleuchten.

Aufbau des OLAP-Würfels

Der OLAP-Würfel ist eine Zusammensetzung aus multidimensionale Datenarrays. Die logische Anordnung der Daten über mehrere Dimensionen erlaubt dem Benutzer verschiedene Ansichten auf die Daten in gleicher Weise zu erlangen. Der Begriff „Würfel“ („Cube“) referenziert hierbei auf die Darstellung eines OLAP-Würfels mit drei Dimensionen. OLAP-Würfel mit mehr als drei Dimensionen werden daher auch „Hypercubes“ genannt.

Die Achsen des Würfels entsprechen den Dimensionen, also den Attributen/ Eigenschaften des Würfels, welche den Würfel aufspannen. Typische Dimensionen sind: Produkt, Ort und Zeit.

Die Zellen im Schnittpunkt der Koordinaten entsprechen den Kennzahlen auch Maßzahlen (engl. „measures“) genannt. Die Kennzahlen stehen im Mittelpunkt der Datenanalyse und können sowohl Basisgrößen (atomare Werte) als auch abgeleitete Zahlen (berechnete Werte) sein. Oftmals handelt es sich bei den Kennzahlen um numerische Werte wie z.B.: Umsatz, Kosten und Gewinn.

Hierarchien beschreiben eine logische Struktur einzelner Elemente in den Dimensionen und nehmen dabei meist ein hierarchisches Schema an z.B.:  Tag -> Monat -> Jahr ->TOP. Die Werte der jeweils übergeordneten Elemente ergeben sich meistens aus einer Konsolidierung aller untergeordneten Elemente. Das größte Element „TOP“ steht dabei für „alles“ und fasst somit die gesamten Elemente der Dimension zusammen.

Je nachdem in welcher Detailstufe, auch Granularität genannt, die Kennzahlen der einzelnen Dimensionen vorliegen, können verschiedene Würfel-Operationen für Daten bis auf der kleinsten Ebenen ausgeführt werden wie z.B.: einzelne Transaktionen in einer Geschäftsstellen für einen bestimmten Tag betrachten. Bei der Wahl der Granularität ist jedoch unbedingt der Zweck sowie die Leistungsfähigkeit der Datenbank mit zu Berücksichtigen.

 

 

 

 

 

Operationen des OLAP-Würfels

Für die Auswertung von OLAP-Würfeln haben sich spezielle Operationsbezeichnungen durchgesetzt, welche im Folgenden mit grafischen Beispielen vorgestellt werden.

Die Slice Operation wird durch die Selektion bzw. Einschränkung einer Dimension auf ein Dimensionselement erwirkt. In dem hier aufgezeigten Beispiel wird durch das Selektieren auf die Produktsparte „Anzüge“,die entsprechende Scheibe aus dem Würfel „herausgeschnitten“.

 

 

 

 

 

 

 


Bei der Dice-Operation wird der Würfel auf mehreren Dimensionen, durch eine Menge von Dimensionselementen eingeschränkt. Als Resultat ergibt sich ein neuer verkleinerter, mehrdimensionaler Datenraum. Das Beispiel zeigt, wie der Würfel auf die Zeit-Dimensionselemente: „Q1 „und „Q2“ sowie die Produkt- Dimensionselemente: „Anzüge“ und „Hosen“ beschränkt wird.

 

 

 

 

 


Mit der Pivotiting/Rotation-Operation wird der Würfel um die eigene Achse rotiert. Diese Operation ermöglicht dem Benutzer unterschiedliche Sichten auf die Daten zu erhalten, da neue Kombinationen von Dimensionen sichtbar werden.

Im abgebildeten Beispiel wird der Datenwürfel nach rechts und um die Zeitachse gedreht. Die dadurch sichtbar gewordene Kombination von Ländern und Zeit ermöglicht dem Benutzer eine neue Sicht auf den Datenwürfel.


Die Operationen: Drill-down oder Drill-up werden benutzt, um durch die Hierarchien der Dimensionen zu navigieren. Je nach Anwendung verdichten sich die Daten bei der Drill-up Operation, während die Drill-down Operation einen höheren Detailgrad ermöglicht.

Beispiel werden die Dimensionen auf die jeweils höchste Klassifikationsstufe verdichtet. Das Ergebnis zeigt das TOP-Element der aggregierten Daten, mit einem Wert von 9267 €.


Technische Umsetzung

In den meisten Fällen werden OLAP-Systeme oberhalb des Data Warehouses platziert und nutzen dieses als Datenquelle.  Für die Datenspeicherung wird vor allem zwischen den klassischen Konzepten „MOLAP“ und „ROLAP“ unterschieden. Die folgende Gegenüberstellung, zeigt die wesentlichen Unterschiede der beiden Konzepte auf.

ROLAP

MOLAP

Bedeutung
Relationales-OLAP Multidimensionales-OLAP
Datenspeicherung
Daten liegen in relationalen Datenbanken vor. Daten werden in multidimensionalen Datenbanken als Datenwürfel gespeichert
Daten Form
Relationale Tabellen Multidimensionale Arrays
Datenvolumen
Hohes Datenvolumen und hohe Nutzerzahl Mittleres Datenvolum, da Detaildaten in komprimiertem Format vorliegen
Technologie
Benötigt Komplexe SQL Abfragen, um Daten zu beziehen Vorberechneter Datenwürfel hält Aggregationen vor
Skalierbarkeit
Beliebig Eingeschränkt
Antwortgeschwindigkeit
Langsam Schnell

Fazit

OLAP Würfel können effizient dafür genutzt werden, Informationen in logische Strukturen zu speichern. Die Dimensionierung sowie der Aufbau von logischen Hierarchien, erlauben dem Benutzer ein intuitives Navigieren und Betrachten des Datenbestandes. Durch die Vorberechnung der Aggregationen bei MOLAP-Systemen, können sehr komplexe Analyseabfragen mit hoher Geschwindigkeit und unabhängig von der Datenquelle durchgeführt werden. Für die betriebliche Datenanalyse ist die Nutzung des Datenwürfels insbesondere für fortgeschrittene Datenanalyse, daher eine enorme Bereicherung.

How To Remotely Send R and Python Execution to SQL Server from Jupyter Notebooks

Introduction

Did you know that you can execute R and Python code remotely in SQL Server from Jupyter Notebooks or any IDE? Machine Learning Services in SQL Server eliminates the need to move data around. Instead of transferring large and sensitive data over the network or losing accuracy on ML training with sample csv files, you can have your R/Python code execute within your database. You can work in Jupyter Notebooks, RStudio, PyCharm, VSCode, Visual Studio, wherever you want, and then send function execution to SQL Server bringing intelligence to where your data lives.

This tutorial will show you an example of how you can send your python code from Juptyter notebooks to execute within SQL Server. The same principles apply to R and any other IDE as well. If you prefer to learn through videos, this tutorial is also published on YouTube here:


 

Environment Setup Prerequisites

  1. Install ML Services on SQL Server

In order for R or Python to execute within SQL, you first need the Machine Learning Services feature installed and configured. See this how-to guide.

  1. Install RevoscalePy via Microsoft’s Python Client

In order to send Python execution to SQL from Jupyter Notebooks, you need to use Microsoft’s RevoscalePy package. To get RevoscalePy, download and install Microsoft’s ML Services Python Client. Documentation Page or Direct Download Link (for Windows).

After downloading, open powershell as an administrator and navigate to the download folder. Start the installation with this command (feel free to customize the install folder): .\Install-PyForMLS.ps1 -InstallFolder “C:\Program Files\MicrosoftPythonClient”

Be patient while the installation can take a little while. Once installed navigate to the new path you installed in. Let’s make an empty folder and open Jupyter Notebooks: mkdir JupyterNotebooks; cd JupyterNotebooks; ..\Scripts\jupyter-notebook

Create a new notebook with the Python 3 interpreter:

 

To test if everything is setup, import revoscalepy in the first cell and execute. If there are no error messages you are ready to move forward.

Database Setup (Required for this tutorial only)

For the rest of the tutorial you can clone this Jupyter Notebook from Github if you don’t want to copy paste all of the code. This database setup is a one time step to ensure you have the same data as this tutorial. You don’t need to perform any of these setup steps to use your own data.

  1. Create a database

Modify the connection string for your server and use pyodbc to create a new database.

  1. Import Iris sample from SkLearn

Iris is a popular dataset for beginner data science tutorials. It is included by default in sklearn package.

  1. Use RecoscalePy APIs to create a table and load the Iris data

(You can also do this with pyodbc, sqlalchemy or other packages)

Define a Function to Send to SQL Server

Write any python code you want to execute in SQL. In this example we are creating a scatter matrix on the iris dataset and only returning the bytestream of the .png back to Jupyter Notebooks to render on our client.

Send execution to SQL

Now that we are finally set up, check out how easy sending remote execution really is! First, import revoscalepy. Create a sql_compute_context, and then send the execution of any function seamlessly to SQL Server with RxExec. No raw data had to be transferred from SQL to the Jupyter Notebook. All computation happened within the database and only the image file was returned to be displayed.

While this example is trivial with the Iris dataset, imagine the additional scale, performance, and security capabilities that you now unlocked. You can use any of the latest open source R/Python packages to build Deep Learning and AI applications on large amounts of data in SQL Server. We also offer leading edge, high-performance algorithms in Microsoft’s RevoScaleR and RevoScalePy APIs. Using these with the latest innovations in the open source world allows you to bring unparalleled selection, performance, and scale to your applications.

Learn More

Check out SQL Machine Learning Services Documentation to learn how you can easily deploy your R/Python code with SQL stored procedures making them accessible in your ETL processes or to any application. Train and store machine learning models in your database bringing intelligence to where your data lives.

Other YouTube Tutorials:

DS-GVO: Wie das moderne Data-Warehouse Unternehmen entlastet

Artikel des Blog-Sponsors: Snowflake

Viele Aktivitäten, die zur Einhaltung der DS-GVO-Anforderungen beitragen, liegen in den Händen der Unternehmen selbst. Deren IT-Anbieter sollten dazu beitragen, die Compliance-Anforderungen dieser Unternehmen zu erfüllen. Die SaaS-Anbieter eines Unternehmens sollten zumindest die IT-Sicherheitsanforderungen erfüllen, die sich vollständig in ihrem Bereich befinden und sich auf die Geschäfts- und Datensicherheit ihrer Kunden auswirken.

Snowflake wurde von Grund auf so gestaltet, dass die Einhaltung der DS-GVO erleichtert wird – und von Beginn darauf ausgelegt, enorme Mengen strukturierter und semistrukturierter Daten mit der Leichtigkeit von Standard-SQL zu verarbeiten. Die Zugänglichkeit und Einfachheit von SQL gibt Organisationen die Flexibilität, alle unter der DS-GVO erforderlichen Aktualisierungen, Änderungen oder Löschungen nahtlos vorzunehmen. Snowflakes Unterstützung für semistrukturierte Daten kann die Anpassung an neue Felder und andere Änderungen der Datensätze erleichtern. Darüber hinaus war die Sicherheit von Anfang an von grundlegender Bedeutung für Architektur, Implementierung und Betrieb von Snowflakes Data-Warehouse-as-a-Service.

Ein Grundprinzip der DS-GVO

Ein wichtiger Faktor für die Einhaltung der DS-GVO ist, zu verstehen, welche Daten eine Organisation besitzt und auf wen sie sich beziehen. Diese Anforderung macht es nötig, dass Daten strukturiert, organisiert und einfach zu suchen sind.

Die relationale SQL-Datenbankarchitektur von Snowflake bietet eine erheblich vereinfachte Struktur und Organisation, was sicherstellt, dass jeder Datensatz einen eindeutigen und leicht identifizierbaren Speicherort innerhalb der Datenbank besitzt. Snowflake-Kunden können auch relationalen Speicher mit dem Variant-Spaltentyp von Snowflake für semistrukturierte Daten kombinieren. Dieser Ansatz erweitert die Einfachheit des relationalen Formats auf die Schema-Flexibilität semistrukturierter Daten.

Snowflake ist noch leistungsfähiger durch seine Fähigkeit, massive Nebenläufigkeit zu unterstützen. Bei größeren Organisationen können Dutzende oder sogar Hunderte nebenläufiger Datenänderungen, -abfragen und -suchvorgänge zu einem bestimmten Zeitpunkt auftreten. Herkömmliche Data-Warehouses können nicht zu einem bestimmten Zeitpunkt über einen einzelnen Rechen-Cluster hinaus skaliert werden, was zu langen Warteschlangen und verzögerter Compliance führt. Snowflakes Multi-Cluster-Architektur für gemeinsam genutzte Daten löst dieses Problem, indem sie so viele einzigartige Rechen-Cluster bereitstellen kann, wie für einen beliebigen Zweck nötig sind, was zu einer effizienteren Workload-Isolierung und höherem Abfragedurchsatz führt. Jeder Mitarbeiter kann sehr große Datenmengen mit so vielen nebenläufigen Benutzern oder Operationen wie nötig speichern, organisieren, ändern, suchen und abfragen.

Rechte von Personen, deren Daten verarbeitet werden („Datensubjekte“)

Organisationen, die von der DS-GVO betroffen sind, müssen sicherstellen, dass sie Anfragen betroffener Personen nachkommen können. Einzelpersonen haben jetzt erheblich erweiterte Rechte, um zu erfahren, welche Art von Daten eine Organisation über sie besitzt, und das Recht, den Zugriff und/oder die Korrektur ihrer Daten anzufordern, die Daten zu löschen und/oder die Daten an einen neuen Provider zu übertragen. Bei der Bereitstellung dieser Dienste müssen Organisationen ziemlich schnell reagieren, in der Regel innerhalb von 30 Tagen. Daher müssen sie ihre Geschäftssysteme und ihr Data-Warehouse schnell durchsuchen können, um alle personenbezogenen Daten zu finden, die mit einer Person in Verbindung stehen, und entsprechende Maßnahmen ergreifen.

Organisationen können in großem Umfang von der Speicherung aller Daten in einem Data-Warehouse-as-a-Service mit vollen DML- und SQL-Fähigkeiten profitieren. Dies erleichtert das (mühevolle) Durchsuchen getrennter Geschäftssysteme und Datenspeicher, um die relevanten Daten zu finden. Und das wiederum hilft sicherzustellen, dass einzelne Datensätze durchsucht, gelöscht, eingeschränkt, aktualisiert, aufgeteilt und auf andere Weise manipuliert werden können, um sie an entsprechende Anfragen betroffener Personen anzupassen. Außerdem können Daten so verschoben werden, dass sie der Anforderung einer Anfrage zum „Recht auf Datenübertragbarkeit“ entsprechen. Von Anfang an wurde Snowflake mit ANSI-Standard-SQL und vollständiger DML-Unterstützung entwickelt, um sicherzustellen, dass diese Arten von Operationen möglich sind.

Sicherheit

Leider erfordern es viele herkömmliche Data-Warehouses, dass sich Unternehmen selbst um die IT-Sicherheit kümmern und diese mit anderen Services außerhalb des Kernangebots kombiniert wird. Außerdem bieten sie manchmal noch nicht einmal standardmäßige Verschlüsselung.

Als Data-Warehouse, das speziell für die Cloud entwickelt wurde und das Sicherheit als zentrales Element bietet, umfasst Snowflake unter anderem folgende integrierte Schutzfunktionen:

  • Minimaler Betriebsaufwand: Weniger Komplexität durch automatische Performance, Sicherheit und Hochverfügbarkeit, sodass die Infrastruktur nicht optimiert werden muss und kein Tuning nötig ist.
  • Durchgängige Verschlüsselung: Automatische Verschlüsselung aller Daten jederzeit (in ruhendem und bewegtem Zustand).
  • Umfassender Schutz: Zu den Sicherheitsfunktionen zählen Multi-Faktor-Authentifizierung, rollenbasierte Zugriffskontrolle, IP-Adressen-Whitelisting, zentralisierte Authentifizierung und jährliche Neuverschlüsselung verschlüsselter Daten.
  • Tri-Secret Secure: Kundenkontrolle und Datenschutz durch die Kombination aus einem vom Kunden, einem von Snowflake bereitgestellten Verschlüsselungsschlüssel und Benutzerzugangsdaten.
  • Unterstützung für AWS Private Link: Kunden können Daten zwischen ihrem virtuellen privaten Netzwerk und Snowflake übertragen, ohne über das Internet gehen zu müssen. Dadurch ist die Konnektivität zwischen den Netzwerken sicher und einfacher zu verwalten.
  • Stärkere unternehmensinterne Datenabgrenzung dank Snowflake Data Sharing: Organisationen können die Datenfreigabefunktionen von Snowflake nutzen, um nicht personenbezogene Daten mit anderen Abteilungen zu teilen, die keinen Zugriff benötigen – indem sie strengere Sicherheits- und DS-GVO-Kontrollen durchsetzen.
  • Private Umgebung: Unternehmen können eine dedizierte, verwaltete Snowflake- Instanz in einer separaten AWS Virtual Private Cloud (VPC) abrufen.

Rechenschaftspflicht

Was die Komplexität weiter erhöht: Organisationen müssen auch sicherstellen, dass sie und die Organisationen und Tools, mit denen sie arbeiten, Compliance nachweisen können. Snowflake prüft und verfeinert seine IT-Sicherheitspraxis regelmäßig mit peniblen Penetrationstests. Snowflakes Data-Warehouse-as-a-Service ist zertifiziert nach SOC 2 Type II, ist PCI-DSS-konform und unterstützt HIPAA-Compliance. Um Anfragen von Personen, deren Daten verarbeitet werden („Datensubjekte“), zu entsprechen, können Kunden genutzte Daten überprüfen.

Zusätzlich zu diesen Standardfunktionen und -validierungen schützt Snowflake seine Kunden auch durch den Datenschutznachtrag („Data Protection Addendum“), der genau auf die Anforderungen der DS-GVO abgestimmt ist. Snowflake hält sich außerdem an penibel vertraglich festgelegte Sicherheitsverpflichtungen („contractual security commitments“), um effizientere Transaktionen und eine vereinfachte Sorgfaltspflicht zu ermöglichen.

Fazit

Im Rahmen der Europäischen Datenschutz-Grundverordnung müssen Unternehmen technische Maßnahmen ergreifen, mit deren Hilfe sie den Anforderungen ihrer Kunden in Bezug auf Datenschutz und Schutz der Privatsphäre gerecht werden können. Snowflake bietet hier nicht nur den Vorteil, alle wichtigen Kundendaten an einem einzigen Ort zu speichern, sondern ermöglicht auch das schnelle Auffinden und Abrufen dieser Daten, sodass Unternehmen im Bedarfsfall schnell aktiv werden können.

Big Data Essentials – Intro

1. Big Data Definition

Data umfasst Nummern, Text, Bilder, Audio, Video und jede Art von Informationen die in Ihrem Computer gespeichert werden können. Big Data umfasst Datenmengen, die eine oder mehrere der folgenden Eigenschaften aufweisen: Hohes Volumen (High Volume), hohe Vielfalt (High Variety) und / oder eine notwendige hohe Geschwindigkeit (High Velocity) zur Auswertung. Diese drei Eigenschaften werden oft auch als die 3V’s von Big Data bezeichnet.

1.1. Volumen: Menge der erzeugten Daten

Volumen bezieht sich auf die Menge der generierten Daten. Traditionelle Datenanalysemodelle erfordern typischerweise Server mit großen Speicherkapazitäten, bei massiver Rechenleistung sind diese Modelle nicht gut skalierbar. Um die Rechenleistung zu erhöhen, müssen Sie weiter investieren, möglicherweise auch in teurere proprietäre Hardware. Die NASA ist eines von vielen Unternehmen, die enorme Mengen an Daten sammeln. Ende 2014 sammelte die NASA alle paar Sekunden etwa 1,73 GB an Daten. Und auch dieser Betrag der Datenansammlung steigt an, so dass die Datenerfassung entsprechend exponentiell mitwachsen muss. Es resultieren sehr hohe Datenvolumen und es kann schwierig sein, diese zu speichern.

1.2. Vielfalt: Unterschiedliche Arten von Daten

Das  traditionelle  Datenmodell (ERM)  erfordert  die  Entwicklung  eines  Schemas,  das  die  Daten in ein Korsett zwingt. Um das Schema zu erstellen, muss man das Format der Daten kennen, die gesammelt werden. Daten  können  wie  XML-Dateien  strukturiert  sein,  halb  strukturiert  wie  E-Mails oder unstrukturiert wie Videodateien.

Wikipedia – als Beispiel – enthält mehr als nur Textdaten, es enthält Hyperlinks, Bilder, Sound-Dateien und viele andere Datentypen mit mehreren verschiedenen Arten von Daten. Insbesondere unstrukturierte   Daten haben   eine   große   Vielfalt.  Es   kann   sehr   schwierig   sein, diese Vielfalt in einem Datenmodell zu beschreiben.

1.3. Geschwindigkeit: Geschwindigkeit, mit der Daten genutzt werden

Traditionelle Datenanalysemodelle wurden für die Stapelverarbeitung (batch processing) entwickelt. Sie sammeln die gesamte Datenmenge und verarbeiten sie, um sie in die Datenbank zu speichern. Erst mit einer Echtzeitanalyse der Daten kann schnell auf Informationen reagiert werden. Beispielsweise können Netzwerksensoren, die mit dem Internet der Dinge (IoT) verbunden sind, tausende von Datenpunkten pro Sekunde erzeugen. Im Gegensatz zu Wikipedia, deren Daten später verarbeitet werden können, müssen Daten von Smartphones und anderen Netzwerkteilnehmern mit entsprechender Sensorik in  Echtzeit  verarbeitet  werden.

2. Geschichte von Big Data

2.1. Google Solution

  • Google File System speichert die Daten, Bigtable organisiert die Daten und MapReduce verarbeitet es.
  • Diese Komponenten arbeiten zusammen auf einer Sammlung von Computern, die als Cluster bezeichnet werden.
  • Jeder einzelne Computer in einem Cluster wird als Knoten bezeichnet.

2.2 Google File System

Das Google File System (GFS) teilt Daten in Stücke ‚Chunks’ auf. Diese ‚Chunks’ werden verteilt und auf verschiedene Knoten in einem Cluster nachgebildet. Der Vorteil ist nicht nur die mögliche parallele Verarbeitung bei der späteren Analysen, sondern auch die Datensicherheit. Denn die Verteilung und die Nachbildung schützen vor Datenverlust.

2.3. Bigtable

Bigtable ist ein Datenbanksystem, das GFS zum Speichern und Abrufen von Daten verwendet. Trotz seines Namens ist Bigtable nicht nur eine sehr große Tabelle. Bigtable ordnet die Datenspeicher mit einem Zeilenschlüssel, einem Spaltenschlüssel und einem Zeitstempel zu. Auf diese Weise können dieselben Informationen über einen längeren Zeitraum hinweg erfasst werden, ohne dass bereits vorhandene Einträge überschrieben werden. Die Zeilen sind dann in den Untertabellen partitioniert, die über einem Cluster verteilt sind. Bigtable wurde entwickelt, um riesige Datenmengen zu bewältigen, mit der Möglichkeit, neue Einträge zum Cluster hinzuzufügen, ohne dass eine der vorhandenen Dateien neu konfiguriert werden muss.

2.4. MapReduce

Als dritter Teil des Puzzles wurde ein Parallelverarbeitungsparadigma namens MapReduce genutzt, um die bei GFS gespeicherten Daten zu verarbeiten. Der Name MapReduce wird aus den Namen von zwei Schritten im Prozess übernommen. Obwohl der Mapreduce-Prozess durch Apache Hadoop berühmt geworden ist, ist das kaum eine neue Idee. In der Tat können viele gängige Aufgaben wie Sortieren und Falten von Wäsche als Beispiele für den MapReduce- Prozess betrachtet werden.

Quadratische Funktion:

  • wendet die gleiche Logik auf jeden Wert an, jeweils einen Wert
  • gibt das Ergebnis für jeden Wert aus
    (map square'(1 2 3 4)) = (1 4 9 16)

Additionsfunktion

  • wendet die gleiche Logik auf alle Werte an, die zusammen genommen werden.
    (reduce + ‘(1 4 9 16)) = 30

Die Namen Map und Reduce können bei der Programmierung mindestens bis in die 70er-Jahre zurückverfolgt werden. In diesem Beispiel sieht man, wie die Liste das MapReduce-Modell verwendet. Zuerst benutzt man Map der Quadratfunktion auf einer Eingangsliste für die Quadratfunktion, da sie abgebildet ist, alle angelegten Eingaben und erzeugt eine einzige Ausgabe pro Eingabe, in diesem Fall (1, 4, 9 und 16). Additionsfunktion reduziert die Liste und erzeugt eine einzelne Ausgabe von 30, der die Summe aller Eingänge ist.

Google nutzte die Leistung von MapReduce, um einen Suchmaschinen-Markt zu dominieren. Das Paradigma kam in der 19. Websearch-Engine zum Einsatz und etablierte sich innerhalb weniger Jahre und ist bis heute noch relevant. Google verwendete MapReduce auf verschiedene Weise, um die Websuche zu verbessern. Es wurde verwendet, um den Seiteninhalt zu indexieren und ein Ranking über die Relevant einer Webseite zu berechnen.

Dieses  Beispiel  zeigt  uns  den MapReduce-Algorithmus, mit dem Google Wordcount auf Webseiten ausführte. Die Map-Methode verwendet als Eingabe einen Schlüssel (key) und einen Wert, wobei der Schlüssel den Namen des Dokuments darstellt  und  der  Wert  der  Kontext  dieses Dokuments ist. Die Map-Methode durchläuft jedes Wort im Dokument und gibt es als Tuple zurück, die aus dem Wort und dem Zähler 1 besteht.

Die   Reduce-Methode   nimmt   als   Eingabe auch  einen  Schlüssel  und  eine  Liste  von  Werten an, in der der Schlüssel ein Wort darstellt. Die  Liste  von  Werten  ist  die  Liste  von  Zählungen dieses Worts. In diesem Beispiel ist der Wert 1. Die Methode “Reduce” durchläuft alle Zählungen. Wenn die Schleife beendet ist, um die Methode zu reduzieren, wird sie als Tuple zurückgegeben, die aus dem Wort und seiner Gesamtanzahl besteht.

 

Consider Anonymization – Process Mining Rule 3 of 4

This is article no. 3 of the four-part article series Privacy, Security and Ethics in Process Mining.

Read this article in German:
Datenschutz, Sicherheit und Ethik beim Process Mining – Regel 3 von 4

If you have sensitive information in your data set, instead of removing it you can also consider the use of anonymization. When you anonymize a set of values, then the actual values (for example, the employee names “Mary Jones”, “Fred Smith”, etc.) will be replaced by another value (for example, “Resource 1”, “Resource 2”, etc.).

If the same original value appears multiple times in the data set, then it will be replaced with the same replacement value (“Mary Jones” will always be replaced by “Resource 1”). This way, anonymization allows you to obfuscate the original data but it preserves the patterns in the data set for your analysis. For example, you will still be able to analyze the workload distribution across all employees without seeing the actual names.

Some process mining tools (Disco and ProM) include anonymization functionality. This means that you can import your data into the process mining tool and select which data fields should be anonymized. For example, you can choose to anonymize just the Case IDs, the resource name, attribute values, or the timestamps. Then you export the anonymized data set and you can distribute it among your team for further analysis.

Do:

  • Determine which data fields are sensitive and need to be anonymized (see also the list of common process mining attributes and how they are impacted if anonymized).
  • Keep in mind that despite the anonymization certain information may still be identifiable. For example, there may be just one patient having a very rare disease, or the birthday information of your customer combined with their place of birth may narrow down the set of possible people so much that the data is not anonymous anymore.

Don’t:

  • Anonymize the data before you have cleaned your data, because after the anonymization the data cleaning may not be possible anymore. For example, imagine that slightly different customer category names are used in different regions but they actually mean the same. You would like to merge these different names in a data cleaning step. However, after you have anonymized the names as “Category 1”, “Category 2”, etc. the data cleaning cannot be done anymore.
  • Anonymize fields that do not need to be anonymized. While anonymization can help to preserve patterns in your data, you can easily lose relevant information. For example, if you anonymize the Case ID in your incident management process, then you cannot look up the ticket number of the incident in the service desk system anymore. By establishing a collaborative culture around your process mining initiative (see guideline No. 4) and by working in a responsible, goal-oriented way, you can often work openly with the original data that you have within your team.

Responsible Handling of Data – Process Mining Rule 2 of 4

This is article no. 2 of the four-part article series Privacy, Security and Ethics in Process Mining.

Read this article in German:
Datenschutz, Sicherheit und Ethik beim Process Mining – Regel 2 von 4

Like in any other data analysis technique, you must be careful with the data once you have obtained it. In many projects, nobody thinks about the data handling until it is brought up by the security department. Be that person who thinks about the appropriate level of protection and has a clear plan already prior to the collection of the data.

Do:

  • Have external parties sign a Non Disclosure Agreement (NDA) to ensure the confidentiality of the data. This holds, for example, for consultants you have hired to perform the process mining analysis for you, or for researchers who are participating in your project. Contact your legal department for this. They will have standard NDAs that you can use.
  • Make sure that the hard drive of your laptop, external hard drives, and USB sticks that you use to transfer the data and your analysis results are encrypted.

Don’t:

  • Give the data set to your co-workers before you have checked what is actually in the data. For example, it could be that the data set contains more information than you requested, or that it contains sensitive data that you did not think about. For example, the names of doctors and nurses might be mentioned in a free-text medical notes attribute. Make sure you remove or anonymize (see guideline No. 3) all sensitive data before you pass it on.
  • Upload your data to a cloud-based process mining tool without checking that your organization allows you to upload this kind of data. Instead, use a desktop-based process mining tool (like Disco [3] or ProM [4]) to analyze your data locally or get the cloud-based process mining vendor to set-up an on-premise version of their software within your organization. This is also true for cloud-based storage services like Dropbox: Don’t just store data or analysis results in the cloud even if it is convenient.

Privacy, Security and Ethics in Process Mining – Article Series

When I moved to the Netherlands 12 years ago and started grocery shopping at one of the local supermarket chains, Albert Heijn, I initially resisted getting their Bonus card (a loyalty card for discounts), because I did not want the company to track my purchases. I felt that using this information would help them to manipulate me by arranging or advertising products in a way that would make me buy more than I wanted to. It simply felt wrong.

Read this article in German:
Datenschutz, Sicherheit und Ethik beim Process Mining – Artikelserie

The truth is that no data analysis technique is intrinsically good or bad. It is always in the hands of the people using the technology to make it productive and constructive. For example, while supermarkets could use the information tracked through the loyalty cards of their customers to make sure that we have to take the longest route through the store to get our typical items (passing by as many other products as possible), they can also use this information to make the shopping experience more pleasant, and to offer more products that we like.

Most companies have started to use data analysis techniques to analyze their data in one way or the other. These data analyses can bring enormous opportunities for the companies and for their customers, but with the increased use of data science the question of ethics and responsible use also grows more dominant. Initiatives like the Responsible Data Science seminar series [1] take on this topic by raising awareness and encouraging researchers to develop algorithms that have concepts like fairness, accuracy, confidentiality, and transparency built in (see Wil van der Aalst’s presentation on Responsible Data Science at Process Mining Camp 2016).

Process Mining can provide you with amazing insights about your processes, and fuel your improvement initiatives with inspiration and enthusiasm, if you approach it in the right way. But how can you ensure that you use process mining responsibly? What should you pay attention to when you introduce process mining in your own organization?

In this article series, we provide you four guidelines that you can follow to prepare your process mining analysis in a responsible way:

Part 1 of 4: Clarify the Goal of the Analysis

Part 2 of 4: Responsible Handling of Data

Part 3 of 4: Consider Anonymization

Part 4 of 4: Establish a collaborative Culture

Acknowledgements

We would like to thank Frank van Geffen and Léonard Studer, who initiated the first discussions in the workgroup around responsible process mining in 2015. Furthermore, we would like to thank Moe Wynn, Felix Mannhardt and Wil van der Aalst for their feedback on earlier versions of this article.