Schnelles Datenrezept basierend auf Big Data-Lösung

    Quelle: http://searchsoa.techtarget.com/photostory/2240203721/Five-potential-big-data-problems-and-solutions/5/Velocity-Catch-it-Capture-fast-moving-data-and-use- es

    Bildquelle

    Bei der Diskussion der Arbeit mit Big Data werden am häufigsten die Probleme der Analyse und der Organisation des Computerprozesses angesprochen. Meine Kollegen und ich hatten die Gelegenheit, an Aufgaben anderer Art zu arbeiten - den Zugriff auf Daten zu beschleunigen und die Belastung des Speichersystems auszugleichen. Im Folgenden werde ich darüber sprechen, wie wir damit umgegangen sind.

    Wir haben unser „Rezept“ aus vorhandenen „Zutaten“ gemacht: einem Stück Eisen und einem Software-Tool. Zunächst möchte ich Ihnen erläutern, wie wir uns der Aufgabe gestellt haben, den Zugang zu beschleunigen. Dann betrachten wir ein Stück Eisen und ein Software-Tool. Lassen Sie uns abschließend zwei Probleme ansprechen, denen wir uns im Laufe der Arbeit stellen mussten.

    Beginnen wir mit einer Beschreibung des Problems.
    In der Umgebung, die wir optimieren mussten, wird horizontal skalierbarer Netzwerkspeicher zum Speichern von Daten verwendet . Wenn Sie mit diesen Wörtern nicht vertraut sind, haben Sie keine Angst, ich werde jetzt alles erklären :) Ein

    horizontal skalierbares Speichersystem (auf Englisch - Scale-Out-NAS) ist ein Clustersystem, das aus vielen Knoten besteht, die durch ein internes Hochgeschwindigkeitsnetzwerk miteinander verbunden sind. Alle Knoten stehen dem Benutzer einzeln über ein externes Netzwerk, beispielsweise über das Internet, zur Verfügung.

    Scale-Out-NAS

    Das Diagramm zeigt nur drei Knoten. Tatsächlich kann es noch viel mehr geben. Das ist das Schöne an Scale-Out-Systemen. Sobald Sie zusätzlichen Speicherplatz oder zusätzliche Leistung benötigen, fügen Sie dem Cluster einfach neue Knoten hinzu.

    Ich sagte oben, dass jeder der Cluster-Knoten separat verfügbar ist. Es versteht sich, dass Sie mit jedem Knoten eine separate Netzwerkverbindung (oder sogar mehrere) herstellen können. Unabhängig davon, über welchen Knoten der Benutzer eine Verbindung zum Cluster herstellt, wird ein einziges Dateisystem angezeigt.

    Im Scale-Out-Rechenzentrum sieht der Speicher ungefähr so ​​aus (Clusterknoten sind in eleganten Racks gestapelt).

    Isilon


    In unserem Fall wurde nur das abgebildete System zur Datenspeicherung verwendet: Isilon von EMC. Es wurde aufgrund seiner nahezu unbegrenzten Skalierbarkeit ausgewählt: Ein Cluster kann bis zu 30 Petabyte Festplattenspeicher bereitstellen. Und von außen wird der gesamte Speicherplatz als ein einziges Dateisystem zur Verfügung stehen.

    Das Problem, das wir lösen mussten, hängt mit einem bestimmten Modell der Verwendung von Isilon zusammen. In einer Umgebung, die wir optimieren, wird auf Daten über ein Datenverwaltungssystem zugegriffen. Ich werde hier nicht auf Details eingehen Dies ist ein eigenständiges großes Thema. Ich werde nur auf die Konsequenzen dieses Ansatzes eingehen. Außerdem werde ich das Gesamtbild stark vereinfachen, um mich nur auf das zu konzentrieren, was für die Zukunft am wichtigsten ist.

    Vereinfachtes Bild des Zugriff auf die Daten in unserer Umwelt ist wie folgt:

    Bild

    Viele Kunden Datenmanagementsystem wenden , die auf einem dedizierten Server ausgeführt wird . Kunden schreiben / lesen keine Daten direkt von Isilon. Dies erfolgt nur über ein Steuerungssystem, das möglicherweise Daten manipulieren kann, z. B. verschlüsseln.

    In dem Diagramm kommuniziert der Steuersystemserver nur mit einem Knoten des Datenspeichersystems (SHD). Und das hatten wir wirklich. Der Strom zahlreicher Client-Anforderungen ging an einen einzelnen Speicherknoten. Es stellt sich heraus, dass die Belastung des Clusters sehr unausgeglichen sein kann, wenn die anderen Knoten nicht mit anderen Servern oder Clients belastet sind.

    Isilon bietet im Allgemeinen hervorragende automatische Lastausgleichsfunktionen. Wenn beispielsweise ein Server versucht, eine Verbindung mit Isilon herzustellen, wird er von dem Knoten bedient, der gerade am wenigsten ausgelastet ist. Um einen solchen Ausgleich zu ermöglichen, ist es natürlich notwendig, Isilon entsprechend zu konfigurieren und zu verwenden.

    Ein automatischer Lastausgleich auf Speichersystemen ist jedoch nur auf der Ebene der Netzwerkverbindungen möglich. Wenn sich beispielsweise auf einem Knoten des Clusters eine große Anzahl von „gefräßigen“ Verbindungen ansammelt, kann das Speichersystem diese auf mehr freie Knoten „verteilen“. Bei der einzigen geladenen Verbindung ist das Speichersystem jedoch stromlos.

    Nun ein paar Worte darüber, was die einzige hochgeladene Verbindung ist, die wir entladen mussten. Dies ist nur ein NFS-Mount. Wenn Sie nicht mit NFS vertraut sind, werfen Sie einen Blick unter den Spoiler.
    Nfs
    Unix hat das Konzept eines virtuellen Dateisystems. Dies ist eine solche verallgemeinerte Schnittstelle für den Zugriff auf Informationen. Über diesen können Sie bereits auf bestimmte Dateisysteme zugreifen. Tatsächlich werden die Dateisysteme verschiedener Geräte einfach in das lokale Dateisystem integriert und scheinen für den Benutzer ein Teil davon zu sein. Auf der unteren Ebene kann ein Disketten-Dateisystem oder Remote-Dateisysteme verwendet werden, auf die über das Netzwerk zugegriffen werden kann. Ein Beispiel für ein solches Remote-Dateisystem ist NFS.

    Nfs


    Jetzt, da das Problem klar ist, ist es Zeit darüber zu sprechen, wie wir es gelöst haben.

    Wie ich bereits sagte, hat uns ein Stück Hardware und eine Softwarelösung geholfen, die für die Arbeit mit Big Data entwickelt wurden. Das Stück Eisen ist das gleiche Isilon. Und wir hatten großes Glück, dass vor mehr als zwei Jahren eine interessante Immobilie dazugekommen ist. Ohne dies wäre der Umgang mit dem Lastausgleich viel schwieriger. Die betreffende Eigenschaft unterstützt das HDFS-Protokoll. Die zweite Zutat unseres Rezepts basiert darauf.

    Wenn Sie mit dieser Abkürzung und der technischen Seite des Problems nicht vertraut sind, gibt es einen Spoiler für Welkams.
    HDFS
    HDFS ist ein verteiltes Dateisystem, das Teil von Hadoop ist, einer Plattform zum Entwickeln und Ausführen verteilter Programme. Hadoop wird mittlerweile häufig für die Big-Data-Analyse eingesetzt.

    Eine klassische Hadoop-basierte Computerlösung ist ein Cluster von Rechenknoten und Datenknoten. Rechenknoten führen verteiltes Rechnen durch und laden / speichern Informationen von Datenknoten. Beide Knotentypen sind wahrscheinlich logische Komponenten eines Clusters als physische. Beispielsweise können auf einem physischen Server ein Rechenknoten und mehrere Datenknoten bereitgestellt werden. Obwohl die typischste Situation darin besteht, dass zwei Knoten auf derselben physischen Maschine ausgeführt werden, einer von jedem Typ.

    Die Kommunikation von Rechenknoten mit Datenknoten erfolgt nur gemäß dem HDFS-Protokoll. Der Vermittler dieser Kommunikation ist das HDFS-Dateisystemverzeichnis, das im Cluster durch einen anderen Knotentyp - den Knotennamen - dargestellt wird. Wenn wir Nebensätze aufgeben, können wir davon ausgehen, dass es nur einen Verzeichnisknoten im Cluster gibt.

    Datenknoten speichern Datenblöcke. In dem Verzeichnis sind unter anderem Informationen darüber gespeichert, wie die Blöcke, die sich auf bestimmte Dateien beziehen, über Datenknoten verteilt sind.

    Der Vorgang zum Platzieren einer Datei in HDFS von der Clientseite sieht ungefähr so ​​aus:
    • Der HDFS-Client fordert das Verzeichnis zum Erstellen einer Datei an
    • Wenn alles in Ordnung ist, signalisiert das Verzeichnis, dass die Datei erstellt wurde
    • Wenn der Client bereit ist, den nächsten Block dieser Datei zu schreiben, wendet er sich erneut dem Verzeichnis zu und fordert die Adresse des Datenknotens an, an den der Block gesendet werden soll
    • Das Verzeichnis gibt die entsprechende Adresse zurück
    • Der Client sendet einen Block an diese Adresse
    • Die erfolgreiche Aufnahme wird bestätigt
    • Wenn der Client alle Blöcke gesendet hat, fordert er möglicherweise das Schließen der Datei an


    Ursprünglich wurde die HDFS-Schnittstelle in Isilon nicht unterstützt, sodass meine Kollegen und ich sie verwenden konnten, um die Speicherauslastung auszugleichen. Wenn Sie interessiert sind, warum HDFS in Isilon implementiert ist, fahren Sie mit dem nächsten Spoiler fort.
    Native HDFS-Unterstützung
    Bei Isilon wurde die HDFS-Schnittstelle unterstützt, sodass der Speicher direkt mit Hadoop verwendet werden kann. Was hat das gebracht? Siehe die folgenden Abbildungen. Das erste zeigt eines der typischen Szenarien für die Organisation eines Hadoop-Clusters (nicht alle im Cluster vorhandenen Knotentypen werden angezeigt).

    Klassische Hadoop-Verwendung


    Worker Node ist ein Server, der die Funktionen von Computing und Datenspeicherung kombiniert. Datenknoten ist ein Server, der nur Daten speichert. Neben allen Servern werden "dicke" Festplatten angezeigt, die Daten unter der Kontrolle von HDFS hosten.

    Warum ist der Speicher in der Abbildung dargestellt? Es ist ein Data Warehouse für Lebensmittel. Es speichert Dateien, die während des täglichen Geschäftsbetriebs in die Produktumgebung gelangen. In der Regel werden diese Dateien mithilfe eines weit verbreiteten Protokolls an das Speichersystem übertragen. Zum Beispiel NFS. Wenn wir sie analysieren möchten, müssen wir die Dateien (do staging) in den Hadoup-Cluster kopieren. Wenn es um viele Terabyte geht, kann das Staging viele Stunden dauern.

    Das zweite Bild zeigt, was sich ändert, wenn die Umgebung Speichersysteme verwendet, die HDFS unterstützen. Die Server verschwinden große Festplatten. Darüber hinaus werden Server aus dem Cluster gelöscht, die ausschließlich für den Zugriff auf Daten zuständig waren. Alle Festplattenressourcen werden jetzt in einem einzigen Speichersystem konsolidiert. Es besteht keine Notwendigkeit, eine Inszenierung durchzuführen. Analytische Berechnungen können jetzt direkt auf Produktkopien von Dateien durchgeführt werden.

    Native HDFS-Unterstützung durch Storage System


    Daten können weiterhin mit dem NFS-Protokoll gespeichert werden. Und lesen Sie mit dem HDFS-Protokoll. Wenn die Berechnungen aus irgendeinem Grund nicht für Produktkopien von Dateien durchgeführt werden können, können die Daten in dasselbe Speichersystem kopiert werden. Ich werde nicht alle Reize dieses Ansatzes auflisten. Es gibt viele von ihnen, und in englischsprachigen Blogs und Newsfeeds wurde viel darüber geschrieben.

    Besser, ich sage ein paar Worte darüber, wie die Arbeit mit der Isilon HDFS-Oberfläche vom Client aus aussieht. Jeder der Clusterknoten kann als HDFS-Datenknoten fungieren (sofern dies nicht durch die Einstellungen verhindert wird). Was aber interessanter ist und was nicht im "echten" HDFS steckt, kann jeder Knoten auch als Verzeichnis (Namensknoten) fungieren. Es ist zu beachten, dass Isilon HDFS aus Sicht der "Interna" fast nichts mit der Hadoup-Implementierung von HDFS zu tun hat. Das Isilon HDFS-Dateisystem wird nur auf der Schnittstellenebene dupliziert. Die gesamte Innenküche ist originell und sehr effizient. Zum Schutz von Daten werden beispielsweise eigene kostengünstige und schnelle Isilon-Technologien verwendet, im Gegensatz zum Kopieren entlang einer Kette von Datenknoten, die im „Standard“ -HDFS implementiert ist.

    Lassen Sie uns nun sehen, wie HDFS uns geholfen hat, die Last auf Isilon auszugleichen. Kehren wir zum Beispiel der Aufnahme einer Datei in HDFS zurück, das oben im Spoiler untersucht wurde. Was haben wir im Fall von Isilon?

    Um der Datei einen weiteren Block hinzuzufügen, muss der Client in das Verzeichnis wechseln, um die Adresse des Datenknotens zu ermitteln, den dieser Block erhalten wird. In Isilon für jedermannAuf den Clusterknoten kann als Verzeichnis zugegriffen werden. Dies erfolgt entweder direkt über die Knotenadresse oder über einen speziellen Dienst, der sich mit dem Ausgleich von Verbindungen befasst. Die Adresse, die das Verzeichnis zurückgibt, entspricht derzeit dem am wenigsten belasteten Knoten. Es stellt sich heraus, dass Sie beim Senden von Blöcken an HDFS diese immer an die meisten freien Knoten übertragen. Das heißt Sie haben automatisch ein sehr feines, granulares Balancing: auf der Ebene einzelner elementarer Operationen, nicht wie bei NFS.

    Als wir dies bemerkten, entschieden wir uns, HDFS als eigenständige Schnittstelle zu verwenden. "Stand alone" bedeutet hier, dass die Schnittstelle isoliert von Hadoop verwendet wird. Vielleicht ist dies das erste Beispiel dieser Art. Zumindest habe ich bisher nicht gehört, dass HDFS getrennt von der Familie der Khadupov- oder okolokhadupovskih-Produkte verwendet werden sollte.

    Infolgedessen haben wir HDFS an unser Datenmanagementsystem „angebunden“. Die meisten Probleme, die wir gleichzeitig lösen mussten, lagen auf der Seite des Managementsystems. Ich werde hier nicht darüber sprechen, weil Dies ist ein eigenständiges großes Thema, das zusätzlich zu den Besonderheiten eines bestimmten Systems verknüpft ist. Ich werde jedoch auf zwei kleine Probleme eingehen, die mit der Verwendung von HDFS als eigenständiges Dateisystem verbunden sind.

    Das erste Problem ist, dass HDFS keinem separaten Produkt zugeordnet ist. Es wird als Teil von Hadoop vertrieben. Daher gibt es keinen „HDFS-Standard“ oder keine „HDFS-Spezifikation“. Im Wesentlichen existiert HDFS als Referenzimplementierung von Apache. Wenn Sie also die Details der Implementierung kennen möchten (z. B. die Richtlinien zum Erfassen und Freigeben von Leases), müssen Sie ein Reverse Engineering durchführen, indem Sie entweder den Quellcode lesen oder nach Personen suchen, die Ihnen dies bereits angetan haben.

    Das zweite Problem besteht darin, eine Bibliothek auf niedriger Ebene für HDFS zu finden.

    Nach einer oberflächlichen Suche im Netzwerk scheint es viele solcher Bibliotheken zu geben. In Wirklichkeit gibt es jedoch eine Apache-Referenz-Java-Bibliothek. Die meisten anderen Bibliotheken für C ++, C, Python und andere Sprachen sind einfach Wrapper um die Java-Bibliothek.

    Wir konnten die Java-Bibliothek nicht für unser C ++ - Projekt verwenden. Auch mit dem passenden Wrapper. Erstens war es eine inakzeptable Luxus-Java-Maschine, ein Datenverwaltungssystem zusammen mit unserem kleinen HDFS-Modul auf den Server zu ziehen. Zweitens gibt es im Internet einige Beschwerden über die Leistung von Java-Bibliotheken.

    Die Situation war so, dass wir, wenn wir keine fertige C ++ - Bibliothek für HDFS finden würden, unsere eigene schreiben müssten. Und dies ist zusätzliche Zeit für das Reverse Engineering. Zum Glück haben wir die Bibliothek gefunden.

    Letztes Jahr (und vielleicht sogar früher) begannen die ersten nativen Bibliotheken für HDFS zu erscheinen. Im Moment sind mir zwei davon bekannt: für C und Python. Hadoofus und Schlangenbiss . Vielleicht ist etwas anderes aufgetaucht. Ich habe die Suche lange nicht wiederholt.

    Für unser Projekt haben wir Hadoofus genommen. Während der gesamten Nutzungsdauer haben wir nur zwei Fehler darin gefunden. Das erste - einfache - führte dazu, dass die Bibliothek nicht vom C ++ - Compiler erstellt wurde. Der zweite ist unangenehmer: Deadlock bei Verwendung mit mehreren Threads. Es erschien äußerst selten, was die Analyse des Problems erschwerte. Beide Fehler sind derzeit behoben. Obwohl wir immer noch daran arbeiten, das Fehlen von Deadlocks zu testen.

    Wir mussten keine anderen Probleme im Zusammenhang mit der Verwendung von HDFS lösen.

    Im Allgemeinen sollte beachtet werden, dass das Schreiben eines HDFS-Clients für Isilon einfacher ist als das Schreiben eines Clients für "Standard" -HDFS. Zweifellos funktioniert jeder „Standard“ -HDFS-Client problemlos mit Isilon. Das Gegenteil muss nicht wahr sein. Wenn Sie einen HDFS-Client exklusiv für Isilon schreiben, wird die Aufgabe vereinfacht.

    Betrachten Sie ein Beispiel. Angenommen, Sie müssen einen Datenblock mit HDFS lesen. Dazu wechselt der Client in das Verzeichnis und fragt, von welchen Datenknoten dieser Block entnommen werden kann. Im Allgemeinen gibt der Katalog als Antwort auf eine solche Anforderung die Koordinaten nicht eines Knotens, sondern mehrerer zurück, auf denen Kopien dieses Blocks gespeichert sind. Wenn der Client keine Antwort vom ersten Knoten in der Liste erhält (z. B. dieser Knoten ist ausgefallen), wechselt er zum zweiten, dritten usw., bis ein Knoten gefunden wird, der antwortet.

    Im Fall von Isilon müssen Sie nicht über solche Szenarien nachdenken. Isilon gibt immer die Adresse eines einzelnen Knotens zurück, der Ihnen sicherlich weiterhelfen wird. Dies bedeutet nicht, dass die Isilon-Knoten nicht „fallen“ können. Am Ende können Sie den Knoten zumindest mit einer Axt deaktivieren. Wenn Isilon jedoch aus irgendeinem Grund einen Knoten verliert, gibt er seine Adresse einfach an einen anderen - überlebenden - Knoten im Cluster weiter. Das Fehlertoleranzszenario ist also bereits weitgehend in die Hardware eingebettet und muss nicht vollständig in die Software implementiert werden.

    Insofern kann die Geschichte über unser „Rezept“ als vollständig angesehen werden. Es bleiben nur ein paar Worte zu den Ergebnissen.

    Der amortisierte Produktivitätszuwachs im Vergleich zur Arbeit mit NFS liegt in unserer Umgebung bei etwa 25%. Diese Zahl wurde durch Vergleichen von "uns" erhalten: In beiden Fällen wurde die Leistung mit demselben Gerät und derselben Software gemessen. Der einzige Unterschied war das Modul für den Zugriff auf das Dateisystem.

    Wenn wir nur Leseoperationen berücksichtigen, wird beim Herunterladen jeder einzelnen Datei ein Zuwachs von 25% festgestellt. Bei der Datenerfassung kann nur von einer amortisierten Verstärkung gesprochen werden. Das Schreiben jeder einzelnen Datei ist langsamer als über NFS. Dafür gibt es zwei Gründe:
    • HDFS unterstützt keine Multithread-Dateiaufzeichnung
    • Unser Datenverwaltungssystem verfügt über Funktionen, die aufgrund der oben genannten Einschränkung von HDFS keine schnelle Aufzeichnung einer einzelnen Datei ermöglichen

    Wenn die Dateiaufzeichnung im Datenverwaltungssystem optimaler organisiert wäre, könnte ein 25% iger Zuwachs bei der Aufzeichnung für eine separate Übertragung erwartet werden.

    Ich stelle fest, dass uns das Verlangsamen des Uploads der einzelnen Dateien nicht sonderlich gestört hat, weil Der Durchsatz bei Lastspitzen ist für uns am wichtigsten. Darüber hinaus ist das Lesen von Daten in ähnlichen Umgebungen weitaus häufiger als das Schreiben.

    Abschließend werde ich eine Illustration geben, die eine Vorstellung davon gibt, wie sich die Belastung von Isilon ändert, wenn HDFS als Schnittstelle verwendet wird.

    Der Screenshot zeigt die Clusterlast beim Übertragen einer 2-GB-Datei auf beiden Seiten (die Datei wurde 14-mal nacheinander heruntergeladen und heruntergeladen). Der blaue Hochpeak links wird beim Durcharbeiten von NFS erhalten. Das Lesen und Schreiben erfolgt über ein einzelnes Mount, und die gesamte Last wird in diesem Fall von einem Clusterknoten getragen. Die mehrfarbigen niedrigen Peaks rechts entsprechen der Arbeit mit HDFS. Es ist zu erkennen, dass die Last jetzt auf alle Knoten im Cluster verteilt ist (3 Teile).

    Isilon-Arbeitsbelastung


    Das ist wahrscheinlich alles.

    Lassen Sie immer alles schnell und zuverlässig für Sie arbeiten!

    Jetzt auch beliebt: