Es ist wohl kein Geheimnis, dass das letzte Jahr für Apache Hadoop ein Jahr großer Veränderungen war. Im vergangenen Jahr fusionierten Cloudera und Hortonworks (in der Praxis wurde letzterer übernommen), und Mapr wurde aufgrund ernsthafter finanzieller Probleme an Hewlett Packard verkauft. Während man vor einigen Jahren bei On-Premises-Installationen häufig zwischen Cloudera und Hortonworks wählen musste, gibt es heute leider diese Wahl nicht mehr. Überraschend war auch die Tatsache, dass Cloudera im Februar dieses Jahres angekündigt hat, die Ausgabe von Binärversionen seiner Distribution im öffentlichen Repository einzustellen, und diese nun nur noch gegen kostenpflichtiges Abonnement verfügbar sind. Natürlich besteht weiterhin die Möglichkeit, die letzten Versionen von CDH und HDP, die bis Ende 2019 veröffentlicht wurden, herunterzuladen, und die Unterstützung dafür wird voraussichtlich ein bis zwei Jahre bestehen. Aber was tun wir jetzt? Für diejenigen, die zuvor für ein Abonnement bezahlt haben, hat sich nichts geändert. Für diejenigen, die nicht auf die kostenpflichtige Version der Distribution umsteigen wollen, aber dennoch frische Versionen der Clusterkomponenten sowie Patches und andere Updates erhalten möchten, haben wir diesen Artikel vorbereitet. Darin werden wir mögliche Lösungen für die bestehende Situation erörtern.
Der Artikel ist eher allgemein gehalten. Er wird keinen Vergleich der Distributionen und detaillierte Analysen enthalten, auch keine Anleitungen zur Installation und Konfiguration. Was wird es also geben? Wir werden kurz über eine Distribution namens Arenadata Hadoop sprechen, die aufgrund ihrer Zugänglichkeit, die heutzutage selten ist, unsere Aufmerksamkeit verdient hat. Danach werden wir über Vanilla Hadoop sprechen, insbesondere darüber, wie man es mit Apache Bigtop 'zubereiten' kann. Bereit? Dann willkommen unter dem Artikel.
Arenadata Hadoop
Es handelt sich um eine ganz neue und bisher noch kaum bekannte Distribution, die im Inland entwickelt wurde. Leider gibt es momentan auf Habr nur .
Detaillierte Informationen finden Sie auf der offiziellen des Projekts. Die letzten Versionen der Distribution basieren auf Hadoop 3.1.2 für die 3. Version und 2.8.5 für die 2. Version.
Informationen zum Roadmap finden Sie .
Benutzeroberfläche des Arenadata Cluster Managers
Das Hauptprodukt von Arenadata ist , der zur Installation, Konfiguration und Überwachung verschiedener Softwarelösungen des Unternehmens verwendet wird. ADCM wird kostenlos verteilt, und seine Funktionalität wird durch die Hinzufügung von Bundles erweitert, die aus einer Reihe von Ansible-Playbooks bestehen. Die Bundles werden in zwei Arten unterteilt: Enterprise und Community. Letztere sind kostenlos von der Website Arenadata herunterzuladen. Außerdem gibt es die Möglichkeit, ein eigenes Bundle zu entwickeln und es mit ADCM zu verbinden.
Für das Deployment und Management von Hadoop 3 wird eine Community-Version des Bundles zusammen mit ADCM angeboten, während es für Hadoop 2 nur als Alternative gibt. Was die Repositorys mit Paketen angeht, sind diese für den öffentlichen Zugriff geöffnet, sie können heruntergeladen und auf die gewohnte Weise für alle Cluster-Komponenten installiert werden. Insgesamt macht das Distributionspaket einen sehr interessanten Eindruck. Ich bin mir sicher, dass es Nutzer geben wird, die an solchen Lösungen wie Cloudera Manager und Ambari gewöhnt sind und die ADCM ansprechend finden. Für einige wird es ein großer Vorteil sein, dass das Distributionspaket zum Ersatz von Importen enthalten ist.
Wenn wir über die Nachteile sprechen, so sind sie die gleichen wie bei allen anderen Hadoop-Distributionen. Nämlich:
- So genannter «Vendor Lock-in». Am Beispiel von Cloudera und Hortonworks haben wir bereits verstanden, dass es immer ein Risiko gibt, die Unternehmenspolitik zu ändern.
- Deutliche Rückstände hinter dem Upstream von Apache.
Vanilla Hadoop
Wie Sie wissen, ist Hadoop kein monolithisches Produkt, sondern im Grunde eine ganze Reihe von Diensten rund um sein verteiltes Dateisystem HDFS. Es reicht den wenigsten, nur einen Dateiknoten zu haben. Einige benötigen Hive, andere Presto, und es gibt auch HBase und Phoenix, wobei Spark zunehmend verwendet wird. Für die Orchestrierung und den Datenimport kommen manchmal Oozie, Sqoop und Flume zum Einsatz. Und wenn es um Sicherheitsaspekte geht, denkt man sofort an Kerberos in Verbindung mit Ranger.
Die Binärversionen der Hadoop-Komponenten sind auf der Website jedes Projekts des Ökosystems in Form von Tarballs verfügbar. Sie können heruntergeladen und mit der Installation begonnen werden, jedoch mit einer Bedingung: Neben dem selbständigen Erstellen von Paketen aus „rohen“ Binärdateien, was Sie wahrscheinlich tun möchten, haben Sie keine Sicherheit über die Kompatibilität der heruntergeladenen Versionen untereinander. Eine bevorzugte Option ist der Aufbau mit Apache Bigtop. Bigtop ermöglicht es, aus den Maven-Repositories von Apache zu bauen, Tests durchzuführen und Pakete zu erstellen. Aber was für uns sehr wichtig ist, Bigtop wird die Versionen der Komponenten erstellen, die untereinander kompatibel sind. Darüber werden wir im Folgenden genauer berichten.
Apache Bigtop
Apache Bigtop ist ein Tool zum Erstellen, Paketieren und Testen einer Reihe
von Open-Source-Projekten, wie zum Beispiel Hadoop und Greenplum. Bigtop hat viele
Versionen. Zum Zeitpunkt des Schreibens war die letzte stabile Version 1.4,
während sich in der Masterversion 1.5 befand. In den verschiedenen Versionen
der Releases werden unterschiedliche Versionen
von Komponenten verwendet. Zum Beispiel haben die Kernkomponenten von Hadoop in Version 1.4 die Version 2.8.5, während es in der Masterversion 2.10.0 ist. Auch die Zusammensetzung der unterstützten Komponenten ändert sich. Etwas Veraltetes und Nicht-Aktualisiertes verschwindet, während etwas Neues und Gefragteres an dessen Stelle tritt, und es muss nicht unbedingt etwas aus der Apache-Familie sein.
Darüber hinaus hat Bigtop viele
Forks.
Als wir begannen, uns mit Bigtop vertraut zu machen, waren wir vor allem über seine bescheidene Verbreitung und Bekanntheit im Vergleich zu anderen Apache-Projekten überrascht, sowie über die sehr kleine Community. Daraus folgt, dass es nur minimales Informationsmaterial zum Produkt gibt und die Suche nach Lösungen für aufgetretene Probleme in Foren und Mailinglisten möglicherweise wenig nützt. Zunächst stellte es sich für uns als eine nicht einfache Aufgabe heraus, eine vollständige Distribution zu erstellen, aufgrund der Besonderheiten des Tools selbst, aber darüber werden wir gleich etwas mehr erzählen. .
Als wir anfingen, uns mit Bigtop vertraut zu machen, waren wir in erster Linie über seine bescheidene, im Vergleich zu anderen Apache-Projekten, Verbreitung und Bekanntheit überrascht, sowie über die sehr kleine Community. Daraus folgt, dass es nur wenig Informationen über das Produkt gibt und die Suche nach Lösungen für auftretende Probleme in Foren und Mailinglisten möglicherweise nichts bringt. Zunächst stellte es sich für uns als Herausforderung heraus, eine vollständige Distribution zu erstellen, bedingt durch die Eigenheiten des Tools selbst, aber darüber werden wir später ein wenig mehr erzählen.
Als Teaser – diejenigen, die in ihrer Zeit Projekte aus der Linux-Universum wie Gentoo und LFS mochten, werden vielleicht nostalgisch erfreut sein, mit diesem Ding zu arbeiten und sich an die "heldenhaften" Zeiten zu erinnern, als wir selbst ebuilds suchten (oder sogar schrieben) und regelmäßig mit neuen Patches Mozilla neu kompilierten.
Ein großer Vorteil von Bigtop ist die Offenheit und Vielseitigkeit der Werkzeuge, auf denen es basiert. Im Kern stehen Gradle und Apache Maven. Gradle ist als Werkzeug, das Google zum Erstellen von Android verwendet, ziemlich bekannt. Es ist flexibel und, wie man so sagt, „im Einsatz bewährt“. Maven ist das Standardwerkzeug zum Erstellen von Projekten in Apache, und da die meisten seiner Produkte tatsächlich über Maven veröffentlicht werden, kommt man auch hier nicht ohne es aus. Besonders hervorzuheben ist die POM (Project Object Model) – eine „fundamentale“ XML-Datei, die alles beschreibt, was für die Arbeit von Maven mit Ihrem Projekt erforderlich ist und um die die gesamte Arbeit aufgebaut wird. Genau in
diesem Teil von Maven treten einige Hindernisse auf, auf die normalerweise Anfänger stoßen, die sich mit Bigtop vertrautmachen.
Praxis
Also, wo fangen wir an? Gehen Sie zur Download-Seite und laden Sie die letzte stabile Version im Archivformat herunter. Dort finden Sie auch die von Bigtop erstellten binären Artefakte. Übrigens werden die gängigen Paketmanager YUM und APT unterstützt.
Alternativ können Sie die letzte stabile Version direkt von
github:
$ git clone --branch branch-1.4 https://github.com/apache/bigtop.gitKlone in ‚bigtop‘…
remote: Objekte werden gezählt: 46, abgeschlossen.
remote: Zähle Objekte: 100% (46/46), abgeschlossen.
remote: Komprimiere Objekte: 100% (41/41), abgeschlossen.
remote: Insgesamt 40217 (delta 14), wiederverwendet 10 (delta 1), pack-wiederverwendet 40171
Erhalte Objekte: 100% (40217/40217), 43.54 MiB | 1.05 MiB/s, fertig.
Bestimme Änderungen: 100% (20503/20503), fertig.
Aktualisiere Dateien: 100% (1998/1998), fertig.Das so entstandene Verzeichnis ./bigtop sieht etwa so aus:
./bigtop-bigpetstore — Demoprojekte, synthetische Beispiele
./bigtop-ci — CI-Tools, Jenkins
./bigtop-data-generators — Datengenerierung, synthetisch, für Smoke-Tests usw.
./bigtop-deploy — Bereitstellungstools
./bigtop-packages — Konfigurationen, Skripte, Patches für das Bauen, Hauptteil des Tools
./bigtop-test-framework — Test-Framework
./bigtop-tests — die Tests selbst, Last- und Smoke-Tests
./bigtop_toolchain — Build-Umgebung, Vorbereitung der Umgebung für die Arbeit des Tools
./build — Arbeitsverzeichnis für den Build
./dl — Verzeichnis für heruntergeladene Quellcodes
./docker — Build in Docker-Images, Tests
./gradle — Gradle-Konfiguration
./output – Verzeichnis, in das die Build-Artefakte gelangen
./provisioner — Provisionierung
Das Interessanteste in dieser Phase für uns ist die Hauptkonfiguration ./bigtop/bigtop.bom, in dem wir alle unterstützten Komponenten mit Versionen sehen. Hier können wir eine andere Produktversion angeben (falls wir sie ausprobieren möchten) oder die Version des Builds (wenn wir beispielsweise ein bedeutendes Update hinzugefügt haben).
Ein großes Interesse weckt auch das Unterverzeichnis .\/bigtop\/bigtop-packages, das einen direkten Bezug zum Prozess des Aufbaus von Komponenten und Paketen hat.
Also, wir haben das Archiv heruntergeladen, entpackt oder einen Klon von GitHub gemacht, können wir mit dem Bauen beginnen?
Nein, zuerst bereiten wir die Umgebung vor.
Vorbereitung der Umgebung
Hier ist ein kleiner Exkurs erforderlich. Um nahezu jedes mehr oder weniger komplexe Produkt zu bauen, ist eine bestimmte Umgebung notwendig – in unserem Fall sind das JDK, die gleichen gemeinsam genutzten Bibliotheken, Header-Dateien usw., Werkzeuge wie Ant, Ivy2 und vieles mehr. Eine Möglichkeit, die für Bigtop benötigte Umgebung zu erhalten, ist die Installation der benötigten Komponenten auf dem Build-Host. Ich könnte mich in der Chronologie irren, aber es scheint, dass mit Version 1.0 auch die Möglichkeit hinzugefügt wurde, in vorab konfigurierten und verfügbaren Docker-Images zu bauen, die wir hier einsehen können.
Was die Vorbereitung der Umgebung betrifft, so gibt es dafür einen Helfer – Puppet.
Wir können die folgenden Befehle verwenden, der Start erfolgt aus dem Wurzelverzeichnis
des Werkzeugs, .\/bigtop:
.\/gradlew toolchain\n.\/gradlew toolchain-devtools\n.\/gradlew toolchain-puppetmodules
Oder direkt über Puppet:
puppet apply --modulepath=<<path_to_bigtop> -e "include bigtop_toolchain::installer"\npuppet apply --modulepath=<<path_to_bigtop> -e "include bigtop_toolchain::deployment-tools"\npuppet apply --modulepath=<<path_to_bigtop> -e "include bigtop_toolchain::development-tools"Leider können bereits an diesem Punkt Schwierigkeiten auftreten. Allgemeiner Rat hier – verwenden Sie eine unterstützte Distribution, die aktuell auf dem Build-Host ist, oder versuchen Sie den Weg über Docker.
Bau
Was können wir also versuchen zu bauen? Die Antwort auf diese Frage liefert die Ausgabe des Befehls
.\/gradlew tasks Im Abschnitt Package Tasks gibt es eine Reihe von Produkten, die Endartefakte von Bigtop sind.
Sie sind an dem Suffix -rpm oder -pkg-ind zu erkennen (im Fall des Builds
in Docker). In unserem Fall ist Hadoop am interessantesten.
Lassen Sie uns versuchen, im Umfeld unseres Build-Servers zu bauen:
.\/gradlew hadoop-rpmBigtop lädt die erforderlichen Quellcodes für das spezifische Modul herunter und beginnt mit dem Build-Prozess. So ist die Funktion des Werkzeugs an Maven-Repositories und andere Quellen gebunden, was bedeutet, dass es Internetzugang benötigt.
Während des Betriebs wird eine Standardausgabe generiert. Manchmal kann man daran und an Fehlermeldungen erkennen, was schiefgelaufen ist. Manchmal ist es jedoch erforderlich, zusätzliche Informationen zu erhalten. In diesem Fall sollten die Argumente hinzugefügt werden --info oder --debug, und es kann auch hilfreich sein –stacktrace. Es gibt eine einfache Möglichkeit, einen Datensatz für spätere Anfragen an die Mailinglisten zu erstellen, wobei der Schlüssel --scan.
verwendet wird, um alle Informationen zu sammeln und in Gradle abzulegen, wonach ein Link bereitgestellt wird,
über den qualifizierte Personen nachvollziehen können, warum der Build fehlgeschlagen ist.
Es ist zu beachten, dass diese Option unerwünschte Informationen öffentlich machen kann, wie z.B. Benutzernamen, Knoten, Umgebungsvariablen usw., also seien Sie vorsichtig.
Häufig sind Fehler die Folge davon, dass einige erforderliche Komponenten für den Build nicht abgerufen werden können. In der Regel kann das Problem durch das Erstellen eines Patches behoben werden, um etwas im Quellcode zu reparieren, z.B. die Adresse in der pom.xml im Stammverzeichnis der Quellcodes. Dies erfolgt durch Erstellung und Ablage im entsprechenden Verzeichnis .\/bigtop\/bigtop-packages\/src\/common\/oozie\/ des Patches, z.B. in Form von patch2-fix.diff.
--- a\/pom.xml
+++ b\/pom.xml
@@ -136,7 +136,7 @@
central
- http:\/\/repo1.maven.org\/maven2
+ https:\/\/repo1.maven.org\/maven2
false
Wahrscheinlich müssen Sie die oben genannte Korrektur, während Sie diesen Artikel lesen, nicht selbst vornehmen.
Beim Implementieren von Patches und Anpassungen am Build-Mechanismus kann es notwendig sein, den Build über einen Reinigungsbefehl "zurückzusetzen":
.\/gradlew hadoop-clean
> Task :hadoop_vardefines
> Task :hadoop-clean
BUILD SUCCESSFUL in 5s
2 actionable tasks: 2 executedDieser Vorgang setzt alle Änderungen am Build dieses Moduls zurück, woraufhin der Build neu ausgeführt wird. Diesmal versuchen wir, das Projekt im Docker-Image zu bauen:
.\/gradlew -POS=centos-7 -Pprefix=1.2.1 hadoop-pkg-ind
> Aufgabe :hadoop-pkg-ind
Bau von 1.2.1 hadoop-pkg auf centos-7 in Docker...
+++ dirname .\/bigtop-ci\/build.sh
++ cd .\/bigtop-ci\/..
++ pwd
+ BIGTOP_HOME=\/tmp\/bigtop
+ '[' 6 -eq 0 ']'
+ [[ 6 -gt 0 ]]
+ key=--prefix
+ case $key in
+ PREFIX=1.2.1
+ shift
+ shift
+ [[ 4 -gt 0 ]]
+ key=--os
+ case $key in
+ OS=centos-7
+ shift
+ shift
+ [[ 2 -gt 0 ]]
+ key=--target
+ case $key in
+ TARGET=hadoop-pkg
+ shift
+ shift
+ [[ 0 -gt 0 ]]
+ '[' -z x ']'
+ '[' -z x ']'
+ '[' '' == true ']'
+ IMAGE_NAME=bigtop\/slaves:1.2.1-centos-7
++ uname -m
+ ARCH=x86_64
+ '[' x86_64 '!=' x86_64 ']'
++ docker run -d bigtop\/slaves:1.2.1-centos-7 \/sbin\/init
+
CONTAINER_ID=0ce5ac5ca955b822a3e6c5eb3f477f0a152cd27d5487680f77e33fbe66b5bed8
+ trap 'docker rm -f
0ce5ac5ca955b822a3e6c5eb3f477f0a152cd27d5487680f77e33fbe66b5bed8' EXIT
....
viel Ausgabe
....
Geschrieben: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-2.8.5-1.el7.x86_64.rpm
Geschrieben: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-hdfs-2.8.5-1.el7.x86_64.rpm
Geschrieben: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-yarn-2.8.5-1.el7.x86_64.rpm
Geschrieben: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-mapreduce-2.8.5-1.el7.x86_64.rpm
Geschrieben: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-hdfs-namenode-2.8.5-1.el7.x86_64.rpm
Geschrieben: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-hdfs-secondarynamenode-2.8.5-
1.el7.x86_64.rpm
Geschrieben: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-hdfs-zkfc-2.8.5-1.el7.x86_64.rpm
Geschrieben: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-hdfs-journalnode-2.8.5-
1.el7.x86_64.rpm
Geschrieben: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-hdfs-datanode-2.8.5-1.el7.x86_64.rpm
Geschrieben: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-httpfs-2.8.5-1.el7.x86_64.rpm
Geschrieben: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-yarn-resourcemanager-2.8.5-
1.el7.x86_64.rpm
Geschrieben: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-yarn-nodemanager-2.8.5-
1.el7.x86_64.rpm
Geschrieben: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-yarn-proxyserver-2.8.5-
1.el7.x86_64.rpm
Geschrieben: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-yarn-timelineserver-2.8.5-
1.el7.x86_64.rpm
Geschrieben: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-mapreduce-historyserver-2.8.5-
1.el7.x86_64.rpm
Geschrieben: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-client-2.8.5-1.el7.x86_64.rpm
Geschrieben: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-conf-pseudo-2.8.5-1.el7.x86_64.rpm
Geschrieben: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-doc-2.8.5-1.el7.x86_64.rpm
Geschrieben: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-libhdfs-2.8.5-1.el7.x86_64.rpm
Geschrieben: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-libhdfs-devel-2.8.5-1.el7.x86_64.rpm
Geschrieben: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-hdfs-fuse-2.8.5-1.el7.x86_64.rpm
Geschrieben: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-debuginfo-2.8.5-1.el7.x86_64.rpm
+ umask 022
+ cd \/bigtop\/build\/hadoop\/rpm\/\/BUILD
+ cd hadoop-2.8.5-src
+ \/usr\/bin\/rm -rf \/bigtop\/build\/hadoop\/rpm\/BUILDROOT\/hadoop-2.8.5-1.el7.x86_64
Ausführen(%clean): \/bin\/sh -e \/var\/tmp\/rpm-tmp.uQ2FCn
+ exit 0
+ umask 022
Ausführen(--clean): \/bin\/sh -e \/var\/tmp\/rpm-tmp.CwDb22
+ cd \/bigtop\/build\/hadoop\/rpm\/\/BUILD
+ rm -rf hadoop-2.8.5-src
+ exit 0
[ant:touch] Erstelle \/bigtop\/build\/hadoop\/.rpm
:hadoop-rpm (Thread[Task worker for ':',5,main]) abgeschlossen. Dauert 38 Minuten 1.151 Sekunden.
:hadoop-pkg (Thread[Task worker for ':',5,main]) gestartet.
> Aufgabe :hadoop-pkg
Aufgabe ':hadoop-pkg' ist nicht auf dem neuesten Stand, weil:
Aufgabe hat keine Ausgaben deklariert, obwohl sie Aktionen ausgeführt hat.
:hadoop-pkg (Thread[Task worker for ':',5,main]) abgeschlossen. Dauert 0.0 Sekunden.
BUILD ERFOLGREICH in 40m 37s
6 umsetzbare Aufgaben: 6 ausgeführt
+ RESULT=0
+ mkdir -p output
+ docker cp
ac46014fd9501bdc86b6c67d08789fbdc6ee46a2645550ff6b6712f7d02ffebb:\/bigtop\/build .
+ docker cp
ac46014fd9501bdc86b6c67d08789fbdc6ee46a2645550ff6b6712f7d02ffebb:\/bigtop\/output .
+ docker rm -f ac46014fd9501bdc86b6c67d08789fbdc6ee46a2645550ff6b6712f7d02ffebb
ac46014fd9501bdc86b6c67d08789fbdc6ee46a2645550ff6b6712f7d02ffebb
+ '[' 0 -ne 0 ']'
+ docker rm -f ac46014fd9501bdc86b6c67d08789fbdc6ee46a2645550ff6b6712f7d02ffebb
Fehler: Kein solches Container:
ac46014fd9501bdc86b6c67d08789fbdc6ee46a2645550ff6b6712f7d02ffebb
BUILD ERFOLGREICH in 41m 24s
1 umsetzbare Aufgabe: 1 ausgeführtDie Zusammenstellung erfolgte unter CentOS, kann aber auch unter Ubuntu durchgeführt werden:
.\/gradlew -POS=ubuntu-16.04 -Pprefix=1.2.1 hadoop-pkg-indNeben der Paketzerlegung für verschiedene Linux-Distributionen kann das Tool auch ein Repository mit kompilierten Paketen erstellen, zum Beispiel:
.\/gradlew yumAußerdem kann man an die Smoke-Tests und das Deployment in Docker denken.
Erstellen Sie einen Cluster aus drei Knoten:
.\/gradlew -Pnum_instances=3 docker-provisionerFühren Sie Smoke-Tests in einem Cluster aus drei Knoten durch:
.\/gradlew -Pnum_instances=3 -Prun_smoke_tests docker-provisionerCluster löschen:
.\/gradlew docker-provisioner-destroyErhalten Sie die Befehle zum Verbinden mit den Docker-Containern:
.\/gradlew docker-provisioner-sshStatus anzeigen:
.\/gradlew docker-provisioner-statusWeitere Informationen zu Deployment-Tasks finden Sie in der Dokumentation.
Bei den Tests handelt es sich um eine erhebliche Anzahl, hauptsächlich um Smoke-Tests und Integrationstests. Ihre Analyse liegt außerhalb des Rahmens dieses Artikels. Ich kann nur sagen, dass die Erstellung einer Distribution nicht so schwierig ist, wie sie auf den ersten Blick erscheinen mag. Alle Komponenten, die wir in unserer Produktion verwenden, konnten kompiliert und erfolgreich getestet werden, und wir hatten auch keine Probleme mit ihrem Deployment und der Ausführung grundlegender Operationen in einer Testumgebung.
Neben den bestehenden Komponenten in Bigtop gibt es die Möglichkeit, zusätzliche Entwicklungen, sogar eigene Software, hinzuzufügen. All dies wird hervorragend automatisiert und passt in das CI/CD-Konzept.
Fazit
Offensichtlich sollte eine so erstellte Distribution nicht sofort in die Produktion geschickt werden. Es ist wichtig zu verstehen, dass, wenn es einen echten Bedarf an der Erstellung und Unterstützung Ihrer eigenen Distribution gibt, dies finanziell und zeitlich investiert werden muss.
Dennoch ist es in Kombination mit dem richtigen Ansatz und einem professionellen Team durchaus möglich, ohne kommerzielle Lösungen auszukommen.
Es ist wichtig zu betonen, dass das Projekt Bigtop selbst einer Weiterentwicklung bedarf und es scheint, dass zurzeit keine aktive Entwicklung stattfindet. Auch die Perspektive der Einführung von Hadoop 3 in ihm ist unklar. Übrigens, wenn Sie einen echten Bedarf an der Erstellung von Hadoop 3 haben, können Sie sich den von Arenadata ansehen, der neben den Standard-
Komponenten auch eine Reihe zusätzlicher (Ranger, Knox, NiFi) umfasst.
Was Rostelecom betrifft, so ist Bigtop für uns eine der Optionen, die wir derzeit in Betracht ziehen. Ob wir uns für ihn entscheiden oder nicht, wird die Zeit zeigen.
Anhang
Um eine neue Komponente in das Build aufzunehmen, muss ihre Beschreibung in bigtop.bom und ./bigtop-packages hinzugefügt werden. Sie können versuchen, dies analog zu den vorhandenen Komponenten zu tun. Versuchen Sie, es herauszufinden. Es ist nicht so schwierig, wie es auf den ersten Blick erscheint.
Was denken Sie darüber? Wir würden uns freuen, Ihre Meinung in den Kommentaren zu sehen, und vielen Dank für Ihre Aufmerksamkeit!
Der Artikel wurde vom Datenmanagement-Team von "Rostelecom" vorbereitet
Quelle: habr.com
