{"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 wird sie implementiert?","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Der Markt f\u00fcr verteiltes Rechnen und Big Data w\u00e4chst, wenn man den Quellen Glauben schenken mag, j\u00e4hrlich um 18-19 %. Daher bleibt die Auswahl der Software f\u00fcr diese Zwecke relevant. In diesem Beitrag werden wir zun\u00e4chst darauf eingehen, warum verteiltes Rechnen n\u00f6tig ist, dann detaillierter die Auswahl der Software betrachten, die Anwendung von Hadoop mit Cloudera besprechen, und abschlie\u00dfend \u00fcber die Hardwarewahl und deren verschiedene Auswirkungen auf die Leistung sprechen. Statistik<\/a><\/noindex>, w\u00e4chst j\u00e4hrlich um 18-19 %. Das hei\u00dft, die Wahl der Software f\u00fcr diese Zwecke bleibt relevant. In diesem Beitrag beginnen wir damit, warum verteilte Berechnungen erforderlich sind, werden genauer auf die Auswahl der Software eingehen, erz\u00e4hlen von der Anwendung von Hadoop mit Cloudera und zum Schluss sprechen wir \u00fcber die Auswahl der Hardware und wie diese auf verschiedene Weise die Leistung beeinflusst.<\/p>\n

\"Was<\/a><\/noindex>
\nWarum sind verteilte Rechenverfahren im gew\u00f6hnlichen Gesch\u00e4ft n\u00f6tig? Die Antwort ist gleichzeitig einfach und komplex. Einfach \u2014 weil wir in den meisten F\u00e4llen relativ unkomplizierte Berechnungen pro Informationseinheit durchf\u00fchren. Komplex \u2014 weil es eine enorme Menge an Informationen gibt. Infolgedessen m\u00fcssen wir Terabytes von Daten in 1000 Str\u00f6men verarbeiten.<\/a><\/noindex>Somit sind die Nutzungsszenarien recht universell: Berechnungen k\u00f6nnen \u00fcberall dort angewendet werden, wo eine gro\u00dfe Anzahl von Metriken auf einem noch gr\u00f6\u00dferen Datensatz ber\u00fccksichtigt werden muss.<\/p>\n

Ein aktuelles Beispiel: die Pizzakette Dodo Pizza. feststellte,<\/a><\/noindex> Basierend auf der Analyse der Kundenbestellungen haben Nutzer bei der Auswahl einer Pizza mit beliebigem Belag normalerweise nur sechs Grundsets von Zutaten plus ein paar zuf\u00e4llige Elemente. In \u00dcbereinstimmung damit hat die Pizzeria ihre Einkaufsstrategien angepasst. Zudem konnte sie den Kunden besser zus\u00e4tzliche Produkte empfehlen, die im Bestellprozess angeboten werden, was zu einer Steigerung des Gewinns f\u00fchrte.<\/p>\n

Ein weiteres Beispiel: Analyse<\/a><\/noindex> Die Reduzierung des Sortiments um 40 % in bestimmten Filialen von H&M konnte erreicht werden, w\u00e4hrend das Verkaufsniveau beibehalten wurde. Dies wurde erm\u00f6glicht, indem schlecht verkaufte Artikel ausgeschlossen wurden, wobei die Saisonalit\u00e4t ber\u00fccksichtigt wurde.<\/p>\n

Wahl des Werkzeugs<\/h2>\n

\nDer Branchenstandard f\u00fcr diese Art von Berechnungen ist Hadoop. Warum? Weil Hadoop ein hervorragendes, gut dokumentiertes Framework ist, das mit einer Vielzahl von Tools und Bibliotheken ausgestattet ist. Sie k\u00f6nnen gro\u00dfe Mengen sowohl strukturierter als auch unstrukturierter Daten einspeisen, w\u00e4hrend das System selbst diese auf die Rechenressourcen verteilt. Diese Ressourcen k\u00f6nnen jederzeit erweitert oder deaktiviert werden \u2013 das ist die horizontale Skalierbarkeit in Aktion. <\/p>\n

Im Jahr 2017 stellte das einflussreiche Beratungsunternehmen Gartner fest,<\/a><\/noindex>dass Hadoop bald obsolet sein wird. Der Grund ist relativ einfach: Analysten glauben, dass Unternehmen massenhaft in die Cloud migrieren werden, da sie dort nach tats\u00e4chlichem Verbrauch von Rechenressourcen bezahlen k\u00f6nnen. Ein weiterer wichtiger Faktor, der angeblich Hadoop 'begraben' k\u00f6nnte, ist die Geschwindigkeit. Denn Alternativen wie Apache Spark oder Google Cloud DataFlow arbeiten schneller als das zugrunde liegende MapReduce von Hadoop.<\/p>\n

Hadoop basiert auf mehreren Kerntechnologien, wobei die herausragendsten die MapReduce-Technologie (ein System zur Verteilung von Daten f\u00fcr Berechnungen zwischen Servern) und das HDFS-Dateisystem sind. Letzteres wurde speziell f\u00fcr die Speicherung von Informationen entwickelt, die \u00fcber die Knoten eines Clusters verteilt sind: Jeder Block fester Gr\u00f6\u00dfe kann auf mehreren Knoten platziert werden, und durch Replikation wird die Ausfallsicherheit des Systems gew\u00e4hrleistet. Anstelle einer Dateitabelle kommt ein spezieller Server namens NameNode zum Einsatz.<\/p>\n

Das untenstehende Diagramm zeigt die Funktionsweise von MapReduce. Im ersten Schritt werden die Daten nach bestimmten Kriterien aufgeteilt, im zweiten Schritt werden sie auf Berechnungsressourcen verteilt, und im dritten Schritt erfolgt die Berechnung. <\/p>\n

\"Was
\nUrspr\u00fcnglich wurde MapReduce von Google f\u00fcr seine Suchmaschinenbed\u00fcrfnisse entwickelt. Anschlie\u00dfend wurde MapReduce als Open Source verf\u00fcgbar gemacht, und Apache \u00fcbernahm das Projekt. Google hat sich mittlerweile auf andere L\u00f6sungen ausgerichtet. Ein interessanter Punkt ist, dass Google derzeit ein Projekt namens Google Cloud Dataflow hat, das als n\u00e4chster Schritt nach Hadoop positioniert wird, quasi als dessen schnelle Alternative.<\/p>\n

Bei genauerer Betrachtung wird deutlich, dass Google Cloud Dataflow auf einer Variante von Apache Beam basiert, wobei Apache Beam ein gut dokumentiertes Framework von Apache Spark enth\u00e4lt. Dies f\u00fchrt dazu, dass die Ausf\u00fchrungsgeschwindigkeit der L\u00f6sungen nahezu identisch ist. Zudem funktioniert Apache Spark hervorragend mit dem HDFS-Dateisystem, was eine Bereitstellung auf Hadoop-Servern erm\u00f6glicht.<\/p>\n

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

Cloud oder lokaler Server<\/h2>\n

\nDer Trend zum umfassenden Umstieg in die Cloud hat sogar einen interessanten Begriff wie Hadoop-as-a-Service hervorgebracht. In diesem Szenario ist das Management der angebundenen Server von entscheidender Bedeutung. Denn trotz seiner Popularit\u00e4t ist reines Hadoop leider ein recht komplexes Tool, das viel manuelle Arbeit erfordert. Man muss die Server einzeln konfigurieren, ihre Kennzahlen \u00fcberwachen und zahlreiche Parameter sorgf\u00e4ltig einstellen. Insgesamt ist es eine anspruchsvolle Aufgabe, bei der die Gefahr besteht, Fehler zu machen oder etwas zu \u00fcbersehen.<\/p>\n

Deshalb erfreuen sich verschiedene Distributionen gro\u00dfer Beliebtheit, die von Anfang an mit benutzerfreundlichen Bereitstellungs- und Verwaltungstools ausgestattet sind. Eine der beliebtesten Distributionen, die Spark unterst\u00fctzt und vieles vereinfacht, ist Cloudera. Es gibt sowohl eine kostenpflichtige als auch eine kostenlose Version, wobei die letzte alle grundlegenden Funktionen bietet, ohne Einschr\u00e4nkung der Anzahl der Nodes. <\/p>\n

\"Was
\n
\nW\u00e4hrend der Einrichtung wird Cloudera Manager per SSH eine Verbindung zu Ihren Servern herstellen. Ein interessanter Punkt: Es ist besser, w\u00e4hrend der Installation anzugeben, dass diese so genannte Paketen<\/i>: speziellen Paketen, in denen alle notwendigen Komponenten enthalten sind, die so konfiguriert sind, dass sie reibungslos zusammenarbeiten. Im Grunde genommen handelt es sich um eine verbesserte Version eines Paketmanagers.<\/p>\n

Nach der Installation erhalten wir ein Verwaltungskonsole f\u00fcr den Cluster, auf der Sie die Telemetrie der Cluster, installierte Dienste sehen k\u00f6nnen. Zudem haben Sie die M\u00f6glichkeit, Ressourcen hinzuzuf\u00fcgen\/zu entfernen und die Konfiguration des Clusters zu bearbeiten. <\/p>\n

\"Was
\n
\nDas Ergebnis ist das Cockpit der Rakete, die Sie in die glorreiche Zukunft von Big Data bef\u00f6rdern wird. Aber bevor wir 'Los' sagen, schauen wir uns mal unter die Haube.<\/p>\n

Anforderungen an die Hardware<\/h2>\n

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

\"Was
\nDie optimistische Aussicht kann durch MapReduce getr\u00fcbt werden. Wenn wir erneut das Diagramm aus dem vorherigen Abschnitt betrachten, wird deutlich, dass ein MapReduce-Job in nahezu allen F\u00e4llen auf ein \u201eFlaschenhals\u201c-Problem sto\u00dfen kann, wenn Daten von der Festplatte oder aus dem Netzwerk gelesen werden. Dies wird auch im Blog von Cloudera hervorgehoben. Daher ist f\u00fcr schnelle Berechnungen, einschlie\u00dflich derer, die \u00fcber Spark durchgef\u00fchrt werden, der h\u00e4ufig f\u00fcr Echtzeitanalysen genutzt wird, die Geschwindigkeit der Eingabe\/Ausgabe von gr\u00f6\u00dfter Bedeutung. Es ist daher entscheidend, bei der Nutzung von Hadoop auf einen Cluster zu setzen, der \u00fcber ausgewogene und schnelle Maschinen verf\u00fcgt, was, gelinde gesagt, nicht immer in der Cloud-Infrastruktur gegeben ist.<\/p>\n

Die Balance in der Lastverteilung wird durch den Einsatz von OpenStack-Virtualisierung auf Servern mit leistungsstarken Multi-Core-CPUs erreicht. Den Datenknoten werden eigene Prozessorressourcen und bestimmte Festplatten zugewiesen. In unserer L\u00f6sung Atos Codex Data Lake Engine<\/i> erreichen wir eine umfassende Virtualisierung, wodurch wir sowohl in Bezug auf die Leistung profitieren (der Einfluss der Netzwerk-Infrastruktur wird minimiert) als auch die Gesamtkosten (TCO) gesenkt werden (\u00fcberfl\u00fcssige physische Server werden eliminiert).<\/p>\n

\"Was
\nWenn wir die BullSequana S200 Server verwenden, erhalten wir eine gleichm\u00e4\u00dfige Auslastung ohne signifikante Engp\u00e4sse. Die minimale Konfiguration umfasst 3 BullSequana S200 Server, jeder mit zwei JBOD, zus\u00e4tzlich k\u00f6nnen optional weitere S200 Server mit jeweils vier Datenknoten hinzugef\u00fcgt werden. Hier ist ein Beispiel f\u00fcr die Auslastung im TeraGen-Test:<\/p>\n

\"Was
\n
\nTests mit verschiedenen Datenmengen und Replikationswerten zeigen \u00e4hnliche Ergebnisse hinsichtlich der Lastverteilung zwischen den Clusterknoten. Unten ist ein Diagramm der Festplattendatenzugriffsverteilung aus den Leistungstests dargestellt.<\/p>\n

\"Was
\n
\nDie Berechnungen wurden auf Basis der minimalen Konfiguration von 3 BullSequana S200 Servern durchgef\u00fchrt. Sie umfasst 9 Datenknoten und 3 Hauptknoten sowie reservierte virtuelle Maschinen f\u00fcr den Fall eines OpenStack Virtualization-Schutzes. Testergebnis TeraSort: Mit einem Blocksize von 512 MB und einem Replikationsfaktor von drei betr\u00e4gt die Verschl\u00fcsselungszeit 23,1 Minuten.<\/p>\n

Wie kann das System erweitert werden? F\u00fcr den Data Lake Engine sind verschiedene Erweiterungsarten verf\u00fcgbar:<\/p>\n