{"id":33630,"date":"2019-10-31T21:53:49","date_gmt":"2019-10-31T18:53:49","guid":{"rendered":"https:\/\/prohoster.info\/blog\/chto-osobennogo-v-cloudera-i-kak-ee-gotovit\/"},"modified":"2019-10-31T21:53:49","modified_gmt":"2019-10-31T18:53:49","slug":"chto-osobennogo-v-cloudera-i-kak-ee-gotovit","status":"publish","type":"post","link":"https:\/\/prohoster.info\/de\/blog\/administrirovanie\/chto-osobennogo-v-cloudera-i-kak-ee-gotovit","title":{"rendered":"Was ist besonders an Cloudera und wie man sie zubereitet","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Der Markt f\u00fcr verteiltes Rechnen und Big Data w\u00e4chst, wenn man denn glaubt Statistik<\/a><\/noindex>, um 18-19 % pro Jahr. Das bedeutet, die Wahl der Software f\u00fcr diese Zwecke bleibt aktuell. In diesem Beitrag beginnen wir damit, warum verteiltes Rechnen ben\u00f6tigt wird, vertiefen die Wahl der Software, erl\u00e4utern die Anwendung von Hadoop mit Cloudera und sprechen schlie\u00dflich \u00fcber die Wahl der Hardware und wie diese auf verschiedene Weise die Leistung beeinflusst.<\/p>\n

\"Was<\/a><\/noindex>
\nWarum ist verteiltes Rechnen im normalen Gesch\u00e4ft wichtig? Hier ist alles gleichzeitig einfach und komplex. Einfach \u2013 weil wir in den meisten F\u00e4llen relativ unkomplizierte Berechnungen pro Informationseinheit durchf\u00fchren. Komplex \u2013 weil es viele solcher Informationen gibt. Sehr viele. Infolgedessen m\u00fcssen wir Terabytes von Daten in 1000 Streams verarbeiten<\/a><\/noindex>. Damit sind die Nutzungsszenarien ziemlich universell: Berechnungen k\u00f6nnen \u00fcberall dort angewendet werden, wo eine gro\u00dfe Anzahl von Metriken auf einem noch gr\u00f6\u00dferen Datenvolumen ber\u00fccksichtigt werden muss.<\/p>\n

Ein Beispiel aus der letzten Zeit: Die Pizzakette Dodo Pizza hat festgestellt<\/a><\/noindex> , dass basierend auf der Analyse der Auftragsdaten der Kunden bei der Auswahl einer Pizza mit beliebigem Belag die Nutzer in der Regel nur mit sechs grundlegenden Zutaten-Sets plus ein paar Zuf\u00e4lligen arbeiten. In \u00dcbereinstimmung damit hat die Pizzakette ihre Einkaufsstrategien angepasst. Dar\u00fcber hinaus konnte sie den Nutzern besser erg\u00e4nzende Produkte anbieten, die w\u00e4hrend des Bestellvorgangs angeboten werden, was die Gewinne erh\u00f6ht hat.<\/p>\n

Ein weiteres Beispiel: 13. Alles liegt in Ihren H\u00e4nden\u2026<\/a><\/noindex> die Reduzierung der Produktpalette erm\u00f6glichte es dem Gesch\u00e4ft H&M, das Sortiment in bestimmten Filialen um 40 % zu verkleinern und gleichzeitig die Verkaufszahlen aufrechtzuerhalten. Dies gelang, indem schlecht verkaufte Artikel ausgeschlossen wurden, wobei die Saisonalit\u00e4t ber\u00fccksichtigt wurde.<\/p>\n

Die Wahl des Werkzeugs<\/h2>\n

\nDer Branchenstandard f\u00fcr derartige Berechnungen ist Hadoop. Warum? Weil Hadoop ein hervorragendes, gut dokumentiertes Framework ist (der gleiche Habr ver\u00f6ffentlicht zahlreiche detaillierte Artikel zu diesem Thema), das mit einer ganzen Reihe von Dienstprogrammen und Bibliotheken einhergeht. Sie k\u00f6nnen riesige Mengen sowohl strukturierter als auch unstrukturierter Daten einspeisen, und das System wird diese automatisch auf die Rechenkapazit\u00e4ten verteilen. Diese Kapazit\u00e4ten k\u00f6nnen jederzeit erh\u00f6ht oder abgeschaltet werden \u2013 die horizontale Skalierbarkeit ist hier in Aktion. <\/p>\n

Im Jahr 2017 erkl\u00e4rte das einflussreiche Beratungsunternehmen Gartner Vor kurzem feierte der gr\u00f6\u00dfte chinesische OEM- und ODM-Hersteller vielf\u00e4ltiger Flash-Laufwerke, die Firma Longsys, feierlich ihr 20-j\u00e4hriges Bestehen.<\/a><\/noindex>, dass Hadoop bald obsolet sein wird. Der Grund ist ziemlich banal: Die Analysten glauben, dass Unternehmen massenhaft in die Cloud migrieren werden, da sie dort nach tats\u00e4chlichem Verbrauch der Rechenleistung bezahlen k\u00f6nnen. Ein zweiter wichtiger Faktor, der angeblich in der Lage ist, Hadoop zu \u201ebegraben\u201c, ist die Geschwindigkeit. Denn Alternativen wie Apache Spark oder Google Cloud DataFlow arbeiten schneller als das zugrunde liegende MapReduce von Hadoop.<\/p>\n

Hadoop ruht auf mehreren S\u00e4ulen, von denen die bemerkenswertesten die MapReduce-Technologie (ein System zur Verteilung von Daten f\u00fcr Berechnungen zwischen Servern) und das Dateisystem HDFS sind. Letzteres ist speziell daf\u00fcr konzipiert, Informationen, die auf die Knoten eines Clusters verteilt sind, zu speichern: Jeder Block fester Gr\u00f6\u00dfe kann auf mehreren Knoten abgelegt werden, und durch die Replikation wird die Zuverl\u00e4ssigkeit des Systems bei Ausf\u00e4llen einzelner Knoten gew\u00e4hrleistet. Anstelle einer Datei wird ein spezieller Server, der NameNode genannt wird, verwendet.<\/p>\n

In der untenstehenden Abbildung wird das Schema der Arbeit von MapReduce dargestellt. In der ersten Phase werden die Daten nach bestimmten Kriterien aufgeteilt, in der zweiten werden sie auf die Rechenressourcen verteilt, und in der dritten erfolgt die Berechnung. <\/p>\n

\"Was
\nUrspr\u00fcnglich wurde MapReduce von Google f\u00fcr die Bed\u00fcrfnisse seiner Suchmaschine entwickelt. Dann wurde MapReduce Open Source, und das Projekt wurde von Apache \u00fcbernommen. Google migrierte jedoch allm\u00e4hlich zu anderen L\u00f6sungen. Ein interessanter Aspekt: Momentan hat Google ein Projekt namens Google Cloud Dataflow, das als der n\u00e4chste Schritt nach Hadoop positioniert wird, als dessen schnelle Alternative.<\/p>\n

Bei n\u00e4herer Betrachtung wird deutlich, dass Google Cloud Dataflow auf einer Variante von Apache Beam basiert, wobei Apache Beam ein gut dokumentiertes Framework namens Apache Spark enth\u00e4lt, was man sagen kann, dass nahezu die gleiche Geschwindigkeit bei der Ausf\u00fchrung von L\u00f6sungen erzielt wird. Au\u00dferdem funktioniert Apache Spark hervorragend mit dem HDFS-Dateisystem, was es erm\u00f6glicht, es auf Hadoop-Servern einzusetzen.<\/p>\n

Wenn wir hier das Volumen der Dokumentation und fertigen L\u00f6sungen f\u00fcr Hadoop und Spark im Vergleich zu Google Cloud Dataflow hinzuf\u00fcgen, wird die Wahl des Werkzeugs offensichtlich. Dar\u00fcber hinaus k\u00f6nnen Ingenieure selbst entscheiden, welchen Code \u2013 f\u00fcr Hadoop oder Spark \u2013 sie ausf\u00fchren m\u00f6chten, abh\u00e4ngig von der Aufgabe, der Erfahrung und der Qualifikation.<\/p>\n

Cloud oder lokaler Server<\/h2>\n

\nDer Trend zur umfassenden Cloud-Nutzung hat sogar einen interessanten Begriff wie Hadoop-as-a-Service hervorgebracht. In einem solchen Szenario wurde die Verwaltung der angeschlossenen Server sehr wichtig. Denn leider ist reines Hadoop trotz seiner Beliebtheit ein ziemlich komplexes Tool, das schwer einzurichten ist, da vieles manuell erledigt werden muss. Zum Beispiel m\u00fcssen Server einzeln konfiguriert, ihre Leistungskennzahlen \u00fcberwacht und zahlreiche Parameter sorgf\u00e4ltig eingestellt werden. Insgesamt ist es eine Angelegenheit f\u00fcr Liebhaber und es besteht eine gro\u00dfe Chance, dass man irgendwo etwas vermasselt oder etwas \u00fcbersieht.<\/p>\n

Deshalb sind verschiedene Distributionen sehr beliebt geworden, die urspr\u00fcnglich mit bequemen Bereitstellungs- und Verwaltungswerkzeugen ausgestattet sind. Eine der beliebtesten Distributionen, die Spark unterst\u00fctzt und alles vereinfacht, ist Cloudera. Es gibt sowohl kostenpflichtige als auch kostenlose Versionen \u2013 und in letzterer ist die gesamte grundlegende Funktionalit\u00e4t verf\u00fcgbar, ohne Begrenzung der Anzahl der Knoten. <\/p>\n

\"Was
\n
\nW\u00e4hrend der Einrichtung wird Cloudera Manager per SSH eine Verbindung zu Ihren Servern herstellen. Ein interessanter Punkt: Bei der Installation ist es besser anzugeben, dass sie mit sogenannten Parcels<\/i>: speziellen Paketen, in denen alle ben\u00f6tigten Komponenten enthalten sind, die f\u00fcr die Zusammenarbeit optimiert sind, durchgef\u00fchrt werden sollte. Im Grunde genommen ist dies eine verbesserte Version eines Paketmanagers.<\/p>\n

Nach der Installation erhalten wir eine Verwaltungsoberfl\u00e4che f\u00fcr das Cluster, auf der man die Telemetrie zu den Clustern, installierten Services sehen kann, au\u00dferdem k\u00f6nnen Sie Ressourcen hinzuf\u00fcgen\/entfernen und die Clusterkonfiguration bearbeiten. <\/p>\n

\"Was
\n
\nInfolgedessen steht Ihnen der Schnitt dieser Rakete zur Verf\u00fcgung, die Sie in eine strahlende Zukunft der Big Data bringen wird. Aber bevor wir \"Losfahren\" sagen, lassen Sie uns unter die Haube schauen.<\/p>\n

Anforderungen an die Hardware<\/h2>\n

\nAuf seiner Website erw\u00e4hnt Cloudera verschiedene m\u00f6gliche Konfigurationen. Die allgemeinen Prinzipien, nach denen sie aufgebaut sind, sind in der Abbildung dargestellt:<\/p>\n

\"Was
\nMapReduce kann dieses optimistische Bild tr\u00fcben. Wenn man sich das Diagramm aus dem vorherigen Abschnitt erneut ansieht, wird offensichtlich, dass der MapReduce-Job in fast allen F\u00e4llen auf ein \u201eEngpass\u201c-Problem sto\u00dfen kann, wenn Daten von der Festplatte oder aus dem Netzwerk gelesen werden. Dies wird auch im Cloudera-Blog erw\u00e4hnt. Daher ist bei schnellen Berechnungen, einschlie\u00dflich \u00fcber Spark, das h\u00e4ufig f\u00fcr Echtzeitberechnungen genutzt wird, die Geschwindigkeit der Ein- und Ausgabe von entscheidender Bedeutung. Deshalb ist es bei der Verwendung von Hadoop sehr wichtig, dass das Cluster ausgeglichene und schnelle Maschinen erh\u00e4lt, was, gelinde gesagt, in der Cloud-Infrastruktur nicht immer gew\u00e4hrleistet ist.<\/p>\n

Die Ausgewogenheit bei der Verteilung der Lasten wird durch die Nutzung der OpenStack-Virtualisierung auf Servern mit leistungsstarken Mehrkern-CPUs erreicht. Den Datenknoten werden spezifische Prozessorkapazit\u00e4ten und bestimmte Festplatten zugewiesen. In unserer L\u00f6sung Atos Codex Data Lake Engine<\/i> erreicht eine umfassende Virtualisierung, wodurch wir sowohl in Bezug auf die Leistung (der Einfluss der Netzwerkstruktur wird minimiert) als auch auf TCO (\u00fcberfl\u00fcssige physische Server werden ausgeschlossen) profitieren.<\/p>\n

\"Was
\nBei der Verwendung von BullSequana S200-Servern erhalten wir eine sehr gleichm\u00e4\u00dfige Auslastung, die von einzelnen Engp\u00e4ssen befreit ist. In die Minimal-Konfiguration werden 3 BullSequana S200-Server integriert, jeder mit zwei JBOD, und optional k\u00f6nnen zus\u00e4tzliche S200-Server angeschlossen werden, die jeweils vier Datenknoten enthalten. Hier ist ein Beispiel f\u00fcr die Last im TeraGen-Test:<\/p>\n

\"Was
\n
\nTests mit verschiedenen Datenmengen und Replikationswerten zeigen in Bezug auf die Lastverteilung zwischen den Clusterknoten identische Ergebnisse. Im Folgenden ist ein Diagramm zur Verteilung des Zugriffs auf die Festplatte basierend auf den Leistungstests dargestellt.<\/p>\n

\"Was
\n
\nDie Berechnungen wurden auf der Grundlage der Minimal-Konfiguration von 3 BullSequana S200-Servern durchgef\u00fchrt. Diese umfasst 9 Datenknoten und 3 Master-Knoten sowie reservierte virtuelle Maschinen f\u00fcr den Fall, dass der Schutz auf Basis von OpenStack Virtualization implementiert wird. Das Ergebnis des TeraSort-Tests: Blockgr\u00f6\u00dfe von 512 MB bei einem Replikationsfaktor von drei mit Verschl\u00fcsselung betr\u00e4gt 23,1 Minuten.<\/p>\n

Wie kann das System erweitert werden? F\u00fcr die Data Lake Engine stehen verschiedene Erweiterungsarten zur Verf\u00fcgung:<\/p>\n