Solution Approaches for Big Data
Werbung
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 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 Daten – Der größte Aktivposten eines jeden Unternehmens Klassische Business Intelligence Die Situation hat sich geändert Veränderte Anforderungen an die Business Intelligence Big Data – Worum geht es dabei eigentlich? Warum traditionelle Lösungen ungeeignet sind Verteilte Parallelverarbeitung Apache Hadoop Hadoop Distributed File System (HDFS) Hadoop MapReduce YARN (Yet Another Resource Negotiator) Apache Hadoop-Unterprojekte Die destillierte Essenz von Big Data In-Memory Plattform In-Memory Datenbanken (IMDB) In-Memory Data Grid (IMDG) Infrastrukturoptimierung für relationale Datenbanken Datenbanken für Big Data Complex Event Processing Referenzarchitektur für Big Data Bei Big Data geht es aber nicht nur um die Infrastruktur Ihr Weg zu Big Data Betrieb von Big-Data-Infrastrukturen IaaS, PaaS, SaaS oder sogar Data Science als Service? Welchen Beitrag kann Fujitsu leisten? Zusammenfassung Seite 1 von 16 2 2 2 2 3 3 4 5 5 5 6 6 7 7 8 8 9 9 10 12 13 14 14 15 15 16 16 www.fujitsu.com/de White Paper Lösungsansätze für Big Data 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. Seite 2 von 16 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 E-Mails, 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. www.fujitsu.com/de White Paper Lösungsansätze für Big Data 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 18 sprechen von einem Datenvolumen von 2,5 x 10 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, E-Mails 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. Seite 3 von 16 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,. www.fujitsu.com/de White Paper Lösungsansätze für Big Data 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. Seite 4 von 16 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, 10 - 50 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. www.fujitsu.com/de White Paper Lösungsansätze für Big Data 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. 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. 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. 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. Ähnlich wird die Verarbeitung der Daten verteilt, indem Rechenprozesse auf die Serverknoten verlagert werden, auf denen die Daten liegen. 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. Seite 5 von 16 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. www.fujitsu.com/de White Paper Lösungsansätze für Big Data 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 www.fujitsu.com/de White Paper Lösungsansätze für Big Data 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 www.fujitsu.com/de White Paper Lösungsansätze für Big Data 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 1.000- bis 10.000-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. Seite 8 von 16 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 10 - 50-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. www.fujitsu.com/de White Paper Lösungsansätze für Big Data 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. Seite 9 von 16 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. www.fujitsu.com/de White Paper Lösungsansätze für Big Data 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. 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. 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. Es gibt eine Reihe unterschiedlicher Datenmodelle für NoSQL-Datenbanken, die für die Lösung unterschiedlicher Problemstellungen optimiert wurden. 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. 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 www.fujitsu.com/de White Paper Lösungsansätze für Big Data 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. Dictionary compression Region Product Sales Vendor 0 Europe 0 Mice 0 750 0 Tigerfoot 1 America 1 Rabbits 1 1100 1 Lionhead 2 Asia 2 Rats 2 250 3 2000 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. 0 1 1 2 0 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 0 Europe Mice 1 America Mice 2 America Rabbits 3 Asia Rats 4 Europe Rats Sales 750 1100 250 2000 2000 Vendor Tigerfoot Lionhead Tigerfoot Lionhead Tigerfoot Column-oriented store Key Region Product 0 Europe Mice 1 America Mice 2 America Rabbits 3 Asia Rats 4 Europe Rats Sales 750 1100 250 2000 2000 Vendor Tigerfoot Lionhead Tigerfoot Lionhead Tigerfoot SELECT SUM (Sales) GROUP BY Region Data required Data read, but not required 0 0 1 2 2 0 1 2 3 3 0 1 0 1 0 Run-length compression Region Product Sales Vendor 0 Europe 0 Mice 0 750 0 Tigerfoot 1 America 1 Rabbits 1 1100 1 Lionhead 2 Asia 2 Rats 2 250 3 2000 0 1 2 0 x1 x2 x1 x1 0 x2 1 x1 2 x2 0 1 2 3 x1 x1 x1 x2 0 1 0 1 0 x1 x1 x1 x1 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. Spaltenorientierte Datenbanken sind selbstindizierend. Obwohl sie dieselben Vorteile für die Abfrageleistung bieten wie Indizes, ist kein zusätzlicher Indexbereich erforderlich. 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 www.fujitsu.com/de White Paper Lösungsansätze für Big Data 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. Seite 12 von 16 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. www.fujitsu.com/de White Paper Lösungsansätze für Big Data Referenzarchitektur für Big Data Nachdem nun die wesentlichen Infrastrukturkonzepte für Big Data behandelt wurden, soll im nächsten Schritt eine Referenzarchitektur betrachtet werden, in der diese Konzepte berücksichtigt sind. Je nach Anwendungsfall kommen manche Technologien nur alternativ zum Einsatz, oder sie sind möglicherweise gar nicht erforderlich. Die Referenzarchitektur stellt letztlich einen Technologiebaukasten dar, aus dem für jede kundenspezifische Situation eine optimale Lösung als Kombination verschiedener Technologien konzipiert werden kann. Bei weniger zeitkritischen Anwendungsfällen, kann sich die SQL-Datenbank durchaus auf einem zentralen Plattenspeichersystem befinden, das zweckmäßigerweise über eine Hochgeschwindigkeitsverbindung mit dem entsprechenden Datenbank-Server verfügt. Die Verwendung schneller Speichersysteme, wie bspw. All-Flash-Arrays (AFA), die von Hause aus für Solid State Disks (SSD) konzipiert sind, und sich durch extrem hohe I/O-Leistung und geringe Latenzzeiten auszeichnen, kann hier weitere Vorteile bringen. Beginnen wir mit einer kurzen Zusammenfassung der in der Abbildung unten gezeigten Abläufe. Daten werden aus verschiedenen Datenquellen extrahiert. Bei diesen Datenquellen kann es sich handeln um Transaktionssysteme und Data Warehouses, aber auch um Protokolldateien, Click Streams, Internetseiten, die auch miteinander verlinkt sein können, E-Mails, Textdateien und Multimedia-Dateien. Und falls bereits eine IMDB im Einsatz ist, kann diese auch als Datenquelle herangezogen werden. Sind jedoch Analyseergebnisse in Echtzeit gefragt, bietet sich eine IMDB an. Alternativ kann ein IMDG etabliert werden, um die destillierte Essenz entweder komplett oder zumindest zu großen Teilen hauptspeicherresident zu halten, und die Analyse-Applikationen drastisch zu beschleunigen. Zur Beschleunigung der Extraktion von Daten auf Plattenspeichern kann optional ein IMDG eingesetzt werden. Dies ist nicht nur für die Big Data-Anwendung von Vorteil, sondern auch für jede andere Applikation, die diese Daten benötigt. Die Daten aus den genannten Quellen werden in ein verteiltes Datenhaltungssystem importiert, bspw. das HDFS, welches als Sammelbecken für große Datenmengen dient und sich über die lokalen Plattenspeicher von Rechnerknoten erstreckt. Über verteilte Parallelverarbeitung werden die Daten bereinigt und vorbearbeitet. Die Analyse und die Visualisierung der Analyseergebnisse kann unmittelbar auf das verteilte Datenhaltungssystem angewandt werden. Alternativ können durch verteilte Parallelverarbeitung transformierte Daten als destillierte Essenz in ein anderes Datenhaltungssystem exportiert werden. Dies ist in aller Regel entweder eine SQL- oder eine NoSQL-Datenbank. Auf diese Datenbank finden dann entsprechend auch die Analysen statt. Seite 13 von 16 Während Daten aus den oben erwähnten Quellen typischerweise mit Hilfe von Hadoop und MapReduce im Batchbetrieb verarbeitet werden, müssen z.B. Sensordaten, Eindringversuche, Kreditkartentransaktionen, oder andere mit hoher Frequenz generierte Ereignisströme mittels einer CEP-Plattform in Echtzeit erfasst und analysiert werden, damit auch die entsprechenden Maßnahmen in Echtzeit eingeleitet werden können. Als Datenspeicher für Complex Event Processing wird der Hauptspeicher genutzt, je nach Komplexität auch ein IMDG. Ergebnisse aus den der CEP-Engines können auch nach Hadoop, bzw. an die destillierte Essenz außerhalb Hadoop zwecks Weiterverarbeitung oder Visualisierung weitergeleitet werden. Gleichermaßen werden Hadoop-Daten manchmal auch für CEP genutzt. Die Pfeilstärke in der Abbildung steht stellvertretend für das Datenvolumen, welches zwischen den einzelnen Instanzen der Big Data-Referenzarchitektur bewegt wird. www.fujitsu.com/de White Paper Lösungsansätze für Big Data Wie jeder hybride Lösungsansatz erweckt dies auf den ersten Blick den Anschein einer hohen Komplexität. Umso wichtiger ist es, den Endanwender nicht mit dieser hohen Komplexität zu konfrontieren. Dies ist über den Einsatz entsprechender Konnektoren zwischen den Teilsystemen, bzw. durch Datenadapter zu erreichen, die einen reibungslosen Übergang ermöglichen. Letztlich entscheidend für den Endanwender ist jedoch, dass die für ihn bereitgestellten Analysefunktionen sich – für ihn vollkommen transparent - der richtigen Daten aus den richtigen Datenspeichern bedienen. Für den Anwender ist nicht die zu Grunde liegende Technologie entscheidend, sondern die Einsicht in die verfügbaren Daten, und das Gewinnen von Erkenntnissen, die ihn und seinen Geschäftsauftrag nach vorne bringen. Bei Big Data geht es aber nicht nur um die Infrastruktur Bisher wurde erörtert, was unter Big Data zu verstehen ist, welche Vorteile Sie davon erwarten dürfen, welche Lösungsansätze und sogar welche Kombinationen von Lösungsansätzen sinnvoll sein könnten, und wie die Gesamtarchitektur von Lösungen aussieht. Es würde dem Thema jedoch nicht gerecht werden, wenn wir unsere Betrachtung hier beenden würden, da es bei Big Data nicht nur um die Infrastruktur geht. Wer sich für Big Data-Verarbeitung entscheidet, stellt hohe Ansprüche an die Qualität der zu erwartenden Ergebnisse. Hierfür ist die Aufbereitung von Rohdaten zu qualitativ hochwertigen Informationen eine entscheidende Voraussetzung. Daten von geringer Qualität führen zu minderwertiger Ergebnisqualität und einer unbefriedigenden Benutzererfahrung, und Ihr Big Data-Projekt stellt sich im Endeffekt als Zeit- und Geldverschwendung heraus. Eines der am weitesten verbreiteten Probleme, auf das wir in Unternehmen immer wieder stoßen, besteht darin, dass zu viele Daten und zu wenige Ressourcen vorhanden sind und es darüber hinaus auch an analytischem und technischem Know-how mangelt. Dies führt dazu, dass manche Fragen nicht immer hinreichend beantwortet werden können. Hier einige Beispiele: Welche Daten von welchen Datenquellen? Nach was sollen gesucht werden? Wie sieht die Fragestellung bei den Abfragen aus? Welche Aktionen sind anzustoßen? Welche Analysemethoden? Welche Art der Visualisierung? Welche Tools? Wie sind die Tools zu benutzen? Wie kann man die Bedeutung der Daten entdecken? Wie kann eine interaktive Erforschung der Daten aussehen? Welche Daten sind wie lange aufzubewahren? Welche Daten können gelöscht werden? Wie sehen die ersten Schritte aus? Besonders der Analysebereich bedarf besonderer Aufmerksamkeit. Immer mehr Unternehmen interessieren sich für den so genannten „Data Scientist“, eine Fachkraft, die Kompetenz in den Bereichen Datenanalyse, Mathematik und Informatik mitbringt, über ein umfangreiches Branchenwissen verfügt und beauftragt wird, sich eingehend mit der Datenthematik zu befassen. Seite 14 von 16 Ihr Weg zu Big Data Schauen Sie sich nun die Schritte an, die zur erfolgreichen Einführung von Big Data-Analyseverfahren in einem Unternehmen erforderlich sind. Zunächst gilt es, die Big Data-Strategie mit Ihrer Unternehmensstrategie in Einklang zu bringen. Ein erster Schritt besteht daher darin, die Bereiche zu identifizieren, in denen durch neue Erkenntnisse die größten Auswirkungen erzielt werden können. Teilen Sie Ihre Big Data-Strategie dann in überschaubare Zwischenziele ein, fragen Sie sich, welche Analyseergebnisse Sie benötigen oder welche Entscheidungen getroffen werden müssen, und was Sie dazu wissen müssen. Hierbei geht es nicht zwangsläufig um Maximalziele. Konzentrieren Sie sich jeweils nur auf ein Teilziel. Dies trägt dazu bei, die Projektzeit zu verkürzen und die Wertschöpfung zu beschleunigen. Stellen Sie eine funktionsübergreifende Arbeitsgruppe aus Dateneigentümern, System- und Tool-Eigentümern sowie Vertretern der Endanwender zusammen. Dateneigentümer kennen sich mit ihren Daten aus. Sie wissen, welche Daten erforderlich sind und aus welchen Quellen sie stammen. System- und Tool-Besitzer kennen sich mit den Systemarchitekturen und den Tools aus. Sie sind mit den in Frage kommenden Tools vertraut und in der Lage, die verteilten Datenquellen zu integrieren. Die Endanwendervertreter sollten eine klare Vorstellung davon haben, welche Anforderungen an die gewünschten Ergebnisse gestellt werden. Sobald Ihr funktionsübergreifendes Team einsatzbereit ist, können Sie damit beginnen, Testfälle zu erstellen. Bereiten Sie die geeigneten Daten für die Analyse vor, stellen Sie die benötigte Hardware und geeignete Tools zusammen, und beginnen Sie nach Möglichkeit mit einer kleinen Infrastruktur. Versuchen Sie nicht, das Rad neu zu erfinden. Besser ist es, nach dem Bibliotheks-Ansatz vorzugehen. Wählen Sie aus den bereits vorhandenen die brauchbaren Algorithmen aus, und passen Sie sie an Ihre Anforderungen an. Hierdurch sparen Sie Zeit und Geld. Analysieren Sie dann die Daten, und visualisieren Sie die Ergebnisse. Probieren Sie unterschiedliche Datenkombinationen aus, um neue Erkenntnisse zutage zu fördern, und stellen Sie Fragen, die bisher noch nicht gestellt wurden. Eines ist hierbei besonders wichtig: Machen Sie die Ergebnisse allen im Unternehmen zugänglich, die Nutzen daraus ziehen könnten. Nur so können Sie von eventuellen Rückmeldungen und Anregungen profitieren. Darüber hinaus müssen Sie sich mit Problemen auseinandersetzen, die in den Bereichen Sicherheit, Datenschutz, Compliance oder Haftung entstehen könnten. Wenn Sie diese Schritte erfolgreich absolviert haben, können Sie den Projektumfang und die Infrastruktur erweitern. www.fujitsu.com/de White Paper Lösungsansätze für Big Data Bei all dem sollten die erforderlichen Veränderungen innerhalb der Unternehmenskultur nicht unerwähnt bleiben. Insbesondere Datenund Prozesseigentümer müssen bereit sein, die Kontrolle über Dinge abzugeben, die zuvor allein in ihren Händen lag. Entscheidungsträger müssen lernen, Analyseergebnisse zu akzeptieren und zu respektieren. Häufig ist dies nur möglich, wenn die Geschäftsleitung einen entsprechenden Beitrag leistet und Unterstützung anbietet. Betrieb von Big-Data-Infrastrukturen Nachdem wir nun recht ausführlich über zusammengesetzte Konzepte und Referenzarchitekturen für Big Data mit ihren verschiedenen Technologiebausteinen gesprochen haben, bleibt die Frage, wie die IT-Infrastruktur für Big Data zweckmäßigerweise betrieben werden sollte. Eine Option ist sicherlich der Eigenbetrieb im eigenen Rechenzentrum. Hier können vordefinierte, vorgetestete und vorintegrierte Konfigurationen, Appliances und optimal aufeinander abgestimmte Hardware- und Softwarekomponenten dazu beitragen, die Einführung und auch die Verwaltung entscheidend zu vereinfachen. Der Aufbau, die Integration und der Betrieb einer Big Data-Infrastruktur ist jedoch aufwändig, erfordert Personal und entsprechendes Spezialwissen. Insbesondere bei Personalknappheit oder nicht vorhandenem Spezialwissen, kann es sinnvoll sein, sich auf seine Kernkompetenzen zu konzentrieren und den Betrieb der Infrastruktur einem Dienstleister zu überlassen, der diesen Service schneller, besser und auf Grund der erzielbaren Skaleneffekte auch kostengünstiger bereitstellen kann. Immer mehr Unternehmen sind nicht mehr daran interessiert, komplexe Infrastrukturen im eigenen Rechenzentrum zu halten. In diesem Falle ist Big Data aus der Cloud eine interessante Alternative, die den Anwender schließlich von Vorabinvestitionen und allen Betriebsaufgaben befreit. Der Aufwand für Installation, Konfiguration und Wartung entfällt vollständig. Auch eine Kapazitätsplanung ist nicht mehr erforderlich. Die benötigten Kapazitäten lassen sich flexibel an den sich verändernden Bedarf anpassen, insbesondere im Fall von gelegentlich oder periodisch auftretenden Belastungsspitzen. Es gibt aber auch gute Gründe, die Daten im eigenen Rechenzentrum zu belassen. So zum Beispiel, wenn es um interne Daten geht, bspw. Sensordaten von Fertigungsstraßen oder Videodaten von Sicherheitssystemen, die einen erheblichen Datenverkehr im Netz verursachen würden. Ebenso bei sensiblen Daten, bei denen der Verlust ein enorm hohes Risiko für das Unternehmen mit sich bringt, bzw. die auf Grund von Compliance-Anforderungen gar nicht in ein Public Cloud verlagert werden dürfen. Oder aber riesige Mengen flüchtiger Daten, die in einer derart hohen Frequenz anfallen, dass sie nicht schnell genug in die Cloud weitergeleitet werden können. IaaS, PaaS, SaaS oder sogar Data Science als Service? Wenn man erst mit Big Data aus der Cloud liebäugelt, stellt sich die Frage, was nun genau aus der Cloud geliefert werden soll. Am einfachsten ist es sicherlich, wenn man sich weder um die Analyse-Applikationen und die Middleware, noch die Infrastruktur inklusive Serversystemen, Speichersystemen und Netzen kümmern muss. Unternehmen können die Infrastruktur eines Cloud-Anbieters inklusive Serversystemen, Speichersystemen und Netzkomponenten nutzen, kümmern sich aber selbst um Middleware und Analysetools. In diesem Fall spricht man von Infrastructure as a Service (IaaS,). Wird zusätzlich zur Infrastruktur auch die Big Data Middleware, bspw. das Hadoop-Ökosystem vom Cloud-Anbieter bezogen, spricht man von Platform as a Service (PaaS). Bei Software as a Service (SaaS) nutzen Unternehmen auch die Analysetools des Cloud-Anbieters. Somit bleibt für das Unternehmen „nur“ noch die Aufgabe, die so oft zitierte Nadel im Heuhaufen zu finden, also die Data Science-Fragen zu klären, für die man angeblich die händeringend gesuchten Data Scientists benötigt. Da diese sehr rar sind, gehen manche Cloud-Anbieter noch einen Schritt weiter und bieten Data Science as a Service an, ein Service, der dem Kunden quasi die Nadel im Heuhaufen sucht und findet. Insbesondere erübrigt sich dann auch die häufig diskutierte Frage, ob die riesigen Mengen externer Daten tatsächlich durch die Unternehmens-Firewall geschleust werden müssen. Abgerechnet wird Big Data aus der Cloud nach Nutzung der angebotenen Services (Pay-per-Use). Welche Parameter bei der Kostenfindung eine Rolle spielen, hängt vom Cloud-Dienst und vom Cloud-Dienstleister ab. Jedenfalls bietet Big Data aus der Cloud eines Cloud-Anbieters ein beachtliches Potenzial für Kostenreduzierung end ebnet damit den Weg zu Big Data trotz begrenzter Budgets. Falls Big Data aus der Cloud bereitgestellt wird, sollten auch die wesentlichen Datenquellen vom selben Cloud-Anbieter gehostet werden (Storage as a Service). Andernfalls müssten riesige Datenmengen zwischen Netzwerken übertragen werden, was die Ansprüche an eine schnelle Datenanalyse oder gar Echtzeitabfragen ad absurdum führen würde. Seite 15 von 16 www.fujitsu.com/de White Paper Lösungsansätze für Big Data Welchen Beitrag kann Fujitsu leisten? Big Data eröffnet Unternehmen nicht nur ungeahnte Möglichkeiten, sondern stellt sie auch vor Herausforderungen hinsichtlich ihrer Geschäftsprozesse und der erforderlichen Infrastruktur, die nicht zu unterschätzen sind. Mit seinem umfassenden und durchgängigen Dienstleistungsangebot deckt Fujitsu sämtliche Aspekte von Big Data ab; seien es die Daten, die Prozesse oder die IT-Infrastruktur. Wir beraten unsere Kunden, was mit Big Data erreicht werden kann und legen gemeinsam die Roadmap für die Erreichung der Ziele fest. Wir planen und priorisieren die Anwendungsfälle, entwerfen und implementieren die Lösung, integrieren sie in die bestehende Systemlandschaft und übernehmen die Wartung für die Gesamtlösung, bei Bedarf auch vollkommen konsistent über Ländergrenzen hinweg oder sogar global. Unsere Services basieren auf bewährten Methoden und unserer Projekterfahrung über verschiedene Branchen hinweg. Fujitsu unterstützt sämtliche relevanten Big Data-Infrastrukturkonzepte und ist daher stets in der Lage, die optimale Kombination von Technologien für eine kundenspezifische Situation und individuelle Anforderungen zu erarbeiten. Ob Sie nun einen Server-Cluster mit Hadoop Open Source-Software benötigen, und egal wie groß dieser auch sein muss, ob Sie In-Memory-Technologien für Echtzeitanforderungen benötigen oder Plattenspeicher-basierte Lösungen ausreichen, oder selbst wenn eine Kombination aus unterschiedlichen Ansätzen speziell für Sie erstellt werden muss, Fujitsu findet stets die richtige Antwort, um die geeignete Lösung vor Ort für Sie bereitzustellen. In Big Data Lösungen von Fujitsu sind enthalten unsere PRIMERGY Industrie-Standard-Server und unsere PRIMEQUEST Server, die selbst Unternehmenskritische Anforderungen höchsten Grades erfüllen. Darüber hinaus die ETERNUS DX Speichersysteme von Fujitsu, bzw. All-Flash-Array von unserem Partner Violin Memory. Die verwendete Software ist entweder von Fujitsu selbst, Open Source, oder von führenden ISV (Independent Software Vendor), mit denen wir eine enge Partnerschaft pflegen. Zur Datensicherung und Archivierung ist Fujitsu ETERNUS CS die Lösung der Wahl. Da die Produkte von Fujitsu auf Standards basieren, vermeiden Sie die Abhängigkeit von einem einzelnen Anbieter. Integrierte Systeme erleichtern den Einstieg und bringen Sie schnell an Ihr Ziel. Besonders erwähnenswert sind in diesem Zusammenhang FUJITSU Integrated System PRIMEFLEX for Hadoop (ein Hadoop-Cluster, das selbst Anwendern aus den Fachbereichen einfache Analysen ermöglicht), FUJITSU Integrated System PRIMEFLEX for SAP HANA (die IMDB-Lösung von SAP) und die IMDG-Lösung FUJITSU Integrated System PRIMEFLEX for Terracotta BigMemory. Kontakt FUJITSU Technology Solutions GmbH Mies-van-der-Rohe-Straße 8, 80807 München, Deutschland Tel.: +49-7203-922078 Fax: +49 -821-804-88429 E-Mail: [email protected] Website: www.fujitsu.com/de Seite 16 von 16 Attraktive Finanzierungsoptionen ermöglichen sogar die Einführung von Big Data ohne jede Vorabinvestition. Wenn Sie noch einen Schritt weiter gehen und den Betrieb Ihrer Big Data-Infrastruktur in unsere Hände legen möchten, damit Sie sich besser um Ihre Kernkompetenzen und strategischen Projekte kümmern können, bietet Fujitsu Ihnen entsprechende „Managed Data Center Services“. Die monatliche Abrechnung lässt dabei Ihre Investitionsausgaben zu Betriebsausgaben werden. Wenn Sie sich überhaupt nicht mit Infrastrukturaspekten befassen möchten, können Sie Big Data-Analysen auch als Service über die Fujitsu Cloud beziehen. Mit anderen Worten: Fujitsu ist Ihre zentrale Anlaufstelle für Big Data-Infrastrukturen, die Ihnen Komplettlösungen inklusive sämtlicher Sourcing-Optionen aus einer Hand bietet. Auf diese Weise reduzieren Sie Komplexität, Zeit und Risiko. Zusammenfassung Bei Big Data geht es nicht allein um große Datenmengen. Ebenfalls charakteristisch ist die Vielzahl unterschiedlicher Datentypen, Datenquellen und Interpretationsmöglichkeiten, die erforderliche Geschwindigkeit angesichts kontinuierlich entstehender neuer Daten und die Herausforderung, Analyseergebnisse möglichst schnell bereitzustellen. Und natürlich geht es auch um die Technologien, die all dies auf erschwingliche Weise ermöglichen sollen. Big Data bietet enormes Wertschöpfungspotenzial. Wenn Sie sich anstelle oftmals falscher Intuitionen auf Echtzeitdaten verlassen, werden Sie in Zukunft intelligentere Entscheidungen treffen. Wenn man wettbewerbsfähig sein möchte, führt kein Weg an Big Data vorbei. Halten Sie sich immer vor Augen: Sie mögen Big Data ignorieren, Ihre Mitbewerber aber bestimmt nicht! Daher empfiehlt es sich, so früh wie möglich im Ozean von Big Data schwimmen zu lernen. Abhängig von den Geschäftsanforderungen, der bereits vorhandenen Infrastruktur und weiteren Aspekten sind eine Vielzahl unterschiedlicher Lösungsansätze und sogar eine Kombination derselben vorstellbar. Fujitsu bietet komplette Big Data-Lösungen inklusive Hardware, Software und Services – alles aus einer Hand. Das macht Fujitsu zum idealen Partner für Big Data-Lösungen und garantiertem Erfolg. ƒ Copyright 2015. Fujitsu und das Fujitsu-Logo sind Marken oder eingetragene Marken von Fujitsu Limited in Japan und anderen Ländern. Andere Firmen-, Produkt- und Servicebezeichnungen können Marken oder eingetragene Marken der jeweiligen Eigentümer sein. Änderungen bei den technischen Daten vorbehalten. Lieferung unter dem Vorbehalt der Verfügbarkeit. Haftung oder Garantie für Vollständigkeit, Aktualität und Richtigkeit der angegebenen Daten und Abbildungen ausgeschlossen. Wiedergegebene Bezeichnungen können Marken und/oder Urheberrechte sein, deren Benutzung durch Dritte für eigene Zwecke die Rechte der Inhaber verletzen kann. www.fujitsu.com/de
