Der ein oder andere denkt nun sicherlich unweigerlich an Excel. Das ist auch nicht weiter verwerflich. Allerdings verstellt der schnelle Rückgriff auf Excel, als Analysetool für alle Fälle, oft den Blick auf Alternativen, die nur auf den ersten Blick komplizierter anmuten. Ausgefeilte Excel-Tools sind häufig für Außenstehende kaum nachvollziehbar und auch die Entwicklung komplexerer Programme beziehungsweise Arbeitsabläufe in Excel bedarf einer intensiven Einarbeitung in das Tool. Hier gibt es für Citizen Data Scientists sinnvolle Alternativen – eine davon ist die visuelle Programmierumgebung KNIME, die wir im Folgenden etwas genauer vorstellen wollen.
Wer noch nicht den ersten Beitrag „Citizen Data Science – Was ist das?“ zu dieser Blogserie gelesen hat, kann gerne hier reinschauen.
KNIME (oder eine Alternative) statt Excel
KNIME ist eine Open Source Data Mining Plattform, mit der sich Machine Learning Projekte mit Hilfe einer visuellen Programmieroberfläche gestalten lassen (www.knime.com). Natürlich bleibt das klassische „Coden“ nicht ganz aus, allerdings lassen sich auch komplexere Anforderungen mit konfigurierbaren Bausteinen in einer ETL-Machine-Learning Pipeline umsetzen. Für die Entwickler unter uns: KNIME setzt dabei auf Java auf und erinnert grundsätzlich an die Ecplise DIE – das ist aber für einen Citizen Data Scientist zunächst nicht weiter relevant. KNIME bietet diverse Möglichkeiten zur Anbindung von verschiedenen Datenquellen und kann auch in beliebige Ausgabeformate zurückschreiben. Das erleichtert den Austausch zwischen Fachbereichen natürlich ungemein.
In diesem kleinen Beispielprojekt werden Daten aus einer Excel-Datei gelesen (Excel Reader), Zeilen mit fehlenden Werten gefiltert (Row Filter), eine neue Zielvariable erstellt (Rule Engine), in Trainings- und Testdaten unterteilt (Row Splitter), ein Random Forest Prognosemodell mit Hilfe der Trainingsdaten gelernt (Random Forest Learner) und damit Prognosen für die Testdaten erstellt (Random Forest Predictor). Die Prognoseergebnisse werden dann wieder als Excel-Datei gespeichert (Excel Writer).
Wie bitte?
An einem konkreten Beispiel: Ein Kollege stellt mir eine Excel-Datei zur Verfügung, in der über das letzte Jahr für jeden Tag die Auslastung einer Produktionsmaschine vermerkt ist, sowie diverse weitere Informationen. Zu diesen weiteren Informationen zählen unter anderem Angaben dazu, welche Mengen an von der Produktionsmaschine benötigten Materialien sowie wie viele für die Produktionsmaschine zuständige Mitarbeiter an dem jeweiligen Tag verfügbar waren. Nach dem Einlesen dieser Excel-Datei meines Kollegen (Excel Reader) werden nun die Zeilen (also Tage) herausgefiltert, für die die Auslastung der Maschine nicht vermerkt wurde (Row Filter), da diese für das Lernen des Machine Learning Modells zunächst nicht weiterhelfen. Im nächsten Schritt werden drei Kategorien definiert – niedrige Auslastung (unter 50 Prozent), mittlere Auslastung (50-90 Prozent) sowie hohe Auslastung (über 90 Prozent). Dies geschieht via Rule Engine und simplen Wenn-Dann-Regeln. Nun werden die Daten aufgeteilt in Trainingsdaten und Testdaten. Mit den Trainingsdaten wird ein Prognosemodell gelernt bzw. trainiert. Die Testdaten werden nicht zum Lernen verwendet und dienen somit als Test, ob beziehungsweise wie gut das Prognosemodell funktioniert. Für unser Beispiel nutzen wir die ersten 1500 Datensätze als Trainingsdaten und die aktuellsten 200 Datensätze als Testdaten (Row Splitter). Nun trainieren wir mit den Trainingsdaten ein Prognosemodell (Random Forest Learner), indem durch das Erlernen verschiedener Merkmalskombinationen (Anzahl verfügbarer Mitarbeiter, Wochentag, Mengen benötigter Materialien) auf die dann zu erwartende Auslastung der Maschine geschlossen wird. Nachdem dieses Prognosemodell erstellt wurde, wenden wir es direkt auf unsere Testdaten an (Random Forest Predictor) und schauen uns an, wie gut die Auslastung der Produktionsmaschine tatsächlich vorhergesagt werden kann. Die Ergebnisse der Prognose schreiben wir in eine Excel-Datei (Excel Writer), um diese dann Kollegen und Kolleginnen zur Verfügung zu stellen.
Dies ist ein sehr einfaches Beispiel – man könnte nun fragen, warum ein Random Forest Modell verwendet wurde oder wie man neben der Frage, ob das Prognosemodell funktioniert, auch die Frage klären kann, warum es denn gut oder eben nicht so gut funktioniert. Diese Fragen beantworten wir dann in späteren Beiträgen, denn nun wollen wir nochmal auf das Tool KNIME zurückkommen.
Schnelles Prototyping, permanenter Blick in die Daten
In KNIME sieht man die einzelnen Prozessschritte klar visualisiert und hat immer einen direkten Blick auf den Datenfluss und die Transformationen, die vorgenommen werden. Am Ende jedes Bausteins kann komfortabel in die Daten geblickt werden, um direkt zu sehen, ob die entwickelte Pipeline ihre Aufgabe erfüllt. Dabei lernt man als Citizen Data Scientist die Daten intensiv kennen und ist immer mehr in der Lage komplexe Herausforderungen in einzelne Arbeitsschritte herunterzubrechen. Man gelangt schnell zu Erkenntnissen und hat genauso schnell einen ersten Überblick darüber, was mit den Daten möglich ist beziehungsweise möglich sein könnte. In unserem Beispiel von eben ist es einfach, gemeinsam einzelne Arbeitsschritte zu betrachten und gegebenfalls anzupassen, ohne dass man dafür selbst zwangsläufig Programmierkenntnisse benötigt.
Leichter Einstieg auch ohne klassische Programmierkenntnisse
Data Scientists sind nicht unbedingt von Haus aus Informatiker beziehungsweise Software-Entwickler. Sie kommen zum Beispiel eher aus dem Bereich Statistik/quantitative Forschung und sind durch den einfachen Einstieg mit Hilfe der KNIME Benutzeroberfläche in der Lage, auch ohne tiefgehende klassische Programmierkenntnisse komplexe Machine Learning Workflows zu implementieren. Eine große Auswahl an vorgefertigten Bausteinen mit sehr überschaubarem Konfigurationsaufwand erlauben zum Beispiel das Einlesen von Daten aus verschiedensten Formaten und Quellen (json, xml, txt, csv, xlsx, …) und dann die Weiterverarbeitung dieser Daten auf verschiedensten Wegen. Citizen Data Scientists können sich daran gut orientieren und sich mehr auf die Arbeitsschritte und den generellen Ablauf eines Machine Learning Projekts konzentrieren statt eine oder gleich mehrere Programmiersprachen beherrschen zu müssen und zu lernen wie man mit verschiedenen Schnittstellen interagiert.
Comentarios