Tag Archive for: R Statistics

Erwin Enzenhofer

R als Tool im Process Mining

/in , , , , , , , , , /by

Die Open Source Sprache R ermöglicht eine Vielzahl von Analysemöglichkeiten, die von einer einfachen beschreibenden Darstellung eines Prozesses bis zur umfassenden statistischen Analyse reicht. Dabei können Daten aus einem Manufacturing Execution System, kurz MES, als Basis der Prozessanalyse herangezogen werden. R ist ein Open Source Programm, welches sich für die Lösung von statischen Aufgaben im Bereich der Prozessoptimierung sehr gut eignet, erfordert jedoch auf Grund des Bedienungskonzepts als Scriptsprache, grundlegende Kenntnisse der Programmierung. Aber auch eine interaktive Bedienung lässt sich mit einer Einbindung der Statistikfunktionen in ein Dashboard erreichen. Damit können entsprechend den Anforderungen, automatisierte Analysen ohne Programmierkenntnisse realisiert werden.

Der Prozess als Spagetti Diagramm

Um einen Überblick zu erhalten, wird der Prozess in einem „process value flowchart“, ähnlich einem Spagetti‐ Diagramm dargestellt und je nach Anforderung mit Angaben zu den Key Performance Indicators ergänzt. Im konkreten Fall werden die absolute Anzahl und der relative Anteil der bearbeiteten Teile angegeben. Werden Teile wie nachfolgend dargestellt, aufgrund von festgestellten Mängel bei der Qualitätskontrolle automatisiert ausgeschleust, können darüber Kennzahlen für den Ausschuss ermittelt werden.

Der Prozess in Tabellen und Diagrammen

Im folgenden Chart sind grundlegende Angaben zu den ausgeführten Prozessschritten, sowie deren Varianten dargestellt. Die Statistikansicht bietet eine Übersicht zu den Fällen, den sogenannte „Cases“, sowie zur Dauer und Taktzeit der einzelnen Aktivitäten. Dabei handelt es sich um eine Fertigungsline mit hohem Automatisierungsgrad, bei der jeder Fertigungsschritt im MES dokumentiert wird. Die Tabelle enthält statistische Angaben zur Zykluszeit, sowie der Prozessdauer zu den einzelnen Aktivitäten. In diesem Fall waren keine Timestamps für das Ende der Aktivität vorhanden, somit konnte die Prozessdauer nicht berechnet werden.

Die Anwendung von Six Sigma Tools

R verfügt über eine umfangreiche Sammlung von Bibliotheken zur Datendarstellung, sowie der Prozessanalyse. Darin sind auch Tools aus Six Sigma enthalten, die für die weitere Analyse der Prozesse eingesetzt werden können. In den folgenden Darstellungen wird die Möglichkeit aufgezeigt, zwei Produktionszeiträume, welche über eine einfache Datumseingabe im Dashboard abgegrenzt werden, gegenüber zu stellen. Dabei handelt es sich um die Ausbringung der Fertigung in Stundenwerten, die für jeden Prozessschritt errechnet wird. Das xbar und r Chart findet im Bereich der Qualitätssicherung häufig Anwendung zur ersten Beurteilung des Prozessoutputs.

Zwei weitere Six Sigma typische Kennzahlen zur Beurteilung der Prozessfähigkeit sind der Cp und Cpk Wert und deren Ermittlung ein Bestandteil der R Bibliotheken ist. Bei der Berechnung wird von einer Normalverteilung der Daten ausgegangen, wobei das Ergebnis aus der Überprüfung dieser Annahme im Chart durch Zahlen, als auch grafisch dargestellt wird.

Von Interesse ist auch die Antwort auf die Frage, welchem Trend folgt der Prozess? Bereits aus der Darstellung der beiden Produktionszeiträume im Box‐Whiskers‐Plot könnte man anhand der Mediane auf einen Trend zu einer Verschlechterung der Ausbringung schließen, den der Interquartilsabstand nicht widerspiegelt. Eine weitere Absicherung einer Aussage über den Trend, kann über einen statistischen Vergleichs der Mittelwerte erfolgen.

Der Modellvergleich

Besteht die Anforderung einer direkten Gegenüberstellung des geplanten, mit dem vorgefundenen, sogenannten „Discovered Model“, ist aufgrund der Komplexität beim Modellvergleich, dieser in R mit hohem Programmieraufwand verbunden. Besser geeignet sind dafür spezielle Process Miningtools. Diese ermöglichen den direkten Vergleich und unterstützen bei der Analyse der Ursachen zu den dargestellten Abweichungen. Bei Produktionsprozessen handelt es sich meist um sogenannte „Milestone Events“, die bei jedem Fertigungsschritt durch das MES dokumentiert werden und eine einfache Modellierung des Target Process ermöglichen. Weiterführende Analysen der Prozessdaten in R sind durch einen direkten Zugriff über ein API realisierbar oder es wurde vollständig integriert. Damit eröffnen sich wiederum die umfangreichen Möglichkeiten bei der statistischen Prozessanalyse, sowie der Einsatz von Six Sigma Tools aus dem Qualitätsmanagement. Die Analyse kann durch eine, den Kundenanforderungen entsprechende Darstellung in einem Dashboard vereinfacht werden, ermöglicht somit eine zeitnahe, weitgehend automatisierte Prozessanalyse auf Basis der Produktionsdaten.

Resümee

Process Mining in R ermöglicht zeitnahe Ergebnisse, die bis zur automatisierten Analyse in Echtzeit reicht. Der Einsatz beschleunigt erheblich das Process Controlling und hilft den Ressourceneinsatz bei der Datenerhebung, sowie deren Analyse zu reduzieren. Es kann als stand‐alone Lösung zur Untersuchung des „Discovered Process“ oder als Erweiterung für nachfolgende statistische Analysen eingesetzt werden. Als stand‐alone Lösung eignet es sich für Prozesse mit geringer Komplexität, wie in der automatisierten Fertigung. Besteht eine hohe Diversifikation oder sollen standortübergreifende Prozessanalysen durchgeführt werden, übersteigt der Ressourcenaufwand rasch die Kosten für den Einsatz einer Enterprise Software, von denen mittlerweile einige angeboten werden.

 

Dr. Uwe Schneider

R Data Frames meistern mit dplyr – Teil 2

/in , , , , , , , , , , /by

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:

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:

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:

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:

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:

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:

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:

… 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:

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():

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:

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():

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.

 

Daniela Keller

Warenkorbanalyse in R

/in , , , , , , /by

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

Benjamin Aunkofer

Python vs R Statistics

/in , , , /by

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!