Hadoop: was, wo und warum



    Wir zerstreuen Ängste, beseitigen Analphabetismus und zerstören Mythen über den eisernen Elefanten. Unter der Katze ein Überblick über das Hadoop-Ökosystem, Entwicklungstrends und ein bisschen persönliche Meinung.

    Lieferanten: Apache, Cloudera, Hortonworks, MapR



    Hadoop ist das Top-Level-Projekt der Apache Software Foundation, weshalb Apache Hadoop als Hauptdistributions- und zentrales Repository für alle Entwicklungen gilt. Dieselbe Verteilung ist jedoch der Hauptgrund für die Mehrheit der verbrannten Nervenzellen, die mit diesem Tool vertraut sind: Standardmäßig erfordert die Installation eines Elefanten in einem Cluster eine Vorkonfiguration der Maschinen, die manuelle Installation von Paketen, die Bearbeitung vieler Konfigurationsdateien und eine Reihe anderer Körperbewegungen. Die Dokumentation ist jedoch häufig unvollständig oder einfach veraltet. In der Praxis werden daher meistens Distributionen von einem der drei Unternehmen verwendet:

    Cloudera. Ein Schlüsselprodukt - CDH (Cloudera Distribution, einschließlich Apache Hadoop) - eine Reihe der beliebtesten Tools der Hadoop-Infrastruktur, auf der Cloudera Manager ausgeführt wird. Der Manager übernimmt die Verantwortung für die Bereitstellung des Clusters, die Installation aller Komponenten und deren weitere Überwachung. Neben CDH entwickelt das Unternehmen auch seine anderen Produkte, zum Beispiel Impala (mehr dazu weiter unten). Eine Besonderheit von Cloudera ist auch der Wunsch, die ersten zu sein, die neue Funktionen auf dem Markt anbieten, auch auf Kosten der Stabilität. Nun und ja, der Schöpfer von Hadoop - Doug Cutting - arbeitet bei Cloudera.

    Hortonworks. Wie Cloudera bieten sie eine einzige Lösung in Form von HDP (Hortonworks Data Platform). Sie zeichnen sich dadurch aus, dass sie nicht ihre eigenen Produkte entwickeln, sondern mehr in die Entwicklung von Apache-Produkten investieren. Beispielsweise verwenden sie anstelle von Cloudera Manager Apache Ambari und anstelle von Impala entwickeln sie Apache Hive weiter. Meine persönliche Erfahrung mit dieser Distribution beruht auf ein paar Tests auf einer virtuellen Maschine, aber es scheint, dass HDP stabiler aussieht als CDH.

    Mapr. Im Gegensatz zu den beiden Vorgängerunternehmen, bei denen offenbar Beratung und Affiliate-Programme die Haupteinnahmequelle darstellen, ist MapR direkt am Verkauf seiner Entwicklungen beteiligt. Von den Profis: Viele Optimierungen, ein Partnerprogramm bei Amazon. Von den Minuspunkten: Die kostenlose Version (M3) hat Funktionalität abgeschnitten. Darüber hinaus ist MapR der Hauptideologe und Chefentwickler von Apache Drill.

    Grundlage: HDFS



    Wenn wir über Hadoop sprechen, meinen wir hauptsächlich das Dateisystem - HDFS (Hadoop Distributed File System). Der einfachste Weg, an HDFS zu denken, ist, sich ein reguläres Dateisystem vorzustellen, nur mehr. Ein typisches Dateisystem besteht im Großen und Ganzen aus einer Dateideskriptortabelle und einem Datenbereich. In HDFS wird anstelle einer Tabelle ein spezieller Server verwendet - ein Nameserver (NameNode), und Daten werden auf Datenserver (DataNode) verteilt.

    Bild

    Ansonsten gibt es nicht so viele Unterschiede: Die Daten sind in Blöcke unterteilt (normalerweise 64 MB oder 128 MB), für jede Datei speichert der Nameserver seinen Pfad, eine Liste von Blöcken und deren Replikate. HDFS verfügt über eine klassische Unix-Baumstruktur mit Verzeichnissen, Benutzern mit drei Rechten und sogar ähnlichen Konsolenbefehlen:

    # просмотреть корневую директорию: локально и на HDFS
    ls /
    hadoop fs -ls /
    # оценить размер директории 
    du -sh mydata
    hadoop fs -du -s -h mydata
    # вывести на экран содержимое всех файлов в директории
    cat mydata/*
    hadoop fs -cat mydata/* 
    


    Warum ist HDFS so cool? Erstens, weil es zuverlässig ist: Irgendwie hat die IT-Abteilung beim Umbau der IT-Ausrüstung versehentlich 50% unserer Server zerstört, während nur 3% der Daten unwiederbringlich verloren gingen. Und zweitens, und was noch wichtiger ist, der Nameserver zeigt die Position von Datenblöcken auf Maschinen für jedermann an . Warum dies wichtig ist, erfahren Sie im nächsten Abschnitt.

    Motoren: MapReduce, Spark, Tez



    Mit der richtigen Architektur der Anwendung können Sie anhand der Informationen zu den Computern, auf denen sich die Datenblöcke befinden, Rechenprozesse auf diesen Computern ausführen (die wir "Worker" nennen) und die meisten Berechnungen lokal ausführen , d. H. ohne Datenübertragung über das Netzwerk. Es ist diese Idee, die dem MapReduce- Paradigma und seiner konkreten Implementierung in Hadoop zugrunde liegt.

    Die klassische Hadoop-Cluster-Konfiguration besteht aus einem Nameserver, einem MapReduce-Assistenten (dem sogenannten JobTracker) und einer Reihe von Arbeitsmaschinen, auf denen jeweils gleichzeitig ein Datenserver (DataNode) und ein Worker (TaskTracker) ausgeführt werden. Jede MapReduce-Arbeit besteht aus zwei Phasen:

    1. map - läuft parallel und (wenn möglich) lokal auf jedem Datenblock. Anstatt Terabytes an Daten an das Programm zu liefern, wird ein kleines benutzerdefiniertes Programm mit den Daten auf den Server kopiert und erledigt alles damit, was kein Mischen und Verschieben von Daten (Shuffle) erfordert.
    2. verkleinern - ergänzt die Karte um Aggregationsoperationen


    Tatsächlich gibt es zwischen diesen Phasen auch eine Kombinationsphase , die das gleiche bewirkt wie das Reduzieren , jedoch oberhalb der lokalen Datenblöcke. Angenommen, wir haben 5 Terabyte an Mailserver-Protokollen, die wir zum Parsen und Extrahieren von Fehlermeldungen benötigen. Linien sind unabhängig voneinander, sodass ihre Analyse auf die Kartenaufgabe verschoben werden kann . Anschließend können Sie mit dem Befehl "Kombinieren" die Zeilen mit der Fehlermeldung auf Einzelserverebene und anschließend mit " Reduzieren" filternMachen Sie dasselbe auf der Ebene aller Daten. Alles, was parallelisiert werden konnte, haben wir parallelisiert und darüber hinaus den Datentransfer zwischen Servern minimiert. Und selbst wenn eine Aufgabe aus irgendeinem Grund abstürzt, wird sie von Hadoop automatisch neu gestartet, wobei Zwischenergebnisse von der Festplatte abgerufen werden. Cool!

    Das Problem ist, dass die meisten Aufgaben in der Praxis viel komplizierter sind als ein einzelner MapReduce-Job. In den meisten Fällen möchten wir parallele Operationen ausführen, dann sequentiell, dann erneut parallel, dann mehrere Datenquellen kombinieren und erneut parallele und sequentielle Operationen ausführen. Das Standard-MapReduce ist so konzipiert, dass alle Ergebnisse - sowohl endgültige als auch mittlere - auf die Festplatte geschrieben werden. Infolgedessen überschreitet die Zeit für das Lesen und Schreiben auf die Festplatte, multipliziert mit der Häufigkeit, mit der das Problem gelöst wird, häufig die Zeit für die eigentlichen Berechnungen.

    Und hier kommt Spark. Spark wurde von den Mitarbeitern der Berkeley University entwickelt und basiert auf der Idee der Datenlokalität. Dabei werden jedoch die meisten Berechnungen nicht auf einer Festplatte, sondern im Speicher abgelegt. Das Schlüsselkonzept in Spark ist RDD (Resilient Distributed Dataset) - ein Zeiger auf eine verzögerte verteilte Datenerfassung. Die meisten Operationen auf RDD führen zu keinen Berechnungen, sondern erstellen nur den nächsten Wrapper, der verspricht, Operationen nur dann auszuführen, wenn sie benötigt werden. Dies ist jedoch leichter zu zeigen als zu sagen. Das Folgende ist ein Python-Skript (Spark out of the Box unterstützt Schnittstellen für Scala, Java und Python) zur Lösung des Protokollproblems:

    sc = ...                                                        # создаём контекст (SparkContext)
    rdd = sc.textFile("/path/to/server_logs")     # создаём указатель на данные
    rdd.map(parse_line) \                                # разбираем строки и переводим их в удобный формат
          .filter(contains_error) \                         # фильтруем записи без ошибок
          .saveAsTextFile("/path/to/result")         # сохраняем результаты на диск
    


    In diesem Beispiel beginnen reale Berechnungen nur in der letzten Zeile: Spark sieht, dass die Ergebnisse materialisiert werden müssen, und wendet dafür Operationen auf die Daten an. Gleichzeitig gibt es keine Zwischenschritte - jede Zeile wird in den Speicher geladen, zerlegt, auf Anzeichen eines Fehlers in der Nachricht überprüft, und wenn es ein solches Anzeichen gibt, wird es sofort auf die Festplatte geschrieben.

    Ein solches Modell erwies sich als so effektiv und praktisch, dass Projekte aus dem Hadoop-Ökosystem damit begannen, ihre Berechnungen nacheinander auf Spark zu übertragen, und jetzt arbeiten mehr Menschen an der Engine selbst als an dem veralteten MapReduce.

    Aber nicht die von Spark. Hortonworks entschied sich für einen alternativen Motor - Tez. Tez präsentiert die Aufgabe als gerichteten azyklischen Graphen (DAG) von Handlerkomponenten. Der Scheduler startet die Berechnung des Graphen und konfiguriert ihn gegebenenfalls dynamisch neu, um die Daten zu optimieren. Dies ist ein sehr naheliegendes Modell für die Ausführung komplexer Datenabfragen, z. B. von SQL-ähnlichen Skripten in Hive, bei denen Tez die Beschleunigung auf das 100-fache gebracht hat. Abgesehen von Hive ist diese Engine jedoch noch nicht weit verbreitet. Daher ist es schwierig zu sagen, wie gut sie für einfachere und häufigere Aufgaben geeignet ist.

    SQL: Hive, Impala, Shark, Spark SQL, Drill



    Trotz der Tatsache, dass Hadoop eine vollständige Plattform für die Entwicklung von Anwendungen ist, wird es am häufigsten im Zusammenhang mit Datenspeicherung und speziell SQL-Lösungen verwendet. Eigentlich ist das nicht verwunderlich: Große Datenmengen bedeuten fast immer Analysen, und diese lassen sich mit tabellarischen Daten viel einfacher durchführen. Darüber hinaus ist es für SQL-Datenbanken viel einfacher, sowohl Tools als auch Personen zu finden als für NoSQL-Lösungen. In der Hadoop-Infrastruktur gibt es mehrere SQL-orientierte Tools:

    Hive- Das allererste und immer noch beliebteste DBMS auf dieser Plattform. Als Abfragesprache wird HiveQL verwendet, ein reduzierter SQL-Dialekt, mit dem Sie jedoch relativ komplexe Abfragen für in HDFS gespeicherte Daten durchführen können. Hier müssen Sie eine klare Linie zwischen den Versionen von Hive <= 0.12 und der aktuellen Version 0.13 ziehen: Wie ich bereits sagte, hat Hive in der neuesten Version von MapReduce auf die neue Tez-Engine umgestellt, diese um ein Vielfaches beschleunigt und für interaktive Analysen geeignet gemacht. Das heißt Jetzt müssen Sie nicht 2 Minuten warten, um die Anzahl der Datensätze in einer kleinen Partition zu berechnen, oder 40 Minuten, um die Daten für eine Woche nach Tag zu gruppieren (auf Wiedersehen, lange Pausen!). Darüber hinaus bieten sowohl Hortonworks als auch Cloudera ODBC-Treiber, mit denen Sie Tools wie Tableau mit Hive verbinden können.

    Impala ist ein Cloudera-Produkt und ein wichtiger Konkurrent von Hive. Im Gegensatz zu letzterem verwendete Impala nie das klassische MapReduce, sondern führte zunächst Abfragen auf einer eigenen Engine aus (übrigens nicht standardgemäß für Hadoop C ++ geschrieben). Zusätzlich hat Impala in letzter Zeit das Caching häufig verwendeter Datenblöcke und Spaltenspeicherformate aktiv eingesetzt, was sich sehr gut auf die Leistung von analytischen Abfragen auswirkt. Genau wie für Hive bietet Cloudera seinen Nachkommen einen sehr effektiven ODBC-Treiber.

    Hai. Als Spark mit seinen revolutionären Ideen in das Hadoop-Ökosystem eintrat, bestand der natürliche Wunsch darin, eine SQL-Engine auf dieser Basis zu entwickeln. Dies führte zu einem Projekt namens Shark, das von Enthusiasten ins Leben gerufen wurde. In Spark 1.0 veröffentlichte das Spark-Team jedoch die erste Version seiner eigenen SQL-Engine - Spark SQL. Von nun an gilt Shark als gestoppt.

    Spark sq- Ein neuer Zweig der SQL-Entwicklung, der auf Spark basiert. Ehrlich gesagt ist der Vergleich mit früheren Tools nicht ganz korrekt: Spark SQL verfügt nicht über eine separate Konsole und ein eigenes Metadaten-Repository, der SQL-Parser ist immer noch ziemlich schwach, und die Partitionen werden anscheinend überhaupt nicht unterstützt. Anscheinend besteht sein Hauptziel derzeit darin, Daten aus komplexen Formaten (wie z. B. Parkett, siehe unten) lesen und Logik in Form von Datenmodellen und nicht in Form von Programmcode ausdrücken zu können. Und ehrlich gesagt, das ist nicht so wenig! Sehr oft besteht die Verarbeitungspipeline aus alternierenden SQL-Abfragen und Programmcode. Mit Spark SQL können Sie diese Phasen nahtlos verknüpfen, ohne auf schwarze Magie zurückgreifen zu müssen.

    Hive on Spark - es gibt so etwas, aber anscheinend wird es nicht früher als Version 0.14 funktionieren.

    Bohren. Um das Bild zu vervollständigen, sollte Apache Drill erwähnt werden. Dieses Projekt befindet sich immer noch im ASF-Inkubator und ist nicht weit verbreitet, aber anscheinend wird der Schwerpunkt darin auf halbstrukturierten und eingebetteten Daten liegen. In Hive und Impala können Sie auch mit JSON-Zeichenfolgen arbeiten. Die Abfrageleistung ist jedoch erheblich reduziert (häufig bis zu 10-20 Mal). Es ist schwer zu sagen, wozu die Erstellung eines anderen auf Hadoop basierenden DBMS führen wird, aber lassen Sie uns abwarten.

    Persönliche Erfahrung
    Wenn es keine besonderen Anforderungen gibt, können nur zwei Produkte aus dieser Liste ernst genommen werden - Hive und Impala. Beide sind schnell genug (in den neuesten Versionen), reich an Funktionalität und entwickeln sich aktiv weiter. Hive erfordert jedoch viel mehr Aufmerksamkeit und Sorgfalt: Um das Skript korrekt auszuführen, müssen Sie häufig ein Dutzend Umgebungsvariablen festlegen, die JDBC-Schnittstelle in Form von HiveServer2 funktioniert offen gesagt schlecht, und die aufgetretenen Fehler haben wenig mit der eigentlichen Ursache des Problems zu tun. Impala ist auch unvollkommen, aber insgesamt viel schöner und vorhersehbarer.


    NoSQL: HBase



    Trotz der Popularität von SQL Analytics-Lösungen, die auf Hadoop basieren, müssen Sie sich manchmal noch mit anderen Problemen auseinandersetzen, für die NoSQL-Datenbanken besser geeignet sind. Darüber hinaus funktionieren sowohl Hive als auch Impala besser mit großen Datenpaketen, und das Lesen und Schreiben einzelner Zeilen bedeutet fast immer mehr Overhead (beachten Sie, dass die Datenblockgröße 64 MB beträgt).

    Und hier kommt HBase zur Rettung. HBase ist ein verteiltes versioniertes nicht relationales DBMS, das das zufällige Lesen und Schreiben effektiv unterstützt. Hier können Sie feststellen, dass die Tabellen in HBase dreidimensional sind (ein Zeichenfolgenschlüssel, ein Zeitstempel und ein qualifizierter Spaltenname), dass die Schlüssel in lexikografischer Reihenfolge gespeichert sind und vieles mehr, aber das Wichtigste ist, dass Sie mit HBase in Echtzeit mit einzelnen Datensätzen arbeiten können . Dies ist eine wichtige Ergänzung der Hadoop-Infrastruktur. Stellen Sie sich zum Beispiel vor, Sie müssen Informationen über Benutzer speichern: deren Profile und ein Protokoll aller Aktionen. Das Aktionsprotokoll ist ein klassisches Beispiel für Analysedaten: Aktionen, d.h. Tatsächlich werden Ereignisse einmal aufgezeichnet und nie wieder geändert. Aktionen werden chargenweise und in bestimmten Intervallen analysiert, beispielsweise einmal am Tag. Profile sind jedoch eine ganz andere Sache. Die Profile müssen ständig und in Echtzeit aktualisiert werden. Daher verwenden wir für das Ereignisprotokoll Hive / Impala und für Profile HBase.

    Bei alledem bietet HBase aufgrund seiner HDFS-Basis zuverlässigen Speicher. Stoppen Sie, aber haben wir nicht gerade gesagt, dass Direktzugriffsoperationen auf diesem Dateisystem aufgrund der großen Datenblockgröße nicht effizient sind? Das ist richtig, und das ist HBases großer Trick. Tatsächlich werden der sortierten Struktur im Speicher zuerst neue Datensätze hinzugefügt, und erst wenn diese Struktur eine bestimmte Größe erreicht, werden sie auf die Festplatte geschrieben. Die Konsistenz wird auf Kosten von Write-Ahead-Log (WAL) gewährleistet, das direkt auf die Festplatte geschrieben wird, jedoch keine Unterstützung für sortierte Schlüssel erfordert. Lesen Sie mehr dazu im Cloudera-Blog .

    Oh ja, Sie können HBase-Tabellen direkt von Hive und Impala aus abfragen.

    Datenimport: Kafka





    In der Regel durchläuft der Import von Daten in Hadoop mehrere Entwicklungsstufen. Zunächst entscheidet das Team, dass normale Textdateien ausreichen. Jeder kann CSV-Dateien schreiben und lesen, es sollte keine Probleme geben! Dann tauchen irgendwo nicht druckbare und nicht standardmäßige Zeichen auf (was für ein Bastard hat sie eingefügt!), Das Problem des Entkommens von Zeichenfolgen usw., und Sie müssen zu Binärformaten oder zumindest zu einem überzähligen JSON wechseln. Dann erscheinen zwei Dutzend Clients (extern oder intern), und es ist nicht für jedermann bequem, Dateien an HDFS zu senden. Zu diesem Zeitpunkt wird RabbitMQ angezeigt. Aber er hält nicht lange durch, weil sich plötzlich alle daran erinnern, dass das Kaninchen versucht, alles in seinem Gedächtnis zu behalten, und es gibt viele Daten, und es ist nicht immer möglich, sie schnell zu sammeln.

    Und dann stolpert jemand über Apache Kafka- Ein verteiltes Nachrichtensystem mit hoher Bandbreite. Im Gegensatz zur HDFS-Schnittstelle bietet Kafka eine einfache und vertraute Nachrichtenschnittstelle. Im Gegensatz zu RabbitMQ schreibt es Nachrichten sofort auf die Festplatte und speichert dort einen konfigurierten Zeitraum (z. B. zwei Wochen), in dem Sie Daten sammeln können. Kafka ist einfach zu skalieren und kann theoretisch jede Datenmenge ausdrücken.

    All dieses schöne Bild bricht zusammen, wenn Sie das System in der Praxis einsetzen. Das Erste, woran man sich erinnern muss, wenn man sich mit Kafka befasst, ist, dass jeder lügt. Besonders die Dokumentation. Besonders offiziell. Wenn die Autoren "wir haben X unterstützt" schreiben, bedeutet dies oft "wir möchten X unterstützt haben" oder "in zukünftigen Versionen planen wir X zu unterstützen". Wenn es heißt "der Server garantiert Y", dann bedeutet es höchstwahrscheinlich "der Server garantiert Y, aber nur für Client Z". Es gab Fälle, in denen einer in der Dokumentation, ein anderer im Kommentar zur Funktion und der dritte im Code selbst geschrieben war.

    Kafka ändert die Hauptschnittstellen auch in Nebenversionen und kann den Übergang von 0.8.x auf 0.9 schon lange nicht mehr schaffen. Der Quellcode selbst, sowohl strukturell als auch stilistisch, ist klar unter dem Einfluss des berühmten Schriftstellers geschrieben, der diesem Monster den Namen gab.

    Und trotz all dieser Probleme bleibt Kafka das einzige Projekt auf Architekturebene, das das Problem des Imports einer großen Datenmenge löst. Wenn Sie sich dennoch für eine Kontaktaufnahme mit diesem System entscheiden, sollten Sie sich an folgende Punkte erinnern:
    • Kafka lügt nicht über die Zuverlässigkeit - wenn Nachrichten den Server erreichen, bleiben sie für die angegebene Zeit dort. Wenn keine Daten vorhanden sind, überprüfen Sie Ihren Code.
    • Verbrauchergruppen funktionieren nicht: Unabhängig von der Konfiguration werden alle Nachrichten von der Partition an alle verbundenen Verbraucher gesendet.
    • Der Server speichert keine Offsets für Benutzer. Tatsächlich kann der Server verbundene Verbraucher im Allgemeinen nicht identifizieren.


    Ein einfaches Rezept, zu dem wir nach und nach gekommen sind, besteht darin, einen Consumer pro Partitionszeile (Thema, in der Kafka-Terminologie) zu starten und die Schichten manuell zu steuern.

    Stream-Verarbeitung: Spark-Streaming



    Wenn Sie bis zu diesem Absatz gelesen haben, dann sind Sie wahrscheinlich interessiert. Und wenn Sie interessiert sind, dann haben Sie wahrscheinlich von Lambda-Architektur gehört , aber für den Fall, ich werde es wiederholen. Bei der Lambda-Architektur wird die Berechnungspipeline für die Stapel- und Streaming-Datenverarbeitung dupliziert. Die Stapelverarbeitung beginnt in regelmäßigen Abständen (z. B. gestern) und verwendet die vollständigsten und genauesten Daten. Im Gegensatz dazu führt die Stream-Verarbeitung zu Echtzeitberechnungen, garantiert jedoch keine Genauigkeit. Dies kann beispielsweise hilfreich sein, wenn Sie eine Werbeaktion gestartet haben und deren Wirksamkeit stündlich verfolgen möchten. Eine Verzögerung von einem Tag ist hier nicht akzeptabel, aber der Verlust von ein paar Prozent der Ereignisse ist nicht kritisch. Spark Streaming

    ist für das Streaming von Daten im Hadoop-Ökosystem verantwortlich.. Streaming von der Box kann Daten von Kafka, ZeroMQ, Socket, Twitter usw. aufnehmen. Dem Entwickler steht eine praktische Schnittstelle in Form von DStream zur Verfügung - eine Sammlung kleiner RDDs, die über einen festgelegten Zeitraum (z. B. in 30 Sekunden oder 5 Minuten) aus einem Stream gesammelt wurden ) Alle Brötchen der normalen RDD bleiben erhalten.

    Maschinelles Lernen





    Das obige Bild drückt den Zustand vieler Unternehmen perfekt aus: Jeder weiß, dass Big Data gut ist, aber nur wenige Menschen verstehen wirklich, wie man damit umgeht. Und Sie müssen vor allem zwei Dinge mit ihnen tun - sich in Wissen übersetzen (lesen Sie, wie: bei Entscheidungen verwenden) und die Algorithmen verbessern. Die Analyse-Tools helfen bereits beim ersten, und beim zweiten geht es um maschinelles Lernen. Hadoop hat dafür zwei große Projekte:

    Mahout- Die erste große Bibliothek, die viele gängige Algorithmen mit MapReduce implementiert. Es enthält Algorithmen für Clustering, kollaboratives Filtern, zufällige Bäume sowie verschiedene Grundelemente zum Faktorisieren von Matrizen. Anfang dieses Jahres beschlossen die Organisatoren, alles auf den Apache Spark-Rechenkern zu übertragen, der iterative Algorithmen wesentlich besser unterstützt (versuchen Sie, mit dem Standard-MapReduce 30 Iterationen des Gradientenabfalls durch die Festplatte zu fahren!).

    MLlib. Im Gegensatz zu Mahout, der versucht, seine Algorithmen auf den neuen Kernel zu portieren, ist MLlib zunächst ein Spark-Teilprojekt. Es umfasst: grundlegende Statistiken, lineare und logistische Regression, SVM, k-means, SVD und PCA sowie Optimierungsprimitive wie SGD und L-BFGS. Die Scala-Oberfläche verwendet Breeze für die lineare Algebra, die Python-Oberfläche ist NumPy. Das Projekt wird aktiv weiterentwickelt und mit jedem Release wird die Funktionalität erheblich erweitert.

    Datenformate: Parkett, ORC, Thrift, Avro



    Wenn Sie sich dazu entschließen, Hadoop in vollem Umfang zu nutzen, wird es nicht schaden, sich mit den wichtigsten Formaten der Datenspeicherung und -übertragung vertraut zu machen.

    Parkett ist ein Säulenformat, das für die Speicherung komplexer Strukturen und eine effiziente Komprimierung optimiert ist. Es wurde ursprünglich auf Twitter entwickelt und ist jetzt eines der Hauptformate in der Hadoop-Infrastruktur (insbesondere wird es von Spark und Impala aktiv unterstützt).

    ORC ist das neue optimierte Speicherformat für Hive. Hier sehen wir wieder die Konfrontation zwischen Cloudera c Impala und Parkett und Hortonworks mit Hive und ORC. Am interessantesten ist ein Vergleich der Leistung von Lösungen: Auf dem Cloudera-Blog gewinnt Impala immer mit einer signifikanten Gewinnspanne, und auf dem Hortonworks-Blog gewinnt Hive, wie Sie sich vorstellen können, ohne eine geringere Gewinnspanne.

    Sparsamkeit- Ein effektives, aber nicht sehr praktisches Übertragungsformat für Binärdaten. Das Arbeiten mit diesem Format umfasst das Definieren eines Datenschemas und das Generieren des entsprechenden Clientcodes in der gewünschten Sprache, was nicht immer möglich ist. Vor kurzem haben sie begonnen, es abzulehnen, aber viele Dienste nutzen es immer noch.

    Avro - im Grunde genommen als Ersatz für Thrift positioniert: Es erfordert keine Codegenerierung, kann ein Schema zusammen mit Daten übertragen oder sogar mit dynamisch typisierten Objekten arbeiten.

    Sonstiges: ZooKeeper, Hue, Flume, Sqoop, Oozie, Askaban



    Und zum Schluss noch kurz über andere nützliche und nutzlose Projekte.

    ZooKeeper ist das primäre Koordinierungswerkzeug für alle Elemente der Hadoop-Infrastruktur. Es wird am häufigsten als Konfigurationsdienst verwendet, obwohl seine Funktionen viel breiter sind. Einfach, bequem, zuverlässig.

    Hue ist eine webbasierte Schnittstelle zu Hadoop-Diensten, die Teil von Cloudera Manager ist. Es funktioniert schlecht, mit Fehlern und Laune. Geeignet für die Anzeige an nicht-technische Spezialisten, aber für ernsthafte Arbeiten ist es besser, Konsolenanaloga zu verwenden.

    Flume ist ein Dienst zum Organisieren von Datenflüssen. Sie können ihn beispielsweise so konfigurieren, dass er Nachrichten von syslog empfängt, aggregiert und automatisch in ein Verzeichnis auf HDFS ablegt. Leider erfordert es viel manuelle Konfiguration von Threads und ständige Erweiterung der eigenen Java-Klassen.

    Sqoop ist ein Dienstprogramm zum schnellen Kopieren von Daten zwischen Hadoop und RDBMS. Theoretisch schnell. In der Praxis stellte sich heraus, dass Sqoop 1 im Wesentlichen Single-Threaded und langsam war, und Sqoop 2 funktionierte zum Zeitpunkt des letzten Tests einfach nicht.

    Oozie ist ein Task Flow Scheduler. Ursprünglich entworfen, um einzelne MapReduce-Jobs in einer einzigen Pipeline zu kombinieren und nach einem Zeitplan auszuführen. Darüber hinaus kann es Hive-, Java- und Konsolenaktionen ausführen, aber im Kontext von Spark, Impala usw. sieht diese Liste ziemlich nutzlos aus. Sehr zerbrechlich, verwirrend und fast unmöglich zu debuggen.

    Askaban- Ein vollkommen geeigneter Ersatz für Oozie. Es ist Teil der Hadoop-Infrastruktur von LinkedIn. Es werden verschiedene Arten von Aktionen unterstützt. Die Hauptaktion ist der Konsolenbefehl (und was sonst noch benötigt wird), der geplante Start, Anwendungsprotokolle, Benachrichtigungen über abgebrochene Arbeiten usw. Die Minuspunkte sind eine gewisse Feuchtigkeit und eine nicht immer klare Oberfläche (versuchen Sie zu erraten, dass Sie nicht arbeiten müssen) über die Benutzeroberfläche erstellen und als ZIP-Archiv mit Textdateien hochladen).

    Das ist alles. Vielen Dank an alle, jeder ist frei.

    Jetzt auch beliebt: