Der Markt für verteiltes Computing und Big Data, so , wächst jährlich um 18-19 %. Das bedeutet, dass die Frage der Auswahl von Software für diese Zwecke weiterhin relevant bleibt. In diesem Beitrag beginnen wir damit, warum wir verteiltes Computing benötigen, gehen detaillierter auf die Wahl der Software ein, sprechen über die Verwendung von Hadoop mit Cloudera und schließlich sprechen wir über die Wahl der Hardware und wie sie sich auf die Leistung auswirkt auf veschiedenen Wegen.
Warum brauchen wir verteiltes Computing im normalen Geschäftsleben? Alles ist einfach und kompliziert zugleich. Einfach – weil wir in den meisten Fällen relativ einfache Berechnungen pro Informationseinheit durchführen. Schwierig – weil es viele solcher Informationen gibt. Sehr viel. Folglich muss man es tun . Somit sind die Anwendungsfälle recht universell: Berechnungen können überall dort angewendet werden, wo eine große Anzahl von Metriken auf einem noch größeren Datenfeld berücksichtigt werden muss.
Ein aktuelles Beispiel: Dodo Pizza Basierend auf einer Analyse der Kundenbestellungsbasis, dass Benutzer bei der Auswahl einer Pizza mit willkürlichen Belägen in der Regel mit nur sechs Grundzutatensätzen plus ein paar zufälligen Zutaten operieren. Dementsprechend hat die Pizzeria ihre Einkäufe angepasst. Darüber hinaus konnten den Nutzern bereits bei der Bestellung angebotene Zusatzprodukte besser empfohlen werden, was den Gewinn steigerte.
Ein anderes Beispiel: Dank der neuen Handelsware konnte H&M das Sortiment in einzelnen Filialen um 40 % reduzieren und gleichzeitig das Umsatzniveau halten. Dies wurde durch den Ausschluss schlecht abverkaufter Positionen erreicht und die Saisonalität wurde bei den Berechnungen berücksichtigt.
Werkzeugauswahl
Der Industriestandard für diese Art der Datenverarbeitung ist Hadoop. Warum? Denn Hadoop ist ein hervorragendes, gut dokumentiertes Framework (derselbe Habr veröffentlicht viele ausführliche Artikel zu diesem Thema), das von einer ganzen Reihe von Dienstprogrammen und Bibliotheken begleitet wird. Sie können große Mengen strukturierter und unstrukturierter Daten als Eingabe übermitteln, und das System selbst verteilt sie auf die Rechenleistung. Darüber hinaus können dieselben Kapazitäten jederzeit erhöht oder deaktiviert werden – dieselbe horizontale Skalierbarkeit in Aktion.
Im Jahr 2017 wurde das einflussreiche Beratungsunternehmen Gartner dass Hadoop bald veraltet sein wird. Der Grund ist eher banal: Analysten gehen davon aus, dass Unternehmen massiv in die Cloud migrieren werden, da sie dort nach der Nutzung der Rechenleistung bezahlen können. Der zweite wichtige Faktor, der Hadoop angeblich „begraben“ kann, ist die Arbeitsgeschwindigkeit. Denn Optionen wie Apache Spark oder Google Cloud DataFlow sind schneller als das MapReduce, das Hadoop zugrunde liegt.
Hadoop basiert auf mehreren Säulen, von denen die MapReduce-Technologien (ein System zur Verteilung von Daten für Berechnungen zwischen Servern) und das HDFS-Dateisystem die bemerkenswertesten sind. Letzteres ist speziell für die Speicherung von Informationen konzipiert, die zwischen Cluster-Knoten verteilt sind: Jeder Block einer festen Größe kann auf mehreren Knoten platziert werden, und dank der Replikation ist das System resistent gegen Ausfälle einzelner Knoten. Anstelle einer Dateitabelle wird ein spezieller Server namens NameNode verwendet.
Die folgende Abbildung zeigt, wie MapReduce funktioniert. Im ersten Schritt werden die Daten nach einem bestimmten Attribut aufgeteilt, im zweiten Schritt erfolgt die Verteilung nach Rechenleistung, im dritten Schritt erfolgt die Berechnung.
MapReduce wurde ursprünglich von Google für die Bedürfnisse seiner Suche entwickelt. Dann ging MapReduce in den freien Code über und Apache übernahm das Projekt. Nun, Google ist nach und nach auf andere Lösungen umgestiegen. Eine interessante Nuance: Derzeit hat Google ein Projekt namens Google Cloud Dataflow, das als nächster Schritt nach Hadoop und als dessen schneller Ersatz positioniert ist.
Ein genauerer Blick zeigt, dass Google Cloud Dataflow auf einer Variante von Apache Beam basiert, während Apache Beam das gut dokumentierte Apache Spark-Framework enthält, was es uns ermöglicht, von einer nahezu gleichen Geschwindigkeit der Lösungsausführung zu sprechen. Nun, Apache Spark funktioniert gut auf dem HDFS-Dateisystem, sodass Sie es auf Hadoop-Servern bereitstellen können.
Fügen Sie hier die Menge an Dokumentation und vorgefertigten Lösungen für Hadoop und Spark im Vergleich zu Google Cloud Dataflow hinzu, und die Wahl des Tools wird offensichtlich. Darüber hinaus können Ingenieure je nach Aufgabenstellung, Erfahrung und Qualifikation selbst entscheiden, welchen Code – unter Hadoop oder Spark – sie ausführen.
Cloud oder lokaler Server
Der Trend zum allgemeinen Übergang zur Cloud hat sogar einen so interessanten Begriff wie Hadoop-as-a-Service hervorgebracht. In einem solchen Szenario ist die Verwaltung der angeschlossenen Server sehr wichtig geworden. Denn leider ist reines Hadoop trotz seiner Beliebtheit ein ziemlich schwierig zu konfigurierendes Tool, da man viel von Hand erledigen muss. Sie können beispielsweise Server individuell konfigurieren, ihre Leistung überwachen und viele Parameter feinabstimmen. Wenn man für einen Amateur arbeitet, besteht im Allgemeinen eine große Chance, irgendwo einen Fehler zu machen oder etwas zu verpassen.
Daher erfreuen sich verschiedene Distributionen großer Beliebtheit, die zunächst mit komfortablen Bereitstellungs- und Verwaltungstools ausgestattet sind. Eine der beliebtesten Distributionen, die Spark unterstützt und die Arbeit erleichtert, ist Cloudera. Es gibt sowohl kostenpflichtige als auch kostenlose Versionen – in letzterer sind alle Hauptfunktionen verfügbar, ohne die Anzahl der Knoten zu begrenzen.
Während der Einrichtung stellt Cloudera Manager über SSH eine Verbindung zu Ihren Servern her. Ein interessanter Punkt: Bei der Installation ist es besser, anzugeben, dass die sogenannte Installation durchgeführt werden soll Pakete: spezielle Pakete, von denen jedes alle notwendigen Komponenten enthält, die für die Zusammenarbeit konfiguriert sind. Tatsächlich handelt es sich hierbei um eine so verbesserte Version des Paketmanagers.
Nach der Installation erhalten wir eine Cluster-Verwaltungskonsole, in der Sie Telemetriedaten für Cluster und installierte Dienste sehen, außerdem Ressourcen hinzufügen/entfernen und die Cluster-Konfiguration bearbeiten können.
Als Ergebnis erscheint vor Ihnen der Abriss dieser Rakete, die Sie in die glänzende Zukunft von BigData entführt. Aber bevor wir „Los geht’s“ sagen, schauen wir kurz unter die Haube.
Hardware-Anforderungen
Auf ihrer Website nennt Cloudera verschiedene mögliche Konfigurationen. Die allgemeinen Prinzipien, nach denen sie aufgebaut sind, sind in der Abbildung dargestellt:
MapReduce kann dieses optimistische Bild verwischen. Wenn man sich das Diagramm im vorherigen Abschnitt noch einmal ansieht, wird deutlich, dass ein MapReduce-Job in fast allen Fällen beim Lesen von Daten von der Festplatte oder im Netzwerk auf einen Engpass stoßen kann. Dies wird auch im Cloudera-Blog vermerkt. Daher ist die E/A-Geschwindigkeit für alle schnellen Berechnungen, auch über Spark, das häufig für Echtzeitberechnungen verwendet wird, sehr wichtig. Daher ist es bei der Verwendung von Hadoop sehr wichtig, dass ausgewogene und schnelle Maschinen in den Cluster gelangen, was, gelinde gesagt, nicht immer in der Cloud-Infrastruktur bereitgestellt wird.
Eine ausgewogene Lastverteilung wird durch den Einsatz der Openstack-Virtualisierung auf Servern mit leistungsstarken Multicore-CPUs erreicht. Datenknoten werden eigene Prozessorressourcen und bestimmte Festplatten zugewiesen. In unserer Lösung Atos Codex Data Lake Engine Es wird eine umfassende Virtualisierung erreicht, weshalb wir sowohl hinsichtlich der Leistung (die Auswirkungen der Netzwerkinfrastruktur werden minimiert) als auch hinsichtlich der Gesamtbetriebskosten (zusätzliche physische Server werden eliminiert) gewinnen.
Bei der Verwendung von BullSequana S200-Servern erhalten wir eine sehr gleichmäßige Auslastung ohne einige Engpässe. Die Mindestkonfiguration umfasst 3 BullSequana S200-Server mit jeweils zwei JBODs, außerdem sind optional weitere S200 mit vier Datenknoten angeschlossen. Hier ist eine Beispiellast in einem TeraGen-Test:
Tests mit unterschiedlichen Datenmengen und Replikationswerten zeigen die gleichen Ergebnisse hinsichtlich der Lastverteilung über Clusterknoten hinweg. Nachfolgend finden Sie ein Diagramm der Verteilung des Festplattenzugriffs nach Leistungstests.
Die Berechnungen basieren auf einer Mindestkonfiguration von 3 BullSequana S200-Servern. Es umfasst 9 Datenknoten und 3 Masterknoten sowie reservierte virtuelle Maschinen im Falle der Bereitstellung eines auf OpenStack Virtualization basierenden Schutzes. TeraSort-Testergebnis: 512 MB Blockgröße eines Replikationsfaktors von drei mit Verschlüsselung beträgt 23,1 Minuten.
Wie kann das System erweitert werden? Für die Data Lake Engine stehen verschiedene Arten von Erweiterungen zur Verfügung:
- Datenknoten: für jeweils 40 TB nutzbaren Speicherplatz
- Analyseknoten mit der Möglichkeit, eine GPU zu installieren
- Andere Optionen je nach Geschäftsanforderungen (z. B. wenn Sie Kafka und dergleichen benötigen)
Der Atos Codex Data Lake Engine-Komplex umfasst sowohl die Server selbst als auch vorinstallierte Software, einschließlich des Cloudera-Kits mit Lizenz; Hadoop selbst, OpenStack mit virtuellen Maschinen basierend auf dem RedHat Enterprise Linux-Kernel, Datenreplikations- und Backup-Systemen (einschließlich der Verwendung eines Backup-Knotens und Cloudera BDR – Backup and Disaster Recovery). Die Atos Codex Data Lake Engine ist die erste zertifizierte Virtualisierungslösung .
Wenn Sie sich für die Details interessieren, beantworten wir gerne unsere Fragen in den Kommentaren.
Source: habr.com