Über Big Data

Bevor Sie sich darüber beschweren, dass Big Data ein völlig überladener Begriff ist, denke ich, dass wir unabhängig davon, ob das stimmt, erst einmal lernen müssen, damit zu leben. Der Begriff Big Data wird uns noch eine Weile begleiten. Hier ist der Grund dafür:

Quelle: Google Trends.

Das Interesse ist eindeutig auf dem Höhepunkt und die Menschen sind in Kauflaune. Wenn die Menschen in Kauflaune sind, verkaufen die Unternehmen. Die Unternehmen, die verkaufen, haben ganze Abteilungen, die dafür sorgen, dass wir davon hören (auch bekannt als Marketing): Ich denke, wir werden noch eine ganze Weile von Big Data hören. Lassen Sie uns einen Blick darauf werfen, wie es dazu kam und was wir tun können, um davon zu profitieren.

Big Data avant la lettre

Im Jahr 2009 war ich Teil eines Teams, das sich mit der Indizierung und dem Abruf großer Mengen von Netzwerkdaten beschäftigte, die von unserem Kunden gesammelt wurden. Die bestehende Lösung, bei der MySQL-Datenbanken gesplittet wurden, funktionierte zwar, war aber mühsam zu warten und hatte mit Skalierbarkeitsproblemen zu kämpfen, so dass wir Apache Hadoop und HBase als Ersatz ausprobierten. Beide Technologien waren bestenfalls schwer zu warten und brachten in scheinbar zufälligen Momenten kryptische Fehlermeldungen, bis man sich die Zeit nahm, den eigentlichen Quellcode zu lesen und herausfand, wie die Dinge wirklich funktionierten. Darüber hinaus war die Software nicht sonderlich effizient in dem, was sie tat; sie holte nicht alles an Leistung aus den Rechnern heraus, auf denen sie lief. Doch trotz dieser Macken haben Hadoop und HBase vor allem eines getan: Sie sind skalierbar.

Hadoop und seine MapReduce-Implementierung boten eine allgemein verfügbare, quelloffene, skalierbare Abstraktion, die es Entwicklern ermöglichte, sich auf ihren Datenverarbeitungscode zu konzentrieren.

Im Wesentlichen bedeutete dies, dass es keine Rolle spielte, ob Sie einen Auftrag für einen Cluster mit zwei Rechnern oder einen Cluster mit zweihundert Rechnern programmierten; derselbe Code würde auf beiden gleichermaßen laufen. Wenn Sie viele Daten haben und nicht wissen, wie schnell sie wachsen werden, bedeutet das eine Menge. Ganz zu schweigen davon, dass es eine lebhafte Gemeinschaft von Leuten gab, die an dieser Open-Source-Software arbeiteten und Fragen auf Mailinglisten in einer Weise beantworteten, die den meisten kommerziellen Supportangeboten für Datenbanksoftware weit überlegen war. Wir haben viel Zeit damit verbracht, Cluster einzurichten, Probleme zu beheben und eine Menge auszuprobieren. Am Ende hat alles relativ gut funktioniert. Wie bei den meisten Softwareprojekten haben wir es geschafft, dass es funktioniert.

Wenig später gewann Hadoop an Zugkraft, da große Webunternehmen über Erfolge mit dieser Technologie berichteten. Die Kritiker waren damit beschäftigt, auf die praktischen Probleme hinzuweisen, während diejenigen, die die theoretischen Möglichkeiten verstanden, hart daran arbeiteten, die Software zu verbessern. Zu dieser Zeit begannen auch die Abteilungen, die dafür sorgen, dass wir von den Dingen erfahren, sie Big Data zu nennen und dafür zu sorgen, dass jeder über die drei, vier oder fünf V's Bescheid weiß, die damit verbunden sein sollten. (Beachten Sie, dass der ursprüngliche Bericht, in dem die drei V's zum ersten Mal aufgelistet wurden, den Begriff "Big Data" nirgends enthält).

In der Zwischenzeit waren die Menschen, die tatsächlich von der Technologie profitierten, nicht so sehr daran interessiert, welches der V's ihre Probleme verkörperten, sondern hauptsächlich daran, die Dinge zu erledigen. Es war, als gäbe es eine Big-Data-Welt, angeführt von Leuten wie Gartner, und eine Hadoop-Welt, angeführt von Ingenieuren. Unternehmen, die bereits Probleme mit der Skalierbarkeit ihrer Daten hatten, sahen sich Hadoop als Lösung an, während Unternehmen, die gut zurechtkamen, aber Angst hatten, Big Data zu verpassen, hart daran arbeiteten, Anwendungsfälle zu erfinden, die zu ihnen passen würden. Letzteres mag zwar albern erscheinen, ist aber gar nicht so verschwenderisch, wie es klingen mag. Diese Initiativen trieben die Innovation voran und zwangen traditionelle Unternehmen dazu, einige ihrer Geschäfte neu zu bewerten und neue Wege einzuschlagen. In den meisten dieser Fälle war nicht die Tatsache, dass Hadoop große Datenmengen verarbeiten kann, das interessante Ergebnis. Vielmehr war es die Tatsache, dass ein Großteil der in Unternehmen verfügbaren Daten auf andere Weise als für den vorgesehenen Zweck genutzt werden kann und zu neuen Geschäfts- oder Kundenkontakten führt. In einigen Fällen war eine Plattform wie Hadoop technisch nicht erforderlich, aber sie trug dazu bei, ein Klima für Innovationen zu schaffen; sie brachte die Menschen dazu, über die Nutzung von Daten anders nachzudenken.

Das Versprechen von Big Data

Die Magie von Big Data besteht angeblich darin, dass Sie mit sehr einfachen Methoden und Modellen interessante und aussagekräftige Ergebnisse erzielen können, solange die Datenmenge sehr groß ist. Die Muster tauchen einfach auf. Ein Beispiel dafür ist die Google Trends-Grafik oben in diesem Beitrag. Wir können Aussagen über das relative öffentliche Interesse an diesen Themen machen, wenn wir davon ausgehen, dass es einen Zusammenhang zwischen dem Suchverhalten der Menschen und realen Ereignissen und Trends gibt. In diesem Fall interessiert uns die Kausalität dieser Beziehung nicht. Die verwendete Methode ist extrem einfach: Zählen Sie, wie oft eine Suche vorkommt. Dennoch sind die Ergebnisse aufgrund des immensen Datenvolumens interessant.

Wenn Sie sich über den Zusammenhang zwischen Google-Suchanfragen und realen Ereignissen wundern, finden Sie hier ein Beispiel, das sich kaum leugnen lässt. In der Grafik unten zeigen die Punkte auf der blauen Linie das relative wöchentliche Suchvolumen für den Begriff "Vollmond" an. Die Wochen mit den roten Punkten sind die Wochen, in denen ein Vollmond stattfand, die Wochen mit den blauen Punkten die übrigen. Es gibt eine sehr klare Beziehung zwischen dem Suchvolumen und dem realen Ereignis. Es ist für uns leicht zu verstehen, dass die Suchanfragen keinen Vollmond verursachen, genauso wie die Suchanfragen nach Big Data nicht das Interesse an diesem Thema verursachen. Für ein Modell, das den nächsten Vollmond (oder die nächste Welle des Interesses an einem Thema) vorhersagt, ist dies jedoch nicht relevant. Sie können einfach Wörter im Internet zählen, um Aussagen über die reale Welt zu treffen: Big Data in seiner schönsten Form.

Quelle: Google Trends und moongiant.com. Hinweis: Google Trends zeigt nur wochenweise Daten an, so dass die Vollmonddaten ebenfalls auf den Beginn der Woche, in der sie stattfanden, normalisiert sind.

Wie sich herausstellt, sind die obigen Beispiele zwar nett, aber das Zählen von Wörtern im Internet löst nicht alle Geschäftsprobleme. Wir möchten detailliertere Vorhersagen machen als die über die gesamte Population der Google-Nutzer. Wir kümmern uns um unsere eigenen Kunden oder Nutzergemeinschaften, denn sie erwarten von unseren Produkten ein sehr hohes Maß an Personalisierung und Anpassung. Doch die Daten, die wir über diese Kunden sammeln, sind in der Regel sehr spärlich. Als Online-Händler haben Sie vielleicht Millionen von Besuchern, aber jeder einzelne von ihnen besucht Ihren Shop vielleicht nur ein- oder zweimal im Jahr. Trotzdem sollen wir ihnen personalisierte E-Mail-Kampagnen schicken, punktgenaue Produktempfehlungen geben und erkennen können, ob es Möglichkeiten für Up-Sell oder Cross-Sell gibt. All dies basiert auf diesen ein oder zwei Besuchen pro Jahr.

Die Gesamtmenge der Daten kann sehr groß sein, aber die Menge der Informationen über einzelne Kunden ist begrenzt. In diesem Szenario noch eine punktgenaue Personalisierung zu bieten, ist ein sehr schwieriges Problem und geht weit über das Zählen von Wörtern hinaus: Hier kommen Data Science und maschinelles Lernen ins Spiel.

Es überrascht nicht, dass wir in unseren Suchtrends feststellen, dass diese Disziplinen im Vergleich zu traditionelleren datenbezogenen Arbeiten wie Business Intelligence immer beliebter werden.

Die Fähigkeiten, die für die Bearbeitung von Problemen im Bereich Data Science und maschinelles Lernen erforderlich sind, sind rar und die Kombination dieser Fähigkeiten mit denen, die für den Umgang mit großen Datenmengen aus einer technischen Perspektive erforderlich sind, noch viel mehr. Aus diesem Grund haben wir GoDataDriven gegründet. Wir helfen unseren Kunden, diesen Weg einzuschlagen. Außerdem sind diese komplexen Modelle und Methoden sehr viel rechenintensiver als das bloße Zählen von Wörtern. Glücklicherweise befinden wir uns hier in einer guten Position.

Computer sind billig und schnell

Viele der Methoden, die derzeit beim maschinellen Lernen in großem Maßstab eingesetzt werden, sind Jahre, wenn nicht Jahrzehnte alt. Natürlich gibt es in letzter Zeit Verfeinerungen und zusätzliche Forschungsarbeiten, aber das Grundgerüst gibt es schon seit langem. Zwei Dinge haben sich geändert: Wir haben mehr Daten und wir haben bessere Möglichkeiten, sie zu verarbeiten.

Es geht nicht so sehr darum, dass wir früher nicht in der Lage waren, leistungsfähige Computer zu bauen, sondern dass sich die Wirtschaftlichkeit der Skalierung von Computersystemen drastisch verändert hat.

Ab und zu wird im Internet etwas über dieses Phänomen gewitzelt:

"'Wenn Sie die Rechenleistung, die in einem iPhone 5S steckt, im Jahr 1991 gekauft hätten, hätte es Sie 3,56 Millionen Dollar gekostet.'" Technologie: Der große Gleichmacher

â Steven Sinofsky (@stevesi) December 23, 2014

Mit oder ohne zweijähriges Abonnement. Es wäre auch nicht gerade im Taschenformat gewesen. Diese Zahl mag zwar nicht auf den Dollar genau sein, aber die Größenordnung ist wahrscheinlich korrekt. Die Rechenleistung in Ihrer Hosentasche war irgendwann einmal ein Multi-Millionen-Dollar-Computer, wahrscheinlich noch zu Ihren Lebzeiten. Unten sehen Sie ein Diagramm, dessen Daten ursprünglich von John C. McCallum gesammelt und später von Blok ergänzt wurden, der auch dieses Diagramm erstellt hat. Beachten Sie, dass die vertikale Achse eine logarithmische Skala hat! Hier gibt es ein paar Dinge zu beachten (in keiner bestimmten Reihenfolge). Als Google sein MapReduce-Papier veröffentlichte (2004), waren Spinning-Festplatten teurer als SSDs heute. Die erste Veröffentlichung von Hadoop war im September 2007. Zu diesem Zeitpunkt lagen die Preise für Spinning-Festplatten mehr oder weniger auf dem Niveau der heutigen SSD-Preise. Der niedrigste Preis für Arbeitsspeicher (RAM) entspricht in etwa den Preisen für Spinning Disks im Jahr 2001. Wie auch immer Sie es betrachten: In-Memory-Computing ist eine attraktive Option für viele Probleme, die bisher auf der Festplatte gelöst werden mussten. Das Gleiche gilt für die Verwendung von SSDs anstelle von rotierenden Festplatten. Das Lesen von Daten von einer SSD ist etwa 6-7 Mal schneller als das Lesen von einer rotierenden Festplatte. Das Lesen von Daten aus dem Speicher ist etwa 105 Mal schneller als das Lesen von einer Spinning Disk und 15 Mal schneller als das Lesen von einer SSD. (Zahlen zur Latenzzeit mit freundlicher Genehmigung dieser Website). All dies bedeutet, dass einige Probleme, die früher als Cluster-Probleme galten (d.h. zu groß für eine einzelne Maschine), jetzt Probleme im Maßstab einer einzelnen Maschine sind. Das Problem ist, dass es ein bewegliches Ziel ist, welche Klasse von Problemen Sie vor sich haben. Die Maschinen werden immer billiger und schneller, aber die Daten wachsen und die Methoden und Modelle, die wir anwenden, werden immer komplexer. Dies erfordert die Art von Skalierbarkeit, die Hadoop bietet. Um flexibel zu sein, sollte es keine Rolle spielen, ob Ihr Code auf zwei oder zweihundert Rechnern läuft.

Die Ineffizienz der Verkleinerung

val tf = sc.textFile("/mnt/raid/numbers.txt")
tf.count

val data = tf.map(_.split('|'))
.map(line => (
 line(0).toLong, line(1).toLong,
 line(2).toLong, line(3).toLong,
 line(4).toLong, line(5).toDouble,
 line(6).toDouble)
 )
data.count

import org.apache.spark.SparkContext._
data.map(_._5.toDouble)
.stats

data.map( x => (x._3, 1) )
.reduceByKey(_ + _)
.collect

data.map( x => (x._4, 1) )
.reduceByKey(_ + _)
.map(List(_))
.reduce( (x,y) => (x ++ y).sortWith(_._2 > _._2)
.slice(0,10))

import org.apache.spark.mllib.clustering.KMeans
import org.apache.spark.mllib.linalg.Vectors
val clusterData =
 data.sample(false, 0.1)
.map(
 t => Vectors.dense( Array(t._6, t._7) )
 )
clusterData.cache
clusterData.count //returns 60011237
val clusters = KMeans.train(clusterData, 4, 10)

Fazit