Wahrscheinlichkeitsverteilungen – Zentralen Grenzwertsatz verstehen mit Pyhton

Wahrscheinlichkeitsverteilung sind im Data Science ein wichtiges Handwerkszeug. Während in der Mathevorlesung die Dynamik dieser Verteilungen nur durch wildes Tafelgekritzel schwierig erlebbar zu machen ist, können wir mit Programmierkenntnissen (in diesem Fall wieder mit Python) eine kleine Testumgebung für solche Verteilungen erstellen, um ein Gefühl dafür zu entwickeln, wie unterschiedlich diese auf verschiedene Wahrscheinlichkeitswerte, Varianz und Mengen an Datenpunkten reagieren und wann sie untereinander annäherungsweise ersetzbar sind – der zentrale Grenzwertsatz. Den Schwerpunkt lege ich in diesem Artikel auf die Binominal- und Normalverteilung.

Für die folgenden Beispiele werden folgende Python-Bibliotheken benötigt:

Read more

R Data Frames meistern mit dplyr – Teil 1

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

Data Frames sind das Arbeitspferd von R, wenn Daten in eine Struktur gepackt werden sollen, um sie einzulesen, zu säubern, zu transformieren, zu analysieren und zu visualisieren. Abstrakt gesprochen sind Data Frames nichts anderes als Relationen, also Mengen von Tupels, gebildet aus Elementen von geeigneten Mengen.

Dieses Konzept hat sich auch außerhalb des R-Universums bestens bewährt, umzusammengesetzte Daten, Beobachtungen oder Geschäftsobjekte zu repräsentieren. Der beste Beleg für diese Aussage sind die allgegenwärtigen Relationalen Datenbanksysteme (RDBMS). Dort werden Relationen als Tabellen (Tables) oder Sichten (Views) bezeichnet, und darauf wirkt eine mächtige, imperative Abfrage- und Manipulationssprache namens Structured Query Language, kurz:
SQL.

SQL ist in meiner Wahrnehmung die Lingua Franca der Datenverarbeitung, da sie im Kern über sehr viele Softwareprodukte gleich ist und nach erstaunlich geringem Lernaufwand mächtige Auswerte- und Manipulationsoperationen an den Daten ermöglicht. Hier eine SQL-Anweisung, um eine fiktive Tabelle aller Verkäufe (SALES) nach den Top-10-Kunden in diesem Jahr zu untersuchen:

Dieser selbsterklärliche Code aus sieben Zeilen hat einen enormen Effekt: Er fast alle Verkäufe des Jahres 2016 auf Basis der Kundennummer zusammen, berechnet dabei die Summe aller Verkaufsbeträge, zählt die Anzahl der Transaktionen und der verschiedenen vom Kunden gekauften Produkte. Nach Sortierung gemäß absteigenden Umsatzes schneidet der Code nach dem 10. Kunden ab.

SQL kann aber mit der gleichen Eleganz noch viel mehr: Beispielsweise verbinden Joins die Daten mehrerer Tabellen über Fremschlüsselbeziehungen oder analytische Funktionen bestimmen Rankings und laufende Summen. Wäre es nicht toll, wenn R ähnlich effektiv mit Data Frames analoger Struktur umgehen könnte? Natürlich! Aber schon der Versuch, obige SQL-Query auf einem R Data Frame mit den althergebrachten Bordmitteln umzusetzen (subset, aggregate, merge, …), führt zu einem unleserlichen, uneleganten Stück Code.

Genau in diese Bresche springt der von vielen anderen Bibliotheken bekannte Entwickler Hadley Wickham mit seiner Bibliothek dplyr: Sie standardisiert Operationen auf Data Frames analog zu SQL-Operationen und führt zu einer wirklich selbsterklärlichen Syntax, die noch dazu sehr performant abgearbeitet wird. Ganz analog zu ggplot2, das sich an der Grammar of Graphics orientiert, spricht Wickham bei dplyr von einer Grammar of Data Manipulation. Die Funktionen zur Manipulation nennt er folgerichtig Verben.

Dabei treten naturgemäß eine Reihe von Analogien zwischen den Teilen eines SELECT-Statements und dplyr-Funktionen auf:

SELECT-Operation dplyr-Funktion
Bildung der Spaltenliste select()
Bildung eines Ausdrucks mutate()
WHERE-Klausel filter()
GROUP BY Spaltenliste group_by()
Bildung von Aggregaten wie sum() etc. summarise()
HAVING-Klausel filter()
ORDER BY Spaltenliste arrange()
LIMIT-Klausel slice()

Die ersten Schritte

Ich möchte die Anwendung von dplyr mithilfe des Standard-Datensatzes Cars93
aus dem Paket MASS demonstrieren:

Die erste Aufgabe soll darin bestehen, aus dem Data Frame alle Autos zu selektieren, die vom Hersteller “Audi” stammen und nur Model und Anzahl Passagiere auszugeben. Hier die Lösung in Standard-R und mit dplyr:

Man sieht, dass die neue Funktion filter() der Zeilenselektion, also der Funktion subset() entspricht. Und die Auswahl der Ergebnisspalten, die in Standard-R durch Angabe einer Spaltenliste zwischen [ und ] erfolgt, hat in dplyr das Pendant in der Funktion select().

select() ist sehr mächtig in seinen Möglichkeiten, die Spaltenliste anzugeben. Beispielsweise funktioniert dies über Positionslisten, Namensmuster und ggf. das auch noch negiert:

Die obige Abfrage projiziert aus dem Data Frame sämtliche Spalten, die nicht mit “L” beginnen. Das scheint zunächst ein unscheinbares Feature zu sein, zahlt sich aber aus, wenn analytische Data Frames Dutzende oder Hunderte von Spalten haben, deren Bezeichnung sich nach einem logischen Namensschema richtet.
Soweit ist das noch nicht spektakulär. dplyr hilft uns in obigem Beispiel, als erstes bestimmte Datensätze zu selektieren und als zweites die interessierenden Spalten zu projizieren. dplyr ist aber bezüglich der Verarbeitung von Data Frames sehr intuitiv und funktional, sodass wir früher oder später viele Operationen auf unserem Data Frame verketten werden. So erreichen wir die Mächtigkeit von SQL und mehr. Die funktionale Syntax aus dem letzten Beispiel wird dann ganz schnell unleserlich, da die Verabeitungsreihenfolge (zuerst filter(), dann select()) nur durch Lesen des Codes von innen nach außen und von rechts nach links ersichtlich wird.

Daher geht dplyr einen Schritt weiter, indem es den eleganten Verkettungsoperator %>% aus dem magrittr-Paket importiert und zur Verfügung stellt. Dadurch werden die verschachtelten Ausdrücke in Sequenzen von Operationen gewandelt und somit sehr viel lesbarer und wartbarer:

Diese in meinen Augen geniale Syntax durch den neuen Operator %>% erlaubt einen sequenziellen Aufbau der Operationen auf einem Data Frame. Benutzer der Unix-Kommandozeile werden hier leicht die Analogie zu Pipes erkennen. Ganz abstrakt kann man sagen, dass damit folgende Operationen äquivalent sind:

Traditioneller Funktionsaufruf Verkettung mit %>%
f(a,b) a %>% f(b)
f(a,b,c) a %>% f(b,c)
g(f(a,b),c) a %>% f(b) %>% g(c)

Weiteres erklärt die Dokumentation zum %>%-Operator im Paket magrittr mithilfe
des Befehls ?magrittr::‘%>%‘.

Neue Variablen

Durch die Funtionen select() und filter() können wir aus Data Frames Spalten projizieren und Zeilen selektieren. Ergebnisse neuer Ausdrücke entstehen hingegen mit dem Verb mutate():

Im obigen Beispiel wird zunächst auf den Hersteller Audi selektiert und danach auf einen Streich zwei neue Spalten eingeführt, l_100km und eur. Durch Zuweisen auf eine neue Variable wird das fertige Ergebnis dauerhaft gespeichert. Hierbei handelt es sich wieder um ein natives Data Frame-Objekt. Die Operation transmute() arbeitet analog zu mutate(), verwirft aber nach Bildung der Ausdrücke alle nicht genannten Spalten. Somit können wir obiges Beispiel auch wie folgt schreiben:

Aggregate

Neben der Selektion von Zeilen und Spalten sowie der Bildung abgeleiteter Ausdrücke ist bei Datenbanktabellen die Gruppierung und Aggregation mit GROUP BY eine sehr wichtige Operation. Dies gilt auch für Data Frames in R, wenngleich hier der Funktionsumfang über diverse Funktionen wie table() oder aggregate() verteilt ist und wenig intuitiv ist.

Hier bringt dplyr ebenfalls eine großartige Verbesserung mit. Das entsprechende Verb heißt group_by(). Diese Operation wird zusammen mit einer Spaltenliste auf ein Data Frame angewendet:

Das Ergebnis von group_by() ist ein Objekt, das “mehr” ist als ein Data Frame, sondern auch noch einige spezifische Strukturinformationen von dplyr enthält. In unserem Beispiel sind dies Indizes von Zeilen, die zum gleichen Hersteller gehören. Das ursprüngliche Data Frame wird hierbei nicht kopiert, sondern nur eingebettet.

Nach Anwenden einer group_by()-Operation ist das Data Frame optimal vorbereitet für die eigentliche Aggregation mit summarise():

Das Resultat von summarise() ist wieder ein Data Frame, das neben den ursprünglichen Gruppierungskriterien nur noch die Aggregate enthält.

Daten in Reih’ und Glied

Zwischen Relationalen Datenbanken und R-Data Frames besteht ein wesentlicher konzeptioneller Unterschied: Die Ergebnisse eines SELECT-Befehls haben keine definierte Reihenfolge, so lange die Zeilen nicht mit der Klausel ORDER BY festgelegt wird. Im Gegensatz dazu haben die Zeilen von Data Frames eine konstante Reihenfolge, die sich aus der Anordnung derWerte in den Spaltenvektoren ergibt.

Dennoch ist es manchmal wünschenswert, Data Frames umzusortieren, um eine fachliche Reihenfolge abzubilden. Hierzu dient in dplyr das Verb arrange(), das im Standard-R weitgehend der Indizierung eines Data Frames mit Ergebnissen der order()-Funktion entspricht, aber syntaktisch eleganter ist:

Dieses Beispiel hat zum Ziel, die fünf PS-stärksten Autos zu selektieren. Die arrange()-Funktion sortiert hier zunächst absteigend nach der PS-Stärke, dann aufsteigend nach Herstellername. Die Selektion der 5 ersten Zeilen erfolgt mit der hilfreichen Funktion slice(), die aus einem Data Frame Zeilen anhand ihrer Reihenfolge selektiert.

Fazit und Ausblick

Mit dplyr wird die Arbeit mit Data Frames stark verbessert: Im Vergleich zu “nacktem” R bringt das Paket eine klarere Syntax, abgerundete Funktionalität und bessere Performance. In der Kürze dieses Artikels konnte ich dies nur oberflächlich anreissen. Daher verweise ich auf die vielen Hilfe-Seiten, Vignetten und Internet-Videos zum Paket. Im zweiten Teil dieses Artikels werde ich auf einige fortgeschrittene Features von dplyr eingehen, z.B. die Verknüpfung von Data Frames mit Joins, die Window-Funktionen und die Verwendung von Datenbanken als Backend.

Weiter zu R Data Frames meistern mit dplyr – Teil 2.

ABC-XYZ-Analyse

Die ABC-XYZ-Analyse ist eine aussagekräftige Analyse für die Strategiefindung in der Warenwirtschaft und Logistik bzw. im Supply Chain Management. Die Analyse basiert auf der Vorstellung einer Pareto-Verteilung, die darauf hindeutet, dass oftmals eine kleine Menge eines großen Ganzen einen unverhältnismäßig großen Einfluss auf eben dieses große Ganze hat.

Die ABC-XYZ-Analyse beinhaltet im ersten Schritt eine ABC- und im zweiten Schritt eine XYZ-Analyse. Im dritten Schritt werden die Ergebnisse in einer Matrix zusammengeführt. In diesem Artikel erläutere ich nicht, wofür eine ABC-XYZ-Analyse dient und wie die Ergebnisse zu interpretieren sind, hier kann ich jedoch auf einen älteren Artikel “ABC-XYZ-Analyse” – www.der-wirtschaftsingenieur.de vom 3. Mai 2011 von mir verweisen, der vorher lesenswert ist, wenn kein Vorwissen zur ABC-XYZ-Analyse vorhanden ist.

Die Vorarbeit

Für die ABC- und XYZ-Analyse benötigen wir folgende Python-Bibliotheken:

Wir laden die EKPO-Tabelle in ein DataFrame (Datenstruktur der Pandas-Bibliothek):

Die Datei stammt aus einem SAP-Testsystem und steht hier zum Download bereit:

csv-icon

SAP.EKPO

Wir benötigen daraus nur folgende Zeilen:

Jetzt kommt der erste Kniff: Das Feld “MENGE” im SAP beschreibt die Menge in der jeweiligen Mengeneinheit (z. B. Stück, Meter oder Liter). Da wir hier jedoch nicht den genauen Verbrauch vorliegen haben, sondern nur die Einkaufsmenge (indirekt gemessener Verbrauch), sollten wir die Menge pro Preiseinheit “PEINH” berücksichtigen, denn nach dieser Preiseinheitsmenge erfolgt der Einkauf.

Für die Preiseinheitsmenge ein Beispiel:
Sie kaufen sicherlich pro Einkauf keine 3 Rollen Toilettenpapier, sondern eine oder mehrere Packungen Toilettenpapier. Wenn Sie zwei Packung Toilettenpapier für jeweils 2 Euro kaufen, die jeweils 10 Rollen beinhalten, ist die Preiseinheit = 10 und die Preiseinheitsmenge => 20 gekaufte Toilettenrollen / 10 Rollen pro Packung = 2 Packungen Toilettenpapier.

Nun haben wir also unsere für den Einkauf relevante Mengeneinheit. Jetzt sortieren wir diese Materialeinkäufe primär nach dem Umsatzvolumen “NETWR” absteigend (und sekundär nach der Preiseinheitsmenge aufsteigend, allerdings spielt das keine große Rolle):

Einige Störfaktoren müssen noch bereinigt werden. Erstens sollen Einträge mit Preisen oder Umsätzen in Höhe von 0,00 Euro nicht mehr auftauchen:

Zweitens gibt es Einkäufe, die ein Material ohne Materialnummer und/oder ohne Materialklasse haben. Bei einer Zusammenfassung (Aggregation) über die Materialnummer oder die Materialklasse würden sich diese “leeren” Einträge als NULL-Eintrag bündeln. Das wollen wir vermeiden, indem wir alle NULL-Einträge mit jeweils unterschiedlichen Zufallszahlen auffüllen.

ABC – Analyse:

Nun geht es an die eigentliche ABC-Analyse, dafür müssen wir die Gruppierung der Materialien vornehmen. Gleich vorweg: Dies sollte man eigentlich über die einzelnen Materialnummern machen, da dies jedoch in der Visualisierung (auf Grund der hohen Anzahl und Vielfältigkeit) etwas aufwändiger ist, machen wir es über die Materialklassen. Wir gehen dabei einfach davon aus, dass die Materialklassen relativ homogene Materialien zusammenfassen und somit auch das Verbrauchs-/Einkaufverhalten innerhalb einer Gruppe nicht sonderlich viel Abweichung aufweist.


Nun können wir uns ganz im Sinne der ABC-Analyse die typische Pareto-Verteilung der kumulierten Umsätze (Umsatzgrößen absteigend sortiert) ansehen:

abc_analyse_sap_netwr_menge_kumulierte_kurve_pareto

Die X-Achse zeigt die Materialklassen von links nach rechts in der Sortierung nach dem Umsatzvolumen (größester Umsatz links, kleinster Umsatz rechts). Die Y-Achse zeigt den Betrag der Umsatzhöhe (Euro) bzw. der Menge (Preiseinheitsmenge). Die Kurve der Menge ist mit Vorsicht zu bewerten, da primär nach dem Umsatz und nicht nach der Menge sortiert wurde.

Klassifikation:

Nun kommen wir zur Klassifikation. Hier machen wir es uns sehr einfach: Wir gehen einfach davon aus, dass 80% des Wertbeitrages aller Umsätze von etwa 20% der Materialien (hier: Materialklassen) umfassen und klassifizieren daher über feste relative Größen:

Hinweis:
Intelligenter wird so eine Klassifikation, wenn wir den steilsten Anstieg innerhalb der kumulierten Volumen (die zuvor gezeigte Kurve) ermitteln und danach die Grenzen für die A-, B-, C-Klassen festlegen.

Optional: Farben für die Klassen festlegen (für die nachfolgende Visualisierung)

Jetzt Aggregieren wir über die ABC-Gruppe:

Das Ergebnis:

Schauen wir uns nun die Verteilung der Werte und Mengen zwischen den Klassen A, B und C an:

 

abc_analyse_gruppen_vergleich

Es ist recht gut erkennbar, dass die Gruppe A deutlich mehr Umsatzvolumen (also Wertbeitrag) als die Gruppen B und C hat. Allerdings hat sie auch eine höhere Bestellmenge, wie jedoch nicht proportional von C über B zu A ansteigt wie das Umsatzvolumen.

Nachfolgend sehen wir die Klassifikation nochmal nicht kumuliert über die Umsatzvolumen der Materialien (Materialklassen):

abc_analyse_sap_netwr

XYZ – Analyse

Für die XYZ-Analyse berechnen wir den arithmetischen Mittelwert, die Standardabweichung und die Summe aller Mengen pro Materialklasse [‘MATKL’] (oder alternativ, der einzelnen Materialnummern [‘MATNR’]) über eine Aggregation: 

Die XYZ-Analyse soll aufzeigen, welche Materialien (hier: Materialklassen) in stabilen Mengen verbraucht (hier: eingekauft) werden und welche größere Schwankungen hinsichtlich der Verbrauchsmenge (hier: Einkaufsmenge) aufweisen. Dazu berechnen wir den Variationskoeffizienten:

Variationskoeffizient = \frac{Standardabweichung}{Mittelwert}

Wir berechnen diesen Variationskoeffizienten und sortieren das DataFrame nach diesem aufsteigend:

Klassifikation:

Nun klassifizieren wir die Materialien (Materialklassen) über den Variationskoeffizienten in XYZ-Klassen. Dabei gehen wir davon aus, dass Materialien/Materialklassen, die einen Variationskoeffizienten von bis zu 70% des Maximalwertes aufweisen, in die Y-Klasse fallen. Solche, die nur maximal 20% des Maximalwertes aufweisen, fallen in die X-Klasse:

Auch hier gilt analog zur ABC-Analyse: Intelligente Klassifikation erfolgt über die Analyse der Kurve der kumulierten Variationskoeffizienten. Die Grenzen der Klassen sollten idealerweise zwischen den steilsten Anstiegen (bzw. die größten Wertedifferenzen) zwischen den Werten der kumulierten Variationskoeffizienten-Liste gezogen werden.

Optional: Farben fürs Plotten setzen.

Jetzt schauen wir uns mal die Verteilung der Materialien hinsichtlich des Variationskoeffizienten an:

xyz_analyse_sap_matkl_menge

Die meisten Materialklassen haben einen recht niedrigen Variationskoeffizienten, sind im Einkauf (und daher vermutlich auch im Verbrauch) recht stabil. Die Materialklasse 0004 hingegen ist einigen Mengenschwankungen unterworfen. In der ABC-Analyse ist diese Materialklasse 0004 als B-Gruppe klassifiziert.

ABC-XYZ-Analyse

Nun möchten wir also die zuvor erstellte ABC-Klassifikation mit der XYZ-Klassifikation zusammen bringen.

Dafür fügen wir die beiden Pandas.DataFrame über den Index (hier die Materialklasse ‘MATKL’, im anderen Fall das Material ‘MATNR’) zusammen:

Die Zusammenfassung als Kreuztabelle:

Für die Interpretation dieser Ergebnisse verweise ich erneut auf den Artikel bei der-wirtschaftsingenieur.de.

Warenkorbanalyse in R

Was ist die Warenkorbanalyse?

Die Warenkorbanalyse ist eine Sammlung von Methoden, die die beim Einkauf gemeinsam gekauften Produkte oder Produktkategorien aus einem Handelssortiment untersucht. Ziel der explorativen Warenkorbanalyse ist es, Strukturen in den Daten zu finden, so genannte Regeln, die beschreiben, welche Produkte oder Produktkategorien gemeinsam oder eben nicht gemeinsam gekauft werden.

Beispiel: Wenn ein Kunde Windeln und Bier kauft, kauft er auch Chips.

Werden solche Regeln gefunden, kann das Ergebnis beispielsweise für Verbundplatzierungen im Verkaufsraum oder in der Werbung verwendet werden.

Datenaufbau

Die Daten, die für diese Analyse untersucht werden, sind Transaktionsdaten des Einzelhandels. Meist sind diese sehr umfangreich und formal folgendermaßen aufgebaut:

data-bsp

Ausschnitt eines Beispieldatensatzes: Jede Transaktion (= Warenkorb = Einkauf) hat mehrere Zeilen, die mit der selben Transaktionsnummer (Spalte Transaction) gekennzeichnet sind. In den einzelnen Zeilen der Transaktion stehen dann alle Produkte, die sich in dem Warenkorb befanden. In dem Beispiel sind zudem noch zwei Ebenen von Produktkategorien als zusätzliche Informationen enthalten.

Es gibt mindestens 2 Spalten: Spalte 1 enthält die Transaktionsnummer (oder die Nummer des Kassenbons, im Beispielbild Spalte Transaction), Spalte 2 enthält den Produktnamen. Zusätzlich kann es weitere Spalten mit Infos wie Produktkategorie, eventuell in verschiedenen Ebenen, Preis usw. geben. Sind Kundeninformationen vorhanden, z.B. über Kundenkarten, so können auch diese Informationen enthalten sein und mit ausgewertet werden.

Beschreibende Datenanalyse

Die Daten werden zunächst deskriptiv, also beschreibend, analysiert. Dazu werden z.B. die Anzahl der Transaktionen und die Anzahl der Produkte im Datensatz berechnet. Zudem wird die Länge der Transaktionen, also die Anzahl der Produkte in den einzelnen Transaktionen untersucht. Dies wird mit deskriptiven Maßzahlen wie Minimum, Maximum, Median und Mittelwert in Zahlen berichtet sowie als Histogramm grafisch dargestellt, siehe folgende Abbildung.

hist-sizes
Histogramm der Längenverteilung der Transaktionen.

Die häufigsten Produkte werden ermittelt und können gesondert betrachtet werden. Als Visualisierung kann hier ein Balkendiagramm mit den relativen Häufigkeiten der häufigsten Produkte verwendet werden, wie im folgenden Beispiel.

relfreq-items
Relative Häufigkeiten der häufigsten Produkte, hier nach relativer Häufigkeit größer 0,1 gefiltert.

Ähnliche Analysen können bei Bedarf auch auf Kategorien-Ebene oder nach weiteren erhobenen Merkmalen selektiert durchgeführt werden, je nachdem, welche Informationen in den Daten stecken und welche Fragestellungen für den Anwender interessant sind.

Verbundanalyse

Im nächsten Schritt wird mit statistischen Methoden nach Strukturen in den Daten gesucht, auch Verbundanalyse genannt. Als Grundlage werden Ähnlichkeitsmatrizen erstellt, die für jedes Produktpaar die Häufigkeit des gemeinsamen Vorkommens in Transaktionen bestimmen. Solch eine Ähnlichkeitsmatrix ist zum Beispiel eine Kreuztabelle in der es für jedes Produkt eine Spalte und eine Zeile gobt. In den Zellen in der Tabelle steht jeweils die Häufigkeit, wie oft dieses Produktpaar gemeinsam in Transaktionen in den Daten vorkommt, siehe auch folgendes Beispiel.

screenshot-crosstable-ausschnitt

Ähnlichkeitsmatrix oder Kreuztabelle der Produkte: Frankfurter und Zitrusfrüchte werden in 64 Transaktionen zusammen gekauft, Frankfurter und Berries in 22 usw.

Auf Basis solch einer Ähnlichkeitsmatrix wird dann z.B. mit Mehrdimensionaler Skalierung oder hierarchischen Clusteranalysen nach Strukturen in den Daten gesucht und Gemeinsamkeiten und Gruppierungen gefunden. Die hierarchische Clusteranalyse liefert dann ein Dendrogram, siehe folgende Abbildung, in der ähnliche Produkte miteinander gruppiert werden.

dendrogram

Dendrogram als Visualisierung des Ergebnisses der hierarchischen Clusterananlyse. Ähnliche Produkte (also Produkte, die zusammen gekauft werden) werden zusammen in Gruppen geclustert. Je länger die vertikale Verbindungslinie ist, die zwei Gruppen oder Produkte zusammen fasst, um so unterschiedlicher sind diese Produkte bzw. Gruppen.

Assoziationsregeln

Schließlich sollen neben den Verbundanalysen am Ende in den Daten Assoziationsregeln gefunden werden. Es werden also Regeln gesucht und an den Daten geprüft, die das Kaufverhalten der Kunden beschreiben. Solch eine Regel ist zum Beispiel „Wenn ein Kunde Windeln und Bier kauft, kauft er auch Chips.“ Formal: {Windeln, Bier} → {Chips}

Für diese Regeln lassen sich statistische Maßzahlen berechnen, die die Güte und Bedeutung der Regeln beschreiben. Die wichtigsten Maßzahlen sind Support, Confidence und Lift:

Support ist das Signifikanzmaß der Regel. Es gibt an, wie oft die gefundene Regel in den Daten anzuwenden ist. Wie oft also die in der Regel enthaltenen Produkte gemeinsam in einer Transaktion vorkommen. In dem Beispiel oben: Wie oft kommen Windeln, Bier und Chips in einer Transaktion gemeinsam vor?

Confidence ist das Qualitätsmaß der Regel. Es beschreibt, wie oft die Regel richtig ist. In dem oben genanten Beispiel: Wie oft ist in einer Transaktion Chips enthalten, wenn auch Windeln und Bier enthalten sind?

Lift ist das Maß der Bedeutung der Regel. Es sagt aus wie oft die Confidence den Erwartungswert übersteigt. Wie ist die Häufigkeit des gemeinsamen Vorkommens von Windeln, Bier und Chips im Verhältlnis zur erwarteten Häufigkeit des Vorkommens, wenn die Ereignisse stochastisch unabhängig sind?

Algorithmen

In den Daten werden zunächst alle möglichen Regeln gesammelt, die einen Mindestwert an Support und Confidence haben. Die Mindestwerte werden dabei vom Nutzer vorgegeben. Da es sich bei Transaktionsdaten um große Datenmengen handelt und häufig große Anzahlen von Produkten enthalten sind, wird die Suche nach Regeln zu einem komplexen Problem. Es wurden verschiedene effiziente Algorithmen als Suchstrategien entwickelt, z.B. der APRIORI-Algorithmus von Agrawal und Srikant (1994), der auch im weiter unten vorgestellten Paket arules von R verwendet wird.

Sind die Assoziationsregeln gefunden, können Sie vom Nutzer genauer untersucht werden und z.B. nach den oben genannten Kennzahlen sortiert betrachtet werden, oder es werden die Regeln für spezielle Warenkategorien genauer betrachtet, siehe folgendes Beispiel.

screenshot-rules

Beispielausgabe von Regeln, hier die drei Regeln mit dem besten Lift. In der ersten Regel sieht man: Wenn Bier und Wein gekauft wird, wird auch Likör gekauft. Diese Regel hat einen Support von 0,002. Diese drei Produkte kommen also in 0,2 % der Transaktionen vor. Die Confidence von 0,396 zeigt, dass in 39,6 % der Transaktionen auch Likör gekauft wird, wenn Bier und Wein gekauft wird.

Umsetzung mit R

Die hier vorgestellten Methoden zur Warenkorbanalyse lassen sich mit dem Paket arules der Software R gut umsetzen. Im Folgenden gebe ich eine Liste von nützlichen Befehlen für diese Analysen mit dieser Software. Dabei wird mit data hier durchgehend der Datensatz der Transaktionsdaten bezeichnet.

Zusammenfassung des Datensatzes:

  • Anzahl der Transaktionen und Anzahl der Warengruppen
  • die häufigsten Produkte werden genannt mit Angabe der Häufigkeiten
  • Längenverteilung der Transaktionen (Anzahl der Produkte pro Transaktion): Häufigkeiten, deskriptive Maße wie Quartile
  • Beispiel für die Datenstruktur (Levels)

Längen der Transaktionen (Anzahl der Produkte pro Transaktion)

Histogramm als grafische Darstellung der Transaktionslängen

rel. Häufigkeiten der einzelnen Produkte, hier nur die mit mindestens 10 % Vorkommen

Äquivalenzmatrix: Häufigkeiten der gemeinsamen Käufe für Produktpaare

Unähnlichkeitsmatrix für die hierarchische Clusteranalyse

Hierarchische Clusteranalyse

Dendrogram der hierarchischen Clusteranalyse

Assoziationsregeln finden mit APRIORI-Algorithmus, hier Regeln mit mindestens 1% Support und 20 % Confidence

Zusammenfassung der oben gefundenen Regeln (Anzahl, Eigenschaften Support, Confidence, Lift)

Einzelne Regeln betrachten, hier die laut Lift besten 5 Regeln

Referenzen:

  • Michael Hahsler, Kurt Hornik, Thomas Reutterer: Warenkorbanalyse mit Hilfe der Statistik-Software R, Innovationen in Marketing, S.144-163, 2006.
  • Michael Hahsler, Bettina Grün, Kurt Hornik, Christian Buchta, Introduciton to arules – A computational environment for mining association rules and frequent item sets. (Link zum PDF)
  • Rakesh Agrawal, Ramakrishnan Srikant, Fast algorithms for mining association rules, Proceedings of the 20th VLDB Conference Santiago, Chile, 1994
  • Software R:  R Core Team (2016). R: A language and environment for statistical computing. R Foundation for Statistical Computing, Vienna, Austria. Link: R-Project.org.
  • Paket: arules: Mining Association Rules using R.

Beispieldatensatz: Groceries aus dem Paket arules

Benford-Analyse

Das Benfordsche Gesetz beschreibt eine Verteilung der Ziffernstrukturen von Zahlen in empirischen Datensätzen. Dieses Gesetz, welches kein striktes Naturgesetz ist, sondern eher ein Erklärungsversuch in der Natur und in der Gesellschaft vorkommende Zahlenmuster vorherzusagen.

Das Benfordsche Gesetz beruht auf der Tatsache, dass die Ziffern in einem Zahlensystem hierarchisch aufeinander aufbauen: Es beginnt mit der 1, dann folgt die 2, dann die 3 usw. In Kombination mit bestimmten Gesetzen der Natur (der natürliche Wachstumsprozess, dabei möglichst energiesparend wachsen/überleben) oder Ökonomie (so günstig wie möglich einkaufen) ist gemäß des Benfordschen Gesetz zu erwarten, dass die Ziffer 1 häufiger vorkommt als die 2, die wiederum häufiger vorkommt als die 3. Die Ziffer 9 braucht demnach den längsten Weg und kommt entsprechend verhältnismäßig seltener vor.

Dieses Phönomen hilft uns bei echten Zufallszahlen nicht weiter, denn dann sind alle Ziffern nicht aufeinander aufbauend, sondern mehr oder weniger gleichberechtigt in ihrem Auftrauen. Bei der klassischen und axiomatischen Wahrscheinlichkeit kommen wir damit also nicht ans Ziel.

Die Benford-Analyse ist im Grunde eine Ausreißeranalyse: Wir vergleichen Ziffernmuster in Datenbeständen mit der Erwartungshaltung des Benfordschen Gesetzes. Weicht das Muster von dieser Erwartung ab, haben wir Diskussionsbedarf.

Moderne Zahlensysteme sind Stellenwert-Zahlensysteme. Neben den Dual-, Oktal- und Hexadezimalzahlensystemen, mit denen sich eigentlich nur Informatiker befassen, wird unser Alltag vom Dezimalzahlensystem geprägt. In diesem Zahlensystem hat jede Stelle die Basis 10 (“dezi”) und einen Exponenten entsprechend des Stellenwertes, multipliziert mit der Ziffer d. Es ist eine Exponentialfunktion, die den Wert der Ziffern in bestimmter Reihenfolge ermittelt:

Z =\sum_{i=-n}^{m}d_{i}\cdot10^{i}

Die Benford-Analyse wird meistens nur für die erste Ziffer (also höchster Stellenwert!) durchgeführt. Dies werden wir gleich einmal beispielhaft umsetzen.

Die Wahrscheinlichkeit des Auftretens der ersten “anführenden” Ziffer d ist ein Logarithmus zur Basis B. Da wir im alltäglichen Leben – wie gesagt – nur im Dezimalzahlensystem arbeiten, ist für uns B = 10.

p(d)=\log_{B}\left( 1 +\frac{1}{d} \right)

Im Standard-Python lässt sich diese Formel leicht mit einer Schleife umsetzen:

Benford-Algorithmus in Python mit NumPy und Pandas

Nachfolgend setzen wir eine Benford-Analyse als Minimalbeispiel in NumPy und Pandas um.

Nun möchten wir eine Tabelle erstellen, mit zwei Spalten, eine für die Ziffer (Digit), die andere für die relative Häufigkeit der Ziffer (Benford Law). Dazu nutzen wir das DataFrame aus dem Pandas-Paket. Das DataFrame erstellen wir aus den zwei zuvor erstellten NumPy-Arrays.

Man könnte sicherlich auch den natürlichen Index des DataFrames nutzen, indem wir diesen nur um jeweils 1 erhöhen, aber das verwirrt später nur und tun wir uns jetzt daher lieber nicht an…

Das Dataframe-Objekt kann direkt plotten (das läuft über die matplotlib, die wir aber nicht direkt einbinden müssen):benfordsches_gesetz_dezimalzahlen_ziffern

Diese neun Balken zeigen die Verteilung der Ziffernhäufigkeit nach dem Benfordschen Gesetz, diese Verteilung ist unsere Erwartungshaltung an andere nummerische Datenbestände, wenn diese einem natürlichen Wachstum unterliegen.

Analyse der Verteilung der ersten Ziffer in Zahlungsdaten

Jetzt brauchen wir Daten mit nummerischen Beträgen, die wir nach Benford testen möchten. Für dieses Beispiel nehme ich aus einem ein SAP-Testdatensatz die Spalte ‘DMBTR’ der Tabelle ‘BSEG’ (SAP FI). Die Spalte ‘DMBTR’ steht für “Betrag in Hauswährung’, die ‘BSEG’ ist die Tabelle für die buchhalterischen Belegsegmente.
Die Datei mit den Testdaten ist über diesen Link zum Download verfügbar (Klick) und enthält 40.000 Beträge.

Wir laden den Inhalt der Datei via NumPy.LoadTxt() und machen aus dem resultierenden NumPy-Array wieder ein Pandas.DataFrame und holen uns die jeweils erste Ziffer für alle Einträge als Liste zurück.

Die Einträge der ersten Ziffer in firstDigits nehmen wir uns dann vor und gruppieren diese über die Ziffer und ihrer Anzahl relativ zur Gesamtanzahl an Einträgen.

Wenn wir die Werte der relativen Anzahl aufsummieren, landen wir bei 94% statt 100%. Dies liegt daran, dass wir die Ziffer 0 ausgelassen haben, diese jedoch tatsächlich vorkommt, jedoch nur bei Beträgen kleiner 1.00. Daher lassen wir die Ziffer 0 außenvor. Wer jedoch mehr als nur die erste Ziffer prüfen möchte, wird die Ziffer 0 wieder mit in die Betrachtung nehmen wollen. Nur zur Probe nocheinmal mit der Ziffer 0, so kommen wir auf die 100% der aufsummierten relativen Häufigkeiten:

Nun erstellen wir ein weiteres Pandas.DataFrame, mit zwei Spalten: Die Ziffern (Digit) und die tatsächliche Häufigkeit in der Gesamtpopulation (Real Distribution):

Abgleich der Ziffernhäufigkeit mit der Erwartung

Nun bringen wir die theoretische Verteilung der Ziffern, also nach dem zuvor genannten Logarithmus, und die tatsächliche Verteilung der ersten Ziffern in unseren Zahlungsdaten in einem Plot zusammen:

In dem Plot wird deutlich, dass die Verteilung der führenden Ziffer in unseren Zahlungsdaten in ziemlich genau unserer Erwartung nach dem Benfordschen Gesetz entspricht. Es sind keine außerordentlichen Ausreißer erkennbar. Das wäre auch absolut nicht zu erwarten gewesen, denn der Datensatz ist mit 40.000 Einträgen umfassend genug, um dieses Muster gut abbilden zu können und von einer Manipulation dieser Beträge im SAP ist ebenfalls nicht auszugehen.

benford-analyse-python-fuer-sap-bseg-dmbtr

Gegenüberstellung: Computer-generierte Zufallszahlen

Jetzt wollen wir nochmal kurz darauf zurück kommen, dass das Benfordsche Gesetz für Zufallszahlen nicht unwendbar ist. Bei echten Zufallszahlen bin ich mir da auch sehr sicher. Echte Zufallszahlen ergeben sich beispielweise beim Lotto, wenn die Bälle mit Einzel-Ziffern durch eine Drehkugel hüpfen. Die Lottozahl-Ermittlung erfolgt durch die Zusammenstellung von jeweils gleichberechtigt erzeugten Ziffern.
Doch wie ist dies bei vom Computer generierten Zufallszahlen? Immerhin heißt es in der Informatik, dass ein Computer im Grunde keine Zufallszahlen erzeugen kann, sondern diese via Takt und Zeit erzeugt und dann durchmischt. Wir “faken” unsere Zahlungsdaten nun einfach mal via Zufallszahlen. Hierzu erstellen wir in NumPy ein Array mit 2000 Einträgen einer Zufallszahl (NumPy.Random.rand(), erzeugt floats 0.xxxxxxxx) und multiplizieren diese mit einem zufälligen Integer (Random.randint()) zwischen 0 und 1000.

Erzeugen wir die obigen Datenstrukturen erneut, zeigt sich, dass die Verteilung der Zufallszahlen ganz anders aussieht: (vier unterschiedliche Durchläufe)

benford-analyse-python-numpy-pseudo-zufallszahlen

Anwendung in der Praxis

Data Scientists machen sich das Benfordsche Gesetz zu Nutze, um Auffälligkeiten in Zahlen aufzuspüren. In der Wirtschaftsprüfung und Forensik ist diese Analyse-Methode recht beliebt, um sich einen Eindruck von nummerischen Daten zu verschaffen, insbesondere von Finanztransaktionen. Die Auffälligkeit durch Abweichung vom Benfordchen Gesetz entsteht z. B. dadurch, dass Menschen eine unbewusste Vorliebe für bestimmte Ziffern oder Zahlen haben. Greifen Menschen also in “natürliche” Daten massenhaft (z. B. durch Copy&Paste) ein, ist es wahrscheinlich, dass sie damit auch vom Muster des Benfordschen Gesetzes abweichen. Weicht das Muster in Zahlungsströmen vom Bendfordsche Erwartungsmuster für bestimmte Ziffern signifikant ab, könnte dies auf Fälle von unnatürlichen Eingriffen hindeuten.

Die Benford-Analyse wird auch gerne eingesetzt, um Datenfälschungen in wissenschaftlichen Arbeiten oder Bilanzfälschungen aufzudecken. Die Benford-Analyse ist dabei jedoch kein Beweis, sondern liefert nur die Indizien, die Detailanalysen nach sich ziehen können/müssen.

Die Rastrigin-Funktion

Jeder Data Scientist kommt hin und wieder mal in die Situation, einen Algorithmus trainieren bzw. optimieren zu wollen oder zu müssen, ohne jedoch, dass passende Trainingsdaten unmittelbar verfügbar wären. Zum einen kann man in solchen Fällen auf Beispieldaten zugreifen, die mit vielen Analysetools mitgeliefert werden, oder aber man generiert sich seine Daten via mathematischer Modelle selbst, die für bestimmte Eigenschaften bekannt sind, die gute Bedingungen für das Optimierungstraining liefern. 

Ein solches Modell, das man als Machine Learning Entwickler kennen sollte, ist die Rastrigin-Funktion, die laut Wikipedia von Leonard A. Rastrigin erstmalig beschrieben wurde. Dabei handelt es sich um eine Häufigkeites-/Wahrscheinlichkeitsverteilung, deren Dichte mehrere lokale Modi (Gipfel) aufweist. Ein Modus (oder Modalwert) ist in einer Häufigkeitsverteilung der häufigste Wert (“Bergspitze”) bzw. der Wert mit der höchsten Wahrscheinlichkeit.

Anmerkung des Autors: Dieser Artikel stellt zum einen die Rastrigin-Funktion und ihre Bedeutung für die Optimierungsrechnung vor, ist zum anderen aber auch eine Einführung in den Umgang mit NumPy-Matrizen (die eine Menge For-Schleifen ersparen können).

Die Rastrigin-Funktion

Mathematisch beschrieben wird die Rastrigin-Funktion wie folgt:

f(x_1 \cdots x_n) = An + \sum_{i=1}^n (x_i^2 -10cos(2\pi x_i))

-5.12 \leq x_i \leq 5.12

Wobei für das globale Minimum gilt: f(0) = 0
Außerdem ist zu beachten, dass A=10 eine Konstante ist.

Die Rastrigin-Funktion im Standard-Python umsetzen und visualisieren

Die Formel lässt sich in Python (wie natürlich in jeder anderen Programmiersprache auch) einfach umsetzen:

Nun können wir über den klassischen Weg der Programmierung einfach eine For-Schleife verwenden, um die Rastrigin-Funktionswerte in eine Liste zu packen und mit einem Plot zu visualsieren, dabei bin ich leider doch nicht ganz um die Verwendung des NumPy-Pakets nicht herumgekommen:

rastrigin-line-chart

Die grafische Darstellung zeigt, dass es sich tatsächlich um eine symmetrische multimodalen Verteilung handelt.

Die Rastrigin-Funktion mehrdimensional umsetzen, mit NumPy-Matrizen-Funktionen

Die obige Umsetzung der Rastrigin-Funktion ist eindimensional (eine Variable), braucht für die Darstellung allerdings zwei Dimensionen (f(x) und die Durchlaufanzahl bzw. Zeitachse). Nun könnten wir die Zahl der Variablen von 1 (x) auf 2 (x und y) erhöhen und eine dreidimensionale Darstellung erzeugen. Eine ähnliche dreidimensionale Darstellung gab es bereits in meiner Vorstellung des k-nearest-Neighbour-Algorithmus nachzuvollziehen. Dabei müssten wir die Konstante A=10 auf A=20 verdoppeln:

rastrigin-funktion-python-3d-plot

Die Rastrigin-Funktion wird gerne für Optimierungsalgorithmen eingesetzt, wofür sie wegen des großen Suchraums und der hohen Anzahl lokaler Modi ein herausforderndes Umfeld bietet. Beispielsweise wird – meines Erachtens nach – das wohl beliebteste Optimierungsverfahren im maschinellen Lernen, das Gradientenverfahren, hier keine guten Ergebnisse liefern, denn es gibt einfach zu viele lokale Minima.

 

 

Python vs R Statistics

Immer wieder wird mir von Einsteigern die Frage gestellt, ob sich der Einstieg und die Einarbeitung in die Programmiersprache Python eher lohnen würde als in R Statistics. Nun gibt es in den englischsprachigen Portalen bereits viele Diskussionen und Glaubenskriege zu diesem Vergleich – diese habe ich mir mit Absicht nicht weiter durchgelesen, sondern ich versuche hier meine Erfahrung aufs Blog zu bringen und bin auf Eure Meinungen/Erfahrungen gespannt!

Mit weniger R-Code schneller zum Ziel, und mit Python darüber hinaus

Was mir beim Einstieg in R gleich auffiel: Nach der Installation kann man sofort loslegen! Ein Plot oder eine Regressionsanalyse ist binnen weniger Code-Zeilen erledigt, denn die Sprache bringt diese Funktionen von Haus aus mit. In Python ist das Ziel auch nicht weit weg, allerdings müssen für die Plots erst die MatplotLib installiert werden, für Matrizenberechnung die Numpy-Bibliothek und um eine, mit der R-Datenstruktur Data.Frame vergleichbare Datenstruktur in Python zu erhalten, die Pandas-Bibliothek. Diese Python-Bibliotheken kann man zwar mit Fug und Recht als Bestandteil des Python-Universums ansehen, standardmäßig ausgeliefert werden sie aber nicht und auch sollten sie streng vom Standardpython in der Anwendung getrennt werden, im Klartext: Die Bibliotheken erfordern extra Einarbeitung und machen die Handhabung komplizierter, das einfache Python verliert ein Stück weit seine Einfachheit.

Auch die beliebte Entwicklungsumgebung R-Studio sucht seinesgleichen und ist IPython meiner Meinung nach hinsichtlich der Usability absolut überlegen. R ist einfach darauf ausgerichtet, Daten zu analysieren und zu visualisieren, aber beschränkt sich eben auch darauf.

“R is more about sketching, and not building,” says Michael Driscoll, CEO of Metamarkets. “You won’t find R at the core of Google’s page rank or Facebook’s friend suggestion algorithms. Engineers will prototype in R, then hand off the model to be written in Java or Python.”

Im Gegenzug ist Python eine Programmiersprache, die nicht nur an den einen Zweck gebunden ist. Mit Python können ebenfalls (Web-)Server- oder Desktop-Anwendungen und somit ohne Technologiebruch analytische Anwendungen komplett in Python entwickelt werden. Und auch wenn R ebenfalls unüberschaubar viele Packages mitbringt, bietet Python noch einiges mehr, beispielsweise zur dreidimensionalen Darstellung von Graphen.

Software-Entwickler lieben Python, Mathematiker eher R

Data Science ist ein äußerst interdisziplinäres Fachgebiet und Data Scientists können Mathematiker, Physiker, Informatiker, Ingenieure oder (wenn auch etwas seltener) Wirtschafts- oder auch Geisteswissenschaftler sein. Ein Großteil kommt aus der Mathematik oder äußerst mathematischer Fachgebiete wie der Physiker oder der Elektroingenieurwissenschaft. In diesen Studiengängen wird überwiegend mit Programmiersprachen gearbeitet, die von Mathematikern für Mathematiker entwickelt wurden, also R Statistics, MATLAB oder Octave. Beispielsweise ist meine Frau studierte Elektotechnikingenieurin und setzte alle ihre Prototypen des maschinellen Lernens in MATLAB um, sie findet sich aber auch in R gut zurecht.

Wer aus der Software-Entwicklung kommt, findet sich in Python vermutlich sehr viel schneller zurecht als in R. In meiner subjektiven Wahrnehmung stelle ich tatsächlich fest, dass diejenigen Data Scientists, die aus der Mathematik zum Data Science gekommen sind, meistens R präferieren und diejenigen, die aus der Anwendungsentwicklung kommen, eher mit Python arbeiten.

datascience

Python kollaboriert besser

Ein Data Scientist kommt selten allein, denn Data Science ist Teamarbeit. Und wo Teams ein gemeinsames Ziel erreicht sollen, werden besondere Anforderungen an die Arbeitsumgebung gestellt. Python gilt als eine syntaktisch leicht verständliche Programmiersprache, die manchmal sogar als “executable Pseudocode” bezeichnet wird (was allerdings dann doch leicht übertrieben ist…). Es ist also für alle Teammitglieder eine relativ einfach zu erlernende Sprache. Dabei muss Python nicht von allen Teammitgliedern favorisiert werden, denn eigene lokale Prototypen können in R, Octave oder was auch immer erstellt werden, lassen sich dann aber auch einfach in Python integrieren. Für richtig schnelle Anwendungen sind Python und R als Interpretersprachen sowieso zu langsam, solche Anwendungen werden am Ende in C/C++ umgesetzt werden müssen, aber selbst dann bietet Python nicht zu unterschätzende Vorteile: Der Erfolg von Python im wissenschaftlichen Rechnen beruht nämlich auch auf der unkomplizierten Integration von Quellcode der Programmiersprachen C, C++ und Fortran.

Neue Spieler auf dem Feld: Scala und Julia

Leider kann ich zu den beiden Programmiersprachen Scala und Julia (noch) nicht viel sagen. Scala scheint sich meiner Einschätzung nach als eine neue Alternative für Python zu entwickeln. Scala ist ein Produkt aus dem Java-Universum und war als eine Programmiersprache für unterschiedlichste Zwecke gedacht. Die Sprache setzt sich im Big Data Science immer weiter durch, einige Tools für Big Data Analytics (Apache Spark, Apache Flink) sind auf Scala ausgelegt und basieren selbst auf dieser Programmiersprache. Was Scala als eine stark von Java inspirierte Sprache sehr sympathisch macht, ist der enorm kompakte Code. Ein MapReduce-Algorithmus lässt sich in Scala mit einem Bruchteil an Code erstellen, als es in Java der Fall wäre, wie es auch die Code-Beispiele der Spark-Webseite eindrücklich zeigen: (Was ist eigentlich Apache Spark?)

Text Search in Python (Apache Spark)
Text Search in Scala (Apache Spark)
Text Search in Java (Apache Spark)

Julia wurde (ähnlich wie R) explizit für den Zweck der statistischen Datenanalyse entwickelt, wird auf Grund des aktuellen Beta-Status noch kaum produktiv eingesetzt. Da Julia auf sehr schnelle Anwendungen ausgerichtet ist, liegt in Julia die neue Hoffnung für jene, für die R und Python zu langsame Interpretersprachen sind.

Buchempfehlungen zum Einstieg in R oder Python

Es versteht sich von selbst, dass ich alle Bücher auch selbst besitze und mehr als nur das Vorwort gelesen habe…

Was ist Eure Erfahrung? Ihr seid gefragt!

Schreibt Eure Meinung einfach als Kommentar zu diesem Artikel! Wer meint, den Vergleich logischer, “richtiger” und nachvollziehbarer aufs digitale Papier bringen zu können, darf einen Artikelvorschlag übrigens gerne an redaktion@data-science-blog.com senden!

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.

 

Einführung in WEKA

Waikato Environment for Knowledge Analysis, kurz WEKA, ist ein quelloffenes, umfangreiches, plattformunabhängiges Data Mining Softwarepaket. WEKA ist in Java geschrieben und wurde an der WAIKATO Iniversität entwickelt. In WEKA sind viele wichtige Data Mining/Machine Learning Algorithmen implementiert und es gibt extra Pakete, wie z. B. LibSVM für Support Vector Machines, welches nicht in WEKA direkt implementiert wurde. Alle Einzelheiten zum Installieren und entsprechende Download-Links findet man unter auf der Webseite der Waikato Universität. Zusammen mit der Software wird ein Manual und ein Ordner mit Beispiel-Datensätzen ausgeliefert. WEKA arbeitet mit Datensätzen im sogenannten attribute-relation file format, abgekürzt arff. Das CSV-Format wird aber ebenfalls unterstützt. Eine Datei im arff-Format ist eine ASCI-Textdatei, welche aus einem Header- und einem Datateil besteht. Im Header muss der Name der Relation und der Attribute zusammen mit dem Typ stehen, der Datenteil beginnt mit einem @data-Schlüsselwort. Als Beispiel sei hier ein Datensatz mit zwei Attributen und nur zwei Instanzen gegeben.

WEKA unterstützt auch direktes Einlesen von Daten aus einer Datenbank (mit JDBC) oder URL. Sobald das Tool installiert und gestartet ist, landet man im Hauptmenü von WEKA – WEKA GUI Chooser 1.

Abbildung 1: WEKA GUI Chooser

Abbildung 1: WEKA GUI Chooser

Der GUI Chooser bietet den Einstieg in WEKA Interfaces Explorer, Experimenter, KnowledgeFlow und simple CLI an. Der Explorer ist ein graphisches Interface zum Bearbeiten von Datensätzen, Ausführen von Algorithmen und Visualisieren von den Resultaten. Es ist ratsam, dieses Interface als Erstes zu betrachten, wenn man in WEKA einsteigen möchte. Beispielhaft führen wir jetzt ein paar Algorithmen im Explorer durch.

Der Explorer bietet mehrere Tabs an: Preprocess, Classify, Cluster, Associate, Select attributes und Visualize. Im Preprocess Tab hat man die Möglichkeit Datensätze vorzubereiten. Hier sind zahlreiche Filter zum Präprozessieren von Datensätzen enthalten. Alle Filter sind in supervised und unsupervised unterteilt, je nachdem, ob das Klassenattribut mitbetrachtet werden soll oder nicht. Außerdem kann man entweder Attribute oder Instanzen betrachten, mit Attributen lässt man Filter spaltenweise arbeiten und bei Instanzen reihenweise. Die Auswahl der Filter ist groß, man kann den ausgewählten Datensatz diskretisieren, normalisieren, Rauschen hinzufügen etc. Unter Visualize können z. B. die geladenen Datensätze visualisert werden. Mit Select attributes kann man mithilfe von Attribut Evaluator und Search Method ein genaueres Ergebnis erzielen. Wenn man im Preprocess den Datensatz lädt, erhält man einen Überblick über den Datensatz und dessen Visualisierung. Als Beispiel wird hier der Datensatz diabetes.arff genommen, welcher mit WEKA zusammen ausgeliefert wird. Dieser Datensatz enthält 768 Instanzen mit je 9 Attributen, wobei ein Attribut das Klassenattribut ist. Die Attribute enthalten z. B. Informationen über die Anzahl der Schwangerschaften, diastolischer Blutdruck, BMI usw. Alle Attribute, außer dem Klassenattribut, sind numerisch. Es gibt zwei Klassen tested negativ und tested positiv, welche das Resultat des Testens auf diabetes mellitus darstellen. über Preprocess -> Open File lädt man den Datensatz in WEKA und sieht alle relevanten Informationen wie z. B. Anzahl und Name der Attribute. Nach dem Laden kann der Datensatz klassifiziert werden.

Abbildung 2: Diabetes.arff Datensatz geladen in WEKA

Abbildung 2: Diabetes.arff Datensatz geladen in WEKA

Hierzu einfach auf Classify klicken und unter Choose den gewünschten Algorithmus auswählen. Für diesen Datensatz wählen wir jetzt den Algorithmus kNN (k-Nearest Neighbour). Der Algorithmus klassifiziert das Testobjekt anhand der Klassenzugehörigkeit von den k Nachbarobjekten, die am nähsten zu dem Testobjekt liegen. Die Distanz zwischen den Objekten und dem Testobjekt wird mit einer Ähnlichkeitsmetrik bestimmt, meistens als euklidische oder Manhattan-Distanz. In WEKA ist der Algorithmus unter lazy iBk zu finden. Wenn man auf das Feld neben dem Algorithmusnamen in WEKA mit rechter Maustaste klickt, kann man unter show properties die Werte für den ausgewählten Algorithmus ändern, bei iBk kann man u.A. den Wert für k ändern. Für den ausgewählten Datensatz diabetes.arff stellen wir beispielsweise k = 3 ein und führen die 10-fache Kreuzvalidierung durch, indem wir unter Test Options die Cross Validation auswählen. Nach der Klassifikation werden die Ergebnisse in einer Warhheitsmatrix präsentiert. In unserem Fall sieht diese wie folgt aus:

Die Anzahl der richtig klassifizierten Instanzen beträgt 72.6563 %. Wenn man in der Result list auf den entsprechenden Algorithmus einen Rechtsklick macht, kann man z. B. noch den Fehler der Klassifizierung visualisieren. Entsprechend lassen sich im Explorer unter Cluster Clustering-Algorithmen und unter Associate Assoziationsalgorithmen auf einen ausgewählten Datensatz anwenden. Die restlichen Interfaces von WEKA bieten z. T. die gleiche Funktionalität oder erweitern die Möglichkeiten des Experimentierens, fordern aber mehr Erfahrung und Wissen von dem User. Das Experimenter Interface dient dazu, mehrere Datensätze mit mehreren Algorithmen zu analysieren. Mit diesem Interface kann man groß-skalierte Experimente durchführen. Simple CLI bietet dem User eine Kommandozeile, statt einem graphischen Interface, an.

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