Es ist wahrscheinlich kein Geheimnis, dass das letzte Jahr eine Zeit großer Veränderungen für Apache Hadoop war. Im vergangenen Jahr fand die Fusion von Cloudera und Hortonworks statt (praktisch die Übernahme des Letzteren), während MapR aufgrund schwerwiegender finanzieller Probleme an Hewlett Packard verkauft wurde. Wenn man vor einigen Jahren bei On-Premises-Installationen normalerweise zwischen Cloudera und Hortonworks wählen konnte, so bleibt uns heute dieser Auswahl leider nicht mehr. Überraschend war auch die Tatsache, dass Cloudera seit Februar dieses Jahres die Veröffentlichung von Binärversionen seiner Distribution im öffentlichen Repository eingestellt hat und diese nun nur noch über ein kostenpflichtiges Abonnement erhältlich 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 für diese Versionen wird für ein oder zwei Jahre vorgesehen. Aber was nun? Für diejenigen, die zuvor für ein Abonnement gezahlt haben, hat sich nichts geändert. Für diejenigen, die nicht auf die kostenpflichtige Version der Distribution wechseln möchten, aber dennoch die neuesten Versionen der Clusterkomponenten sowie Patches und andere Updates erhalten möchten, haben wir diesen Artikel vorbereitet. Darin betrachten wir mögliche Lösungsansätze für die aktuelle Situation.
Dieser Artikel ist eher ein Überblick. Er wird keinen Vergleich der Distributionen und deren detaillierte Analyse enthalten, ebenso wenig wie Installations- und Konfigurationstipps. Was wird er jedoch bieten? Wir werden kurz über die Distribution Arenadata Hadoop sprechen, die aufgrund ihrer Verfügbarkeit unsere Aufmerksamkeit verdient, was heutzutage eine Seltenheit ist. Anschließend werden wir Vanilla Hadoop diskutieren, hauptsächlich darüber, wie man es mit Apache Bigtop "zubereiten" kann. Bereit? Dann heißen wir Sie herzlich willkommen.
Arenadata Hadoop
Es handelt sich um eine ganz neue und noch wenig bekannte Distribution aus inländischer Entwicklung. Leider gibt es zum aktuellen Zeitpunkt im Habr darüber nur .
Weitere Informationen finden Sie auf der offiziellen Projekts. Die neuesten 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 Fahrplan finden Sie .
Die 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 angeboten, und seine Funktionalität wird durch das Hinzufügen von Bundles erweitert, die eine Sammlung von Ansible-Playbooks darstellen. Die Bundles werden in zwei Arten unterteilt: Enterprise und Community. Letztere sind kostenlos von der Arenadata-Website herunterladbar. Es besteht auch 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 in Kombination mit ADCM angeboten, während für Hadoop 2 nur als Alternative verfügbar ist. Was die Repositorys mit den Paketen betrifft, so sind sie öffentlich zugänglich und können wie gewohnt für alle Komponenten des Clusters heruntergeladen und installiert werden. Insgesamt macht das Distributionspaket einen sehr vielversprechenden Eindruck. Ich bin mir sicher, dass es Nutzer gibt, die an Lösungen wie Cloudera Manager und Ambari gewöhnt sind und auch ADCM zu schätzen wissen. Für einige wird es auch ein großer Vorteil sein, dass das Distributionspaket für die Importsubstitution enthalten ist.
Wenn wir über die Nachteile sprechen, sind diese dieselben, die für alle anderen Hadoop-Distributionen gelten. Und zwar:
- Der sogenannte „Vendor Lock-in“. Am Beispiel von Cloudera und Hortonworks haben wir bereits erkannt, dass immer das Risiko besteht, dass sich die Unternehmenspolitik ändert.
- Deutlicher Rückstand gegenüber dem Apache-Upstream.
Vanilla Hadoop
Wie Sie wissen, ist Hadoop kein monolithisches Produkt, sondern besteht im Wesentlichen aus einer Vielzahl von Diensten rund um sein verteiltes Dateisystem HDFS. Nur ein einzelnes Dateikluster reicht den wenigsten aus. Einige benötigen Hive, andere Presto, und dann gibt es noch HBase und Phoenix; zunehmend wird auch Spark verwendet. Für die Orchestrierung und Datenladung kommen manchmal Oozie, Sqoop und Flume zum Einsatz. Wenn es um Sicherheit geht, denkt man sofort an Kerberos in Verbindung mit Ranger.
Die binäre Version der Hadoop-Komponenten ist auf der Website jedes Projekts des Ökosystems in Form von Tarballs verfügbar. Sie können diese herunterladen und mit der Installation beginnen, jedoch mit einem Vorbehalt: Abgesehen von der aufwendigen Paketkompilierung aus "rohen" Binarien, die Sie wahrscheinlich durchführen möchten, haben Sie keine Gewissheit über die Kompatibilität der heruntergeladenen Versionen der Komponenten untereinander. Eine bevorzugte Option ist die Kompilierung mit Apache Bigtop. Bigtop ermöglicht die Kompilierung aus den Maven-Repositories von Apache, das Ausführen von Tests und das Erstellen von Paketen. Was für uns von großer Bedeutung ist, ist, dass Bigtop die Versionen der Komponenten erstellt, die miteinander kompatibel sind. Darüber werden wir später ausführlicher berichten.
Apache Bigtop
Apache Bigtop ist ein Werkzeug zum Erstellen, Verpacken und Testen einer Reihe von
Open-Source-Projekten, wie zum Beispiel Hadoop und Greenplum. Bigtop hat zahlreiche
Versionen. Zum Zeitpunkt des Verfassens des Artikels war die letzte stabile Version 1.4,
während in der Master-Version 1.5 verfügbar war. In 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, und in der Master-Version
2.10.0. Die unterstützten Komponenten verändern sich. Etwas Altes und nicht mehraktualisiertes wird entfernt, während neue, gefragtere Alternativen hinzukommen, und
es handelt sich dabei nicht unbedingt um etwas aus der Apache-Familie.
Zusätzlich bietet Bigtop eine Vielzahl von
Forks. .
Als Teaser – diejenigen, die einst Projekte der Linux-Welt wie Gentoo und LFS schätzten, werden möglicherweise nostalgisch erfreut sein, mit diesem Ding zu arbeiten und sich an die "legendären" Zeiten zu erinnern, in denen wir selbst nach (oder auch geschriebenen) ebuilds suchten und regelmäßig mit neuen Patches Mozilla neu kompilierten.
Als Teaser — für diejenigen, die zu ihrer Zeit Projekte wie Gentoo und LFS aus dem Linux-Universum schätzten, könnte es nostalgisch angenehm sein, mit diesem Teil zu arbeiten und sich an die "legendären" Zeiten zu erinnern, als wir selbst ebuilds suchten (oder sogar schrieben) und Mozilla regelmäßig mit neuen Patches neu compilierten.
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 das Werkzeug bekannt, mit dem Google Android baut. Es ist flexibel und, wie man so schön sagt, „im Einsatz erprobt“. Maven ist das offizielle Build-Tool innerhalb von Apache, und da die meisten seiner Produkte genau über Maven veröffentlicht werden, kommt man auch hier nicht ohne es aus. Besonders erwähnenswert ist das POM (Project Object Model) – eine „fundamentale“ XML-Datei mit einer Beschreibung alles Wichtigen für die Arbeit von Maven mit Ihrem Projekt, um die herum die gesamte Arbeit organisiert wird. Genau in
der Maven-Integration treten einige Hindernisse auf, auf die Anfänger, die sich zum ersten Mal mit Bigtop beschäftigen, normalerweise stoßen.
Praxis
Also, womit sollte man anfangen? Gehen Sie zur Download-Seite und laden Sie die neueste stabile Version als Archiv herunter. Dort finden Sie auch die binären Artefakte, die von Bigtop erstellt wurden. Übrigens werden gängige Paketmanager wie YUM und APT unterstützt.
Alternativ können Sie die neueste stabile Version direkt von
github herunterladen:
$ git clone --branch branch-1.4 https://github.com/apache/bigtop.gitKlonen in „bigtop“…
remote: Zähle Objekte: 46, abgeschlossen.
remote: Zähle Objekte: 100 % (46/46), abgeschlossen.
remote: Komprimieren von Objekten: 100 % (41/41), abgeschlossen.
remote: Insgesamt 40217 (delta 14), 10 wiederverwendet (delta 1), pack-wiederverwendet 40171
Objekte abrufen: 100 % (40217/40217), 43,54 MiB | 1,05 MiB/s, bereit.
Änderungen ermitteln: 100 % (20503/20503), bereit.
Dateien aktualisieren: 100 % (1998/1998), bereit.Das Verzeichnis ./bigtop sieht ungefähr so aus:
./bigtop-bigpetstore — Demoversionen, synthetische Beispiele
./bigtop-ci — CI-Toolkit, Jenkins
./bigtop-data-generators — Daten generieren, synthetisch, für Smoke-Tests usw.
./bigtop-deploy — Bereitstellungstools
./bigtop-packages — Konfigurationen, Skripte, Patches für den Build, Hauptteil des Tools
./bigtop-test-framework — Testframework
./bigtop-tests — die Tests selbst, Last- und Smoke-Tests
./bigtop_toolchain — Build-Umgebung, Vorbereitung der Umgebung für das Tool
./build — Arbeitsverzeichnis für den Build
./dl — Verzeichnis für heruntergeladene Quellcodes
./docker — Build in Docker-Images, Testen
./gradle — Gradle-Konfiguration
./output – Verzeichnis, in das die Build-Artefakte gelangen
./provisioner — Provisionierung
Am interessantesten ist uns in dieser Phase die Hauptkonfiguration ./bigtop/bigtop.bom, in dem wir alle unterstützten Komponenten mit ihren Versionen sehen. Hier können wir eine andere Produktversion angeben (wenn wir sie ausprobieren möchten) oder die Version des Builds (wenn wir beispielsweise einen signifikanten Patch hinzugefügt haben).
Ein besonderes Interesse weckt auch das Verzeichnis ./bigtop/bigtop-packages, das direkt mit dem Prozess des Zusammenbaus der Komponenten und deren Paketen zusammenhängt.
Also, wir haben das Archiv heruntergeladen, entpackt oder ein Klon von GitHub erstellt. Können wir mit dem Aufbau beginnen?
Nein, zuerst müssen wir die Umgebung vorbereiten.
Umgebungsvorbereitung
Hier ist ein kleiner Exkurs erforderlich. Für den Zusammenbau eines nahezu beliebigen, mehr oder weniger komplexen Produkts ist eine bestimmte Umgebung erforderlich – in unserem Fall das JDK, dieselben Shared Libraries, Header-Dateien usw., Werkzeuge wie Ant, Ivy2 und vieles mehr. Eine Möglichkeit, die benötigte Umgebung für Bigtop zu erhalten, besteht darin, die erforderlichen Komponenten auf dem Build-Host zu installieren. Ich könnte mit der Chronologie falsch liegen, aber ich glaube, ab Version 1.0 wurde auch die Option eingeführt, in vorab konfigurierten und verfügbaren Docker-Images zu bauen; diese können hier eingesehen werden.
Für die Einrichtung der Umgebung gibt es einen Assistenten – Puppet.
Es können die folgenden Befehle verwendet werden, der Start erfolgt aus dem Wurzelverzeichnis
des Werkzeugs, ./bigtop:
./gradlew toolchain
./gradlew toolchain-devtools
./gradlew toolchain-puppetmodules
Oder direkt über Puppet:
puppet apply --modulepath= -e "include bigtop_toolchain::installer"
puppet apply --modulepath= -e "include bigtop_toolchain::deployment-tools"
puppet apply --modulepath= -e "include bigtop_toolchain::development-tools"Leider können bereits an diesem Punkt Schwierigkeiten auftreten. Der allgemeine Hinweis hier ist, eine unterstützte Distribution zu verwenden, die aktuell auf dem Build-Host ist, oder den Weg über Docker zu versuchen.
Zusammenbau
Was können wir also versuchen zu bauen? Die Antwort auf diese Frage liefert die Ausgabe des Befehls
./gradlew tasks In der Kategorie Package tasks gibt es eine Reihe von Produkten, die die endgültigen Artefakte von Bigtop sind.
Diese können anhand des Suffixes -rpm oder -pkg-ind (im Fall des Builds
in Docker) identifiziert werden. In unserem Fall ist das Interessanteste Hadoop.
Versuchen wir, den Build in der Umgebung unseres Build-Servers auszuführen:
./gradlew hadoop-rpmBigtop lädt automatisch die benötigten Quellcodes für die spezifischen Komponenten herunter und startet den Build-Prozess. Dadurch ist das Tool auf Maven-Repositories und andere Quellen angewiesen, was bedeutet, dass es Internetzugang benötigt.
Während der Arbeit wird eine Standardausgabe erzeugt. Manchmal können anhand dieser Ausgabe und von Fehlermeldungen Rückschlüsse gezogen werden, was schiefgelaufen ist. In anderen Fällen ist es notwendig, weitere Informationen zu erhalten. In diesem Fall sollten Sie die Argumente hinzufügen, --info oder --debug, und möglicherweise ist auch --stacktracenützlich. Es gibt eine praktische Möglichkeit, ein Datenset für eine spätere Rücksprache in Mailinglisten zu erstellen, den Schlüssel --scan.
. Mit diesem Befehl sammelt Bigtop alle erforderlichen Informationen und gibt sie in Gradle aus, wonach ein Link bereitgestellt wird,
über den ein kompetenter Ansprechpartner nachvollziehen kann, warum der Build fehlgeschlagen ist.
Es ist zu beachten, dass diese Option möglicherweise unerwünschte Informationen öffentlich macht, wie beispielsweise Benutzernamen, Knoten, Umgebungsvariablen usw. Seien Sie daher vorsichtig.
Häufig sind Fehler die Folge davon, dass benötigte Komponenten für den Aufbau nicht verfügbar sind. In der Regel lässt sich das Problem durch das Erstellen eines Patches beheben, um zum Beispiel etwas in den Quellcodes zu korrigieren, wie die Adresse in der pom.xml im Stammverzeichnis der Quellen. Dies erfolgt durch das Erstellen und Platzieren des Patches im entsprechenden Verzeichnis. ./bigtop/bigtop-packages/src/common/oozie/ Patch, zum Beispiel 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 zur Zeit des Lesens dieses Artikels die oben angegebene Korrektur nicht selbst durchführen.
Beim Einfügen von Patches und Änderungen im Build-Mechanismus kann es erforderlich sein, den Build über den Bereinigungsvorgang '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 dieser Komponente zurück, woraufhin der Build erneut durchgeführt wird. Dieses Mal versuchen wir, das Projekt im Docker-Image zu erstellen:
./gradlew -POS=centos-7 -Pprefix=1.2.1 hadoop-pkg-ind
> Aufgabe :hadoop-pkg-ind
Erstelle 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, da:
Aufgabe hat keine Ausgaben deklariert, obwohl Aktionen ausgeführt wurden.
:hadoop-pkg (Thread[Task worker for ':',5,main]) abgeschlossen. Dauert 0,0 Sekunden.
BAU 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
BAU ERFOLGREICH in 41m 24s
1 umsetzbare Aufgabe: 1 ausgeführtDie Erstellung wurde unter CentOS durchgeführt, es ist jedoch auch unter Ubuntu möglich:
./gradlew -POS=ubuntu-16.04 -Pprefix=1.2.1 hadoop-pkg-indNeben dem Erstellen von Paketen für verschiedene Linux-Distributionen kann das Tool auch ein Repository mit den erstellten Paketen generieren, beispielsweise:
./gradlew yumAußerdem kann man an Smoke-Tests und die Bereitstellung in Docker denken.
Ein Cluster aus drei Nodes erstellen:
./gradlew -Pnum_instances=3 docker-provisionerSmoke-Tests im Cluster mit drei Nodes ausführen:
./gradlew -Pnum_instances=3 -Prun_smoke_tests docker-provisionerCluster löschen:
./gradlew docker-provisioner-destroyBefehle zum Verbinden mit den Docker-Containern abrufen:
./gradlew docker-provisioner-sshStatus anzeigen:
./gradlew docker-provisioner-statusWeitere Informationen zu Deployment-Aufgaben finden Sie in der Dokumentation.
Was die Tests angeht, gibt es eine Vielzahl, hauptsächlich Smoke- und Integrationstests. Ihre Analyse liegt außerhalb des Rahmens dieses Artikels. Ich möchte nur sagen, dass das Erstellen der Distribution nicht so kompliziert ist, wie es auf den ersten Blick erscheinen mag. Alle Komponenten, die wir in unserer produktiven Umgebung verwenden, konnten erfolgreich zusammengebaut und getestet werden. Zudem traten keine Probleme beim Deployment und der Ausführung grundlegender Operationen in der Testumgebung auf.
Neben den vorhandenen Komponenten in Bigtop besteht die Möglichkeit, noch weitere hinzuzufügen, sogar eigene Softwareentwicklungen. All dies lässt sich hervorragend automatisieren und passt perfekt in das CI/CD-Konzept.
Fazit
Es ist offensichtlich, dass ein auf diese Weise zusammengesetztes Distribution nicht sofort in die Produktion geschickt werden sollte. Man muss verstehen, dass, wenn es einen echten Bedarf gibt, ein eigenes Distribution zu erstellen und zu warten, es finanziellen und zeitlichen Aufwand erfordert.
Dennoch ist es 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 weiterentwickelt werden muss und es derzeit anscheinend keine aktive Entwicklung gibt. Auch die Perspektive auf die Unterstützung von Hadoop 3 ist unklar. Übrigens, wenn Sie einen echten Bedarf haben, Hadoop 3 zu bauen, können Sie sich mal von Arenadata anschauen, das neben den Standard-
Komponenten auch eine ganze Reihe zusätzlicher (Ranger, Knox, NiFi) bietet.
Was Ростелеком 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 zur Sammlung hinzuzufügen, müssen Sie deren Beschreibung in bigtop.bom und ./bigtop-packages einfügen. Sie können dies versuchen, indem Sie sich an den vorhandenen Komponenten orientieren. Versuchen Sie, sich damit auseinanderzusetzen. Es ist nicht so kompliziert, wie es auf den ersten Blick scheint.
Was denken Sie darüber? Wir würden uns freuen, Ihre Meinung in den Kommentaren zu sehen. Vielen Dank für Ihre Aufmerksamkeit!
Dieser Artikel wurde vom Datenmanagement-Team von "Rostelecom" erstellt.
Quelle: habr.com
