Archiv der Kategorie: Data Science

Window Functions in RapidMiner

(English version)

Window-Funktionen in RapidMiner

Richtige Datenbankserver wie PostgreSQL haben seit geraumer Zeit den SQL-99-Standard umgesetzt, der unter anderem Window Functions beschreibt.

Mit Window Functions lassen sich gruppenbezogene Statistiken und Kennzahlen berechnen, ohne die Ergebnismenge zu gruppieren. (Dies ist der Unterschied zur klassischen Aggregierung mit GROUP BY.) Es gibt eine Menge Anwendungsbeispiele: es lassen sich laufende Summen, gleitende Mittelwerte, Anteile innerhalb der Gruppe, gruppenweise Minima oder Maxima und noch viele andere Dinge berechnen. Manche Leute meinen, daß mit Window Functions eine neue Ära für SQL begonnen hat, und ich neige dazu, ihnen zuzustimmen.

RapidMiner hat bislang keine Window Functions eingebaut. Erfahrene Data Scientists, die Bedarf an dieser Funktionalität hatten, haben diese mit verschiedenen Operatoren (Loops, gruppenweise Aggregation und Join usw.) selbst nachbauen können, aber das ist alles andere als trivial.

Um die Funktionalität für einen größeren Benutzerkreis zu öffnen und gleichzeitig eine wiederverwendbare Implementierung zu schaffen, habe ich das Projekt rapidminer-windowfunctions ins Leben gerufen und eine erste funktionierende Implementierung hochgeladen.

Alle im RapidMiner-Operator „Aggregate“ eingebauten Aggregationsfunktionen lassen sich verwenden: sum, average, minimum, maximum usw. Zusätzlich sind die Funktionen row_number, rank und dense_rank verfügbar.

Im Projektordner sind der eigentliche Prozess und aktuell drei Beispielprozesse enthalten, um gleich verschiedene Anwendungsmöglichkeiten testen zu können.

Golf-Datensatz: Gruppenmittelwert der Temperatur und Rang innerhalb der Gruppe für Luftfeuchtigkeit
  • Golf: Der berühmte Golf-Dataset wird aus dem mitgelieferten Beispiel-Repository geladen. Für jede Gruppe basierend auf dem „Outlook“-Attribut wird die Durchschnittstemperatur berechnet und als Attribut hinzugefügt. Ein zweites neues Attribut enthält den Rang des Datensatzes bei Sortierung nach dem Wert der Luftfeuchtigkeit. Gleiche Werte erhalten den gleichen Rang.
  • Iris: Ein weiterer Standard-Dataset, Iris, wird geladen, und es wird pro Spezies der Durchschnittswert fürs Attribut „a3“ berechnet. Dieser Mittelwert wird dann genutzt, um Exemplare herauszufiltern, die mehr als 10 % vom Gruppenmittelwert entfernt sind.
  • Deals: Der mitgelieferte Dataset „Deals“ wird geladen. In jeder Kundengruppe aus Geschlecht und Zahlungsmethode werden die drei ältesten Kunden gesucht, die anderen werden herausgefiltert.

Das zeigt schon die Bandbreite der Möglichkeiten, die Window Functions bieten. Die Möglichkeit, sie leicht einzusetzen und Indikatoren sowie Kennzahlen wie „Transaktionszähler des Kunden im Monat“, „Anteil des Produkts an der Monatssumme“ und ähnliche erzeugen zu können, wird viele Prozesse vereinfachen, oder neue Möglichkeiten eröffnen.

Implementierung

Nach einigen Prüfungen, z. B. ob die benötigten Makros gesetzt sind, werden neue Attribute zur Gruppierung und Identifizierung von Examples angelegt. Das zusammengesetzte Gruppierungsattribut wird dabei aus den Werten der als groupFields angegebenen Attribute generiert. Das Identifizerungs-Attribut muß mit einem Groovy-Skript generiert werden, da Generate Id mit vielen Datensätzen nicht funktionieren würde. (Generate Id funktioniert nicht, wenn der Datensatz bereits ein Attribut mit der Rolle id enthält.)

Die drei Spezialfunktionen, die in Aggregate nicht enthalten sind, werden gesondert behandelt. Die Untergruppen werden nach dem ausgewählten Attribut sortiert und der Datensatzzähler bzw. die Rangfolge berechnet.

Die Standard-Aggregierungsfunktionen von RapidMiner werden einfach auf jede Subgruppe angewendet, dabei entsteht jeweils eine gruppierte Zeile. Diese wird wieder mit den Originaldaten gejoint.

Einschränkungen

Gegenüber dem SQL-Standard und der in Datenbanken implementierten Funktionalität fehlt noch einiges. Z. B. erlauben Datenbanken bei Funktionen wie SUM die Angabe eines Sortierkriteriums und berechnen dann eine kumulierte Summe für jede Zeile, statt die gleiche Summe wiederholt auszugeben.

Der Prozess ist auch recht langsam, wenn viele Gruppen existieren. Dies ergibt eine große Anzahl von Filterungen in der Schleife. Bei den speziellen Rang- und Zählerfunktionen ist das Problem besonders ausgeprägt, da in jedem Durchlauf ein Groovy-Interpreter gestartet wird, was erhebliche Zeit kostet.

Das Konzept von Window-Definitionen geht in SQL-Datenbanken über Selektion von Gruppen hinaus. Z. B. kann man in SQL auf den vorherigen oder nächsten Datensatz zugreifen (LAG bzw. LEAD), ein fixes Fenster von X Zeilen definieren, und in den Daten „nach vorne“ schauen. Diese Dinge sind gegenwärtig nicht im Prozess eingebaut.

Mögliche Erweiterungen

Es spricht nichts dagegen, einige von den in SQL zur Verfügung stehenden Funktionen wie percent_rank, ntile oder first/last_value einzubauen. Dies wird bei Bedarf sicher passieren.

Die Funktionalität, über ORDER BY das Verhalten der Aggregierungsfunktionen zu ändern (z. B. für kumulierte Summen), erscheint mit RapidMiner-Mitteln nicht einfach. Allerdings ließe sich die kumulierte Summe leicht mit einem weiteren Groovy-Skript implementieren.

Bezugsquelle

Das Projekt kann auf Github heruntergeladen oder ausgecheckt werden. Es enthält Dokumentation und Beispielprozesse. Die Lizenz ist Apache 2.0, somit sind Einsatz und Weiterentwicklung uneingeschränkt möglich. Es ist also ein klassisches Open-Source-Projekt, das von der Beteiligung und Weiterentwicklung durch die Community leben soll.

Window functions in RapidMiner

For powerful database software like PostgreSQL the SQL-99 standard has been implemented for a long time. Window functions are an important part of SQL-99.

Window functions are used for calculating groupwise statistics and measures without actually grouping the result. (This is the difference between Window functions and the well-known aggregation with GROUP BY.) There are many applications: running sums, moving averages, ratios inside a group, groupwise minimum and maximum and so on. Some people consider the introduction of Window functions the beginning of a new era for SQL. I agree with this quite strongly.

RapidMiner doesn’t offer Window functions, yet. Experienced data scientists were able to build this functionality when they had to, using loops, aggregation and join, but these processes are not easy to create and debug.

My goal is to open this functionality for a larger group of potential users and to create a reusable implementation. So I started the rapidminer-windowfunctions project and uploaded the first working version.

All functions built into RapidMiner’s Aggregate operator can be used: sum, average, minimum, maximum etc. Additional functions are row_number, rank and dense_rank.

The project ships with the actual process and a number of example processes. These demonstrate different applications of Window functions on public datasets available in RapidMiner Studio.

Golf dataset with groupwise temperature average and rank by humidity
  • Golf: The process loads the well-known Golf dataset from the Samples repository. For each group defined by the attribute “Outlook”, the average temperature gets calculated. A second attribute ranks the examples by the attribute “Humidity”. Identical values get the same rank.

  • Iris: This is another standard dataset, available from RapidMiner’s Samples repository. The process calculates the average value for the attribute “a3”. This group average is used to filter out examples which differ from the average by more than 10 %.

  • Deals: Another data set built into RapidMiner. This process considers all combinations of Gender and Payment Method as groups and ranks the customers based on their age. Only the 3 oldest customers per group are retained.

This is just a small sample of all the functionality available with Window Functions. Being able to use them easily for building indicators and measures like “transaction counter per customer and month” or “the product’s contribution percentage” will open new possibilities for modelling or reporting.

Implementation

The process checks a few preconditions, for example required parameter macros. It creates new attributes for grouping and identifying examples. The grouping attribute is built from all values given in the groupFields parameter. The identifying attribute needs to be generated in a Groovy script, as Generate Id would fail on too many real-world datasets. (It doesn’t work when the dataset already has an attribute with the role id.)

The three special functions not available in Aggregate are implemented with Groovy scripts. The process sorts the subgroups by the selected attributes and calculates the record counter or the rank.

The implementation of the standard aggregations is simpler: each subgroup is aggregated and the result is joined with the original data.

Limitations

Some functionality is missing compared to the SQL standard and to database systems. For example, in SQL databases, you can use ORDER BY in the window function to specify an ordering and calculate cumulative sums for each row instead of a groupwise sum.

The process is quite slow if many groups exist in the dataset. Having many groups results in a large number of filters in the loop. The performance is especially bad with the special ranking and counter functions because they start a Groovy interpreter in each iteration, which takes a lot of time compared to other operators.

The concept of window definition in SQL databases covers more than just the selection of groups. For example, you can access the previous and next records (LAG and LEAD), define a fixed window of N rows, and look forward in the data. These things are not available in the current version of the process.

Possible extensions

It’s entirely possible to implement more SQL standard functions like percent_rank, ntile and first/last_value. This will happen for sure when there’s a need.

It seems to be hard to change the behaviour of aggregation functions using ORDER BY (e. g. for cumulative sums) with RapidMiner means. However, special cases like the cumulative sum could be implemented with another Groovy script.

Getting the process

You can download the process or check it out on Github. The project also contains documentation and example processes. The license is Apache 2.0, so there are no restrictions on usage or further development. It is intended to become an Open Source project with the participation of and further development by the community.

Generic Joins in RapidMiner

Allgemeine Joins in RapidMiner

(English version)

Der letzte Beitrag hat sich mit der Verbesserung von geographischen Joins in RapidMiner beschäftigt. Tatsächlich kann die beschriebene Methode aber auf alle Arten von Joins angewendet werden, die nicht nur für einen kleinen Nutzerkreis interessant sind.

Der eingebaute Join-Operator in RapidMiner erlaubt nur „ist gleich“-Vergleiche. In der Praxis sind aber auch andere Operationen nützlich: z. B. reguläre Ausdrücke, oder „kleiner gleich“.

Der Beispielprozess nutzt generierte Testdaten und wendet eine Liste von regulären Ausdrücken auf sie an. Wie schon bei den geographischen Joins wird dafür ein Scripting-Operator mit einem Groovy-Skript verwendet.

Das Skript muß wie gehabt ziemlich viel Datenverwaltung betreiben, um die resultierende Tabelle aus den beiden Eingangs-Tabelle zu bauen. Bei der Erstellung des Skripts war wichtig, daß es möglichst allgemein verwendbar ist. Das ist in Groovy mit Hilfe der Closure-Syntax möglich: die Join-Funktion wird am Anfang des Skripts als eine Art Konfigurationsvariable festgelegt. Somit sind im Skript nur drei Dinge festzulegen: die beiden Join-Attribute und der Ausdruck, der auf sie anzuwenden ist.

In diesem Beispiel:

es1AttName = "Person";
es2AttName = "regexp";

def joinFunc = { e1, e2 ->
    e1.matches(e2)
}

Die beiden Attributsvariablen aus Example Set 1 und 2 werden am Anfang angegeben. Hier müssen die Attributnamen exakt (inkl. Groß- und Kleinschreibung) angegeben werden.

Die Closure joinFunc nimmt zwei Parameter (e1 und e2) entgegen, das sind die Werte aus den genannten Attributen. Die Funktion prüft in diesem Fall, ob das Person-Attribut dem regulären Ausdruck aus dem zweiten Datensatz entspricht.

Andere Join-Kriterien könnten so lauten:

e1 <= e2 // kleiner-gleich-Vergleich
e1 == e2 || e2 == null // Vergleich mit optional fehlenden Daten

usw.

Für den Vergleich mehrerer Variablen muß das Skript dann doch angepaßt werden.

Das Skript verzichtet aus Performance-Gründen auf eine Prüfung, ob gleichnamige Attribute in beiden Datensätzen existieren. Im Zweifelsfall kann die Eindeutigkeit der Namen mit einem Rename by Replacing vor dem Join-Operator sichergestellt werden.

In SQL verwende ich immer wieder komplexe Joins – jetzt wird Ähnliches auch in RapidMiner möglich sein.

Generic Joins in RapidMiner

The last blog entry presented an improvement of geographic joins in RapidMiner. However, the described method can be applied to all kinds of joins, including those usable for a much larger group of analysts.

The Join operator in RapidMiner supports only the „is equal“ comparison. In reality, other operations like regular expression matching or „less or equal“ can be useful.

The example process uses generated data and joins a list of regular expressions with them. A Groovy script in an Execute Script operator is used, just like in the geographic joins.

Much data wrangling is done in the script as usual to build the resulting table from the incoming example sets. I developed the script with the goal of reusability. The closure syntax in Groovy makes this possible: the join function is specified in a kind of configuration variable at the top of the script. So to reuse the script you just need to set three variables: both join attributes and the expression to apply on them.

This is the configuration part in the example script:

es1AttName = "Person";
es2AttName = "regexp";

def joinFunc = { e1, e2 ->
    e1.matches(e2)
}

The attribute variables from ExampleSet 1 and 2 are given in the first two rows. It is important to specify them exactly (including capitalization).

The closure called joinFunc takes two parameters (e1 and e2), the values of the selected attributes. In this case the function executes a regular expression match on them.

Other possible join criteria:

e1 <= e2 // less-or-equal comparison
e1 == e2 || e2 == null // comparison that allows missing data

and so on.

The script needs to be changed for joins on multiple variables.

For performance reasons the script doesn‘t check for duplicate attribute names in the incoming data sets. If unsure, just use a Rename by Replace operator before the join to make sure the names are unique.

I‘m using complex joins in SQL all the time – it‘s time to make similar things possible in RapidMiner!

Linuxwochen 2016 Wien: Citizen Data Science

Wie schon einige Male halte ich wieder einen Vortrag bei den Linuxwochen Wien. Dieses Jahr heißt mein Thema „Citizen Data Science“.

Der Begriff „Citizen Data Scientist“ wurde von großen Beratungsfirmen geprägt. Sie verstehen darunter Mitarbeiter in Unternehmen, die keine Data-Scientist-Ausbildung haben, aber trotzdem analytisch arbeiten.

Ich möchte mich allerdings auf mein Verständnis von „Citizen“– wir alle, nicht unbedingt in einem Unternehmenskontext – konzentrieren.

Im Vortrag geht es darum, was man sich unter Data Science vorstellen kann, welche Werkzeuge und Methoden es gibt, und wie man mit frei verfügbarer Software Daten holen, zusammenführen, verarbeiten und analysieren kann.

Einige Themen: Open Data und Web-APIs; Datenbanken; Software für Analytik.

Hier sind die Vortragsfolien.

RapidMiner-Training in Wien; Sprechstunde

Die nächsten RapidMiner-Trainings in Wien (Basics 1 + 2: Einführung in Datenvorverarbeitung und Predictive Analytics/Data Mining mit RapidMiner) halte ich ab 9. Mai 2016. Es sind jeweils 2 Tage, also insgesamt 4.

Die Anmeldung ist hier möglich. Wir sind wieder bei Data Technology zu Gast.

Seit einiger Zeit gibt es „RapidMiner-Sprechstunden”, bei denen ein Experte ein bestimmtes Thema per Webcasting vorstellt. Während der Sprechstunde kann man auch Fragen stellen; die Aufzeichnung ist dann auf Youtube verfügbar.

Ich werde am 20. April und dann am 1. Juni die Sprechstunde leiten.

Am 20. 4. ist „Geographic Processing and Visualization“ das Thema (auf Basis meiner Blogserie GIS in RapidMiner), am 1. 6. dann „Access Google Analytics using RapidMiner“.

 

Simulation mit RapidMiner

(English version)

Die Simulation von mathematisch beschreibbaren Prozessen ist für viele Anwendungen nützlich. Die „Monte-Carlo-Simulation“ ist eine elegante Methode, verschiedene Probleme zu lösen, etwa die Berechnung der Kreiszahl Pi.

RapidMiner wird zwar nicht unbedingt als Simulationswerkzeug beworben, aber auch diese Aufgabe läßt sich mit etwas Know-How leicht darin lösen. Und was liegt näher als die „Monte-Carlo-Simulation“ am Beispiel von (französischem) Roulette zu demonstrieren?

Roulette läßt sich einfach beschreiben: Die Spieler setzen auf verschiedene Bereiche eines Tisches. Diese Bereiche decken unterschiedlich große Teile des Zahlenraums zwischen 0 und 36 ab. Die Wahrscheinlichkeit, daß ein Zahlenfeld gewinnt, liegt bei 1/37; bei größeren Bereichen (z. B. vier Zahlen, sechs Zahlen, ein Drittel der Zahlen von 1-36, eine Farbe) bei Mehrfachen davon. Der Gewinn ist bei einzelnen Zahlen das 35-Fache des Einsatzes (zusätzlich zum Einsatz, den man behält), und nimmt bei größeren Bereichen proportional zum Risiko ab. Z. B. erhält man, wenn man etwa auf Rot gesetzt hat und die Kugel auf einem roten Feld landet, den Einsatz noch einmal zurück. Da auch das Feld 0 existiert, das von den meisten möglichen Einsätzen nicht abgedeckt ist, verdient die Bank auch manchmal Geld. Roulette ist wahrscheinlich das „fairste“ reine Glücksspiel, das man spielen kann. (Deswegen gibt es wohl auch „Amerikanisches Roulette“ mit einem zweiten Null-Feld – Die Kasinos in den USA haben sich mit 1/37 Gewinn nicht zufriedengegeben.)

Simulationsprozess

Der hier verfügbare Prozess simuliert wiederholte Besuche im Kasino mit einigen Einstellungen. Die Einstellungen lassen sich im Prozesskontext (View/Show Panel/Context) in Form von Makros setzen. Sie sind auch direkt im Prozess beschrieben.

Man legt die Anzahl der Besuche fest und die Anzahl der Spiele pro Besuch (solange man noch Geld übrig hat). Es läßt sich auch ein Betrag angeben, bei dessen Erreichen man freiwillig aufhört zu spielen. (Z. B. wenn man das anfängliche Guthaben verdoppelt hat.)

Die eigene Spielweise läßt sich im Makro „Risk“ einstellen. Hier legt man das gewünschte Risiko fest: von 2 (rot/schwarz, gerade/ungerade, 1-18/19-36) bis 36 (einzelne Zahl).

Der Prozess besteht aus zwei verschachtelten Schleifen (Loop Visits und Loop Bets) und danach etwas Datenaufbereitung für die Darstellung der Ergebnisse.

Die tatsächliche Berechnung einer Spielrunde findet in „Calculate bet results“ (Generate Attributes) statt. Aus dem Einsatz und dem Risiko wird der Gewinn (Einsatz + gewonnener Betrag) oder der Verlust (der Einsatz) berechnet; daraus dann das neue Spielguthaben.

Nach der Ausführung der äußeren Schleife werden Kennzahlen errechnet.

Aggregierte Ergebnisse der Simulation
Aggregierte Ergebnisse der Simulation

average(VisitWonPct): Anteil des Einsatzes, der durchschnittlich gewonnen oder verloren wurde. (Realistischerweise eher verloren, ausgedrückt durch eine negative Zahl.)

average(VisitReachedGoal): Anteil der Casino-Besuche, bei denen man das Ziel-Guthaben (z. B. 150 € bei einem Anfangsguthaben von 100 €) erreicht hat.

average(VisitLostEverything): Anteil der Casino-Besuche, bei denen man das gesamte Anfangsguthaben verloren hat.

average(VisitWonAmount): Durchschnittlich gewonnener oder verlorener Betrag.

Zusätzlich lassen sich die Verläufe der einzelnen Besuche grafisch darstellen:

Grafische Darstellung der einzelnen Spielverläufe
Grafische Darstellung der einzelnen Spielverläufe

Dafür habe ich das Ergebnis „Pivot for series plot“ geöffnet, die Charts aktiviert, den Chart-Typ Series ausgewählt, die BetNr als Index-Dimension festgelegt und alle CurrentAmount-Spalten für die Plot Series markiert.

Jede Linie zeigt den Verlauf eines Casinobesuchs (pro Besuch eine Farbe). Die X-Achse ist die Spielrunde, die Y-Achse das Guthaben, das man nach dieser Runde hat. Es ist gut sichtbar, daß es Besuche gab, in denen man über 30 Runden nur verloren hat! Oben ist das Feld durch die Besuche begrenzt, in denen man vor Ablauf der geplanten Spielrunden den Zielbetrag erreicht hat.

Mit diesem Simulationsprozess, der auch mit RapidMiner Studio Basic (gratis und ohne Registrierung nutzbar) funktioniert, läßt sich gut feststellen, wie die Chancen im Casino stehen, wenn man mit einer „Strategie“ spielt. Wenig überraschend ist das Ergebnis überwiegend negativ.

Der Prozess ließe sich leicht für andere Arten von Spielen und generell andere Zwecke adaptieren. Eine Monte-Carlo-Simulation zur Annäherung von Pi wäre z. B. mit der gleichen Struktur möglich.

Simulation in RapidMiner

There are many applications for simulation of processes that can be described mathematically. The Monte Carlo simulation is an elegant method for solving different problems like calculating Pi.

RapidMiner is not advertised as a simulation tool, but with a bit of knowledge you can easily solve this task in it. So how about demonstrating Monte Carlo simulation with the example of French roulette?

The game of roulette is easy to describe. Players bet on different areas of a table. The areas cover smaller or larger sets of the numbers between 0 and 36. The probability of winning with a single number is 1/37; when betting on a larger area (e. g. four numbers, six numbers, one third of the numbers between 1 and 36, one color) it is a multiple of that. The won amount when guessing a number correctly is the 35 times the bet amount (and the player keeps the bet), and it decreases proportionally with the risk. For example, if you bet on red and the ball lands on a red field, you win an equal amount to your bet.

There is also a field with 0 that is not covered by most of the bets, so the bank also wins sometimes. Roulette is probably one of the most „fair“ games of luck available. (That’s probably the reason for the existence of American roulette that has a second 0 field: The US casinos weren’t satisfied with winning just 1/37 of the players‘ money.)

Simulation process

The process available here simulates repeated casino visits with a few settings. You can manipulate the settings in the process context (View menu/Show Panel/Context) in the Macros area. The process contains a description of each setting.

You can specify the number of visits and the betting rounds per visit (as long as there’s money left in the current visit). It is also possible to specify an amount that is enough to leave the casino before the specified number of rounds. (E. g. when you doubled the original amount.)

You can set a „style of gambling“ with the macro „Risk“. Here you specify the risk you’d like to try: it starts at 2 (red/black, even/odd, 1-18/19-36) and ends at 36 (betting on one number).

The process contains two loops, the first one (Loop Visits) holding the second one (Loop Bets) inside. After those there is some processing for displaying results.

The calculation of one betting round happens in „Calculate bet results“ (Generate Attributes). The amount lost or won in the round is calculated from the bet amount and the risk. This results in a change of the current amount.

After finishing the outer loop, the process calculates a few summary results.

Aggregated simulation results
Aggregated simulation results

average(VisitWonPct): Portion of the original amount that was lost or won in the average case. (Realistically, lost: this is expressed with a negative percentage.)

average(VisitReachedGoal): Portion of visits when reaching the desired amount (e. g. 150 € after starting with 100 €).

average(VisitLostEverything): Portion of visits when you lost everything.

average(VisitWonAmount): Average amount won or lost.

In addition to the numbers you can display each visit graphically:

Chart of each visit's progression
Chart of each visit’s progression

Open the „Pivot for series plot“ result, go to Charts, select Series, select BetNr as the Index dimension and mark all CurrentAmount attributes as Plot Series.

Each line describes the course of a casino visit (one color per visit). The X axis is the betting round, the Y axis the available amount after the round. It is easy to see that in several visits up to 30 rounds have been lost! The upper limit is the specified „leaving amount“ that was reached before the number of specified rounds.

This simulation process even works in RapidMiner Studio Basic (available for free without registration). You can easily determine your chance of winning in the casino playing your „strategy“. It’s not a big surprise that the result is mostly negative.

It should be easy to change the process to simulate other games or events. For example, you could estimate Pi using the same process structure.

 

Predictive-Analytics-Konferenz 2015, zweiter Tag

Heute fand der zweite und damit letzte Tag der PRAN statt. Die Vorträge waren wieder sehr interessant.

Christoph Reininger von Runtastic sprach über die Methoden und Werkzeuge der Kunden-Analytik. Hier habe ich mir mehr erwartet. Im Vortrag ging es eher nur um klassische Kundensegmentierung und Customer Life Time Value, beides sind Dinge, die viele andere klassische Firmen machen. Aber wahrscheinlich wollen sie die wirklich innovativen Dinge (falls diese stattfinden) nicht an die große Glocke hängen. Es ist jedenfalls gut zu wissen, daß die von Runtastic direkt erhobenen Daten alle in Österreich in einem Rechenzentrum gespeichert sind und nicht irgendwo in der Cloud. (Leider gilt das nicht für die Google-Analytics-Daten und jene aus dem Werbenetzwerk.)

Marc Bastien von IBM demonstrierte dann IBM Watson Analytics. Das ist schon beeindruckend, wie viel Intelligenz in diesem Cloud-Werkzeug steckt. Aktuell kann es noch keinen Data Scientist ersetzen, aber wenn gerade kein solcher in der Nähe ist, könnte es helfen, in den eigenen Daten interessante Zusammenhänge zu entdecken. Hier kam schon vom Vortragenden die Empfehlung, keine personenbezogenen Daten hochzuladen – selten sind Cloud-Diensteanbieter so ehrlich, zuzugeben, daß es datenschutzrechtliche Bedenken gibt. (Generell wurde die gestrige EuGH-Entscheidung zum Safe-Harbor-Abkommen mehrmals thematisiert. Darüber wird es in nächster Zeit sicher noch einiges zu diskutieren geben.)

Allan Hanbury von der TU Wien zeigte medizinische Anwendungen von Big Data. Spannend für mich und andere im Publikum war die Erkenntnis, daß Ärzte lieber auf Google und Wikipedia nach Symptomen und Therapien suchen als in medizinischer Fachliteratur. Traurig ist auch, daß die Elektronische Gesundheitskarte ELGA zwar eine Zusammenführung der Daten erlaubt, aber Forschung mit ihnen explizit untersagt. Die Konsequenz daraus ist wohl ein opt out. Dafür gibt es im Bereich der Radiologie Fortschritte: Es wurde eine „Suchmaschine“ entwickelt, mit der Ärzte nach Auffälligkeiten in Röntgenbildern und den dazu gehörenden Diagnosen suchen können.

Lisa Neuhofer und Barbara Hachmöller von myr:conn solutions stellten ihr Projekt vor, das Erdölunternehmen hilft, die Ergiebigkeit einer Ölquelle anhand von Probebohrungen zu schätzen. Sie haben dafür einen recht erfolgreichen Modellierungsprozess entwickeln können. Die Anwendung zeigt auch wieder, wie weit das Feld ist, an dem man Analytik einsetzen kann. Bei diesem Thema war auch die Zusammenarbeit mit der Geowissenschaft (welche Gesteinsschichten welche Eigenschaften haben) sehr wichtig.

Nach der Mittagspause sprach Stefan Gindl von der Modul University über Herausforderungen und Trends der Stimmungsanalyse (sentiment analysis, ein Untergebiet von Text Mining). Es ist interessant zu sehen, daß die heutigen Ansätze bereits gut funktionieren, aber bei Themen wie der Erkennung von Sarkasmus und Ironie noch Verbesserungsbedarf besteht. Tatsächlich gibt es aber schon erste Fortschritte in der Forschung auf diesem Gebiet.

Jens Barthelmes von IBM schloß an. Sein Thema war „Social Media Analytics – Alles nur Hype?“. Er erwähnte verschiedene Kritikpunkte an den Datenquellen (die tatsächlich ziemlich chaotisch sind) und den Ergebnissen und erklärte, warum seiner Meinung nach trotzdem ein Wert in dieser Form der Analytik besteht. Das „Geheimnis“ ist, nicht nach der Phase „Monatsbericht über die Wahrnehmung des Unternehmens auf Facebook/Twitter/usw.“ aufzuhören, sondern die Ergebnisse als zusätzlichen Input für die restliche Analytik des Unternehmens anzusehen. Somit lassen sich etwa Absatzprognosemodelle etwas verbessern.

Michael Sedlmair von der Uni Wien sprach über Visualisierung im Big-Data-Zeitalter. Große Datensätze mit eventuell vielen Attributen lassen sich ja mit herkömmlichen Methoden schlecht darstellen. Für dieses Problem hat er einige mögliche Lösungen wie etwa die automatische Vorselektion „interessanter“ Attribute präsentiert. Er gab seinem Bedauern Ausdruck, daß noch kein fertiges Werkzeug existiert, mit dem diese Operationen ohne Programmierung ausgeführt werden könnten.

Wie immer beschloß Prof. Marcus Hudec die Konferenz mit einem seiner berühmten 100-Folien-Vorträge. Die Präsentation war von Anfang bis Ende fesselnd: er erklärte neue Trends wie Deep Learning und beschäftigte sich mit den Auswirkungen großer Datensätze auf die statistischen Eigenschaften von Modellen, die Konfidenzberechnung und innovative Sampling-Verfahren.

Wie immer waren es interessante anderthalb Tage bei der Konferenz. Ich nehme eine Menge Anregungen für meine Projekte in nächster Zeit mit und bin 2016 sicher wieder dabei.

Predictive-Analytics-Konferenz, erster Tag

Die Predictive-Analytics-Konferenz in Wien ist für mich jedes Jahr ein Pflichttermin. Die meisten Vorträge sind spannend und man trifft viele interessante Leute. In Wien ist es ja sonst nicht so einfach, Gesprächpartner mit Data-Mining-Erfahrung zu finden.

Die Keynote war ein sehr interessanter Vortrag von Stefan Stoll (Duale Hochschule Baden-Württemberg), der über disruptive Entwicklungen durch den Einsatz von Software und Analytik gesprochen hat. Er hat dabei wirtschaftliche Zusammenhänge beleuchtet, die mir so bisher unbekannt waren.

Danach stellte Prof. Erich Neuwirth (bei dem ich meine ersten Statistik-Vorlesungen hatte) seine Methode der Wahlhochrechnungen vor. Er gab auch historische Einblicke in die Anfangszeit in den 1970ern und erklärte den Kontrast mit heute: einerseits waren die Modelle damals einfacher, weil nur zwei Großparteien und eine kleine existierten, andererseits geschieht die Berechnung selbst heute in Sekunden auf einem PC, während damals Großrechner eingesetzt werden mußten.

Michael Wurst von IBM stellte die In-Database-Mining-Möglichkeiten der IBM-Datenbankprodukte vor. Es ist jetzt möglich, Data-Mining-Verfahren etwa in Netezza und DB/2 auszuführen, entweder native Implementierungen oder externe R- oder Python-Skripts. Analytik in der Datenbank ist für mich auch sehr interessant, ich habe dazu bereits 2014 bei den Linuxwochen vorgetragen und es wird auch bei den PostgreSQL-Konferenzen in Wien und Hamburg diesen Herbst mein Thema sein.

Ingo Feinerer stellt das von ihm entwickelte R-Paket „tm“ vor. Dieses Paket ist eine Komplettlösung für Text Mining in R. Dieses Aufgabengebiet habe ich bisher nur mit RapidMiner abgedeckt, aber ich werde sicher einmal auch die Gelegenheit haben, mit tm in R zu arbeiten. Spannend ist hierbei die transparente Hadoop-Integration, die ja für größere Textsammlungen notwendig sein kann.

Den Schlußvortrag des Tages hielten Wilfried Grossmann und Stefanie Rinderle-Ma von der Uni Wien. Sie berichteten über ihr Projekt, in einer Lernplattform an der Uni Process Mining zu betreiben. Soweit ich mich erinnern kann, war dies der erste Vortrag zu Business Process Mining bei der Predictive-Analytics-Konferenz. Das Thema ist sicher auch eine Betrachtung  in SCO2T wert. Wenn der Tag nur mehr Stunden hätte…

 

Data Science with PostgreSQL

… ist der Titel des Vortrags, den ich bei der Europäischen PostgreSQL-Konferenz eingereicht habe. Die Konferenz findet vom 27. bis 30. Oktober in Wien statt. Der Vortrag wurde vom Programmkomitee (alles große Namen in der PostgreSQL-Welt) angenommen.

Im Vortrag geht es um die verschiedenen Aufgaben im Bereich Data Science und wie PostgreSQL sie abdeckt:

  • Datenintegration und ETL: Foreign Data Wrappers für den Zugriff auf andere Datenbanken, Dateien, NoSQL- und Hadoop-Datenquellen; prozedurale Sprachen für den Zugriff auf Web-APIs und andere Systeme
  • Preprocessing: Standard-SQL und fortgeschrittene Methoden
  • Data understanding: Deskriptive Statistiken mit SQL, Visualisierung mit PL/R
  • Predictive analytics: Data Mining mit PL/R und PL/Python, Modellanwendung in der Datenbank

Ich freue mich sehr, vor dem hochkarätigen Publikum einer renommierten Konferenz über diese Themen sprechen zu können.

Über die Schwierigkeit, ein analytisches Unternehmen zu sein

Im immer sehr interessanten „Stats with Cats“-Blog erschien vor kurzem der Beitrag „It’s Hard to be a Data Driven Organization„. Ich kann ihn sowohl Managern als auch anderen Data Scientists sehr empfehlen.

Der Autor spricht viele Themen an, die ich gerade in Österreich auch schon gesehen habe: Insbesondere das Nicht-Glauben an die Aussagekraft von Daten und statistischen Methoden und die Überzeugung, die eigene Erfahrung würde zu besseren intuitiven Entscheidungen führen als eine datengestützte Vorgehensweise.

Auch als Data Scientist muß man sich manchmal dem Management stellen und die Ergebnisse der eigenen Arbeit erklären. In diesem Kontext trifft man dann eventuell auf Gegenmeinungen von Leuten, die das politische Spiel im Unternehmen besser beherrschen (weil es ihre Hauptbeschäftigung ist?). Es kann schwierig sein, dem genug entgegenzusetzen, weil man in der Organisation doch eine niedrigere Rolle einnimmt (trotz der häufig besseren Ausbildung und einer vergleichbaren Gehaltsstufe).

Wenn ein Unternehmen sich als daten-gesteuert ansehen will, ist es die Verantwortung der Geschäftsleitung, durch die politischen Argumente hindurchzusehen und die Arbeit der Data Scientists entsprechend zu bewerten.

Data Science und Mathematik

Auf Heise Developer erschien heute ein Artikel „Data Scientist – ein neues Berufsbild für die Big-Data-Welt„. Relevante Aspekte wie Methoden, Werkzeuge und Ausbildungsmöglichkeiten werden darin thematisiert.

Mit einer Aussage bin ich jedoch nicht ganz einverstanden: der Formel „Data Science = Mathematik + Informatik + Domänenwissen“.

Informatik (wenn auch nur Teile davon) kann ich absolut bestätigen. Das Wissen um Datenbanksysteme, Systemarchitekturen, Programmiersprachen, Textkodierungssysteme usw. ist für uns Data Scientists ohne Frage essenziell.

Domänenwissen über alle möglichen Themen kann man als Freelancer gar nicht haben. Es zählt vielmehr die Fähigkeit (und der Wille), sich mit offenen Augen durch die Welt zu bewegen und sich fürs aktuelle Projekt tatsächlich in die Problemfelder der Aufgabe einarbeiten zu können.

Was mich aber in der „Formel“ am meisten stört, ist die Betonung von Mathematik. Statistik ist nur ein sehr kleiner Ausschnitt der Mathematik, vielleicht nicht einmal ein besonders typischer. Und es ist die Statistik, die als Grundlage von Data Mining und Predictive Analytics gilt. Andere Teile von Mathematik (Graphentheorie etwa) sind sicherlich nützlich für abgegrenzte Teilaufgaben (also durchaus für eine Spezialisierung geeignet, wenn man Interesse daran hat), aber im Zweifelsfall sollte man sich lieber intensiv mit Statistik beschäftigen als den gleichen Zeitaufwand auf allgemeine Mathematik aufzuteilen.

Sicher kann es nützlich sein, mehr Mathematik zu wissen. Aber genauso könnte man von Wissen in den Bereichen Betriebs- und Volkswirtschaft, Linguistik oder Physik profitieren. Nach meiner Erfahrung ist Vielseitigkeit ganz wichtig.

Viele Data-Mining-Methoden und Vorgehensweisen lassen sich nicht mehr vollständig mit Mathematik beschreiben. Wir wissen aber, wie wir die Ergebnisse trotzdem in der Praxis validieren und einsetzen können.

Die Unterscheidung zwischen Statistik und Mathematik sieht man auch daran, daß in fast jedem Text über Data Science die Sprachen R (spezialisiert auf Statistik) und Python (mit der Erweiterung um statistische Funktionen), aber selten die klassischen mathematischen Sprachen wie Octave/Matlab erwähnt werden. (Das schließt natürlich nicht aus, daß jemand diese Werkzeuge kennt und erfolgreich nutzt.)

Data Science ist heute so weit fortgeschritten, daß High-Level-Werkzeuge wie RapidMiner, Pentaho und Datameer fast alle Aspekte ohne Programmierung und vor allem ohne mathematische Formeln abdecken. Um mit ihnen erfolgreich predictive analytics zu betreiben, sind gewisse statistische Kenntnisse wichtig. Für Außenstehende mag das von Mathematik nicht unterscheidbar sein, aber Tatsache ist, daß man weitgehend ohne Formeln und mathematische Beweise verstehen kann, wie die Verfahren arbeiten und wo ihre Vor- und Nachteile liegen.

In der RapidMiner-Schulung kommen jedenfalls kaum Formeln vor, trotzdem können die Teilnehmer danach komplexe Data-Mining-Prozesse auf ihre Daten anwenden und aus ihnen erfolgreich Vorhersagen generieren. Sie kennen die Anwendbarkeit und die Vor- und Nachteile von einzelnen Algorithmen (ohne sie mathematisch Schritt für Schritt erklärt zu bekommen) und können sie in der Praxis einsetzen – und darum geht es in der Data Science.

Vielleicht ist der Science-Aspekt im Artikel auch ein bißchen zu kurz gekommen. In der Wissenschaft geht es auch darum, skeptisch zu bleiben und die Ergebnisse am besten nochmal unabhängig zu überprüfen. (Da hilft wieder speziell die Statistik.)

Die Ausbildung ist natürlich ein Thema. Ich bin wirklich gespannt, ob die neuen und kommenden Data-Science-Ausbildungsmöglichkeiten auch in der Praxis verwendbar sind, oder ob vielleicht doch eher die Erfahrung nach wie vor mehr zählt. Jene, die aktuell schon als Data Scientist arbeiten, so wie ich, mußten das ja auch irgendwo lernen und dabei vielleicht Umwege gehen. Unsere Begeisterung für Datenanalyse hat uns (vielleicht auch unbewußt) in diese Richtung gesteuert und dazu geführt, uns in den notwendigen Themen zu vertiefen. Daraus folgt für mich, daß auch in Zukunft Leute eine Chance haben werden, auch wenn sie nicht die konkrete (Data Science genannte) Ausbildung gemacht haben.