Probabilmente non è un segreto per nessuno che lo scorso anno sia stato un anno di grandi cambiamenti per Apache Hadoop. L'anno scorso si è verificata la fusione di Cloudera e Hortonworks (di fatto, l'acquisizione della seconda), e Mapr, a causa di gravi problemi finanziari, è stata venduta a Hewlett Packard. E se un paio di anni fa, nel caso di installazioni on-premises, la scelta era spesso tra Cloudera e Hortonworks, oggi, purtroppo, non abbiamo più questa possibilità. È stata sorprendente anche la notizia che Cloudera ha annunciato a febbraio di quest'anno la cessazione della distribuzione delle versioni binarie del proprio pacchetto in repository pubblici, disponibili ora solo tramite abbonamento a pagamento. Certo, la possibilità di scaricare le ultime versioni di CDH e HDP rilasciate entro la fine del 2019 è ancora disponibile, e il supporto per queste versioni è previsto per uno o due anni. Ma cosa fare dopo? Per coloro che in precedenza avevano pagato un abbonamento, nulla è cambiato. E per chi non vuole passare alla versione a pagamento del pacchetto ma desidera comunque avere accesso alle nuove versioni dei componenti del cluster, nonché patch e altri aggiornamenti, abbiamo preparato questo articolo. Qui esamineremo le possibili soluzioni a questa situazione.
L'articolo è più di carattere informativo. Non ci sarà un confronto dettagliato tra i pacchetti né una disamina approfondita, e neanche ricette per la loro installazione e configurazione. E cosa ci sarà? Riporteremo brevemente un pacchetto come Arenadata Hadoop, che merita la nostra attenzione per la sua accessibilità, una rarità al giorno d'oggi. Dopo parleremo di Vanilla Hadoop, principalmente di come si può "preparare" utilizzando Apache Bigtop. Pronti? Allora benvenuti nel nostro approfondimento.
Arenadata Hadoop
Si tratta di un pacchetto completamente nuovo e, per ora, poco conosciuto, sviluppato a livello nazionale. Purtroppo, attualmente su Habr ci sono solo .
Informazioni più dettagliate possono essere trovate sul sito ufficiale del progetto. Le ultime versioni del pacchetto sono basate su Hadoop 3.1.2 per la terza versione e 2.8.5 per la seconda versione.
Le informazioni sul roadmap sono disponibili .
L'interfaccia di Arenadata Cluster Manager
Il prodotto chiave di Arenadata è , utilizzato per installare, configurare e monitorare varie soluzioni software dell'azienda. ADCM è distribuito gratuitamente e le sue funzionalità possono essere ampliate attraverso l'aggiunta di bundle, costituenti un insieme di ansible-playbooks. I bundle sono divisi in due categorie: enterprise e community. I secondi sono disponibili per il download gratuito dal sito di Arenadata. È anche possibile sviluppare il proprio bundle e collegarlo a ADCM.
Per il deployment e la gestione di Hadoop 3 è disponibile la versione community del bundle in combinazione con ADCM, mentre per Hadoop 2 c'è solo come alternativa. Per quanto riguarda i repository con i pacchetti, sono aperti al pubblico, e possono essere scaricati e installati in modo consueto per tutti i componenti del cluster. In generale, il pacchetto sembra molto interessante. Sono sicuro che ci saranno quelli abituati a soluzioni come Cloudera Manager e Ambari, a cui piacerà ADCM. Per qualcuno sarà un grande vantaggio anche il fatto che il pacchetto per la sostituzione delle importazioni.
Se parliamo dei lati negativi, questi saranno gli stessi di tutti gli altri pacchetti Hadoop. Vale a dire:
- Il cosiddetto «vendor lock-in». L'esempio di Cloudera e Hortonworks ci ha già mostrato che c'è sempre il rischio di un cambiamento di politica aziendale.
- Un sostanziale ritardo rispetto all'upstream di Apache.
Vanilla Hadoop
Come sapete, Hadoop non è un prodotto monolitico, ma, di fatto, un insieme di servizi attorno al suo sistema di file distribuito HDFS. Raramente a qualcuno basta un semplice cluster di file. Alcuni hanno bisogno di Hive, altri di Presto, ci sono anche HBase e Phoenix, e Spark viene utilizzato sempre più spesso. Per l'orchestrazione e il caricamento dei dati si incontrano talvolta Oozie, Sqoop e Flume. E se si pone la questione della sicurezza, subito si pensa a Kerberos in combinazione con Ranger.
Le versioni binarie dei componenti Hadoop sono disponibili sul sito di ciascun progetto dell'ecosistema come tarballs. Possono essere scaricati e installati, ma con una condizione: oltre alla compilazione autonoma dei pacchetti dai «raw» binari, che probabilmente si desidera eseguire, non si avrà alcuna certezza sulla compatibilità delle versioni dei componenti scaricati tra loro. Un'opzione molto più preferibile è la compilazione tramite Apache Bigtop. Bigtop consentirà di eseguire la compilazione dai repository Maven di Apache, eseguire test e compilare pacchetti. Ma, ciò che per noi è molto importante, Bigtop compilerà quelle versioni dei componenti che saranno compatibili tra loro. Di questo parleremo più nel dettaglio in seguito.
Apache Bigtop
Apache Bigtop è uno strumento per la compilazione, il packaging e il test di una serie di
progetti open source, come Hadoop e Greenplum. Bigtop ha una vasta gamma di
rilasci. Al momento della scrittura dell'articolo, l'ultima versione stabile era la 1.4,
mentre nella master era presente la 1.5. Diverse versioni dei rilasci utilizzano diverse versioni
dei componenti. Ad esempio, per la 1.4, i core-componenti di Hadoop hanno la versione 2.8.5, mentre nella master
si trova 2.10.0. Cambia anche la composizione dei componenti supportati. Alcuni componenti obsoleti e
non aggiornabili vengono sostituiti da nuove soluzioni più richieste, e
non è necessariamente qualcosa proveniente dalla famiglia Apache stessa.
Inoltre, Bigtop ha una grande varietà di .
Quando abbiamo iniziato a conoscere Bigtop, siamo rimasti colpiti dalla sua modesta diffusione e popolarità, rispetto ad altri progetti Apache, così come dalla sua comunità piuttosto ristretta. Di conseguenza, ci sono poche informazioni sul prodotto e la ricerca di soluzioni a problemi emersi sui forum e nelle mailing list potrebbe non fornire alcun risultato. Inizialmente, ci è sembrato difficile eseguire una build completa del pacchetto a causa delle peculiarità dello strumento stesso, ma di questo parleremo un po' più tardi.
Come teaser – a chi in passato è piaciuto lavorare con progetti dell'universo Linux, come Gentoo e LFS, potrebbe sembrare nostalgico rituffarsi in questo strumento e ricordare quei "tempi antichi" in cui cercavamo (e talvolta scrivevamo) ebuild e ricompilavamo regolarmente con nuove patch Mozilla.
Un grande punto a favore di Bigtop è la trasparenza e la versatilità degli strumenti su cui è basato. Alla sua base ci sono Gradle e Apache Maven. Gradle è piuttosto noto come lo strumento con cui Google compila Android. È flessibile e, come si suol dire, "testato in battaglia". Maven, d'altra parte, è lo strumento standard per la compilazione dei progetti in Apache e, poiché la maggior parte dei suoi prodotti è rilasciata tramite Maven, non si può fare a meno di lui. Vale la pena prestare attenzione al POM (project object model) – un file xml "fondamentale" che descrive tutto il necessario per il funzionamento di Maven con il tuo progetto, attorno al quale si sviluppa tutto il lavoro. È proprio nella
parte di Maven che si presentano alcune difficoltà che di solito si incontrano la prima volta che ci si avvicina a Bigtop.
Pratica
Quindi, da dove iniziare? Andiamo alla pagina di download e scarichiamo l'ultima versione stabile come archivio. Qui è possibile trovare anche gli artefatti binari compilati da Bigtop. A proposito, tra i gestori di pacchetti più comuni sono supportati YUM e APT.
Come alternativa, è possibile scaricare direttamente l'ultimo rilascio stabile da
github:
$ git clone --branch branch-1.4 https://github.com/apache/bigtop.gitClonazione in "bigtop"...
remote: Enumerating objects: 46, done.
remote: Counting objects: 100% (46/46), done.
remote: Compressing objects: 100% (41/41), done.
remote: Total 40217 (delta 14), reused 10 (delta 1), pack-reused 40171
Ricezione oggetti: 100% (40217/40217), 43.54 MiB | 1.05 MiB/s, fatto.
Determinazione delle modifiche: 100% (20503/20503), fatto.
Aggiornamento file: 100% (1998/1998), fatto.La directory risultante ./bigtop appare più o meno così:
./bigtop-bigpetstore — applicazioni dimostrative, esempi sintetici
./bigtop-ci — strumenti CI, jenkins
./bigtop-data-generators — generazione di dati, sintesi, per smoke test ecc.
./bigtop-deploy — strumenti per il deployment
./bigtop-packages — configurazioni, script, patch per la compilazione, la parte principale dello strumento
./bigtop-test-framework — framework di test
./bigtop-tests — i test stessi, carico e smoke
./bigtop_toolchain — ambiente per la build, preparazione dell'ambiente per il lavoro dello strumento
./build — directory di lavoro per la build
./dl — directory per i sorgenti scaricati
./docker — compilazione in immagini docker, testing
./gradle — configurazione di gradle
./output – directory dove si trovano gli artefatti della build
./provisioner — provisioning
La cosa più interessante in questo stadio per noi è la configurazione principale ./bigtop/bigtop.bom, in cui vediamo tutti i componenti supportati con le loro versioni. È qui che possiamo indicare una versione diversa del prodotto (se vogliamo provare a compilarla) o una versione di build (se, ad esempio, abbiamo aggiunto una patch significativa).
Cattura anche molto interesse la sottodirectory ./bigtop/bigtop-packages, che ha diretta relazione con il processo di compilazione di componenti e pacchetti.
Quindi, abbiamo scaricato l'archivio, lo abbiamo estratto o abbiamo fatto un clone da github, possiamo iniziare a compilarlo?
No, prima prepariamo l'ambiente.
Preparazione dell'ambiente
E qui è necessaria una piccola digressione. Per costruire praticamente qualsiasi prodotto più o meno complesso è necessario avere un ambiente specifico: nel nostro caso si tratta di JDK, le librerie condivise necessarie, i file di intestazione, strumenti come ant, ivy2 e molto altro. Una delle opzioni per ottenere l'ambiente richiesto per Bigtop è l'installazione dei componenti necessari sull'host di build. Potrei sbagliarmi sulla cronologia, ma sembra che dalla versione 1.0 sia stata introdotta anche la possibilità di costruire usando immagini docker preconfigurate e disponibili, che si possono consultare qui.
Per quanto riguarda la preparazione dell'ambiente, c'è un aiuto disponibile: Puppet.
Si possono utilizzare i seguenti comandi, l'esecuzione avviene dalla directory radice
dell'utensile, ./bigtop:
./gradlew toolchain
./gradlew toolchain-devtools
./gradlew toolchain-puppetmodules
Oppure direttamente tramite 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"Purtroppo, già a questo punto potrebbero sorgere delle difficoltà. Un consiglio generale è di utilizzare una distribuzione supportata, aggiornata sull'host di build, oppure provare a procedere con docker.
Build
Cosa possiamo provare a costruire? La risposta a questa domanda è fornita dall'output del comando
./gradlew tasks Nella sezione Package tasks ci sono diversi prodotti che rappresentano artefatti finali di Bigtop.
Possono essere identificati dal suffisso -rpm o -pkg-ind (nel caso di costruzione
in docker). Nel nostro caso, l'elemento più interessante è Hadoop.
Proviamo a eseguire la costruzione nell'ambiente del nostro server di build:
./gradlew hadoop-rpmBigtop scaricherà automaticamente le sorgenti necessarie per il componente specifico e avvierà la costruzione. Pertanto, il funzionamento dello strumento dipende dai repository Maven e da altre fonti, il che significa che ha bisogno di accesso a Internet.
Durante il processo di lavoro viene generato un output standard. Talvolta, da questo e dai messaggi di errore, si può capire cosa sia andato storto. In altre occasioni, è necessario ottenere ulteriori informazioni. In questo caso, è utile aggiungere gli argomenti --info o --debug, e potrebbe essere utile –stacktrace. Esiste un modo comodo per raccogliere un insieme di dati per successivi riferimenti nelle mailing list, la chiave --scan.
Con questa opzione, bigtop raccoglierà tutte le informazioni e le organizzerà in gradle, dopodiché fornirà un link,
attraverso il quale una persona competente sarà in grado di capire perché la costruzione non è riuscita.
Si deve tenere presente che questa opzione potrebbe rendere pubbliche informazioni indesiderate, come nomi utenti, nodi, variabili di ambiente, ecc., quindi siate cauti.
Spesso, gli errori derivano dall'incapacità di ottenere alcuni componenti necessari per la costruzione. In genere, il problema può essere risolto creando una patch per correggere qualcosa nel codice sorgente, ad esempio l'indirizzo in pom.xml nella directory principale delle sorgenti. Questo viene fatto creando e posizionando la patch nella directory appropriata ./bigtop/bigtop-packages/src/common/oozie/ la patch, ad esempio, nella forma di 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
Probabilmente, al momento della lettura di questo articolo, la correzione sopra menzionata non sarà necessaria farla da soli.
Quando si implementano patch o modifiche nel meccanismo di costruzione, potrebbe essere necessario "resettare" la costruzione tramite il comando di pulizia:
./gradlew hadoop-clean
> Task :hadoop_vardefines
> Task :hadoop-clean
BUILD SUCCESSFUL in 5s
2 actionable tasks: 2 executedQuesta operazione annullerà tutte le modifiche alla costruzione di questo componente, dopo di che la costruzione verrà ripetuta. Questa volta proveremo a costruire il progetto in un'immagine docker:
./gradlew -POS=centos-7 -Pprefix=1.2.1 hadoop-pkg-ind
> Task :hadoop-pkg-ind
Building 1.2.1 hadoop-pkg on 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
....
много вывода
....
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-hdfs-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-yarn-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-mapreduce-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-hdfs-namenode-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-hdfs-secondarynamenode-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-hdfs-zkfc-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-hdfs-journalnode-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-hdfs-datanode-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-httpfs-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-yarn-resourcemanager-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-yarn-nodemanager-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-yarn-proxyserver-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-yarn-timelineserver-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-mapreduce-historyserver-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-client-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-conf-pseudo-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-doc-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-libhdfs-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-libhdfs-devel-2.8.5-1.el7.x86_64.rpm
Wrote: /bigtop/build/hadoop/rpm/RPMS/x86_64/hadoop-hdfs-fuse-2.8.5-1.el7.x86_64.rpm
Wrote: /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
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.uQ2FCn
+ exit 0
+ umask 022
Executing(--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] Creating /bigtop/build/hadoop/.rpm
:hadoop-rpm (Thread[Task worker for ':',5,main]) completed. Took 38 mins 1.151 secs.
:hadoop-pkg (Thread[Task worker for ':',5,main]) started.
> Task :hadoop-pkg
Task ':hadoop-pkg' is not up-to-date because:
Task has not declared any outputs despite executing actions.
:hadoop-pkg (Thread[Task worker for ':',5,main]) completed. Took 0.0 secs.
BUILD SUCCESSFUL in 40m 37s
6 actionable tasks: 6 executed
+ 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
Error: No such container:
ac46014fd9501bdc86b6c67d08789fbdc6ee46a2645550ff6b6712f7d02ffebb
BUILD SUCCESSFUL in 41m 24s
1 actionable task: 1 executedLa compilazione è avvenuta su CentOS, ma può essere effettuata anche su Ubuntu:
./gradlew -POS=ubuntu-16.04 -Pprefix=1.2.1 hadoop-pkg-indOltre a costruire pacchetti per diverse distribuzioni Linux, lo strumento è in grado di generare un repository con i pacchetti creati, ad esempio:
./gradlew yumÈ possibile inoltre ricordare i test di smoke e il deployment in docker.
Creare un cluster di tre nodi:
./gradlew -Pnum_instances=3 docker-provisionerEseguire i test di smoke in un cluster di tre nodi:
./gradlew -Pnum_instances=3 -Prun_smoke_tests docker-provisionerEliminare il cluster:
./gradlew docker-provisioner-destroyOttenere i comandi per accedere ai contenitori docker:
./gradlew docker-provisioner-sshMostrare lo stato:
./gradlew docker-provisioner-statusÈ possibile leggere maggiori dettagli sulle Deployment tasks nella documentazione.
Parlando dei test, ce ne sono numerosi, principalmente di smoke e di integrazione. Il loro approfondimento va oltre l'ambito di questo articolo. Posso solo dire che compilare la distribuzione non è così complicato come potrebbe sembrare a prima vista. Tutti i componenti che utilizziamo nel nostro ambiente di produzione sono stati compilati e hanno superato i test, senza problemi nel loro deploy e nelle operazioni basilari nell'ambiente di test.
Oltre ai componenti già presenti in Bigtop, è possibile aggiungerne altri, anche proprie sviluppi software. Tutto ciò è ben automatizzabile e si colloca all'interno della concezione CI/CD.
Conclusione
È chiaro che una distribuzione costruita in questo modo non dovrebbe essere immediatamente inviata in produzione. È necessario comprendere che se c'è una reale necessità di costruire e mantenere la propria distribuzione, è necessario investire sia finanziariamente che in termini di tempo.
Tuttavia, con un approccio corretto e un team professionale è possibile anche fare a meno di soluzioni commerciali.
È importante notare che il progetto Bigtop ha bisogno di sviluppo e sembra che attualmente non ci sia attività di sviluppo attiva. Inoltre, non è chiara la prospettiva di avere Hadoop 3 in questo progetto. A proposito, se hai una reale necessità di costruire Hadoop 3, puoi dare un'occhiata a Arenadata, che oltre ai componenti standard
ha anche tutta una serie di componenti aggiuntivi (Ranger, Knox, NiFi).
Per quanto riguarda Rostelecom, Bigtop è attualmente uno dei nostri candidati. Sarà il tempo a dirci se lo sceglieremo o meno.
Appendice
Per aggiungere un nuovo componente al pacchetto, è necessario inserire la sua descrizione in bigtop.bom e ./bigtop-packages. Puoi provare a farlo seguendo l'esempio dei componenti esistenti. Prova a capirlo. Non è così difficile come sembra a prima vista.
E voi cosa ne pensate? Ci farebbe piacere conoscere la vostra opinione nei commenti e grazie per la vostra attenzione!
Articolo preparato dal team di gestione dati di «Ростелеком»
Fonte: habr.com
