Enterprise und Big Data
Werbung
FACHARTIKEL Aufbau einer analytischen Pipeline mit Apache Hadoop und XML Enterprise und Big Data Daten werden für Unternehmen immer mehr zu einem wichtigen Rohstoff, um ihre Prozesse und Wettbewerbsvorteile zu verbessern. Bisher werden allerdings hauptsächlich strukturierte Daten analysiert. Jedoch werden laut einer Studie des IDC in den nächsten Jahren lediglich 10 Prozent strukturierte Daten erzeugt – den verbleibenden größeren Teil machen semi- und unstrukturierte Daten wie XML-, JSON-, Bild- und Textdateien aus [Int12]. Häufig liegen diese Daten bereits heute in großen Mengen vor. Diese meist ungenutzten semi- und unstrukturierten Datenmassen bieten Unternehmen enorme Potenziale, um mittels Advanced und Predictive Analytics Wissen und Erkenntnisse zu generieren. Um jedoch diese Daten für Advanced und Predictive Analytics überhaupt nutzbar zu machen, sind neue Technologien wie das Hadoop Ecosystem und NoSQL-Datenbanken entstanden. Dabei kann für mittelständische Unternehmen das Hadoop Ecosystem eine Alternative zu proprietären Softwarelösungen sein, da es als Open-Source-Software gut verfügbar und durch eine entsprechende Community unterlegt ist. Einsatz von Hadoop in Unternehmen im Big-Data-Kontext Die Betrachtung des Hadoop Ecosystem steht oftmals im Zusammenhang mit dem Begriff Big Data. Big Data wird über die 3Vs Volume (Volumen), Velocity (Geschwindigkeit) und Variety (Vielfalt) charakterisiert, wobei das hohe und rasant wachsende Datenvolumen aus der zunehmenden Digitalisierung der Unternehmen resultiert. Hadoop ist ein javabasiertes, skalierbares und verteilt arbeitendes Software-Framework, das auf kostengünstiger Standardhardware betrieben werden kann. Den Kern bildet ein verteiltes Dateisystem, das sogenannte HDFS (Hadoop Distributed Filesystem), um die großen verschiedenartig strukturierten Datenmengen zu speichern. Zudem existieren im Hadoop Ecosystem eine Vielzahl von Tools, wie beispielsweise Hive, Pig oder Spark, um die umfangreichen und verschiedenartig strukturierten Datenmengen in einem hochskalierbaren Cluster zu verarbeiten und zu analysieren. Klassische BI-Systeme wie das Data Warehouse (DWH) stoßen an ihre Grenzen, wenn Unternehmen die ungenutzten Potenziale der heterogenen Datenmengen nutzen wollen. Allerdings sollen die klassischen DWHs von Hadoop nicht ersetzt, sondern ergänzt werden. Hadoop kann dabei als sogenannter Data Lake agieren. Ein Data Lake speichert die Rohdaten, egal in welcher Menge und in welcher Form sie von der Datenquelle erzeugt werden. Die anschließende Aufgabe besteht darin, den meist schemalosen Daten einen Sinn zu geben, um sie in Analysen nutzen zu können. Die daraus resultierenden Ergebnisse lassen sich wieder ins DWH zurückspielen [Dei15; FaM16]. Anwendungszenario Hadoop Ecosystem und XML Im gestellten Anwendungsszenario wird das Hadoop Ecosystem genutzt, um semistrukturierte XML-Dateien zu speichern, zu verarbeiten und zu analysieren, damit das Unternehmen einen Mehrwert aus diesen bisher ungenutzten Daten erzielen kann. Das Anwendungsszenario betrifft ein mittelständisches Unternehmen, das mehrere Tausend Kiosk-Systeme in Eu- ropa besitzt. Ein Kiosk-System ist ein rechnergestütztes Terminalgerät, das meist an öffentlich zugänglichen Orten oder in Einzelhandelsgeschäften steht und als Point of Information (POI) oder Point of Sale (POS) genutzt wird. Beispielsweise können sich Fahrkartenautomaten oder Geldautomaten als Kiosk-System bezeichnet werden. Die Kiosk-Systeme des Anwendungsszenarios erzeugen semistrukturierte XML-Dateien. Diese können von wenigen Kilobyte bis zu einigen Megabyte groß sein. In Summe entstehen täglich rund 10 GB XML-Dateien, was auf einen Monat hochgerechnet etwa 300 GB Datenvolumen bedeutet. Inhalt dieser Daten sind beispielsweise Metadaten des Kiosk-Geräts sowie die Interaktion des Nutzers mit dem Gerät. Großes Interesse hat das Unternehmen an der Reduktion von Ausfallzeiten und der frühzeitigen Erkennung von Defekten der Kiosk-Geräte. Durch technische Informationen in den Metadaten kann versucht werden, Defekte der KioskGeräte im Sinne frühzeitig vorherzusagen, um dadurch Ausfallzeiten zu reduzieren. Dieser Bereich wird als Predictive Maintenance bezeichnet. Problemstellung und Umsetzung des Anwendungsszenarios Das Problem ist die semistrukturierte Form der Daten, wodurch diese nicht direkt für Analysen nutzbar sind. Somit müssen diese zunächst strukturiert werden. In diesem Anwendungsszenario soll das Hadoop Ecosystem als mögliche Lösung untersucht werden. In Abbildung 1 ist die entstandene Systemarchitektur für das Anwendungsszenario dargestellt, mit dem die XML-Dateien für Analysen nutzbar gemacht werden konnten. Dabei wurde mit Hilfe der Tools im Hadoop Ecosystem und Eigenentwicklungen ein Extract, Load and Transform (ELT-)Prozess entwickelt [Dmi15]. Die Komponenten aus Abbildung 1 sollen im Folgenden kurz erläutert werden: 1. Datenquelle FTP-Server: Die Datenquelle ist ein zen­ traler FTP-Server, der die XML-Dateien im Minutentakt von den Kiosk-Geräten erhält. 2. Datenimport AXT (Eigenentwicklung): Für das Extrahieren der XML-Dateien vom FTP-Server und Laden ins HDFS (Extract & Load) wurde AXT (Agent for XML ONLINE -THEMENSPECIAL PREDICTIVE & ADVANCED ANALYTICS 01 FACHARTIKEL Transportation), eine javabasierte Eigenentwicklung, implementiert. 3. Datenspeicher XMLDateien HDFS: Die unbearbeiteten XML-Dateien sollen zunächst im HDFS, das hier als ­Data Lake fungiert, gespei­ chert werden. 4. Verarbeiten (Parsen) der XML-Dateien: Zum Parsen der XML-Dateien wurde eine Python-basierte Eigenentwicklung implementiert. Um den Parser verteilt und parallel auf den Daten auszuführen, kommen die zwei Technologien Spark und Hadoop Streaming zur Anwendung. Das Ergebnis des Parsing-Prozesses sind strukturierte CSV-Dateien. Abb. 1: Gesamt­architektur für das Anwendungs­szenario 5. Strukturierte Speicherung der geparsten Daten: Die strukturierten CSV-Da- heiten bei der Bearbeitung von XML-Dateien eingegangen teien sollen in das modellierte Hive-Datenbankschema werden, die eine wesentliche Rolle bei der Speicherung und importiert werden. Für den Import von CSV-Dateien Verarbeitung in einem Hadoop Cluster spielen. in Hive wurde eine javabasierte Eigenentwicklung Valide XML-Dateien erfordern die Einhaltung der implementiert. XML-Syntax, die zum Beispiel vorschreibt, dass jedes 6. Verwendete Analytics-Tools: Die im Hive-Datenbank- XML-Dokument mit einem öffnenden Root-Element beschema strukturiert vorliegenden Daten wurden direkt ginnt und jedes öffnende Element auch wieder geschlossen mit der SQL-ähnlichen Abfragesprache HiveQL (De- werden muss. Dies impliziert, dass jedes XML-Dokument scriptive Analytics) und der Machine Learning Library mit einem schließenden Root-Element enden muss. Daraus (MLlib) von Spark (Advanced Analytics) analysiert. lässt sich eine Unteilbarkeit von XML-Dateien ableiten. Ein 7. Tool zur Visualisierung: Für die explorative Erfor- XML-Dokument, das die Syntax erfüllt, wird als wohlgeschung der im Hive-Datenbankschema strukturierten Da- formt bezeichnet. ten und zur Visualisierung der Ergebnisse aus den AnaEin weiterer wichtiger Punkt: Das HDFS ist für Dateien lysen wurde das Tool Apache Zeppelin aus dem Hadoop mit Größen im Bereich zwischen Giga- und Terabyte entwiEcosystem genutzt. ckelt worden [Apa16a]. Das gestellte Anwendungsszenario 8. Anbindung klassischer relationaler Datenquellen wie beinhaltet jedoch viele kleine Dateien. Die daraus resuldem DWH: Für den Austausch von Daten mit relatio- tierenden Probleme und Hürden werden ersichtlich, wenn nalen Datenquellen wie einem DWH ist das Tool Sqoop der Datenzugriff über das HDFS betrachtet wird. Dateien aus dem Hadoop Ecosystem benutzt worden. Analysen werden im HDFS standardmäßig in 64-MB-Blöcken geim Hadoop Ecosystem konnten mit Daten aus dem DWH speichert [Apa16A]. Wie bereits erwähnt, ist der Kern von angereichert werden und die Ergebnisse der Analysen Hadoop das MapReduce-Paradigma. Bei einem Dateizuzurück ins DWH übertragen werden (wie im Data-Lake- griff wird für jeden Block einer Datei ein eigener Map Task Ansatz beschrieben). erstellt. Wenn eine 1 GB große Datei gespeichert wird, teilt 9. Workflowmanagement-Tool für den ELT-Prozess: Für das HDFS diese Datei in 16 Blöcke zu je 64 MB. Bei einem das täglich automatisierte Ausführen des ELT-Prozesses Lesezugriff werden somit 16 Map Tasks benötigt. wurde Apache Airflow aus dem Hadoop Ecosystem beWas aber passiert, wenn diese 1 GB nicht als eine einnutzt. Airflow bietet eine Web-Oberfläche, über die das zelne Datei, sondern als zum Beispiel 10.000 Dateien zu je Sheduling und Monitoring des Prozesses möglich ist. 100 KB abgelegt werden? Das HDFS erkennt, dass 100 KB kleiner sind als 64 MB. Eine Aufteilung einer 100-KB-Datei in mehrere Blöcke ist offensichtlich nicht nötig. Stattdessen Besonderheiten bei der speichert das HDFS diese kleine Datei in einem einzelnen Verarbeitung von XML-Dateien Block. Zu beachten ist, dass, obwohl der Block 64 MB groß Vor der detaillierten Beschreibung der Probleme und Um- sein darf, nicht noch weitere Dateien in diesem Block gesetzung des ETL-Prozess mit Hadoop soll auf die Besonder- speichert werden können. Allerdings ist darauf hinzuweisen, 02ONLINE-THEMENSPECIAL PREDICTIVE & ADVANCED ANALYTICS FACHARTIKEL dass nicht die vollen 64 MB des Blocks allokiert werden, sondern nur die tatsächliche Größe der zu speichernden Datei, hier also 100 KB. Der Block dient vielmehr als Hilfsmittel, um die Datei wiederzufinden. Diese Art der Speicherung wird für jede der 10.000 Dateien durchgeführt. Soll nun 1 GB in Form von 10.000 Dateien gelesen werden, wird wieder für jeden Block ein Map Task benötigt, hier also 10.000 Tasks. Dieses Beispiel zeigt, dass es, obwohl in beiden Fällen die gleiche Datenmenge von 1 GB geladen wird, massive Unterschiede in der Anzahl der auszuführenden Tasks gibt und somit auch Unterschiede in der Performance. Dies zeigt deutlich die Ausrichtung des HDFS auf große Dateien und die signifikante Verschlechterung im Umgang mit kleinen Dateien. In einem Artikel von Cloudera werden Möglichkeiten genannt, die zuvor beschriebenen Probleme zu umgehen [Whi14]. Ein Ansatz besteht darin, mit HAR-Dateien des Hadoop-Archivs viele kleine Dateien zu einer großen Datei zusammenzufassen. Dies hat zur Folge, dass ein weiterer Layer über das HDFS gezogen werden muss, über den dann die Dateizugriffe erfolgen. Dieser Layer ist in der Lage, aus den HAR-Dateien eine einzeln angefragte Datei zu extrahieren. Um einen weiteren Layer zu vermeiden, werden im vorliegenden Anwendungsszenario die vielen kleinen XMLDateien vor der Speicherung zusätzlich in größere Dateien zusammengefasst. Es werden somit die originalen Dateien sowie die zusammengefassten, für die Verarbeitung optimierten Dateien abgelegt. Diese zusammengefassten Dateien werden nur für die Weiterverarbeitung benötigt und anschließend gelöscht, um Speicherplatz zu sparen. Hadoop fungiert für die originalen Dateien im Rahmen des ­Data ­Lake als Rohdaten-Archiv. Import und Speicherung der XML-Dateien im HDFS Der Import der Dateien in das HDFS lässt sich über die Schritte Extract und Load des ELT-Prozesses realisieren. Die Datenquelle, von der die XML-Dateien bezogen werden, stellt ein FTP-Server dar (Abbildung 1, Komponente 1). Das Zielsystem ist das HDFS. Um nun ein Tool zu finden, das als Schnittstelle dieser beiden Systeme fungieren kann, wurden diverse Werkzeuge am Markt, wie Storm, Fluentd, Kafka und Flume, evaluiert. Dabei ist insbesondere Apache Flume hervorzuheben, da es eine Standardkomponente des Hadoop Ecosystem ist. Im Rahmen der Evaluierung von Flume sind jedoch gravierende Probleme mit der Verarbeitung von XML-Dateien aufgetreten. Das Kernproblem besteht in der chunk- oder zeilenbasierten Verarbeitung von Flume-Dateien. Flume generiert für jeden gelesenen Chunk oder Zeile ein Event. Dabei werden jedoch die Events unter Umständen nicht in der eingelesenen Reihenfolge an das HDFS geschickt. Bei der Übertragung von XML-Dateien ist die Reihenfolge der Zeilen entscheidend, um ein wohlgeformtes XML im HDFS zu erhalten. Durch die Entwicklung eines Deserialisers wurde versucht, die gelesenen Chunks bzw. Zeilen zusammenzufassen und das Ende einer Datei zu erkennen. Erst wenn eine vollständige Datei „gesammelt“ wurde, wird ein Event generiert, das ins HDFS geschrieben wird. Dieser Ansatz war allerdings ebenfalls erfolglos. Dies liegt an dem standardmäßig implementierten RolloverVerhalten von Flume. Im HDFS wird eine Zieldatei konfiguriert, die beispielsweise 100 MB groß ist. Die im H ­ DFS ankommenden Events, also die Dateien, werden dieser Zieldatei so lange angehängt, bis 100 MB erreicht sind. Anschließend wird ein Rollover ausgeführt und die nächste Datei erstellt. Durch diesen Rollover besteht wiederum die Gefahr, nicht wohlgeformtes und somit nutzloses XML zu produzieren. Aufgrund dieser Evaluation wurde eine javabasierte Eigenentwicklung implementiert, die Dateien als Ganzes bearbeiten und im HDFS ablegen kann. Diese Eigenentwicklung wird intern als AXT bezeichnet und ist in Abbildung 1 als Komponente 2 zu sehen. Parallel dazu konkatiniert diese Eigenentwicklung auch Dateien, um so größere, für das Hadoop-System besser zugängliche Dateien zu schaffen. Um einen hohen Datendurchsatz zu erreichen, wurde das Programm Multithread-fähig entwickelt und ist über eine Konfigurationsdatei frei konfigurierbar und in unterschiedlichen Systemen einsetzbar. Über diese Konfigurationsdatei lässt sich auch die Größe der konkatinierten Datei einstellen. Mit dieser Einstellung kann nun weiter experimentiert werden, um für das entsprechende Hadoop-Cluster die optimale Dateigröße zu ermitteln. Strukturierung (Transformation) der XML-Daten in Hive Um die semistrukturierten Daten für Analysen nutzbar zu machen, sollten diese strukturiert werden. Hierzu wurde ein relationales Hive-Datenbankschema entwickelt, in das die XML-Dateien transformiert werden sollen. Hive ist ein SQL-Layer auf dem HDFS und bietet die Möglichkeit, Daten verteilt in Tabellen zu speichern und mit SQL abzufragen [Thu09]. Zunächst wurde ein möglichst flexibles relationales Schema konzipiert, das die XML-Dateien größtenteils widerspiegelt. Da nicht alle Informationen aus der XMLDatei nützlich sind oder nützlich erscheinen, wurden nur die potenziell nützlichen Informationen strukturiert. Um zukünftige interessante Informationen nachträglich aufnehmen zu können, sollen das Datenbankschema und auch der Parser möglichst flexibel sein. Für die Erstellung des Datenbankschemas mussten einige XML-Dateien manuell betrachtet werden. Zudem wurden dabei die potenziell nützlichen Informationen identifiziert, die strukturiert werden sollten. Transformation der semistrukturierten Daten mit Spark und Hadoop Streaming Damit die nützlichen Informationen aus den XML-Dateien strukturiert werden können, wurde ein Python-basierter XML-Parser entwickelt. Der XML-Parser basiert auf dem SAX-Ansatz. Ein Kernelement des Parsers ist eine ConfigDatei, in der gepflegt wird, welche Inhalte der XML-Datei geparst werden. Entdeckt ein Data Scientist bei der explorativen Erforschung der Rohdaten eine weitere potenziell nützliche Information in den XML-Rohdateien, kann diese ONLINE -THEMENSPECIAL PREDICTIVE & ADVANCED ANALYTICS 03 FACHARTIKEL Abb. 2: Transformation der semistrukturierten Daten mit Spark und Hadoop ­Streaming in der Konfiguration eingepflegt und mit den nächsten ELTProzessen strukturiert werden, um sie für Analysen nutzbar zu machen. Für das verteilte und parallele Parsen der XML-Dateien im Hadoop-Cluster wurden Hadoop Streaming und Apache Spark benutzt. Beide Varianten werden im Folgenden erläutert (siehe Abbildung 2). ÂÂ Hadoop Streaming: Hadoop Streaming ist in den Kernfunktionalitäten von Hadoop enthalten. Es basiert auf dem klassischen MapReduce-Ansatz. Mit Hadoop Streaming können Map- und Reduce-Jobs mit ausführbaren Programmen oder Skripten als Mapper und Reducer ausgeführt werden. Der Austausch der Daten zwischen Map- und ReducePhase findet über STDIN und STDOUT statt [Apa16B]. Für das Anwendungsszenario wurde ein Python-basiertes Mapper-Skript implementiert, das den XML-Parser beinhaltet und die definierte relationale Struktur in Form von Key-Value-Paaren (Key = Tabellenname; Value = Tabellenzeile im CSV-Format) als Output an den Reducer übergibt. Der Reducer ist ein Python-basiertes Skript, das die gesamten Key-Value-Paare in CSV-Dateien im HDFS persistiert. Anschließend werden die CSV-Dateien durch eine javabasierte Eigenentwicklung in das Hive-Datenbankschema importiert. ÂÂ Apache Spark: Apache Spark ist ein In-Memory ClusterComputing Framework. Spark kann als Stand-alone betrieben werden, üblicher ist jedoch die Einbettung in das Hadoop Ecosystem. Spark bietet Java-, Scala-, Pythonund R-APIs. Weiterhin stellt es Komponenten wie Spark SQL zur Verfügung, um strukturierte Daten zu verarbeiten, und eine Machine Learning Library (MLlib) [Zah12]. Für das Anwendungsszenario wurde die Python-API benutzt. Dazu wurde ein Python-basiertes Spark-Programm entwickelt, das die XML-Dateien aus dem HDFS in den Arbeitsspeicher lädt. Anschließend wird mittels LambdaExpression der XML-Parser auf die Dateien angewandt und die geparsten Ergebnisse in CSV-Dateien im HDFS gespeichert. Die CSV-Dateien werden anschließend mit einer javabasierten Eigenentwicklung in die entsprechenden Hive-Tabellen des Datenbankschemas geladen. Während der Entwicklung mit Apache Spark traten häufig „Executor-Lost“-Fehler auf. Diese Fehler werden ausgelöst, wenn das Spark-Programm mehr als den vorhandenen Arbeitsspeicher allokiert. Hier wurde während der Entwicklung viel ausprobiert, um das Spark-Programm unabhängig vom verfügbaren Arbeitsspeicher lauffähig zu machen. Beide implementierten Lösungen, sowohl Hadoop Strea­ ming als auch Spark, funktionieren und lassen sich zum Parsen von XML-Dateien im Hadoop-Cluster verwenden. Hadoop Streaming erwies sich als die robustere und stabilere Lösung, wohingegen Spark die deutlich performantere Lösung der beiden ist. Bei einer zu parsenden Datenmenge von ca. 10 GB unter gleichen Hardwarebedingungen war Spark rund 50 Prozent schneller als die Hadoop-Streaming-Lösung. Predictive Maintenance Die mit dem ELT-Prozess strukturierten Daten können nun für die Analysen genutzt werden. Mit Hilfe von Apache Zeppelin und Hive wurden deskriptive Analysen durchgeführt. Um den Bereich Predictive Maintenance mit AdvancedAnalytics-Verfahren umzusetzen, wurde die Spark MLlib genutzt. Sie bietet neben statistischen Funktionalitäten für das Verstehen der Daten auch viele Machine-Learning-Algorithmen. Hierzu zählen Algorithmen für die Aufgaben der Assoziationsanalyse, das Clustering und die Klassifikation [Apa16C]. Oftmals existieren in Unternehmen bereits Reporting- und Data-Mining-Systeme. Diese lassen sich weiterhin nutzen, um über den HDBC-Treiber auf die strukturierten Daten aus dem Hive-Datenbankschema zuzugreifen. An dieser Stelle setzen die standardisierten Analyseprozesse wie CRISP-DM der Unternehmen an, nachdem die semistrukturierten Daten strukturiert wurden. Fazit Um zu untersuchen, ob das Hadoop Ecosystem eine OpenSource-Alternative zu proprietärer Big-Data-Software darstellen kann, wurde für ein Anwendungsszenario eines mittelständischen Unternehmens eine entsprechende System­architektur aufgebaut, um Informationen aus bestehenden XML-Dateien zu extrahieren und zu analysieren. Da bereits bei der Übertragung der Quelldateien ins HDFS kein am Markt etabliertes Werkzeug überzeugen konnte, wurde für den Transformprozess ein Python-basierter SAX-XMLParser entwickelt. Dabei wurde festgestellt, dass Hadoop Streaming eine deutlich robustere, wenn auch langsamere Variante zu Apache Spark darstellt. Letztlich konnten jedoch über beide Varianten die benötigten Informationen aus den XML-Dateien extrahiert und in ein erstelltes relationales Zielschema in Hive überführt werden. Somit konnte gezeigt werden, dass mittelständische Unternehmen das Hadoop Ecosystem für analytische Fragestellungen einsetzen können. Der Aufwand bringt zwar einen gewissen Teil an Eigenentwicklung mit sich, ist jedoch beherrschbar, und ebenso ist schnell ein Nutzen zu erzielen. 04ONLINE-THEMENSPECIAL PREDICTIVE & ADVANCED ANALYTICS FACHARTIKEL [ Literatur ] [Apa16a] Apache Software Foundation: HDFS Architecture. https://hadoop.apache.org/docs/r2.7.3/hadoopproject-dist/hadoop-hdfs/HdfsDesign.html, abgerufen am 4.10.2016 [Apa16b] Apache Software Foundation: Apache Hadoop MapReduce Streaming. https://hadoop.apache.org/docs/ r2.7.3/hadoop-streaming/HadoopStreaming.html, abgerufen am 4.10.2016 [Apa16c] Apache Software Foundation: MLlib: RDD-based API. http://spark.apache.org/docs/latest/mllib-guide.html, abgerufen am 4.10.2016 [Dei15] Deininghaus, J.: Welche Chancen Big Data für traditionelle BI-Architekturen birgt: Die BI-(R)Evolution. In: BI-Spektrum, Nr. 01/2015, S. 8–10 [Dmi15] Dmitriyev, V. / Mahmoud, T. / Marín-Ortega, P.: SOA enabled ELTA: approach in designing business intelligence solutions in Era of Big Data. In: International Journal of Information Systems and Project Management, Nr. 3, 2015, S. 49–63 [FaM16] Fasel, D. / Meier, A.: Big Data: Grundlagen, Systeme und Nutzungspotenziale. Springer-Verlag 2016 [Int12] Intel IT Center: Einführung in Big Data: Die Analyse unstrukturierter Daten. http://www.intel.de/content/dam/ www/public/emea/de/de/pdf/unstructured-data-analyticspaper.pdf, abgerufen am 4.10.2016 [Thu09] Thusoo, A. et al.: Hive: a warehousing solution over a map-reduce framework. In: Proceedings of the VLDB Endowment, Bd. 2, VLDB Endowment 2009, S. 1626–1629 [Whi14] White, T.: The Small Files Problem. http://blog. cloudera.com/blog/2009/02/the-small-files-problem/, abgerufen am 4.10.2016 [Zah12] Zaharia, M. et al.: Resilient distributed datasets: A fault-tolerant abstraction for in-memory cluster computing. In: Proceedings of the 9th USENIX conference on Networked Systems Design and Implementation. USENIX Association, 2012, S. 2 Prof. Dr.-Ing. Jorge Marx Gómez studierte Technische Informatik und Wirtschaftsingenieurwesen an der Technischen Fachhochschule Berlin. Anschließend war er als Entwicklungsingenieur für digitale Übertragungs- und Vermittlungstechnik in der Wirtschaft tätig. 2001 promovierte er am Institut für Technische und Betriebliche Informationssysteme der Ottovon-Guericke-Universität Magdeburg, wo er auch Wissenschaftlicher Assistent war und sich 2004 habilitierte. Von 2002 bis 2003 vertrat Marx Gómez, der auch Honorarprofessor der Universidad Central „Marta Abreu“ in Kuba ist, die Professur für Wirtschaftsinformatik an der TU Clausthal. Gastdozenturen und Lehraufträge führten ihn unter anderem nach Moskau (Russland), Havanna (Kuba) und Berlin. Zudem war er in zahlreichen nationalen und internationalen Forschungsprojekten tätig. Seit 2006 ist Marx Gómez Professor für Wirtschaftsinformatik am Department für Informatik der Universität Oldenburg. Seine Forschungsschwerpunkte sind unter anderem Betriebliche Umweltinformationssysteme, Föderierte ERP-Systeme, Adaptive Lehr- und Lernsysteme, Business Intelligence und Big Data. E-Mail: [email protected] Viktor Dmitriyev studierte Informatik an der Kasachisch-Britischen Technischen Universität in Almaty. Seit 2014 ist Viktor Dmitriyev Wissenschaftlicher Mitarbeiter in Lehre und Forschung an der Abteilung Wirtschaftsinformatik / Very ­Large Business Applications (VLBA) am Department für Informatik der Universität Oldenburg. Seine Forschungsschwerpunkte sind unter anderem Big Data, Business Intelligence, Datenbanksysteme und In-Memory Computing. E-Mail: [email protected] Hauke Precht absolvierte ein duales Studium der Wirtschaftsinformatik (Bachelor) an der IBS Oldenburg. Seit zwei Jahren arbeitet er als Junior Engineer bei der BTC AG und ist im Bereich Softwareentwicklung tätig. Parallel studiert er an der Carl von Ossietzky-Universität Oldenburg Informatik im Masterstudiengang. Er ist besonders an technischen Umsetzungen interessiert und richtet den Fokus auf die Entwicklung im Big-Data- und Analytics-Umfeld. Durch ein einjähriges Uni-Projekt sammelte er erste Erfahrungen im Bereich Hadoop. E-Mail: [email protected] Felix Kruse absolvierte ein duales Bachelorstudium der Wirtschaftsinformatik an der IBS Oldenburg. Seit zwei Jahren arbeitet er im Bereich Business Intelligence bei der Oldenburgischen Landesbank AG und studiert parallel an der Carl von Ossietzky-Universität Oldenburg im Studiengang Master of Science Wirtschaftsinformatik mit Schwerpunkt Business Intelligence. Durch ein einjähriges Uni-Projekt mit einem Unternehmenspartner sammelte er erste Erfahrungen im Bereich Hadoop und Big Data (Analytics). E-Mail: [email protected] ONLINE -THEMENSPECIAL PREDICTIVE & ADVANCED ANALYTICS 05
