Sechs Eigenschaften einer modernen Business Intelligence

Völlig unabhängig von der Branche, in der Sie tätig sind, benötigen Sie Informationssysteme, die Ihre geschäftlichen Daten auswerten, um Ihnen Entscheidungsgrundlagen zu liefern. Diese Systeme werden gemeinläufig als sogenannte Business Intelligence (BI) bezeichnet. Tatsächlich leiden die meisten BI-Systeme an Mängeln, die abstellbar sind. Darüber hinaus kann moderne BI Entscheidungen teilweise automatisieren und umfassende Analysen bei hoher Flexibilität in der Nutzung ermöglichen.


english-flagRead this article in English:
“Six properties of modern Business Intelligence”


Lassen Sie uns die sechs Eigenschaften besprechen, die moderne Business Intelligence auszeichnet, die Berücksichtigungen von technischen Kniffen im Detail bedeuten, jedoch immer im Kontext einer großen Vision für die eigene Unternehmen-BI stehen:

1.      Einheitliche Datenbasis von hoher Qualität (Single Source of Truth)

Sicherlich kennt jeder Geschäftsführer die Situation, dass sich seine Manager nicht einig sind, wie viele Kosten und Umsätze tatsächlich im Detail entstehen und wie die Margen pro Kategorie genau aussehen. Und wenn doch, stehen diese Information oft erst Monate zu spät zur Verfügung.

In jedem Unternehmen sind täglich hunderte oder gar tausende Entscheidungen auf operative Ebene zu treffen, die bei guter Informationslage in der Masse sehr viel fundierter getroffen werden können und somit Umsätze steigern und Kosten sparen. Demgegenüber stehen jedoch viele Quellsysteme aus der unternehmensinternen IT-Systemlandschaft sowie weitere externe Datenquellen. Die Informationsbeschaffung und -konsolidierung nimmt oft ganze Mitarbeitergruppen in Anspruch und bietet viel Raum für menschliche Fehler.

Ein System, das zumindest die relevantesten Daten zur Geschäftssteuerung zur richtigen Zeit in guter Qualität in einer Trusted Data Zone als Single Source of Truth (SPOT) zur Verfügung stellt. SPOT ist das Kernstück moderner Business Intelligence.

Darüber hinaus dürfen auch weitere Daten über die BI verfügbar gemacht werden, die z. B. für qualifizierte Analysen und Data Scientists nützlich sein können. Die besonders vertrauenswürdige Zone ist jedoch für alle Entscheider diejenige, über die sich alle Entscheider unternehmensweit synchronisieren können.

2.      Flexible Nutzung durch unterschiedliche Stakeholder

Auch wenn alle Mitarbeiter unternehmensweit auf zentrale, vertrauenswürdige Daten zugreifen können sollen, schließt das bei einer cleveren Architektur nicht aus, dass sowohl jede Abteilung ihre eigenen Sichten auf diese Daten erhält, als auch, dass sogar jeder einzelne, hierfür qualifizierte Mitarbeiter seine eigene Sicht auf Daten erhalten und sich diese sogar selbst erstellen kann.

Viele BI-Systeme scheitern an der unternehmensweiten Akzeptanz, da bestimmte Abteilungen oder fachlich-definierte Mitarbeitergruppen aus der BI weitgehend ausgeschlossen werden.

Moderne BI-Systeme ermöglichen Sichten und die dafür notwendige Datenintegration für alle Stakeholder im Unternehmen, die auf Informationen angewiesen sind und profitieren gleichermaßen von dem SPOT-Ansatz.

3.      Effiziente Möglichkeiten zur Erweiterung (Time to Market)

Bei den Kernbenutzern eines BI-Systems stellt sich die Unzufriedenheit vor allem dann ein, wenn der Ausbau oder auch die teilweise Neugestaltung des Informationssystems einen langen Atem voraussetzt. Historisch gewachsene, falsch ausgelegte und nicht besonders wandlungsfähige BI-Systeme beschäftigen nicht selten eine ganze Mannschaft an IT-Mitarbeitern und Tickets mit Anfragen zu Änderungswünschen.

Gute BI versteht sich als Service für die Stakeholder mit kurzer Time to Market. Die richtige Ausgestaltung, Auswahl von Software und der Implementierung von Datenflüssen/-modellen sorgt für wesentlich kürzere Entwicklungs- und Implementierungszeiten für Verbesserungen und neue Features.

Des Weiteren ist nicht nur die Technik, sondern auch die Wahl der Organisationsform entscheidend, inklusive der Ausgestaltung der Rollen und Verantwortlichkeiten – von der technischen Systemanbindung über die Datenbereitstellung und -aufbereitung bis zur Analyse und dem Support für die Endbenutzer.

4.      Integrierte Fähigkeiten für Data Science und AI

Business Intelligence und Data Science werden oftmals als getrennt voneinander betrachtet und geführt. Zum einen, weil Data Scientists vielfach nur ungern mit – aus ihrer Sicht – langweiligen Datenmodellen und vorbereiteten Daten arbeiten möchten. Und zum anderen, weil die BI in der Regel bereits als traditionelles System im Unternehmen etabliert ist, trotz der vielen Kinderkrankheiten, die BI noch heute hat.

Data Science, häufig auch als Advanced Analytics bezeichnet, befasst sich mit dem tiefen Eintauchen in Daten über explorative Statistik und Methoden des Data Mining (unüberwachtes maschinelles Lernen) sowie mit Predictive Analytics (überwachtes maschinelles Lernen). Deep Learning ist ein Teilbereich des maschinellen Lernens (Machine Learning) und wird ebenfalls für Data Mining oder Predictvie Analytics angewendet. Bei Machine Learning handelt es sich um einen Teilbereich der Artificial Intelligence (AI).

In der Zukunft werden BI und Data Science bzw. AI weiter zusammenwachsen, denn spätestens nach der Inbetriebnahme fließen die Prädiktionsergebnisse und auch deren Modelle wieder in die Business Intelligence zurück. Vermutlich wird sich die BI zur ABI (Artificial Business Intelligence) weiterentwickeln. Jedoch schon heute setzen viele Unternehmen Data Mining und Predictive Analytics im Unternehmen ein und setzen dabei auf einheitliche oder unterschiedliche Plattformen mit oder ohne Integration zur BI.

Moderne BI-Systeme bieten dabei auch Data Scientists eine Plattform, um auf qualitativ hochwertige sowie auf granularere Rohdaten zugreifen zu können.

5.      Ausreichend hohe Performance

Vermutlich werden die meisten Leser dieser sechs Punkte schon einmal Erfahrung mit langsamer BI gemacht haben. So dauert das Laden eines täglich zu nutzenden Reports in vielen klassischen BI-Systemen mehrere Minuten. Wenn sich das Laden eines Dashboards mit einer kleinen Kaffee-Pause kombinieren lässt, mag das hin und wieder für bestimmte Berichte noch hinnehmbar sein. Spätestens jedoch bei der häufigen Nutzung sind lange Ladezeiten und unzuverlässige Reports nicht mehr hinnehmbar.

Ein Grund für mangelhafte Performance ist die Hardware, die sich unter Einsatz von Cloud-Systemen bereits beinahe linear skalierbar an höhere Datenmengen und mehr Analysekomplexität anpassen lässt. Der Einsatz von Cloud ermöglicht auch die modulartige Trennung von Speicher und Rechenleistung von den Daten und Applikationen und ist damit grundsätzlich zu empfehlen, jedoch nicht für alle Unternehmen unbedingt die richtige Wahl und muss zur Unternehmensphilosophie passen.

Tatsächlich ist die Performance nicht nur von der Hardware abhängig, auch die richtige Auswahl an Software und die richtige Wahl der Gestaltung von Datenmodellen und Datenflüssen spielt eine noch viel entscheidender Rolle. Denn während sich Hardware relativ einfach wechseln oder aufrüsten lässt, ist ein Wechsel der Architektur mit sehr viel mehr Aufwand und BI-Kompetenz verbunden. Dabei zwingen unpassende Datenmodelle oder Datenflüsse ganz sicher auch die neueste Hardware in maximaler Konfiguration in die Knie.

6.      Kosteneffizienter Einsatz und Fazit

Professionelle Cloud-Systeme, die für BI-Systeme eingesetzt werden können, bieten Gesamtkostenrechner an, beispielsweise Microsoft Azure, Amazon Web Services und Google Cloud. Mit diesen Rechnern – unter Einweisung eines erfahrenen BI-Experten – können nicht nur Kosten für die Nutzung von Hardware abgeschätzt, sondern auch Ideen zur Kostenoptimierung kalkuliert werden. Dennoch ist die Cloud immer noch nicht für jedes Unternehmen die richtige Lösung und klassische Kalkulationen für On-Premise-Lösungen sind notwendig und zudem besser planbar als Kosten für die Cloud.

Kosteneffizienz lässt sich übrigens auch mit einer guten Auswahl der passenden Software steigern. Denn proprietäre Lösungen sind an unterschiedliche Lizenzmodelle gebunden und können nur über Anwendungsszenarien miteinander verglichen werden. Davon abgesehen gibt es jedoch auch gute Open Source Lösungen, die weitgehend kostenfrei genutzt werden dürfen und für viele Anwendungsfälle ohne Abstriche einsetzbar sind.

Die Total Cost of Ownership (TCO) gehören zum BI-Management mit dazu und sollten stets im Fokus sein. Falsch wäre es jedoch, die Kosten einer BI nur nach der Kosten für Hardware und Software zu bewerten. Ein wesentlicher Teil der Kosteneffizienz ist komplementär mit den Aspekten für die Performance des BI-Systems, denn suboptimale Architekturen arbeiten verschwenderisch und benötigen mehr und teurere Hardware als sauber abgestimmte Architekturen. Die Herstellung der zentralen Datenbereitstellung in adäquater Qualität kann viele unnötige Prozesse der Datenaufbereitung ersparen und viele flexible Analysemöglichkeiten auch redundante Systeme direkt unnötig machen und somit zu Einsparungen führen.

In jedem Fall ist ein BI für Unternehmen mit vielen operativen Prozessen grundsätzlich immer günstiger als kein BI zu haben. Heutzutage könnte für ein Unternehmen nichts teurer sein, als nur nach Bauchgefühl gesteuert zu werden, denn der Markt tut es nicht und bietet sehr viel Transparenz.

Dennoch sind bestehende BI-Architekturen hin und wieder zu hinterfragen. Bei genauerem Hinsehen mit BI-Expertise ist die Kosteneffizienz und Datentransparenz häufig möglich.

Process Mining Tools – Artikelserie

Process Mining ist nicht länger nur ein Buzzword, sondern ein relevanter Teil der Business Intelligence. Process Mining umfasst die Analyse von Prozessen und lässt sich auf alle Branchen und Fachbereiche anwenden, die operative Prozesse haben, die wiederum über operative IT-Systeme erfasst werden. Um die zunehmende Bedeutung dieser Data-Disziplin zu verstehen, reicht ein Blick auf die Entwicklung der weltweiten Datengenerierung an. Waren es 2010 noch 2 Zettabytes (ZB), sind laut Statista für das Jahr 2020 mehr als 50 ZB an Daten zu erwarten. Für 2025 wird gar mit einem Bestand von 175 ZB gerechnet.

Hier wird das Datenvolumen nach Jahren angezeit

Abbildung 1 zeigt die Entwicklung des weltweiten Datenvolumen (Stand 2018). Quelle: https://www.statista.com/statistics/871513/worldwide-data-created/

Warum jetzt eigentlich Process Mining?

Warum aber profitiert insbesondere Process Mining von dieser Entwicklung? Der Grund liegt in der Unordnung dieser Datenmenge. Die Herausforderung der sich viele Unternehmen gegenübersehen, liegt eben genau in der Analyse dieser unstrukturierten Daten. Hinzu kommt, dass nahezu jeder Prozess Datenspuren in Informationssystemen hinterlässt. Die Betrachtung von Prozessen auf Datenebene birgt somit ein enormes Potential, welches in Anbetracht der Entwicklung zunehmend an Bedeutung gewinnt.

Was war nochmal Process Mining?

Process Mining ist eine Analysemethodik, welche dazu befähigt, aus den abgespeicherten Datenspuren der Informationssysteme eine Rekonstruktion der realen Prozesse zu schaffen. Diese Prozesse können anschließend als Prozessflussdiagramm dargestellt und ausgewertet werden. Die klassischen Anwendungsfälle reichen von dem Aufspüren (Discovery) unbekannter Prozesse, über einen Soll-Ist-Vergleich (Conformance) bis hin zur Anpassung/Verbesserung (Enhancement) bestehender Prozesse. Mittlerweile setzen viele Firmen darüber hinaus auf eine Integration von RPA und Data Science im Process Mining. Und die Analyse-Tiefe wird zunehmen und bis zur Analyse einzelner Klicks reichen, was gegenwärtig als sogenanntes „Task Mining“ bezeichnet wird.

Hier wird ein typischer Process Mining Workflow dargestellt

Abbildung 2 zeigt den typischen Workflow eines Process Mining Projektes. Oftmals dient das ERP-System als zentrale Datenquelle. Die herausgearbeiteten Event-Logs werden anschließend mittels Process Mining Tool visualisiert.

In jedem Fall liegt meistens das Gros der Arbeit auf die Bereitstellung und Vorbereitung der Daten und der Transformation dieser in sogenannte „Event-Logs“, die den Input für die Process Mining Tools darstellen. Deshalb arbeiten viele Anbieter von Process Mining Tools schon länger an Lösungen, um die mit der Datenvorbereitung verbundenen zeit -und arbeitsaufwendigen Schritte zu erleichtern. Während fast alle Tool-Anbieter vorgefertigte Protokolle für Standardprozesse anbieten, gehen manche noch weiter und bieten vollumfängliche Plattform Lösungen an, welche eine effiziente Integration der aufwendigen ETL-Prozesse versprechen. Der Funktionsumfang der Process Mining Tools geht daher mittlerweile deutlich über eine reine Darstellungsfunktion hinaus und deckt ggf. neue Trends sowie optimierte Einsteigerbarrieren mit ab.

Motivation dieser Artikelserie

Die Motivation diesen Artikel zu schreiben liegt nicht in der Erläuterung der Methode des Process Mining. Hierzu gibt es mittlerweile zahlreiche Informationsquellen. Eine besonders empfehlenswerte ist das Buch „Process Mining“ von Will van der Aalst, einem der Urväter des Process Mining. Die Motivation dieses Artikels liegt viel mehr in der Betrachtung der zahlreichen Process Mining Tools am Markt. Sehr oft erlebe ich als Data-Consultant, dass Process Mining Projekte im Vorfeld von der Frage nach dem „besten“ Tool dominiert werden. Diese Fragestellung ist in Ihrer Natur sicherlich immer individuell zu beantworten. Da individuelle Projekte auch einen individuellen Tool-Einsatz bedingen, beschäftige ich mich meist mit einem großen Spektrum von Process Mining Tools. Daher ist es mir in dieser Artikelserie ein Anliegen einen allgemeingültigen Überblick zu den üblichen Process Mining Tools zu erarbeiten. Dabei möchte ich mich nicht auf persönliche Erfahrungen stützen, sondern die Tools anhand von Testdaten einem praktischen Vergleich unterziehen, der für den Leser nachvollziehbar ist.

Um den Umfang der Artikelserie zu begrenzen, werden die verschiedenen Tools nur in Ihren Kernfunktionen angewendet und verglichen. Herausragende Funktionen oder Eigenschaften der jeweiligen Tools werden jedoch angemerkt und ggf. in anderen Artikeln vertieft. Das Ziel dieser Artikelserie soll sein, dem Leser einen ersten Einblick über die am Markt erhältlichen Tools zu geben. Daher spricht dieser Artikel insbesondere Einsteiger aber auch Fortgeschrittene im Process Mining an, welche einen Überblick über die Tools zu schätzen wissen und möglicherweise auch mal über den Tellerand hinweg schauen mögen.

Die Tools

Die Gruppe der zu betrachteten Tools besteht aus den folgenden namenhaften Anwendungen:

Die Auswahl der Tools orientiert sich an den „Market Guide for Process Mining 2019“ von Gartner. Aussortiert habe ich jene Tools, mit welchen ich bisher wenig bis gar keine Berührung hatte. Diese Auswahl an Tools verspricht meiner Meinung nach einen spannenden Einblick von verschiedene Process Mining Tools am Markt zu bekommen.

Die Anwendung in der Praxis

Um die Tools realistisch miteinander vergleichen zu können, werden alle Tools die gleichen Datengrundlage benutzen. Die Datenbasis wird folglich über die gesamte Artikelserie hinweg für die Darstellungen mit den Tools genutzt. Ich werde im nächsten Artikel explizit diese Datenbasis kurz erläutern.

Das Ziel der praktischen Untersuchung soll sein, die Beispieldaten in die verschiedenen Tools zu laden, um den enthaltenen Prozess zu visualisieren. Dabei möchte ich insbesondere darauf achten wie bedienbar und anpassungsfähig/flexibel die Tools mir erscheinen. An dieser Stelle möchte ich eindeutig darauf hinweisen, dass dieser Vergleich und seine Bewertung meine Meinung ist und keineswegs Anspruch auf Vollständigkeit beansprucht. Da der Markt in Bewegung ist, behalte ich mir ferner vor, diese Artikelserie regelmäßig anzupassen.

Die Kriterien

Neben der Bedienbarkeit und der Anpassungsfähigkeit der Tools möchte ich folgende zusätzliche Gesichtspunkte betrachten:

  • Bedienbarkeit: Wie leicht gehen die Analysen von der Hand? Wie einfach ist der Einstieg?
  • Anpassungsfähigkeit: Wie flexibel reagiert das Tool auf meine Daten und Analyse-Wünsche?
  • Integrationsfähigkeit: Welche Schnittstellen bringt das Tool mit? Läuft es auch oder nur in der Cloud?
  • Skalierbarkeit: Ist das Tool dazu in der Lage, auch große und heterogene Daten zu verarbeiten?
  • Zukunftsfähigkeit: Wie steht es um Machine Learning, ETL-Modeller oder Task Mining?
  • Preisgestaltung: Nach welchem Modell bestimmt sich der Preis?

Die Datengrundlage

Die Datenbasis bildet ein Demo-Datensatz der von Celonis für die gesamte Artikelserie netter Weise zur Verfügung gestellt wurde. Dieser Datensatz bildet einen Versand Prozess vom Zeitpunkt des Kaufes bis zur Auslieferung an den Kunden ab. In der folgenden Abbildung ist der Soll Prozess abgebildet.

Hier wird die Variante 1 der Demo Daten von Celonis als Grafik dargestellt

Abbildung 4 zeigt den gewünschten Versand Prozess der Datengrundlage von dem Kauf des Produktes bis zur Auslieferung.

Die Datengrundlage besteht aus einem 60 GB großen Event-Log, welcher lokal in einer Microsoft SQL Datenbank vorgehalten wird. Da diese Tabelle über 600 Mio. Events beinhaltet, wird die Datengrundlage für die Analyse der einzelnen Tools auf einen Ausschnitt von 60 Mio. Events begrenzt. Um die Performance der einzelnen Tools zu testen, wird jedoch auf die gesamte Datengrundlage zurückgegriffen. Der Ausschnitt der Event-Log Tabelle enthält 919 verschiedene Varianten und weisst somit eine ausreichende Komplexität auf, welche es mit den verschiednene Tools zu analysieren gilt.

Folgender Veröffentlichungsplan gilt für diese Artikelserie und wird mit jeder Veröffentlichung verlinkt:

  1. Celonis
  2. PAFnow
  3. MEHRWERK (erscheint demnächst)
  4. Lana Labs (erscheint demnächst)
  5. Signavio (erscheint demnächst)
  6. Process Gold (erscheint demnächst)
  7. Fluxicon Disco (erscheint demnächst)
  8. Aris Process Mining der Software AG (erscheint demnächst)

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.

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.

map(String key, String value): 
    //key: document name 
    //value: document contents 
    for each word w in value: 
        EmitIntermediate(w,"1"); 
     
reduce(String key, Iterator values): 
    //key: a word 
    //values: a list of counts 
    int result = 0; 
    for each v in values: 
        result += ParseInt(v); 
        Emit(AsString(result)); 

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.

 

Einstieg in das Maschinelle Lernen mit Python(x,y)

Python(x,y) ist eine Python-Distribution, die speziell für wissenschaftliche Arbeiten entwickelt wurde. Es umfasst neben der Programmiersprache auch die Entwicklungsumgebung Spyder und eine Reihe integrierter Python-Bibliotheken. Mithilfe von Python(x,y) kann eine Vielzahl von Interessensbereichen bearbeitet werden. Dazu zählen unter anderem Bildverarbeitung oder auch das maschinelle Lernen. Das All-in-One-Setup für Python(x,y) ist für alle gängigen Betriebssysteme online erhältlich. Read more

R Data Frames meistern mit dplyr – Teil 2

Dieser Artikel ist Teil 2 von 2 aus der Artikelserie R Data Frames meistern mit dplyr.

Noch mehr Datenbank-Features

Im ersten Teil dieser Artikel-Serie habe ich die Parallelen zwischen Data Frames in R und Relationen in SQL herausgearbeitet und gezeigt, wie das Paket dplyr eine Reihe von SQL-analogen Operationen auf Data Frames standardisiert und optimiert. In diesem Teil möchte ich nun drei weitere Analogien aufzeigen. Es handelt sich um die

  • Window Functions in dplyr als Entsprechung zu analytischen Funktionen in SQL,
  • Joins zwischen Data Frames als Pendant zu Tabellen-Joins
  • Delegation von Data Frame-Operationen zu einer bestehenden SQL-Datenbank

Window Functions

Im letzten Teil habe ich gezeigt, wie durch die Kombination von group_by() und summarise() im Handumdrehen Aggregate entstehen. Das Verb group_by() schafft dabei, wie der Name schon sagt, eine Gruppierung der Zeilen des Data Frame anhand benannter Schlüssel, die oft ordinaler oder kategorialer Natur sind (z.B. Datum, Produkt oder Mitarbeiter).

Ersetzt man die Aggregation mit summarise() durch die Funktion mutate(), um neue Spalten zu bilden, so ist der Effekt des group_by() weiterhin nutzbar, erzeugt aber „Windows“, also Gruppen von Datensätzen des Data Frames mit gleichen Werten der Gruppierungskriterien. Auf diesen Gruppen können nun mittels mutate() beliebige R-Funktionen angewendet werden. Das Ergebnis ist im Gegensatz zu summarise() keine Verdichtung auf einen Datensatz pro Gruppe, sondern eine Erweiterung jeder einzelnen Zeile um neue Werte. Das soll folgendes Beispiel verdeutlichen:

library(dplyr)
set.seed(42)	

df <- data.frame(id = 1:20, 
                 a=sample(c("Hund","Katze","Maus","Tiger"),20,replace=T),
                 b=sample(1:10,20, replace = T))
df
   id     a  b
1   1  Maus  7
2   2  Hund  3
3   3 Katze  3
4   4  Maus  4
5   5 Tiger 10
6   6  Maus 10
7   7  Hund  8
8   8  Hund  8
9   9  Hund  6
10 10 Katze  1
11 11  Maus  7
12 12  Hund  9
13 13  Hund  8
14 14 Tiger  5
15 15 Tiger  6
16 16  Maus  6
17 17 Katze  1
18 18  Maus  4
19 19  Maus  7
20 20  Maus  9
df %>%
  group_by(a) %>%
  mutate(r = row_number(),        # aus dplyr 
         n_memb = n(),            # aus dplyr
         n_dist = n_distinct(b),  # aus dplyr
         ra=rank(desc(b)),        # aus base und dplyr
         last_b = lag(b),         # aus dplyr
         next_b = lead(b),        # aus dplyr
         mb = mean(b),            # aus base
         cs = cumsum(b)  )        # aus base
Source: local data frame [20 x 11]
Groups: a [4]

     id      a     b     r n_memb n_dist    ra last_b next_b       mb     cs
                    
1      1   Maus     7     1      8      5   4.0     NA      4 6.750000     7
2      2   Hund     3     1      6      4   6.0     NA      8 7.000000     3
3      3  Katze     3     1      3      2   1.0     NA      1 1.666667     3
4      4   Maus     4     2      8      5   7.5      7     10 6.750000    11
5      5  Tiger    10     1      3      3   1.0     NA      5 7.000000    10
6      6   Maus    10     3      8      5   1.0      4      7 6.750000    21
7      7   Hund     8     2      6      4   3.0      3      8 7.000000    11
8      8   Hund     8     3      6      4   3.0      8      6 7.000000    19
9      9   Hund     6     4      6      4   5.0      8      9 7.000000    25
10    10  Katze     1     2      3      2   2.5      3      1 1.666667     4
11    11   Maus     7     4      8      5   4.0     10      6 6.750000    28
12    12   Hund     9     5      6      4   1.0      6      8 7.000000    34
13    13   Hund     8     6      6      4   3.0      9     NA 7.000000    42
14    14  Tiger     5     2      3      3   3.0     10      6 7.000000    15
15    15  Tiger     6     3      3      3   2.0      5     NA 7.000000    21
16    16   Maus     6     5      8      5   6.0      7      4 6.750000    34
17    17  Katze     1     3      3      2   2.5      1     NA 1.666667     5
18    18   Maus     4     6      8      5   7.5      6      7 6.750000    38
19    19   Maus     7     7      8      5   4.0      4      9 6.750000    45
20    20   Maus     9     8      8      5   2.0      7     NA 6.750000    54

Das group_by() unterteilt den Data Frame nach den 4 gleichen Werten von a. Innerhalb dieser Gruppen berechnen die beispielsweise eingesetzten Funktionen

  • row_number(): Die laufende Nummer in dieser Gruppe
  • n(): Die Gesamtgröße dieser Gruppe
  • n_distinct(b): Die Anzahl verschiedener Werte von b innerhalb der Gruppe
  • rank(desc(b)): Den Rang innerhalb der selben Gruppe, absteigend nach b geordnet
  • lag(b): Den Wert von b der vorherigen Zeile innerhalb derselben Gruppe
  • lead(b): Analog den Wert von b der folgenden Zeile innerhalb derselben Gruppe
  • mean(b): Den Mittelwert von b innerhalb der Gruppe
  • cumsum(b): Die kumulierte Summe der b-Werte innerhalb der Gruppe.

Wichtig ist hierbei, dass die Anwendung dieser Funktionen nicht dazu führt, dass die ursprüngliche Reihenfolge der Datensätze im Data Frame geändert wird. Hier erweist sich ein wesentlicher Unterschied zwischen Data Frames und Datenbank-Relationen von Vorteil: Die Reihenfolge von Datensätzen in Data Frames ist stabil und definiert. Sie resultiert aus der Abfolge der Elemente auf den Vektoren, die die Data Frames bilden. Im Gegensatz dazu haben Tabellen und Views keine Reihenfolge, auf die man sich beim SELECT verlassen kann. Nur mit der ORDER BY-Klausel über eindeutige Schlüsselwerte erreicht man eine definierte, stabile Reihenfolge der resultierenden Datensätze.

Die Wirkungsweise von Window Functions wird noch besser verständlich, wenn in obiger Abfrage das group_by(a) entfernt wird. Dann wirken alle genannten Funktionen auf der einzigen Gruppe, die existiert, nämlich dem gesamten Data Frame:

df %>%
  mutate(r = row_number(),        # aus dplyr 
         n_memb = n(),            # aus dplyr
         n_dist = n_distinct(b),  # aus dplyr
         ra=rank(desc(b)),        # aus base und dplyr
         last_b = lag(b),         # aus dplyr
         next_b = lead(b),        # aus dplyr
         mb = mean(b),            # aus base
         cs = cumsum(b)  )        # aus base


   id     a  b  r n_memb n_dist   ra last_b next_b  mb  cs
1   1  Maus  7  1     20      9  9.0     NA      3 6.1   7
2   2  Hund  3  2     20      9 17.5      7      3 6.1  10
3   3 Katze  3  3     20      9 17.5      3      4 6.1  13
4   4  Maus  4  4     20      9 15.5      3     10 6.1  17
5   5 Tiger 10  5     20      9  1.5      4     10 6.1  27
6   6  Maus 10  6     20      9  1.5     10      8 6.1  37
7   7  Hund  8  7     20      9  6.0     10      8 6.1  45
8   8  Hund  8  8     20      9  6.0      8      6 6.1  53
9   9  Hund  6  9     20      9 12.0      8      1 6.1  59
10 10 Katze  1 10     20      9 19.5      6      7 6.1  60
11 11  Maus  7 11     20      9  9.0      1      9 6.1  67
12 12  Hund  9 12     20      9  3.5      7      8 6.1  76
13 13  Hund  8 13     20      9  6.0      9      5 6.1  84
14 14 Tiger  5 14     20      9 14.0      8      6 6.1  89
15 15 Tiger  6 15     20      9 12.0      5      6 6.1  95
16 16  Maus  6 16     20      9 12.0      6      1 6.1 101
17 17 Katze  1 17     20      9 19.5      6      4 6.1 102
18 18  Maus  4 18     20      9 15.5      1      7 6.1 106
19 19  Maus  7 19     20      9  9.0      4      9 6.1 113
20 20  Maus  9 20     20      9  3.5      7     NA 6.1 122

Anwendbar sind hierbei sämtliche Funktionen, die auf Vektoren wirken. Diese müssen also wie in unserem Beispiel nicht unbedingt aus dplyr stammen. Allerdings komplettiert das Package die Menge der sinnvoll anwendbaren Funktionen um einige wichtige Elemente wie cumany() oder n_distinct().

Data Frames Hand in Hand…

In relationalen Datenbanken wird häufig angestrebt, das Datenmodell zu normalisieren. Dadurch bekommt man die negativen Folgen von Datenredundanz, wie Inkonsistenzen bei Datenmanipulationen und unnötig große Datenvolumina, in den Griff. Dies geschieht unter anderem dadurch, dass tabellarische Datenbestände aufgetrennt werden Stammdaten- und Faktentabellen. Letztere beziehen sich über Fremdschlüsselspalten auf die Primärschlüssel der Stammdatentabellen. Durch Joins, also Abfragen über mehrere Tabellen und Ausnutzen der Fremdschlüsselbeziehungen, werden die normalisierten Tabellen wieder zu einem fachlich kompletten Resultat denormalisiert.

In den Data Frames von R trifft man dieses Modellierungsmuster aus verschiedenen Gründen weit seltener an als in RDBMS. Dennoch gibt es neben der Normalisierung/Denormalisierung andere Fragestellungen, die sich gut durch Joins beantworten lassen. Neben der Zusammenführung von Beobachtungen unterschiedlicher Quellen anhand charakteristischer Schlüssel sind dies bestimmte Mengenoperationen wie Schnitt- und Differenzmengenbildung.

Die traditionelle R-Funktion für den Join zweier Data Frames lautet merge(). dplyr erweitert den Funktionsumfang dieser Funktion und sorgt für sprechendere Funktionsnamen und Konsistenz mit den anderen Operationen.

Hier ein synthetisches Beispiel:

products <- data.frame(
  id = 1:5, 
  name = c("Desktop", "Laptop", "Maus", "Tablet", "Smartphone"),
  preis = c(500, 700, 10, 300, 500)  
)

set.seed(1)

(salesfacts <- data.frame(
  prod_id = sample(1:5,size = 8,replace = T),
  date = as.Date('2017-01-01') + sample(1:5,size = 8,replace = T)
)  )  

 prod_id       date
1      2 2017-01-05
2      2 2017-01-02
3      3 2017-01-03
4      5 2017-01-02
5      2 2017-01-05
6      5 2017-01-03
7      5 2017-01-05
8      4 2017-01-04

Nun gilt es, die Verkäufe aus dem Data Frame sales mit den Produkten in products zusammenzuführen und auf Basis von Produkten Bilanzen zu erstellen. Diese Denormalisierung geschieht durch das Verb inner_join() auf zweierlei Art und Weise:

salesfacts %>% 
  inner_join(products, by = c("prod_id" = "id"))

  prod_id       date       name preis
1       2 2017-01-05     Laptop   700
2       2 2017-01-02     Laptop   700
3       3 2017-01-03       Maus    10
4       5 2017-01-02 Smartphone   500
5       2 2017-01-05     Laptop   700
6       5 2017-01-03 Smartphone   500
7       5 2017-01-05 Smartphone   500
8       4 2017-01-04     Tablet   300

products %>% 
  inner_join(salesfacts, by = c("id" = "prod_id")) 

  id       name preis       date
1  2     Laptop   700 2017-01-05
2  2     Laptop   700 2017-01-02
3  2     Laptop   700 2017-01-05
4  3       Maus    10 2017-01-03
5  4     Tablet   300 2017-01-04
6  5 Smartphone   500 2017-01-02
7  5 Smartphone   500 2017-01-03
8  5 Smartphone   500 2017-01-05

Die Ergebnisse sind bis auf die Reihenfolge der Spalten und der Zeilen identisch. Außerdem ist im einen Fall der gemeinsame Schlüssel der Produkt-Id als prod_id, im anderen Fall als id enthalten. dplyr entfernt also die Spalten-Duplikate der Join-Bedingungen. Letzere wird bei Bedarf im by-Argument der Join-Funktion angegeben. R-Experten erkennen hier einen „Named Vector“, also einen Vektor, bei dem jedes Element einen Namen hat. Diese Syntax verwendet dplyr, um elegant die äquivalenten Spalten zu kennzeichnen. Wird das Argument by weggelassen, so verwendet dplyr im Sinne eines „Natural Join“ automatisch alle Spalten, deren Namen in beiden Data Frames vorkommen.

Natürlich können wir dieses Beispiel mit den anderen Verben erweitern, um z.B. eine Umsatzbilanz pro Produkt zu erreichen:

salesfacts %>% 
  inner_join(products, by = c("prod_id" = "id")) %>% 
  group_by(prod_id) %>% 
  summarise(n_verk = n(), sum_preis = sum(preis), letzt_dat = max(date))

# A tibble: 4 × 4
  prod_id n_verk sum_preis  letzt_dat
                
1       2      3      2100 2017-01-05
2       3      1        10 2017-01-03
3       4      1       300 2017-01-04
4       5      3      1500 2017-01-05

dplyr bringt insgesamt 6 verschiedene Join-Funktionen mit: Neben dem bereits verwendeten Inner Join gibt es die linksseitigen und rechtsseitigen Outer Joins und den Full Join. Diese entsprechen genau der Funktionalität von SQL-Datenbanken. Daneben gibt es die Funktion semi_join(), die in SQL etwa folgendermaßen ausgedrückt würde:

SELECT ...
FROM a
WHERE EXISTS (SELECT * FROM b WHERE b.a_id = a.id)

Das Gegenteil, also ein NOT EXISTS, realisiert die sechste Join-Funktion: anti_join(). Im folgenden Beispiel sollen alle Produkte ausgegeben werden, die noch nie verkauft wurden:

products %>% anti_join(salesfacts,c("id" = "prod_id"))

  id    name preis
1  1 Desktop   500

… und in der Datenbank

Wir schon mehrfach betont, hat dplyr eine Reihe von Analogien zu SQL-Operationen auf relationalen Datenbanken. R Data Frames entsprechen Tabellen und Views und die dplyr-Operationen den Bausteinen von SELECT-Statements. Daraus ergibt sich die Möglichkeit, dplyr-Funktionen ohne viel Zutun auf eine bestehende Datenbank und deren Relationen zu deligieren.

Mir fallen folgende Szenarien ein, wo dies sinnvoll erscheint:

  • Die zu verarbeitende Datenmenge ist zu groß für das Memory des Rechners, auf dem R läuft.
  • Die interessierenden Daten liegen bereits als Tabellen und Views auf einer Datenbank vor.
  • Die Datenbank hat Features, wie z.B. Parallelverarbeitung oder Bitmap Indexe, die R nicht hat.

In der aktuellen Version 0.5.0 kann dplyr nativ vier Datenbank-Backends ansprechen: SQLite, MySQL, PostgreSQL und Google BigQuery. Ich vermute, unter der Leserschaft des Data Science Blogs dürfte MySQL (oder der Fork MariaDB) die weiteste Verbreitung haben, weshalb ich die folgenden Beispiele darauf zeige. Allerdings muss man beachten, dass MySQL keine Window Funktionen kennt, was sich 1:1 auf die Funktionalität von dplyr auswirkt.

Im folgenden möchte ich zeigen, wie dplyr sich gegen eine bestehende MySQL-Datenbank verbindet und danach einen bestehenden R Data Frame in eine neue Datenbanktabelle wegspeichert:

mysql_db <- src_mysql(host = "localhost", user = "testuser",
                   password = "********", dbname = "test")

library(ggplot2)

str(diamonds)

Classes ‘tbl_df’, ‘tbl’ and 'data.frame':       53940 obs. of  10 variables:
 $ carat  : num  0.23 0.21 0.23 0.29 0.31 0.24 0.24 0.26 0.22 0.23 ...
 $ cut    : chr  "Ideal" "Premium" "Good" "Premium" ...
 $ color  : chr  "E" "E" "E" "I" ...
 $ clarity: chr  "SI2" "SI1" "VS1" "VS2" ...
 $ depth  : num  61.5 59.8 56.9 62.4 63.3 62.8 62.3 61.9 65.1 59.4 ...
 $ table  : num  55 61 65 58 58 57 57 55 61 61 ...
 $ price  : int  326 326 327 334 335 336 336 337 337 338 ...
 $ x      : num  3.95 3.89 4.05 4.2 4.34 3.94 3.95 4.07 3.87 4 ...
 $ y      : num  3.98 3.84 4.07 4.23 4.35 3.96 3.98 4.11 3.78 4.05 ...
 $ z      : num  2.43 2.31 2.31 2.63 2.75 2.48 2.47 2.53 2.49 2.39 ...

diamonds %>% mutate(cut = as.character(cut), 
                    color = as.character(color),
                    clarity = as.character(clarity)) -> diamonds

diamonds_mysql <- copy_to(mysql_db, diamonds, name="diamonds",
                         temporary = FALSE, indexes = list(
                       c("cut", "color", "clarity"), "carat", "price"))

diamonds_mysql %>% summarise(count = n())

Source:   query [?? x 1]
Database: mysql 5.5.54-0ubuntu0.14.04.1 [testuser@localhost:/test]

  count
  <dbl>
1 53940

Die erste Anweisung verbindet R mit einer bestehenden MySQL-Datenbank. Danach lade ich den Data Frame diamonds aus dem Paket ggplot2. Mit str() wird deutlich, dass drei darin enthaltene Variablen vom Typ Factor sind. Damit dplyr damit arbeiten kann, werden sie mit mutate() in Character-Vektoren gewandelt. Dann erzeugt die Funktion copy_to() auf der MySQL-Datenbank eine leere Tabelle namens diamonds, in die die Datensätze kopiert werden. Danach erhält die Tabelle noch drei Indexe (von dem der erste aus drei Segmenten besteht), und zum Schluß führt dplyr noch ein ANALYSE der Tabelle durch, um die Werteverteilungen auf den Spalten für kostenbasierte Optimierung zu bestimmen.

Meistens aber wird bereits eine bestehende Datenbanktabelle die interessierenden Daten enthalten. In diesem Fall lautet die Funktion zum Erstellen des Delegats tbl():

diamonds_mysql2 <- tbl(mysql_db,"diamonds")

identical(diamonds_mysql,diamonds_mysql2)

[1] TRUE

Die Rückgabewerte von copy_to() und von tbl() sind natürlich keine reinrassigen Data Frames, sondern Objekte, auf die die Operationen von dplyr wirken können, indem sie auf die Datenbank deligiert werden. Im folgenden Beispiel sollen alle Diamanten, die ein Gewicht von mindestens 1 Karat haben, pro Cut, Color und Clarity nach Anzahl und mittlerem Preis bilanziert werden:

bilanz <- diamonds_mysql2 %>% 
  filter(carat >= 1) %>% 
  group_by(cut,color,clarity) %>% 
  summarise(count = n(), mean_price = mean(price))

bilanz

Source:   query [?? x 5]
Database: mysql 5.5.54-0ubuntu0.14.04.1 [testuser@localhost:/test]
Groups: cut, color

     cut color clarity count mean_price
   <chr> <chr>   <chr> <dbl>      <dbl>
1   Fair     D      I1     3   9013.667
2   Fair     D     SI1    26   6398.192
3   Fair     D     SI2    29   6138.552
4   Fair     D     VS1     1   7083.000
5   Fair     D     VS2     7   8553.429
6   Fair     D    VVS1     1  10752.000
7   Fair     D    VVS2     2   9639.000
8   Fair     E      I1     5   2469.800
9   Fair     E     SI1    28   6407.464
10  Fair     E     SI2    45   5627.489
# ... with more rows

explain(bilanz)

<SQL>
SELECT `cut`, `color`, `clarity`, count(*) AS `count`, AVG(`price`) AS `mean_price`
FROM (SELECT *
FROM `diamonds`
WHERE (`carat` >= 1.0)) `cttxnwlelz`
GROUP BY `cut`, `color`, `clarity`


<PLAN>
  id select_type      table type  possible_keys  key key_len  ref  rows
1  1     PRIMARY <derived2>  ALL           <NA> <NA>    <NA> <NA> 19060
2  2     DERIVED   diamonds  ALL diamonds_carat <NA>    <NA> <NA> 50681
                            Extra
1 Using temporary; Using filesort
2                     Using where

Die Definition der Variablen bilanz geschieht dabei komplett ohne Interaktion mit der Datenbank. Erst beim Anzeigen von Daten wird das notwendige SQL ermittelt und auf der DB ausgeführt. Die ersten 10 resultierenden Datensätze werden angezeigt. Mittels der mächtigen Funktion explain() erhalten wir das erzeugte SQL-Kommando und sogar den Ausführungsplan auf der Datenbank. SQL-Kundige werden erkennen, dass die verketteten dplyr-Operationen in verschachtelte SELECT-Statements umgesetzt werden.

Zu guter Letzt sollen aber meistens die Ergebnisse der dplyr-Operationen irgendwie gesichert werden. Hier hat der Benutzer die Wahl, ob die Daten auf der Datenbank in einer neuen Tabelle gespeichert werden sollen oder ob sie komplett nach R transferiert werden sollen. Dies erfolgt mit den Funktionen compute() bzw. collect():

compute(bilanz, name = "t_bilanz", temporary = F)

df <- collect(bilanz)

str(df)

Classes ‘grouped_df’, ‘tbl_df’, ‘tbl’ and 'data.frame': 265 obs. of  5 variables:
 $ cut       : chr  "Fair" "Fair" "Fair" "Fair" ...
 $ color     : chr  "D" "D" "D" "D" ...
 $ clarity   : chr  "I1" "SI1" "SI2" "VS1" ...
 $ count     : num  3 26 29 1 7 1 2 5 28 45 ...
 $ mean_price: num  9014 6398 6139 7083 8553 ...
...

Durch diese beiden Operationen wurde eine neue Datenbanktabelle „t_bilanz“ erzeugt und danach der Inhalt der Bilanz als Data Frame zurück in den R-Interpreter geholt. Damit schließt sich der Kreis.

Fazit

Mit dem Paket dplyr von Hadley Wickham wird die Arbeit mit R Data Frames auf eine neue Ebene gehoben. Die Operationen sind konsistent, vollständig und performant. Durch den Verkettungs-Operator %>% erhalten sie auch bei hoher Komplexität eine intuitive Syntax. Viele Aspekte der Funktionalität lehnen sich an Relationale Datenbanken an, sodass Analysten mit SQL-Kenntnissen rasch viele Operationen auf R Data Frames übertragen können.

Zurück zu R Data Frames meistern mit dplyr – Teil 1.

 

Was ist eigentlich Apache Spark?

Viele Technologieanbieter versprechen schlüsselfertige Lösungen für Big Data Analytics, dabei kann keine proprietäre Software-Lösung an den Umfang und die Mächtigkeit einiger Open Source Projekten heranreichen.

Seit etwa 2010 steht das Open Source Projekt Hadoop, ein Top-Level-Produkt der Apache Foundation, als einzige durch Hardware skalierbare Lösung zur Analyse von strukturierten und auch unstrukturierten Daten. Traditionell im Geschäftsbereich eingesetzte Datenbanken speichern Daten in einem festen Schema ab, das bereits vor dem Laden der Daten definiert sein muss. Dieses Schema-on-Write-Prinzip stellt zwar sicher, dass Datenformate bekannt und –konflikte vermieden werden. Es bedeutet jedoch auch, dass bereits vor dem Abspeichern bekannt sein muss, um welche Daten es sich handelt und ob diese relevant sind. Im Hadoop File System (HDFS) wird ein Schema für erst bei lesenden Zugriff erstellt.

Apache Spark ist, ähnlich wie Hadoop, dank Parallelisierung sehr leistungsfähig und umfangreich mit Bibliotheken (z. B. für Machine Learning) und Schnittstellen (z. B. HDFS) ausgestattet. Allerdings ist Apache Spark nicht für jede Big Data Analytics Aufgabe die beste Lösung, Als Einstiegslektüre empfiehlt sich das kostenlose Ebook Getting Started with Spark: From Inception to Production. Wer jedoch erstmal wissen möchte, erfährt nachfolgend die wichtigsten Infos, die es über Apache Spark zu wissen gilt.

Was ist Apache Spark?

Apache Spark ist eine Allzweck-Tool zur Datenverarbeitung, eine sogenannte Data Processing Engine. Data Engineers und Data Scientists setzen Spark ein, um äußerst schnelle Datenabfragen (Queries) auf große Datenmengen im Terabyte-Bereich ausführen zu können.

Spark wurde 2013 zum Incubator-Projekt der Apache Software Foundation, eine der weltweit wichtigsten Organisationen für Open Source. Bereits 2014 es wie Hadoop zum Top-Level-Produkt. Aktuell ist Spark eines der bedeutensten Produkte der Apache Software Foundation mit viel Unterstützung von Unternehmen wie etwa Databricks, IBM und Huawei.

Was ist das Besondere an Spark?

Mit Spark können Daten transformiert, zu fusioniert und auch sehr mathematische Analysen unterzogen werden.
Typische Anwendungsszenarien sind interactive Datenabfragen aus verteilten Datenbeständen und Verarbeitung von fließenden Daten (Streaming) von Sensoren oder aus dem Finanzbereich. Die besondere Stärke von Spark ist jedoch das maschinelle Lernen (Machine Learning) mit den Zusätzen MLib (Machine Learning Bibliothek) oder SparkR (R-Bibliotheken direkt unter Spark verwenden), denn im Gegensatz zum MapReduce-Algorithmus von Hadoop, der einen Batch-Prozess darstellt, kann Spark sehr gut iterative Schleifen verarbeiten, die für Machine Learning Algorithmen, z. B. der K-Nearest Neighbor Algorithmus, so wichtig sind.spark-stack

Spark war von Beginn an darauf ausgelegt, Daten dynamisch im RAM (Arbeitsspeicher) des Server-Clusters zu halten und dort zu verarbeiten. Diese sogenannte In-Memory-Technologie ermöglicht die besonders schnelle Auswertung von Daten. Auch andere Datenbanken, beispielsweise SAP Hana, arbeiten In-Memory, doch Apache Spark kombiniert diese Technik sehr gut mit der Parallelisierung von Arbeitsschritten über ein Cluster und setzt sich somit deutlich von anderen Datenbanken ab. Hadoop ermöglicht über MapReduce zwar ebenfalls eine Prallelisierung, allerdings werden bei jedem Arbeitsschrit Daten von einer Festplatte zu einer anderen Festplatte geschrieben. Im Big Data Umfeld kommen aus Kostengründen überwiegend noch mechanisch arbeitende Magnet-Festplatten zum Einsatz, aber selbst mit zunehmender Verbreitung von sehr viel schnelleren SSD-Festplatten, ist der Arbeitsspeicher hinsichtlich der Zeiten für Zugriff auf und Schreiben von Daten unschlagbar. So berichten Unternehmen, die Spark bereits intensiv einsetzen, von einem 100fachen Geschwindigkeitsvorteil gegenüber Hadoop MapReduce.

Spark kann nicht nur Daten im Terabyte, sondern auch im Petabyte-Bereich analysieren, ein entsprechend großes Cluster, bestehend aus tausenden physikalischer oder virtueller Server, vorausgesetzt. Ähnlich wie auch bei Hadoop, skaliert ein Spark-Cluster mit seiner Größe linear in seiner Leistungsfähigkeit. Spark ist neben Hadoop ein echtes Big Data Framework.
Spark bringt sehr viele Bibliotheken und APIs mit, ist ferner über die Programmiersprachen Java, Python, R und Scala ansprechbar – das sind ohne Zweifel die im Data Science verbreitetsten Sprachen. Diese Flexibilität und geringe Rüstzeit rechtfertigt den Einsatz von Spark in vielen Projekten. Es kann sehr herausfordernd sein, ein Data Science Team mit den gleichen Programmiersprachen-Skills aufzubauen. In Spark kann mit mehreren Programmiersprachen gearbeitet werden, so dass dieses Problem teilweise umgangen werden kann.spark-runs-everywhere

In der Szene wird Spark oftmals als Erweiterung für Apache Hadoop betrachtet, denn es greift nahtlos an HDFS an, das Hadoop Distributed File System. Dank der APIs von Spark, können jedoch auch Daten anderer Systeme abgegriffen werden, z. B. von HBase, Cassandra oder MongoDB.

Was sind gängige Anwendungsbeispiele für Spark?

  • ETL / Datenintegration: Spark und Hadoop eignen sich sehr gut, um Daten aus unterschiedlichen Systemen zu filtern, zu bereinigen und zusammenzuführen.
  • Interaktive Analyse: Spark eignet sich mit seinen Abfragesystemen fantastisch zur interaktiven Analyse von großen Datenmengen. Typische Fragestellungen kommen aus dem Business Analytics und lauten beispielsweise, welche Quartalszahlen für bestimmte Vertriebsregionen vorliegen, wie hoch die Produktionskapazitäten sind oder welche Lagerreichweite vorhanden ist. Hier muss der Data Scientist nur die richtigen Fragen stellen und Spark liefert die passenden Antworten.
  • Echtzeit-Analyse von Datenströmen: Anfangs vor allem zur Analyse von Server-Logs eingesetzt, werden mit Spark heute auch Massen von Maschinen- und Finanzdaten im Sekundentakt ausgewertet. Während Data Stream Processing für Hadoop noch kaum möglich war, ist dies für Spark ein gängiges Einsatzgebiet. Daten, die simultan von mehreren Systemen generiert werden, können mit Spark problemlos in hoher Geschwindigkeit zusammengeführt und analysiert werden.
    In der Finanzwelt setzen beispielsweise Kreditkarten-Unternehmen Spark ein, um Finanztransaktionen in (nahezu) Echtzeit zu analysieren und als potenziellen Kreditkartenmissbrauch zu erkennen.
  • Maschinelles Lernen: Maschinelles Lernen (ML – Machine Learning) funktioniert desto besser, je mehr Daten in die ML-Algorithmen einbezogen werden. ML-Algorithmen haben in der Regel jedoch eine intensive, vom Data Scientist betreute, Trainingsphase, die dem Cluster viele Iterationen an Arbeitsschritten auf die großen Datenmengen abverlangen. Die Fähigkeit, Iterationen auf Daten im Arbeitsspeicher, parallelisiert in einem Cluster, durchführen zu können, macht Spark zurzeit zu dem wichtigsten Machine Learning Framework überhaupt.
    Konkret laufen die meisten Empfehlungssysteme (beispielsweise von Amazon) auf Apache Spark.

 

Eine Hadoop Architektur mit Enterprise Sicherheitsniveau

Dies ist Teil 3 von 3 der Artikelserie zum Thema Eine Hadoop-Architektur mit Enterprise Sicherheitsniveau.

Die ideale Lösung

Man denkt, dass die Integration einer sehr alten Technologie, wie ActiveDirectory oder LDAP zusammen mit einem etablierten und ausgereiften Framework wie Hadoop reibungslos funktionieren würde. Leider sind solche Annahmen in der IT Welt zu gut um wahr zu sein. Zum Glück gibt es bereits erste Erfahrungsberichte  von  Unternehmen, die ihre Hadoop Infrastruktur an ein zentrales IMS gekoppelt haben.

Da die meisten Unternehmen  Active Directory als IMS benutzen, werden die im Folgenden  dargestellte Bilder und Architekturen dies ebenfalls tun.  Die vorgeschlagene Architektur ist jedoch derartig flexibel und technologieunabhängig, dass man das Active Directory auf den Bildern problemlos gegen LDAP austauschen könnte. Vielmehr ist die Integration eines Hadoop Clusters mit LDAP einfacher, da beide Technologien nativ zu Linux sind.

Schritt Eins – Integration von Hadoop mit Active Directory

Der erste Schritt, um Hadoop in dasActive Directory zu integrieren, ist ein sogenannter One-Way Trust von der Linux Welt hin zur Windows Welt . Dabei ist das Vertrauen des Authentisierungsmechanismuses von Hadoop zum Active Directory gemeint. Alle Identity Management Systeme bieten diese Funktionalität an, um sich gegenseitig vertrauen zu können und User aus anderen Domänen (Realms) zu akzeptieren. Das ermöglicht z.B. globalen Firmen mit vielen Standorten und unterschiedlichen IT Infrastrukturen und Identity Management Systemen diese zu verwalten und miteinander kommunizieren zu lassen.

Das Key Distribution Center (KDC) von Kerberos ist das Herz des Kerberos Systems im Hadoop. Hier  werden die User und ihre Passwörter oder Keytabs geschützt und verwaltet. Dabei brauchen wir lediglich den One Way Trust von KDC zu Active Directory. Allerdings gibt es eine vielversprechendere Technologie, die FreeIPA. Diese hat laut Wikipedia das Ziel, ein einfach zu verwaltendes Identity,-Policy-and-Audit-System (IPA) zur Verfügung zu stellen. Seit der Version 3.0.0 kann sich FreeIPA in das Active Directory integrieren. Die aussagekräftigen Vorteile von FreeIPA sind folgende:

  1. Reibungslose Integration mit Active Directory
  2. Es wird zusammen mit der Technologie SSSD geliefert, die das temporäre Speichern von Rechten und Passwörtern erlaubt. Das erlaubt auch offline den Zugriff auf  Fähigkeiten und Unabhängigkeit vom zentralen IPA, dem unterliegenden System.
  3. Integrierte Kerberos und Single Sign On (SSO) Funktionalitäten.

Wir lassen dann FreeIPA die Verwaltung von Kerberos und die primäre Authentisierung unseres Clusters übernehmen. Sowohl das Active Directory, als auch FreeIPA erlauben eine kinderleichte Umsetzung des One Way Trusts mithilfe von Web Tools. Im Prinzip muss man beim One Way Trust lediglich die öffentlichen Zertifikate jedes Tools mit denen der anderen bekannt machen.

Schritt Zwei – Synchronisation der Rechte & Rollen von Active Directory

Jetzt sind alle User, die sich im Active Directory befinden, unserem Hadoop Cluster bekannt. Ein User kann sich mithilfe des kinit Kommandos und nach Eingabe seines Usernames und Passwortes einloggen. Aber man braucht auch die im Active Directory definierten Rollen und Gruppen, um eine Autorisierung mithilfe von Ranger oder Sentry zu ermöglichen. Ohne die Provisionierung der Rollen haben wir bei der Autorisierung ein ähnliches Problem, wie es bei der Authentisierung aufgetreten ist.  Man müsste die Rollen selber verwalten, was nicht ideal ist.

Zum Glück gibt es verschiedene Ansätze um eine regelforme Synchronisierung der Gruppen von Active Directory in Ranger oder Sentry zu implementieren. Ranger kommt mit einem LDAP Plugin namens uxugsync, das sowohl mit LDAP als auch mit dem Active Directory kommunizieren kann. Leider hat die aktuelle Version dieses Plugins einige Nachteile:

  1. Leistungsprobleme, weil es defaultsmäßig versucht, den ganzen Hierarchiebaum von Active Directory zu synchronisieren. Das kann zu einem großen Problem für große Firmen werden, die mehrere tausend User haben. Außerdem müssen nicht alle User Zugriff auf Hadoop haben.
  2. Man kann bestimmte User syncen lassen, indem man ihren Gruppename im Gruppenfeld vom Plugin einträgt. Nachteil dabei ist, dass diese Abfrage nicht rekursiv funktioniert und alle Gruppe die im Ranger sein sollen einzeln abgefragt werden müssen, Das wiederum skaliert nicht sonderlich gut.
  3. Massive und regelmäßige Abfragen des Plugins können sogar zu einem DDoS Angriff auf den zentralen Active Directory führen.

Eine bessere Lösung wäre es, wenn wir die schönen Features des SSSD Deamons (der wie oben beschrieben zusammen mit FreeIPA kommt) ausnutzen könnten. Mithilfe von SSSD werden alle User und ihre entsprechenden Gruppen dem unterliegenden Linux Betriebssystem bekannt gemacht. Das bedeutet, dass man ein einfaches Script schreiben könnte, das die User und ihre Gruppen vom System direkt abfragt und zu Ranger oder Sentry über ihre entsprechende REST APIs überträgt. Dabei schont man sowohl das Active Directory vor regelmäßigen und aufwändigen Abfragen und schafft sogar ein schnelleres Mapping der Rollen zwischen Hadoop und Betriebssystem, auch wenn Active Directory nicht erreichbar ist. Es gibt derzeit Pläne, ein solches Plugin in den nächsten Versionen von Ranger mitzuliefern.

Schritt Drei – Anlegen und Verwaltung von technischen Usern

Unser System hat jedoch neben personalisierten Usern, die echten Personen in einem Unternehmen entsprechen, auch  technische User. Die technischen Users (Nicht Personalisierte Accounts – NPA), sind die Linux User mit denen die Hadoop Dienste gestartet werden. Dabei hat HDFS, Ambari usw. jeweils seinen eigenen User mit demselben Namen. Rein theoretisch könnten diese User auch im Active Directory einen Platz finden.

Meiner Meinung nach gehören diese User aber nicht dorthin. Erstens, weil sie keine echten User sind und zweitens, weil die Verwaltung solcher User nach Upgrades oder Neuinstallation des Clusters schwierig sein kann. Außerdem müssen solche User nicht den gleichen Sicherheitspolicies unterliegen, wie die normalen User. Am besten sollten sie kein Passwort besetzen, sondern lediglich ein Kerberos Keytab, das sich nach jedem Upgrade oder Neuinstallierung des Clusters neu generiert und in FreeIPA angelegt ist. Deswegen neige ich eher dazu, die NPAs in IPA anzulegen und zu verwalten.

High Level Architektur

Das folgende Bild fasst die Architektur zusammen. Hadoop Dienste, die üblicherweise in einer explorativen Umgebung benutzt werden, wie Hive und HBase, werden mit dargestellt. Es ist wichtig zu beachten, dass jegliche Technologie, die ein Ausführungsengine für YARN anbietet, wie Spark oder Storm, von dieser Architektur ebenfalls profitiert. Da solche Technologien nicht direkt mit den unterliegenden Daten interagieren, sondern diese immer über YARN und die entsprechenden Datanodes erhalten, benötigen sie auch keine besondere Darstellung oder Behandlung. Der Datenzugriff aus diesen 3rd Party Technologien respektiert die im Ranger definierten ACLs und Rollen des jeweiligen Users, der sie angestoßen hat.

hadoop-integration-active-directory-ipa-domain

Architektur in einer Mehrclusterumgebung

Wir haben schon das Argument untermauert, warum  unsere technischen User direkt im IPA liegen sollten. Das kann jedoch insofern Probleme verursachen, wenn man mit mehreren Clustern arbeitet, die alle die gleichen Namen für ihre technischen User haben. Man merkt sofort, dass es sich hier um eine Namenskollision handelt. Es gibt zwei Lösungsansätze hierfür:

  1. Man fügt den Namen Präfixen, die als kurze Beschreibungen der jeweiligen Umgebung dienen, wie z.B. ada, proj1, proj2 hinzu. Dadurch haben die User unterschiedliche Namen, wie proj1_hdfs für die proj1 Umgebung und ada_hdfs für die ada Umgebung. Man kann diese Lösung auch bei Kerberos KDCs benutzen, die in jeder Umgebung dediziert sind und die technischen User der jeweiligen Umgebung beibehalten.
  2. Man benutzt einen separaten Realm für jede Umgebung und damit auch eine separate IPA Instanz. Hier gibt es wiederum zwei verschiedene Ansätze. Ich muss jedoch zugeben, dass ich die Zweite nie ausprobiert habe und daher für ihre Durchführbarkeit nicht garantieren kann:
    1. Man bindet jede Umgebung einzeln über ihre FreeIPA per One Way Trust an das zentrale Active Directory. Das hat natürlich den Nachteil einer uneinheitlichen User Management Infrastruktur für alle Umgebungen, da Jede ihre eigene IPA Infrastruktur verwaltet und wartet.
    2. Man baut einen Hierarchiebaum von unterschiedlichen IPA Instanzen, so wie man es bei Forests von Active Directory Instanzen macht.

Das folgende Bild stellt den letzten Ansatz dar. Im Prinzip haben wir hier einen hierarchischen IPA Cluster mit mehreren One Way Trusts von den lokalen IPA Instanzen zu der zentralen IPA.

hadoop-local-identity-management-domain-ipa-netzwerk

Zusammenfassung

Wie Sie vielleicht von der gesamten Diskussion her abgeleitet haben, ist die Umsetzung einer unternehmerisch-konformen und personenbasierten Sicherheitsarchitektur innerhalb von Hadoop  keine einfache Sache. Man muss mit unterschiedlichen Architekturen und Ansätzen spielen, bevor man einen relativ vernünftigen oder sogar idealen Zustand erreicht hat. Die Berücksichtigung der jeweiligen IT Architektur spielt dabei eine sehr große Rolle. Ich hoffe, ich konnte die wichtigsten Merkmalen einer solchen Architektur und die Punkte, die ein Architekt besonders beachten muss, klar darstellen.

Als Zusammenfassung habe ich Ihnen am Ende eine Art Shoppingliste aller Komponenten zusammengestellt, die wichtig für den personalisierten Zugriff im Hadoop sind:

  1. Kerberos – Authentisierung
  2. FreeIPA – Authentisierung, Integration mit Active Directory
  3. Active Directory oder LDAP
  4. Ranger oder Sentry
    1. Plugin für Rollen/Gruppen Mapping zwischen AD und dem Betriebssystem
  5. Optional SSSD für schnellere Abfrage der Gruppen und Rollen des Betriebssystems

Zurück zu Teil 2 von 3 – Sicherheitstechnologie in Hadoop

Data Leader Guide – Call for Papers

Connected Industry e. V., der Verband für Digitalisierung und Vernetzung, sammelt wegweisende Anwendungsfälle rund um Digitalisierung und Data Science und fasst diese in einem Leitfaden zusammen, dem Data Leader Guide 2016.

data-leader-guide-cover

Welche Inhalte kommen in den Data Leader Guide?

Der Data Leader Guide konzentriert sich auf Anwendungsfälle aus dem deutschsprachigen Wirtschaftsraum D/A/CH. In diesem Data Leader Guide werden vornehmlich die praktisch umgesetzten Use Cases / Business Cases von Anwender-Unternehmen aus den Branchen Industrie/Produktion, Dienstleistungen, Finanzen und Handel praxisorientiert beschrieben.

Was ist das Ziel des Data Leader Guide?

Anhand greifbarer Erfahrungswerte soll Entscheidern, Entwicklern und sonstigen Interessenten eine Orientierung und der Zugang zu dieser komplexen Materie erleichtert werden. Von besonderem Nutzen ist dabei der branchenübergreifende Blickwinkel des Leitfadens, da der Wissenstransfer von anderen Industrien gerade bei Big Data nicht hoch genug eingeschätzt werden kann.

Wann wird der Data Leader Guide 2016 erscheinen?

Pünktlich zum Data Leader Day am 17. November 2016. Die Ausgaben werden als Druckversion sowie als digitale Version erscheinen.

Warum sollte Ihre Anwendungsfall bzw. Projekt nicht fehlen?

Ihr Projekt wird zum Aushängeschild für die Innovationskraft und des Fortschritts Ihres Unternehmens. Darüber hinaus unterstreicht es die Attraktivität Ihres Unternehmens für qualifizierten Nachwuchs aus dem IT- und ingenieurswissenschaftlichen Bereich. Schließlich ist die Aufnahme Ihres Anwendungsfalles in den Data Leader Guide eine der seltenen Möglichkeiten, diesen auch öffentlich zu präsentieren und somit die Leistung des gesamten Projekt-Teams zu würdigen.

Call for Papers

So bringen Sie Ihren Anwendungsfall in den Data Leader Guide:

Sie sind Geschäftsführer, CIO oder ein Mitarbeiter mit Verantwortung für ein Projekt mit starkem Bezug zur Digitalisierung, Big Data, Data Science oder Industrie 4.0? Dann sollten Sie Ihr Projekt für einen Eintrag in den Data Leader Guide von Connected Industry bewerben. Genauere Informationen, wie Sie Ihren Anwendungsfall (Use Case / Business Case) in den Data Leader Guide 2016 bringen, finden Sie über diesen Direktlink zum Connected Industry e.V.