Det er nok ingen hemmelighet at fjoråret var et år med store endringer for Apache Hadoop. I fjor fusjonerte Cloudera og Hortonworks (i hovedsak oppkjøpet av sistnevnte), og Mapr ble, på grunn av alvorlige økonomiske problemer, solgt til Hewlett Packard. Og hvis det noen år tidligere, når det gjelder lokale installasjoner, ofte måtte gjøres mellom Cloudera og Hortonworks, har vi i dag dessverre ikke dette valget. En annen overraskelse var det faktum at Cloudera kunngjorde i februar i år at de ville slutte å gi ut binære samlinger av distribusjonen til det offentlige depotet, og de er nå kun tilgjengelige gjennom et betalt abonnement. Det er selvfølgelig fortsatt mulig å laste ned de nyeste versjonene av CDH og HDP utgitt før slutten av 2019, og støtte for dem forventes i ett til to år. Men hva skal jeg gjøre videre? For de som tidligere har betalt for et abonnement er ingenting endret. Og for de som ikke ønsker å bytte til den betalte versjonen av distribusjonen, men samtidig ønsker å kunne motta de nyeste versjonene av klyngekomponenter, samt patcher og andre oppdateringer, har vi utarbeidet denne artikkelen. I den vil vi vurdere mulige alternativer for å komme ut av denne situasjonen.
Artikkelen er mer en anmeldelse. Den vil ikke inneholde en sammenligning av distribusjoner og en detaljert analyse av dem, og det vil ikke være noen oppskrifter for å installere og konfigurere dem. Hva vil skje? Vi vil kort snakke om en slik distribusjon som Arenadata Hadoop, som med rette fortjener vår oppmerksomhet på grunn av tilgjengeligheten, som er svært sjelden i dag. Og så skal vi snakke om Vanilla Hadoop, hovedsakelig om hvordan den kan "tilberedes" ved hjelp av Apache Bigtop. Klar? Så velkommen til katt.
Arenadata Hadoop
Dette er et helt nytt og foreløpig lite kjent distribusjonssett for innenlandsk utvikling. Dessverre, for øyeblikket på Habré er det bare .
Mer informasjon finner du på den offisielle prosjekt. De siste versjonene av distribusjonen er basert på Hadoop 3.1.2 for versjon 3, og 2.8.5 for versjon 2.
Informasjon om veikartet finner du .
Arenadata Cluster Manager-grensesnitt
Arenadatas kjerneprodukt er , som brukes til å installere, konfigurere og overvåke ulike firmaprogramvareløsninger. ADCM distribueres gratis, og funksjonaliteten utvides ved å legge til bunter, som er et sett med ansible-playbooks. Bunter er delt inn i to typer: bedrift og fellesskap. Sistnevnte er tilgjengelig for gratis nedlasting fra nettstedet Arenadata. Det er også mulig å utvikle din egen bunt og koble den til ADCM.
For distribusjon og administrasjon av Hadoop 3 tilbys en fellesskapsversjon av pakken i forbindelse med ADCM, men for Hadoop 2 er det bare som et alternativ. Når det gjelder repositories med pakker, er de åpne for offentlig tilgang, de kan lastes ned og installeres på vanlig måte for alle komponenter i klyngen. Totalt sett ser fordelingen veldig interessant ut. Jeg er sikker på at det vil være de som er vant til løsninger som Cloudera Manager og Ambari, og som vil like ADCM selv. For noen vil det også være et kjempepluss at fordelingen for importsubstitusjon.
Hvis vi snakker om ulempene, vil de være de samme som for alle andre Hadoop-distribusjoner. Nemlig:
- Den såkalte "leverandørlåsen". Ved å bruke eksemplene fra Cloudera og Hortonworks har vi allerede innsett at det alltid er en risiko for å endre selskapets policy.
- Betydelig etterslep etter Apache oppstrøms.
Vanilje Hadoop
Som du vet, er ikke Hadoop et monolitisk produkt, men faktisk en hel galakse av tjenester rundt det distribuerte filsystemet HDFS. Få mennesker vil ha nok av én filklynge. Noen trenger Hive, andre Presto, og så er det HBase og Phoenix; Spark blir stadig mer brukt. For orkestrering og datalasting finnes noen ganger Oozie, Sqoop og Flume. Og hvis spørsmålet om sikkerhet oppstår, kommer Kerberos i forbindelse med Ranger umiddelbart til tankene.
Binære versjoner av Hadoop-komponenter er tilgjengelig på nettsiden til hvert av økosystemprosjektene i form av tarballs. Du kan laste dem ned og begynne installasjonen, men med én betingelse: i tillegg til å sette sammen pakker uavhengig fra "rå" binærfiler, som du mest sannsynlig vil gjøre, vil du ikke ha noen tillit til kompatibiliteten til de nedlastede versjonene av komponentene med hver annen. Det foretrukne alternativet er å bygge med Apache Bigtop. Bigtop lar deg bygge fra Apache maven repositories, kjøre tester og bygge pakker. Men det som er veldig viktig for oss, Bigtop vil sette sammen de versjonene av komponenter som vil være kompatible med hverandre. Vi vil snakke om det mer detaljert nedenfor.
Apache Bigtop
Apache Bigtop er et verktøy for å bygge, pakke og teste en rekke
åpen kildekode-prosjekter, som Hadoop og Greenplum. Bigtop har mye
utgivelser. I skrivende stund var den siste stabile utgivelsen versjon 1.4,
og i master var det 1.5. Ulike versjoner av utgivelser bruker forskjellige versjoner
komponenter. For eksempel, for 1.4 Hadoop kjernekomponenter har versjon 2.8.5, og i master
2.10.0. Sammensetningen av støttede komponenter er også i endring. Noe utdatert og
det ufornybare går bort, og i stedet kommer noe nytt, mer etterspurt, og
det er ikke nødvendigvis noe fra Apache-familien selv.
I tillegg har Bigtop mange .
Da vi begynte å bli kjent med Bigtop, ble vi først og fremst overrasket over det beskjedne, sammenlignet med andre Apache-prosjekter, utbredelse og popularitet, samt et veldig lite samfunn. Det følger av dette at det er minimal informasjon om produktet, og å søke etter løsninger på problemer som har oppstått på forum og e-postlister gir kanskje ikke noe som helst. Til å begynne med viste det seg å være en vanskelig oppgave for oss å fullføre den komplette monteringen av distribusjonen på grunn av funksjonene til selve verktøyet, men vi snakker om dette litt senere.
Som en teaser kan de som på en gang var interessert i slike prosjekter av Linux-universet som Gentoo og LFS synes det er nostalgisk hyggelig å jobbe med denne tingen og huske de "episke" tidene da vi selv lette etter (eller til og med skrev) ebuilds og regelmessig ombygd Mozilla med nye patcher.
Den store fordelen med Bigtop er åpenheten og allsidigheten til verktøyene den er basert på. Den er basert på Gradle og Apache Maven. Gradle er ganske godt kjent som verktøyet Google bruker for å bygge Android. Den er fleksibel, og, som de sier, "kamptestet." Maven er et standardverktøy for byggeprosjekter i selve Apache, og siden de fleste av produktene deres er utgitt gjennom Maven, kunne det heller ikke gjøres uten det her. Det er verdt å ta hensyn til POM (prosjektobjektmodellen) - den "grunnleggende" xml-filen som beskriver alt som er nødvendig for at Maven skal jobbe med prosjektet ditt, som alt arbeid er bygget rundt. Nøyaktig kl
deler av Maven og det er noen hindringer som førstegangs Bigtop-brukere vanligvis møter.
Praksis
Så hvor bør du begynne? Gå til nedlastingssiden og last ned den siste stabile versjonen som et arkiv. Du kan også finne binære artefakter samlet av Bigtop der. Forresten, blant de vanlige pakkeforvalterne støttes YUM og APT.
Alternativt kan du laste ned den siste stabile utgivelsen direkte fra
github:
$ git clone --branch branch-1.4 https://github.com/apache/bigtop.gitKloning i "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
Получение объектов: 100% (40217/40217), 43.54 MiB | 1.05 MiB/s, готово.
Определение изменений: 100% (20503/20503), готово.
Updating files: 100% (1998/1998), готово.Den resulterende ./bigtop-katalogen ser omtrent slik ut:
./bigtop-bigpetstore — demoapplikasjoner, syntetiske eksempler
./bigtop-ci - CI-verktøy, jenkins
./bigtop-data-generators — datagenerering, syntetiske stoffer, for røyktester osv.
./bigtop-deploy - distribusjonsverktøy
./bigtop-packages — konfigurasjoner, skript, oppdateringer for montering, hoveddelen av verktøyet
./bigtop-test-framework — testramme
./bigtop-tests — selve testene, last og røyk
./bigtop_toolchain — miljø for montering, forberede miljøet for at verktøyet skal fungere
./build — bygge arbeidskatalog
./dl — katalog for nedlastede kilder
./docker — bygge inn docker-bilder, testing
./gradle - gradle konfig
./output – katalogen der byggeartefakter går
./provisioner — proviantering
Det mest interessante for oss på dette stadiet er hovedkonfigurasjonen ./bigtop/bigtop.bom, der vi ser alle støttede komponenter med versjoner. Det er her vi kan spesifisere en annen versjon av produktet (hvis vi plutselig vil prøve å bygge det) eller en byggeversjon (hvis vi for eksempel la til en betydelig oppdatering).
Underkatalogen er også av stor interesse ./bigtop/bigtop-packages, som er direkte relatert til prosessen med å montere komponenter og pakker med dem.
Så vi lastet ned arkivet, pakket det ut eller laget en klone fra github, kan vi begynne å bygge?
Nei, la oss forberede miljøet først.
Forberede miljøet
Og her trenger vi en liten retrett. For å bygge nesten hvilket som helst mer eller mindre komplekst produkt, kreves et visst miljø - i vårt tilfelle er dette JDK, de samme delte bibliotekene, header-filer, etc., verktøy, for eksempel ant, ivy2 og mye mer. Et av alternativene for å få miljøet du trenger for Bigtop er å installere de nødvendige komponentene på byggeverten. Jeg kan ta feil i kronologien, men det ser ut til at det med versjon 1.0 også var en mulighet for å bygge inn forhåndskonfigurerte og tilgjengelige Docker-bilder, som du finner her.
Når det gjelder å forberede miljøet, er det en assistent for dette - Puppet.
Du kan bruke følgende kommandoer, kjør fra rotkatalogen
verktøy, ./bigtop:
./gradlew toolchain
./gradlew toolchain-devtools
./gradlew toolchain-puppetmodules
Eller direkte via dukke:
puppet apply --modulepath=<path_to_bigtop> -e "include bigtop_toolchain::installer"
puppet apply --modulepath=<path_to_bigtop> -e "include bigtop_toolchain::deployment-tools"
puppet apply --modulepath=<path_to_bigtop> -e "include bigtop_toolchain::development-tools"Dessverre kan det oppstå vanskeligheter allerede på dette stadiet. Det generelle rådet her er å bruke en støttet distribusjon, oppdatert på byggeverten, eller prøve docker-ruten.
sammenstilling
Hva kan vi prøve å samle inn? Svaret på dette spørsmålet vil bli gitt av utgangen av kommandoen
./gradlew tasks
I Pakkeoppgaver-delen er det en rekke produkter som er endelige artefakter av Bigtop.
De kan identifiseres med suffikset -rpm eller -pkg-ind (når det gjelder bygning
i docker). I vårt tilfelle er det mest interessante Hadoop.
La oss prøve å bygge inn miljøet til byggeserveren vår:
./gradlew hadoop-rpmBigtop selv vil laste ned de nødvendige kildene som trengs for en spesifikk komponent og begynne å sette sammen. Dermed er verktøyets drift avhengig av Maven-depoter og andre kilder, det vil si at det krever Internett-tilgang.
Under drift genereres standard utgang. Noen ganger kan det og feilmeldinger hjelpe deg å forstå hva som gikk galt. Og noen ganger trenger du å få ytterligere informasjon. I dette tilfellet er det verdt å legge til argumenter --info eller --debug, og kan også være nyttig –stacktrace. Det er en praktisk måte å generere et datasett for påfølgende tilgang til e-postlister, nøkkelen --scan.
Med sin hjelp vil bigtop samle all informasjon og sette den i gradle, hvoretter den vil gi en lenke,
ved å følge dette vil en kompetent person kunne forstå hvorfor monteringen mislyktes.
Vær oppmerksom på at dette alternativet kan avdekke informasjon du ikke ønsker, for eksempel brukernavn, noder, miljøvariabler osv., så vær forsiktig.
Ofte er feil en konsekvens av manglende evne til å få tak i komponenter som er nødvendige for montering. Vanligvis kan du fikse problemet ved å lage en oppdatering for å fikse noe i kildene, for eksempel adresser i pom.xml i rotkatalogen til kildene. Dette gjøres ved å opprette og plassere den i riktig katalog ./bigtop/bigtop-packages/src/common/oozie/ lapp, for eksempel i skjemaet patch2-fix.diff.
--- a/pom.xml
+++ b/pom.xml
@@ -136,7 +136,7 @@
<repositories>
<repository>
<id>central</id>
- <url>http://repo1.maven.org/maven2</url>
+ <url>https://repo1.maven.org/maven2</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
Mest sannsynlig, når du leser denne artikkelen, trenger du ikke å fikse ovenstående selv.
Når du introduserer eventuelle patcher og endringer i monteringsmekanismen, må du kanskje "tilbakestille" sammenstillingen ved å bruke oppryddingskommandoen:
./gradlew hadoop-clean
> Task :hadoop_vardefines
> Task :hadoop-clean
BUILD SUCCESSFUL in 5s
2 actionable tasks: 2 executedDenne operasjonen vil rulle tilbake alle endringer i monteringen av denne komponenten, hvoretter monteringen vil bli utført på nytt. Denne gangen skal vi prøve å bygge prosjektet i et docker-bilde:
./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 executedByggingen ble utført under CentOS, men kan også gjøres under Ubuntu:
./gradlew -POS=ubuntu-16.04 -Pprefix=1.2.1 hadoop-pkg-indI tillegg til å bygge pakker for ulike Linux-distribusjoner, kan verktøyet lage et depot med kompilerte pakker, for eksempel:
./gradlew yumDu kan også huske røyktester og distribusjon i Docker.
Lag en klynge med tre noder:
./gradlew -Pnum_instances=3 docker-provisionerKjør røyktester i en klynge med tre noder:
./gradlew -Pnum_instances=3 -Prun_smoke_tests docker-provisionerSlett en klynge:
./gradlew docker-provisioner-destroyFå kommandoer for å koble til inne i docker-containere:
./gradlew docker-provisioner-sshVis status:
./gradlew docker-provisioner-statusDu kan lese mer om Utrullingsoppgaver i dokumentasjonen.
Hvis vi snakker om tester, er det ganske mange av dem, hovedsakelig røyk og integrasjon. Analysen deres er utenfor rammen av denne artikkelen. La meg bare si at å sette sammen en distribusjon ikke er en så vanskelig oppgave som det kan virke ved første øyekast. Vi klarte å sette sammen og bestå tester på alle komponentene vi bruker i produksjonen vår, og vi hadde heller ingen problemer med å distribuere dem og utføre grunnleggende operasjoner i testmiljøet.
I tillegg til de eksisterende komponentene i Bigtop, er det mulig å legge til alt annet, til og med din egen programvareutvikling. Alt dette er perfekt automatisert og passer inn i CI/CD-konseptet.
Konklusjon
Det er klart at distribusjonen som er satt sammen på denne måten ikke umiddelbart skal sendes til produksjon. Du må forstå at hvis det er et reelt behov for å bygge og støtte distribusjonen din, så må du investere penger og tid i dette.
Men i kombinasjon med riktig tilnærming og et profesjonelt team er det fullt mulig å klare seg uten kommersielle løsninger.
Det er viktig å merke seg at selve Bigtop-prosjektet har behov for utvikling og ikke ser ut til å være aktivt utviklet i dag. Utsiktene til at Hadoop 3 dukker opp i den er også uklart. Hvis du har et reelt behov for å bygge Hadoop 3, kan du forresten se på fra Arenadata, hvori i tillegg til standard
Det finnes en rekke tilleggskomponenter (Ranger, Knox, NiFi).
Når det gjelder Rostelecom, er Bigtop for oss et av alternativene som vurderes i dag. Om vi velger det eller ikke, vil tiden vise.
Vedlegg
For å inkludere en ny komponent i sammenstillingen, må du legge til beskrivelsen til bigtop.bom og ./bigtop-packages. Du kan prøve å gjøre dette analogt med de eksisterende komponentene. Prøv å finne ut av det. Det er ikke så vanskelig som det ser ut ved første øyekast.
Hva tror du? Vi vil gjerne se din mening i kommentarene og takk for oppmerksomheten!
Artikkelen ble utarbeidet av Rostelecoms dataadministrasjonsteam
Kilde: www.habr.com