Die 7 häufigsten Hadoop- und Spark-Projekte

Es gibt ein altes Axiom, das ungefähr so ​​lautet: Wenn Sie jemandem Ihre volle Unterstützung und finanzielle Unterstützung anbieten, um etwas anderes und innovatives zu tun, wird er am Ende das tun, was alle anderen tun.

So geht es mit Hadoop, Spark und Storm. Jeder glaubt, mit diesen neuen Big-Data-Technologien etwas Besonderes zu tun, aber es dauert nicht lange, bis immer wieder dieselben Muster auftreten. Bestimmte Implementierungen können sich etwas unterscheiden, aber aufgrund meiner Erfahrung sind hier die sieben häufigsten Projekte.

Projekt Nr. 1: Datenkonsolidierung

Nennen Sie es einen "Enterprise Data Hub" oder "Data Lake". Die Idee ist, dass Sie unterschiedliche Datenquellen haben und diese analysieren möchten. Diese Art von Projekt besteht darin, Feeds aus allen Quellen (entweder in Echtzeit oder als Stapel) abzurufen und in Hadoop zu verschieben. Manchmal ist dies der erste Schritt, um ein „datengetriebenes Unternehmen“ zu werden. Manchmal möchten Sie einfach nur hübsche Berichte. Datenseen werden normalerweise als Dateien in HDFS und Tabellen in Hive oder Impala angezeigt. Es gibt eine kühne, neue Welt, in der vieles davon in HBase auftaucht - und in Zukunft in Phoenix, weil Hive langsam ist.

Verkäufer sagen gerne Dinge wie "Schema beim Lesen", aber um erfolgreich zu sein, müssen Sie eine gute Vorstellung davon haben, wie Ihre Anwendungsfälle aussehen werden (das Hive-Schema sieht nicht besonders anders aus als das, was Sie tun würden ein Enterprise Data Warehouse). Der wahre Grund für einen Datensee ist die horizontale Skalierbarkeit und die wesentlich geringeren Kosten als bei Teradata oder Netezza. Für die "Analyse" richten viele Benutzer Tableau und Excel im Frontend ein. Anspruchsvollere Unternehmen mit „Real Data Scientists“ (Mathematikfreaks, die schlechtes Python schreiben) verwenden Zeppelin oder iPython Notebook als Frontend.

Projekt Nr. 2: Spezialisierte Analyse

Viele Datenkonsolidierungsprojekte beginnen tatsächlich hier, wo Sie einen besonderen Bedarf haben und einen Datensatz für ein System abrufen, das eine Art von Analyse durchführt. Diese sind in der Regel unglaublich domänenspezifisch, z. B. Liquiditätsrisiko- / Monte-Carlo-Simulationen bei einer Bank. In der Vergangenheit waren solche spezialisierten Analysen von veralteten, proprietären Paketen abhängig, die nicht so skaliert werden konnten wie die Daten und häufig unter einem begrenzten Funktionsumfang litten (teilweise, weil der Softwareanbieter möglicherweise nicht so viel über die Domäne wissen konnte wie die Institution darin eingetaucht).

In der Hadoop- und Spark-Welt sehen diese Systeme ungefähr so ​​aus wie Datenkonsolidierungssysteme, verfügen jedoch häufig über mehr HBase, benutzerdefinierten Nicht-SQL-Code und weniger Datenquellen (wenn nicht nur eine). Sie basieren zunehmend auf Funken.

Projekt Nr. 3: Hadoop als Dienstleistung

In jeder großen Organisation mit "spezialisierten Analyse" -Projekten (und ironischerweise ein oder zwei "Datenkonsolidierungs" -Projekten) werden sie unweigerlich die "Freude" (dh den Schmerz) verspüren, einige unterschiedlich konfigurierte Hadoop-Cluster zu verwalten, manchmal von verschiedenen Anbieter. Als nächstes werden sie sagen: "Vielleicht sollten wir dies konsolidieren und Ressourcen bündeln", anstatt dass die Hälfte ihrer Knoten die halbe Zeit im Leerlauf sitzt. Sie könnten in die Cloud gehen, aber viele Unternehmen können oder wollen nicht, oft aus Sicherheitsgründen (sprich: interne Politik und Arbeitsschutz). Dies bedeutet im Allgemeinen viele Chef-Rezepte und jetzt Docker-Container-Pakete.

Ich habe es noch nicht verwendet, aber Blue Data scheint hier einer Out-of-the-Box-Lösung am nächsten zu kommen, was auch kleinere Unternehmen ansprechen wird, denen es an den Voraussetzungen mangelt, Hadoop als Service bereitzustellen.

Projekt Nr. 4: Streaming Analytics

Viele Leute würden dies als "Streaming" bezeichnen, aber Streaming-Analysen unterscheiden sich stark vom Streaming von Geräten. Streaming Analytics ist häufig eine Echtzeitversion dessen, was eine Organisation in Stapeln getan hat. Nehmen Sie Antimeldwäsche oder Betrugserkennung: Warum tun Sie das nicht auf Transaktionsbasis und fangen Sie es so ab, wie es passiert, anstatt am Ende eines Zyklus? Gleiches gilt für die Bestandsverwaltung oder alles andere.

In einigen Fällen handelt es sich um eine neue Art von Transaktionssystem, das Daten Stück für Stück analysiert, während Sie sie parallel in ein Analysesystem umleiten. Solche Systeme manifestieren sich als Spark oder Storm mit HBase als üblichem Datenspeicher. Beachten Sie, dass Streaming-Analysen nicht alle Arten von Analysen ersetzen. Sie möchten immer noch historische Trends auftauchen oder frühere Daten nach etwas durchsuchen, das Sie nie in Betracht gezogen haben.

Projekt Nr. 5: Komplexe Ereignisverarbeitung

Hier geht es um die Echtzeit-Ereignisverarbeitung, bei der Subsekunden eine Rolle spielen. Obwohl dies für Anwendungen mit extrem geringer Latenz (Pikosekunden oder Nanosekunden) wie High-End-Handelssystemen immer noch nicht schnell genug ist, können Sie mit Reaktionszeiten von Millisekunden rechnen. Beispiele hierfür sind die Echtzeitbewertung von Anrufdatensätzen für Telekommunikationsunternehmen oder die Verarbeitung von Ereignissen im Internet der Dinge. Manchmal werden Sie feststellen, dass solche Systeme Spark und HBase verwenden - aber im Allgemeinen fallen sie auf ihre Gesichter und müssen in Storm konvertiert werden, was auf dem von der LMAX-Börse entwickelten Disruptor-Muster basiert.

In der Vergangenheit basierten solche Systeme auf kundenspezifischer Messaging-Software - oder leistungsstarken Standard-Client-Server-Messaging-Produkten -, aber das heutige Datenvolumen ist für beide zu hoch. Das Handelsvolumen und die Anzahl der Menschen mit Mobiltelefonen sind seit der Schaffung dieser Legacy-Systeme gestiegen, und medizinische und industrielle Sensoren pumpen zu viele Bits aus. Ich habe es noch nicht benutzt, aber das Apex-Projekt sieht vielversprechend aus und behauptet, schneller als Storm zu sein.

Projekt Nr. 6: Streaming als ETL

Manchmal möchten Sie Streaming-Daten erfassen und irgendwo lagern. Diese Projekte fallen normalerweise mit Nr. 1 oder Nr. 2 zusammen, fügen jedoch ihren eigenen Umfang und ihre eigenen Merkmale hinzu. (Einige Leute denken, sie machen Nr. 4 oder Nr. 5, aber sie werden tatsächlich auf die Festplatte geschrieben und analysieren die Daten später.) Dies sind fast immer Kafka- und Storm-Projekte. Spark wird ebenfalls verwendet, jedoch ohne Begründung, da Sie keine In-Memory-Analyse benötigen.

Projekt Nr. 7: Ersetzen oder Erweitern von SAS

SAS ist in Ordnung; SAS ist nett. SAS ist auch teuer und wir kaufen keine Boxen für alle Datenwissenschaftler und Analysten, damit Sie mit den Daten „spielen“ können. Außerdem wollten Sie etwas anderes tun als SAS oder ein hübscheres Diagramm erstellen. Hier ist dein schöner Datensee. Hier ist iPython Notebook (jetzt) ​​oder Zeppelin (später). Wir werden die Ergebnisse in SAS einspeisen und die Ergebnisse von SAS hier speichern.

Während ich andere Hadoop-, Spark- oder Storm-Projekte gesehen habe, sind dies die „normalen“ Alltagstypen. Wenn Sie Hadoop verwenden, erkennen Sie sie wahrscheinlich. Einige der Anwendungsfälle für diese Systeme habe ich Jahre zuvor implementiert und mit anderen Technologien gearbeitet.

Wenn Sie ein Oldtimer sind, der zu viel Angst vor dem „Big“ in Big Data oder dem „Do“ in Hadoop hat, sollten Sie dies nicht tun. Je mehr Dinge sich ändern, desto mehr bleiben sie gleich. Sie werden viele Parallelen zwischen dem Material finden, das Sie für die Bereitstellung verwendet haben, und den Hipster-Technologien, die in der Hadooposphäre herumwirbeln.