Sturm oder Funke: Wählen Sie Ihre Echtzeitwaffe

Die Idee von Business Intelligence in Echtzeit gibt es schon seit einiger Zeit (siehe die Wikipedia-Seite zu dem 2006 begonnenen Thema). Aber während die Leute jahrelang über die Idee gesprochen haben, habe ich nicht gesehen, dass viele Unternehmen die Vision tatsächlich annehmen, geschweige denn die Vorteile erkennen, die sie ermöglicht.

Zumindest ein Teil des Grundes war das Fehlen von Tools für die Implementierung von BI und Analytics in Echtzeit. Herkömmliche Data-Warehousing-Umgebungen waren stark auf Batch-Vorgänge mit extrem hohen Latenzen ausgerichtet, waren unglaublich teuer oder beides.

Eine Reihe leistungsfähiger, benutzerfreundlicher Open Source-Plattformen hat sich herausgebildet, um dies zu ändern. Zwei der bemerkenswertesten sind Apache Storm und Apache Spark, die Echtzeitverarbeitungsfunktionen für ein viel breiteres Spektrum potenzieller Benutzer bieten. Beide sind Projekte innerhalb der Apache Software Foundation, und obwohl die beiden Tools überlappende Funktionen bieten, haben sie jeweils unterschiedliche Merkmale und Rollen.

Storm: Der Hadoop der Echtzeitverarbeitung

Storm, ein verteiltes Berechnungsframework für die Verarbeitung von Ereignisströmen, wurde als Projekt von BackType ins Leben gerufen, einem Marketing-Intelligence-Unternehmen, das 2011 von Twitter gekauft wurde. Twitter stellte das Projekt bald als Open-Source-Version zur Verfügung und stellte es auf GitHub, aber Storm wechselte schließlich zum Apache Incubator und wurde im September 2014 ein Apache-Top-Level-Projekt.

Storm wurde manchmal als Hadoop der Echtzeitverarbeitung bezeichnet. Die Storm-Dokumentation scheint zuzustimmen: "Storm macht es einfach, unbegrenzte Datenströme zuverlässig zu verarbeiten, und zwar für die Echtzeitverarbeitung, was Hadoop für die Stapelverarbeitung getan hat."

Um dieses Ziel zu erreichen, ist Storm auf massive Skalierbarkeit ausgelegt, unterstützt Fehlertoleranz mit einem "Fail Fast, Auto Restart" -Ansatz für Prozesse und bietet eine starke Garantie dafür, dass jedes Tupel verarbeitet wird. Storm bietet standardmäßig eine "mindestens einmalige" Garantie für Nachrichten, bietet jedoch auch die Möglichkeit, die Verarbeitung "genau einmal" zu implementieren.

Storm wurde hauptsächlich in Clojure geschrieben und unterstützt die Verdrahtung von „Ausgüssen“ (Think Input Streams) und „Bolts“ (Verarbeitungs- und Ausgabemodule) als gerichteten azyklischen Graphen (DAG), der als Topologie bezeichnet wird. Storm-Topologien werden auf Clustern ausgeführt, und der Storm-Scheduler verteilt die Arbeit basierend auf der Topologiekonfiguration auf die Knoten im Cluster.

Sie können sich Topologien als ungefähr analog zu einem MapReduce-Job in Hadoop vorstellen, mit der Ausnahme, dass Topologien angesichts des Fokus von Storm auf Echtzeit-Stream-basierte Verarbeitung standardmäßig für immer oder bis zur manuellen Beendigung ausgeführt werden. Sobald eine Topologie gestartet ist, bringen die Ausläufe Daten in das System und geben sie an Schrauben weiter (die wiederum Daten an nachfolgende Schrauben weitergeben können), wo die Hauptberechnungsarbeit erledigt wird. Während der Verarbeitung können eine oder mehrere Schrauben Daten in eine Datenbank oder ein Dateisystem schreiben, eine Nachricht an ein anderes externes System senden oder den Benutzern die Ergebnisse der Berechnung auf andere Weise zur Verfügung stellen.

Eine der Stärken des Storm-Ökosystems ist eine Vielzahl verfügbarer Ausläufe, die auf den Empfang von Daten aus allen Arten von Quellen spezialisiert sind. Während Sie möglicherweise benutzerdefinierte Ausläufe für hochspezialisierte Anwendungen schreiben müssen, besteht eine gute Chance, dass Sie einen vorhandenen Auslauf für eine unglaublich große Vielfalt von Quellen finden - von der Twitter-Streaming-API über Apache Kafka über JMS-Broker bis hin zu allem dazwischen.

Es gibt Adapter, die die Integration in HDFS-Dateisysteme vereinfachen, sodass Storm bei Bedarf problemlos mit Hadoop zusammenarbeiten kann. Eine weitere Stärke von Storm ist die Unterstützung der mehrsprachigen Programmierung. Während Storm selbst auf Clojure basiert und auf der JVM ausgeführt wird, können Ausläufe und Bolzen in nahezu jeder Sprache geschrieben werden, einschließlich Nicht-JVM-Sprachen, die ein Protokoll für die Kommunikation zwischen Komponenten mithilfe von JSON über stdin / stdout nutzen.

Kurz gesagt, Storm ist ein sehr skalierbares, schnelles und fehlertolerantes Open-Source-System für verteilte Berechnungen mit einem besonderen Schwerpunkt auf der Stream-Verarbeitung. Storm zeichnet sich durch Ereignisverarbeitung und inkrementelle Berechnung aus und berechnet rollierende Metriken in Echtzeit über Datenströme. Während Storm auch Grundelemente bereitstellt, um generische verteilte RPC zu ermöglichen, und theoretisch verwendet werden kann, um fast jeden verteilten Rechenauftrag zusammenzustellen, liegt seine Stärke eindeutig in der Verarbeitung von Ereignisströmen.

Spark: Verteilte Verarbeitung für alle

Spark, ein weiteres Projekt, das für verteilte Echtzeitberechnungen geeignet ist, begann als AMPLab-Projekt an der University of California in Berkeley, bevor es zum Apache Incubator wechselte und schließlich im Februar 2014 als Top-Level-Projekt abschloss. Wie Storm unterstützt Spark Stream -orientierte Verarbeitung, aber es ist eher eine universelle verteilte Computerplattform.

Daher kann Spark als potenzieller Ersatz für die MapReduce-Funktionen von Hadoop angesehen werden, während Spark auf einem vorhandenen Hadoop-Cluster ausgeführt werden kann und sich bei der Ressourcenplanung auf YARN stützt. Zusätzlich zu Hadoop YARN kann Spark Mesos für die Planung überlagern oder mithilfe des integrierten Schedulers als eigenständiger Cluster ausgeführt werden. Beachten Sie, dass, wenn Spark nicht mit Hadoop verwendet wird, weiterhin ein Netzwerk / verteiltes Dateisystem (NFS, AFS usw.) erforderlich ist, wenn es in einem Cluster ausgeführt wird, sodass jeder Knoten Zugriff auf die zugrunde liegenden Daten hat.

Spark ist in Scala geschrieben und unterstützt wie Storm die mehrsprachige Programmierung, obwohl Spark nur für Scala, Java und Python spezifische API-Unterstützung bietet. Spark verfügt nicht über die spezifische Abstraktion eines „Auslaufs“, sondern enthält Adapter für die Arbeit mit Daten, die in zahlreichen unterschiedlichen Quellen gespeichert sind, darunter HDFS-Dateien, Cassandra, HBase und S3.

Wo Spark glänzt, ist die Unterstützung mehrerer Verarbeitungsparadigmen und der unterstützenden Bibliotheken. Ja, Spark unterstützt ein Streaming-Modell, aber diese Unterstützung wird nur von einem von mehreren Spark-Modulen bereitgestellt, einschließlich speziell entwickelter Module für SQL-Zugriff, Diagrammoperationen und maschinelles Lernen sowie Stream-Verarbeitung.

Spark bietet außerdem eine äußerst praktische interaktive Shell, die mithilfe der Scala- oder Python-APIs schnelles und schmutziges Prototyping und explorative Datenanalyse in Echtzeit ermöglicht. Wenn Sie in der interaktiven Shell arbeiten, bemerken Sie schnell einen weiteren großen Unterschied zwischen Spark und Storm: Spark hat eher einen „funktionalen“ Charakter, bei dem die Arbeit mit der API eher durch die Verkettung aufeinanderfolgender Methodenaufrufe zum Aufrufen primitiver Operationen gesteuert wird - im Gegensatz zu Storm-Modell, das in der Regel durch das Erstellen von Klassen und das Implementieren von Schnittstellen gesteuert wird. Keiner der Ansätze ist besser oder schlechter, aber der Stil, den Sie bevorzugen, kann Ihre Entscheidung beeinflussen, welches System besser zu Ihren Anforderungen passt.

Wie Storm ist Spark auf massive Skalierbarkeit ausgelegt, und das Spark-Team hat Benutzer des Systems dokumentiert, auf denen Produktionscluster mit Tausenden von Knoten ausgeführt werden. Darüber hinaus gewann Spark den jüngsten Daytona GraySort-Wettbewerb 2014 und erzielte damit die beste Zeit für eine überlastete Arbeitsbelastung, die aus dem Sortieren von 100 TB Daten besteht. Das Spark-Team dokumentiert auch Spark-ETL-Vorgänge mit Produktions-Workloads im Bereich von mehreren Petabyte.

Spark ist eine schnelle, skalierbare und flexible Open Source-Plattform für verteiltes Rechnen, die mit Hadoop und Mesos kompatibel ist und verschiedene Rechenmodelle unterstützt, darunter Streaming, graphzentrierte Operationen, SQL-Zugriff und verteiltes maschinelles Lernen. Es wurde dokumentiert, dass Spark außergewöhnlich gut skaliert werden kann und wie Storm eine hervorragende Plattform ist, um ein Echtzeit-Analyse- und Business-Intelligence-System aufzubauen.

Treffen Sie Ihre Entscheidung

Wie wählst du zwischen Storm und Spark?

Wenn sich Ihre Anforderungen in erster Linie auf die Stream-Verarbeitung und die Verarbeitung im CEP-Stil konzentrieren und Sie ein Greenfield-Projekt mit einem speziell für das Projekt erstellten Cluster starten, würde ich Storm wahrscheinlich bevorzugen - insbesondere wenn vorhandene Storm-Ausläufe verfügbar sind, die Ihren Integrationsanforderungen entsprechen . Dies ist keineswegs eine feste Regel, aber solche Faktoren würden zumindest darauf hindeuten, mit Storm zu beginnen.

Wenn Sie jedoch einen vorhandenen Hadoop- oder Mesos-Cluster nutzen und / oder wenn Ihre Verarbeitungsanforderungen erhebliche Anforderungen an die Grafikverarbeitung, den SQL-Zugriff oder die Stapelverarbeitung stellen, sollten Sie sich zunächst Spark ansehen.

Ein weiterer zu berücksichtigender Faktor ist die mehrsprachige Unterstützung der beiden Systeme. Wenn Sie beispielsweise Code nutzen müssen, der in R oder einer anderen Sprache geschrieben ist, die von Spark nicht nativ unterstützt wird, bietet Storm den Vorteil einer umfassenderen Sprachunterstützung. Aus dem gleichen Grund bietet Spark eine Funktion, die Storm nicht bietet, wenn Sie eine interaktive Shell für die Datenexploration mithilfe von API-Aufrufen benötigen.

Am Ende möchten Sie wahrscheinlich eine detaillierte Analyse beider Plattformen durchführen, bevor Sie eine endgültige Entscheidung treffen. Ich empfehle, beide Plattformen zu verwenden, um einen kleinen Proof of Concept zu erstellen. Führen Sie dann Ihre eigenen Benchmarks mit einer Arbeitslast aus, die Ihre erwarteten Arbeitslasten so genau wie möglich widerspiegelt, bevor Sie sich vollständig auf eine der beiden Plattformen festlegen.

Natürlich müssen Sie keine Entweder-Oder-Entscheidung treffen. Abhängig von Ihrer Arbeitslast, Infrastruktur und Ihren Anforderungen stellen Sie möglicherweise fest, dass die ideale Lösung eine Mischung aus Storm und Spark ist - zusammen mit anderen Tools wie Kafka, Hadoop, Flume usw. Darin liegt die Schönheit von Open Source.

Unabhängig von der gewählten Route zeigen diese Tools, dass sich das Echtzeit-BI-Spiel geändert hat. Leistungsstarke Optionen, die einst nur wenigen Eliten zur Verfügung standen, sind jetzt für die meisten, wenn nicht alle mittelständischen bis großen Unternehmen erreichbar. Nutzen Sie sie.