Markus Ehrenmüller-Jensen 10. März 2015

Big Data - Microsoft Analytics Platform System (APS)

Big Data: Wachstumsraten überschlagen sich. © depositphotos.com / agsandrew

Ich kann mich noch gut erinnern, welche Sensation es war, von den „normalen“ 5 ½“-Disketten mit einer Kapazität von 360KB auf jene mit HD umzusteigen. Diese boten mit 1,2MB ein Vielfaches an Platz. Mein erster PC mit 80286er-Prozessor hatte eine 40MB-Platte, welche ich später mit einer 80MB-Platte ergänzte (die fast meinen ganzen monatlichen Verdienst aus meiner Ferienarbeit kostete). Speicherplatz war zu dieser Zeit teuer. Auch Unternehmen strengten sich an, einerseits nicht allzu viele Datensätze zu archivieren, andererseits Datensätze selbst kompakt zu halten (Sie erinnern sich vielleicht noch an das „Jahr-2000-Problem“, ausgelöst durch eine Speicherung von Jahreszahlen ohne die Tausender- und Hunderterstelle um eben kostbaren Speicherplatz einzusparen).

Aus heutiger Sicht sind diese Größenangaben niedlich – aber es wird auch nur eine Frage der Zeit sein, wenn wir 2TB-Harddisks für den Privatgebrauch als lächerlich klein ansehen werden. Denn: Die Prognosen der Wachstumsraten des jährlich angefallenen Datenvolumens überschlagen sich und werden laufend nach oben revidiert – und treffen Unternehmen genauso wie Privatpersonen. Rafal Lukawiecki hat also Recht, wenn er, wie bei der Microsoft Analytics Roadshow 2013, behauptet: "Was heute Big Data ist, wird morgen Little Data sein." Wagen wir also zuerst einen Blick auf das, was heute Big Data ist – um am Ende des Artikels einen Ausblick auf morgen zu versuchen.

Heute

Heutzutage kämpfen wir weniger damit, die erforderlichen Daten im Unternehmen aufzuzeichnen oder Daten von extern zu bekommen. Speicherplatz ist relativ günstig. Wir sind auch praktisch immer online und haben über Smartphone, Tablet und Phablet jederzeit Zugriff ins Inter-, Intra- und Extranet. Die Herausforderung besteht jedoch darin, die vorhandenen Daten zu bewältigen und die für uns relevanten Informationen herauszufiltern. Man denke beispielsweise an:

Bilder und Videos
Bestellungen über den Webshop
Demografische Statistiken
Börsendaten
Log Files
Kommentare in sozialen Medien
Sensorik-Daten und das „Internet der Dinge“

Diese Datenansammlungen werden häufig angelegt, „um Kunden und Märkte besser zu verstehen, ein effektiveres Risikomanagement zu betreiben oder generell bessere Unternehmensentscheidungen zu treffen.“ [1]. Die Auswertung selbst ist aber nicht immer leicht, wie jeder weiß, der mal den Windows Event-Viewer durchgeblättert hat, oder versucht hat, die Timeline, Freunde und Likes des eigenen Facebook-Accounts über Excel auszuwerten. Manchmal ist es aber auch schon schwierig genug, das eine süße Kinderfoto, über das wir so herzlich gelacht haben, aus der Flut an Urlaubsbildern zu finden.

Mit dem Ansteigen der Datenflut sinkt gleichzeitig die Halbwertzeit des Informationsgehalts der angesammelten Daten. In unserer schnelllebigen Zeit, sind die Umsatzzahlen vom letzten Jahr, vom letzten Monat oder auch von der letzten Woche möglicherweise schon veraltet und uninteressant. Das bedeutet, dass es umso wichtiger wird, die entscheidungsrelevanten Informationen sehr zeitnah herauszufiltern.

Die klassischen Ansätze eines relationalen Datawarehouse stoßen hier schnell an ihre Grenzen. Ein Beladungslauf über Nacht ist nicht mehr möglich und Voraggregationen würden dem Echtzeit-Charakter widersprechen. Wo früher ein Batch-Job über Nacht gereicht hat sind die Benutzer nun enttäuscht, wenn das Query nicht in wenigen Minuten oder gar Sekunden die benötigten Informationen ausspuckt. Denn nur rasche Antwortzeiten ermöglichen eine intuitiv gesteuerte Vorgangsweise beim Analysieren. Die Flexibilität, aber auch die hohe Geschwindigkeit der Abfragen setzt neue Maßstäbe bei den Erwartungen der End-Benutzer.

Das Schöne ist: Mit den heute zur Verfügung stehenden Methoden, die weiter unten beschrieben sind, können wir diese Daten speichern, ohne uns jetzt schon Gedanken machen zu müssen, wie wir diese später auswerten. Das würde in einem herkömmlichen Datawarehouse nicht gehen, denn da müssen die Daten in den Tabellen und in den Spalten so abgespeichert werden, dass sie später über JOIN-Operationen verknüpft werden können. Das führt in der Regel dazu, dass das Datawarehouse an die neuen Daten (und die später beabsichtigten Abfragen) angepasst werden muss. Sollte beim DWH-Design etwas übersehen worden sein, dann wird später das Query keine zufriedenstellenden Ergebnisse liefern.

Die drei V

„Big Data“ ist ein Buzz-Word (und hat möglicherweise auch bei Ihnen dazu geführt, diesen Artikel bis hierher zu lesen) und Buzz-Words haben es so an sich, dass sie nicht immer in einem einheitlichen Verständnis verwendet werden. Allerdings kristallisiert sich zunehmend als allgemeingültige Definition heraus, dass Daten dann als „Big Data“ gelten, wenn sie zumindest eine der folgenden Eigenschaften erfüllen:

Große Datenmenge
Schnelles Wachstum der Datenmenge
Unstrukturiert oder zumindest komplex strukturiert

Manche Diskussionen stürzen sich auf die erste Eigenschaft und blenden die zwei anderen aus – die trifft dann aber nicht des Pudel’s Kern.

Drei V bei Big Data: volume, velocity, variety.

Im Englischen sprechen wir von drei V: volume, velocity und variety [2] bzw. in deutsch von Volumen, Geschwindigkeit und Komplexität. Diese drei Eigenschaften sind aber nicht neu, denn Daten, die diese Eigenschaften erfüllen, hat es immer schon gegeben. Das eigentliche Problem entsteht, wenn das Volumen, die Wachstumsgeschwindigkeit oder die Komplexität die zur Verfügung stehenden Techniken überfordert. Eine solche Überforderung war halt mit einer 360KB-Diskette oder einem 80286er-Prozessor schneller erreicht als mit einem Petabyte SAN oder einer aktuellen Maschine mit 256 Cores. Aber auch letzteres System wird früher oder später genauso an seine Grenzen stoßen.

Die weiter oben zitierte BARC Big Data Survey definiert Big Data daher nicht anhand der Daten, sondern als Methoden und Technologien für die hochskalierbare Erfassung, Speicherung und Analyse polystrukturierter Daten. Und genau das trifft es auf den Punkt: Denn neu sind die Methoden und Techniken, die uns nun zur Verfügung stehen, nicht die Eigenschaften der Daten an sich.

Die Hochskalierbarkeit garantiert, auch große bzw. schnell wachsende Datenmengen erfolgreich zu verarbeiten. Solange es sich um strukturierte Daten handelt, können diese in einem relationalen Datenbanksystem gut bewältigt werden. Die Herausforderung besteht aber darin, die Datensätze aus einer relationalen Datenbank einerseits mit „polystrukturierten Daten“, die stark unstrukturiert bis gar nicht strukturiert sind, andererseits „unter einen Hut“ zu bringen.

Diese Problemstellungen sind durch die unterschiedlichsten Unternehmungen bereits gelöst worden: Microsoft Bing analysiert 100 Petabytes um Suchanfragen zu beantworten. Twitter und Facebook stellen Statusmeldungen von Millionen Anwendern in Echtzeit an die Follower und Freunde zur Verfügung. Online-Wettanbieter bieten Live-Wetten während eines Fußballspiels an.

In der relationalen Welt können wir durch Indizes und Aggregationen in einem gewissen Ausmaß eine vernünftige Abfrage-Performance garantieren. Doch der Overhead zum Verwalten und Aktualisieren dieser zusätzlichen Datenbankobjekte hat seinen Preis und wird ab einem bestimmten Punkt zu hoch werden, wenn das Wartungs-Fenster für die Beladung des Datawarehouse, die Aktualisierung der Indizes und die Neuberechnung des Datamarts nicht mehr ausreicht.

Scale-up vs. Scale-out

Meinen ersten Rechner mit einer zusätzlichen 80MB-Festplatte aufzurüsten oder ihn später durch einen Rechner mit einem besseren Prozessor auszutauschen war ein typisches Scale-up (vertikales skalieren). Dies war und ist bei vielen Servern immer noch der Fall: Reichen die Kapazitäten eines Servers nicht mehr, so wird er durch ein besseres Modell ersetzt: mit schnelleren Prozessoren, mehr Speicher, etc..

Der aktuelle Trend beim Scale-up von Datenbanken geht in Richtung In-Memory-Technologien. Hier ist wichtig, dass der Server vor allem viel Speicher hat – die Geschwindigkeit der Festplatten spielt nur eine untergeordnete Rolle, weil nach einer Initialbeladung alles im Arbeitsspeicher gehalten wird. Im Falle eines DWH gewährleistet eine intelligente (spaltenweise) Kompression, dass sich große Tabellen ganz oder zumindest temporär im Speicher cachen lassen. Aber auch für OLTP-Anwendungen ist es möglich, die Tabellen und Prozeduren konstant im Speicher vorzuhalten, ohne gegen das Prinzip ACID zu widersprechen. Die dabei (fast) vernachlässigbaren Zugriffszeiten ermöglichen, dass die Datenbank-Server-Software mit den Daten anders umgeht und auch der Overhead der Datenbank minimiert werden kann (frei von Sperren und Latches). Daraus resultieren Abfragezeiten auf bestehender Hardware, die jeden Anwender entweder zu Staunen, Unglauben oder beidem veranlassen.

Der Vorteil an diesem reinen server-lastigen Ansatz ist, dass die Anwender-Software nicht angepasst werden muss. Das Problem an diesem Ansatz ist, dass nicht alle Komponenten immer beliebig verbessert werden können. Wenn man bereits die beste Hardware im Einsatz hat, die aktuell verfügbar ist, dann kann man nicht mehr weiter aufrüsten.

In diese Kerbe schlägt Scale-out (horizontales skalieren). Es wird nicht bessere, sondern einfach mehr Hardware angeschafft und diese parallel betrieben. Und diese Hardware ist in vielen Fällen einfach und günstig (sog. commodity hardware). Die Gesamtlösung muss aber trotzdem nicht billiger als Scale-up sein, weil die Software angepasst werden muss und die Verteilung der Anfragen auf die einzelnen Hardwareknoten auch verwaltet werden muss und daher zusätzliche Ressourcen bindet.

Hadoop

Petabytes an ustrukturierten Daten kostengünstig zu speichern und zu analyiseren ist mit Hadoop keine Herausforderung. Dieses Open-Source-Werkzeug ist eines der bekanntesten um mit Big Data umzugehen. Aus diesem Grund hat sich auch Microsoft entschlossen, Konnektoren aus SQL-Server zu schreiben und das Open-Source-Projekt auch offiziell zu unterstützen.

Die Lösung, die Hadoop für Big Data anbietet, heißt „Map/Reduce“. Anfragen werden zuerst über einzelne Cluster parallel verteilt (map), später werden die Ergebnisse aus diesen parallelen Jobs auf die vom Benutzer gewünschten Inhalte zusammengetragen (reduce). So einfach das klingt, so genial wurde es umgesetzt. Allerdings müssen bei einer reinen Hadoop-Lösung die aus der relationalen Welt gewohnten SQL-Statements in Map/Reduce–Anfragen umgeschrieben werden. Die Entwickler und Power-User müssen also eine neue Abfragesprache erlernen und bestehende Anwender-Software und Berichtsabfragen in diese übersetzen.

Appliances (APS)

Microsoft hat sich in den letzten Jahren mit den Hardwareherstellern HP und Dell zusammengeschlossen um ihren Kunden ein kombiniertes Paket aus aufeinander abgestimmter Hardware und Software anzubieten. Im Falle des Parallel-Datawarehouse (PDW) können diese Appliances schrittweise von einem viertel Rack auf 64 Knoten erweitert werden (Scale-out). Software-seitig ist sichergestellt, dass sich dieser spezielle Datenbank-Server nach außen hin von keinem anderen SQL-Server unterscheidet. Jede Anwendung, die mit einem „herkömmlichen“ SQL-Server arbeiten kann, kann das genauso mit dem Parallel-Datawarehouse. Das gilt für Tools der SQL-Server Suite (z. B. Reporting Services, Analysis Services, Excel, …) genauso, wie für individuelle Software.

Das Microsoft Analytics Platform System (APS) kombiniert das PDW mit HDInsight, Microsoft’s 100% kompatibler Hadoop-Distribution, die intern Abfragen als Pig oder HiveQL und nicht als SQL benötigt. PolyBase stellt dabei sicher, dass in HDInsight (auf der eigenen Hardware oder in der Windows Azure) gespeicherte Daten mit den Daten aus dem PDW über SQL abgefragt werden können. Auch hier gilt also: Jede Anwendung, die mit einem „herkömmlichen“ SQL-Server arbeiten kann, kann das genauso mit dem APS tun. Zusätzliche manuelle Prozesse, Fertigkeiten oder Hadoop-Training sind nicht notwendig.

Dasselbe gilt für die In-Memory-Technologien xVelocitoy (spaltenbasierte Speicherung) und In-Memory OLTP-Tabellen. Auch wenn das Innenleben des SQL-Servers völlig anders ist (und tatsächlich eine zweite Database Engine läuft bzw. die Daten in einem völlig anderen Format auf der Disk liegen), so merkt man das höchstens als Administrator an den zusätzlichen Knöpfen, die bedient werden können, nicht aber als Entwickler oder gar als Anwender.

Es müssen daher beim von Microsoft gewählten Ansatz (im Gegensatz zu den Lösungen der Marktbegleiter), zumindest vom Konzept her, keine Entwickler umgeschult oder Software angepasst werden, um die High-End-Performance nutzen zu können. Und es können relationale Tabellen mit den Tabellen des Hadoop-Clusters ohne Entwicklungsaufwand verjoined werden und auch z. B. ein GROUP BY auf die Hadoop-Tabellen angewendet werden. Zum Zeitpunkt der Drucklegung konnte Polybase aber noch keine hundertprozentige Kompatibiliät mit T-SQL garantieren.

Aus allen Wolken

Cloud-Computing wird im deutschsprachigen Raum seit Jahren sehr kontrovers diskutiert – und zwar mehr auf emotionaler Ebene, als auf technischer. Die einen haben das Gefühl, in der Cloud die Hoheit über die Daten zu verlieren (die von Edward Snowden publizierten NSA-Akten haben die Verunsicherheit nicht verringert), die anderen fürchten um ihren Job als Administrator. Ich möchte Sie für die folgenden Zeilen nur darum bitten, kurz ein eventuell aufkommendes „für mich ist die Cloud sowieso nichts“ auszublenden und einfach einen Blick auf die sich bietenden Möglichkeiten zu werfen.

Da sie bei der Verarbeitung von Big Data sehr hilfreich sein können, möchte ich Ihnen folgende Azure-Dienste vorstellen, die zum Zeitpunkt der Drucklegung noch in Preview sind:

Data Factory
Stream Analytics
Machine Learning

Die Azure Data Factory könnte man als eine Art Polybase der Cloud betrachten. Diese Plattform (als Cloud-Service) hilft uns, Daten aus relationalen und nicht-relationalen Datenquellen, ob on- oder off-premise, anzuzapfen, zu kombinieren und transformieren und in eine sogenannte Pipline zu bündeln. Diese Piplines können an zentraler Stelle verwaltet werden.

Kontinuierliche Ströme an Daten können mit Stream Analytics eingefangen, bewertet und gesammelt werden. Was in traditionellen Lösungen über Logs und Batches in near-real-time versucht wird, auszuwerten, wird über diesen Azure Service in Echtzeit überwacht. Beispiele für solche Überwachungen finden wir in unserer Alltagswelt: Lagerbestand (zwecks Nachbestellung) oder Gesundheitsdaten (Überwachung von Vitalwerten). Und Sie werden es schon erraten: die Definition der zu lesenden Informationen, aus welchen Datenquellen diese auch immer tatsächlich stammen, wird in SQL verfasst.

Machine Learning kann auf die oben erwähnten Services oder andere Datenquellen aufbauen um eine Prognose abzuliefern. Wir brauchen dann nicht auf einen starr vorgegebenen Minimallagerstand für die Neubestellung zu warten, sondern können aufgrund des prognostizierten Verbrauchs viel zuverlässiger die Neubestellung veranlassen, damit diese so spät wie möglich, aber dennoch so früh wie nötig passiert.

Self-Service BI

Big Data hat zwar Self-Service BI als heißestes Modewort in der Informationstechnologie-Branche ersetzt, die Bequemlichkeiten, die sich die Benutzer aus Self-Service BI aber erwarten können, dürfen durch Big Data nicht zunichte gemacht werden. Die End-Anwender erwarten, dass sich Big Data mindestens so komfortabel analysieren lässt, wie die bisherigen Datenquellen. Eine besondere Bedeutung kommt hier prädikativen Analysen zu, die versuchen, aus den vorhandenen Daten Trends, Chancen und Gefahren für die Zukunft vorherzusagen.

Da Big Data in den SQL-Server für den Anwender völlig unbemerkt integriert ist, können auch die bisher verwendeten Analyse-Tools verwendet werden. In der Welt von Microsoft gibt es die folgenden Werkzeuge, mit denen Business-Analysen gemacht werden können:

PerformancePoint Services
Reporting Services
Excel (mit und ohne einem PowerPivot-Daten-Modell)
Power View
Power Map

Je nach Zielgruppe bieten diese Werkzeuge besondere Stärken: Während Excel vielen Anwendern sehr vertraut ist und daher schnell auch als Analyse-Werkzeug eingesetzt werden kann, spielt Power View seine besonderen Karten in der intuitiven Erstellung von Berichten aus. Intuitiv ist auch die Analyse von mit PerformancePoint Services erstellten Berichten, durch leichtes Drill-Down und Drill-Through und dem Entscheidungsbaum. Ebenso können aussagekräftige Balanced Scorecards erstellt werden. Wer seine Berichte pixelgenau benötigt oder Berichte abonnieren und bei Abweichungen automatisch verständigt werden möchte, ist mit Reporting Services bestens bedient. Wollen Sie eine flache Landkarte oder eine 3D-Weltansicht mit Daten anreichern, dann ist Power Map das Tool Ihrer Wahl. Zwischen den geographischen Positionen lassen sich fließende Übergänge festlegen und als Film exportieren.

Mit dem in Excel integrierten PowerPivot-Datenmodell ist es zudem möglich, Daten aus den verschiedensten internen und externen Datenquellen miteinander zu kombinieren, ohne ein Datawarehouse mit der IT-Abteilung aufzubauen.

Morgen

Von allen oben vorgestellten Komponenten scheint mir „Machine Learning“ in der Form von „Machine Self-Learning“ kombiniert mit prädiktiven Analysen am spannendsten. Hier kommt mir sofort der Film „Minority Report“ in den Sinn, der in Hollywood-Manier deutlich vor Augen führt, dass Technologien sowohl ihren Nutzen als auch ihre Gefahren beinhalten, zwischen denen oft nur schwer eine Grenze zu ziehen möglich ist.

Machine Self-Learning wie in Minority Report.

Kenneth Cukier nennt in seinem empfehlenswerten Vortrag „Big data is better data“ [3] Beispiele, wie „Machine Learning“ eingesetzt wird: Suchmaschinen, Warenkorbanalysen, Übersetzungen, Stimmerkennung, etc. gehen jetzt schon weit über die Möglichkeiten einfacher Datenbanken/-ansammlungen hinaus. Am beeindruckendsten ist aber sein Beispiel bei dem „Machine Learning“ genutzt wurde, um Brustkrebs-Biopsien zu analysieren. Das System konnte erfolgreich alle zwölf Erkennungsmerkmale einer positiven Erkennung identifizieren. Das überraschendste daran war aber, dass bislang nur neun Erkennungsmerkmale in der Literatur bekannt waren. Die drei anderen hatte der Algorithmus neu erkannt.

Meiner Meinung nach sind wir noch lange nicht beim „Machine Self-Learning“ angekommen, das uns nicht nur das Handling von Big Data abnimmt, sondern gleich auch noch treffsichere Analysen liefert. Wir waren jedoch auch noch nie so knapp davor, das zu erreichen.

Kehrseite dieser Medaille: Big Data hätte nach Kenneth sogar das Potential – analog zur Industriellen Revolution, bei der die Dampfmaschine vielen Arbeitern die Arbeitsgrundlage entzogen hat – die Jobs in der IT zu gefährden.

Fazit

Nicht die als Big Data bekannten Probleme (große Datenmenge, schnelles Datenwachstum und komplexe Datenstrukturen) sind neu, sondern die Technologien, die uns zur Bewältigung dieser Problemstellungen zur Verfügung stehen.

Die Antwort von Microsoft ist eine folgende Architektur:

Datenverwaltung, die alle Datentypen unterstützt (strukturierte, semi-strukturierte und unstrukturierte Daten aus relationalen, nicht-relationalen, analytischen und strömenden Datenquellen) und nach außen hin trotzdem in der aus der rein relationalen Welt gewohnten Art und Weise (SQL) abgefragt werden kann.
Datenanreicherung durch Verknüpfung mit externen Daten und Analysen im Datawarehouse, das auf relationaler, multidimensionaler, tabularer oder polybasierender Technologie aufbaut.
Hybrides Nutzen von on-premise (also Hardware im Haus) und off-premise (also gemietete Ressourcen in der Cloud), um die Vorteile beider Welten zu verknüpfen.
Datenzugriff und -darstellung mittels Benutzerwerkzeugen, die die End-Anwender bereits kennen und im Einsatz haben (Office und SharePoint).

Diese Architektur ermöglicht es sowohl den IT-Pros als auch den Endanwendern, auf „Big Data“ in der gewohnten Weise zuzugreifen, als würde es sich um „normale“ Daten handeln. Mit dem technologischen Fortschritt werden immer ausgereiftere Technologien on-premise (möglicherweise sogar auf jedermanns Mobiltelefon) verfügbar werden, große Datenzentren in der Cloud werden aber zu jedem Zeitpunkt einen Vorsprung bei Hard- und Software haben. Es bleibt also spannend, zu sehen, in welche Richtung das Pendel bei den aktuell verfügbaren hybriden Ansätzen ausschlagen wird.

Ich denke aber jedenfalls, dass Kenneth Cukier mit der Wahl seines Vortragstitel recht hatte: "Big data is better data".