Hallo und herzlich Willkommen zu unserem Blog.

10.06.2016

Die CEWE Stiftung & Co. KGaA hatte uns zum CEWE Analytics Forum eingeladen, welches am 07. Juni stattgefunden hat. Hierzu haben wir eine Präsentation gezielt für das Publikum bestehend aus Vorstand und Abteilungsleitern erstellt. Die bisherigen Ergebnisse der Projektgruppe sind von dem Publikum positiv aufgenommen worden.

Am 08. Juni und 09. Juni fand an der Carl von Ossietzky Universität Oldenburg eine bundesweite und fächerübergreifende Konferenz für studentische Forschung statt. Die Veranstaltung nennt sich „forschen@studium“. Hier können Studenten ihre Forschungsergebnisse aus Hausarbeiten, Abschlussarbeiten oder Projektarbeiten präsentieren. Weiter Informationen zu der Konferenz sind unter uol.de/lehre/qualitaetspakt-lehre/flif/forschen-at-studium/konferenz-fuer-studentische-forschung/ zu finden.

Um an der Konferenz teilnehmen zu können, mussten alle interessierten Teilnehmer ihre Forschung in einem Abstract, welcher den Umfang von einer Seite hatte, darstellen. Auch wir haben einen Abstract verfasst, welcher angenommen und zusammen mit den anderen angenommen Abstracts in dem Tagungsband der Konferenz „forschen@studium“ veröffentlicht wurde. Unser Abstract ist auf Seite 106 zu finden (uol.de/fileadmin/user_upload/flif/Konferenz2016/Broschur_Forschen_A4_Internet.pdf). Zusätzlich streben wir eine Veröffentlichung in dem studentischen Online-Journal „forsch!“ an.

Für die Konferenz in Oldenburg haben wir unsere Ergebnisse in Form eines Posters im Rahmen einer Postersession vorgestellt. Hierbei konnten wir einige Interessenten über unser Projekt informieren. Dabei haben wir ebenfalls positives Feedback erhalten. 

Quelle: Fotografiert von Simon Becker

16.05.2016

In unserem ELT-Prozess ist nach AXT (Agent for XML Transportation) die Komponente PreX (Prepare XML) geplant gewesen, um die XML-Dateien zu mergen und dann die gemergten Dateien an den Parser zu übergeben. Nun haben wir allerdings beschlossen, die Funktion von PreX nicht separat in einer Komponente zu implementieren, sondern in AXT aufzunehmen.

Weiterhin besteht noch die Problematik, große Datenmengen mittels Hadoop Streaming und Spark zu parsen. Deswegen werden nun einige Mitglieder aus dem Analysen-Team das Parser-Team unterstützen und diese Arbeit weiter vorantreiben.

Die CEWE Stiftung & Co. KGaA hat uns angeboten, dass wir unsere bisherigen Ergebnisse auf dem CEWE Analytics Forum vorstellen dürfen. Wir wollen dieses Angebot annehmen und arbeiten hierzu eine Präsentation aus, welche weniger auf die technischen Details, sondern mehr auf die Ergebnisse eingeht, die mit unserer Arbeit erzielt werden können.

Zeitgleich mit der intensiven Phase der Entwicklung ist nun der Termin für das Projektgruppen-Boule-Turnier bekannt gegeben worden. Wir nehmen natürlich daran teil. In Vorbereitung zur Stärkung des Teamgeistes haben wir noch ein Fußballspiel gegen die Projektgruppe DOHA organisiert.

02.05.2016

Oftmals ist es in der Software-Entwicklung so, dass wenn ein Fehler behoben werden konnte, der nächste auftritt. Ähnliches haben wir bei unserem ELT-Prozess feststellen müssen. Unser AXT (Agent for XML Transportation) läuft jetzt einwandfrei, weil die fehlerhafte Methode durch eine andere Methode ausgetauscht worden ist. Allerdings haben wir nun Schwierigkeiten beim Parsen der Daten. Sowohl bei der Variante mit Hadoop Streaming als auch bei der Alternative mit Spark haben wir Out-of-Memory- Probleme, sodass wir bisher nur kleine Datenmengen parsen können.

Damit dennoch die anderen Ziele erreicht werden können, arbeitet sich ein Teil der Projektgruppe bereits in die XML-Dateien in Hinblick auf Data Understanding ein. Es werden sogar schon erste Analysen an den vorhandenen Daten durchgeführt.

Zudem haben wir nun Testbeauftragte in unserer Projektgruppe definiert, die das Testmanagement übernehmen. Hierzu werden anfangs Testdrehbücher für die einzelnen Komponenten erstellt.

Organisatorisch betrachtet wollen wir uns neu aufstellen. Bisher treffen wir uns jeden Donnerstag für den gesamten Tag, um intensiv in der Gruppe bzw. in Teilgruppen an dem Projekt arbeiten zu können. Diese gemeinsame Zeit ist sehr wichtig, weil viel diskutiert und besprochen wird. Allerdings fehlen uns oftmals 1-2 Stunden, in denen Organisatorisches geklärt wird wie z.B. Weekly Scrum, Sprintabschluss und Sprintplanung. Diesen organisatorischen Teil wollen wir nun auf einen anderen Tag verschieben, damit wir donnerstags noch produktiver sein können.

Bei unserem zweiten Social Event waren wir in der Barcelona Finca.

18.04.2016

Manchmal können im Projektalltag, insbesondere im Rahmen einer studentisch organisierten Gruppe, trotz reiflicher Planung und Abstimmung gesetzte Ziele nicht erreicht werden. 

So konnte unser Ziel eines kompletten ELT-Laufs aufgrund von Problemen innerhalb von AXT (Agent for XML Transportation) bis zum gesteckten Meilenstein nicht erfüllt werden. Intensive Recherchen ergaben, dass beim Übertragen von größeren Dateien der FTP Server einen Fehlercode sendete. Dieser Fehler wurde von der verwendeten Methode der Apache commons.net Library nicht korrekt verarbeitet, wodurch es zu einer Art Endlosschleife kam.

Damit die nachfolgenden Meilensteine allerdings nicht beeinträchtigt werden, wird parallel in der Projektgruppe an Anforderungen und Ideen für erste Analysen und Hypothesen geforscht.

Außerdem zeigte sich, dass im Umgang mit GIT zur Verwaltung unserer Daten einzelne Repositories für die verschiedenen Komponenten notwendig sind. Dies ist begründet durch die Anforderungen an die einzelnen Komponenten und deren Wachstum. Es resultiert eine neue Struktur in unserem GIT: AXT (Agent for XML Transportation), Parser, HIMP (Hive Importer; ehemals Watchdog), Airflow, Tests, Analytics, Dokumentation, Sonstiges.

Des Weiteren müssen wir uns in Zukunft angewöhnen, Änderungen im Quellcode zunächst auf einem Branch vorzunehmen. Erst wenn die Änderungen erfolgreich getestet worden sind, können sie aufdem Master-Branch gepushed werden. Dies dient dazu, dass der Master-Branch immer stabil ist und eine lauffähige Version enthält.

04.04.2016

Die Teilgruppe „Dashboard und Visualisierung“ hat sich in den letzten zwei Wochen mit der Evaluierung von Tools für die Softwareauswahl beschäftigt. Die Entscheidung, welches Tool zur Visualisierung und für unser Dashboard verwendet werden soll, fiel auf Apache Zeppelin. Es erfüllt die gestellten Anforderungen und erlaubt eine einfache Handhabung.

Die weiteren Teilgruppen sind mit der Einhaltung der Fristen für den Meilenstein am 07.04.2016 beschäftigt, der den kompletten Durchlauf des ELT-Prozesses beinhaltet (siehe Grafik in vier Schritten).

1. Im ersten Schritt werden die XML-Daten von dem FTP-Server mittels unserer selbst geschriebenen Anwendung AXT (Agent for XML Transportation) in das HDFS übertragen. Dabei gibt es im HFDS eine baumartige Ordnerstruktur, die sich nach Jahren, Monaten und Tagen untergliedert.
2. Anschließend werden die XML-Daten vorbereitet. D.h. entweder, dass mehrere XML-Dateien zu einer XML-Datei zusammengefasst werden und in den Ordner ready2parse ins HDFS gespeichert werden, oder, dass die Original-XML-Dateien in den Ordner ready2parse kopiert werden. Dieser Schritt geschieht mit unserem eigenen Tool PreX (Prepare XML).
3. Die XML-Dateien aus dem Ordner ready2parse werden geparst. Die Ergebnisse sind dann für den vierten Schritt in dem Ordner parsedData im HDFS zu finden.
4. Abschließend werden im letzten Schritt die Daten mit Hilfe von Watchdog in Hive-Tabellen geladen. Hierbei ist Watchdog für die Anwendung angepasst worden und entspricht keinem „normalen Watchdog“, da eine Überwachung im eigentlichen Sinne nicht durchgeführt wird.

Der gesamte Workflow wird mit dem Workflowmanagementsystem Airflow kontrolliert.

18.03.2016

Neben den bestehenden beiden Teilgruppen für den ELT-Prozess wurden jetzt zwei neue Teilgruppen ins Leben gerufen, um offene Tätigkeiten innerhalb der PG zu erledigen:

• Teilgruppe Dashboard und Visualisierung
• Teilgruppe Data Mining

Somit existieren aktuell vier Teilgruppen à drei Personen in der PG.

Für das Laden der XML-Daten in das HDFS konnte keine passende Anwendung identifiziert werden, sodass die Entscheidung getroffen wurde, diese Tätigkeit selbst zu implementieren: „Agent for XML Transportation“ (AXT). Leider stellte sich erst im Nachhinein bei der Evaluierung einzelner Funktionalitäten anstatt zu einem früheren Zeitraum heraus, dass kein Tool existiert, welches die Anforderungen erfüllt und die Entwicklung in Eigenregie erfolgen muss.

Unabhängig von der Implementierung ist ein Ziel der PG der Wissenserwerb mit den eingesetzten Methoden und Tools, das sich beim Abschluss des siebten Sprints zeigte. In diesem wurde festgestellt, dass Confluence die Möglichkeit der Erstellung einer Retrospektive hat, die ab sofort zur Verbesserung zukünftiger Sprints eingesetzt wird.

Die aktuelle Planung beinhaltet den Meilenstein 07.04.2016: ELT-Prozess Durchlauf auf der Alpha Version. Hierzu müssen unsere selbst entwickelten Tools wie z.B. AXT oder der Parser bis dahin fertig und lauffähig sein. Außerdem müssen alle beteiligten Komponenten über ein Workflowmanagementtool miteinander verbunden werden. 

29.02.2016

Das erste Statusmeeting in 2016 mit der CEWE Stiftung & Co. KGaA findet statt. Es wird der aktuelle Stand der beiden Teilgruppen sowie die bisherige Komponentenauswahl vorgestellt. Die CEWE Stiftung & Co. KGaA nennt uns das Sizing der Hadoop-Landschaft für die Beta-Version. Zudem wird geplant, dass die Projektgruppe im Juni eine Präsentation bei einer CEWE-internen Veranstaltung, dem sogenannten Analytik-Forum hält.

• Das Tool Gobblin wird weiterhin untersucht. Als Alternative zum Hadoop Streaming wird Apache Spark untersucht. Dabei kann der Parser in Apache Spark aufgerufen werden.
• Mit dem Python-Parser lassen sich die bisherigen XML-Dateien parsen. Dabei werden die Ergebnisse in csv-Dateien nach dem entworfenen Datenbankmodell gesichert. Jedoch ist die Implementierung bisher noch statisch. Spätestens in der Beta-Version soll hier eine dynamische (teilweise) Lösung vorliegen.
• Der Import der csv-Dateien in die Hive-Tabellen funktioniert. Nun wird geprüft, ob das Work-Flow-Tool Apache Oozie geeignet ist um zu prüfen, ob neue csv-Dateien vorhanden sind.
• Es ist geplant, ein Logging-System einzurichten. Dies hilft bei Fehlern zu ermitteln, in welcher Komponente bzw. bei welchem Schritt der Fehler aufgetreten ist.

Es werden Programmierrichtlinien erstellt. Obwohl wir bereits mit der Programmierung begonnen haben, ist es noch nicht zu spät hierfür. Noch ist der produzierte Quellcode überschaubar und kann leicht überarbeitet werden.

Damit am Ende des Projekts keine reine Doku-Phase entsteht, werden die bisherigen Ergebnisse bereits in einem Dokument für die Abschlussdokumentation zusammengetragen.

Jedes Teammitglied fängt an, sich mit den Themen Data Mining und Visualisierung bzw. Dashboard auseinanderzusetzen, damit die kommenden Aufgaben entsprechend verstanden und verteilt werden können. Es werden demnächst zwei neue Teilgruppen gebildet. Die eine wird sich dann mit dem Thema Data Mining und die andere mit den Themen Visualisierung und Dashboard beschäftigen.

Das erste Social Event der Projektgruppe fand in der 3Raumwohnung statt. Dort haben wir Tischkicker gespielt, uns unterhalten und einfach Spaß gehabt.

12.02.2016

Nach etwa der Hälfte der Projektgruppen-Zeit finden erste Feedback-Gespräche statt. Jedes Teammitglied erhält ein Einzelgespräch mit den Betreuern um einerseits die aktuelle Note bzw. Tendenz zu erfahren und andererseits etwaige Probleme oder Besonderheiten zu erwähnen.

Da wir beim letzten Mal festgestellt hatten, dass der Umgang mit JIRA noch nicht perfekt bei uns funktioniert, findet nun ein Frühjahrsputz in unserem JIRA-System statt. Einige Teammitglieder übernehmen diese Aufgabe. Dies beinhaltet eine Überarbeitung der Epics (Themengebiete im JIRA) sowie eine neue Namensgebung der verschiedenen Status, damit genau zwischen „in Test“ und „fertig“ unterschieden wird. „Fertig“ ist eine Aufgabe erst dann, wenn sie getestet worden ist.

Hadoop Streaming wird untersucht. Hiermit ist es möglich, Python Skripte auf dem Cluster zu verteilen. Als Alternative wird das manuelle Verteilen der Skripte untersucht. Der Parser an sich wird weiterentwickelt. Zudem werden Hive-Tabellen erstellt. Das Tool Gobblin für das Extrahieren und Laden der Daten wird untersucht. Da dieses Tool noch relativ neu bzw. in der Entwicklung ist, gibt es hier einige Probleme.

Es wird ein erstes Social Event für Ende des Monats geplant. Voraussichtlich werden wir das in Zukunft regelmäßig machen.

13.01.2016

Nach den Weihnachtsferien untersuchen wir weiter, welche der verschiedenen Komponenten des Apache Hadoop Ecosystems am besten für unser Vorhaben geeignet sind. Dabei betrachten wir folgende Komponenten im Detail:

Für das Extrahieren und Laden der Daten werden die Tools Apache Kafka, Elasticsearch, Logstash, Fluentd, Apache Storm und Apache Flume untersucht. Bei Apache Storm sind wir auf Konfigurationsprobleme im Bereich Apache ZooKeeper gestoßen. Die Konfiguration von Apache Storm und Nimbus ist erfolgreich verlaufen. Elasticsearch ist für unsere Anforderungen nicht geeignet. Die Tools Logstach, Apache Flume  und Fluentd haben relativ ähnliche Leistungsmerkmale, weswegen hier nun der Installations- und Konfigurationsaufwand sowie die Kompatibilität mit anderen Tools verglichen werden soll.

Zum Transformieren und Parsen der Daten werden die Tools Apache Hive, Apache Pig und Apache Spark untersucht. Apache Spark wird dabei mit den verschiedenen Programmiersprachen Java, Scala und Python betrachtet. Dabei hat sich bisher gezeigt, dass Apache Pig für unser Anliegen ungeeignet ist, weil sich hier keine einzelnen Attribute aus der XML-Datei auslesen lassen. Mit Apache Hive und Apache Spark lassen sich die Daten für unsere Anliegen parsen. Da Apache Spark jedoch einfacher zu konfigurieren und zu verwenden ist, wird sich hierfür entschieden.

Neben der Komponenten-Auswahl beschäftigt sich ein Teil unserer Gruppe dieser Tage intensiv mit den XML-Dateien. Ziel ist es eine Dokumentation zum Verständnis der XML-Dateien zu erstellen. Derzeit wissen wir noch nicht, wofür jedes einzelne Element und jedes Attribut steht bzw. welche Informationen sich dahinter verbergen. Um dies in Zukunft sagen zu können, wird eine Dokumentation erstellt und mit den Mitarbeiter des Praxispartners besprochen. Dies ist eine notwendige Grundlage für die zukünftige Analyse der Daten.

Neben diesen Tätigkeiten ist uns aufgefallen, dass unsere bisherige Organisation einiges an Verbesserungspotential aufweist. So wird bisher noch nicht in vollem Umfang mit JIRA gearbeitet, was sich dadurch zeigt, dass die Aufgaben nicht immer richtig zugewiesen werden und die Aufgaben im System allgemein wenig aktuell gehalten werden. Oftmals hat die Person, die für die Entwicklung zuständig war, die Ergebnisse auch selbst getestet. Dadurch war das bisherige Testen der Ergebnisse nicht wirklich gegeben. Jetzt wird direkt nach Abschluss einer Aufgabe diese einer anderen Person, die sich mit der Thematik der Aufgabe ebenfalls auskennt, zum Testen zugewiesen. Somit erhält der Bearbeiter der Aufgabe mehr Feedback. Wir wollen dadurch bessere Ergebnisse erzielen. Damit das Tool wirklich unterstützend wirkt, müssen wir mehr darauf achten, die Aufgaben aktuell zu halten und den richtigen Personen zuzuweisen. Nur dann kann es auch einen positiven Einfluss auf unsere Arbeitsergebnisse haben.

Jahresausblick 2016

Nachdem in 2015 die Projektgruppe mit der Einarbeitung in die Thematik begonnen hatte, die Anforderungen erhoben wurden und das Jahr mit der Evaluierung der Komponenten von Apache Hadoop endete, geht es in 2016 mit der Entwicklung eines ersten Prototypen weiter.

Insgesamt teilt sich das Jahr 2016 in Hinblick auf die Projektgruppe in zwei Zeiträume. Der erste Zeitraum geht bis April und umfasst die Entwicklung eines ersten Prototypen (Alpha-Version). Der zweite Zeitraum ist ab April bis September und behandelt die Entwicklung des zweiten Prototypen (Beta-Version) als Ergebnis der Projektgruppe. Der große Hauptunterschied zwischen den beiden Versionen ist, dass die Alpha-Version auf Servern innerhalb der Carl von Ossietzky Universität Oldenburg läuft und die Beta-Version in die Systemumgebung von der CEWE Stiftung & Co. KGaA integriert wird.

In der Alpha-Version haben wir noch die Möglichkeit, alles auszuprobieren und zu testen. Wir können sämtliche Komponenten installieren und von verschiedensten Gesichtspunkten evaluieren. Und genau das wird auch noch viel geschehen. Im April zieht dann unser System von den Servern der Carl von Ossietzky Universität Oldenburg zu den Servern der CEWE Stiftung & Co. KGaA. Hier findet dann die Beta-Version statt. Die Komponenten, welche wir letztendlich verwenden wollen, sollten somit bis April feststehen, weil in der Beta-Version keine Komponenten getestet werden sollen.

Wir haben geplant uns ab März mit der Analyse der Daten auseinanderzusetzen. Hierbei unterscheiden wir zwei Formen der Analyse. Zum einen Analytik an sich und zum anderen Data Mining. Unter Analytik verstehen wir dabei eine reine Ermittlung der Kennzahlen. Mit Data Mining meinen wir sämtliche Analyse-Themen, die komplexer sind.

Um jedoch die Daten überhaupt analysieren zu können, müssen wir die XML-Daten extrahieren, in das Hadoop Distributed File System (HDFS) laden und die Daten transformieren. Mit dieser Thematik haben wir bereits im Dezember 2015 begonnen und führen sie noch im Januar und Februar 2016 weiter.

Jahresrückblick 2015

Im Oktober 2015 begann die Projektgruppe. Als erstes war das große Kennenlernen mit den anderen Projektgruppenteilnehmern und den betreuenden Dozenten angesagt. Danach lernten wir unsere Ansprechpartner bei der Firma CEWE Stiftung & Co. KGaA kennen und uns wurden die DigiFotoMaker (kurz: DFM) vorgestellt. Die DFM sind Kiosk-Geräte der CEWE Stiftung & Co. KGaA, die bei ihren Handelspartnern wie beispielsweise Müller Großhandels Ltd. & Co. KG aufgestellt sind. An diesen Geräten können Fotoprodukte bestellt und direkt vor Ort ausgedruckt werden. Bei der Bedienung eines DFM werden neben technischen Daten auch Informationen zum Bedienverhalten in einer XML-Datei gesichert. Unsere Aufgabe ist es, diese XML-Datei mit Hilfe von Apache Hadoop auswerten zu können.

Bevor wir an die eigentliche Bearbeitung unseres Projekts gehen konnten, mussten wir uns einigen, wie wir uns innerhalb des nächsten Jahres organisieren wollen. Wir einigten uns sehr schnell bei dem Verfahren zur Softwareentwicklung auf SCRUM, weil wir das alle kennen, mit dem Ablauf vertraut sind und uns damit wohl fühlen. Als Tool zur besseren Organisation wählten wir Jira mit dem dazugehörigen Dokumentations-Tool Confluence. Zusätzlich verwenden wir GIT zum Dateiaustausch. Außerdem wurden einige Rollen verteilt, so haben wir nun zwei Projektmanager, zwei Serverbeauftragte, einen Dokumentenverantwortlichen und einen Webseitenverantwortlichen.

Nachdem das Organisatorische geklärt war, wurden die Anforderungen erarbeitet und im Detail definiert. Dabei stellten wir drei Kern-Anforderungen heraus, die hier kurz erwähnt werden. Eine detaillierte Beschreibung ist unter „Projekt“ zu finden.

1. „Near Time“ Analyse wichtiger Kennzahlen
2. Alarm-System, welches Ausfälle und Störzeiten erkennt
3. Auswertung des Bedienverhaltens zur Optimierung der Bestellsoftware

Als nächsten Schritt evaluierten wir, welche Komponenten des Apache Hadoop Ecosystems wir verwenden werden. Dazu teilte sich die PG in zwei Teilgruppen auf. Die erste Teilgruppe untersuchte Komponenten für die Schnittstellen-Extraktion und das Laden der Daten in das Hadoop Distributed File System (HDFS). Die zweite Teilgruppe beschäftigte sich mit Komponenten für das Transformieren der XML-Dateien. Somit wurde der klassische ELT-Prozess aufgeteilt. Am letzten Termin vor den Weihnachtsferien stellten die einzelnen Teilgruppen den Zwischenstand ihrer Ergebnisse vor.

10.12.2015

Als ersten Schritt in Hadoop wollen wir uns für die benötigten Komponenten entscheiden. Weil Hadoop sehr umfangreich ist und über viele verschiedene aber ähnliche Komponenten verfügt, müssen wir einige testen und näher untersuchen. Hierbei zählt vor allem eine wissenschaftliche Herangehensweise, um eine Entscheidung vornehmen zu können. Hierfür hat sich die Projektgruppe in zwei Teilgruppen aufgeteilt. Die erste Teilgruppe beschäftigt sich mit Komponenten für die Schnittstellen-Extraktion und Laden der Daten. Die zweite Teilgruppe befasst sich mit Komponenten für Transformationsstrategien. Somit wurde der ELT-Prozess aufgeteilt.

Sobald wir die Komponenten ausgewählt haben, wollen wir in die nächste Phase übergehen. Das heißt, hier wird sich dann mit dem Thema der Analytik beschäftigt. Dies bezieht Data Mining und Maschinenlernen mit ein.

Es ist geplant, die finale Auswahl der zu installierenden Komponenten mit CEWE Stiftung & Co. KGaA abzustimmen. Obwohl wir zunächst alles Uni-intern installieren, ist zum Frühjahr 2016 ein Umzug der Architektur in die Systemlandschaft von CEWE Stiftung & Co. KGaA geplant. 

17.11.2015

Nachdem die PG DASH sich einige Wochen detailliert mit möglichen Use-/Business-Cases auseinandergesetzt hat, wurden die konkreten Ziele mit den CEWE Stiftung & Co. KGaA-Betreuern abgestimmt. Dabei wurden folgende Ziele definiert:

1. Alarmsystem: Dieser Begriff hat für einige Verwirrung gesorgt, weswegen eine genaue Definition in unserem Glossar dringend erforderlich war. Es ist nämlich kein reiner Ticketing-Dienst gemeint, der eine Nachricht ausgibt, wenn eine Warnung bzw. ein Alarm vorliegen. Hiermit verstehen wir auch die Logik, die benötigt wird, um eine Warnung bzw. den Alarm überhaupt erst erkennen zu können.
2. Operationales Dashboard: Dies dient vor allem auch zum Einstieg der PG in die konkreten XML-Daten. Das Dashboard dient zur Übersicht einiger Kennzahlen wir bspw. bestellte Produkte pro Tag.
3. Clickstream-Analyse: Unter Clickstream verstehen wir den anonymisiert protokollierten Verlauf der Klicks, die in der Bestellsoftware am Digi-Foto-Maker vorgenommen werden. Mit der Analyse dieser Daten kann die Benutzerfreundlichkeit der Digi-Foto-Maker verbessert werden. Es ist außerdem erkennbar, ob bestimmte Wege immer zu Abbrüchen führen oder ob bestimmte Kombinationen häufig getätigt werden.

Der Schwerpunkt unserer Arbeit soll eher in der Entwicklung eines ETL-Prozesses und in der Datenverwaltung in Apache Hadoop liegen. CEWE Stiftung & Co. KGaAist es weniger wichtig, welche Daten wir genau analysieren oder wie wir die Ergebnisse optisch aufbereiten.

Für das bessere Verständnis der XML-Daten ist ein Workshop in Zusammenarbeit mit CEWE Stiftung & Co. KGaA für den Januar geplant. Außerdem erhalten wir Zugang zu einem Digi-Foto-Maker, an dem wir selbst einige Testfälle erstellen können. Außerdem hat CEWE Stiftung & Co. KGaAuns eingeladen, bei dem sogenannten „CEWE Analytics Forum“ einen Vortrag zu halten. Dies ist eine CEWE Stiftung & Co. KGaA-interne Veranstaltung, bei der unser Projekt sogar dem Vorstand vorgestellt werden würde.

25.10.2015

Neben der Beantwortung der Frage „Wohin geht die Reise?“, haben wir uns auch schon erste Gedanken dazu gemacht, wie wir innerhalb des nächsten Jahres eigentlich dahin kommen möchten. Hierzu hat sich die PG auf einige organisatorische Punkte geeinigt. Teilweise waren diese Einigungen nicht immer ganz eindeutig und es wurde viel hin und her diskutiert.

Wo wir uns sehr schnell einig waren, war die Vorgehensweise nach Scrum mit Orientierung an CRISP DM. In beiden Fällen werden wir das Vorgehen individuell auf unsere Bedürfnisse anpassen. In Bezug auf Scrum haben wir uns derzeit auf zweiwöchige Sprints geeinigt. Unser wöchentliches Meeting zählt dabei als Weekly-Scrum anstelle eines Daily-Scrums.

Als einen weiteren organisatorischen Punkt haben wir uns für die Verwendung von Jira und Confluence entschieden. Dabei dient Jira zur Aufgabenverwaltung und Confluence für die Dokumentation. Ebenfalls setzen wir ein GIT auf, wobei hier noch ein paar Unklarheiten herrschen, wozu dies gut sein soll, wenn wir doch auch das Confluence haben. Immerhin brauchen wir nicht in beiden Systemen parallel dokumentieren.

Als kleine Auflockerung zwischendurch haben wir einen Fotoshooting-Termin gemacht. Ihr könnt die Fotos unter „Das Team“ einsehen. Somit habt ihr mal ein Bild, wer die PG DASH und „wir“ eigentlich sind. Im Januar folgt noch ein Fotoshooting, wo wir dann auch mal ein Bild mit den Betreuern sowohl von der Universität Oldenburg als auch von CEWE Stiftung & Co. KGaA machen.

Nach einigem hin und her und vielen kreativen Phasen konnten wir uns mittlerweile auch für unseren PG-Namen „DASH“ (Data Analytics with Hadoop) und unser Logo entscheiden.

18.10.2015

In den ersten Wochen sind wir dabei, die genauen Anforderungen zu erheben. Das erweist sich gar nicht als so einfach. Zu Beginn haben wir nur ein grobes Ziel erhalten. Ansonsten lässt unser Auftraggeber CEWE Stiftung & Co. KGaA uns überaus frei arbeiten.

Um zu bestimmen, wo die Reise hingehen soll, werden wir konkrete Ziele benennen. Hierzu haben wir uns zunächst mögliche Anwendungsfälle überlegt. Außerdem haben wir uns Gedanken zu den Anforderungen sowohl aus technischer Sicht an dem System als auch aus Anwender-Sicht gemacht.

Für die nächste Woche planen wir einen Termin mit CEWE Stiftung & Co. KGaA. Dann wollen wir unsere bisherigen Ergebnisse vorstellen und gemeinsam mit unseren Auftraggebern besprechen, welche Anwendungsfälle unserer Longlist nach Möglichkeit realisiert werden sollen. Zudem sind bei unseren bisherigen Überlegungen einige Fragen aufgekommen, die wir noch beantwortet haben müssen.

Neben den Anforderungen schreibt jeder noch an seiner Seminararbeit. Diese werden wir uns demnächst gegenseitig vorstellen. Auch dazu werden die Ergebnisse ab Dezember unter „Seminararbeiten“ zu finden sein.

13.10.2015 

In der zweiten Woche, waren wir bei der Firma CEWE Stiftung & Co. KGaA. Hier wurden uns unsere Ansprechpartner vorgestellt sowie die Fotostationen, auch Digi-Foto-Maker (kurz: DFM) genannt. Die DFM sind die Kiosk-Geräte von der CEWE Stiftung & Co. KGaA, die bei den Handelspartnern wie z.B. Müller aufgestellt sind. An diesen Geräten können Fotobestellungen aufgeben oder Fotoprodukte sofort vor Ort ausgedruckt werden. Bei der Bedienung eines DFM werden das Bedienverhalten sowie technische Daten des DFM wie beispielsweise die Temperatur des Druckers in einer XML-Datei abgespeichert.

Unsere Aufgabe für das kommende Jahr ist es, mit Hilfe von Apache Hadoop diese XML-Dateien auszuwerten zu können. Um das realisieren zu können, müssen wir uns zunächst mit Apache Hadoop auseinandersetzen und ein solches System aufsetzen. Neben dieser Einführung in die Thematik hat die CEWE Stiftung & Co. KGaA uns auch schon erste Anforderungen und mögliche Analyse-Themen genannt, was wir im Laufe des Projektes umsetzen sollten. Dies war eine „Near Time“ Analyse, ein Alarm-System um Ausfälle und Störzeiten zu erkennen und mittels einer detaillierte Auswertung des Bedienverhaltens der Bestellsoftware, diese weiter optimieren zu können.

01.10.2015

Wir sind die PG DASH an der Carl von Ossietzky Universität Oldenburg.

Unsere Projektgruppe (PG) nennt sich DASH - Data AnalyticS with Hadoop, weil wir uns  ein Jahr mit Apache Hadoop auseinandersetzen werden. Dabei arbeiten wir mit der Firma CEWE Stiftung & Co. KGaA zusammen, welche u.a. für ihre Foto-Dienstleistungen bekannt ist. Näheres hierzu findet ihr in dem Bereich „Das Projekt“.