Neue Geschäftsmöglichkeiten mit Big-Data-Systemen und Hadoop
Innovative Organisationen durchbrechen mit Big-Data-Technologien und Hadoop bestehende Geschäftsmodelle und verfolgen damit neue Ideen und Strategien.
Big-Data-Systeme sind für manche Unternehmen inzwischen nicht mehr nur Plattformen für neue Arten von Datenverarbeitungs- und Analyseanwendungen. Sie sind auch eine treibende Kraft für neue Geschäftsstrategien.
Das ist zum Beispiel der Fall bei iPass, einem weltweit agierenden Anbieter für mobile Konnektivität mit Services für den sicheren Wi-Fi-Zugriff auf mobilen Endgeräten. iPass liefert Kunden unbegrenzte Wi-Fi-Konnektivität über Cloud-Dienste als Software as a Service (SaaS).
Das Unternehmen nutzt eine Big-Data-Umgebung, um den strategischen Wandel voranzutreiben. Es will weg vom Pay per use Wi-Fi-Zugang hin zu Tools zur Verwaltung und Optimierung der mobilen Konnektivität für Unternehmensnutzer.
Die Ende 2015 eingeführte Software iPass SmartConnect enthält Algorithmen, die Wi-Fi Access Points identifizieren und nach ihrer Leistung sortieren kann. Mobile Benutzer können damit eine Verbindung zu den schnellsten und am zuverlässigsten verfügbaren Hotspots herstellen. Das ist eine große Veränderung gegenüber dem bislang praktizierten Modell, bei dem iPass den Nutzern nur eine statische Liste von Hotspots zur Verfügung gestellt hat.
Dieses neue Modell wäre ohne die zugrunde liegende Daten-Management-Plattform, die auf der Processing Engine Apache Spark basiert, nicht möglich gewesen, sagt Tomasz Magdanski, Director of Big Data and Analytics bei iPass. „Wir brauchen die Big-Data-Architektur zu 100 Prozent“, erklärt er. „Es gibt keinen Weg, wie wir all diese Daten in Echtzeit knacken und alle Rankings und Messungen ohne die Plattform machen können.“
Der Weg zur Bereitstellung der Architektur verlief allerdings nicht reibungslos. Der konsultierte kalifornische Dienstleister Redwood Shores verwendete zunächst einen lokalen Hadoop- und Spark-Cluster. Laut Magdanski kam es dabei zu Skalierungs- und Systemwartungsproblemen, die den Produktstart von SmartConnect verzögerten.
Um die Dinge wieder auf den richtigen Weg zu bringen, wechselte iPass Mitte 2016 zu Spark-Clustern von Databricks, die in der Cloud von Amazon Web Services (AWS) laufen. Damit konnte Anfang des Jahres mit der Produktion der Komponenten von SmartConnect begonnen werden.
„Die verarbeiteten Daten werden im Amazon Simple Storage Service (S3) gespeichert, mit der Open-Source-Datenbank Cassandra im Frontend.“
Tomasz Magdanski, iPass
Ein Spark-Cluster führt Extract-, Transform- und Load-Aufträge für Daten aus, die von drahtlosen Hotspots auf der ganzen Welt gesammelt werden. Derzeit werden durchschnittlich 25 bis 30 Millionen Datensätze pro Tag verarbeitet. Die verschiedenen SmartConnect-Algorithmen laufen auf ihren eigenen kleinen Clustern – einschließlich der Algorithmen, die Zugriffsgeschwindigkeiten und die Quality of Service (QoS) der Hotspots analysieren.
„Die separaten Cluster sind Teil einer Strategie zur Trennung von Processing Jobs, um Abhängigkeiten oder Konflikte zu vermeiden“, sagt Magdanski. Die verarbeiteten Daten werden im Amazon Simple Storage Service (S3) gespeichert, mit der Open-Source-Datenbank Cassandra im Frontend, um Netzwerk-Administratoren die nötigen Informationen zur Verfügung zu stellen.
SmartConnect hat das Geschäft bei iPass nicht sofort angekurbelt. Tatsächlich verzeichnete das Unternehmen im zweiten Quartal 2017 einen Umsatzrückgang von 18 Prozent im Vergleich zum Vorjahr. Dies war zum Teil auf Verzögerungen bei den erwarteten Implementierungen der neuen Software zurückzuführen. „Aber es stehen größere Aufträge an“, ergänzt Magdanski.
Darüber hinaus entwickelt sein Team Produkte, die von den Big-Data-Systemen gespeist werden und an Mobilfunkbetreiber, Anbieter von Werbeplattformen und Besitzer von Hotels sowie anderen Orte für Access Points als neue Einnahmequelle verkauft werden.
Über das Crawling hinausgehen
Der Security-Anbieter RiskIQ hat sich ebenfalls eine Big-Data-Architektur zunutze gemacht, um seinen geschäftlichen Horizont zu erweitern. Adam Hunt, leitender Data Scientist bei RiskIQ, fing Anfang 2014 bei der Firma in San Francisco an. Er sagt, dass er zu Beginn in erster Linie Echtzeit-Web-Crawling betrieben hat mit dem Ziel, nach Websites zu suchen, bei denen die Gefahr besteht, dass sie angegriffen werden.
Innerhalb eines Jahres baute das Unternehmen dann eine Data-Warehouse- und Analyse-Umgebung auf einem bestehenden Hadoop-Cluster auf – und ermöglichte so die Entwicklung neuer Sicherheitsprodukte, die alle Daten nutzen, die während eines Crawls gesammelt werden.
„Was wir mit unseren Daten jetzt machen können, hat die Sichtweise aller verändert.“
Adam Hunt, RiskIQ
xxx
„Wir sind nun in der Lage, unsere passiven Datensätze viel stärker als bisher zu nutzen“, sagt Hunt. „Was wir mit unseren Daten jetzt machen können, hat die Sichtweise aller verändert.“ Und das, so Hunt weiter, "hat die Richtung unseres Geschäfts verändert."
RiskIQ hatte den Cluster, der auf der Hadoop-Distribution von MapR basiert, 2012 implementiert. Zu Beginn wurde das System nur dazu benutzt, Rohdaten zu speichern, die dann an Kunden zur Auswertung geliefert wurden. Die Daten mussten die Kunden selbst analysieren.
Mittlerweile unterstützt die Hadoop-Plattform eine Reihe von Analyseapplikationen, die Unternehmen helfen, ihre Websites, mobilen Anwendungen und andere mit dem Internet verbundene Ressourcen zu inventarisieren und zu überwachen. Auch externe Sicherheitsbedrohungen werden identifiziert, Angriffe analysiert und es wird darauf reagiert.
Täglich durchsucht RiskIQ bis zu 20 Millionen Webseiten und holt bis zu 25 TB Daten von dem Cluster ab, der in einer Colocation-Einrichtung untergebracht ist. Um Speicherplatz zu sparen, konvertiert das Unternehmen die Rohdaten in Apache Parquet-Dateien, die nur ein Zehntel der Originalgröße haben.
„Trotzdem hält der Cluster etwa 500 TB an Daten im MapR-eigenen Dateisystem und in der HBase-Datenbank vor“, erklärt der Data Scientist. Die darin laufenden Jobs speisen Indizes mit drei TB an Daten in einem separaten Cluster, auf dem der Solr-Suchserver läuft. Zusätzlich werden zwei Petabyte älterer Datensätze in einem S3-Repository in der AWS-Cloud archiviert.
Wie bekommt man die Daten in Big-Data-Systeme?
Der anspruchsvollste Teil bei Big-Data-Anwendungen besteht möglicherweise nicht darin, Analyse-Algorithmen für umfangreiche Datensätze auszuführen. Stattdessen könnte dies die viel nüchterne Aufgabe sein, die riesigen Datenmassen überhaupt in das Big-Data-System zu bekommen.
Bei TMW Systems war dies der Fall. Der Anbieter von Transport-Management-Software zieht eine Mischung aus strukturierten und unstrukturierten Daten in seinen Hadoop-Cluster – darunter „Tonnen von Sensordaten“, sagt Timothy Leonard. „Viele Arten von Datenplattformen können vielleicht mit analytischer Verarbeitung gut umgehen. Aber es gab nichts da draußen, was ich finden konnte, was die Aufnahme von Daten gut über die Bühne bringt.“
Dieses Problem sollte bereits bei der Beschaffung in die Überlegungen einbezogen werden: „Um das Risiko von Performance-Problemen zu reduzieren, sollten Big-Data-Teams bei Bereitstellungsprojekten weit vorausdenken – insbesondere was das Extrahieren, Transformieren und Laden von Jobs für die Aufnahme der Daten betrifft“, erläutert Tomasz Magdanski.
Gene Stevens, Mitbegründer und CTO bei ProtectWise, sieht das genauso. Die wachsenden Datenmengen ohne irgendwelche Fehler in die Big-Data-Architektur des Netzwerk-Security-Anbieters zu bringen, hatte oberste Priorität. „Wir wussten, dass wir das schaffen mussten“, sagt Stevens. „Die möglichst fehlerfreie Aufnahme der Daten durfte uns nicht misslingen.“
Anleitung nicht im Lieferumfang enthalten
Der Gartner-Analyst Merv Adrian weist darauf hin, dass die Implementierung von Big-Data-Systemen aufgrund ihrer Komplexität oft zum Stillstand kommt. Zum Beleg zitierte er Umfrageergebnisse von 2017, die zeigen, dass nur 17 Prozent der Hadoop-Projekte aktiv genutzt werden.
Dass die Komplexität der Bereitstellung ein Problem ist, zeigt auch die Art der Anwenderfragen. „Anfragen von IT-Teams in Unternehmen zu Hadoop und Data Lakes werden immer häufiger zu Implementierungsfragen“, sagt Adrian während einer Präsentation auf dem Pacific Northwest BI & Analytics Summit 2017. Er vergleicht den Aufbau einer Big-Data-Architektur mit dem Zusammensetzen eines Puzzles, „bei dem das Problem ist, dass man nicht die Schachtel hat, um zu sehen, wie das Puzzle am Ende aussehen soll.“
TMW Systems musste ebenfalls schlechte Erfahrungen machen, als es 2015 mit der Implementierung einer Hadoop-Umgebung begann. Dem Anbieter von Transport-Management-Software für Speditionen mangelte es schlicht an Big Data Skills „Wir mussten bei null anfangen", sagt Timothy Leonard, der als Executive Vice President of Operations and Technology das Projekt bei TMW leiten sollte. „Das Wissen war nicht da, als ich kam. Ich habe die meiste Zeit damit verbracht, den Leuten Big-Data-Konzepte beizubringen.“
„Heute können Transportunternehmen aggregierte Industriedaten über Preise, Kraftstoffverbrauch und andere Parameter sehen – und diese Daten für ihre Zwecke nutzen.“
Timothy Leonard, TMW Systems
Anfang 2016 begann TMW damit, die Plattform für eine neue Reihe von Analyseanwendungen zu nutzen, die das Unternehmen seinen Kunden anbietet. „Früher konnten Transportunternehmen und Spediteure nur auf ihre eigenen Daten zugreifen, um sie zu analysieren“, sagt Leonard. „Heute können sie aggregierte Industriedaten über Preise, Kraftstoffverbrauch und andere Parameter sehen – und diese Daten für ihre Zwecke nutzen.“
Die operativen Daten von den Transportunternehmen, die die Software von TMW einsetzen, werden aus den ERP-Systemen von Mayfield Heights in Ohio in die Big-Data-Architektur gezogen. Diese basiert auf der Hadoop-Distribution von Hortonworks und ist in eine lokale Installation und eine Microsoft Azure Cloud aufgeteilt.
Leonard erklärt, dass die Daten, die sich derzeit auf mehrere hundert TB belaufen, in einer Reihe von HBase-Tabellen mit jeweils bis zu 9.000 Spalten gespeichert sind. Die Tabellen ermöglichen es den Nutzern der Analytics-Anwendungen, „wirklich jede gewünschte Frage zu den Daten zu stellen.“ Es können auch mehrere Tabellen für die Abfrage zusammengefügt werden, um zum Beispiel Daten über Kraftstoffverbrauch und Straßenzustand miteinander zu kombinieren.
Hohe Verarbeitungsgeschwindigkeit erforderlich
Das Network Security Start-up ProtectWise baute sein Geschäft von Anfang an um eine Gruppe von Big-Data-Systeme auf. ProtectWise bietet Unternehmen Utility-Modelle für Netzwerksicherheit. Dazu sammelt das Unternehmen täglich etwa zehn Milliarden Datensätze von Betriebsdaten aus Unternehmensnetzwerken. Die Daten werden sowohl für die Echtzeit- als auch für die historische Analyse von Sicherheitsbedrohungen verwendet. Die Firma verpflichtet sich, dass sie im Rahmen ihrer Verträge mit Kunden keine Aufzeichnungen verpassen oder verlieren wird.
„Das Erfassen, Verarbeiten und Analysieren aller Netzwerkdaten, die rund um die Uhr generiert werden, wäre ohne diese Architektur physisch unmöglich gewesen“, sagt ProtectWise Mitbegründer und CTO Gene Stevens. „Wir hätten daraus nie ein Business machen können.“
„Zu Spitzenzeiten verarbeitet das DSE-System etwa sechs Millionen Transaktionen pro Sekunde.“
Gene Stevens, ProtectWise
Die Cloud-basierte Big-Data-Architektur beruht auf der DataStax Enterprise (DSE) Implementierung von Cassandra, die die Echtzeit-Analyseroutinen zur Erkennung von Angriffen auf Netzwerke übernimmt. Die NoSQL-Datenbank speichert auch Indizes, die auf Petabyte große historische Daten verweisen. Diese werden in S3 typischerweise für ein Jahr aufbewahrt.
Zur Analyse der Daten verwendet ProtectWise das Structured Streaming Modul von Spark. Mit dem Modul erhält das Unternehmen auch Einblicke in frühere Sicherheitsvorfälle, bekommt Angriffsindikatoren und nutzt DSE-Indizes, um relevante Datensätze zu finden. Darüber hinaus ist Solr mit DSE verbunden und kann von Kunden verwendet werden, um ihre eigenen analytischen Abfragen zu machen.
„Zu Spitzenzeiten verarbeitet das DSE-System etwa sechs Millionen Transaktionen pro Sekunde“, sagt Stevens. ProtectWise verwendet auch eine selbst geschriebene Processing Engine, die mit dem Akka Toolkit in Scala geschrieben wurde. Damit werden Daten, die hohe Durchsatzraten erfordern, in DSE eingespeist und dann zur Analyse wieder herausgezogen. Dieses System verarbeitet täglich weitere eine Milliarde Transaktionen.
Die Umsetzung der Architektur hat bei ProtectWise einige Zeit in Anspruch genommen. Das 2013 gegründete Unternehmen begann zunächst mit der Open-Source-Version von Cassandra. Um das System zu beschleunigen und die integrierte Solr-Integration zu erhalten, wechselte man dann zu DSE. „Allerdings gab es hier Probleme mit der Funktionalität in der Datenbank, besonders mit den Solr-Verbindungen“, sagt Stevens.
Nachdem die Schwierigkeiten behoben waren, ging das DSE- und S3-Setup Mitte 2014 in Betrieb. Aber auch hier gab es Probleme, weil Spark die Verarbeitungsanforderungen des Unternehmens nicht erfüllen konnte. Deshalb entschloss sich das Unternehmen schließlich, die Processing Engine selbst zu schreiben. Spark wurde Anfang 2016 in den Mix aufgenommen.
Nun funktioniert alles. „Der Datendurchsatz ist jetzt nur noch durch die Latenzzeit des Netzwerks begrenzt“, sagt Stevens. Und er ist überzeugt, dass die Big-Data-Systeme auch in Zukunft Bestand haben werden. Schließlich will ProtectWise sowohl sein Business als auch die Datenmengen, die es verarbeitet, weiter ausbauen. „Nicht, dass wir unser System nicht beobachten oder managen müssten“, räumt er ein, „aber wir sind ziemlich überzeugt, dass diese Technologie auch in Zukunft für uns wichtig und skalierbar sein wird.“
Folgen Sie SearchEnterpriseSoftware.de auch auf Twitter, Google+, Xing und Facebook!
