White Paper Lösungsansätze für Big Data

Größe: px
Ab Seite anzeigen:

Download "White Paper Lösungsansätze für Big Data"

Transkript

1 White Paper Lösungsansätze für Big Data Das Thema Big Data gewinnt für immer mehr Unternehmen an Bedeutung. Es werden neue Anwendungsfelder erschlossen, bei denen riesige Datenmengen automatisch und kontinuierlich aus unterschiedlichen Datenquellen generiert werden. Bei der Auswertung dieser Daten stößt die traditionelle IT jedoch an ihre Grenzen. Wie lassen sich der hohe Komplexitätsgrad und die Beschränkungen bei der Verarbeitungsgeschwindigkeit überwinden? Verschiedene Lösungsansätze wurden erfolgreich erprobt und bereits produktiv eingesetzt. In diesem White Paper möchte Fujitsu Ihnen Einblicke darin vermitteln, wie in welcher Situation vorzugehen ist. Inhalt Unternehmerisches Wunschdenken 2 Daten Der größte Aktivposten eines jeden Unternehmens 2 Klassische Business Intelligence 2 Die Situation hat sich geändert 2 Veränderte Anforderungen an die Business Intelligence 3 Big Data Worum geht es dabei eigentlich? 3 Warum traditionelle Lösungen ungeeignet sind 4 Verteilte Parallelverarbeitung 5 Apache Hadoop 5 Hadoop Distributed File System (HDFS) 5 Hadoop MapReduce 6 YARN (Yet Another Resource Negotiator) 6 Apache Hadoop-Unterprojekte 7 Die destillierte Essenz von Big Data 7 In-Memory Plattform 8 In-Memory Datenbanken (IMDB) 8 In-Memory Data Grid (IMDG) 9 Infrastrukturoptimierung für relationale Datenbanken 9 Datenbanken für Big Data 10 Complex Event Processing 12 Referenzarchitektur für Big Data 13 Bei Big Data geht es aber nicht nur um die Infrastruktur 14 Ihr Weg zu Big Data 14 Betrieb von Big-Data-Infrastrukturen 15 IaaS, PaaS, SaaS oder sogar Data Science als Service? 15 Welchen Beitrag kann Fujitsu leisten? 16 Zusammenfassung 16 Seite 1 von 16

2 Unternehmerisches Wunschdenken Die Steigerung von Rentabilität und Erlösen hat in Unternehmen normalerweise oberste Priorität. Hierzu ist eine beständige Steigerung von Leistungsfähigkeit und Produktivität der Mitarbeiter sowie der Effizienz und Wettbewerbsfähigkeit des Unternehmens als Ganzes bei gleichzeitiger Risikominimierung erforderlich. Die spannende Frage lautet nun, wie sich dies schneller, effektiver und in größerem Umfang erreichen lässt als bei den Mitbewerbern. Wie wäre es, wenn Sie voraussagen könnten, wie sich Trends, das Verhalten der Kunden oder geschäftliche Chancen entwickeln werden? Wenn Sie stets die optimale Entscheidung treffen würden? Wenn Sie die Entscheidungsfindung beschleunigen könnten? Wenn entscheidende Maßnahmen automatisch ergriffen würden? Wenn Sie Probleme und Kosten bis zu ihrem Ursprung zurückverfolgen könnten? Wenn sich sinnlose Aktivitäten eliminieren ließen? Wenn sich Risiken exakt quantifizieren und auf ein Minimum reduzieren ließen? Die traditionelle BI nutzt hauptsächlich interne und historische Datenbank-Views, die sich aus einigen wenigen Datenquellen speisen. Die Daten werden strukturiert und typischerweise in einem relationalen Datenbankmanagementsystem (RDBMS) gespeichert. Business Analytics-Vorgänge werden auf Grundlage eines statischen Modells entworfen und in regelmäßigen Abständen täglich, wöchentlich oder monatlich als Batchverarbeitung ausgeführt. Da der durchschnittliche Benutzer meist nicht entsprechend geschult ist, um komplexe Analysen in Eigenregie zu erstellen, ist die Zahl derjenigen, die Abfragen ausführen oder sich mit der Auswertung von Unternehmensdaten beschäftigen, auf einige wenige Fachanwender beschränkt. Bei der Betrachtung solcher Fragen denken viele Manager sofort an die Chancen, die sich daraus für ihr Unternehmen ergeben. Sind dies jedoch lediglich Wunschträume, oder besteht die Chance, dass sie eines Tages verwirklicht werden können? Daten Der größte Aktivposten eines jeden Unternehmens Neben den Mitarbeitern sind Daten die wertvollste Ressource eines jeden Unternehmens. Bereits vor Jahrzehnten wurde dies erkannt, und man versuchte, Daten profitbringend einzusetzen. Es lag auf der Hand, dass durch die intelligente Nutzung von Daten eine Entscheidungsfindung möglich wurde, die auf fundierten Fakten und nicht auf Intuition beruhte. Hierdurch konnten geschäftliche Abläufe verbessert, das Risiko minimiert, Kosten reduziert und das Geschäft im Allgemeinen gefördert werden. Eine weitere wichtige Erkenntnis bestand darin, dass Daten in ihrer ursprünglichen Form normalerweise nur von geringem Wert waren. Aus diesem Grund wurden Daten aus abrufbereiten Datenquellen hauptsächlich aus transaktionalen Datenbanken erfasst, konsolidiert und in eine für die Analyse geeignete Form gebracht, um Beziehungen, Muster und Grundsätze und damit letztendlich ihren echten Wert zu ermitteln. Genau dies war anfänglich der Grundgedanke der Business Intelligence (BI). Klassische Business Intelligence Im Rahmen der Business Intelligence werden die aufbereiteten Daten geladen und in einer speziellen Datenbank gespeichert, dem so genannten Data Warehouse. Dieses ist von den Transaktionssystemen getrennt, um diese nicht mit der Analyse von Unternehmensdaten, der Berichterstellung oder der Visualisierung von Abfrageergebnissen zu belasten. Data Warehouses sind für die Generierung von Reports optimiert. Aus Leistungs- oder Berechtigungsgründen werden multidimensionale Intervalle oder andere spezielle Datenbankansichten als Auszüge des Data Warehouse erstellt. Diese so genannten Cubes oder Data Marts können dann für eine tiefgreifende Analyse oder zur Generierung rollenspezifischer Berichte genutzt werden. Die Situation hat sich geändert Seit den Anfangszeiten der BI haben sich die Dinge erheblich geändert. Es sind eine Reihe vielseitig nutzbarer Datenquellen hinzugekommen, die es zu berücksichtigen gilt. Neben transaktionalen Datenbanken sind es insbesondere die Daten aus dem Internet in Form von Blog-Inhalten oder Click-Streams, die wertvolle Informationen enthalten, ganz zu schweigen von den Inhalten der sozialen Medien, die sich zu den am häufigsten genutzten Kommunikationsplattformen entwickelt haben. Auch aus Multimedia-Daten, z. B. Video, Foto oder Audio, lassen sich Rückschlüsse für unternehmerische Entscheidungen ziehen. Es existiert ein riesiger Fundus an Textdateien, darunter schier endlose Protokolldateien aus IT-Systemen, Notizen und s, die ebenfalls Indikatoren enthalten, die für Unternehmen interessant sein könnten. Und nicht zuletzt gibt es noch eine Myriade von Sensoren, die in Smartphones, Fahrzeugen, Gebäuden, Robotersystemen, Geräten und Apparaten, intelligenten Netzwerken schlichtweg in jedem Gerät, das Daten erfasst in einem Umfang verbaut wurden, der noch vor Kurzem unvorstellbar war. Diese Sensoren bilden die Grundlage für das sich im Aufbau befindliche, vielfach zitierte Internet der Dinge. Aus branchenspezifischer Sicht wären außerdem medizinische Untersuchungen im Gesundheitswesen, RFID-Etiketten zur Verfolgung beweglicher Güter sowie geophysische oder dreidimensionale Raumdaten (z. B. GPS-gestützte Ortsdaten) oder Daten von Beobachtungssatelliten zu nennen. Diese Aufzählung ist bei weitem nicht vollständig. Seite 2 von 16

3 Natürlich nimmt das Volumen bei allen Arten von Daten beständig zu, aber es sind insbesondere die Sensoren mit ihren automatisch und kontinuierlich generierten Ereignisdaten, die in Zukunft einen enormen Einfluss haben werden. Es überrascht daher kaum, dass wir uns einem exponentiellen Datenwachstum gegenüber sehen. Schauen wir uns einmal ein wenig genauer an, was diese exponentielle Datenentwicklung eigentlich bedeutet. Die Experten sprechen von einem Datenvolumen von 2,5 x Byte, das täglich hinzukommt. Dabei stammen 90 % aller vorhandenen Daten aus den letzten zwei Jahren. Das Datenvolumen steigt jährlich um 65 % an. Dies entspricht einer Verdopplung der Datenmenge alle 18 Monate bzw. einem Wachstum um den Faktor 12 alle fünf Jahre im Vergleich zum heutigen Stand. Mithin geht es hier nicht nur um Terabyte, sondern um Petabyte, Exabyte, Zettabyte und sogar Yottabyte, und ein Ende ist nicht abzusehen. Viele IT-Manager haben daher das Gefühl, in einer Flut aus Daten buchstäblich unterzugehen. Dabei geht es nicht nur um die Vielzahl von Datenquellen und das anwachsende Datenvolumen, sondern auch um neue Datentypen, die laufend hinzukommen. In der klassischen BI wurden lediglich strukturierte Daten in den festen Tabellenfeldern relationaler Datenbanken berücksichtigt. Heute ist der Großteil der Daten unstrukturiert Experten sprechen dabei von mehr als 80 %. Unstrukturierte Daten sind etwa Textdaten wie Artikel, s und andere Dokumente, oder Daten, die nicht in Textform vorliegen, z. B. Audio, Video oder Bilddaten. Zusätzlich zu strukturierten und unstrukturierten Daten gibt es außerdem semistrukturierte Daten, die nicht in festen Datenfeldern vorliegen, sondern durch so genannte Tags in aufeinander folgende Datenelemente unterteilt werden. Beispiele für semistrukturierte Daten sind XML-, HTML- und PDF/A-Daten sowie RSS-Feeds. Abschließend sind noch die polystrukturierten Daten zu nennen, die aus einer Vielzahl unterschiedlicher Datenstrukturen bestehen, die sich zusätzlich noch verändern können. Beispiele für polystrukturierte Daten sind elektronische Datensätze in Form von XML-Dokumenten mit PDF/A-Elementen oder unterschiedliche Versionen eines Dokuments, die sich in der Anzahl der Elemente oder sogar in der Version des zugrunde liegenden XML-Schemas unterscheiden. Veränderte Anforderungen an die Business Intelligence Interessant ist, welche Auswirkungen all diese Überlegungen auf die Business Intelligence von heute haben. Aus unternehmerischer Sicht wurde nämlich schnell klar, dass sich aus dieser Vielzahl unterschiedlicher Datenquellen mit ihren riesigen, aber bislang ungenutzten Datenbeständen egal ob diese strukturiert, unstrukturiert, semistrukturiert oder polystrukturiert vorliegen immenser Nutzen schlagen lässt. Aber im Gegensatz zur klassischen BI, als es noch Stunden dauerte, um Berichte im Batchverfahren zu generieren, werden heutzutage Ad-hoc-Abfragen mit Analyseergebnissen in Echtzeit erwartet, die die Grundlage für umgehende, proaktive Entscheidungen bilden oder sogar ein automatisiertes Eingreifen ermöglichen. Hinzu kommt, dass sich die Datenanalyse nicht mehr mit der Beschreibung vergangener Ereignisse allein beschäftigt, sondern vorherzusagen versucht, was in Zukunft passieren wird. Aufgrund der Vielzahl von Anwendungsmöglichkeiten und Chancen, die sich aus dieser Datenvielfalt ergibt, gibt es aber auch weitaus mehr Benutzer, die sich einen direkten Zugriff auf Analysedaten wünschen, und dies nicht nur vom Büro aus, sondern ortsungebunden von jedem Gerät aus, sei es ein Laptop-Computer, ein Smartphone oder etwas anderes. Natürlich muss eine Lösung, die all dies ermöglicht, zuallererst auch effizient und kostengünstig sein. Hiermit wurden die Grundlagen für ein neues Modewort und eines der am meisten diskutierten Themen in der heutigen IT geschaffen: Big Data. Big Data Worum geht es dabei eigentlich? Big Data vereint alle oben erörterten Eigenschaften von Daten. Big Data kann für Unternehmen zum Problem werden, bietet aber auch die Chance, sich einen Wettbewerbsvorteil zu erarbeiten. Big Data beginnt bei Datenvolumen im Bereich mehrerer Terabyte und darüber hinaus mehrere Petabyte sind keine Seltenheit, oft in Form unterschiedlicher Datentypen (strukturiert, unstrukturiert, semistrukturiert und polystrukturiert) aus verschiedenen, geografisch verteilten Datenquellen. Die Daten werden häufig mit hoher Geschwindigkeit generiert und müssen in Echtzeit verarbeitet und analysiert werden. Manchmal verlieren Daten genauso schnell ihre Gültigkeit, wie sie generiert wurden. Inhaltlich gesehen können Daten durchaus ambivalent sein, was ihre Interpretation zu einer echten Herausforderung macht. Bei Big Data geht es jedoch nicht nur um die Daten selbst, sondern auch um erschwingliche Systeme, die Speicherung, Erschließung und Analyse riesiger Datenmengen in Echtzeit ermöglichen. Dank Verarbeitung in höchster Geschwindigkeit können Abfragen immer weiter verfeinert und die Abfrageergebnisse so Schritt für Schritt verbessert werden. Auf diese Weise ist ein großer Benutzerkreis auch ohne tiefgreifende Vorkenntnisse in der Lage, produktiv mit Analysedaten umzugehen etwas das noch vor kurzem absolut unvorstellbar gewesen wäre. Big Data verschafft also einen unkomplizierten Zugang zu Analysedaten, und damit zu Wissen, und zwar allen, die diesen Zugang benötigen,. Seite 3 von 16

4 Auf die Frage, ob Sie sich mit dem Thema Big Data überhaupt beschäftigen sollten, gibt es eine relativ einfache Antwort. Führen Sie sich einfach vor Augen, dass Sie derzeitig durchschnittlich 5 % Ihrer verfügbaren Daten für Analysezwecke nutzen, was umgekehrt bedeutet, dass 95 % Ihrer Daten brach liegen. Wenn Sie die Möglichkeiten von Big Data ignorieren und sich mit 5 % begnügen, Ihre Mitbewerber deren Wirkungsgrad bei der Datennutzung ähnlich aussehen dürfte aber dank Big Data-Technologien 15 % ihrer Daten erschließen, ist es ziemlich offensichtlich, wer am Ende erfolgreicher sein wird. Der Nutzen von Big Data Unternehmen können vielfältigen Nutzen aus Big Data ziehen. Sie gewinnen Erkenntnisse über Kunden, Zulieferer und andere Geschäftspartner, über Märkte und Betriebsabläufe, über die Ursachen von Problemen und Kosten und über die potenziellen Risiken, mit denen Ihr Unternehmen umgehen muss. Alle diese Fakten und Erkenntnisse wären ohne Big Data verborgen geblieben. Aus neu entdeckten Mustern und Verhaltensweisen lassen sich Voraussagen über zukünftige Trends und geschäftliche Chancen ableiten, und dies wird die Geschwindigkeit, Qualität und Zweckdienlichkeit betrieblicher, taktischer und strategischer Entscheidungen eindeutig verbessern. Allein das Vermeiden einer Reihe von sinnlosen Aktivitäten birgt ein enormes Einsparpotenzial. Big Data versetzt Sie in die Lage, Ihre Daten effektiv zur Erlangung eines Wettbewerbsvorteils und zur Steigerung der Wertschöpfung einzusetzen. Die Möglichkeit, Maßnahmen zu automatisieren, trägt dazu bei, diese Ziele noch schneller zu erreichen. Schauen wir uns die Vorteile von Big Data anhand einiger Beispiele genauer an. Neue Erkenntnisse können Ihrem Geschäft, Ihren Produkten und Ihren Services neue Impulse geben. Kunden, die wahrscheinlich abgewandert wären, können gehalten werden, und diejenigen, die bereits das Lager gewechselt haben, werden zurückgewonnen, indem die Kundenstimmung verlässlich analysiert und bewertet wird, z. B. durch Vergleich von Lieferstatus und Kundenanrufen beim Helpdesk. Neukunden werden durch Ermitteln der aktuellen Nachfrage gewonnen, z. B. durch Analyse von sozialen Medien. Gleichzeitig lässt sich durch ein mehr zielgerichtetes Vorgehen die Rentabilität von Marketingkampagnen steigern. Andere Beispiele hängen eng mit der Optimierung von Geschäftsprozessen zusammen. Hier wären die Verkürzung der Forschungs- und Entwicklungsdauer, die Verbesserung von Planung und Prognose durch eine detaillierte Analyse historischer Daten, eine optimierte Bereitstellung und Verteilung von materiellen Ressourcen und Personal oder Leistungs- und Produktivitätssteigerungen durch automatisierte Entscheidungsprozesse in Echtzeit zu nennen. Letztendlich wird durch größere Effizienz und Effektivität die Rentabilität erhöht und das Wachstum gefördert. Die Möglichkeit, Risiken exakt zu quantifizieren und auf ein Minimum zu reduzieren, bedeutet enorme unternehmerische Vorteile. Durch effektive Nutzung von Informationen verbessern Sie Ihre Wettbewerbsfähigkeit. Warum traditionelle Lösungen ungeeignet sind Wie bereits erwähnt, fungieren Data Warehouses in klassischen BI-Lösungen als Datenspeicher. Normalerweise basieren sie auf relationalen Datenbanken. Für relationale Datenbanken ist immer eine Art von Struktur erforderlich, d. h. unstrukturierte oder semistrukturierte Daten müssen im Vorfeld aufbereitet werden. Die sich dabei ergebenden Tabellen sind oft riesig, enthalten aber vergleichsweise nur wenige Daten. Dies wiederum bedeutet ein große Menge von Metadaten, hohe Speicherkapazitäten und eine geringe Abfragegeschwindigkeit. Eine Strukturierung von Daten in Zeilen eignet sich gut für OLTP-Anwendungen (Online Transaction Processing), bei analytischen Aufgabenstellungen müssen aber zwangsläufig eine Menge irrelevanter Daten aus den vielen Zeilen gelesen werden, da eben nur die Informationen aus manchen Spalten von Bedeutung ist. Lässt sich diese Situation durch eine vertikale Serverskalierung (Scale up) verbessern? Egal wie leistungsstark Ihr Server auch sein mag, für jede seiner physischen Ressourcen gibt es eine Obergrenze, die nicht überschritten werden kann. Heutzutage liegen diese Obergrenzen bei ca. 128 Prozessorkernen, 4 TB Hauptspeicher, TB an lokalem Festplattenspeicher und 40 GB/s Netzwerkbandbreite. Angesichts des wachsenden Datenvolumens werden diese Obergrenzen früher oder später zum Problem. Zweifellos werden diese Grenzen in Zukunft weiter nach oben verschoben, aber das Gesamtvolumen der Daten, die Sie für Ihre Analysen nutzen, wird um einiges schneller ansteigen. Außerdem werden die Kosten für CPUs, Hauptspeicher und Netzwerkanbindung bei vertikal skalierten Hochleistungsservern immer vergleichsweise hoch sein. Scheidet eine vertikale Skalierung also aus, bleibt die Frage nach relationalen Datenbanken und einer horizontalen Serverskalierung (Scale out) Da mehrere Server auf die Datenbank zugreifen, könnten die Speicherverbindungen zur entscheidenden Schwachstelle werden. Gleichzeitig steigt der Koordinationsaufwand für den Zugriff auf gemeinsam genutzte Daten mit der Anzahl der verwendeten Datenbankserver. Dies führt laut Amdahl schem Gesetz zu einer Abnahme der Servereffizienz und einer Einschränkung der Parallelisierung. Nach dem Amdahl schen Gesetz begrenzt bei jedem Parallelisierungsansatz der Kehrwert des nicht parallelisierbaren, sequentiellen Anteils die theoretisch erreichbare Leistungssteigerung. Demzufolge ist bei 1000 Rechnerknoten um auch eine 1000-fache Leistungssteigerung zu erzielen - ein serieller Anteil von unter 0,1% anzustreben. Folglich wären alle Verbesserungsbemühungen in Verbindung mit relationalen Datenbanken, egal ob Sie horizontal oder vertikal skalieren, äußerst zeit- und kostenintensiv und würden Sie dem Ziel einer Datenanalyse in Echtzeit nur unwesentlich näher bringen. Die Analyseergebnisse würden zu spät vorliegen, und die gewonnenen Einsichten könnten zum Zeitpunkt, zu dem sie präsentiert werden, bereits hinfällig sein. Angesichts des hohen Datenvolumens werden relationale Datenbanken die Grenzen der wirtschaftlichen Machbarkeit überschreiten und trotzdem nicht die geforderte Performance erreichen. Seite 4 von 16

5 Natürlich wäre es denkbar, getrennte Datenbanken und Data Warehouses aufzubauen und die Analyseaufgaben auf sie zu verteilen. Hierdurch würden jedoch voneinander getrennte Datensilos mit separaten Analyseverfahren entstehen, die Ihnen nicht die erwarteten umfassenden Erkenntnisse liefern. Da Sie bei klassischen Lösungen in allen Bereichen auf Einschränkungen stoßen, sind neue Ansätze erforderlich, die es ermöglichen, die Verarbeitungszeit bei steigendem Datenvolumen konstant zu halten. Verteilte Parallelverarbeitung Der Schlüssel zum Erfolg liegt in der Parallelisierung auf Grundlage einer Shared Nothing -Architektur sowie nicht blockierenden Netzwerken, die eine reibungslose Kommunikation zwischen den Servern gewährleisten. Sie verteilen die Ein-/Ausgabe (I/O) auf mehrere Serverknoten, indem Datenuntermengen in den lokalen Speicher der Server ausgelagert werden. Ähnlich wird die Verarbeitung der Daten verteilt, indem Rechenprozesse auf die Serverknoten verlagert werden, auf denen die Daten liegen. Da sich solche Serverfarmen aus handelsüblichen Servern, in der Regel mit Dual-Socket-Konfiguration und einigen Terabyte an lokalem Speicherplatz, aufbauen lassen, aber ansonsten keine speziellen Anforderungen an die Hardware gestellt werden, ist die resultierende Lösung normalerweise extrem kostengünstig, was vor einigen Jahren so noch nicht möglich war. Dies wird als eine der wichtigsten technischen Voraussetzungen für Big Data-Analyseverfahren angesehen. Apache Hadoop Als Standard für Big Data und verteilte Parallelverarbeitung hat sich im Markt Hadoop etabliert. Hadoop ist ein Projekt der Apache Software Foundation und ein in der Sprache Java programmiertes Open-Source-Framework für Batchbetrieb. Es lässt sich horizontal von wenigen auf mehrere tausend Serverknoten skalieren, toleriert Serverausfälle, die in großen Server-Farmen als Normalzustand anzusehen sind, und sorgt so für stabile Speicher- und Analyseprozesse. Die Hauptbestandteile von Hadoop sind das Hadoop MapReduce-Framework und das Hadoop Distributed File System (HDFS), die nachfolgend etwas näher beleuchtet werden. Hadoop Distributed File System (HDFS) HDFS ist ein verteiltes Dateisystem, welches insbesondere für die Verarbeitung hoher Volumina und hohe Verfügbarkeit konzipiert und optimiert ist. Es erstreckt sich über die lokalen Speicher eines Clusters bestehend aus mehreren Rechnerknoten. Die zentrale Komponente von HDFS ist der Master Server (NameNode), der die ursprünglichen Daten partitioniert und sie regelbasiert anderen Rechnerknoten zuteilt. Jeder Slave speichert also nur einen Teil der kompletten Datenmenge. Der auf jedem Slave installierte DataNode ist für die lokale Datenverwaltung verantwortlich. Verteilte Parallelverarbeitung bietet eine Reihe von Vorteilen. Das Ausführen einer Abfrage auf einer Vielzahl von Knoten erhöht die Leistung und sorgt so für schnellere Ergebnisse. Sie können mit nur wenigen Servern klein anfangen und bei Bedarf weitere hinzufügen. Im Grunde lässt sich Ihre Infrastruktur linear und ohne Obergrenze horizontal skalieren. Selbst wenn Tausende von Servern nicht ausreichen sollten, bleibt der Vorgang des Hinzufügens immer derselbe. Die Daten werden automatisch auf mehrere Knoten repliziert, um die Konfiguration fehlertolerant zu machen. Fällt ein Server aus, kann die entsprechende Aufgabe auf einem Server mit einer Datenreplik fortgeführt werden, vollkommen transparent für die Softwareentwicklung und den Betrieb. Zwecks erhöhter Verfügbarkeit wird jeder Datenblock auf mehrere Server repliziert; standardmäßig gibt es jeden Block dreimal. By default, every data lock exists three times. Neben dem Primärblock existieren eine Kopie typischerweise auf einem zweiten Server innerhalb desselben Server-Racks und eine zusätzliche Kopie in einem anderen Rack. Um die Verfügbarkeit zu erhöhen, lassen sich die Daten auch auf unterschiedliche Lokationen verteilen. Gegen logische Fehler beim Kopieren oder Löschen von Daten hilft das natürlich nicht; hier sind zusätzliche Datensicherungsverfahren anzuwenden. Der HDFS NameNode verwaltet die Metadaten, weiß also jederzeit Bescheid, welche Datenblöcke zu welchen Dateien gehören, wo die Datenblöcke liegen und wo welche Speicherkapazitäten belegt sind. Über periodisch übermittelte Signale kann der NameNode feststellen, ob die DataNodes noch funktionsfähig sind. Anhand ausbleibender Signale erkennt der NameNode den Ausfall von DataNodes, entfernt ausgefallene DataNodes aus dem Hadoop-Cluster und versucht jederzeit, die Datenlast gleichmäßig über die zur Verfügung stehenden DataNodes zu verteilen. Und er sorgt dafür, dass stets die festgelegte Anzahl von Datenblockkopien zur Verfügung steht. Seite 5 von 16

6 Um sich gegen einen Ausfall des NameNodes abzusichern, werden zwei NameNodes auf unterschiedlichen Maschinen im Cluster aufgesetzt. Dabei ist zu jeder Zeit einer aktiv und der andere passiv (Hot Stand-by). Änderungen der Daten, sowie ggf. der Metadaten, werden auf den NameNodes protokolliert. Die Synchronisation der Journaldaten kann über einen Shared-Storage (NAS) oder Quorum-basiert über mehrere Rechnerknoten erfolgen. Da immer beide NameNodes von den DataNodes direkt mit aktuellen Blockinformationen und Heartbeat-Signalen versorgt werden, kann bei Ausfall des aktiven NameNodes sehr schnell automatisch umgeschaltet werden. Hadoop MapReduce Wie HDFS, so arbeitet auch das MapReduce-Framework nach dem Master-Slave-Prinzip.. Der Master (JobTracker) zerlegt ein Problem in eine Vielzahl sinnvoller Teilaufgaben (Map-Tasks) und verteilt diese über das Netz auf eine Reihe von Rechnerknoten (TaskTracker) zur parallelen Bearbeitung. Typischerweise laufen die Map-Tasks auf denselben Clusterknoten, auf denen die zu bearbeitenden Daten liegen. Sollte dieser Rechnerknoten schon überlastet sein, so wird ein anderer Knoten ausgewählt, der möglichst nahe bei den Daten liegt, bevorzugt also im selben Rack. Zwischenergebnisse werden zwischen den Knoten ausgetauscht (Shuffling) und danach durch die Reduce-Tasks zu einem Endergebnis zusammengefasst. Da die Bearbeitungsprozesse zu den zu verarbeitenden Daten bewegt werden und nicht umgekehrt, ist es möglich, in der Map-Phase die I/O-Aktivität zu parallelisieren und die Netzbelastung fast vollständig zu vermeiden. Um auch in der Shuffling-Phase Skalierungsengpässe zu vermeiden, ist ein sich nicht blockierendes, leistungsfähiges Switched Network zwischen den Rechnerknoten erforderlich. Während sich die Eingangsdaten für MapReduce wie auch die Endergebnisse im HDFS befinden, werden Zwischenergebnisse in den lokalen Dateisystemen der DataNodes hinterlegt. Der JobTracker steht ständig mit den Slaves in Kontakt, überwacht die Slaves und sorgt dafür, dass unterbrochene bzw. abgebrochene Tasks erneut ausgeführt werden. Meldet eine Task lange Zeit keinen Fortschritt oder fällt ein Knoten ganz aus, so werden die noch nicht beendeten Tasks auf einem anderen Server neu gestartet, in der Regel auf einem Rechnerknoten, auf dem eine Kopie der betreffenden Daten vorhanden ist. Wenn eine Task sehr langsam läuft, kann der JobTracker den Auftrag auf einem anderen Server noch einmal starten (spekulative Ausführung), um den Gesamtauftrag sicher zu erfüllen. Die einzige Schwachstelle ist der JobTracker selbst, der einen Single Point of Failure darstellt. Dieser Rechner sollte deshalb in sich möglichst viele redundante Komponenten enthalten, um die Ausfallwahrscheinlichkeit so gering wie möglich zu halten. MapReduce wird durchaus zur Ausführung von Business Analytics-Abfragen genutzt werden; ein häufiger Anwendungsfall ist allerdings, große Datenmengen erst in eine für Analyseverfahren optimierte Form zu bringen. YARN (Yet Another Resource Negotiator) YARN ist eine Weiterentwicklung des MapReduce-Frameworks. Die Ressourcenverwaltung und die Applikationssteuerung, die in MapReduce v1 beide vom JobTracker erledigt wurden, sind in zwei von einander getrennte Instanzen aufgeteilt. Nur der schlanke Ressourcen-Manager bleibt als zentrale Instanz vorhanden, während die gesamte Job-Planung an die ApplicationMaster delegiert wird, die auf jedem Slave-Knoten ablaufen können. Pro Job wird ein ApplicationMaster dynamisch auf einem der Slave-Knoten erzeugt und steht exklusiv für diesen Jobauftrag zur Verfügung. MapReduce v2 ist dann nur noch eine von mehreren denkbaren Ausprägungen der parallelen Ablaufsteuerung. Die verteilte Applikationssteuerung erhöht den Grad der Parallelisierung, beseitigt Engpässe und ermöglicht Cluster mit zehntausenden von Rechnerknoten. Optional können Zwischenergebnisse aus der Map-Phase und der Shuffle-Phase aggregiert werden(combine), um die Datenmenge, die von den Map-Tasks an die Reduce-Tasks übergeben werden müssen, gering zu halten. Seite 6 von 16

7 Apache Hadoop-Unterprojekte Neben den beiden Basisfunktionen, dem Hadoop Distributed File System (HDFS) und MapReduce gibt es eine Reihe zusätzlicher Hadoop-Unterprojekte, die in Kombination mit den beiden Kernkomponenten, Hadoop zu einem umfassenden Ökosystem und einer universell einsetzbaren Plattform für Analyseanwendungen machen. Nachfolgend werden die wichtigsten Unterprojekte zusammengefasst. Mit Spark können Daten aus HDFS oder HBase direkt in den Hauptspeicher der Cluster-Knoten geladen werden. So kann für bestimmte Applikationen eine erhebliche Beschleunigung im Vergleich zu Hadoop MapReduce erreicht werden. Dies ist insbesondere dann von Vorteil, wenn mehrfache Abfragen auf dieselben Datenbestände erfolgen, wie dies beispielsweise bei Machine Learning der Fall ist. Pig mit der Skriptsprache Pig Latin ermöglicht die Erstellung von Scripts, die in MapReduce-Jobs kompiliert werden. Hive und die deklarative Abfragesprache HiveQL werden für Ad-hoc-Abfragen und die einfache Erstellung von Reports verwendet. Die Kompilierung in die entsprechenden MapReduce-Jobs findet automatisch statt. Hive wird auch verwendet, um Daten aus HDFS in ein bestehendes Data Warehouse zu laden. Sqoop wird für den Import und Export von Massendaten zwischen HDFS und relationalen Datenbanken herangezogen. Flume eignet sich insbesondere für den Import von Datenströmen, wie bspw. Web-Logs oder andere Protokolldaten, in das HDFS. Avro dient der Serialisierung strukturierter Daten. Die strukturierten Daten werden in Bitketten konvertiert und in einem kompakten Format effizient im HDFS abgelegt. Die serialisierten Daten enthalten auch Informationen über das ursprüngliche Datenschema. Die beiden NoSQL Datenbanken HBase und Cassandra erlauben eine sehr effiziente Speicherung großer Tabellen und einen effizienten Zugriff darauf. Mahout ist eine Bibliothek von Moduln für maschinelles Lernen und Data Mining. ZooKeeper ist eine Bibliothek von Modulen zur Implementierung von Koordinations- und Synchronisierungsdiensten in einem Hadoop-Cluster. Die destillierte Essenz von Big Data Wie bereits erwähnt, kann verteilte Parallelverarbeitung auf Basis verteilter Dateisysteme sehr wohl für umfangreiche Analyseaufgaben herangezogen werden. Häufig steht jedoch die Vorverarbeitung großer Datenmengen im Vordergrund. Dabei werden die Daten bereinigt; Redundanzen und Widersprüche werden entfernt; und letztlich werden die Daten in eine Form gebracht, die sich besser für spontane (ad-hoc) Abfragen eignet. Das Ergebnis dieser Transformation ist in der Regel sehr viel kleiner als die Eingangsdatenmenge, enthält aber alle für den Anwendungsfall wichtigen Informationen und lässt sich somit als destillierte Essenz der Gesamtdaten auffassen. Es steht außer Frage, dass der Zugriff zu Daten auf Plattenspeichersystemen oder auch AFA (All-Flash-Arrays), welche sich durch hohe I/O-Leistung und niedrige Latenzzeiten auszeichnen nie so schnell sein kann wie auf Daten, die sich resident im Hauptspeicher eines Servers und somit näher bei den Applikationen befinden. Daher stellt man bei Echtzeitaufgaben die destillierte Essenz in einer In-Memory Plattform bereit, um sie für die Analyseanwendungen schnell zugänglich zu machen. Abläufe lassen sich mit Oozie beschreiben und automatisieren. Dies geschieht unter Berücksichtigung von Abhängigkeiten zwischen einzelnen Jobs. Chukwa überwacht große Hadoop-Umgebungen. Protokolldaten werden von den Clusterknoten gesammelt und verarbeitet und die Ergebnisse visualisiert. Ambari erlaubt eine einfache Verwaltung von Hadoop-Umgebungen. DataNodes werden hinsichtlich ihres Ressourcenverbrauchs und ihres Gesundheitszustandes überwacht. Cluster-Installation und Upgrades können automatisiert ohne jegliche Serviceunterbrechung durchgeführt werden. Dies erhöht die Verfügbarkeit und beschleunigt die Wiederherstellung im Notfall. Seite 7 von 16

8 In-Memory Plattform Bei einer In-Memory Plattform handelt es sich um einen einzelnen Server oder ein Server-Cluster, dessen Hauptspeicher als Datenspeicher für schnellen Datenzugriff verwendet wird. In der Praxis werden mit der Einführung derartiger In-Memory-Plattformen die Datenzugriffe um das bis fache beschleunigt. Die Analyse von Geschäftsdaten kann so in Echtzeit erfolgen und nimmt nicht mehr Stunden, Tage oder sogar Wochen in Anspruch. Wichtige Entscheidungen lassen sich somit viel schneller treffen. Um die Datenverfügbarkeit zu erhöhen, können Hauptspeicherinhalte zwischen verschiedenen Rechnerknoten gespiegelt und damit synchron gehalten werden. Natürlich reduziert sich dadurch die insgesamt verfügbare Netto-Hauptspeicherkapazität entsprechend. Für Analysezwecke kann auf Plattenspeicher komplett verzichtet werden. Zu beachten ist allerdings, dass Daten, die sich nur im flüchtigen Hauptspeicher eines Rechners befinden, bei Systemabsturz verloren gehen können, insbesondere natürlich nach einem Stromausfall. Der Einsatz von Notfallbatterien für den Hauptspeicher hilft hier sicher nur temporär. Um Datenverlustes zu verhindern, müssen die Dateninhalte, die sich im Hauptspeicher befinden, zusätzlich auf ein nichtflüchtiges, persistentes Speichermedium gebracht werden. Hierfür sind mehrere Lösungsansätze denkbar. Eine gängige Methode ist die kontinuierliche Replikation der Hauptspeicherdaten auf Platte. Ein identischer Status von Hauptspeicher und Platte ist damit jederzeit garantiert. Zur Reduzierung der I/O-Last können alternativ in regelmäßigen Abständen oder beim kontrollierten Abschalten des Gesamtsystems Snapshot-Dateien erzeugt werden, die den jeweils aktuellen Zustand des Hauptspeicherinhalts festhalten. Bei einem Absturz können hierbei allerdings Datenänderungen, die sich seit dem letzten Snapshot ergeben haben, verloren gehen. Durch Mitprotokollieren sämtlicher Datenänderungen ist auch diese Lücke zu schließen. Aus dem letzten Snapshot und dem Protokoll der inzwischen getätigten Änderungen kann der zuletzt gültige Hauptspeicherinhalt automatisch wiederhergestellt werden. Als Speicher für die Datenreplikate, die Snapshots bzw. die Änderungsprotokolle kommen sowohl lokale Platten der beteiligten Rechnerknoten, wie auch Speichersysteme im Netz in Betracht. Die Verwendung von Solid State Disks (SSD) beschleunigt natürlich die Wiederherstellung der Daten nach einem Absturz. Infolge der ständig sinkenden Preise für Hauptspeicher und der steigenden Leistung von Netzkomponenten, welche dazu beitragen, die Hauptspeicherinhalte mehrerer Rechner zu einer logischen Einheit zu formen, werden In-Memory-Plattformen mit immer größer werdenden Datenkapazitäten zu einem wichtigen Infrastrukturbaustein für Big Data. Nachfolgend werden verschiedene Implementierungsmöglichkeiten von In-Memory-Plattformen näher unter die Lupe genommen. In-Memory Datenbanken (IMDB) Bei einer In-Memory Datenbank (IMDB) befindet sich der komplette Datenbestand inklusive Verwaltungsdaten komplett im Hauptspeicher. Auch die Datenoperationen werden nur noch im Hauptspeicher durchgeführt, um schnelle Analysen zu ermöglichen. Für die Analysen können Lesevorgänge und Schreivorgänge von und zur Platte entfallen, komplett und ohne Ausnahme. Der Einsatz von IMDB liegt nahe, wenn voneinander unabhängige Applikationen aus vollkommen unterschiedlichen Blickwinkeln auf Datenbestände zugreifen, darauf dynamisch im Vorfeld noch nicht bekannte ad-hoc Abfragen absetzen, und die Ergebnisse in Echtzeit zu bereitzustellen sind. Die ersten im Markt verfügbaren IMDB waren für vertikale Skalierung ausgelegt. Mittlerweile gibt es aber auch IMDB, die horizontal skalieren. Die Skalierbarkeit ist hier jedoch bei weitem nicht so ausgeprägt wie bei Hadoop-Konfigurationen. Der Trend geht derzeit in die Richtung, horizontale und vertikale Skalierung gleichermaßen zu unterstützen. Ob eine In-Memory-Datenbank für die destillierte Essenz in Frage kommt, hängt von verschiedenen Faktoren ab. Zum einen ist dies die Datengröße, welche durch die im gesamten Servercluster verfügbare Hauptspeicherkapazität begrenzt wird. Bei spaltenorientierten Architekturen ist hier auch der Komprimierungsfaktor ausschlaggebend, der je nach IMDB und verwendetem Komprimierungsverfahren bei 10 bis 50 liegt und demzufolge die Kapazitätsgrenze um das fache nach oben verschieben lässt. Wie viele Rechnerknoten insgesamt verwendet werden dürfen, ist in der Regel auch von IMDB zu IMDB verschieden. Außerdem spielt natürlich das verfügbare Budget eine Rolle; obwohl Arbeitsspeicher ständig preiswerter wird, sind die Kosten im Vergleich zu anderen Speichermedien immer noch vergleichsweise hoch. Seite 8 von 16

9 Einige IMDBs beziehen OLTP-Produktionsdaten und störungsfreie OLAP-Abfragen in dieselbe Datenbankinstanz ein und ermöglichen so eine Analyse von Produktionsdaten in Echtzeit. In solchen Implementierungen verwendet man häufig hybride Tabellen, bestehend aus einem für OLAP optimierten Spaltenspeicher und einem Zeilenspeicher. Dabei werden aktuelle Datenänderungen während der Transaktionsverarbeitung im Zeilenspeicher hinterlegt, damit sie nicht ständig in den Spaltenspeicher einsortiert werden müssen. Nach gewissen Kriterien, wie bspw. Systemauslastung, Größe des Update-Zeilenspeichers oder nach einem bestimmten, vorgegebenen Zeitintervall, wird der Inhalt des Zeilenspeichers in den Spaltenspeicher einsortiert. Natürlich laufen Abfragen immer über beide Teile einer Tabelle, sofern es einen nicht-leeren Zeilenspeicher gibt. Kleine Tabellen werden üblicherweise nicht in Spalten konvertiert, ebenso wenig wie Systemtabellen, die in der Regel ja auch klein sind. In-Memory Data Grid (IMDG) Kommt eine IMDB nicht in Frage, verdient ein In-Memory Data Grid (IMDG) zwischen dem Plattenspeicher und den Applikationen Beachtung. Ein IMDG ist ein in der Regel über mehrere Server verteilter residenter Hauptspeicherbereich, in den große Datenbestände von externen Speichersystemen eingelagert werden. Jede Art von Datenobjekt kann in einem IMDG verwaltet werden, also auch vollkommen unstrukturierte Daten, wie man sie bei Big Data mehrheitlich vorfindet. Im Gegensatz zu einer IMDB muss hier nicht zwingend der gesamte Datenbestand in den Hauptspeicher passen. Dennoch wird die I/O-Last drastisch reduziert, Applikationen werden beschleunigt, und Analysen können in Echtzeit durchgeführt werden. Über vertikale und horizontale Skalierung kann mit eventuellem Datenwachstum Schritt gehalten werden. Während sich IMDB für oftmals im Vorfeld noch nicht bekannte ad-hoc Abfragen von unterschiedlichen Anwendungen eignen, welche nach Belieben dynamisch auf den Datenbestand zugreifen, liegt der Haupteinsatz von IMDG eher bei exklusiven Nutzern und vordefinierten, somit also im Vorfeld schon bekannten Abfragen. Die Applikation bestimmt und steuert die Verarbeitung innerhalb der einzelnen Datenobjekte, das IMDG kümmert sich um den Zugriff auf die Daten, ohne dass die Anwendungen wissen müssen, wo sich die Daten befinden. Zusätzliche Funktionen zu Suche und Indexierung der im IMDG gespeicherten Daten lassen die Grenzen zwischen einer IMDG-Lösung und einer NoSQL-Datenbank fließend erscheinen. Ein IMDG kann eine kosteneffiziente Alternative zu einer IMDB sein, vor allem wenn die Dateninhalte nicht häufig aktualisiert werden. Die Anwendungen, die auf die Daten zugreifen, können in der Regel unverändert genutzt werden; bei entsprechend vorhandener Expertise kann aber durch eine Anpassung der Anwendungen der Nutzen eines IMDG optimiert werden. Wo letztlich die Daten in einem IMDG herkommen, spielt für das IMDG keine Rolle. Die Daten können von Speichersystemen im Netz kommen, oder es kann sich um Daten aus dem HDFS handeln. Weniger denkbar sind NoSQL-Datenbanken, da diese oftmals eine integrierte Caching-Funktion besitzen, die bereits manche der Vorteile eines IMDG bietet. Infrastrukturoptimierung für relationale Datenbanken Zu einer häufig geführten Diskussion führt die Frage, wie vorhandene Infrastrukturen für relationale Datenbanken in die Big Data-Welt integriert werden können. Für relationale Datenbanken gelten die bereits erörterten Einschränkungen. Deshalb kommen sie im Big Data-Umfeld nicht generell zum Einsatz. Relationale Datenbanken können jedoch Datenquellen für Hadoop sein, oder auch der Bestimmungsort für die destillierte Essenz. In beiden Fällen sind die Verarbeitungs- und Zugriffsgeschwindigkeit ausschlaggebend, insbesondere angesichts der steigenden Datenbankgrößen. Wie lässt sich der Datenbankzugriff also beschleunigen? Wie lässt sich die I/O-Aktivität reduzieren, wie holen Sie mehr IOPS aus der Speicherinfrastruktur heraus, und wie erreichen Sie eine kürzere Latenz? Welche Möglichkeiten zur Optimierung der Datenbankinfrastrukturen gibt es? Die bereits vorgestellte In-Memory-Datenbank, sowie das In-Memory Data Grid sind mögliche Lösungsansätze. In diesem Abschnitt werden weitere Alternativen behandelt. Eine Möglichkeit ist das Caching, bei dem häufig abgefragte Datensätze im Hauptspeicher des Datenbankservers verbleiben. Hierdurch werden die Lesevorgänge in der Datenbank beschleunigt, während die Schreibvorgänge direkt auf Festplatte erfolgen. Je größer der Cache, umso mehr Treffer sind zu erwarten und umso geringer die erzeugte I/O-Aktivität. Andererseits werden hierdurch zusätzlicher Speicher für den Cache und ein wenig mehr Arbeitsspeicher sowie zusätzliche CPU-Zyklen für den Cache-Algorithmus benötigt. Werden bestimmte Datensätze aufgrund ihrer besonderen Bedeutung im Hauptspeicher vorgehalten, dann sollten dafür In-Memory-Tabellen verwendet werden. Auch hierfür sind zusätzlicher Arbeitsspeicher und auch zusätzliche CPU-Zyklen zur Tabellenverwaltung erforderlich. Eine weitere Möglichkeit besteht in der Nutzung von RAM-Disks, eine Softwarelösung, bei der ein Teil des Hauptspeichers (RAM) reserviert und wie eine Festplatte genutzt wird. Die bisher vorgestellten Varianten nutzen allesamt die Tatsache, dass eine reine In-Memory-Verarbeitung zu einer Reduzierung der I/O-Aktivität führt. Die Nutzung schnellerer Festplattentechnologien für Ihre Speichersysteme, bspw. SSD (Halbleiterlaufwerke auf Basis von NAND-Flash), könnte aber auch in Betracht gezogen werden. SSDs sind einerseits leistungsfähiger als Festplattenlaufwerke und bieten außerdem mehr Kapazität als der Hauptspeicher. Eine weitere denkbare Alternative besteht darin, die Datenbankserver selbst mit einem lokalen Flash-Speicher (z.b. PCIe SSD) zu versehen, der ein Großteil der zur Bearbeitung benötigten Daten bei extrem verkürzten Zugriffszeiten vorhalten kann. Seite 9 von 16

10 Interessant könnte außerdem ein All-Flash-Array (AFA) sein, das dem Speicher-Array vorgeschaltet ist und in dem idealerweise die gesamte Datenbank Platz findet. Eine solche Architektur bedeutet jedoch immer einen Kompromiss zwischen Größe, erforderlicher Systemleistung und Kosten. Unabhängig davon, für welche der Optionen Sie sich entscheiden, ob der Zugriff auf das Speicher-Array direkt erfolgt oder ein Flash-Array zwischen Server und Speicher-Array geschaltet wird eine Hochgeschwindigkeitsanbindung zwischen Servern und Speicher-Array ist im Grunde unerlässlich. Die latenzarme und leistungsstarke Infiniband-Technologie ist für diesen Zweck bestens geeignet. Um Infiniband in die bereits vorhandenen Speicher- topologien und -protokolle zu integrieren, sind eventuell Hard- oder Software-Gateways erforderlich. Datenbanken für Big Data Verteilte Dateisysteme, wie das HDFS, können problemlos für große Datenmengen und Daten unterschiedlichen Typs verwendet werden. Im Vergleich zu einem Dateisystem erlaubt eine Datenbank auf Grund der bereitgestellten Abfragesprache eine weitaus effizientere Bereitstellung und einfachere Bearbeitung der Daten. Die heute am weitesten verbreitete Form der Datenbank ist die relationale Datenbank. Relationale Datenbanken eignen sich hervorragend für die Transaktionsverarbeitung strukturierter Daten von begrenztem Umfang. Sie sind optimiert für den satzweisen parallelen Zugriff vieler Benutzer, sowie für Operationen zum Einfügen, Aktualisieren und Löschen von Datensätzen. Abfragen dagegen verursachen einen höheren zeitlichen Aufwand. Big Data überschreitet diese Volumenbeschränkung, enthält mehrheitlich unstrukturierte Date und erfordert häufige Abfragen. Dies alles zeigt, dass relationale Datenbanken nicht die beste Wahl für Big Data sind. NoSQL (Not only SQL) Datenbanken sind speziell für Big Data-Anwendungen ausgelegt und können daher die Einschränkungen des relationalen Modells geschickt umgehen. Da sie auf keinem festen Schema aufsetzen, können sie recht einfach beliebige neue Datentypen aufnehmen; ebenso sind Datenformate einfach veränderbar, ohne dabei die Applikationen in irgendeiner Form zu beeinträchtigen. Im Gegensatz zu relationalen Datenbanken, die praktisch für unterschiedlichste Zwecke eingesetzt werden können, sind NoSQL-Datenbanken nur für spezielle Anwendungsfälle gedacht. Auf Grund ihrer Einfachheit kann ein höherer Durchsatz auch bei großen Datenmengen erzielt werden, wie sie bei Big Data typisch sind. Die Abfragen ähneln denen von SQL. Da hohe Geschwindigkeit bei Datenzugriffen und Datenverarbeitung im Vordergrund steht, ist in vielen NoSQL-Implementierungen eine Caching-Funktion integriert, bei der häufig benutzte Daten resident im Hauptspeicher der Rechnerknoten gehalten werden, um die I/O-Last zu reduzieren. Es gibt eine Reihe unterschiedlicher Datenmodelle für NoSQL-Datenbanken, die für die Lösung unterschiedlicher Problemstellungen optimiert wurden. Key-Value Stores Die erste Variante, die wir uns anschauen, sind die Key-Value-Stores, in denen Paare aus Schlüssel und Wert-in großen Mengen gespeichert werden. Der Zugriff auf den Wert erfolgt über den Schlüssel, über den der Wert eindeutig referenziert werden kann. Die Struktur der Values wird nicht von der Datenbank interpretiert; das ist allein Sache der Applikation. Key-Value Stores eignen sich insbesondere für die schnelle Verarbeitung von Daten aus dem Internet, wie bspw. Clickstreams bei Online Shopping-Anwendungen. Suchfunktionen, z.b. in Mail-Systemen, ist ebenfalls ein interessanter Einsatzfall. Dokument-orientierte Datenbanken (Document Stores) Bei Dokument-orientierten Datenbanken werden die Daten in Form von Dokumenten gespeichert. Ähnlich wie bei den Key-Value-Stores werden die Dokumente (Values) durch eindeutige Namen (Keys) referenziert. Jedes Dokument ist vollkommen frei bezüglich seiner Struktur oder seines Schemas; das heißt, es kann das Schema verwendet werden, das für die Applikation benötigt wird. Sollten neue Anforderungen auftreten, so ist leicht eine Anpassung möglich. Neue Felder können hinzugefügt und bereits verwendete Felder können weggelassen werden. Da dokumenten-orientierte Datenbanken über keine Mittel zur Verarbeitung der Dateiinhalte verfügen, ist der Datenzugriff vollständig durch die Applikation zu leisten und die Programmierung etwas aufwändiger. Dokument-orientierte Datenbanken eignen sich besonders zum Speichern zusammenhängender Daten in einem Dokument (bspw. HTML-Seiten), oder serialisierter Objektstrukturen (bspw. im JSON-Format). Beispielsweise setzt Twitter eine Dokument-orientierte Datenbank zur Verwaltung der Nutzerprofile unter Einbeziehung der Follower und Kurznachrichten (Tweets) ein. Daten und Abfragen lassen sich auf die Rechnerknoten eines Clusters verteilen und ermöglichen fast lineare und unbegrenzte Skalierbarkeit, sowie hohe Fehlertoleranz durch Datenreplikation und automatische Wiederherstellung im Fehlerfall. Seite 10 von 16

11 Spaltenorientierte Datenbanken (Columnar Stores) Die geläufigste und wahrscheinlich am häufigsten genutzte Variante der NoSQL-Datenbank ist die spaltenorientierte Datenbank. Ihr Hauptanwendungsgebiet liegt in der Verarbeitung großer Mengen strukturierter Daten, die sich mit relationalen Datenbanksystemen nicht angemessen bewältigen lassen. Man stelle sich eine Tabelle mit Milliarden von Zeilen vor, wobei jede einzelne Zeile einen Datensatz darstellt. Die Anzahl der benötigten Spalten pro Datensatz ist dagegen vergleichsweise gering. Abfragen bei Analyseaufgaben beziehen sich in aller Regel nur auf wenige Spalten. Auf Grund der zeilenweisen Ablage müssen jedoch bei jeder Abfrage alle Spalten gelesen werden. Dies ist äußerst ineffizient. Eine spaltenweise Speicherung der Daten in einer spaltenorientierten Datenbank erhöht die Effizienz. Der Zugriff wird auf die für die Abfrage der relevanten Spalten beschränkt, wodurch das Lesen irrelevanter Daten vermieden wird. Aufgrund der eingeschränkten Spaltenzahl pro Datensatz kann eine gesamte Spalte in einem Schritt gelesen werden. Auf diese Weise lässt sich die zu lesende Datenmenge erheblich reduzieren. Bei Bedarf können Spalten in mehrere Bereiche unterteilt werden, um die parallele Verarbeitung zu vereinfachen und Analyseverfahren auf diese Weise zusätzlich zu beschleunigen. Row-oriented store Key Region Product Sales Vendor 0 Europe Mice 750 Tigerfoot 1 America Mice 1100 Lionhead 2 America Rabbits 250 Tigerfoot 3 Asia Rats 2000 Lionhead 4 Europe Rats 2000 Tigerfoot Column-oriented store Key Region Product Sales Vendor 0 Europe Mice 750 Tigerfoot 1 America Mice 1100 Lionhead 2 America Rabbits 250 Tigerfoot 3 Asia Rats 2000 Lionhead 4 Europe Rats 2000 Tigerfoot SELECT SUM (Sales) GROUP BY Region Data required Data read, but not required Spaltenorientierte Datenbanken sind selbstindizierend. Obwohl sie dieselben Vorteile für die Abfrageleistung bieten wie Indizes, ist kein zusätzlicher Indexbereich erforderlich. Dictionary compression Region Product Sales Vendor 0 Europe 0 Mice Tigerfoot 1 America 1 Rabbits Lionhead 2 Asia 2 Rats Run-length compression Region Product Sales Vendor 0 Europe 0 Mice Tigerfoot 1 America 1 Rabbits Lionhead 2 Asia 2 Rats x1 0 x2 0 x1 0 x1 1 x2 1 x1 1 x1 1 x1 2 x1 2 x2 2 x1 0 x1 0 x1 3 x2 1 x1 0 x1 Columnar Stores eignen sich besonders, um sehr große Datenmengen in der Struktur dünn besetzter Tabellen schnell für Ad-hoc-Abfragen zur Verfügung zu stellen. Einige Columnar Stores unterstützen Spaltenfamilien. Das Datenbankschema enthält nur die grobe Struktur dieser Familien. Jede Spaltenfamilie steht typischerweise für einen inhaltlich zusammenhängenden Bereich von Daten mit ähnlichen Zugriffsmustern. Eine Unterteilung der Familie in mehrere Spalten, auch das Hinzufügen neuer Spalten, kann dynamisch erfolgen, ohne dass das Schema geändert und die Datenbank reorganisiert werden muss. Dies macht den Einsatz der Datenbank sehr flexibel. Neue oder geänderte Einträge werden mit einem Zeitstempel versehen, so dass nicht nur der aktuelle Stand, sondern auch eine gewisse Historie der Daten gespeichert wird. Dadurch wird das dynamische Verhalten nachvollziehbar, und es ist möglich, ggf. auftretende Inkonsistenzen im Nachhinein zu beheben. Da Daten in einer Spalte denselben Datentyp haben und es oft nur wenige verschiedene Werte pro Spalte gibt, lässt sich eine hohe Datenkomprimierung erzielen. Typische Komprimierungsfaktoren liegen im Bereich von 10 bis 50. Somit lassen sich die benötigten Speicherkapazitäten und folglich auch die Speicherkosten reduzieren. Der einzige Nachteil besteht darin, dass für das Einfügen bzw. Aktualisieren von Datensätzen eine höhere Anzahl von CPU-Zyklen erforderlich ist. Seite 11 von 16

12 Graph-Datenbanken Bei Graph-Datenbanken werden Informationen in Graphen mit Knoten und Kanten, sowie deren Eigenschaften dargestellt. Eine der häufigsten Berechnungen in einer Graphen-Datenbank ist die Suche nach dem einfachsten und effizientesten Pfad durch den gesamten Graphen. Anwendungsgebiete sind die Fahrplanoptimierung, geografische Informationssysteme (GIS), Hyperlinkstrukturen sowie die Darstellung von Nutzerbeziehungen innerhalb sozialer Netzwerke. Eine CEP-Lösung muss demzufolge vor allem schnell und skalierbar sein. Um zeitraubende Plattenzugriffe zu vermeiden, werden die Ereignisströme hauptspeicherresident organisiert. Lediglich Betriebsprotokolldaten werden in eine Datei auf Platte geschrieben, sofern von dieser Option überhaupt Gebrauch gemacht wird. In diesem Protokoll werden unter anderem Engpässe bei Betriebsmitteln festgehalten, oder auch Anomalitäten, um im Nachgang die Ursache dafür zu ermitteln. Ist die auftretende Last nicht von einem Server zu bewältigen, ist eine Verteilung auf mehrere Server erforderlich. Große Datenströme werden auf mehrere Server mit entsprechenden CEP Engines verteilt. Eingehende Ereignisse werden verarbeitet oder an andere Server weiter geroutet. Wenn die Anzahl der Knoten und Kanten für einen Server zu groß wird, muss der Graph partitioniert werden, was im Prinzip einer horizontalen Skalierung entspricht. Dabei wird der Gesamtgraph in Teilgraphen zerlegt, was sich als durchaus schwierige, manchmal sogar unlösbare Aufgabe erweisen kann. In letzterem Falle müssten manche Knoten mehreren Teilgraphen zugeordnet werden; man spricht dann auch von einer überlappenden Partitionierung. Bei großen Datenbanken mit hoher Lese-Intensität und relativ geringer Schreiblast, kann eine Replikation der Daten auf mehrere Server zu einer beschleunigten Bearbeitung beitragen. Complex Event Processing In den bisherigen Abschnitten wurde stets davon ausgegangen, dass Daten auf lokalen oder zentralen Plattenspeichern oder resident im Hauptspeicher von Rechnersystemen ruhen (Data at Rest) und auf Verarbeitung warten. Nun schauen wir uns Daten in Bewegung (Data in Motion) etwas näher an. Sind sehr viele Regeln und Abfragen abzuarbeiten, findet eine Verteilung auf mehrere Server mit voneinander unabhängigen CEP Engines statt. Dabei wird versucht, Abfragen die in einer Beziehung miteinander stehen, soweit möglich, auf denselben Rechnerknoten zu dirigieren. Bei Regeln mit hohem Hauptspeicherbedarf, bspw. auf Grund größerer zu betrachtender Zeitfenster, kann ein IMDG helfen, welches sich über mehrere Server erstreckt. Datenverluste können über die in IMDG-Lösungen realisierten Hochverfügbarkeitsfunktionen vermieden werden (bspw. automatische Datenreplikation auf unterschiedlichen Rechnerknoten, bzw. eine temporäre Zwischenlagerung auf persistenten Speichermedien). Komplexe Abfragen, die ein einzelner Server nicht alleine bearbeiten kann, können in Teilaufgaben zerlegt und auf mehrere Server verteilt werden. Ereignisströme (Event Streams) werden kontinuierlich und in hoher Frequenz bspw. von Sensoren erzeugt. Diese Event Streams müssen sofort erfasst und in Echtzeit analysiert werden. Je nach Relevanz werden die Ereignisse gefiltert und korreliert. Die Analyse erfolgt mit Hilfe von vordefinierten Regeln, die jeweils eine Bedingung und eine Aktion enthalten. Wenn die Bedingung erfüllt ist (das kann eine Korrelation sowohl in logischer wie auch in zeitlicher Hinsicht sein), wird die Aktion in Echtzeit angestoßen. Das genau ist das Arbeitsprinzip einer CEP (Complex Event Processing) Engine. Je nach Anwendungsfall sind Hunderttausende oder gar Millionen von Ereignissen pro Sekunde bewältigen. Ein weiterer kritischer Parameter ist die Latenz, d. h. in diesem Fall die Zeit, die zwischen Ereigniseingabe- und Ereignisausgabe verstreichen darf. Typische Anforderungen bezüglich der Latenzwerte liegen im Mikro- bzw. Millisekunden-Bereich. Je nach Anwendungsfall können von einer CEP-Engine erarbeitete Ergebnisse auch in HDFS (bspw. die Betriebsprotokolldaten), NoSQL-Datenbanken, In-Memory-Datenbanken oder IMDG hinterlegt und für weitere Analysezwecke oder zur Visualisierung, bzw. für das Berichtswesen (Reporting) genutzt werden. Theoretisch ist es auch denkbar, von Sensoren erzeugte Daten in anderen Datenspeichern zu konservieren; bspw. wenn alle Vorgänge nachvollziehbar sein müssen und deshalb sämtliche eintreffenden Daten protokolliert werden. Seite 12 von 16

White Paper Lösungsansätze für Big Data

White Paper Lösungsansätze für Big Data White Paper Lösungsansätze für Big Data Das Thema Big Data gewinnt für immer mehr Unternehmen an Bedeutung. Es werden neue Anwendungsfelder erschlossen, bei denen riesige Datenmengen automatisch und kontinuierlich

Mehr

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

Peter Dikant mgm technology partners GmbH. Echtzeitsuche mit Hadoop und Solr

Peter Dikant mgm technology partners GmbH. Echtzeitsuche mit Hadoop und Solr Peter Dikant mgm technology partners GmbH Echtzeitsuche mit Hadoop und Solr ECHTZEITSUCHE MIT HADOOP UND SOLR PETER DIKANT MGM TECHNOLOGY PARTNERS GMBH WHOAMI peter.dikant@mgm-tp.com Java Entwickler seit

Mehr

ANALYTICS, RISK MANAGEMENT & FINANCE ARCHITECTURE. NoSQL Datenbanksysteme Übersicht, Abgrenzung & Charakteristik

ANALYTICS, RISK MANAGEMENT & FINANCE ARCHITECTURE. NoSQL Datenbanksysteme Übersicht, Abgrenzung & Charakteristik ARFA ANALYTICS, RISK MANAGEMENT & FINANCE ARCHITECTURE NoSQL Datenbanksysteme Übersicht, Abgrenzung & Charakteristik Ralf Leipner Domain Architect Analytics, Risk Management & Finance 33. Berner Architekten

Mehr

FLASHRECOVER SNAPSHOTS. Sofortige, unlimitierte Snapshots, speziell für 100 % Flash-Speicherung

FLASHRECOVER SNAPSHOTS. Sofortige, unlimitierte Snapshots, speziell für 100 % Flash-Speicherung FLASHRECOVER SNAPSHOTS Sofortige, unlimitierte Snapshots, speziell für 100 % Flash-Speicherung FLASHRECOVER SNAPSHOTS BIETEN EFFIZIENTE, SKALIERBARE UND LEICHT ZU VERWALTENDE SNAPSHOTS OHNE KOMPROMISSE

Mehr

25.09.2014. Zeit bedeutet eine Abwägung von Skalierbarkeit und Konsistenz

25.09.2014. Zeit bedeutet eine Abwägung von Skalierbarkeit und Konsistenz 1 2 Dies ist ein Vortrag über Zeit in verteilten Anwendungen Wir betrachten die diskrete "Anwendungszeit" in der nebenläufige Aktivitäten auftreten Aktivitäten in einer hochgradig skalierbaren (verteilten)

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 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

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

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

Fachbericht zum Thema: Anforderungen an ein Datenbanksystem

Fachbericht zum Thema: Anforderungen an ein Datenbanksystem Fachbericht zum Thema: Anforderungen an ein Datenbanksystem von André Franken 1 Inhaltsverzeichnis 1 Inhaltsverzeichnis 1 2 Einführung 2 2.1 Gründe für den Einsatz von DB-Systemen 2 2.2 Definition: Datenbank

Mehr

Big Data Mythen und Fakten

Big Data Mythen und Fakten Big Data Mythen und Fakten Mario Meir-Huber Research Analyst, IDC Copyright IDC. Reproduction is forbidden unless authorized. All rights reserved. About me Research Analyst @ IDC Author verschiedener IT-Fachbücher

Mehr

Hadoop. Eine Open-Source-Implementierung von MapReduce und BigTable. von Philipp Kemkes

Hadoop. Eine Open-Source-Implementierung von MapReduce und BigTable. von Philipp Kemkes Hadoop Eine Open-Source-Implementierung von MapReduce und BigTable von Philipp Kemkes Hadoop Framework für skalierbare, verteilt arbeitende Software Zur Verarbeitung großer Datenmengen (Terra- bis Petabyte)

Mehr

Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken

Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken Handbuch ECDL 2003 Basic Modul 5: Datenbank Grundlagen von relationalen Datenbanken Dateiname: ecdl5_01_00_documentation_standard.doc Speicherdatum: 14.02.2005 ECDL 2003 Basic Modul 5 Datenbank - Grundlagen

Mehr

Analyse von unstrukturierten Daten. Peter Jeitschko, Nikolaus Schemel Oracle Austria

Analyse von unstrukturierten Daten. Peter Jeitschko, Nikolaus Schemel Oracle Austria Analyse von unstrukturierten Daten Peter Jeitschko, Nikolaus Schemel Oracle Austria Evolution von Business Intelligence Manuelle Analyse Berichte Datenbanken (strukturiert) Manuelle Analyse Dashboards

Mehr

In-Memory & Real-Time Hype vs. Realität: Maßgeschneiderte IBM Business Analytics Lösungen für SAP-Kunden

In-Memory & Real-Time Hype vs. Realität: Maßgeschneiderte IBM Business Analytics Lösungen für SAP-Kunden In-Memory & Real-Time Hype vs. Realität: Maßgeschneiderte IBM Business Analytics Lösungen für SAP-Kunden Jens Kaminski ERP Strategy Executive IBM Deutschland Ungebremstes Datenwachstum > 4,6 Millarden

Mehr

Integration Services - Dienstarchitektur

Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Dieser Artikel solle dabei unterstützen, Integration Services in Microsoft SQL Server be sser zu verstehen und damit die

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

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

Definition Informationssystem

Definition Informationssystem Definition Informationssystem Informationssysteme (IS) sind soziotechnische Systeme, die menschliche und maschinelle Komponenten umfassen. Sie unterstützen die Sammlung, Verarbeitung, Bereitstellung, Kommunikation

Mehr

Möglichkeiten für bestehende Systeme

Möglichkeiten für bestehende Systeme Möglichkeiten für bestehende Systeme Marko Filler Bitterfeld, 27.08.2015 2015 GISA GmbH Leipziger Chaussee 191 a 06112 Halle (Saale) www.gisa.de Agenda Gegenüberstellung Data Warehouse Big Data Einsatz-

Mehr

SOLISYON GMBH CHRISTIAN WOLF, BENJAMIN WEISSMAN. Optimierung von Abfragen in MS SQL Server DWH-Umgebungen

SOLISYON GMBH CHRISTIAN WOLF, BENJAMIN WEISSMAN. Optimierung von Abfragen in MS SQL Server DWH-Umgebungen WEITER BLICKEN. MEHR ERKENNEN. BESSER ENTSCHEIDEN. Optimierung von Abfragen in MS SQL Server DWH-Umgebungen SOLISYON GMBH CHRISTIAN WOLF, BENJAMIN WEISSMAN VERSION 1.0 OPTIMIERUNG VON ABFRAGEN IN MS SQL

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

Die Cloud, die für Ihr Unternehmen geschaffen wurde.

Die Cloud, die für Ihr Unternehmen geschaffen wurde. Die Cloud, die für Ihr Unternehmen geschaffen wurde. Das ist die Microsoft Cloud. Jedes Unternehmen ist einzigartig. Ganz gleich, ob im Gesundheitssektor oder im Einzelhandel, in der Fertigung oder im

Mehr

Big, Bigger, CRM: Warum Sie auch im Kundenmanagement eine Big-Data-Strategie brauchen

Big, Bigger, CRM: Warum Sie auch im Kundenmanagement eine Big-Data-Strategie brauchen Big, Bigger, CRM: Warum Sie auch im Kundenmanagement eine Big-Data-Strategie brauchen 01000111101001110111001100110110011001 Volumen 10 x Steigerung des Datenvolumens alle fünf Jahre Big Data Entstehung

Mehr

Effizienter Einsatz von Flash-Technologien im Data Center

Effizienter Einsatz von Flash-Technologien im Data Center Effizienter Einsatz von Flash-Technologien im Data Center Herbert Bild Solution Marketing Manager Georg Mey Solutions Architect 1 Der Flash-Hype 2 Drei Gründe für den Hype um Flash: 1. Ungebremstes Datenwachstum

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

Copyright 2015 DataCore Software Corp. All Rights Reserved. 1

Copyright 2015 DataCore Software Corp. All Rights Reserved. 1 Copyright 2015 DataCore Software Corp. All Rights Reserved. 1 Software Defined Storage - wenn Storage zum Service wird - Jens Gerlach Regional Manager West Copyright 2015 DataCore Software Corp. All Rights

Mehr

Oracle Automatic Storage Management (ASM) Best Practices

Oracle Automatic Storage Management (ASM) Best Practices Oracle Automatic Storage Management (ASM) Best Practices Markus Michalewicz BU Database Technologies ORACLE Deutschland GmbH 2 Page 1 www.decus.de 1 Agenda ASM Funktionalität und Architektur Storage Management

Mehr

Big Data Hype und Wirklichkeit Bringtmehrauchmehr?

Big Data Hype und Wirklichkeit Bringtmehrauchmehr? Big Data Hype und Wirklichkeit Bringtmehrauchmehr? Günther Stürner, Vice President Sales Consulting 1 Copyright 2011, Oracle and/or its affiliates. All rights Überschrift 2 Copyright 2011, Oracle and/or

Mehr

VMware Schutz mit NovaBACKUP BE Virtual

VMware Schutz mit NovaBACKUP BE Virtual VMware Schutz mit NovaBACKUP BE Virtual Anforderungen, Konfiguration und Restore-Anleitung Ein Leitfaden (September 2011) Inhalt Inhalt... 1 Einleitung... 2 Zusammenfassung... 3 Konfiguration von NovaBACKUP...

Mehr

Einführung in Hauptspeicherdatenbanken

Einführung in Hauptspeicherdatenbanken Einführung in Hauptspeicherdatenbanken Harald Zankl Probevorlesung 13. 01., 13:15 14:00, HS C Inhaltsverzeichnis Organisation Überblick Konklusion Harald Zankl (LFU) Hauptspeicherdatenbanken 2/16 Organisation

Mehr

Big Data Plattformen für polystrukturierte Daten neue Chancen und Herausforderungen

Big Data Plattformen für polystrukturierte Daten neue Chancen und Herausforderungen Big Data Plattformen für polystrukturierte Daten neue Chancen und Herausforderungen Oracle DWH-Konferenz 21. März 2012 Dr. Carsten Bange Gründer & Geschäftsführer BARC Big Data bietet Methoden und Technologien

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

Asklepius-DA Die intelligente Technologie für die umfassende Analyse medizinischer Daten Leistungsbeschreibung

Asklepius-DA Die intelligente Technologie für die umfassende Analyse medizinischer Daten Leistungsbeschreibung Asklepius-DA Die intelligente Technologie für die umfassende Analyse medizinischer Daten Leistungsbeschreibung Datei: Asklepius DA Flyer_Leistung_2 Seite: 1 von:5 1 Umfassende Datenanalyse Mit Asklepius-DA

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

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

Softwaretool Data Delivery Designer

Softwaretool Data Delivery Designer Softwaretool Data Delivery Designer 1. Einführung 1.1 Ausgangslage In Unternehmen existieren verschiedene und häufig sehr heterogene Informationssysteme die durch unterschiedliche Softwarelösungen verwaltet

Mehr

Jump Project. Softwarelösungen für professionelles Projektmanagement

Jump Project. Softwarelösungen für professionelles Projektmanagement Jump Project Softwarelösungen für professionelles Projektmanagement Jump Project Office Übersichtliche Dokumentenstruktur und schneller Zugriff auf alle wichtigen Funktionen. Steuern Sie Ihre Projekte

Mehr

Synchronisation von redundanten Datenbeständen

Synchronisation von redundanten Datenbeständen Synchronisation von redundanten Datenbeständen seit 1999 Themenübersicht Mobile Anwendungen Verteilte Datenbanksysteme Synchronisation Lösungsansätze Mobile Anwendungen Erwartungen der Anwender Der App-Stil

Mehr

Review Freelancer-Workshop: Fit für Big Data. Mittwoch, 29.04.2015 in Hamburg

Review Freelancer-Workshop: Fit für Big Data. Mittwoch, 29.04.2015 in Hamburg Review Freelancer-Workshop: Fit für Big Data Mittwoch, 29.04.2015 in Hamburg Am Mittwoch, den 29.04.2015, hatten wir von productive-data in Zusammenarbeit mit unserem langjährigen Partner Informatica zu

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

Software Defined Storage in der Praxis

Software Defined Storage in der Praxis Software Defined Storage in der Praxis - Vorteile und Nutzen für jede Unternehmensgröße - Torsten Welke Regional Manager Nord 1 Speicherbedarf nimmt weiter rasant zu - aber ohne Nachhaltigkeit - 2 Herausforderungen

Mehr

Big-Data-Technologien - Überblick - Prof. Dr. Jens Albrecht

Big-Data-Technologien - Überblick - Prof. Dr. Jens Albrecht Big-Data-Technologien - Überblick - Quelle: http://www.ingenieur.de/panorama/fussball-wm-in-brasilien/elektronischer-fussball-smartphone-app-helfen-training Big-Data-Anwendungen im Unternehmen Logistik

Mehr

Ein Beispiel. Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse?

Ein Beispiel. Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse? Ein Beispiel Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse? Dipl.-Kfm. Claus Häberle WS 2015 /16 # 42 XML (vereinfacht) visa

Mehr

vinsight BIG DATA Solution

vinsight BIG DATA Solution vinsight BIG DATA Solution München, November 2014 BIG DATA LÖSUNG VINSIGHT Datensilos erschweren eine einheitliche Sicht auf die Daten...... und machen diese teilweise unmöglich einzelne individuelle Konnektoren,

Mehr

RAC auf Sun Cluster 3.0

RAC auf Sun Cluster 3.0 RAC auf Sun Cluster 3.0 Schlüsselworte RAC, OPS, Sun Cluster, Performance, Availability Zusammenfassung Oracle hat mit dem Real Application Cluster (RAC) aus einer Hochverfügbarkeitslösung eine Höchstverfügbarkeitslösung

Mehr

Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht)

Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht) Performanceoptimierung mit Exadata Verarbeitung extremer Datenmengen mit PL/SQL basierter Datenbewirtschaftung (Erfahrungsbericht) Christian Haag, DATA MART Consulting Consulting Manager Oracle DWH Team

Mehr

DATENBANK LÖSUNGEN. mit Azure. Peter Schneider Trainer und Consultant. Lernen und Entwickeln. www.egos.co.at

DATENBANK LÖSUNGEN. mit Azure. Peter Schneider Trainer und Consultant. Lernen und Entwickeln. www.egos.co.at DATENBANK LÖSUNGEN mit Azure Peter Schneider Trainer und Consultant Agenda Cloud Services, Data Platform, Azure Portal Datenbanken in Virtuelle Maschinen Azure SQL Datenbanken und Elastic Database Pools

Mehr

Verteiltes Backup. Einleitung Grundlegende Backup Techniken Backup in Netzwerken. Client/Server Peer-to-Peer

Verteiltes Backup. Einleitung Grundlegende Backup Techniken Backup in Netzwerken. Client/Server Peer-to-Peer Verteiltes Backup Einleitung Grundlegende Backup Techniken Backup in Netzwerken Client/Server Peer-to-Peer Einleitung Backup: Das teilweise oder gesamte Kopieren der in einem Computersystem vorhandenen

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

Dell Data Protection Solutions Datensicherungslösungen von Dell

Dell Data Protection Solutions Datensicherungslösungen von Dell Dell Data Protection Solutions Datensicherungslösungen von Dell André Plagemann SME DACH Region SME Data Protection DACH Region Dell Softwarelösungen Vereinfachung der IT. Minimierung von Risiken. Schnellere

Mehr

Darüber hinaus wird das Training dazu beitragen, das Verständnis für die neuen Möglichkeiten zu erlangen.

Darüber hinaus wird das Training dazu beitragen, das Verständnis für die neuen Möglichkeiten zu erlangen. Ora Education GmbH www.oraeducation.de info@oraeducation.de Lehrgang: Oracle 11g: New Features für Administratoren Beschreibung: Der Kurs über fünf Tage gibt Ihnen die Möglichkeit die Praxis mit der neuen

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

Software-Engineering und Datenbanken

Software-Engineering und Datenbanken Software-Engineering und Datenbanken Prof. Dr. Bernhard Schiefer bernhard.schiefer@fh-kl.de http://www.fh-kl.de/~schiefer Prof. Dr. Bernhard Schiefer 1-1 Wesentliche Inhalte Begriff DBS Datenbankmodelle

Mehr

NoSQL-Datenbanken und Hadoop im Zusammenspiel mit dem Data Warehouse

NoSQL-Datenbanken und Hadoop im Zusammenspiel mit dem Data Warehouse NoSQL-Datenbanken und Hadoop im Zusammenspiel mit dem Data Warehouse Carsten Czarski Oracle Deutschland B.V. & Co KG Big Data Betrachten von Daten die bislang nicht betrachtet wurden

Mehr

I N F O R M A T I O N V I R T U A L I S I E R U N G. Wir schützen Ihre Unternehmenswerte

I N F O R M A T I O N V I R T U A L I S I E R U N G. Wir schützen Ihre Unternehmenswerte I N F O R M A T I O N V I R T U A L I S I E R U N G Wir schützen Ihre Unternehmenswerte Wir schützen Ihre Unternehmenswerte Ausfallsicherheit durch Virtualisierung Die heutigen Anforderungen an IT-Infrastrukturen

Mehr

TOP. wird ein wichtiges Jahr für BIG (Business Intelligence Growth) DER BUSINESS INTELLIGENCE TRENDS FÜR DAS JAHR 2013

TOP. wird ein wichtiges Jahr für BIG (Business Intelligence Growth) DER BUSINESS INTELLIGENCE TRENDS FÜR DAS JAHR 2013 0 Es TOP 10 DER BUSINESS INTELLIGENCE TRENDS FÜR DAS JAHR 2013 wird ein wichtiges Jahr für BIG (Business Intelligence Growth) 2012 war ein fantastisches Jahr für Business Intelligence! Die biedere alte

Mehr

Überblick und Vergleich von NoSQL. Datenbanksystemen

Überblick und Vergleich von NoSQL. Datenbanksystemen Fakultät Informatik Hauptseminar Technische Informationssysteme Überblick und Vergleich von NoSQL Christian Oelsner Dresden, 20. Mai 2011 1 1. Einführung 2. Historisches & Definition 3. Kategorien von

Mehr

ROPit-R8. ROP-IRMA & ROP-FiBu TECHNISCHE INFORMATIONEN

ROPit-R8. ROP-IRMA & ROP-FiBu TECHNISCHE INFORMATIONEN ROPit-R8 ROP-IRMA & ROP-FiBu TECHNISCHE INFORMATIONEN Softwarelösung Gastronomie Event-Management Catering Gemeinschaftsverpflegung Stand 05/2010 INHALT Installationsvarianten 3 ROPit R8 als Einzelplatzlösung

Mehr

Verfügbarkeit von Applikationen und Failover Szenarien. Winfried Wojtenek. wojtenek@mac.com

Verfügbarkeit von Applikationen und Failover Szenarien. Winfried Wojtenek. wojtenek@mac.com Verfügbarkeit von Applikationen und Failover Szenarien Winfried Wojtenek wojtenek@mac.com Verfügbarkeit % Tage Stunden Minuten 99.000 3 16 36 99.500 1 20 48 99.900 0 9 46 99.990 0 0 53 99.999 0 0 5 Tabelle

Mehr

Cordaware bestinformed Neuerungen in Version 4 Copyright Cordaware Informationslogistik GmbH 2007

Cordaware bestinformed Neuerungen in Version 4 Copyright Cordaware Informationslogistik GmbH 2007 Änderungen ab Basis Edition: Interne Datenbank: Durch die Erweiterung der bestinformed Datenstruktur mit einer leistungsfähigen internen Datenbank werden zahlreiche Verbesserungen erzielt. Um die wichtigsten

Mehr

4 Planung von Anwendungsund

4 Planung von Anwendungsund Einführung 4 Planung von Anwendungsund Datenbereitstellung Prüfungsanforderungen von Microsoft: Planning Application and Data Provisioning o Provision applications o Provision data Lernziele: Anwendungen

Mehr

Big Data Herausforderungen und Chancen für Controller. ICV Jahrestagung, 19.05.2014 Dr. Carsten Bange, Gründer und Geschäftsführer BARC

Big Data Herausforderungen und Chancen für Controller. ICV Jahrestagung, 19.05.2014 Dr. Carsten Bange, Gründer und Geschäftsführer BARC Big Data Herausforderungen und Chancen für Controller ICV Jahrestagung, 19.05.2014 Dr. Carsten Bange, Gründer und Geschäftsführer BARC BARC: Expertise für datengetriebene Organisationen Beratung Strategie

Mehr

Die maßgeschneiderte IT-Infrastruktur aus der Südtiroler Cloud

Die maßgeschneiderte IT-Infrastruktur aus der Südtiroler Cloud Die maßgeschneiderte IT-Infrastruktur aus der Südtiroler Cloud Sie konzentrieren sich auf Ihr Kerngeschäft und RUN AG kümmert sich um Ihre IT-Infrastruktur. Vergessen Sie das veraltetes Modell ein Server,

Mehr

Business Intelligence - Wie passt das zum Mainframe?

Business Intelligence - Wie passt das zum Mainframe? Business Intelligence - Wie passt das zum Mainframe? IBM IM Forum, 15.04.2013 Dr. Carsten Bange, Gründer und Geschäftsführer BARC Ressourcen bei BARC für Ihr Projekt Durchführung von internationalen Umfragen,

Mehr

E-Interview mit Herrn Dr. Winokur, CTO von Axxana

E-Interview mit Herrn Dr. Winokur, CTO von Axxana E-Interview mit Herrn Dr. Winokur, CTO von Axxana Titel des E-Interviews: Kostengünstige Datenrettung ohne Verlust und über alle Distanzen hinweg wie mit Enterprise Data Recording (EDR) von Axxana eine

Mehr

MapReduce und Datenbanken Thema 15: Strom bzw. Onlineverarbeitung mit MapReduce

MapReduce und Datenbanken Thema 15: Strom bzw. Onlineverarbeitung mit MapReduce MapReduce Jan Kristof Nidzwetzki MapReduce 1 / 17 Übersicht 1 Begriffe 2 Verschiedene Arbeiten 3 Ziele 4 DEDUCE: at the intersection of MapReduce and stream processing Beispiel 5 Beyond online aggregation:

Mehr

OLAP und Data Warehouses

OLAP und Data Warehouses OLP und Data Warehouses Überblick Monitoring & dministration Externe Quellen Operative Datenbanken Extraktion Transformation Laden Metadaten- Repository Data Warehouse OLP-Server nalyse Query/Reporting

Mehr

In-Memory Analytics. Marcel Poltermann. Fachhochschule Erfurt. Informationsmanagement

In-Memory Analytics. Marcel Poltermann. Fachhochschule Erfurt. Informationsmanagement Marcel Poltermann Fachhochschule Erfurt Informationsmanagement Inhaltsverzeichnis Glossar...III Abbildungsverzeichnis...III 1 Erläuterung:... 2 2 Technische Grundlagen... 2 2.1 Zugriff physische Datenträger:...

Mehr

Big Data Informationen neu gelebt

Big Data Informationen neu gelebt Seminarunterlage Version: 1.01 Copyright Version 1.01 vom 21. Mai 2015 Dieses Dokument wird durch die veröffentlicht. Copyright. Alle Rechte vorbehalten. Alle Produkt- und Dienstleistungs-Bezeichnungen

Mehr

StorageCraft ImageManager ist eine voll ausgereifte Ergänzung zu

StorageCraft ImageManager ist eine voll ausgereifte Ergänzung zu Produktszenarien Was kann das Produkt für Sie tun? ist eine voll ausgereifte Ergänzung zu StorageCraft ShadowProtect, mit deren Hilfe Sie von einer einfachen Backup- und Wiederherstellungslösung zu einer

Mehr

Datenbanken. Prof. Dr. Bernhard Schiefer. bernhard.schiefer@fh-kl.de http://www.fh-kl.de/~schiefer

Datenbanken. Prof. Dr. Bernhard Schiefer. bernhard.schiefer@fh-kl.de http://www.fh-kl.de/~schiefer Datenbanken Prof. Dr. Bernhard Schiefer bernhard.schiefer@fh-kl.de http://www.fh-kl.de/~schiefer Wesentliche Inhalte Begriff DBS Datenbankmodelle Datenbankentwurf konzeptionell, logisch und relational

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

Big Data in der Forschung

Big Data in der Forschung Big Data in der Forschung Dominik Friedrich RWTH Aachen Rechen- und Kommunikationszentrum (RZ) Gartner Hype Cycle July 2011 Folie 2 Was ist Big Data? Was wird unter Big Data verstanden Datensätze, die

Mehr

OPERATIONEN AUF EINER DATENBANK

OPERATIONEN AUF EINER DATENBANK Einführung 1 OPERATIONEN AUF EINER DATENBANK Ein Benutzer stellt eine Anfrage: Die Benutzer einer Datenbank können meist sowohl interaktiv als auch über Anwendungen Anfragen an eine Datenbank stellen:

Mehr

SimpleVOC-Yetanother. Bausteine für eine Key/Value- Datenbank

SimpleVOC-Yetanother. Bausteine für eine Key/Value- Datenbank SimpleVOC-Yetanother Memcached? Bausteine für eine Key/Value- Datenbank SimpleVOC Yet another memcached? Bausteine für eine Key/Value Datenbank. Theorie (Martin Schönert) Praxis (Frank Celler) Eine Weisheit

Mehr

Data Cube. Aggregation in SQL. Beispiel: Autoverkäufe. On-line Analytical Processing (OLAP) 1. Einführung. 2. Aggregation in SQL, GROUP BY

Data Cube. Aggregation in SQL. Beispiel: Autoverkäufe. On-line Analytical Processing (OLAP) 1. Einführung. 2. Aggregation in SQL, GROUP BY Data Cube On-line Analytical Processing (OLAP). Einführung Ziel: Auffinden interessanter Muster in großen Datenmengen 2. Aggregation in SQL, GROUP BY 3. Probleme mit GROUP BY 4. Der Cube-Operator! Formulierung

Mehr

Oracle 10g revolutioniert Business Intelligence & Warehouse

Oracle 10g revolutioniert Business Intelligence & Warehouse 10g revolutioniert Business Intelligence & Warehouse Marcus Bender Strategisch Technische Unterstützung (STU) Hamburg 1-1 BI&W Market Trends DWH werden zu VLDW Weniger Systeme, mehr Daten DWH werden konsolidiert

Mehr

Isilon Solutions + OneFS

Isilon Solutions + OneFS Isilon Solutions + OneFS Anne-Victoria Meyer Betreuer: Dr. Julian Kunkel Proseminar: Ein-/Ausgabe - Stand der Wissenschaft 16. Oktober 2013 Contents 1 Einleitung 2 1.1 Scale-Out-NAS..........................

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

eevolution Business Intelligence Oliver Rzeniecki COMPRA GmbH Programmierer & Datenbankadministrator

eevolution Business Intelligence Oliver Rzeniecki COMPRA GmbH Programmierer & Datenbankadministrator eevolution Business Intelligence Oliver Rzeniecki COMPRA GmbH Programmierer & Datenbankadministrator Agenda Was ist Business Intelligence? Was ist OLAP? Unterschied zwischen OLAP und OLTP? Bestandteile

Mehr

Oracle Big Data Technologien Ein Überblick

Oracle Big Data Technologien Ein Überblick Oracle Big Data Technologien Ein Überblick Ralf Lange Global ISV & OEM Sales NoSQL: Eine kurze Geschichte Internet-Boom: Erste Ansätze selbstgebauter "Datenbanken" Google stellt "MapReduce"

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

Datenbanken. Ein DBS besteht aus zwei Teilen:

Datenbanken. Ein DBS besteht aus zwei Teilen: Datenbanken Wikipedia gibt unter http://de.wikipedia.org/wiki/datenbank einen kompakten Einblick in die Welt der Datenbanken, Datenbanksysteme, Datenbankmanagementsysteme & Co: Ein Datenbanksystem (DBS)

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

Die allerwichtigsten Raid Systeme

Die allerwichtigsten Raid Systeme Die allerwichtigsten Raid Systeme Michael Dienert 4. Mai 2009 Vorbemerkung Dieser Artikel gibt eine knappe Übersicht über die wichtigsten RAID Systeme. Inhaltsverzeichnis 1 Die Abkürzung RAID 2 1.1 Fehlerraten

Mehr

Teil VI. Datenbanken

Teil VI. Datenbanken Teil VI Datenbanken Überblick 1 Grundlegende Begriffe Motivation 2 Relationale Datenbanksysteme Das Relationale Datenmodell SQL 3 Entwurf von Datenbanken Das Enity Relationship (ER) Modell Abbildung von

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

wikima4 mesaforte firefighter for SAP Applications

wikima4 mesaforte firefighter for SAP Applications 1 wikima4 mesaforte firefighter for SAP Applications Zusammenfassung: Effizienz, Sicherheit und Compliance auch bei temporären Berechtigungen Temporäre Berechtigungen in SAP Systemen optimieren die Verfügbarkeit,

Mehr

Software Defined Storage in der Praxis

Software Defined Storage in der Praxis Software Defined Storage in der Praxis Jens Gerlach Regional Manager West 1 Der Speichermarkt im Umbruch 1985 2000 Heute Herausforderungen Serverspeicher Serverspeicher Serverspeicher Hyper-konvergente

Mehr

Oracle Database 10g Die RAC Evolution

Oracle Database 10g Die RAC Evolution Oracle Database 10g Die RAC Evolution Markus Michalewicz BU Database Technologies ORACLE Deutschland GmbH 2 Page 1 www.decus.de 1 RAC-Revolution, RAC-Evolution & Computing Oracle8i mit OPS Oracle9i Rel.

Mehr

Storage-Trends am LRZ. Dr. Christoph Biardzki

Storage-Trends am LRZ. Dr. Christoph Biardzki Storage-Trends am LRZ Dr. Christoph Biardzki 1 Über das Leibniz-Rechenzentrum (LRZ) Seit 50 Jahren Rechenzentrum der Bayerischen Akademie der Wissenschaften IT-Dienstleister für Münchner Universitäten

Mehr

Beratung. Results, no Excuses. Consulting. Lösungen. Grown from Experience. Ventum Consulting. SQL auf Hadoop Oliver Gehlert. 2014 Ventum Consulting

Beratung. Results, no Excuses. Consulting. Lösungen. Grown from Experience. Ventum Consulting. SQL auf Hadoop Oliver Gehlert. 2014 Ventum Consulting Beratung Results, no Excuses. Consulting Lösungen Grown from Experience. Ventum Consulting SQL auf Hadoop Oliver Gehlert 1 Ventum Consulting Daten und Fakten Results, no excuses Fachwissen Branchenkenntnis

Mehr

Oracle BI EE mit großen Datenmengen

Oracle BI EE mit großen Datenmengen Oracle BI EE mit großen Datenmengen Christian Casek Riverland Solutions GmbH München Schlüsselworte: Oracle BI EE, Oracle BI Applications, Informatica, RPD, große Datenmengen, Performance, Performanceoptimierung,

Mehr

Die richtige Cloud für Ihr Unternehmen.

Die richtige Cloud für Ihr Unternehmen. Die richtige Cloud für Ihr Unternehmen. Das ist die Microsoft Cloud. Jedes einzelne Unternehmen ist einzigartig. Ob Gesundheitswesen oder Einzelhandel, Produktion oder Finanzwesen keine zwei Unternehmen

Mehr

HANA. TOBA-Team Dresden 19.05.2012

HANA. TOBA-Team Dresden 19.05.2012 HANA TOBA-Team Dresden 19.05.2012 Kunde droht mit Auftrag! Ein großer Discounter schickt Anfrage: Bis wann und zu welchem Preis können Sie 30.000 Stück liefern? Die Hektik beginnt! Bis wann Welche und

Mehr

Die aktuellen Top 10 IT Herausforderungen im Mittelstand

Die aktuellen Top 10 IT Herausforderungen im Mittelstand Die aktuellen Top 10 IT Herausforderungen im Mittelstand Ronald Boldt, SPI GmbH Über mich Ronald Boldt Leiter Business Solutions SPI GmbH Lehrbeauftragter für Geschäftsprozess orientiertes IT Management

Mehr

Zeitgemäße Verfahren für ganzheitliche Auswertungen

Zeitgemäße Verfahren für ganzheitliche Auswertungen Intelligente Vernetzung von Unternehmensbereichen Zeitgemäße Verfahren für ganzheitliche Auswertungen Sächsische Industrie- und Technologiemesse Chemnitz, 27. Juni 2012, Markus Blum 2012 TIQ Solutions

Mehr