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 3 Veränderte Anforderungen an die Business Intelligence 3 Big Data Worum geht es dabei eigentlich? 3 Warum traditionelle Lösungen ungeeignet sind 4 Big Data erfordert Parallelisierung 5 Verteilte Dateisysteme und der Map-Reduce-Algorithmus 5 Big Data und Hadoop 6 Datenbanken für Big Data 6 ETL oder ELT? 8 Der Big Data-Prozessablauf auf einen Blick 9 In-Memory-Technologien 9 Infrastrukturoptimierung für relationale Datenbanken 10 Complex Event Processing 11 Lösungsarchitektur für Big Data 11 Bei Big Data geht es aber nicht nur um die Infrastruktur 12 Ihr Weg zu Big Data 12 Analytics as a Service 13 Welchen Beitrag kann Fujitsu leisten 13 Zusammenfassung 14 Seite 1 von 14

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? 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 Transaktionsystemen 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. 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). 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. Seite 2 von 14

3 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. 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. einer Verzwölffachung 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. 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. 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. Seite 3 von 14

4 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,. 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 im Verborgenen 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 zielgerichteteres 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. Mit anderen Worten: Relationale Datenbanken sind nicht für Massendaten mit extrem hohen Zeilenzahlen geeignet. Hinzu kommt, dass eine Strukturierung von Daten in Zeilen sich gut für OLTP-Anwendungen (Online Transaction Processing) eignet, bei analytischen Aufgabenstellungen aber zwangsläufig eine Menge irrelevanter Daten gelesen wird. Der Grund hierfür ist, dass nur bestimmte Informationen aus bestimmten Spalten von Bedeutung sind. 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 Amdahlschem Gesetz zu einer Abnahme der Servereffizienz und einer Einschränkung der Parallelisierung. 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, an dem sie dem Anwender 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. 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. Seite 4 von 14

5 Big Data erfordert Parallelisierung 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. Außerdem gibt es eine Instanz bzw. ein Framework, das in der Lage ist, ein definiertes Problem in eine Vielzahl von Teilaufgaben aufzugliedern, diese dann über das Netzwerk auf eine Reihe von parallel verarbeitenden Server verteilt und zum Schluss die Ergebnisse wieder zusammenfasst. Die Parallelisierung 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. Der so genannte Map-Reduce-Algorithmus ist der De-Facto-Standard für paralleles Computing. Bei einer Berechnungsanfrage gliedert der Koordinator die Berechnung in Teilaufgaben, die parallel ausgeführt werden können, und verteilt diese Aufgaben dann auf Serverknoten, die in der Nähe der zu bearbeitenden Daten sind, bzw. ordnet sie ihnen zu. Da die Tasks den einzelnen Serverknoten zugeordnet werden (Mapping), werden sie als Map-Tasks bezeichnet. Die Map-Tasks berechnen Zwischenergebnisse, die der Koordinator möglicherweise sortiert, bevor er sie den Serverknoten zuweist. Diese generieren dann das Endergebnis durch Aggregation, d. h. durch Kombinieren, Zusammenführen und Konsolidieren der Zwischenergebnisse in einem so genannten Reduce-Vorgang. Daher werden diese Tasks als Reduce-Tasks bezeichnet. 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 Dateisysteme und der Map-Reduce-Algorithmus Parallelisierung erfordert eine Art von Middleware, die die eigentliche Parallelisierung übernimmt und für Fehlertoleranz sorgt. Der erste wichtige Baustein ist ein Dateisystem, das über den lokalen Speicher eines Clusters mit einer Vielzahl von Serverknoten verteilt werden kann. Normalerweise umfasst ein verteiltes Dateisystem einen Koordinator, der die ursprünglichen Daten partitioniert und sie dann anhand genau definierter Vorschriften auf die Serverknoten verteilt. Auf jedem Server wird dabei nur ein winziges Fragment des kompletten Datensatzes gespeichert, wobei die Fragmente zusätzlich auf mehrere Server repliziert werden, um hohe Verfügbarkeit zu gewährleisten. Anmerkung: Da die Bearbeitungsprozesse zu den zu verarbeitenden Daten manövriert werden und nicht umgekehrt, ist es möglich, die I/O-Aktivität erheblich zu verringern. Seite 5 von 14

6 Neben der Verteilung von Tasks auf die Serverknoten besteht eine der wichtigsten Aufgaben des Koordinators in der Aufgabenüberwachung. Schlägt die Taskausführung aus irgendeinem Grund fehl, wird der Vorgang erneut ausgeführt, in der Regel per Failover auf einen Serverknoten, auf dem eine Kopie der betreffenden Daten vorhanden ist. Der Map-Reduce-Algorithmus setzt voraus, dass die parallelen Tasks vollständig unabhängig voneinander sind, da für ihre Ausführung keine gemeinsamen Ressourcen genutzt werden. Dies ist der Hauptgrund für die lineare Skalierbarkeit. Map-Reduce wird bei Business Analytics-Abfragen angewendet, wird aber auch genutzt, um Daten erst in eine für Analyseverfahren optimierte Form zu bringen. Big Data und Hadoop Wenn wir von Big Data im Sinne unserer Definition sprechen hohes Datenvolumen und hohe Verarbeitungsgeschwindigkeit, verschiedene Datenquellen und -typen geht praktisch kein Weg an Hadoop vorbei. Auf die eine oder andere Art werden Sie mit Hadoop in Kontakt kommen. Hadoop ist eine Plattform für verteilt arbeitende Software und der Branchenstandard für Big Data-Umgebungen. Die Hauptbestandteile von Hadoop sind das Hadoop Distributed File System (HDFS) und Hadoop MapReduce, eine Implementierung des Map-Reduce-Algorithmus. Hadoop ist für die Verarbeitung von strukturierten und unstrukturierten Daten sowie einer großen Vielzahl unterschiedlicher Datentypen geeignet. Das Hadoop-Softwareframework wurde in Java programmiert. Es lässt sich horizontal auf mehrere Tausend Serverknoten skalieren, akzeptiert Serverausfälle in großen Farmen als Normalzustand und sorgt so für stabile Speicher- und Analyseprozesse. Die Open Source Software wurde zum Top-Level-Projekt der Apache Software Foundation erklärt. Darüber hinaus gibt es eine Reihe von Unterprojekten und Erweiterungen, die Hadoop zu einer universell einsetzbaren Plattform für Analyseanwendungen machen. Zu den Unterprojekten gehören eine Skriptsprache für die parallele Verarbeitung (Pig), eine interaktive Abfragesprache für Ad-hoc-Abfragen und Reporting (Hive), NoSQL-Datenbanken (HBase und Cassandra), Hilfswerkzeuge für die Erfassung (Chukwa und Flume) und Serialisierung (Avro) von Daten, eine Bibliothek von Modulen zur Implementierung von Koordinations- und Synchronisierungsdiensten (Zookeeper) sowie eine Bibliothek für maschinelles Lernen und Data Mining (Mahout). Datenbanken für Big Data Wie bereits erwähnt, eignen sich relationale Datenbanken eigentlich nur für strukturierte Daten von begrenztem Umfang, da sonst die Performance, die für Abfragen mit akzeptablen Zugriffszeiten erforderlich ist, nicht erreicht wird. Big Data überschreitet diese Volumenbeschränkung und enthält eine Vielzahl unstrukturierter Daten. Wenn Sie die Vorteile nutzen möchten, die ein Datenbanksystem gegenüber einem Dateisystem hat, z. B. die bessere Abfragesprache, hilft Ihnen eine NoSQL-Datenbank (Not only SQL), die Einschränkungen des relationalen Modells zu überwinden. NoSQL-Datenbanken sind speziell auf Big Data-Anwendungen ausgelegt. Aufgrund Ihres einfachen Aufbaus können sie als schneller Datenspeicher mit extrem hohen Durchsatzraten genutzt werden. NoSQL-Datenbanken lassen sich außerdem auf die Serverknoten in einem Cluster verteilen und ermöglichen deshalb eine fast lineare Skalierbarkeit und hohe Fehlertoleranz. Die Abfragen selbst ähneln den Abfragen in SQL. Es gibt eine Reihe unterschiedlicher Datenmodelle für NoSQL-Datenbanken, die für die Lösung unterschiedlicher Problemstellungen optimiert wurden. Die erste Variante, die wir uns anschauen, sind die so genannten Key-Value-Stores, in denen Schlüssel/Wert-Paare in großen Mengen gespeichert werden, wobei der Schlüssel einen Wert eindeutig referenziert und deshalb auch für den Zugriff auf den Wert verwendet wird. Der Wert selbst kann als strukturierter oder beliebiger Datentyp vorliegen. Die zweite Ausprägung, die hier vorgestellt werden soll, sind die dokumentorientierten Datenbanken. Die einzelnen Dokumente sind semistrukturierte Zusammensetzungen aus Schlüsseln und Zeichenketten von beliebiger Länge, und es gibt keine Beziehungen zwischen den Dokumenten. Abfragen in dokumentorientierten Datenbanken werden mithilfe von Map-Reduce ausgeführt. Der dritte Typ von NoSQL-Datenbanken sind die so genannten Graphen-Datenbanken. Informationen werden in Diagrammen durch Knoten und Kanten mitsamt deren Eigenschaften dargestellt. Eine der häufigsten Berechnungen in einer Graphen-Datenbank ist die Suche nach der einfachsten und effizientesten Route durch den gesamten Graphen. Anwendungsgebiete sind die Fahrplanoptimierung, geografische Informationssysteme (GIS), Hyperlinkstrukturen sowie die Darstellung von Nutzerbeziehungen innerhalb sozialer Netzwerke. Seite 6 von 14

7 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. Stellen Sie sich riesige Tabellen mit Milliarden von Zeilen vor, von denen jede einzelne einen Datensatz darstellt. Die Anzahl der Spalten pro Datensatz ist dagegen vergleichsweise gering. Hinzu kommt, dass sich viele Abfragen nur auf eine Teilmenge der Spalten beziehen. In einem zeilenorientierten Datenspeicher, müssen für jede Abfrage alle Spalten gelesen werden, eine Vorgehensweise, die wenig effizient ist. Spaltenorientierte Datenbanken sind selbstindizierend. Obwohl sie dieselben Vorteile für die Abfrageleistung bieten wie Indizes, sind kein zusätzlicher Speicherplatz für die Indizierung und kein spezieller Indexbereich erforderlich. Da Spaltendaten einen einheitlichen Datentyp haben und es meist nur wenige verschiedene Werte pro Spalte gibt, ist es sinnvoll, nur diese wenigen, eindeutigen Werte zusammen mit auf sie verweisenden Zeigern zu speichern. Auf diese Weise lässt sich eine sehr hohe Kompression erzielen. Durchschnittliche Kompressionsraten liegen im Bereich von Hierdurch lassen sich die Speicherkapazitäten und folglich auch die Speicherkosten reduzieren. Das spaltenweise Speichern von Daten erhöht die Effizienz. Der Zugriff wird auf die für eine Abfrage relevanten Spalten beschränkt, es besteht keine Notwendigkeit, irrelevante Daten zu lesen. 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. 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 7 von 14

8 ETL oder ELT? In klassischen BI-Lösungen werden in einem ersten Schritt Daten aus einer oder mehreren Datenquellen extrahiert. Während der Extraktion werden die Daten gleichzeitig bereinigt, d. h. inkonsistente oder doppelt vorhandene Daten werden ignoriert. Danach werden die Daten in eine für das jeweilige Analyseverfahren geeignete Struktur gebracht. Entsprechend seinem Verarbeitungsablauf wird dieses Verfahren als Extrahieren-Transformieren-Laden, oder kurz ETL, bezeichnet. Aus diesen Gründen hat sich bei der aktuellen Behandlung von Big Data eine neue Vorgehensweise durchgesetzt, nämlich ELT (Extrahieren-Laden-Transformieren). Nach der Extraktion aus verschiedenen Datenquellen und der Bereinigung wird die gesamte Datenmenge umgehend ins Data Warehouse oder einen alternativen Datenspeicher geladen. Auf diese Weise wird der Data Warehouse-Prozess in zwei separate Vorgänge unterteilt, bei denen das Extrahieren und Laden von Daten vollkommen unabhängig von der Transformierung geschieht. Die Transformierung in ein optimales Format erfolgt nämlich erst dann, wenn eine konkrete Aufgabenstellung für die Analyse vorhanden ist. Dies ermöglicht eine schnelle und flexible Anpassung an neue Gegebenheiten. Darüber hinaus wird das Projektmanagement erleichtert, weil sich das Projekt in einfacher zu handhabende Stücke aufteilen lässt und Risiken und Kosten überschaubarer werden. Im Grunde setzt ETL eine BI-Lösung voraus, deren Entwurf auf einem vorgegebenen Ergebnis basiert. Es ist bereits vorher bekannt, was analysiert werden soll und welche Daten für diesen Zweck benötigt werden. Entsprechend werden nur die Daten extrahiert, transformiert und in das Data Warehouse geladen, die für die Weiterverarbeitung relevant sind. Es gibt eine ganze Reihe von Tools, die für die Umsetzung von ETL geeignet sind. Durch ETL lässt sich das für Analyseverfahren benötigte Datenvolumen reduzieren. Dies geschieht jedoch auf Kosten der Flexibilität. Eine geänderte Geschäftslage macht neue Informationen und folglich eine neue Analyse erforderlich. Zusätzliche ETL-Routinen und starke Abhängigkeiten zwischen den Routinen erfordern oftmals eine aufwändige Umgestaltung des Data Warehouse. Dies kann sich als sehr zeitaufwändig und kostspielig erweisen. Der Nachteil von ELT besteht darin, dass das Design von traditionellen Methoden abweicht und daher nur eine eingeschränkte Anzahl geeigneter Tools verfügbar ist. Es könnte auch bei der Abfrageleistung zu Einbußen kommen, da die Transformation immer noch vor der Analyse stattfindet. Hinzu kommt, dass das zu verarbeitende Datenvolumen in der Regel weitaus größer ist. Dank der Parallelisierung ist dieses Problem jedoch in den Griff zu bekommen. Seite 8 von 14

9 Der Big Data-Prozessablauf auf einen Blick Damit wären die Grundlagen von Big Data erläutert. Im Folgenden geht es um den Big Data-Prozessablauf mitsamt seinen Optionen. In-Memory-Technologien Die Parallelisierung ist hervorragend geeignet, um große Datenmengen schnell und effizient zu verarbeiten. Die Verteilung der I/O-Aktivität auf eine Vielzahl von Serverknoten mit lokalem Speicherplatz trägt dazu bei, die normalerweise bei hohem I/O-Aufkommen auftretenden Engpässe zu vermeiden. Zweifelsohne wird das Speichern und Abrufen von Daten von der Festplatte wohl niemals so schnell sein, als wenn die Daten im Hauptspeicher verbleiben. Genau hier kommen In-Memory-Datenbanken ins Spiel. Wie der Name schon sagt, wird bei In-Memory-Datenbanken das gesamte Datenvolumen zusammen mit den Datenbankanwendungen (gespeicherten Prozeduren) in den Hauptspeicher des Servers geladen, um eine schnelle Analyse zu ermöglichen. In-Memory-Datenbanken werden normalerweise vertikal skaliert. Bei einigen In-Memory-Datenbanklösungen ist auch eine horizontale Skalierung möglich, d. h. einem Cluster werden weitere Server hinzugefügt. Die Skalierbarkeit ist hierbei jedoch bei weitem nicht so massiv und linear wie bei Hadoop-Konfigurationen. Am Anfang stehen Rohdaten, die in Datenquellen generiert werden. Diese werden von dort extrahiert und bereinigt. Wenn die für das Analyseverfahren benötigte Datenstruktur bekannt ist, können die Daten umgehend aufbereitet, d. h in ein besser nutzbares Format transformiert werden, bevor sie in den Datenspeicher geladen werden. Danach können die Daten anhand entsprechender Abfragen analysiert und die Ergebnisse visualisiert werden. Wenn die Nadel im Heuhaufen dabei schon gefunden wurde, stehen bereits Ergebnisse zur Verfügung, die als Grundlage für Entscheidungen und erforderliche Maßnahmen genutzt werden können. Im Allgemeinen ist es jedoch kaum vorstellbar, dass bei der ersten Analyse direkt die entscheidenden Informationen zutage gefördert werden. In den meisten Fällen bedarf es weiterer Durchläufe aus Analyse und Visualisierung, d. h. es ist eine interaktive Analyse erforderlich. Diese dauert normalerweise so lange an, bis die sprichwörtliche Nadel im Heuhaufen entdeckt wurde. Gelingt dies trotzdem nicht, müssen die Daten für eine andere Art von Analyseverfahren erneut aufbereitet werden. Dies bedeutet eine Wiederholung der Transformationsphase, d. h. eine Umformatierung der Daten innerhalb des Datenspeichers, bevor eine neue Analyse ausgeführt werden kann. Wenn nach Extraktion und Bereinigung bereits klar ist, dass mehrere Datentransformationen für unterschiedliche Analyseverfahren erforderlich sein werden, können Sie die Transformationsphase auch überspringen und die Rohdaten in dem Zustand, in dem sie in den Datenquellen zur Verfügung stehen, direkt in den Datenspeicher laden. Die Abbildung unten zeigt einen vereinfachten Prozessablauf. Es spielt keine Rolle, ob es sich bei der Datenbank um eine SQL- oder NoSQL-Datenbank handelt. Auf Festplatten kann für die eigentliche Analyse komplett verzichtet werden, sie werden lediglich für die Protokollierung, Sicherung und Wiederherstellung benötigt, z. B. wenn nach einem Stromausfall der gesamte Inhalt des Hauptspeichers verloren gegangen ist. Lesevorgänge von der Festplatte entfallen bei Verwendung von In-Memory-Datenbanken vollständig. Hierdurch können Daten extrem schnell gespeichert, abgerufen und sortiert werden. Die Analyse von Geschäftsdaten kann so in Echtzeit ausgeführt werden und nimmt nicht Tage oder Wochen in Anspruch. Wichtige Entscheidungen lassen sich mithin viel schneller treffen, was zu einem Wettbewerbsvorteil führen kann. Da sich die gesamte Datenbank im Hauptspeicher befindet, entfällt auch das Cache-Management, für das normalerweise zusätzliche Hauptspeicherkapazität beansprucht wird. Seite 9 von 14

10 Natürlich sollte dabei nicht vergessen werden, dass bei einem Server- oder Stromausfall der gesamte Inhalt des Hauptspeichers verloren geht. Um dies zu verhindern, ist zusätzlich eine Art von permanenter Datenspeicherung erforderlich. Zum Erzielen von Datenpersistenz gibt es eine Reihe von Optionen. Am sichersten ist eine kontinuierliche Datenreplikation auf Festplatte in Echtzeit, die jederzeit einen identischen Status von Hauptspeicher und Festplatte garantiert. Zur Reduzierung der I/O-Last können Schnappschüsse bzw. Protokolldateien, in denen sämtliche Änderungen an den Daten aufgezeichnet werden, auf der Festplatte gespeichert werden. Ähnlich können in einem Servercluster synchronisierte Datenkopien auf alle Serverknoten verteilt werden, wodurch sich aber die insgesamt verfügbare Nettospeicherkapazität reduziert. Datenverlusten nach Stromausfällen kann durch die Verwendung nicht-flüchtiger Speicher oder den Einsatz von Notfallbatterien für den Hauptspeicher begegnet werden. Eine wichtige Frage wurde bisher jedoch noch nicht beantwortet: Was sind die typischen Anwendungsgebiete für In-Memory-Datenbanken? Als wichtigste Einschränkung ist die Datengröße zu nennen, da diese durch die im gesamten Servercluster verfügbare Hauptspeicherkapazität begrenzt wird. Welche Größe bei Hauptspeicher bzw. Cluster gewählt werden kann, hängt wiederum maßgeblich vom verfügbaren Budget ab, wenngleich Arbeitsspeicher (DRAM) immer preiswerter wird. Es stimmt zwar, dass sich die Kapazitätsgrenze durch intelligente Kompressionsverfahren (z. B. in spaltenorientierten Architekturen) um das fache nach oben verschieben lässt, aber im Vergleich zu den weiter oben erörterten Parallelisierungskonzepten ist die Skalierbarkeit von In-Memory-Datenbanken im Grunde beschränkt. In-Memory-Datenbanken sind ideal als Beschleuniger für vorhandene Data Warehouses bzw. transaktionale Datenbanken geeignet, die von der Größenordnung her in einem Bereich von bis zu mehreren Dutzend Terabyte liegen. In einem realen Big Data-Szenario mit Datenvolumen, die diese Größenordnungen bei weitem sprengen, stellt eine In-Memory-Datenbank eine attraktive Leistungsstufe dar. Die Daten werden aus unterschiedlichen Datenquellen erfasst und in ein verteiltes Dateisystem bzw. eine NoSQL-Datenbank geladen, die über eine Vielzahl von Servern innerhalb eines Clusters verteilt ist. Die Daten werden in das für die Analyseaufgabe optimale Format umgewandelt und dann in eine In-Memory-Datenbank exportiert. Alle weiteren Analyseschritte werden dann nur noch im Hauptspeicher ausgeführt. Infrastrukturoptimierung für relationale Datenbanken Die Frage, wie vorhandene Infrastrukturen für relationale Datenbanken in die Big Data-Analyse integriert werden können, ist ein häufig diskutiertes Problem. Für relationale Datenbanken gelten die bereits erörterten Einschränkungen. Deshalb kommen sie für den Umgang mit Big Data eigentlich nicht in Frage. Relationale Datenbanken können jedoch in Big Data-Hadoop-Projekten als Datenquellen eingesetzt werden, und es ist beispielsweise denkbar, eine Untermenge der aufbereiteten Daten zu Analysezwecken in eine relationale Datenbank zu laden. 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? Das im vorherigen Kapitel vorgestellte In-Memory-Datenbankmodell ist eine mögliche Lösung. In diesem Kapitel werden weitere Alternativen behandelt. Eine Möglichkeit ist das Caching, bei dem häufig abgefragte Datensätze im Hauptspeicher 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, z. B 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. 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 Speichertopologien und -protokolle zu integrieren, sind eventuell Hard- oder Software-Gateways erforderlich. Seite 10 von 14

11 Complex Event Processing Ein bedeutender Teilbereich von Big Data ist das so genannte Complex Event Processing (kurz CEP, dt. Verarbeitung komplexer Ereignisse ). Hierbei werden die kontinuierlich und mit hoher Frequenz erzeugten Datenströme erfasst und dann anhand vorab definierter Regeln in Echtzeit analysiert. Je nach Relevanz der Daten werden diese gefiltert und miteinander korreliert. Bei Auftreten von Übereinstimmungen werden Alarme ausgelöst. Zu den Regeln gehören u. a. zeitbasierte Regeln, d. h ein Alarm wird beispielsweise nur dann ausgelöst, wenn innerhalb eines Intervalls mehr als eine vorgegebene Menge an Übereinstimmungen gefunden wird bzw. wenn bestimmte Ereignisse ausbleiben. Der Alarm leitet immer eine entsprechende Maßnahme in Echtzeit ein. Daten werden aus verschiedenen Datenquellen extrahiert. Zusätzlich zu den vorwiegend strukturierten Daten aus transaktionalen Datenbanken, Data Warehouses und In-Memory Datenbanken (IMDB), werden unstrukturierte, semistrukturierte und polystrukturierte Daten aus einer großen Vielfalt anderer Quellen extrahiert und erfasst, z. B. aus Internetseiten, -Systemen, IT-Systemprotokollen usw. Alle diese Daten werden in einen konsolidierten Big Data-Speicher importiert, nachdem sie wahlweise bereinigt und zur Verwendung aufbereitet wurden. Zur Beschleunigung des Festplattenzugriffs kann der Datenbank bzw. dem Data Warehouse optional ein In-Memory-Data-Grid (IMDG) zur Datenpufferung vorgeschaltet werden. Dieser Datenpuffer ist hauptsächlich bei Mehrfachlesevorgängen hilfreich und nicht nur speziell für Big Data erforderlich. Entfällt die Transformation vor dem Laden der Daten, werden diese später dynamisch aufbereitet, wodurch die Analyseverfahren flexibler werden. Analyse und Visualisierung der Ergebnisse können unmittelbar innerhalb des konsolidierten Big Data-Speichers stattfinden. Die transformierten Daten können zur Analyse und Visualisierung um die Essenz der riesigen Big Data-Volumen zu destillieren auch in relationale Datenbanken oder Data Warehouses exportiert werden. Einige IMDBs wie SAP HANA beziehen OLTP-Produktionsdaten und störungsfreie OLTP-Abfragen in dieselbe Datenbankinstanz ein und ermöglichen so eine Analyse von Produktionsdaten in Echtzeit. Typischerweise muss eine CEP-Engine Hundertausende oder gar Millionen von Ereignissen pro Sekunde bewältigen. Ein weiterer wichtiger Faktor ist die Latenz, d. h. in diesem Fall die Zeit, die zwischen Ereigniseingabe- und Ereignisausgabe verstreicht. Typische Latenzwerte liegen im Mikro- bzw. Millisekundenbereich. Aus diesem Grund wird als Sammelbehälter für die Streaming-Daten oft ein über mehrere Server verteilter In-Memory-Cache genutzt. Hierdurch können zeitintensive I/O-Vorgänge eingespart werden. Um Datenverluste nach Serverausfällen zu vermeiden, werden die Daten auf mehrere Serverknoten repliziert. Wenn die aktuelle Größe des verteilten In-Memory-Caches nicht genügt, reicht es aus, einen weiteren Server hinzuzufügen. Lösungsarchitektur für Big Data Bisher hat sich dieses White Paper mit verschiedenen Teilaspekten beschäftigt. Jetzt sind Sie in der Lage, die Lösungsarchitektur für Big Data in ihrer Gesamtheit zu betrachten. Beginnen wir mit einer kurzen Zusammenfassung der in der Abbildung unten gezeigten Abläufe. Wird zwischen Analyseanwendung und den festplattenbasierten Datenbanken bzw. Data Warehouses ein IMDG geschaltet, beschleunigt dies die Ad-hoc-Analyse und ermöglicht Abfragen in Echtzeit. Während Aufbereitung und Analyse der Daten im konsolidierten Big Data-Speicher auf Grundlage des Map-Reduce-Algorithmus per Batchverarbeitung ausgeführt wird, müssen Click-Streams, Sensordaten oder andere mit hoher Frequenz generierte Datenströme erfasst und analysiert werden, damit Maßnahmen in Echtzeit eingeleitet werden können. Diese Aufgabe übernimmt CEP (Complex Event Processing). Da CEP ein äußerst zeitkritisches Verfahren ist, wird der Hauptspeicher als Datenspeicher genutzt. Die CEP-Ergebnisse werden in der Abbildung als Reporting oder Benachrichtigung dargestellt. Je nach Anwendungsfall können die CEP-Ergebnisse an den konsolidierten Big Data-Speicher weitergeleitet werden. Ähnlich werden Daten aus dem Big Data-Speicher manchmal auch für CEP genutzt. Seite 11 von 14

12 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 Zeitund 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 technischen Know-how mangelt. Dies führt dazu, dass viele Fragen, beispielsweise welche Daten, welche Tools, wie diese Tools einzusetzen sind, welche Fragen überhaupt gestellt werden müssen, welche Infrastruktur benötigt wird oder welche Schritte zuerst zu unternehmen sind, nicht hinreichend beantwortet werden. 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. 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. Bei all dem sollten die erforderlichen Veränderungen innerhalb der Unternehmenskultur nicht unerwähnt bleiben. Insbesondere Daten- und 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. Seite 12 von 14

13 Analytics as a Service Nicht jedes Unternehmen ist bereit oder in der Lage, sich eine Infrastruktur für paralleles Computing und Geschäftsdatenanalyse zu leisten. Hierfür kann es vielfältige Gründe geben, beispielsweise ein beschränktes Budget, ein Mangel an IT-Mitarbeitern bzw. technischer Expertise oder die nicht vorhandene Zeit, um sich mit neuen Aufgabenstellungen zu beschäftigen. Glücklicherweise gibt es auch für diese Unternehmen die Möglichkeit, die Vorteile von Big Data zu nutzen, und zwar mit Analytics as a Service on demand aus der Cloud. Unternehmen nutzen hierzu die Infrastruktur eines Clouddienstanbieters und konzentrieren sich stattdessen auf Middleware und Analysetools (IaaS, Infrastructure as a Service) oder nutzen zusätzlich auch dessen Middleware (PaaS, Platform as a Service). Bei SaaS-Angeboten (Software as a Service) nutzen Unternehmen auch die Analysetools des Cloudanbieters. Hier reicht zur Nutzung des Dienstangebots ein Webbrowser aus. Abgerechnet wird in diesem Fall nach dem nutzungsbasierten Modell. Es sollte erwähnt werden, dass sich Analytics as a Service nur dann lohnt, wenn die Daten im Rahmen eines Storage as a Service-Angebots vom selben Cloudanbieter gehostet werden. 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. Die Unternehmenssoftware, die zur Generierung der Daten eingesetzt wird, sollte ebenfalls auf der Serverinfrastruktur desselben Cloudanbieters ausgeführt werden. Analytics as a Service bietet erhebliches Einsparungspotenzial. 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, beispielsweise bei Quartals- oder Jahresabschlüssen. Mit anderen Worten, das Cloud-Computing ebnet trotz schmaler werdender Budgets den Weg zu Big Data. Welchen Beitrag kann Fujitsu leisten Big Data eröffnet Unternehmen nicht nur ungeahnte Möglichkeiten, sondern stellt sie auch vor Herausforderungen, die nicht unterschätzt werden sollten. Wie sollte das Infrastrukturkonzept aussehen? Welche Server- und Speichersysteme sind geeignet, und wie müssen sie konfiguriert werden? Welche Middleware und Anwendungen werden zum Erreichen der unternehmerischen Ziele benötigt? Was ist zur Inbetriebnahme der Lösung erforderlich? Wie gestaltet sich das Lebenszyklusmanagement der einzelnen Infrastrukturkomponenten? Wie sieht die optimale Vorgehensweise für den Betrieb der Infrastruktur aus in Eigenregie oder per Outsourcing? Was ist insgesamt die beste Sourcing-Option? Bei all diesen Fragen kommt Fujitsu ins Spiel. Fujitsu kümmert sich um sämtliche Aspekte von Big Data und bietet Ihnen in allen Situationen das optimale Lösungskonzept. Das für Ihre geschäftlichen Anforderungen am besten geeignete Infrastrukturkonzept wird im Rahmen eines Assessment ermittelt. Fujitsu entwirft und implementiert die zukünftige Infrastruktur und beschleunigt gleichzeitig die Bereitstellung mithilfe automatisierter Prozesse, die auf unserer reichhaltigen und branchenübergreifenden Projekterfahrung basieren. Dank der Fujitsu PRIMERGY-Server und den Fujitsu ETERNUS DX- Onlinespeichersystemen, die in punkto Leistungsfähigkeit, Skalierbarkeit, Verfügbarkeit und Verwaltbarkeit branchenweit Standards setzen, verfügt Fujitsu über alle Kernkomponenten, die für eine verlässliche Big Data-Implementierung erforderlich sind. Und falls ein Backup erforderlich ist oder Archivierungsbedarf besteht, bietet Fujitsu mit der virtuellen Bandbibliothek Fujitsu ETERNUS CS eine großartige Wahl. Da die Produkte von Fujitsu auf Standards basieren, vermeiden Sie die Abhängigkeit von einem einzelnen Anbieter. Ob Sie nun einen Servercluster mit Hadoop Open Source-Software benötigen, und egal, wie groß dieser auch sein muss, ob Sie In-Memory-Technologien für Echtzeit-Analyseverfahren benötigen oder festplattenbasierte 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 aufzubauen. Selbstverständlich bietet Fujitsu Wartungsservices und durchgängigen Support für die Infrastruktur als Ganzes an, auch konsistent über Ländergrenzen hinweg und, falls erforderlich, global. Wenn Sie noch einen Schritt weiter gehen und den Betrieb Ihrer Big Data-Infrastruktur in unsere Hände legen möchten, bietet Fujitsu Ihnen entsprechende Managed Infrastructure 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 Trusted Fujitsu Global Cloud Platform beziehen. Mit anderen Worten: Fujitsu ist Ihre zentrale Anlaufstelle für Big Data-Infrastrukturen, die Ihnen Komplettlösungen aus einer Hand anbietet. Auf diese Weise reduzieren Sie Komplexität, Zeit und Risiko. Seite 13 von 14

14 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 einer kontinuierlichen Datengenerierung 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. Eigenschaften von Big Data Volumen (Terrabytes bis Petabytes) Vielfalt (Datentypen) Vielseitigkeit (Datenquellen und Interpretationsmöglichkeiten) Geschwindigkeit (Datengenerierung und -analyse) Wirtschaftlichkeit (Technologien) Big Data bietet enormes Wertschöpfungspotenzial. Wenn Sie sich statt auf oftmals falsche Intuitionen auf Echtzeitdaten verlassen, werden Sie in der Lage sein, in Zukunft intelligentere Entscheidungen zu treffen. Wenn Sie sich Ihre Wettbewerbsfähigkeit erhalten wollen, führt um Big Data-Analyseverfahren kein Weg herum. 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 der Big Data schwimmen zu lernen. Abhängig von den geschäftlichen Anforderungen, der im Unternehmen bereits vorhandenen Infrastruktur und weiteren Aspekten ist eine Vielzahl unterschiedlicher Lösungsansätze und sogar eine Kombination aus diesen vorstellbar. Und es wird immer einen Migrationspfad geben. Die vorhandenen Datenbestände sowie die bereits existierende Hardware- und Datenbankinfrastruktur in einem Unternehmen lassen sich in eine neue Big Data-Lösung integrieren. Fujitsu unterstützt sämtliche Konzepte und setzt den geeigneten Technologiemix ein, um optimale Lösungen für den Kunden zu finden. Diese Lösungen setzen sich zusammen aus branchenführender Open Source-Middleware, Fujitsu-spezifischen Erweiterungen, die unseren Kunden Mehrwert bieten, sowie Infrastrukturprodukten und End-to-End-Services von Fujitsu. Darüber hinaus können sich unsere Kunden ihr bevorzugtes Sourcingmodell aussuchen: Kundenspezifische Lösungen, die beim Kunden entweder in Eigenregie oder von Fujitsu betrieben und verwaltet werden, oder Bereitstellung der Lösung aus der Cloud. Aufgrund unserer Erfahrung und Expertise sowie unserer Fähigkeit, alles aus einer Hand zu liefern, ist Fujitsu der ideale Partner für Big Data-Lösungen, die Ihnen große Unternehmenserfolge ermöglichen. Kontakt FUJITSU Technology Solutions GmbH Mies-van-der-Rohe-Straße 8, München, Deutschland Tel.: Fax: Website: Seite 14 von 14 ƒ Copyright 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.