zurück zum Artikel

Big Data: das Ende vom Hype und der Anfang vom Business

Architektur/Methoden
Big Data: das Ende vom Hype und der Anfang vom Business

Nachdem die Gartner-Analysten den Hype-Zyklus rund um das Thema Big Data für beendet erklärt haben [1], stellt sich nun die Frage, warum Big Data in Deutschland weiterhin ein Akzeptanzproblem hat: Ist das Thema etwa doch nicht erwachsen genug oder wird einfach die Relevanz nicht gesehen?

Big Data ist noch nicht in vielen deutschen Unternehmen ein Thema. Liegt das an hierzulande fehlenden disruptiven Geschäftsmodellen wie bei Uber? Mangelt es an neuen, datengetriebenen Ideen [2], die sich Big Data realisieren lassen? Tatsächlich sind diese Fragen falsch gestellt – die wirkliche ist, welches Risiko ein Unternehmen eingeht, das Big Data nicht einsetzt. Nämlich das Risiko, dass seine Mitbewerber auf genau diese Unterstützung für ihre Geschäftsmodelle setzen. Dabei ist Big Data nur der "Enabler", der erweiterte Geschäftsmodelle praktikabel macht. Denn das Versprechen von Big-Data-Techniken wie Apache Hadoop ist dem Kern nach nicht so sehr das "Big", sondern vielmehr die Skalierbarkeit. Ein solches System kann mit den Anforderungen mitwachsen, ohne dass die grundlegende IT-Architektur zu ändern ist.

Neues Berufsbild Data Scientist:

Die Skalierbarkeit ermöglicht neue Ansätze in der Auswertung von Daten: ETL- (Extract, Transform, Load) werden durch ELT-Prozesse (Extract, Load, Transform), das strukturierte Data Warehouse durch einen "Data Lake" ersetzt, sodass Datenanalysen auf einer viel größeren Datenbasis erfolgen können. Neben der Berechnung von Kennzahlen/KPIs (Key Performance Indicators) auf dem Datenbestand wird auch die Gewinnung neuen Wissens zunehmend wichtiger. Die Anwendung von Methoden aus dem Bereich Statistik oder Machine Learning auf diesen Daten wird heute unter dem Begriff "Data Science" zusammengefasst.

Im Zuge der zunehmenden digitalen Transformation werden Big-Data-Techniken weiter an Bedeutung gewinnen und nicht selten alle Bereiche eines Unternehmens, von der Entwicklung über Marketing und Vertrieb bis hin zur Produktion, betreffen. Das kann helfen, Management-Entscheidungen datengetrieben zu treffen und die Produktivität signifikant zu erhöhen [5].

Technische Umsetzung

Wie lässt sich ein derartiges Szenario nun technisch umsetzen? Die Einstiegshürde ist denkbar niedrig – ein Hadoop-Cluster lässt sich heute auf Standard-Hardware oder auch in der Cloud in wenigen Stunden aufsetzen und für den Big-Data-Einstieg nutzen.

Hersteller wie Cloudera oder Hortonworks funktionieren analog zu dem, was Linux-Distributoren im Betriebssystemumfeld machen: Sie nehmen die Einzelprojekte des Hadoop-Ökosystems (z. B. Hive, Pig, Spark und Sqoop) und bauen daraus ihre Distributionen zusammen. Ein wesentlicher Bestandteil sind dabei die Cluster-Verwaltungstools wie Cloudera Manager oder Apache Ambari: Sie stellen die Installation, die Konfiguration und das Monitoring der Komponenten zur Verfügung. Und sie kommen in der Regel da zum Einsatz, wo ein Hadoop-Cluster auf eigener Hardware ausgerollt werden soll – typischerweise bei klassischen On-Premise-Infrastrukturen. Dabei sollten Firmen beachten, dass sie auch über entsprechend leistungsfähige Hardware verfügen, um In-Memory-Techniken wie Apache Spark nutzen zu können. Die Hardware stellt dabei einen nicht unerheblichen Kostenfaktor dar.

Ein Hadoop-Cluster lässt sich aber auch in der Cloud umsetzen: Hier übernehmen zum Beispiel Cloudera Director beziehungsweise Hortonworks Cloudbreak die Provisionierung und Installation des kompletten Clusters. Mit diesen Tools lässt sich ein Hadoop-Cluster unter Amazon Web Services (AWS), auf der Google Cloud Platform oder unter Microsofts Azure mit einem Klick einrichten. Ein Cluster in der Cloud eignet sich vor allem gut, um die Technik kennenzulernen und für den Einsatz im eigenen Unternehmen zu evaluieren. Allerdings sind hier Randbedingungen zu beachten – etwa der Schutz vertraulicher Daten.

Technische Reife

Hadoop ist anfänglich eher als Insellösung für eine spezialisierte Anwendergruppe gestartet worden, mit Lücken in den Bereichen Datensicherheit, Zugangskontrolle und Auditing. Zu Beginn konnten zum Beispiel in der Hadoop-Default-Konfiguration im Prinzip alle Nutzer auf alle Daten zugreifen. In dem Bereich hat Hadoop stark aufgeholt. Heute ist die Technik so ausgereift, dass ein unternehmensweiter Einsatz möglich ist. Das heißt: Die anfänglich nicht berücksichtigten Themen sind mittlerweile umgesetzt, und zwar so, dass sich höchste Anforderungen an Datensicherheit, Zugangskontrolle und Auditing im Betrieb realisieren lassen.

Hier kommen Komponenten wie Apache Knox [6] und Apache Ranger [7] zum Einsatz. Dabei geht es um zwei Ansätze: Der eine beruht darauf, die Authentifizierung im Hadoop-Cluster grundsätzlich auf den verteilten Authentifizierungsdienst Kerberos umzustellen. Wenn das erfolgt ist, können Zugriffe nur noch mit gültigen Kerberos-Tickets erfolgen. Darauf aufbauend kann sich Apache Ranger in die Hadoop-Komponenten einklinken und feingranulare Zugriffskontrollen zur Verfügung stellen. Der Ansatz lässt sich am ehesten mit Zugriffssteuerungslisten (Access Control List; ACL) zum Beispiel in einem Dateisystem oder mit Zugriffsrechten in einem traditionellen RDBMS vergleichen.

Apache Ranger besteht aus zwei Teilen: dem Access Manager, der eine Web-basierte Oberfläche für die Verwaltung von Policies bereitstellt, und Plug-ins für Hadoop-Komponenten, die diese Policies umsetzen. Über Letztere lässt sich der Zugriff auf Daten oder Funktionen gewähren oder verbieten. Beispielsweise könnte einer Gruppe von Nutzern der Zugriff auf Tabellenspalten in Hive verboten werden, die personenbezogene Daten enthalten.

Der andere Ansatz beruht darauf, Zugriffe auf einen Hadoop-Cluster nur über sogenannte Edge-Knoten zuzulassen. Hier nimmt dann Apache Knox die Rolle eines Proxy ein, der Authentifizierung und Autorisierung übernimmt. Dabei ist Knox architektonisch modular aufgebaut und bietet somit die Möglichkeit, im Laufe der Zeit noch mehr Dienste über den Knox-Server abzusichern. Damit er nicht selbst zum Engpass wird, ist er zustandslos implementiert und lässt sich dadurch etwa durch Vorschalten eines Load Balancer horizontal skalieren. Insgesamt erleichtert Knox damit das Leben für beide Seiten:

Hadoop-Administratoren müssen etwa SSL nur noch auf einem Server konfigurieren, durch die integrierte Anbindung von Identity-Management-Systemen entfällt das Anlegen von Benutzern, und das Verschleiern der Infrastruktur bietet weniger Angriffsfläche. Hadoop-Benutzer hingegen müssen sich nur noch eine URL und einen Log-in merken, um ohne Wissen um die Komplexität des Hadoop-Clusters hinter dem Portal direkt loszulegen.

Wichtige Themen wie Ausfallsicherheit und Redundanz sind ebenfalls in der Hadoop-Architektur adressiert. Sie sieht vor, dass einzelne Komponenten ausfallen können, ohne dass das Auswirkungen auf den Betrieb hat. Daten werden grundsätzlich redundant gespeichert – typischerweise auf mindestens drei Cluster-Knoten. Bei Ausfall eines Knotens werden gegebenenfalls auch neue Kopien der Daten erzeugt. Bei Berechnungen mit Map/Reduce oder Apache Spark sorgen Mechanismen wie ein automatischer Retry oder die spekulative Ausführung dafür, dass diese auch bei Ausfall einzelner Knoten weiter laufen. Auch Standarddienste wie Apache Flume, ein verteilt arbeitendes System zum Sammeln, Aggregieren und Transportieren großer Datenmengen, bieten immer Möglichkeiten, sie redundant zu konfigurieren. Die drei folgenden Business Cases zeigen nun Hadoop in der Praxis.

Drei Business Cases

Business Case: Analyse-Backend für die Mobilfunkanalyse

Ein internationaler IT-Dienstleister ermittelt weltweit für Betreiber von Mobilfunknetzen deren Netzqualität. Mit eigenentwickelter Hardware, Software und Messsystemen erhebt das Unternehmen pro Tag zwischen 50 und 100 Gigabyte Daten, die analysiert und aus denen Key-Performance-Indikatoren als Basis für die Netzoptimierungen abgeleitet werden. Für die Analyse führt der Dienstleister zeitbasierte Daten von verschiedenen Sensoren zusammen und spaltet sie in Sequenzen auf. Auf ihnen arbeiten dann Algorithmen, die die KPIs berechnen. Beispiele hierfür sind die Zeit zum Rufaufbau bei einer Sprachverbindung oder der Durchsatz einer Datenverbindung. Die KPIs werden mit Metadaten, etwa zur GPS-Position oder zu Radiomessdaten wie Empfangsstärke, angereichert und in Tabellenform abgelegt.

Die Analyseanforderungen wandeln sich jedoch ständig und schnell: Standen früher beispielsweise Analysen zu Sprachdiensten und Bandbreiten im Vordergrund, sind es heute Dienste wie Videostreaming oder soziale Netze. Das erfordert ein offenes System, das speziell auf verteilte Rechenprozesse und große Datenmengen ausgerichtet ist, um eine hohe Flexibilität und Skalierbarkeit zu erreichen.

Zur Umsetzung wurde ein Hadoop-Cluster in AWS gestartet, der die Rohdaten aus S3 einliest, die Algorithmen (realisiert mit MapReduce und Apache Spark) darauf anwendet und die berechneten KPIs dann wieder im S3 speichert. Hier ging es im Wesentlichen um Kostenkontrolle: Statt selbst die Hardware zu kaufen und zu betreiben, wird der Cluster in AWS provisioniert und die Berechnung gestartet. Nach dem Abschluss der Kalkulation wird der Cluster wieder gestoppt.

Dass das jetzt gerade in der Amazon-Cloud passiert, hatte im Wesentlichen den Hintergrund, dass sie bekannt und der Mechanismus zum Hochladen der Rohdaten in S3 schon etabliert war. Als Speicherformat wird Apache Parquet verwendet, da es besonders für die Ablage spaltenorientierter Daten geeignet ist. Es benutzt sehr große Blöcke (1 GByte), in denen es die Daten spaltenweise ablegt. Dadurch lässt sich beim Auslesen schnell auf einzelne Spalten zugreifen.

Nach der Berechnung wird der Cluster wieder gestoppt – so sind nur die effektiv genutzten Ressourcen zu bezahlen.

Die Visualisierung der KPIs erfolgt dann mit der Analysesoftware Tableau, die über die SQL-Abfrage-Engine Impala auf die berechneten KPIs zugreift. Hadoop erleichtert dem Dienstleister, weltweit neue Dienste oder Techniken, zum Beispiel VoLTE (Voice over LTE), schneller und einfacher und ohne hohe zusätzliche Lizenzinvestitionen in die Analysen zu integrieren. Denn mit der offenen Plattform lassen sich Rechenprozesse mit unterschiedlichen Softwaresystemen beliebig auf Serverkapazitäten weltweit verteilen und skalieren.

Für den Einsatz von Hadoop sprach die Offenheit. Das Vorgängersystem nutzte ein kommerzielles RDBMS, sodass man hier komplett vom Hersteller abhängig war, insbesondere in Bezug auf Lizenzkosten und -bedingungen. Hier konnte Hadoop dann dadurch punkten, dass es ein (fast) komplett quelloffenes System ist. Die Gefahr, von einem Hersteller abhängig zu werden, wurde damit als viel geringer wahrgenommen.

Architektur des Systems aus dem ersten Business Case
Architektur des Systems aus dem ersten Business Case

Business Case: Predictive Maintenance

Ein Aufzughersteller rüstet seine Anlagen mit Sensoren aus, die in Echtzeit ihre Daten an einen Cloud-Service senden. Dieses Projekt wurde auf Basis von Azure implementiert. Auch hier sprach wieder als wesentlicher Vorteil für den Cloud-Ansatz, dass der Cloud-Provider die Infrastruktur zur Verfügung stellt.

Die Messdaten werden mit Protokollen der Service-Techniker abgeglichen, um mit Machine-Learning-Techniken Muster in Störungen und Ausfällen zu finden. Bei geplanten Wartungen errechnet das System, welche Teile präventiv auszutauschen sind, um Störungen und ungeplante Ausfallzeiten zu vermeiden. Der Mehrwert für die Kunden ist neben einer besseren Verfügbarkeit der Aufzüge eine Reduktion der Wartungsausgaben.

Die Technik zur "Data Ingestion", also zur Aufnahme der Daten in das System, entsprechen der des ersten Beispiels. Die "Prediction"-Seite wird dann über Machine-Learning-Verfahren umgesetzt – dazu gehören die Aufbereitung der Daten (per Apache Pig) und die Anwendung von Machine Learning-Algorithmen von Apache Mahout.

Business Case: DWH-Offloading

Ein Anbieter einer Gesundheits- und Fitness-App analysiert Fitness- und Bewegungsdaten von Anwendern auf dem Smartphone oder der Smartwatch. Er steht vor der Herausforderung, dass seine klassische, auf RDBMS basierende Data-Warehouse-Anwendung nicht mit dem Wachstum seiner Daten mithalten kann. Statt sie auszubauen, hat er sich entschieden, Teile der Funktionen des DWH in einem Hadoop-Cluster zu realisieren. Dieser speichert die Rohdaten und bereitet sie so auf, dass sie sich direkt im DWH weiterverarbeiten lassen. So kann das bestehende DWH-System weiter genutzt werden – eine teure Erweiterung oder Neuinstallation wurde vermieden. Daneben lassen sich neue Funktionen einfach auf dem Hadoop-Cluster implementieren.

Die Rohdaten bestehen aus einzelnen Events, die die App generiert. Sie kommen über zwei Wege in das System: zum einem aus einem bestehenden Backend-System, dass Events über RabbitMQ zur Verfügung stellt, zum anderen von einem anderen Dienstleister über eine HTTP-Schnittstelle.

Im Hadoop-Cluster nimmt Flume die Events aus RabbitMQ beziehungsweise per HTTP-Endpunkt entgegen und schreibt sie im Original-Format (JSON) in HDFS. Die Weiterverarbeitung erfolgt dann per Hive, das SQL-Zugriffe auf JSON ermöglicht. Per Hive-ODBC-Zugriff kann das DWH dann auf die Daten zugreifen.

Neue Funktionen kommen zum einen mit neuen Apps oder Erweiterungen älterer Applikationen, hier lässt sich das System einfach an neue oder erweiterte Event-Typen anpassen. Zudem erlaubt es den Data Scientists auch, direkt mit den Rohdaten zu arbeiten, was im alten DWH nicht ging. Damit sind neue Analysen möglich, weil die komplette Datenbasis verfügbar ist. Das DWH hat immer nur den aktuellen Datenstand abgebildet – mit dem Hadoop-System ist die komplette Historie aller Events verfügbar.

Fazit

Als "Enabler" neuer Geschäftsmodelle oder der schnellen Anpassung des Geschäfts an neue Herausforderungen bietet Big Data mit Hadoop ernstzunehmende Vorteile: Dank seiner skalierbaren Architektur bildet das Framework die Grundlage dafür, alle aktuellen und zukünftigen Unternehmensdaten mit Data-Science-Methoden auswerten und so neue Einsichten und Mehrwert gewinnen zu können. Wie die Anwendungsbeispiele zeigen, lassen sich damit unterschiedliche Business Cases auf einfache Weise realisieren. (ane [8])

Thorsten Greiner
ist Teamleiter Software Development bei der ConSol* Software GmbH. Mit seinem Team kümmert er sich schwerpunktmäßig um Projekte um Big Data-Projekte im Umfeld Apache Hadoop. Darüber hinaus ist er Mit-Organisator des "Düsseldorf Data Science Meetup".


URL dieses Artikels:
http://www.heise.de/-3127707

Links in diesem Artikel:
[1] http://blogs.gartner.com/andrew_white/2015/08/20/the-end-of-big-data-its-all-over-now/
[2] http://www.cambridgeservicealliance.org/uploads/downloadfiles/2014_March_Data%20Driven%20Business%20Models.pdf
[3] https://www.heise.de/developer/artikel/Data-Scientist-ein-neues-Berufsbild-fuer-die-Big-Data-Welt-2739893.html
[4] https://www.heise.de/developer/artikel/Im-Gespraech-Jose-Quesada-ueber-Skills-der-Data-Scientists-2838397.html
[5] http://www.a51.nl/storage/pdf/SSRN_id1819486.pdf
[6] http://hortonworks.com/hadoop/knox-gateway/
[7] http://hortonworks.com/hadoop/ranger/
[8] mailto:ane@heise.de