Verteilte Visualisierung für datenintensive wissenschaftliche Experimente

Größe: px
Ab Seite anzeigen:

Download "Verteilte Visualisierung für datenintensive wissenschaftliche Experimente"

Transkript

1 Verteilte Visualisierung für datenintensive wissenschaftliche Experimente BACHELORARBEIT für die Prüfung zum Bachelor of Engineering des Studiengangs Informationstechnik an der Dualen Hochschule Baden-Württemberg Mannheim von Patrick Neuberger Bearbeitungszeitraum: 12 Wochen ( ) Matrikelnummer Kurs: Ausbildungsfirma: Betreuer der Ausbildungsfirma : Gutachter der Dualen Hochschule: TIT07AIN Karlsruher Institut für Technologie Dipl. Ing. Thomas Jejkal Prof. Dr. Jochem Poller

2 Erklärung gemäß 5 (2) der Studien- und Prüfungsordnung DHBW Technik vom 18. Mai Ich habe die vorliegende Arbeit selbstständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel verwendet. Karlsruhe, 20. September 2010 Patrick Neuberger

3 Zusammenfassung Heutige wissenschaftliche Projekte erzeugen bei ihren Messungen mehrere Gigabyte an Daten für einzelne Experimente. Diese Menge können die Wissenschaftler vor Ort nicht speichern und verwalten. Zur Lagerung solcher großen Datenmengen wird am Karlsruhe Institut für Technologie ein Datenzentrum aufgebaut, welches sowohl genügend Speicherkapazitäten für wissenschaftliche Projekte bereitstellen soll, aber auch Methodiken für die Verwaltung und den Zugriff auf die Daten. Realisiert wird dies in der Large Scale Data Facility (LSDF). Neben der Speicherung benötigen die Wissenschaftler auch Softwarelösungen mit denen sie auf der LSDF abgelegte Daten visualisieren können. Hierzu ist an die LSDF hochperformant eine Computing Infrastruktur angebunden. Das Ziel dieser Bachelorarbeit war es, ein Konzept für die verteilte Visualisierung im Zusammenspiel der LSDF und der Computing Infrastruktur zu entwerfen und zu implementieren. Das Konzept zielt darauf ab, dem Nutzer möglichst schnell ein Ergebnis der Visualisierung anzuzeigen. Zur schnellen Darstellung von Ergebnissen wird lokal mit geringer Auflösungen eine Visualisierung durchgeführt, während auf der Computing Infrastruktur die Daten mit der maximalen Auflösung berechnet werden. Nach der Implementierung des Konzepts in Java mit der Hadoop API wird die benötigte Zeit der einzelnen Visualisierungen mit einem Mikroskopiedatensatz evaluiert. Dabei wird der Datensatz mit maximale Auflösung, das implementierte Konzept mit drei niedrigen Auflösungen lokal visualisiert und der Datensatz mit maximale Auflösung auf der Computing Infrastruktur berechnet. Es zeigt sich, dass durch das entwickelte Konzept dem Nutzer unmittelbar nach dem Start der Visualisierung ein erstes Ergebnis angezeigt werden kann. Ebenso konnte durch das Einblenden neuer Details eine Vorschaufunktion bereitgestellt werden, mit dem die Wissenschaftler eine Vorauswahl ihrer Daten treffen können.

4 Abstract Nowadays scientific projects produce during their measurements several gigabyte of data for one experiment. Such amounts of data scientists can not store or manage on local systems. The Karlsruhe Institute of Technology develops a data facility which can handle this massive amounts of experimental data. The Large Scale Data Facility (LSDF) will provide not only enough storage capacities, it will also provide methods for data access und management. The scientists also need a software solution to visualize their data on the LSDF. For this purpose there is a computing infrastructure with high performance connection to the LSDF. The aim of this bachelor thesis was to design and implement a concept for a distributed visualization in an interaction between the LSDF and the computing infrastructure. The concept has the ambition to present a result image of the visualization in a short term of waiting. To produce first results immediately there will be two different kinds of visualizations. A local one with low resolution image stacks and a distributed one with high resolution on the computing infrastructure. After the implementation of the concept in Java using the Hadoop API the visualization time will be evaluated with a microscopy data set. The evaluation shows the duration for a local visualization with a maximum resolution image stack and the local visualization of the implemented concept by processing three low resolution image stacks. The distributed visualization will process the maximum image stack on the computing infrastructure. It turns out that the designed concept shows the first results directly after starting the visualization. And with the fade in of new details into the presented image, the implemented software provides a preview function to the scientists with which they can make a pre selection of their data.

5 Inhaltsverzeichnis Abkürzungsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis iii iv v 1 Einführung Motivation Ziele Stand der Technik Large Scale Data Facility ADALAPI Datenorganisation Computing Infrastruktur Hadoop Visualisierungslösungen V3D OMERO Fiji Eigenentwicklung Konzept für die verteilte Verarbeitung Grundprinzip Konzeptbeschreibung Prozesse i

6 Inhaltsverzeichnis Kommunikation Implementierung des Konzepts Konfiguration der Visualisierung Anpassung des Image Stack Aufbaus Steuersoftware und lokale Visualisierung Verteilte Visualisierung Aufbau der Parameter Implementieren des MapReduce Workflows JobPilot Projektion und Komposition Evaluierung Messumgebung Synapsen Datensatz Ablauf der Messung Testergebnisse Zusätzliche Ergebnisse Diskussion und Ausblick 43 Literaturverzeichnis A ii

7 Abkürzungsverzeichnis MB Megabyte GB Gigabyte TB Terabyte PB Petabyte LSDF Large Scale Data Facility KIT Karlsruher Institut für Technologie ITG Institut für Toxikologie und Genetik LFC Logical File Catalog LDC Logical Directory Catalog LPC Logical Project Catalog ADALAPI Abstract Data Access Layer Application Programming Interface HDFS Hadoop Distributed File System IPE Institut für Prozessdatenverarbeitung und Elektronik OME Open Microscopy Environment MIP Maximum Intensity Projection JAR Java Archive HHMI Howard Hughes Medical Institute iii

8 Abbildungsverzeichnis 2.1 Gesamtaufbau der LSDF im Modell Workflow des MapReduce-Modells Vereinfachter Aufbau der OMERO Client-Server Architektur Räumliche Struktur welche in der Datenstruktur abgebildet wird Kommunikation innerhalb des entwickelten Konzepts Vergleich fehlerhafter und korrekter Stackaufbau Projektion eines Ausschnittes von 3 2 Fields des Synapsen- Datensatzes Z-Projektion eines Image Stacks des Zebrafisch-Datensatzes iv

9 Tabellenverzeichnis 5.1 Ergebnis der lokalen Projektion des kompletten Image Stacks Ergebnis der lokalen Projektion für den Image Stack nach dem entwickelten Konzept Ergebnis der lokalen Projektion für den Image Stack nach dem entwickelten Konzept Ergebnis der lokalen Projektion für den Image Stack nach dem entwickelten Konzept Ergebnis der verteilten Projektion für den Image Stack nach dem entwickelten Konzept v

10 1 Einführung Wissenschaftliche Projekte erzeugen mit ihren Experimenten immer größere Datenmengen. Diese können sich für einzelne Experimente auf mehrere hundert Gigabyte (GB) belaufen. So erzeugt ein einzelnes Projekt mehrere Terabyte (TB) an Daten pro Jahr. Diese Speicherkapazitäten können lokal nicht von den Wissenschaftlern bereitgestellt werden. Ebenso müssen gemessene Daten für mindestens zehn Jahre gespeichert werden, da in Deutschland der Gesetzgeber für wissenschaftlich publizierte Daten diese Speicherdauer vorschreibt. Die Experimente erzeugen bei ihren Messungen unterschiedliche Arten von Dateistrukturen. Einige Projekte generieren viele tausende kleine und andere hingegen wenige große Dateien. Zum Verwalten von vielen tausenden kleinen Dateien gibt es keine Standardlösungen, welche angewendet werden könnten. Die Experimentdaten wollen viele Projekte mit Kooperationspartner rund um die Welt austauschen können. Dafür wird ein weltweiter Zugriff auf die Daten benötigt. Der Zugriff soll hierbei sicher sein, damit Daten nicht gelöscht oder verfälscht werden. Dazu müssen gängige Sicherheitsstandards eingesetzt werden. Zur möglichen Lösung dieser Anforderungen, wird zur Zeit am Karlsruher Institut für Technologie (KIT)[1] ein Datenzentrum für wissenschaftliche Experimentdaten aufgebaut. Dieses Datenzentrum soll für europäische Forschungsprojekte ausreichend Speicherkapazitäten bereitstellen. Realisiert wird dieses in einer Large Scale Data Facility (LSDF)[2]. Bis zum Ende des Jahres 2010 wird die LSDF eine Gesamtkapazität von 6 Petabyte (PB) bereitstellen. Sie wird neben der Speicherkapazität auch Zugriffs- und Datenmanagementverfahren zur Verfügung stellen. 1

11 1.1. MOTIVATION 1.1 Motivation Am Institut für Toxikologie und Genetik (ITG)[3] untersuchen Wissenschaftler biologische Prozesse in lebendem Gewebe. Eines dieser Projekte beschäftigt sich mit der Untersuchung von Synapsen in Mäusemuskeln und ein weiteres mit der Embryoentwicklung von Zebrafischen. Hierzu nutzen beide Projekte ein bildgebendes Verfahren, mit dem Volumendaten von dreidimensionalem Gewebe in Form von Schichtbildern aufgenommen werden. Dieses Verfahren wird als Hochdurchsatz Mikroskopie bezeichnet und nutzt zur Aufnahme ein Robotermikroskop. Mittels Fokussierung kann das Mikroskop die einzelnen Schichten des Gewebes erfassen und aufnehmen. Zur Hervorhebung von unterschiedlichen Gewebebereichen können Kontrastmittel eingebracht werden. Dabei werden die aufgenommenen Schichten mit entsprechenden Farbkanälen in Bildern abgespeichert. Bei der Durchführung einer solchen Mikroskopie kann eine Datenrate von ca. 270 MB/s erreicht werden. Einzelne Experimente können so Datensätze mit bis zu 300 GB erzeugen. Beide Projekte nutzen bereits die LSDF für die Lagerung ihrer Experimentdaten. Neben der Datenhaltung möchten die Wissenschaftler ihre aufgenommenen Daten betrachten können. Dazu müssen die Daten vor der Betrachtung visualisiert werden. Zur Verarbeitung von Experimentdaten wird nahe an der LSDF eine Computing Infrastruktur bereitgestellt. Sie besteht aus mehreren Rechen- und Speicherressourcen, welche hochperformant an die LSDF angebunden sind. Mit der Computing Infrastruktur sollen große Datenmengen parallel verarbeitet werden können, damit die dafür benötigte Zeit möglichst gering gehalten wird. Die standardmäßig eingesetzten Visualisierungslösungen der Wissenschaftler sind dafür nicht konzipiert, da sie nur mit lokal verfügbaren Daten umgehen können. Ebenso wird keines von den LSDF bereitgestellten Zugriffsprotokolle unterstützt. Das Visualisieren der abgelegten Experimentdaten hat des Weiteren die Herausforderung, dass lokales Berechnen von Ergebnissen mit den Standardlösungen nicht möglich ist. Die aufgenommenen Datenmengen überschreiten hierbei die im Hauptspeicher und Grafikkartenspeicher vorhandenen Kapazitäten. 2

12 1.2. ZIELE Für die Visualisierung ihrer abgelegten Experimentdaten haben sich die Wissenschaftler des ITG dafür entschieden, die an der LSDF angebundene Computing Infrastruktur zu nutzen. 1.2 Ziele Das Ziel dieser Bachelorarbeit ist es, die auf der LSDF abgelegten Mikroskopie- Datensätze durch die angebunde Computing Infrastruktur zu visualisieren. Dabei soll zunächst geprüft werden, ob die in der Biologie verwendete Visualisierungslösungen für den Einsatz im Umfeld der LSDF und der Computing Infrastruktur in Frage kommen. Nach der Analyse soll ein Konzept erarbeitet werden, welches definiert, wie die verwendete Visualisierung mit der LSDF und der Computing Infrastruktur arbeiten soll. Das Ziel des Konzeptes ist es, die wahrgenommene Zeit des Nutzers, in der er auf das Ergebnis der Visualisierung wartet, zu verringern. Der Nutzer soll dadurch schneller seine Ergebnisse betrachten können. Es soll den Wissenschaftlern ermöglicht werden, schnell aus den visualisierten Daten eine Vorauswahl zu treffen. Das aufgestellte Konzept soll im Anschluss mit der verwendeten Visualisierungssoftware implementiert werden. Anhand einer Evaluation soll ermittelt werden, ob die Wartezeit während der Visualisierung für die Wissenschaftler zumutbar ist. 3

13 2 Stand der Technik Das folgende Kapitel beschreibt die Technologien für die Datenhaltung, welche durch die LSDF realisiert wird. Des Weiteren wird auf die Computing Infrastruktur eingegangen, welche an die LSDF angebunden ist. Zum Visualisieren von biologischen Daten gibt es unterschiedliche Softwarepakete. Um einen Überblick über die Lösungen aus dem Umfeld der Biologie zu erhalten werden in diesem Kapitel einige dieser Lösung aufgezeigt. 2.1 Large Scale Data Facility Bei der LSDF handelt es sich um ein Datenzentrum, welches zum einen Speicherkapazitäten und zum anderen Methoden für den Datenzugriff und die - verwaltung zur Verfügung stellt. Dabei wird sie für die Haltung wissenschaftlicher Experimentdaten aus europäischen Forschungsprojekten konzipiert. Zur Gewährleistung der Langzeitverfügbarkeit besteht die LSDF aus verschiedenen Speichertypen, welche in Abbildung 2.1 in der rechten oberen Ecke dargestellt sind. Zum einen gibt es den Online-Speicher, welcher für den interaktiven Zugriff auf die Daten verwendet wird. Er besteht aus verteilten Plattenspeichern, welche einen schnellen Zugriff auf die Daten erlaubt. Für die Archivierung wird ein Bandspeicher verwendet. Dabei werden Daten, auf die nur noch selten oder gar nicht mehr zugegriffen wird, auf den Bandspeicher ausgelagert. Im Gegensatz zum Online-Speicher bietet der Bandspeicher nicht die Möglichkeit interaktiv auf die Daten zuzugreifen, da das Auslesen vom Band nur langsam möglich ist. Will man auf Daten zugreifen, die auf Band ausgelagert sind, müsse diese im Vorfeld auf den Plattenspeicher kopiert werden. Damit keine 4

14 2.1. LARGE SCALE DATA FACILITY Datenverluste durch den Ausfall einzelner Speicherressourcen erfolgen, werden die Daten zusätzlich durch Backups gesichert. Die LSDF wird hierbei einen 24/7-Service zur Verfügung stellen. Die abgelegten Daten werden unterschiedliche Formate und Größen besitzen. Damit für jedes Format und jede Dateigröße ein effizienter Datenzugriff erfolgen kann, wird die LSDF eine Vielzahl von Protokolle unterstützen. Beispielsweise wird GridFTP[4] verwendet, ein Protokoll für den Transfer von großen Dateien. Es erfüllt Sicherheitsaspekte durch die Verwendung von X.509[5] Zertifikaten. Abbildung 2.1: Der Gesamtaufbau der LSDF im Modell. Client Anwendungen können über die bereitgestellten Protokolle auf die LSDF zugreifen oder mit der Hadoop API direkt auf die Computing Infrastruktur. Quelle: Projekt interne Grafik 5

15 2.2. ADALAPI 2.2 ADALAPI ADALAPI[6] steht für Abstract Data Access Layer Application Programming Interface. Sie ermöglicht den Zugriff auf die LSDF, da verschiedene Zugriffsmethoden in einer einzigen Schnittstelle gekapselt wird. Abbildung 2.1 zeigt, dass die ADALAPI die Verbindung des Nutzers mit der LSDF bildet. Für den Datenzugriff wird die Klasse AbstractFile angeboten. Durch die Übergabe einer URL ermittelt das AbstractFile die benötigte Zugriffsmethodik. Dazu verwendet die ADALAPI das in der URL angegebene Protokoll. Alle an das AbstractFile gestellten Operationen leitet dieses an die Implementierung des Protokolls weiter und liefert den resultierenden Rückgabewerte an den Nutzer weiter. Durch die Abstraktion der einzelnen Zugriffsmethoden kann die ADALAPI leicht durch weitere Protokolle erweitert werden. Beim Erzeugen eines AbstractFile kümmert sich die ADALAPI, wenn nötig, um den Verbindungsaufbau. Besteht eine Verbindung, wird diese erkannt und verwendet, statt eine neue Verbindung herzustellen. Für einige Protokolle müssen sich die Nutzer vor einem Verbindungsaufbau authentifizieren. Hierzu stellt die ADALAPI dem Nutzer eine Authentifizierung über Kommandozeile oder einem Eingabedialog bereit. Mit der Klasse AbstractFile können Dateiinformationen wie Lese- und Schreibrechte abgefragt werden. Zum Übertragen von Dateien können einzelne Dateien, aber auch ganze Verzeichnishierarchien transferiert werden. Durch die ADALAPI wird somit der Zugriff über die bereitgestellten Protokolle virtualisiert und durch die Kapselung einheitlich und einfach dargestellt. 2.3 Datenorganisation Die Datenorganisation dient zur Virtualisierung der Dateien. Sie liegt vor der Abstract Data Access Layer Application Programming Interface (ADALAPI) (siehe Abbildung 2.1). Dadurch soll dem Nutzer für einen einfacheren Umgang mit den Daten der physikalische Speicherort nicht mitgeteilt werden. Es kann sein, dass sich dieser zum Beispiel durch das Auslagern auf Band ändert. Ein 6

16 2.4. COMPUTING INFRASTRUKTUR direktes Arbeiten mit den Daten ist so nicht immer möglich. Für die Verwaltung der Daten werden Kataloge verwendet, welche in drei hierarchische Schichten unterteilt sind. Auf unterster Ebene wird der Logical File Catalog (LFC) verwendet. Er übernimmt die Übersetzung eines physikalischen Dateinamens in einen logischen Dateinamen. Der LFC dient dazu die zugrunde liegenden Speichertechnologien zu verbergen, damit LSDF-intern verschiedene Speichersysteme verwendet werden können. Eine neu angelegte Datei wird hierfür in die Datenbank des LFC aufgenommen und der Nutzer erhält den logischen Namen der Datei zurück. Bei der Auslagerung einer Datei von Onlineauf Bandspeicher oder beim Erzeugen von Kopien muss dies im LFC vermerkt werden. Eine Schicht höher wird der Logical Directory Catalog (LDC) verwendet. Hierbei wird durch logische Verzeichnisse ein virtuelles Dateisystem erzeugt, in dem die logischen Dateien gruppiert werden können. An oberster Stelle wird der Logical Project Catalog (LPC) verwendet. Hier beschreiben die Wissenschaftler ihre Projekte in Form von Metadaten. Diese sind dabei nach einem bestimmten Schema aufgebaut und werden im Metadatenspeicher abgelegt. Die meisten Interaktionen der Wissenschaftler, wie zum Beispiel die Suche nach einem Datensatz, wird hierbei vom LPC übernommen. Anhand der Beschreibung des Projekts durch die Metadaten kann dessen logisches Verzeichnis zurückgegeben werden. Dadurch ist der Zugriff auf die Daten möglich. 2.4 Computing Infrastruktur Zur Verarbeitung der Experimentdaten ist eine Computing Infrastruktur an die LSDF angebunden. Die Infrastruktur besteht aus 55 Knoten mit jeweils zwei Intel QuadCore Prozessoren. Jeder Knoten besitzt einen Arbeitsspeicher von 36 GB und zwei 1 TB Plattenspeicher. Das Cluster wird mit der Hadoop Umgebung[7] aufgebaut, wobei dieses auf dem Betriebssystem Scientific Linux 5.5 läuft. Das Hadoop Dateisystem besitzt dabei eine Kapazität von ca. 110 TB. Die LSDF ist über zwei 10 Gbit Verbindungen an die Infrastruktur 7

17 2.4. COMPUTING INFRASTRUKTUR angebunden. Die Abbildung 2.1 zeigt, dass die Computing Infrastruktur per NFSv4-Mount[8] Zugriff auf die LSDF hat. Tools können über die Hadoop API auf das Cluster zugreifen Hadoop Das Apache Hadoop Projekt entwickelt Open-Source Software für zuverlässiges, skalierbares und verteiltes Rechnen. [7] Hadoop wird dabei beim Cluster Computing eingesetzt. Es besteht aus mehreren Teilprojekten, wobei für diese Arbeit die Projekte Hadoop Distributed File System und Hadoop MapReduce verwendet werden, auf die nun genauer eingegangen wird. Hadoop Distributed File System Das Hadoop Distributed File System (HDFS)[9] ist ein verteiltes Dateisystem, welches auf Google s Dateisystem GoogleFS[10] basiert. HDFS ist aus einem NameNode und mehreren DataNodes aufgebaut und hat eine Master/Slave Architektur. Der Master ist hierbei der NameNode, welcher den Namensraum des Dateisystems verwaltet und den Dateizugriff der Clients reguliert. Die Slaves sind die DataNodes, wobei normalerweise jeder Knoten des Clusters einen DataNode darstellt. Sie sind für die Speicherverwaltung des Knotens auf denen sie laufen verantwortlich. HDFS stellt einen Namensraum bereit in dem Daten in Form von Dateien gespeichert werden können. Intern teilt HDFS die Dateien standardmäßig in 64 Megabyte (MB) große Blöcke auf, die auf einzelnen DataNodes abgelegt werden. Die Blöckgröße kann im HDFS eingestellt werden. Für Anfragen wie Datei öffnen/schließen und Dateinamen ändern wird der NameNode kontaktiert. Ein DataNode führt Blockoperationen wie erzeugen/löschen und das Erstellen von Replikationen nach den Anweisungen des NameNodes durch. Zum Abbilden eines Dateinamens auf dessen verteilte Blöcke nutzt das HDFS eigene Metadaten. In ihnen ist festgehalten auf welchen DataNode die Blöcke lagern, wie viele Replikate es davon gibt und an welcher Stelle der Block in der gesamten Datei steht. Die Replikate werden von Hadoop automatisch erstellt, ihre An- 8

18 2.4. COMPUTING INFRASTRUKTUR zahl kann im HDFS konfiguriert werden. Durch die Aufteilung der Dateien in Blöcke und deren Lagerung auf den DataNodes unterstützt HDFS das Ziel die Verarbeitung auf die Knoten zu verlagern, auf denen die Daten bereits vorhanden sind, anstatt die Daten zu den einzelnen Knoten zu transferieren. Moving Computation is Cheaper than Moving Data [11], durch diese Strategie kann HDFS einen performanten Daten- zugriff bei der Verarbeitung gewährleisten. Hadoop MapReduce Hadoop MapReduce ist ein Software Framework für die einfache Entwicklung von Applikationen zur parallelen Verarbeitung von riesigen Datenmengen auf großen Clustern, bestehend aus Standard-Hardware, in einer zuverlässigen und fehlertoleranten Weise. [12] Hierbei handelt es sich um eine Java Implementierung des von Google entwickelten Programmiermodells MapReduce[13]. Das von Hadoop implementierte Modell ist in Form eines Workflows realisiert und bestehend aus einer Map- und einer Reduce-Phase. Zur Erläuterung des Modells wird das Beispiel des Wörterzählens verwendet. Zu Beginn wird ein Job erstellt in dem festgelegt wird, wie der NameNode des HDFS lautet und welche Rechte der Nutzer dort besitzt. Zum Setzen der Rechte muss der Nutzername und der Gruppenname angegeben werden. Des Weiteren muss der Pfad zu den verwendeten Input Files angegeben werden. Im verwendeten Beispiel bedeutet das, an welchem Ort im HDFS die Textdatei mit den zu zählenden Wörtern liegt. Zur Übergabe der Funktionalität in der Map- und der Reduce-Phase werden dem Job die benötigten Java-Klassen mitgegeben. Für das Starten der beiden Phasen ist der JobTracker verantwortlich. Dieser wird im Job angegeben und sorgt für die Verteilung der einzelnen Aufgaben im Cluster. Danach wird der Job gestartet. Das MapReduce Framework arbeitet ausschließlich mit Key-Value Paaren. Dies hat zur Folge, dass aus dem Input File Key-Value Paare generiert werden müssen. Diese Aufgabe wird vom JobTracker übernommen. Als Key wird hierbei die Zeilennummer der Textdatei verwendet, als zugewiesener Value die gesamte Textzeile. In der darauf folgenden Map-Phase werden Mapper (auch 9

19 2.4. COMPUTING INFRASTRUKTUR Map-Prozesse genannt) auf den einzelnen Knoten gestartet. Übergeben wird diesen Prozessen ein Key-Value Paar. Der Mapper trennt die erhaltene Zeile in einzelne Wörter auf. Danach bildet er aus den einzelnen Wörtern wiederum Key-Value Paare, wobei hier die einzelnen Wörter als Key verwendet werden und als Value eine 1 erhalten. Diese werden als Zwischenergebnis ins HDFS geschrieben. Nachdem alle Mapper fertig sind ist die Map-Phase beendet und der JobTracker startet die Reduce-Phase. Dafür werden die Reducer (Reduce- Prozesse) auf den Knoten gestartet. Diese lesen die Zwischenergebnissen ein, indem sie einen Key mit den dazugehörigen Values verwenden. Die Besonderheit liegt darin, dass ein Key mehrere Values besitzen kann. Da ein Key ein Wort repräsentiert und alle Values den Wert 1 haben, müssen nur die Values zusammengezählt werden. Dadurch erhält man die Anzahl eines Wortes im Input File. Zum Schluss schreiben die Reducer ihre Ergebnis in ein Output File im HDFS. Nachdem der letzte Reducer beendet ist löscht der JobTracker die Zwischenergebnisse und andere temporäre Dateien. Der Job ist danach beendet. Zur Veranschaulichung ist der Workflow von MapReduce in Abbildung 2.2 dargestellt. Mapper Zwischenergebnisse Reducer Input File Mapper Reducer Outnput File Mapper Abbildung 2.2: Workflow des MapReduce-Modells. Input Files werden in Form von Key-Value Paaren an die Mapper verteilt. Die Mapper erzeugen daraus Zwischenergebnisse, welche der Reducer als Input verwenden. Als Gesamtergebnis erzeugen die Reducer die Output Files. Quelle: Eigenerstellung in Anlehnung an [13] 10

20 2.5. VISUALISIERUNGSLÖSUNGEN 2.5 Visualisierungslösungen In den folgenden Abschnitte wird sowohl auf drei Visualisierungslösungen eingegangen, welche in der Biologie etabliert sind. Ebenfalls wird auch eine Lösung beschrieben die am Institut für Prozessdatenverarbeitung und Elektronik (IPE) entwickelt wurde V3D V3D[14] ist eine Visualisierungssoftware für 3D, 4D und 5D Bilder und ein Analysesystem für Biologiedaten. Entwickelt wurde es im Peng Lab[15] am Janelia Farm Research Campus[16] im Howard Hughes Medical Institute (HHMI)[17]. Es ist für die Plattformen Mac, Linux und Windows verfügbar. Dabei kann V3D mit 3D Image Stacks umgehen wie sie bei den Synapsen als auch bei den Zebrafischdatensätzen erzeugt werden. V3D ist in C/C++ implementiert und nutzt als Visualisierungsengine optimierte OpenGL[18] Methoden für die 3D Visualisierung auf einer Grafikkarte. V3D bietet sowohl einen synchronen als auch einen asynchronen Modus für die Volumenvisualisierung an. Beim asynchronen Modus nutzt V3D für die interaktive Betrachtung eine niedrigere Auflösung des Datensatzes. Sobald die Interaktionen, wie beispielsweise drehen oder zoomen, vom Nutzer beendet sind, wird mit der originale Auflösung das Volumen berechnet. Als interactive Visualisierungen bietet V3D zum Beispiel Maximum Intensity Projection (MIP) und 3D-Surface-Mesh Generierung. Durch die Verwendung von OpenGL kann V3D eine schnelle, grafikkartenbeschleunigte Visualisierung bereitstellen. Allerdings ist der Einsatz auf der Computing Infrastruktur der LSDF nicht möglich. Die einzelnen Knoten der Infrastruktur besitzen keine Grafikkarten, welche für die Visualisierung mit V3D genutzt werden könnten. Ebenfalls ist eine hardwarenahe Implementierung sehr aufgabenspezifisch und kann nicht einfach und schnell auf andere Strukturen oder Problemstellungen angepasst werden. Für den Einsatz im Umfeld der LSDF muss die Software 11

21 2.5. VISUALISIERUNGSLÖSUNGEN erweiterbar sein und einfach angepasst werden können. Dies kann V3D nicht gewährleisten, weshalb es als Visualisierungslösung nicht verwendet wird OMERO OMERO[19] ist eine Java Enterprise Anwendung der Open Microscopy Environment (OME)[20], welche eine Client-Server Plattform für die Verarbeitung und Speicherung von Bilddaten der Biologie zur Verfügung stellt. Die Plattform besteht aus dem OMERO.server und den OMERO.clients. In Abbildung 2.3 erkennt man den vereinfachten Aufbau der Client-Server Architektur von OMERO. Die Client Anwendungen können via Netzwerk die vom Server Abbildung 2.3: Vereinfachter Aufbau der OMERO Client-Server Architektur. Die Client Anwendungen können über das Netzwerk auf die einzelnen Schnittstellen des Servers zugreifen, um die Visualisierung und den Datenzugriff zu nutzen. Quelle: ( ) angebotenen Verarbeitungsprozesse aufrufen. Danach werden diese auf dem Server berechnet und vom Client angezeigt. Ebenfalls können eigene Anwendungen entwickelt werden, indem sie für die Analyse oder Datenzugriffe die 12

22 2.5. VISUALISIERUNGSLÖSUNGEN vom Server angebotenen Programmierschnittstellen nutzen. Dies wird durch die Middelware ZeroC IceGrid[21], eine Softwaretechnologie zum einheitlichen Repräsentieren von einzelnen Ressourcen, aufgebaut. Durch die nahe Anbindung der Rechenressourcen an die Daten kann eine hohe Performanz bei der Verarbeitung erreicht werden. Neben der Datenverarbeitung kümmert sich der OMERO.server um die Datenarchivierung und mittels Metadaten um das Datenmanagement. OMERO stellt zum Beispiel Maxium/Mean Projection zum Visualisieren von dreidimensionalen Datensätzen zur Verfügung. Die Bilddaten werden im OMERO.fs abgelegt, welches aus verteilten Ressourcen bestehen kann. Zum Verwalten der Daten nutzt OMERO Metadaten, welche in einer Hibernate[22] Datenbank abgelegt sind. Allerdings verwendet OMERO intern ein proprietäres Datenformat und nutzt hierzu einen Importer, welcher die unterstützten Eingabeformate entsprechend konvertiert und im Dateisystem ablegt. Die Gewährleistung der LSDF, die abgelegten Daten unverändert zu lagern, kann somit nicht gegeben werden. Zum Visualisieren der Mikroskopiedaten wird OMERO deshalb nicht eingesetzt. Allerdings ist es vorstellbar OMERO als optionale Infrastruktur neben der LSDF einzusetzen Fiji Fiji[23] ist eine Sammelwerk aus verschiedenen Softwarepaketen, wobei es die Hauptfunktionalitäten aus ImageJ[24] bezieht. Für den leichteren Umgang mit unterschiedlichen Bildtypen (8, 16, 32 Bit-Grauwert oder RGB) wurde ImageJ von Fiji erweitert. Zum Repräsentieren von Bildern nutzt ImageJ die Klasse ImagePlus. Die Bildinformationen befinden sich dort in der abstrakten Klasse ImageProcessor. Für die einzelnen Bildtypen gibt es Implementierungen, in denen aus Gründen der Performanz die passenden primitiven Datentypen byte, short, float und int verwendet werden. Ein entwickelter Algorithmus muss so für jeden Datentyp implementiert werden. Durch die Erweiterung imglib von Fiji werden Operationen von Bildinformationen in 13

23 2.5. VISUALISIERUNGSLÖSUNGEN der Klasse Cursor gekapselt. Dabei geht der Cursor alle Pixel eines Bild ab und sorgt dafür, dass alle Operationen auf die Pixel mit den richtigen primitive Datentypen durchgeführt werden. Des Weiteren benötigt Fiji Java3D[25] und die dort zugänglichen OpenGL- Funktionen zum Beispiel für die Bereitstellung eines 3D Viewers. Durch die Verwendung von OpenGL ist wiederum eine Hardwareabhängigkeit gegeben, welche auf der Computing Infrastruktur nicht gewünscht ist. Daher kann Fiji nicht für die Realisierung des Visualisierungskonzepts eingesetzt werden Eigenentwicklung Im Rahmen mehrerer studentischer Arbeiten wurde am IPE in der Fachgruppe Softwaremethoden eine Visualisierung in Java auf Basis von ImageJ implementiert. Die Eigenentwicklung bietet die Möglichkeit 3D Image Stacks durch eine MIP in 2D abzubilden. Dabei kann der 3D Stack aus einem beliebigen Blickwinkel betrachtet werden. Hierzu kann der Nutzer zum einen die Rotationswinkel aber auch den Rotationspunkt frei einstellen. Bereits getestet wurde die Visualisierung für die Synapsen-Datensätze. Bei diesen Daten liegen mehrere Image Stacks räumlich nebeneinander und die entwickelte Visualisierung konnte stackübergreifend die Volumendaten projizieren. Diese Funktionalität wird durch eine Datenstruktur ermöglicht die anhand der verwendeten Speicherstruktur der Image Stacks den Datensatz nachbildet. Die Datenstruktur bildet dabei die räumliche Struktur des Datensatzes in Form von Volumen ab. Hierbei kann ein Volumen aus mehreren Teilvolumina bestehen, welche wiederum Teilvolumen enthalten können. Das kleinste Teilvolumen beinhaltet dann die Bilder. In Abbildung 2.4 sind die Unterteilungen des gesamten Raumes dargestellt. Implementiert wurde diese Struktur in der Klasse Volume, welches eine hierarchische Struktur besitzt. Sie enthält eine Liste aus weiteren Volume Instanzen, welche die Teilvolumina darstellen. Die enthalten statt weitere Volumen die Schichtbilder. Die Datenstruktur ist somit für beliebige Datensätze verwendbar, welche durch ein dreidimensionalen Raum beschrieben sind. 14

24 2.5. VISUALISIERUNGSLÖSUNGEN Abbildung 2.4: Die Unterteilung des Raums in Schichten und Rasterelementen. Diese Volumina werden in die Datenstruktur abgebildet. Bei der Projektion wird die Datenstruktur rekursiv abgegangen und jedes Teilvolumen welches Bilder enthält wird projiziert. Die Ergebnisprojektion eines solchen Teilvolumens wird Teilprojektion genannt. Nachdem alle Teilprojektionen berechnet sind, wird mit diesen eine Komposition durchgeführt. Hierbei werden alle Teilprojektionen wiederum durch eine MIP in das Ergebnisbild übertragen. Die verwendete Datenstruktur ist so aufgebaut, dass sie für beliebige Datensätze verwendet werden kann. Durch die verwendete Datenstruktur kann die Visualisierung auf die Datensätze der Mikroskopie angewendete werden und zusätzlich kann eine Portierung auf zukünftige Projekte gewährleistet werden. Zudem ist die Visualisierung komplett als Software realisiert, wodurch sich keine Hardwareabhängigkeiten ergeben. Die einfachere Anpassung und Erweiterung ist somit gegeben. Darum wird die Eigenentwicklung als Basis für das aufzustellende und zu implementierende Konzept verwendet. 15

25 3 Konzept für die verteilte Verarbeitung Zur Durchführung der Visualisierung auf der Computing Infrastruktur wird im Vorfeld der Implementierung ein Konzept erarbeitet, mit dem die wahrgenommene Zeit der Nutzer reduziert werden soll. Hierbei soll verfolgt werden, dem Nutzer möglichst schnell ein Ergebnisse der Visualisierung darzustellen. 3.1 Grundprinzip Als Grundprinzip wird der von Google Maps[26] verwendete Ansatz zum Darstellen einzelner geographischer Daten verwendet. Es stellt hierbei eine Landkarte aus nebeneinander liegenden Einzelbildern dar. Google Maps verwendet hier für verschiedene Zoom-Stufen unterschiedliche Bildauflösungen. Wird ein Bereich aus der Landkarte vergrößert wird errechnet welche Einzelbilder im betrachteten Bereich liegen. Gibt es für die neue Zoom-Stufe eine andere Auflösungen, werden die Bilder mit der passenden Auflösung nachgeladen und ersetzen die mit niederer Auflösung. Durch diesen Ansatz wird für jeden Bereich eine Auflösung pro Zoom-Stufe benötigt, was eine höhere Datenmenge zur Folge hat. Allerdings kann durch die geringere Auflösung dem Nutzer schneller eine Vorschau auf die Landkarte ermöglicht werden, als wenn direkt die höchste Auflösung dargestellt werden würde. 16

26 3.2. KONZEPTBESCHREIBUNG Dieses Grundprinzip wird für das aufzustellende Konzept verwendet. Dafür werden die zu visualisierenden Datensätze in niederen Auflösungen, durch herunterskalieren der Originaldaten, zusätzlich auf der LSDF bereitgestellt. Zur Zeit wird dies von Hand durchgeführt, da es dafür noch keinen Automatismus gibt. Allerdings gibt es bereits Bestrebungen Dienste zu realisieren, welche im Hintergrund auf der LSDF automatisch arbeiten sollen. Einer dieser Dienste könnte dann für die Erzeugung der einzelnen Auflösungen sorgen. Daher wird für das Konzept die Vorbereitung der Datensätze nicht einbezogen. 3.2 Konzeptbeschreibung Der zugrunde liegende Ansatz für eine schnelle Darstellung von Ergebnissen muss nun in Zusammenhang mit der LSDF und der Computing Infrastruktur gesetzt werden. Hierbei soll die Visualisierung mit kleinen Auflösungen lokal auf dem Client erfolgen. Parallel dazu wird das Ergebnis mit der maximale Auflösung auf der Computing Infrastruktur berechnet. Dazu muss definiert werden, wie die Prozesse ablaufen und welche Komponenten untereinander kommunizieren Prozesse Das entwickelte Konzept ist in zwei Prozesse gegliedert. Der erste Prozess befasst sich mit der verteilte Visualisierung und beschreibt hierbei wie die Visualisierung auf der Computing Infrastruktur durchgeführt wird. Der Zweite thematisiert die lokale Visualisierung und definiert, wie der Client genutzt wird, um aus den Experimentdaten möglichst schnell Ergebnisbilder anzeigen zu können. Verteilte Visualisierung Die verteilte Visualisierung wird vom Client auf der Computing Infrastruktur gestartet. Zunächst werden die zu visualisierenden Bilder aus der LSDF von 17

27 3.2. KONZEPTBESCHREIBUNG den verwendeten Knoten heruntergeladen. Aus den einzelnen Bildern wird die benötigte Struktur der Visualisierung aufgebaut. Danach werden die Bilder visualisiert. Daraus entstehen Zwischenergebnisse, welche danach zurück in die LSDF geschrieben werden. War die Visualisierung und das Speichern erfolgreich, wird an den Client ein Bestätigung übermittelt, dass auf der LSDF die Zwischenergebnisse erzeugt wurden. Danach wird die Komposition der Zwischenergebnisse gestartet. Hierzu wird die verteilte Visualisierung erneut genutzt, allerdings werden jetzt die erzeugten Zwischenergebnisse auf einen einzigen Knoten geladen und in das Gesamtergebnis eingetragen. Am Ende der Projektion wird das Ergebnisbild auf die LSDF geschrieben und der Client erhält wieder eine Bestätigung. Lokale Visualisierung Die lokale Visualisierung wird parallel zur verteilte Visualisierung gestartet. Hierbei lädt der Client zwei Bilder mit der niedrigsten Auflösung von der LSDF herunter. Die benötigte Datenstruktur der Visualisierung wird mit den heruntergeladenen Bilder aufgebaut und im Anschluss visualisiert. Das Zwischenergebnis wird danach direkt angezeigt. Durch die geringe Anzahl der Bilder und deren niedrige Auflösung soll die Übertragungszeit aber auch die Zeit zur Visualisierung verkürzt werden. Daraufhin werden die nächsten zwei Bilder des Datensatzes heruntergeladen und visualisiert. Das hieraus resultierende Zwischenergebnis wird in das momentan angezeigten Bild hineinprojiziert. Dadurch wird der Fortschritt der Visualisierung direkt in dem angezeigten Bild sichtbar, da neue Details zu dem bestehenden Ergebnis hinzugefügt werden. Durch das stetige Einblenden neuer Details soll die Wartezeit auf die verteilte Visualisierung subjektiv verringert werden, da die Aufmerksamkeit auf der sich ändernden lokale Visualisierung liegt. Zudem erhält der Wissenschaftler durch das Einblenden der Teilprojektionen eine Vorschaufunktion und kann so die Visualisierung uninteressanter Daten abbrechen. Sobald die niedrigste Auflösung eines Datensatzes komplett visualisiert wurde, beginnt die lokale Visualisierung mit der nächsthöheren Auflösung. Dieser Vor- 18

28 3.2. KONZEPTBESCHREIBUNG gang wird solange wiederholt, bis die verteilte Visualisierung eine Bestätigung übermittelt, dass das Ergebnisbild mit maximale Auflösung bereit zur Anzeige ist oder keine weiteren reduzierten Auflösungen vorhanden sind. Abschließend wird das Endergebnis heruntergeladen und dargestellt Kommunikation Bei der Kommunikation der einzelnen Komponenten soll festgelegt werden, wie der Datenfluss und der Kontrollfluss untereinander abläuft. Die Abbildung 3.1 stellt hierbei die beiden Kommunikationsflüsse dar. Es ist zu erkennen, dass hierbei der Kontrollfluss zwischen allen Komponenten bidirektional verläuft. Der Datenfluss erfolgt nur zwischen der LSDF und der Computing Infrastruktur in beide Richtungen. Die restlichen Datenflüsse sind vom Client zur Computing Infrastruktur und von der LSDF zum Client einfach gerichtet. Abbildung 3.1: Kommunikation innerhalb des Konzepts. Der Kontrollfluss zwischen allen Komponenten ist bidirektional. Ein Datenfluss geht von der LSDF zum Client. Ebenso geht vom Client zur Computing Infrastruktur. Der Datenfluss zwischen LSDF und Computing Infrastruktur ist wir der Kontrollfluss bidirektional. 19

29 3.2. KONZEPTBESCHREIBUNG Die folgende Auflistung stellt die Informationsinhalte zwischen den Komponenten dar. Client - LSDF: Zwischen dem Client und der LSDF besteht die Kommunikation vorwiegend aus dem Herunterladen der niedrigauflösenden Bilder. Allerdings muss der Client zuvor Anfragen an die LSDF richten, damit die gewünschten Dateien vor der Übertragung gefunden werden, was der Kontrollfluss verdeutlicht. Client - Computing Infrastruktur: Der Client dient hierbei dazu die verteilte Visualisierung auf der Computing Infrastruktur zu starten und die dafür notwendigen Parameter zu übermitteln. Ebenfalls kümmert sich der Client darum die Originaldaten für die erste Visualisierung zu nutzen und bei der Komposition die erzeugten Zwischenergebnisse zu verwenden. Die Computing Infrastruktur hingegen meldet dem Client nur das korrekte Visualisieren und speichert die Ergebnisbilder. Computing Infrastruktur - LSDF: Die Computing Infrastruktur nutzt die LSDF zum Herunterladen der Bilddaten. Anders als vom Client erhält die LSDF von der Computing Infrastruktur die erzeugten Ergebnisse, welche auf ihr abgelegt werden. 20

30 4 Implementierung des Konzepts 4.1 Konfiguration der Visualisierung Zur Konfiguration der Visualisierung wurde entschieden die benötigten Parameter in einer Konfigurationsdatei zu verwalten. Da die Parameter für die Visualisierung eines Image Stacks je nach Auflösung variieren, wird für die Projektion jeder Auflösung eines Image Stacks eine eigene Konfigurationsdatei verwendet. In den Listings 4.1, 4.2 und 4.3 sieht man Auszüge aus einer Konfigurationsdatei, mit der die Parameter der Visualisierung festgelegt werden. Diese werden zu Beginn der Visualisierung geladen und für den weiteren Ablauf verwendet. In den Umgebungsparametern wird angegeben, wo die Visualisierung durchgeführt werden soll, welcher Image Stack dabei verwendet und wie darauf zugegriffen wird. ###Umgebungsparameter #Visualisierungsort run.local = false #Mount-Punkte auf der LSDF (müssen den URL-Standard von Java einhalten) local.mount.point = gsiftp://f e.gridka.de:2811/lsdf/sink/ remote.mount.point = file:/gpfs/lsdf/ #Die relativen Pfade auf der LSDF source.path = itg/visualization/dataset/mice/2048x2048/field--x06--y14/ destination.path = itg/visualization/projections/mice/2048x2048/ #Parameter für die verteilte Visualisierung files.per.node = 10 job.directory = 2048x2048 #Lokaler Speicherort download.path = file:/e:/temp/download/ Listing 4.1: Die Umgebungsparameter eines Image Stacks 21

31 4.1. KONFIGURATION DER VISUALISIERUNG Visualisierungsort: Hier wird definiert, ob die Visualisierung auf dem lokalen Rechner oder auf der Computing Infrastruktur durchgeführt werden soll. Mount-Punkte an die LSDF: Diese Mount-Punkte verweisen an Stellen auf der LSDF. Sie werden als URL mit dem in Java verwendeten Standard angegeben. Für die Verbindung vom lokalen Rechner zur LSDF wird ein anderes Zugriffsverfahren verwendet als von der Computing Infrastruktur. Die Mount-Punkte werden dazu verwendet, damit auf eine gemeinsame Stelle auf der LSDF verwiesen wird. Relative Pfade auf der LSDF: Wird eine Mount-Punkt mit einem relativen Pfad verbunden, ergibt sich der absolute Pfad zu einer bestimmten Datei oder Verzeichnis. Dadurch wird der Zugriff auf die Daten möglich. Parameter für die verteilte Visualisierung: Hier wird die Anzahl der zu projizierenden Bilder pro Knoten und der Input Ordner von Hadoop angegeben. Lokaler Speicherort: Der Ort an den die Bilder für die lokale Visualisierung heruntergeladen werden. In den Datensatzparametern wird das verwendete Dateiformat und der Kanal der Bilder angegeben, der projiziert werden soll. Ebenfalls werden dort datensatzspezifische Klassen festgelegt. ###Datensatzparameter #Das von den Bildern verwendete Format image.format =.tif #Die Nummer des Kanals channel.number = 1 #Datensatzspezifische Klassen, zum Erstellen und Sortieren der Datenstruktur volume.param = visualizationclient.dataset.volume.micemicroscopyvolumeparameter image.comp = visualizationclient.dataset.comparator.micemicroscopyimagecomparator Listing 4.2: Die Datensatzparameter eines Image Stacks 22

32 4.1. KONFIGURATION DER VISUALISIERUNG Bildformat: Zum Unterstützen mehrerer Bildformate wird hier die Bezeichnung des zu verwendeten Formates angegeben. Kanalnummer: Hier wird die zu verwendende Kanalnummer angegeben. Datensatzspezifische Klassen: Wie die Datenstruktur für den verwendeten Datensatz aufgebaut wird ist in einer Klasse definiert. Ebenfalls gibt es eine Klasse die sich um die Sortierung der Bilder eines Datensatzes kümmert. Diese Klassen müssen mit Package-Struktur und Klassennamen angegeben werden. In den Projektionsparametern werden die räumlichen Informationen des Datensatzes und die Parameter für die Rotation angegeben. ###Projektionsparameter #Der absolute Ursprungspunkt der Projektionsfläche projection.root.x = projection.root.y = #Die Abmessung der Projektionsfläche projection.width = 2048 projection.height = 2048 #Der absolute Rotationspunkt im Raum rotation.point.x = rotation.point.y = rotation.point.z = 30 #Die Rotationswinkel um die entsprechenden Achsen rotation.angle.x.axis = 0 rotation.angle.y.axis = 0 rotation.angle.z.axis = 0 Listing 4.3: Die Projektionsparameter eines Image Stacks Ursprung der Projektionsfläche: Hier werden die X- und Y-Koordinaten der Projektionsfläche angegeben. Für die Koordinaten müssen die absoluten Werten im Raum der Projektionsfläche verwendet werden. Dadurch kann eine Visualisierung von räumlich nebeneinander liegenden Image Stack durchgeführt werden. 23

33 4.2. ANPASSUNG DES IMAGE STACK AUFBAUS Abmessung der Projektionsfläche: Die Größe der Projektionsfläche wird hierbei über deren Höhe und Breite angegeben. Der Rotationspunkt: Für die Rotation des Image Stacks muss X-, Y- und Z-Koordinate des Rotationspunktes mit absoluten Werten angegeben werden. Die Rotationswinkel: Für die Rotation des Image Stacks müssen die Winkel um die X-, Y- und Z-Achse im Rotationspunkte angegeben werden. 4.2 Anpassung des Image Stack Aufbaus Das Konzept sieht sowohl für die lokale als auch für die verteilte Visualisierung vor, dass nur einzelne Schichten eines Image Stacks auf einmal projiziert werden. Lokal werden immer zwei Bilder des Stacks projiziert, auf dem Cluster sollen beliebig viele Bilder auf einem Knoten projiziert werden. Dies führt zu einem Problem, da die Visualisierung ausschließlich für das Projizieren eines gesamten Image Stacks implementiert wurde. Die Problematik wird anhand der lokalen Visualisierung beschrieben, bei der immer zwei Schichtbilder visualisiert werden. Vor der Visualisierung wird aus den heruntergeladenen Bildern der Image Stack erzeugt. Durch das Konzept besteht dieser Stack nicht mehr wie bisher aus allen Bildern, sondern aus zwei. Die Abbildung 4.1(a) zeigt hierbei wie die Schicht 5 und 6 so an den Anfang des Stacks gesetzt werden. Dabei sollten sie korrekterweise, wie in Abbildung 4.1(b) gezeigt, tiefer im Stack liegen. Dadurch sind im Ergebnisbild einer Projektion nur zwei Schichten zu sehen. 24

34 4.2. ANPASSUNG DES IMAGE STACK AUFBAUS (a) Schichten an fehlerhafter Position (b) Schichten an richtiger Position Abbildung 4.1: Seitenansicht des aufgebauten Image Stacks für die Visualisierung mit a) fehlerhafter und b) richtige Position der Schichten. Durch das Konzept besteht ein Stack bei jeder lokalen Projektion aus zwei Schichten. Dadurch haben alle zu projizierenden Schichten die Position 1 oder 2 im Stack. Die Projektion verwendet nur diese Position als Z-Koordinate, wodurch der Fehler bei der Darstellung entsteht. Zur Behebung des Problems werden die unbesetzten Positionen eines Stacks vor der Visualisierung mit leeren Schichten besetzt, so dass die zu visualisierenden Bilder an der richtigen Position stehen. Da sowohl die Anzahl der Schichten im Stack als auch die Position der beiden zu projizierenden Schichten bekannt sind, müssen nur die fehlenden Schichten davor und dahinter hinzugefügt werden. Dies kann einfach mittels zweier Schleifen realisiert werden. Die erste Schleife fügt hierbei falls nötig die oberen Schichten zum Stack hinzu. Danach werden die beiden heruntergeladenen Bilder in den Stack eingefügt. Die zweite Schleife befüllt im Anschluss falls notwendig die darunter liegenden Schichten des Stacks. Dadurch ist sichergestellt, dass die Koordinaten bei einer Drehung korrekt aus dem Stack gelesen werden können und das Ergebnisbild nicht verfälscht wird. 25

35 4.3. STEUERSOFTWARE UND LOKALE VISUALISIERUNG 4.3 Steuersoftware und lokale Visualisierung Die Steuersoftware ist die zentrale Verwaltungsstelle der lokalen als auch der verteilten Visualisierung. Bei deren Start bekommt sie die Konfigurationsdateien der einzelnen Image Stacks übergeben. Zunächst werden die Informationen aus den Dateien ausgelesen und in eine HashMap geladen. Durch die HashMap kann zum Beispiel über den Key run.local auf den Wert false zugegriffen werden. Gekapselt wird diese Funktionalität in der Klasse VisualizationPropertyHandler. Über die dort verfügbare Methode getvaluebykey und den in der Klasse fest definierten Keys kann unkompliziert auf die einzelnen Parameter zugegriffen werden. Durch die Reihenfolge der übergebenen Konfigurationsdatei wird bestimmt wann welche Auflösungen für die Berechnung verwendet wird. Eine flexibleres Visualisieren der Daten ist dadurch gegeben. Zur Einhaltung des Konzepts werden beim Start die Konfigurationsdateien der Image Stacks mit steigender Auflösung übergeben. Nachdem alle Konfigurationen geladen wurden, werden die zugehörigen Datenstrukturen für die Visualisierung aufgebaut. Dazu werden die datensatzspezifische Klassen wie zum Beispiel MiceMicroscopyVolumeParameter und MiceMicroscopyImageComparator benötigt. Die Klasse MiceMicroscopyVolumeParameter implementiert hierbei, wie aus den einzelnen Datensatzstrukturen die räumlichen Informationen ausgelesen werden, damit die Datenstruktur aufgebaut werden kann. Den Aufbau der Datenstruktur übernimmt die Klasse Dataset. Sie generiert durch die räumlichen Informationen eine Instanz von Volume. Da es für die Visualisierung wichtig ist, dass die Schichten an der korrekten Position im Stack stehen wurde ein MiceMicroscopyImageComparator implementiert. Dieser extrahiert aus den Schichten die Z-Koordinate und sortiert anhand dieser Koordinate die Bilder. Neben den Klassen für die Synapsendaten der Mäusemuskeln wurden entsprechende Klassen auch für die Zebrafischdaten implementiert. Damit die Visualisierung auf die entsprechenden datensatzspezifische Klassen zugreifen kann erben diese zum einen von der 26

36 4.3. STEUERSOFTWARE UND LOKALE VISUALISIERUNG Klasse AbstractVolumeParameter und zum anderen von der Klasse AbstractImageComparator. Diese stellen die Zugriffsmethoden auf die Parameter bereit, wodurch die Visualisierung datensatzunabhängig die Parameter verwenden kann. Für den Zugriff auf die Speicherstruktur verwendet die Steuersoftware die ADALAPI. Aus dem lokalen Mount-Punkt und dem Pfad zum Datensatz wird eine URL erzeugt. Die URL wird für die Erzeugung eines AbstractFile benötigt. Beim Erstellen der Instanz kümmert sich die ADALAPI selbständig um den Verbindungsaufbau. Mit dem AbstractFile können nun Informationen wie von einer lokale Datei abgefragt werden. Wurden die Datenstrukturen für die einzelnen Datensätze aufgebaut, wird die Visualisierung gestartet. Es wird zunächst anhand des Visualisierungsortes geprüft, wo der entsprechende Datensatz visualisiert werden soll. Wird dieser lokal visualisiert, startet die Steuersoftware die lokale Visualisierung in einem separaten Thread. Dazu werden aus der Datenstruktur die benötigten Bilder ausgelesen und über die ADALAPI paarweise von der LSDF in das angegebene Verzeichnis heruntergeladen. Danach wird der Image Stack über die Klasse ImageStack nach dem beschriebenen Prinzip aufgebaut. Der so aufgebaute Image Stack wird an die Visualisierung weitergereicht und gestartet. Das hierbei entstandene Zwischenergebnis wird anschließend angezeigt. Wird bereits ein Zwischenergebnis angezeigt muss zunächst zwischen dem angezeigten und dem neu berechneten Ergebnis eine Komposition stattfinden. Dazu wird aus den beiden Ergebnisbildern ein Image Stack generiert und die Komposition durchgeführt. Das dabei entstandene Ergebnis wird dann wieder für die Anzeige verwendet. Dieser Vorgang wird solange wiederholt bis alle Bilder einer Auflösungen visualisiert und angezeigt wurden. Steht noch kein Ergebnis der verteilten Visualisierung bereit, wird die nächsthöhere Auflösung verwendet. Diese wird ebenfalls in einem neuen Thread gestartet und wie beschrieben visualisiert. Alle Zwischenergebnisse werden im gleichen Bild angezeigt, damit der Fortschritt während der Visualisierung erkennbar ist. Die Wiederholungen werden 27

37 4.4. VERTEILTE VISUALISIERUNG solange durchgeführt bis ein Ergebnis der verteilten Visualisierung vorliegt oder keine weiterer Auflösungen zum Berechnen vorhanden ist. 4.4 Verteilte Visualisierung Soll ein Datensatz nicht nur lokal visualisiert werden, wird parallel dazu in einem eigenen Thread die verteilte Visualisierung gestartet. Damit die verteilte Visualisierung auf der Computing Infrastruktur arbeiten kann, muss sie innerhalb der Hadoop Umgebung lauffähig sein. Dazu wird das Hadoop MapReduce Framework benötigt. Für die Durchführung musste zum einen ein Weg gefunden werden wie die Parameter der Visualisierung zu den einzelnen Knoten übertragen werden, zum anderen musste die Visualisierung mit dem MapReduce Framework umgehen können, damit sie auf den einzelnen Knoten durchgeführt wird. Die genaue Vorgehensweise wird in den folgenden Abschnitten erklärt Aufbau der Parameter Für die Implementierung der verteilten Visualisierung musste definiert werden, wie die einzelnen Parameter aufgebaut sind. Da in der bestehenden Visualisierung zwischen den Volumen- und den Projektionsparametern bereits unterschieden wird, wurde die Kategorisierung aufgegriffen und durch die Bildinformationen und Stackposition ergänzt. Der Aufbau der Parameter für die verteilte Visualisierung ist wie folgt: Stackposition Projektionsparameter Volumenparameter Bildinformationen Listing 4.4: Kategorisierter Aufbau der Parameter Da das MapReduce Framework primär für die parallel Verarbeitung von Textdateien konzipiert wurde, bietet es sich an die Parameter als Text aufzubauen. Die einzelnen Kategorien werden hierbei durch das -Symbol voneinander ge- 28

38 4.4. VERTEILTE VISUALISIERUNG trennt. In den einzelnen Kategorien werden die Parameter durch ein Komma getrennt. Stackposition: Dieser Parameter gibt die Position der zu visualisierenden Bilder im gesamten Image Stack an. Dadurch kann der Image Stack für die Visualisierung korrekt aufgebaut werden. Projektionsparameter: Alle benötigten Parameter für die Visualisierung wie Rotationspunkt, Drehwinkel, Position der Projektionsfläche und deren Größe. Volumenparameter: Die Position des Volumens im Raum und dessen Stackgröße. Bildinformationen: Hier wird der Speicherort des Zwischenergebnisses angegeben und welche Bilder für die Projektion verwendet werden sollen. Alle Pfade sind dabei als URL anzugeben. Zuständig für die Erzeugung der Parameter ist die Klasse DistributedProjectionParameterGenerator. Ihr werden die Volumen- und Projektionsparameter übergeben sowie alle zu verwendenden Bilder. Der Parameter-Generator fügt automatisch die gewünschte Anzahl an Bildern pro Knoten im Text hinzu Implementieren des MapReduce Workflows Wie bereits eingehend erwähnt besteht der Workflow des MapReduce Modells aus einer Map- und einer Reduce-Phase. Die Funktionalität während der einzelnen Phasen wird über eine Mapper- Klasse und eine Reducer-Klasse definiert. Sie müssen hierzu von der Klasse Mapper<KEYIN,VALUEIN,KEYOUT,VALUEOUT> respektive Reducer<KEYIN,VALUEIN,KEYOUT,VALUEOUT> abgeleitet sein. Beim Starten eines Map-Prozesses wird in der Mapper-Klasse die map Methode 29

39 4.4. VERTEILTE VISUALISIERUNG aufgerufen. Analog dazu wird in der Reducer-Klasse die Methode reduce während des Reduce-Prozesses aufgerufen. Die gewünschte Funktionalität muss in diesen beiden Methoden implementiert werden. Damit die entsprechende Funktionalität auf dem Cluster gestartet werden kann wird ein Hadoop Job erzeugt. In ihm werden Angaben über das HDFS und des Clusters angegeben und welche Klassen in der Map- und Reduce- Phase verwendet werden. Die Konfiguration eines Jobs wird über die Klasse Configuration geregelt. Dabei müssen folgenden Parameter angegeben werden. hadoop.job.ugi : Dieser Parameter setzt den Nutzer und die Gruppe mit dessen Rechte der Job gestartet werden soll. fs.default.name : Hier wird über eine URL der NameNode angegeben, damit auf die Input Files im HDFS zugegriffen werden kann. mapred.job.tracker : Durch die Angabe des mapred.job.tracker wird der Hostname des JobTrackers angegeben, welcher für das Starten des Workflows verantwortlich ist. mapred.jar : Falls selbsterstellte Klassen während des Job benötigt werden, können diese in Form eines Java Archive (JAR) mit übertragen werden. Hierzu muss der Pfad zum JAR angegeben werden. Die hierbei erstellte Konfiguration wird der Klasse Job übergeben. Des Weiteren werden dem Job mittels der Methoden setmapperclass und setreducerclass die Klassen für die Map- und Reduce-Phase übergeben. Zu beachten ist, wenn selbst erstellte Mapper- und Reducer-Klassen verwendet werden sollen, müssen diese in dem übertragenen JAR enthalten sein. Falls ein Job keine Reduce-Phase benötigt kann in der Konfiguration der Key mapred.reduce.tasks auf den Wert 0 gesetzt werden. Diese Option wird im Laufe 30

40 4.4. VERTEILTE VISUALISIERUNG der Arbeit noch Anwendung finden. Für das Einlesen der Input Files muss dem Job deren Verzeichnis übergeben werden. Ebenfalls muss für das Erzeugen von temporären Dateien und Zwischenergebnissen ein Output Verzeichnis definiert sein. Wichtig ist, dass der Output Ordner vor Beginn des Jobs nicht existiert, da dieser von Hadoop angelegt werden muss. Für die korrekte Erzeugung der Key-Value-Paare für die Map-Phase müssen dem Job die entsprechenden Input Formate mitgeteilt werden. Danach ist der Job bereit gestartet zu werden. Zum Kapseln des Jobaufbaus und der Parameterübergabe ist die Klasse HadoopJobHandler erstellt worden. Dieser Klasse wird das Verzeichnis übergeben, in dem die Input Files erzeugt werden sollen. Die Konfiguration für die LSDF und die Computing Infrastruktur wird dabei automatisch durchgeführt. Zum Erzeugen der Input Files steht die Methode createparamfileonhadoop für Verfügung. Als Übergabeparameter werden die Parameter in der definierten Struktur übergeben. Diese werden dann, mittels der Hadoop API ins HDFS übertragen. Durch die Klasse FSDataOutputStreams können die einzelnen Parameter direkt in eine Textdatei auf dem HDFS geschrieben werden. Die Parameter werden hierbei als eine einzige Zeile in die Datei geschrieben. Damit die Visualisierung möglichst parallel abläuft, werden mehrere Textdateien verwendet. Beim Anlegen einer Datei schreibt der NameNode diese auf unterschiedliche DataNodes im HDFS. Beim späteren Verarbeiten werden dadurch auch die Knoten verwendet, welche die Textdateien enthalten. Neben der Übertragung mit der Hadoop API hätte auch die ADALAPI verendet werden können. Allerdings müsste hierzu die Datei lokal erzeugt werden und anschließend Übertragen werden. Durch den FSDataOutputStreams kann aber direkt die Datei erzeugt werden, wodurch Zeit eingespart werden kann. Zum Starten des Jobs wird die Methode startjob benutzt, bei der angegeben werden muss, welche Map- und Reduce-Klasse für den Job verwendet werden soll. In der Methode wird dann der Job erzeugt, die Klassen gesetzt und gestartet. Nach dem Starten wird auf die Benachrichtigung der Computing In- 31

41 4.4. VERTEILTE VISUALISIERUNG frastruktur gewartet. Als Funktionalität innerhalb des MapReduce Workflows wurden der JobPilot, die Projektion und die Komposition implementiert JobPilot Das Konzept der verteilten Visualisierung sieht vor die bei der Projektion erzeugten Zwischenergebnisse zurück auf die LSDF zu schreiben. Dabei sollen diese nicht zu den Originaldaten gespeichert werden, sondern in einer separaten Verzeichnisstruktur. Diese Struktur soll dabei für alle Projekte nutzbar sein. Deshalb wird ein Verzeichnis mit einer Projektbezeichnung erstellt und darin für die Zwischenergebnisse ein Verzeichnis mit der berechneten Auflösung. Da zur Zeit der Implementierung kein Protokoll der ADALAPI auf der LSDF unterstützt wurde, konnte die Erzeugung der gewünschten Verzeichnisstruktur nicht über die Steuersoftware erfolgen. Der einzige direkte Zugriff aus einer Anwendung heraus ist über die Computing Infrastruktur möglich. Die einzelnen Knoten können hierbei über einen NFS-Mount auf die LSDF zugreifen. Daher wurde ein JobPilot implementiert, welcher über die Computing Infrastruktur die benötigten Verzeichnisse anlegt. Zusätzlich setzt der JobPilot die Rechte der Verzeichnisse, so dass alle Nutzer diesen Ordner lesen und schreiben dürfen. Zwischen der LSDF und der Computing Infrastruktur gibt es keine einheitliche Nutzerkennung durch Nutzername und Gruppenname, da es zwei unterschiedliche Systeme sind. Damit allerdings die berechneten Zwischenergebnisse auch von der LSDF aus lesbar sind werden hierzu die Rechte der Verzeichnisse geändert. Der JobPilot ist als Hadoop Job implementiert worden, da nur aus dem Hadoop heraus die Änderungen der Rechte durchgeführt werden kann. Hierfür wurde der HadoopPilotMapper implementierte. Er erhält als Parameter zwei Verzeichnisse mit absoluten Pfaden. Das erst Verzeichnis ist der Ablageort der Zwischenergebnisse und das Verzeichnis für das Ergebnis der Komposition. Diese Pfade werden in eine Zeile geschrieben, wobei sie durch ein Trennzeichen voneinander abgegrenzt sind. Wird dem HadoopPilotMapper die Textzeile beim Start übergeben, wird durch einen StringTokenizer die Zeile an- 32

42 4.4. VERTEILTE VISUALISIERUNG hand des Trennzeichens aufgeteilt. Danach werden alle Elemente des Tokenizers durchlaufen und die enthaltenen Verzeichnisse angelegt. Nachdem ein Verzeichnis angelegt wurde, werden dessen Lese- und Schreibrechte so gesetzt, dass das Verzeichnis für alle Benutzer freigegeben ist Projektion und Komposition Die Funktionalität für die Projektion und die Komposition ist identisch, der Unterschied liegt hierbei bei den verwendeten Parametern. Bei der Projektion wird die Rotation und die Lage des Image Stacks berücksichtigt, bei der Komposition müssen nur die bereits gedrehten Ergebnisse zusammengefügt werden. Für die Erzeugung der Parameterzeilen aus den Projektionsparamtern wird der DistributedProjectionParameterGenerator verwendet, für die Komposition wird dafür die Klasse DistributedComposeParameterGenerator verwendet. Hierfür werden alle Werte für die räumliche Lage und für die Rotation auf 0 gesetzt. Dadurch wird nur eine Mapper-Klasse für beide Funktionalitäten benötigt, da die Parameterdekodierung sowohl für die Komposition als auch für die Projektion genutzt werden kann. Zum Auslesen der Parameter aus der Textzeile werden zwei Typen von StringTokenizer im DistributedVisualizationMapper verwendet. Der erste Typ trennt hierbei die Zeile mit dem -Trennzeichen auf, so dass auf die vier Kategorien zugegriffen werden kann. Die einzelnen Kategorien werden dann wieder durch einen StringTokenizer aufgeteilt, wobei die Trennung der Zeichenkette durch ein Komma durchgeführt wird. Sobald alle Informationen aus der Parameterzeile ausgelesen sind wird der Image Stack durch nach dem beschriebenen Schema aufgebaut und die Projektion wird gestartet. Die auf der Computing Infrastruktur verwendete Visualisierung unterscheidet sich hierbei nicht von der lokal verwendeten. Nachdem alle Projektionen abgeschlossen sind wird an die Steuersoftware eine Bestätigung übertragen, dass die Komposition durchgeführt werden kann. Die Steuersoftware erzeugt dann das benötigte Input File mit der vom DistributedComposeParameterGenerator 33

43 4.4. VERTEILTE VISUALISIERUNG erzeugte Parameterzeile. Die Komposition wird dann auf einem Knoten durchgeführt. 34

44 5 Evaluierung Durch eine Evaluierung soll zum einen die Funktionalität des erarbeiteten und implementierten Konzepts geprüft werden. Zum Anderen soll durch Zeitmessungen festgehalten werden, wie die konventionelle Art der lokalen Verarbeitung im Vergleich zur Realisierten steht. 5.1 Messumgebung Die einzelnen Messungen für die Evaluierung müssen auf zwei verschiedenen Systemen durchgeführt werden. Da zur Zeit der Evaluation für einen Client der Zugriff auf der LSDF ausschließlich über SSH[27] möglich war, wurde für die Messung der lokalen Visualisierung der LSDF Prototyp verwendet. Dieser stellt den Datentransfer über das verwendete Protokoll GridFTP bereit und sollte mit der LSDF vergleichbare Ergebnisse liefern. Für die verteilte Visualisierung kann hingegen die LSDF verwendet werden, da die einzelnen Knoten über einen NFSv4-Mount direkt auf die LSDF zugreifen können. Als Client wird ein herkömmlicher Arbeitsplatzrechner verwendet. Die LSDF und der LSDF Prototyp liegen beide nicht im selben Subnetz, wie der Arbeitsplatzrechner. Der lokale Rechner ist über eine 1 GBit/s Leitung an die LSDF und den Prototyp angebunden. Arbeitsplatzrechner: Betriebssystem: 32-Bit Windows XP (Service Pack 3) Prozessor: Intel Dual Core 2140 mit 2 x 1,6 GHz 35

45 5.2. SYNAPSEN DATENSATZ Arbeitsspeicher: 2 GB Verbindung mit der LSDF: 1 GBit Computing Infrastruktur: Anzahl Knoten: 55 Betriebssystem: 64-Bit Scientific Linux 5.5 Prozessor: 2 x Intel Quad Core pro Knoten Arbeitsspeicher: 36 GB pro Knoten Verbindung mit der LSDF: 10 GBit 5.2 Synapsen Datensatz Der für die Evaluierung verwendete Datensatz wurde für die Untersuchung von Synapsen in Mäusemuskeln erzeugt. Die Synapsen werden durch ein Kontrastmittel hervorgehoben. Ein einzelnes Schichtbild ist Pixel groß und hat dabei eine Abmessung von 775µm sowohl in der Höhe als auch in der Breite. Die aufgenommenen Schichten werden nach der Aufnahme als 8-Bit Grauwertbilder im Tiff-Format abgespeichert. Der Datensatz ist in folgende Bereiche aufgeteilt. Experiment: Ein Experiment repräsentiert den kompletten Bereich einer Aufnahme. Slide: Die Unterteilung eines Experimentes in Schichten wird Slide genannt. Die Slides liegen entlang der z-achse hintereinander. Chamber: Ein Chamber ist ein Element, welches bei der Rasterung eines Slides entsteht. 36

46 5.3. ABLAUF DER MESSUNG Field: Ein Field ist der kleinste Bereich im Datensatz. Es beinhaltet die aufgenommenen Schichtbilder. Bei der Aufnahem werden zwei unterschiedliche Kontrastmittel verwendent, woraus sich 2 Farbkanäle ergeben. Das Field ist ein Rasterelement eines Chamber. Bei der Aufnahme des Datensatzes werden für jedes Field und pro Farbkanal 60 Schichten aufgezeichnet. Die Datenmenge eines Image Stack beläuft sich somit auf Byte = 240 MB. Die Abbildung der Datensatzstruktur in die von der Visualisierung verwendeten Datenstruktur ist durch die räumliche Unterteilung möglich. Dabei entsprechen die Bereiche Experiment, Slide und Chamber einem Volume welches Teilvolumen enthält. Der kleinste Bereich des Datensatzes, das Field, ist in der Datenstruktur ein Volume welches Schichten enthält. 5.3 Ablauf der Messung Bei den durchzuführenden Messungen wird immer ein Image Stack bestehend aus 60 Schichtbilder (Field) verwendet. Dabei wird zunächst die maximale Auflösung des Image Stacks lokal visualisiert. Die Schichtbilder werden zuerst komplett heruntergeladen, dann wird der Image Stack aufgebaut und visualisiert. Dabei wird die Zeit für die Übertragung der Bilder, das Aufbauen des Stacks und die Visualisierung gemessen. Eine Komposition ist durch die Visualisierung nur eines Image Stacks nicht notwendig. Diese Messung wird als Referenz verwendet. Im Anschluss wird die lokale Visualisierung durchgeführt. Hierzu wurde der originale Image Stack auf eine Auflösung von , und Pixel herunterskaliert. Es wird von der niedrigsten Auflösung bis zur höchsten Auflösung die Visualisierung lokal durchgeführt. Hierbei werden allerdings die Zeiten für den Download und das Aufbauen des Image Stacks zusammen gemessen, da sich das Herunterladen der Bilder und das Aufbauen des Image Stacks überschneiden. Ebenfalls werden die Zeiten für die Projektion und die 37

47 5.4. TESTERGEBNISSE Komposition gemessen. Bei der verteilten Visualisierung wird der Image Stack mit maximaler Auflösungen verwendet. Dabei wird die Zeit für den JobPilot, die Projektion und die Komposition gemessen. Dabei werden bei der verteilten Visualisierung 10 Knoten für die Berechnung der 60 Schichtbildern verwendet. Ein einzelner Knoten projiziert hierbei 6 Schichtbilder. Bei der Komposition visualisiert ein Knoten die 10 erzeugten Teilprojektionen zu einem Ergebnisbild. Es wird jede Visualisierung zehnmal gemessen. Dabei werden die Messungen an Zeiten durchgeführt an denen das Netzwerk einer geringen Last ausgesetzt ist, wie zum Beispiel Abends oder an Wochenenden. Die gemessenen Werte werden dann gemittelt. 5.4 Testergebnisse Die lokalen Visualisierung des Image Stacks mit maximaler Auflösung, bei der zunächst alle Daten heruntergeladen, in einen Image Stack geschrieben und anschließen komplett visualisiert wurden, ergab die in Tabelle 5.1 gemessenen Werte. Man erkennt, dass die meiste Zeit für die Übertragung benötigt wird. Mit diesem Vorgehen würde ein Nutzer erst nach 53 Sekunden ein Ergebnis der Visualisierung sehen. Die Ergebnisse der lokalen Projektionen nach Anzahl Bilder Download Stackaufbau Projektion Gesamt 60 26,131 s 11,815 s 14,692 s s Tabelle 5.1: Ergebnis der lokalen Projektion des kompletten Image Stacks. dem implementieren Konzept sind in den drei folgenden Tabellen zu sehen. Bei der Visualisierung des kleinsten Image Stacks (siehe Tabelle 5.2) dauerte das Herunterladen, Projizieren und Komposizieren für zwei Bilder im Durchschnitt 0,6 Sekunden. Die Darstellung des ersten Teilergebnisses ist nach einer Sekunde möglich. Man erkennt ebenfalls, wie bei der lokalen Projektion des Image Stacks mit maximaler Auflösung, dass der Download die meiste Zeit in 38

48 5.4. TESTERGEBNISSE Anspruch nimmt. Insgesamt betrachtet ist das Ergebnisbild aus 60 Schichtbilder nach 19,3 Sekunden verfügbar. Die nächsthöhere Auflösungen benötigt Anzahl Bilder Download & Projektions Kompositions Gesamt Stackaufbau 2 0,622 s 0,007 s 0,016 s 0,646 s s 0,215 s 0,473 s 19,336 s Tabelle 5.2: Ergebnis der lokalen Projektion für den Image Stack nach dem entwickelten Konzept. im Vergleich zur niedrigeren vier mal so lange für die Projektion. Dies liegt somit im erwarteten Bereich, da die in Tabelle 5.3 gezeigten Auflösung auch eine 4 mal so große Datenmenge hat wie die niedrigere. Neben der Projektionszeit nahm auch die Übertragungszeit zu, aber nur um ca. 0,1 Sekunden pro Bildpaar. Die Gesamtzeit beträgt für die lokale Visualisierung des Image Stacks mit der Auflösung von Pixel 22,7 Sekunden. Die letzte lokale Anzahl Bilder Download & Projektions Kompositions Gesamt Stackaufbau 2 0,703 s 0,031 s 0,023 s 0,757 s 60 21,098 s 0,939 s 0,676 s 22,713 s Tabelle 5.3: Ergebnis der lokalen Projektion für den Image Stack nach dem entwickelten Konzept. Visualisierung zeigt wiederum, dass durch die verdoppelte Auflösung die vierfache Zeit für die Projektion benötigt wird. Allerdings sind die Bilder schneller übertragen worden als bei der vorherigen Auflösung. Im Allgemeinen macht die Übertragung den Großteil der Gesamtzeit aus. Eine mögliche Erklärung für die ähnlichen Übertragungszeiten der unterschiedlichen Auflösungen ist, dass verwendete Protokoll GridFTP bei jede Übertragung Overhead durch die integrierten Sicherheitsmethoden erzeugt. Diese Zeit dominiert die eigentliche Übertragungszeit bei weitem. Das Ergebnis der verteilten Visualisierung in Tabelle 5.5 zeigt, dass der Image Stack mit maximaler Auflösung in 44 Sekunden berechnet wurde. Somit kann dieses Ergebnisbild noch während der lokalen Visualisierung des Image Stacks angezeigt werde. Betrach- 39

49 5.5. ZUSÄTZLICHE ERGEBNISSE Anzahl Bilder Download & Projektions Kompositions Gesamt Stackaufbau 2 0,625 s 0,132 s 0,106 s s 60 18,764 s 3,945 s 3,184 s 25,890 s Tabelle 5.4: Ergebnis der lokalen Projektion für den Image Stack nach dem entwickelten Konzept. tet man die Zeit des JobPilot, bei dem lediglich zwei Verzeichnisse angelegt werden, kann man den erzeugten Overhead von Hadoop abschätzen. Nimmt man als Overhead 13 Sekunden benötigt die Projektion auf der Computing Infrastruktur eine Sekunde. Im Vergleich zur lokalen Projektion dieses Image Stacks konnte durch die Parallelisierung eine Zeit von 1,5 Sekunden erwartet werden. Allerdings erreicht man, unter der getroffenen Annahme, eine Zeit von nur einer Sekunde. Durch die schnellere Anbindung an die LSDF konnte diese Zeit erreicht werden. JobPilot Projektion Komposition Gesamtzeit 13,70300 s 14,03100 s 16,62400 s 44,26400 s Tabelle 5.5: Ergebnis der verteilten Projektion für den Image Stack nach dem entwickelten Konzept. 5.5 Zusätzliche Ergebnisse Neben einzelnen Image Stacks wurde auch der gesamte Synapsen-Datensatz für die Visualisierung verwendet. Dabei wurde ein Ausschnitt aus dem gesamten Raum des Datensatzes projiziert. Die Projektionsfläche betrug dabei 3 2 Fields. Das daraus resultierende Projektionsbild hat dadurch eine Abmessung von Pixel, für die Berechnung wurde ein Kanal aus dem Datensatz verwendet. Da keine Vorauswahl der Image Stacks für Visualisierung stattfindet, werden alle Image Stacks des Datensatzes für die Berechnung verwendet. Die hierbei verwendete Datenmenge beläuft sich auf ungefähr 15 GB. Die Abbildung 5.1 zeigt das Ergebnisbild der Visualisierung. Die beschriebene Vi- 40

50 5.5. ZUSÄTZLICHE ERGEBNISSE sualisierung wurde dabei in unter 180 Sekunden durchgeführt. Die Projektion als auch die Komposition dauern dabei zusammen etwa 150 Sekunden. Neben Abbildung 5.1: Die Abbildung zeigt einen in z-richtung projizierten Ausschnitt aus dem gesamten Synapsen-Datensatz. Die Abmessung des Projektionsbildes beträgt Pixel (3 2 Fields). dem Synapsen-Datensatz wurden auch der Zebrafisch-Datensatz visualisiert. Im Vergleich zu Synapsen konnte der Zebrafisch-Datensatz für die Evaluation nicht verwendet werden. Die maximale Auflösung des Datensatze beträgt Pixel und das Herunterskalieren in kleine Auflösung wäre hier unvorteilhaft gewesen, da auch hier die Übertragungszeit der Daten durch GridFTP das ausschlaggebende Kriterium für die Visualisierung bei kleinen Auflösungen wäre. Ein Ergebnisbild ist in Abbildung

51 5.5. ZUSÄTZLICHE ERGEBNISSE Abbildung 5.2: Die Abbildung zeigt die Z-Projektion eines Image Stacks vom Zebrafisch-Datensatz. 42

Hadoop aus IT-Operations Sicht Teil 1 Hadoop-Grundlagen

Hadoop aus IT-Operations Sicht Teil 1 Hadoop-Grundlagen Hadoop aus IT-Operations Sicht Teil 1 Hadoop-Grundlagen Brownbag am Freitag, den 26.07.2013 Daniel Bäurer inovex GmbH Systems Engineer Wir nutzen Technologien, um unsere Kunden glücklich zu machen. Und

Mehr

MapReduce in der Praxis

MapReduce in der Praxis MapReduce in der Praxis Rolf Daniel Seminar Multicore Programmierung 09.12.2010 1 / 53 Agenda Einleitung 1 Einleitung 2 3 Disco Hadoop BOOM 4 2 / 53 1 Einleitung 2 3 Disco Hadoop BOOM 4 3 / 53 Motivation

Mehr

Einführung in Hadoop

Einführung in Hadoop Einführung in Hadoop Inhalt / Lern-Ziele Übersicht: Basis-Architektur von Hadoop Einführung in HDFS Einführung in MapReduce Ausblick: Hadoop Ökosystem Optimierungen Versionen 10.02.2012 Prof. Dr. Christian

Mehr

Hadoop. Simon Prewo. Simon Prewo

Hadoop. Simon Prewo. Simon Prewo Hadoop Simon Prewo Simon Prewo 1 Warum Hadoop? SQL: DB2, Oracle Hadoop? Innerhalb der letzten zwei Jahre hat sich die Datenmenge ca. verzehnfacht Die Klassiker wie DB2, Oracle usw. sind anders konzeptioniert

Mehr

Perzentile mit Hadoop ermitteln

Perzentile mit Hadoop ermitteln Perzentile mit Hadoop ermitteln Ausgangspunkt Ziel dieses Projektes war, einen Hadoop Job zu entwickeln, der mit Hilfe gegebener Parameter Simulationen durchführt und aus den Ergebnissen die Perzentile

Mehr

Cloud-Computing. 1. Definition 2. Was bietet Cloud-Computing. 3. Technische Lösungen. 4. Kritik an der Cloud. 2.1 Industrie 2.

Cloud-Computing. 1. Definition 2. Was bietet Cloud-Computing. 3. Technische Lösungen. 4. Kritik an der Cloud. 2.1 Industrie 2. Cloud Computing Frank Hallas und Alexander Butiu Universität Erlangen Nürnberg, Lehrstuhl für Hardware/Software CoDesign Multicorearchitectures and Programming Seminar, Sommersemester 2013 1. Definition

Mehr

Neue Ansätze der Softwarequalitätssicherung

Neue Ansätze der Softwarequalitätssicherung Neue Ansätze der Softwarequalitätssicherung Googles MapReduce-Framework für verteilte Berechnungen am Beispiel von Apache Hadoop Universität Paderborn Fakultät für Elektrotechnik, Informatik und Mathematik

Mehr

GPU-basierte Beschleunigung von MapReduce am Beispiel von OpenCL und Hadoop

GPU-basierte Beschleunigung von MapReduce am Beispiel von OpenCL und Hadoop am Beispiel von OpenCL und Masterseminar Hochschule für Technik, Wirtschaft und Kultur Leipzig Leipzig, 02.11.2011 Gliederung 1 Grundlagen 2 3 Gliederung 1 Grundlagen 2 3 Was ist? Clustersystem zur verteilten

Mehr

SEMT. Prof. G. Bengel. Searching as a Service (Programming Model: MapReduce)

SEMT. Prof. G. Bengel. Searching as a Service (Programming Model: MapReduce) Hochschule Mannheim Fakultät für Informatik SEMT Prof. G. Bengel Sommersemester 2009 Semester 8I Searching as a Service (Programming Model: MapReduce) Michel Schmitt (520361) 1.06.2009 Inhalt 1. Einführung...

Mehr

Grundlagen des Grid Computing

Grundlagen des Grid Computing Grundlagen des Grid Computing Grid Middleware Toolkits: glite ICA Joh.. Kepler Universität t Linz glite Grid Middleware für das LHC Grid Wurde im Rahmen des EGEE Projekts entwickelt Basiert auf dem Globus

Mehr

Dateisysteme mit Plugin-Funktion

Dateisysteme mit Plugin-Funktion Dateisysteme mit Plugin-Funktion Basierend auf Reiser 4 unter Linux http://llugb.amsee.de/logo.gif Ausgearbeitet und vorgetragen von Michael Berger 1/23 Agenda Die Idee Dateisysteme mit Plugin-Funktion

Mehr

Complex Hosting. Whitepaper. Autor.: Monika Olschewski. Version: 1.0 Erstellt am: 14.07.2010. ADACOR Hosting GmbH

Complex Hosting. Whitepaper. Autor.: Monika Olschewski. Version: 1.0 Erstellt am: 14.07.2010. ADACOR Hosting GmbH Complex Hosting Autor.: Monika Olschewski Whitepaper Version: 1.0 Erstellt am: 14.07.2010 ADACOR Hosting GmbH Kaiserleistrasse 51 63067 Offenbach am Main info@adacor.com www.adacor.com Complex Hosting

Mehr

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221

Oracle 10g und SQL Server 2005 ein Vergleich. Thomas Wächtler 39221 Oracle 10g und SQL Server 2005 ein Vergleich Thomas Wächtler 39221 Inhalt 1. Einführung 2. Architektur SQL Server 2005 1. SQLOS 2. Relational Engine 3. Protocol Layer 3. Services 1. Replication 2. Reporting

Mehr

Datenbearbeitung in der Cloud anhand von Apache Hadoop Hochschule Mannheim

Datenbearbeitung in der Cloud anhand von Apache Hadoop Hochschule Mannheim Tobias Neef Cloud-Computing Seminar Hochschule Mannheim WS0910 1/23 Datenbearbeitung in der Cloud anhand von Apache Hadoop Hochschule Mannheim Tobias Neef Fakultät für Informatik Hochschule Mannheim tobnee@gmail.com

Mehr

Managed Cloud Services

Managed Cloud Services Managed Cloud Services Autor.: Monika Olschewski Whitepaper Version: 1.0 Erstellt am: 14.07.2010 ADACOR Hosting GmbH Kaiserleistrasse 51 63067 Offenbach am Main info@adacor.com www.adacor.com Cloud Services

Mehr

June 2015. Automic Hadoop Agent. Data Automation - Hadoop Integration

June 2015. Automic Hadoop Agent. Data Automation - Hadoop Integration June 2015 Automic Hadoop Agent Data Automation - Hadoop Integration + Aufbau der Hadoop Anbindung + Was ist eigentlich ist MapReduce? + Welches sind die Stärken von Hadoop + Welches sind die Schwächen

Mehr

Verteilte Dateisysteme in der Cloud

Verteilte Dateisysteme in der Cloud Verteilte Dateisysteme in der Cloud Cloud Data Management Maria Moritz Seminar Cloud Data Management WS09/10 Universität Leipzig 1 Inhalt 1.) Anforderungen an verteilte Dateisysteme 2.) GoogleFS 3.) Hadoop

Mehr

GeoShop Netzwerkhandbuch

GeoShop Netzwerkhandbuch Technoparkstrasse 1 8005 Zürich Tel.: 044 / 350 10 10 Fax.: 044 / 350 10 19 GeoShop Netzwerkhandbuch Zusammenfassung Diese Dokumentation beschreibt die Einbindung des GeoShop in bestehende Netzwerkumgebungen.

Mehr

Parallele und funktionale Programmierung Wintersemester 2013/14. 8. Übung Abgabe bis 20.12.2013, 16:00 Uhr

Parallele und funktionale Programmierung Wintersemester 2013/14. 8. Übung Abgabe bis 20.12.2013, 16:00 Uhr 8. Übung Abgabe bis 20.12.2013, 16:00 Uhr Aufgabe 8.1: Zeigerverdopplung Ermitteln Sie an folgendem Beispiel den Rang für jedes Listenelement sequentiell und mit dem in der Vorlesung vorgestellten parallelen

Mehr

Dateisysteme und Datenverwaltung in der Cloud

Dateisysteme und Datenverwaltung in der Cloud Dateisysteme und Datenverwaltung in der Cloud Sebastian Fischer Master-Seminar Cloud Computing - WS 2013/14 Institut für Telematik, Universität zu Lübeck Dateisysteme und Datenverwaltung in der Cloud 1

Mehr

PADS 3.0 Viewer - Konfigurationen

PADS 3.0 Viewer - Konfigurationen PADS 3.0 Viewer - Konfigurationen Net Display Systems (Deutschland) GmbH - Am Neuenhof 4-40629 Düsseldorf Telefon: +49 211 9293915 - Telefax: +49 211 9293916 www.fids.de - email: info@fids.de Übersicht

Mehr

0. Inhaltsverzeichnis

0. Inhaltsverzeichnis 0. Inhaltsverzeichnis 0. Inhaltsverzeichnis...1 1. Kurze Einführung WebService Architektur...2 1.1 Synchrones Modell:...2 1.2 Asynchrones Modell:...2 1.3 Vorteile:...3 1.4 Voraussetzungen...3 2. Testseite

Mehr

Verteilte Systeme. Map Reduce. Secure Identity Research Group

Verteilte Systeme. Map Reduce. Secure Identity Research Group Verteilte Systeme Map Reduce Map Reduce Problem: Ein Rechen-Job (meist Datenanalyse/Data-Mining) soll auf einer riesigen Datenmenge ausgeführt werden. Teile der Aufgabe sind parallelisierbar, aber das

Mehr

Group and Session Management for Collaborative Applications

Group and Session Management for Collaborative Applications Diss. ETH No. 12075 Group and Session Management for Collaborative Applications A dissertation submitted to the SWISS FEDERAL INSTITUTE OF TECHNOLOGY ZÜRICH for the degree of Doctor of Technical Seiences

Mehr

Antwortzeitverhalten von Online Storage Services im Vergleich

Antwortzeitverhalten von Online Storage Services im Vergleich EPOD Encrypted Private Online Disc Antwortzeitverhalten von Online Storage Services im Vergleich Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee

Mehr

PowerBridge MSSQL Beta

PowerBridge MSSQL Beta SoftENGINE PowerBridge MSSQL Beta Dokumentation Thomas Jakob 17.04.2011 Inhalt Einrichtung der SQL Umgebung... 3 SQL-Server Installieren... 3 BüroWARE Installieren... 3 PowerBridge-SQL Modus einrichten...

Mehr

ein verteiltes und repliziertes Dateisystem XtreemOS IP project is funded by the European Commission under contract IST-FP6-033576

ein verteiltes und repliziertes Dateisystem XtreemOS IP project is funded by the European Commission under contract IST-FP6-033576 ein verteiltes und repliziertes Dateisystem is funded by the European Commission XtreemOS IPunder project contract IST-FP6-033576 1 Das XtreemOS Projekt Europäisches Forschungsprojekt gefördert von der

Mehr

Technische Beschreibung: EPOD Server

Technische Beschreibung: EPOD Server EPOD Encrypted Private Online Disc Technische Beschreibung: EPOD Server Fördergeber Förderprogramm Fördernehmer Projektleitung Projekt Metadaten Internet Foundation Austria netidee JKU Linz Institut für

Mehr

IBM SPSS Modeler Server 16 for Windows Installationsanweisungen

IBM SPSS Modeler Server 16 for Windows Installationsanweisungen IBM SPSS Modeler Server 16 for Windows Installationsanweisungen Inhaltsverzeichnis Installationsanweisungen....... 1 Systemanforderungen........... 1 Installation............... 1 Ziel................

Mehr

KURZANLEITUNG CLOUD BLOCK STORAGE

KURZANLEITUNG CLOUD BLOCK STORAGE KURZANLEITUNG CLOUD BLOCK STORAGE Version 1.12 01.07.2014 SEITE _ 2 INHALTSVERZEICHNIS 1. Einleitung......Seite 03 2. Anlegen eines dauerhaften Block Storage...Seite 04 3. Hinzufügen von Block Storage

Mehr

Diese Anleitung bezieht sich auf FixFoto, V 3.40. In älteren oder neueren Versionen könnte die Arbeitsweise anders sein.

Diese Anleitung bezieht sich auf FixFoto, V 3.40. In älteren oder neueren Versionen könnte die Arbeitsweise anders sein. Pfade einstellen Stand: Dezember 2012 Diese Anleitung bezieht sich auf FixFoto, V 3.40. In älteren oder neueren Versionen könnte die Arbeitsweise anders sein. Diese Anleitung soll zeigen, wie man Pfad-Favoriten

Mehr

Online Help StruxureWare Data Center Expert

Online Help StruxureWare Data Center Expert Online Help StruxureWare Data Center Expert Version 7.2.7 Virtuelle StruxureWare Data Center Expert-Appliance Der StruxureWare Data Center Expert-7.2-Server ist als virtuelle Appliance verfügbar, die auf

Mehr

PROFI UND NUTANIX. Portfolioerweiterung im Software Defined Data Center

PROFI UND NUTANIX. Portfolioerweiterung im Software Defined Data Center PROFI UND NUTANIX Portfolioerweiterung im Software Defined Data Center IDC geht davon aus, dass Software-basierter Speicher letztendlich eine wichtige Rolle in jedem Data Center spielen wird entweder als

Mehr

ISA Server 2004 - Best Practice Analyzer

ISA Server 2004 - Best Practice Analyzer ISA Server 2004 - Best Practice Analyzer Die Informationen in diesem Artikel beziehen sich auf: Microsoft ISA Server 2004 Seit dem 08.12.2005 steht der Microsoft ISA Server 2004 Best Practice Analyzer

Mehr

phycam VM-012 - Remapping

phycam VM-012 - Remapping Application Note No.: LAN-062d_1 Version: 1.0 Autor: H. Fendrich Date: 20.10.2014 Historie: Version Änderungen Datum Autor 1.0 Erstellung des Dokuments 20.10.2014 H. Fendrich phycam VM-012 - Remapping

Mehr

Shibboleth Clustering und Loadbalancing

Shibboleth Clustering und Loadbalancing Shibboleth Clustering und Loadbalancing STEINBUCH CENTRE FOR COMPUTING - SCC KIT Universität des Landes Baden-Württemberg und nationales Forschungszentrum in der Helmholtz-Gemeinschaft www.kit.edu Computercluster

Mehr

Acronis TrueImage (Version 7.0) Benutzerführung. genutzte Quelle: http://www.acronis.de / Hilfedatei zum Programm Acronis TrueImage Version 7.

Acronis TrueImage (Version 7.0) Benutzerführung. genutzte Quelle: http://www.acronis.de / Hilfedatei zum Programm Acronis TrueImage Version 7. Hier finden Sie von der Firma GriCom Wilhelmshaven eine, um ein Backup Ihres Computers / Ihrer Festplatten zu erstellen und dieses Backup bei Bedarf zur Wiederherstellung zu nutzen. Diese Bedienerführung

Mehr

Angewandte Forschung zu Datenlebenszyklen in der Helmholtz-Gemeinschaft und darüber hinaus

Angewandte Forschung zu Datenlebenszyklen in der Helmholtz-Gemeinschaft und darüber hinaus Angewandte Forschung zu Datenlebenszyklen in der Helmholtz-Gemeinschaft und darüber hinaus Christopher Jung, KIT (SCC) KIT University of the State of Baden-Wuerttemberg and National Research Center of

Mehr

2. DFG- Workshop 3.1. Erfassung/Bewertung/Transfer. Beitrag von Peter Küsters. Spiegelung. Archiv. Bild 1: Unterschied zwischen FTP und Spiegelung

2. DFG- Workshop 3.1. Erfassung/Bewertung/Transfer. Beitrag von Peter Küsters. Spiegelung. Archiv. Bild 1: Unterschied zwischen FTP und Spiegelung 2. DFG- Workshop 3.1. Erfassung/Bewertung/Transfer Beitrag von Peter Küsters Formen des Datentransfers bei der Erfassung von Websites Im folgenden werden Methoden und Software zur Erfassung vorgestellt.

Mehr

Spark, Impala und Hadoop in der Kreditrisikoberechnung

Spark, Impala und Hadoop in der Kreditrisikoberechnung Spark, Impala und Hadoop in der Kreditrisikoberechnung Big Data In-Memory-Technologien für mittelgroße Datenmengen TDWI München, 22. Juni 2015 Joschka Kupilas, Data Scientist, Adastra GmbH 2 Inhalt Vorwort

Mehr

Inhalt: Version 1.7.5

Inhalt: Version 1.7.5 Inhalt: Objekte ohne Methoden Objekte mit einfachen Methoden Objekte und Methoden mit Parametern Objekte und Methoden mit Rückgabewert Objekte mit einem Array als Attribut Beziehungen zwischen Objekten

Mehr

Das Knowledge Grid. Eine Architektur für verteiltes Data Mining

Das Knowledge Grid. Eine Architektur für verteiltes Data Mining Das Knowledge Grid Eine Architektur für verteiltes Data Mining 1 Gliederung 1. Motivation 2. KDD und PDKD Systeme 3. Knowledge Grid Services 4. TeraGrid Projekt 5. Das Semantic Web 2 Motivation Rapide

Mehr

Clouds. Erwartungen der Nutzer. Wolkig bis Heiter. (c) 2013, Peter Sturm, Universität Trier. Er ist verwöhnt! Er ist nicht dankbar!

Clouds. Erwartungen der Nutzer. Wolkig bis Heiter. (c) 2013, Peter Sturm, Universität Trier. Er ist verwöhnt! Er ist nicht dankbar! Clouds Wolkig bis Heiter Erwartungen der Nutzer Er ist verwöhnt! Verfügbarkeit Viele Anwendungen Intuitive Interfaces Hohe Leistung Er ist nicht dankbar! Mehr! Mehr! Mehr! Moore 1 Erwartungen der Entwickler

Mehr

RIWA NetUpdater Tool für automatische Daten- und Softwareupdates

RIWA NetUpdater Tool für automatische Daten- und Softwareupdates RIWA NetUpdater Tool für automatische Daten- und Softwareupdates Grundlegendes... 1 Ausführbare Dateien und Betriebsmodi... 2 netupdater.exe... 2 netstart.exe... 2 netconfig.exe... 2 nethash.exe... 2 Verzeichnisse...

Mehr

Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz

Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC. Alexander Scholz Hochverfügbar und Skalierung mit und ohne RAC Szenarien zu Hochverfügbarkeit und Skalierung mit und ohne Oracle RAC Alexander Scholz Copyright its-people Alexander Scholz 1 Einleitung Hochverfügbarkeit

Mehr

White Paper. Embedded Treiberframework. Einführung

White Paper. Embedded Treiberframework. Einführung Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded

Mehr

Session Storage im Zend Server Cluster Manager

Session Storage im Zend Server Cluster Manager Session Storage im Zend Server Cluster Manager Jan Burkl System Engineer, Zend Technologies Agenda Einführung in Zend Server und ZSCM Überblick über PHP Sessions Zend Session Clustering Session Hochverfügbarkeit

Mehr

> Soft.ZIV. Soft.ZIV Zentrales Dateisystem des ZIV für die Softwareverteilung

> Soft.ZIV. Soft.ZIV Zentrales Dateisystem des ZIV für die Softwareverteilung > Soft.ZIV Soft.ZIV Zentrales Dateisystem des ZIV für die Softwareverteilung Inhaltsverzeichnis Hersteller, Produkte, Versionen - Organisation von Soft.ZIV... 3 Viele Wege führen zur CD-ROM - Zugriff auf

Mehr

Hadoop-as-a-Service (HDaaS)

Hadoop-as-a-Service (HDaaS) Hadoop-as-a-Service (HDaaS) Flexible und skalierbare Referenzarchitektur Arnold Müller freier IT Mitarbeiter und Geschäftsführer Lena Frank Systems Engineer @ EMC Marius Lohr Systems Engineer @ EMC Fallbeispiel:

Mehr

Kurzbeschreibung PC-Software für das Gerät URO-2050

Kurzbeschreibung PC-Software für das Gerät URO-2050 Kurzbeschreibung PC-Software für das Gerät URO-2050 1 Einleitung 1.1 Allgemeines Das Programm kann zum Verwalten der durchgeführten Untersuchungen mit dem Gerät URO-2050 benutzt werden. Es funktioniert

Mehr

Projektphasen und Technische Vorbereitung eines NX Refiles mit dem PLMJobManager

Projektphasen und Technische Vorbereitung eines NX Refiles mit dem PLMJobManager Projektphasen und Technische Vorbereitung eines NX Refiles mit dem PLMJobManager Dieses Dokument dient zur Information über die Organisation der Projektphasen und der technischen Vorbereitung eines Refile

Mehr

HVS32. ein Versandsystem das immer passt. Dokumentation. SAP-IDoc Schnittstelle

HVS32. ein Versandsystem das immer passt. Dokumentation. SAP-IDoc Schnittstelle ein Versandsystem das immer passt Dokumentation SAP-IDoc Schnittstelle Inhalt 1 HVS32 Anbindung an SAP mit IDocs...2 1.1 Integration...2 1.1.1 HVS32...2 1.1.2 HVS32-Gateway...2 1.2 Ablauf...3 2 IDoc Typen...4

Mehr

TECHNISCHE PRODUKTINFORMATION CARUSO

TECHNISCHE PRODUKTINFORMATION CARUSO 1111 TECHNISCHE PRODUKTINFORMATION CARUSO TECHNISCHE PRODUKTINFORMATION Seite 0/7 Inhalt 1 Systemdefinition............2 2 Technische Details für den Betrieb von CARUSO......2 2.1 Webserver... 2 2.2 Java

Mehr

Data Mining in der Cloud

Data Mining in der Cloud Data Mining in der Cloud von Jan-Christoph Meier Hamburg, 21.06.2012 1 Ablauf Einführung Verwandte Arbeiten Fazit / Ausblick Literatur 2 Ablauf Einführung Verwandte Arbeiten Fazit / Ausblick Literatur

Mehr

Projekt AGB-10 Fremdprojektanalyse

Projekt AGB-10 Fremdprojektanalyse Projekt AGB-10 Fremdprojektanalyse 17. Mai 2010 1 Inhaltsverzeichnis 1 Allgemeines 3 2 Produktübersicht 3 3 Grundsätzliche Struktur und Entwurfsprinzipien für das Gesamtsystem 3 3.1 Die Prefuse Library...............................

Mehr

MGE Datenanbindung in GeoMedia

MGE Datenanbindung in GeoMedia TIPPS & TRICKS MGE Datenanbindung in GeoMedia 10. September 2002 / AHU INTERGRAPH (Schweiz) AG Neumattstrasse 24, CH 8953 Dietikon Tel: 043 322 46 46 Fax: 043 322 46 10 HOTLINE: Telefon: 043 322 46 00

Mehr

Kurzanleitung - XVA Provider unter Mac OSX 10

Kurzanleitung - XVA Provider unter Mac OSX 10 Kurzanleitung - XVA Provider unter Mac OSX 10 Installation und Bedienung- Inhalt Allgemeine Hinweise:... 1 Kapitel 1 Installation und Konfiguration... 2 Schritt 1: Java SE Development Kit 6 installieren:...

Mehr

Möglichkeiten der E-Mail- Archivierung für Exchange Server 2010 im Vergleich

Möglichkeiten der E-Mail- Archivierung für Exchange Server 2010 im Vergleich Möglichkeiten der E-Mail- Archivierung für Exchange Server 2010 im Vergleich Seit Microsoft Exchange Server 2010 bieten sich für Unternehmen gleich zwei mögliche Szenarien an, um eine rechtskonforme Archivierung

Mehr

Heterogenes Speichermanagement mit V:DRIVE

Heterogenes Speichermanagement mit V:DRIVE Heterogenes Speichermanagement mit V:DRIVE V:DRIVE - Grundlage eines effizienten Speichermanagements Die Datenexplosion verlangt nach innovativem Speichermanagement Moderne Businessprozesse verlangen auf

Mehr

WEBINAR@LUNCHTIME THEMA: SAS ADMINISTRATION LEICHT GEMACHT MIT SAS 9.4 ALLE SYSTEME IM BLICK" ANKE FLEISCHER

WEBINAR@LUNCHTIME THEMA: SAS ADMINISTRATION LEICHT GEMACHT MIT SAS 9.4 ALLE SYSTEME IM BLICK ANKE FLEISCHER WEBINAR@LUNCHTIME THEMA: SAS ADMINISTRATION LEICHT GEMACHT MIT SAS 9.4 ALLE SYSTEME IM BLICK" ANKE FLEISCHER EBINAR@LUNCHTIME HERZLICH WILLKOMMEN BEI WEBINAR@LUNCHTIME Moderation Anne K. Bogner-Hamleh

Mehr

MapReduce-Konzept. Thomas Findling, Thomas König

MapReduce-Konzept. Thomas Findling, Thomas König MapReduce - Konzept 1 Inhalt 1. Motivation 2. Einführung MapReduce Google Rechenzentren Vergleich MapReduce und Relationale DBS 3. Hadoop Funktionsweise Input / Output Fehlerbehandlung 4. Praxis-Beispiel

Mehr

WI EDI Solution. Stand 17.02.2012

WI EDI Solution. Stand 17.02.2012 WI EDI Solution Stand 17.02.2012 WIAG Überblick 2011 - SAP, SAP BW, SAP SEM/BPS, SAP BPC, SAP R/3, ABAP, Netweaver sind eingetragene Warenzeichen der SAP AG, Walldorf Folie 1 Inhalt Was ist WIEDIS? IDOC

Mehr

Acronis Universal Restore

Acronis Universal Restore Acronis Universal Restore BENUTZERANLEITUNG Inhaltsverzeichnis 1 Was ist Acronis Universal Restore?...3 2 Acronis Universal Restore installieren...3 3 Bootfähige Medien erstellen...3 4 Acronis Universal

Mehr

Hochschule Darmstadt - Fachbereich Informatik - Fachschaft des Fachbereiches

Hochschule Darmstadt - Fachbereich Informatik - Fachschaft des Fachbereiches Hochschule Darmstadt - Fachbereich Informatik - Fachschaft des Fachbereiches Verwendung der bereitgestellten Virtuellen Maschinen»Einrichten einer Virtuellen Maschine mittels VirtualBox sowie Zugriff auf

Mehr

Archivierung von digitalen Daten Lösungsansätze mit SIARD und OAIS

Archivierung von digitalen Daten Lösungsansätze mit SIARD und OAIS Archivierung von digitalen Daten Lösungsansätze mit SIARD und OAIS Informationsveranstaltung Forschungsarbeit im Bereich Historisierung und Archivierung von Geodaten Bern, 3. Juli 2009 Dr. K. Ohnesorge

Mehr

Einführung in die Cross-Plattform Entwicklung Das Intel XDK

Einführung in die Cross-Plattform Entwicklung Das Intel XDK Einführung in die Cross-Plattform Entwicklung Das Intel XDK Einführung Dieses Hands-on-Lab (HOL) macht den Leser mit dem Intel XDK vertraut. Es wird Schritt für Schritt die erste eigene Hybrid-App entwickelt

Mehr

TERRA X5.Filialabgleich Client

TERRA X5.Filialabgleich Client TERRA X5.Filialabgleich Client Inhaltsverzeichnis TERRA X5.Filialabgleich Client...1 Installation...3 Mindestvoraussetzungen...3 Der erste Start / die Konfiguration...4 Das Hauptfenster...5 Installation

Mehr

Objektorientiertes Programmieren für Ingenieure

Objektorientiertes Programmieren für Ingenieure Uwe Probst Objektorientiertes Programmieren für Ingenieure Anwendungen und Beispiele in C++ 18 2 Von C zu C++ 2.2.2 Referenzen und Funktionen Referenzen als Funktionsparameter Liefert eine Funktion einen

Mehr

Hadoop aus IT-Operations Sicht Teil 2 Hardware- und Netzwerk-Grundlagen

Hadoop aus IT-Operations Sicht Teil 2 Hardware- und Netzwerk-Grundlagen Hadoop aus IT-Operations Sicht Teil 2 Hardware- und Netzwerk-Grundlagen Brownbag am Freitag, den 09.08.2013 Daniel Bäurer inovex GmbH Systems Engineer Wir nutzen Technologien, um unsere Kunden glücklich

Mehr

Zero Effort Backup (ZEB) automatische Datensicherung über das Internet

Zero Effort Backup (ZEB) automatische Datensicherung über das Internet Ralph Lehmann. Computerservice und IT-Beratung. Kochstraße 34. 04275 Leipzig Ralph Lehmann Computerservice und IT-Beratung Kochstraße 34 04275 Leipzig Ralph Lehmann Computerservice und IT-Beratung Tel.:

Mehr

Präsentation. homevisu Familie. Peter Beck. Juni 2011. www.p-b-e.de. 2011 p b e Peter Beck 1

Präsentation. homevisu Familie. Peter Beck. Juni 2011. www.p-b-e.de. 2011 p b e Peter Beck 1 Präsentation homevisu Familie Peter Beck Juni 2011 2011 p b e Peter Beck 1 Funktionensumfang Der Funktionsumfang das provisu Framework. Modular und durch Plug-In erweiterbar / anpassbar. Plug-In Schnittstelle

Mehr

Visualisierung. Grid-Computing Seminar SS04 Prof. Dr. Fuhr, Universität Duisburg-Essen

Visualisierung. Grid-Computing Seminar SS04 Prof. Dr. Fuhr, Universität Duisburg-Essen Grid-Computing Seminar SS04 Prof. Dr. Fuhr, Universität Duisburg-Essen Visualisierung Basierend auf den Artikeln: GridMapper: A Tool for Visualizing the Behavior of Large-Scale Distributed Systems, von

Mehr

PDF FormServer Quickstart

PDF FormServer Quickstart PDF FormServer Quickstart 1. Voraussetzungen Der PDF FormServer benötigt als Basis einen Computer mit den Betriebssystemen Windows 98SE, Windows NT, Windows 2000, Windows XP Pro, Windows 2000 Server oder

Mehr

Userhandbuch. Version B-1-0-2 M

Userhandbuch. Version B-1-0-2 M Userhandbuch Version B-1-0-2 M Inhaltsverzeichnis 1.0 Was bietet mir SERVRACK?... 3 1.1 Anmeldung... 3 1.2 Passwort vergessen?... 3 1.3 Einstellungen werden in Realtime übernommen... 4 2.0 Die SERVRACK

Mehr

Leistungsbeschreibung. PHOENIX Archiv. Oktober 2014 Version 1.0

Leistungsbeschreibung. PHOENIX Archiv. Oktober 2014 Version 1.0 Leistungsbeschreibung PHOENIX Archiv Oktober 2014 Version 1.0 PHOENIX Archiv Mit PHOENIX Archiv werden Dokumente aus beliebigen Anwendungen dauerhaft, sicher und gesetzeskonform archiviert. PHOENIX Archiv

Mehr

Managed VPSv3 Was ist neu?

Managed VPSv3 Was ist neu? Managed VPSv3 Was ist neu? Copyright 2006 VERIO Europe Seite 1 1 EINFÜHRUNG 3 1.1 Inhalt 3 2 WAS IST NEU? 4 2.1 Speicherplatz 4 2.2 Betriebssystem 4 2.3 Dateisystem 4 2.4 Wichtige Services 5 2.5 Programme

Mehr

RAID. Name: Artur Neumann

RAID. Name: Artur Neumann Name: Inhaltsverzeichnis 1 Was ist RAID 3 1.1 RAID-Level... 3 2 Wozu RAID 3 3 Wie werden RAID Gruppen verwaltet 3 3.1 Software RAID... 3 3.2 Hardware RAID... 4 4 Die Verschiedenen RAID-Level 4 4.1 RAID

Mehr

Windows SharePoint Services als gemeinsamen Dateispeicher einrichten

Windows SharePoint Services als gemeinsamen Dateispeicher einrichten Windows SharePoint Services als gemeinsamen Dateispeicher einrichten (Engl. Originaltitel: Setting up Windows SharePoint Services as a Collaborative File Store) Dustin Friesenhahn Veröffentlicht: August

Mehr

SmartExporter 2013 R1

SmartExporter 2013 R1 Die aktuelle Version wartet mit zahlreichen neuen Features und umfangreichen Erweiterungen auf. So können mit SmartExporter 2013 R1 nun auch archivierte Daten extrahiert und das Herunterladen der Daten

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

VCM Solution Software

VCM Solution Software VCM Solution Software Die BORUFA VCM Solution ist ein umfangreiches Werkzeug für virtuelles Content Management basierend auf hochauflösenden vollsphärischen Bildern, 360 Videos und Punktwolken. In der

Mehr

Hardware- und Software-Anforderungen IBeeS.ERP

Hardware- und Software-Anforderungen IBeeS.ERP Hardware- und Software-Anforderungen IBeeS.ERP IBeeS GmbH Stand 08.2015 www.ibees.de Seite 1 von 8 Inhalt 1 Hardware-Anforderungen für eine IBeeS.ERP - Applikation... 3 1.1 Server... 3 1.1.1 Allgemeines

Mehr

Nutzerhandbuch für LSDF-DIS am SCC/KIT

Nutzerhandbuch für LSDF-DIS am SCC/KIT Nutzerhandbuch für LSDF-DIS am SCC/KIT Steinbuch Centre for Computing, KIT Version 0.7 Inhaltsverzeichnis 1 Einleitung... 1 2 Registrierung... 1 3 Zugangsprotokolle... 4 3.1 Zugriff über Network File System

Mehr

Installation des edu- sharing Plug- Ins für Moodle

Installation des edu- sharing Plug- Ins für Moodle Installation des edu- sharing Plug- Ins für Moodle [edu-sharing Team] [Dieses Dokument beschreibt die Installation und Konfiguration des edu-sharing Plug-Ins für das LMS Moodle.] edu- sharing / metaventis

Mehr

Browserbasiertes, kollaboratives Whiteboard

Browserbasiertes, kollaboratives Whiteboard WS 2011/12 Bachelorarbeit Browserbasiertes, kollaboratives Whiteboard Sebastian Dorn 1 von 21 Inhalt 1. Motivation 2. Analyse 3. Design 4. Evaluation 5. Fazit Inhalt 2 von 21 Motivation Zusammenarbeit

Mehr

Betriebssysteme WS 2012/13 Peter Klingebiel, DVZ. Zusammenfassung Kapitel 4 - Datenträger/Dateiverwaltung

Betriebssysteme WS 2012/13 Peter Klingebiel, DVZ. Zusammenfassung Kapitel 4 - Datenträger/Dateiverwaltung Betriebssysteme WS 2012/13 Peter Klingebiel, DVZ Zusammenfassung Kapitel 4 - Datenträger/Dateiverwaltung Zusammenfassung Kapitel 4 Dateiverwaltung 1 Datei logisch zusammengehörende Daten i.d.r. permanent

Mehr

dsmisi Storage Lars Henningsen General Storage

dsmisi Storage Lars Henningsen General Storage dsmisi Storage dsmisi MAGS Lars Henningsen General Storage dsmisi Storage Netzwerk Zugang C Zugang B Zugang A Scale-Out File System dsmisi Storage Netzwerk Zugang C Zugang B Zugang A benötigt NFS oder

Mehr

Database Exchange Manager. Infinqa IT Solutions GmbH, Berlin Stralauer Allee 2 10245 Berlin Tel.:+49(0) 30 2900 8639 Fax.:+49(0) 30 2900 8695

Database Exchange Manager. Infinqa IT Solutions GmbH, Berlin Stralauer Allee 2 10245 Berlin Tel.:+49(0) 30 2900 8639 Fax.:+49(0) 30 2900 8695 Database Exchange Manager Replication Service- schematische Darstellung Replication Service- allgemeines Replikation von Daten von bzw. in ein SAP-System und einer relationalen DMS-Datenbank Kombination

Mehr

Die wichtigsten Funktionen von Red Hat Storage Server 2.0 im Überblick:

Die wichtigsten Funktionen von Red Hat Storage Server 2.0 im Überblick: Red Hat Storage Server Die wichtigsten Funktionen von Red Hat Storage Server 2.0 im Überblick: Offene Software Lösung für Storage Ansprache über einen globalen Namensraum Betrachtet Storage als einen virtualisierten

Mehr

7 Dateien und Datenströme (Streams)

7 Dateien und Datenströme (Streams) 7 Dateien und Datenströme (Streams) Jörn Loviscach Versionsstand: 21. März 2014, 22:57 Die nummerierten Felder sind absichtlich leer, zum Ausfüllen beim Ansehen der Videos: http://www.j3l7h.de/videos.html

Mehr

Teamprojekt & Projekt

Teamprojekt & Projekt 18. Oktober 2010 Teamprojekt & Projekt Veranstalter: Betreuer: Prof. Dr. Georg Lausen Thomas Hordnung, Alexander Schätzle, Martin Przjyaciel-Zablocki dbis Studienordnung Master: 16 ECTS 480 Semesterstunden

Mehr

Datenaustausch mit Mac / PC & HeadCook / Ecoshop

Datenaustausch mit Mac / PC & HeadCook / Ecoshop Datenaustausch mit Mac / PC & HeadCook / Ecoshop 2008-2011 InnoBytes, Wolfgang Kohrt 1 Inhalt! Allgemeines! 3 1. Vorbereitungen! 4 1.1 Vorbereitungen für MacOSX 10! 4 1.2 Vorbereitungen für Windows XP/Vista/7!

Mehr

Handbuch für ios 1.4 1

Handbuch für ios 1.4 1 Handbuch für ios 1.4 1 Inhaltsverzeichnis 1. Leistungsumfang... 3 1.1 Über Boxcryptor Classic... 3 1.2 Über dieses Handbuch... 4 2. Installation... 5 3. Grundfunktionen... 6 3.1. Einrichtung von Boxcryptor

Mehr

Upgrade auf die Standalone Editionen von Acronis Backup & Recovery 10. Technische Informationen (White Paper)

Upgrade auf die Standalone Editionen von Acronis Backup & Recovery 10. Technische Informationen (White Paper) Upgrade auf die Standalone Editionen von Acronis Backup & Recovery 10 Technische Informationen (White Paper) Inhaltsverzeichnis 1. Über dieses Dokument... 3 2. Überblick... 3 3. Upgrade Verfahren... 4

Mehr

Cloud-Computing Seminar - Vergleichende Technologien: Grid-Computing Hochschule Mannheim

Cloud-Computing Seminar - Vergleichende Technologien: Grid-Computing Hochschule Mannheim Sven Hartlieb Cloud-Computing Seminar Hochschule Mannheim WS0910 1/23 Cloud-Computing Seminar - Vergleichende Technologien: Grid-Computing Hochschule Mannheim Sven Hartlieb Fakultät für Informatik Hochschule

Mehr

Datenbanksystem. System Global Area. Hintergrundprozesse. Dr. Frank Haney 1

Datenbanksystem. System Global Area. Hintergrundprozesse. Dr. Frank Haney 1 Datenbanksystem System Global Area Hintergrundprozesse Dr. Frank Haney 1 Komponenten des Datenbanksystems System Global Area Program Global Area Hintergrundprozesse Dr. Frank Haney 2 System Global Area

Mehr

SmarTeam MS Outlook Integration Version 3.1 Beschreibung des Funktionsumfangs

SmarTeam MS Outlook Integration Version 3.1 Beschreibung des Funktionsumfangs SmarTeam MS Outlook Integration Version 3.1 Beschreibung des Funktionsumfangs Der Aufbau der MS Outlook Integration orientiert sich stark an den SmarTeam Integrationen zu den MS Office Produkten, wobei

Mehr

Oracle Data Warehouse Mit Big Data neue Horizonte für das Data Warehouse ermöglichen

Oracle Data Warehouse Mit Big Data neue Horizonte für das Data Warehouse ermöglichen DATA WAREHOUSE Oracle Data Warehouse Mit Big Data neue Horizonte für das Data Warehouse ermöglichen Alfred Schlaucher, Detlef Schroeder DATA WAREHOUSE Themen Big Data Buzz Word oder eine neue Dimension

Mehr

Änderungen erkennen Schneller handeln Stefan Panek. Senior Consultant Christoph Jansen. Consultant 23.10.2008

Änderungen erkennen Schneller handeln Stefan Panek. Senior Consultant Christoph Jansen. Consultant 23.10.2008 Änderungen erkennen Schneller handeln Stefan Panek. Senior Consultant Christoph Jansen. Consultant 23.10.2008 Seit der Datenbankversion 9i bietet Oracle das Feature Change Data Capture an. Aber was genau

Mehr