Det er nok ingen hemmelighed, at sidste år var et år med store forandringer for Apache Hadoop. Sidste år fusionerede Cloudera og Hortonworks (i det væsentlige købet af sidstnævnte), og Mapr blev på grund af alvorlige økonomiske problemer solgt til Hewlett Packard. Og hvis der nogle år tidligere, i tilfælde af lokale installationer, ofte skulle valget mellem Cloudera og Hortonworks, har vi i dag desværre ikke dette valg. En anden overraskelse var det faktum, at Cloudera annoncerede i februar i år, at det ville stoppe med at frigive binære samlinger af dets distribution til det offentlige lager, og de er nu kun tilgængelige via et betalt abonnement. Det er selvfølgelig stadig muligt at downloade de seneste versioner af CDH og HDP, der er udgivet inden udgangen af 2019, og support for dem forventes i et til to år. Men hvad skal man så gøre? For dem, der tidligere har betalt for et abonnement, er intet ændret. Og for dem, der ikke ønsker at skifte til den betalte version af distributionen, men samtidig ønsker at kunne modtage de nyeste versioner af klyngekomponenter, samt patches og andre opdateringer, har vi udarbejdet denne artikel. I den vil vi overveje mulige muligheder for at komme ud af denne situation.
Artiklen er mere en anmeldelse. Den vil ikke indeholde en sammenligning af distributioner og en detaljeret analyse af dem, og der vil ikke være nogen opskrifter til at installere og konfigurere dem. Hvad vil der ske? Vi vil kort tale om en sådan distribution som Arenadata Hadoop, som med rette fortjener vores opmærksomhed på grund af dens tilgængelighed, hvilket er meget sjældent i dag. Og så taler vi om Vanilla Hadoop, hovedsageligt om hvordan det kan "tilberedes" ved hjælp af Apache Bigtop. Parat? Så velkommen til kat.
Arenadata Hadoop
Dette er et helt nyt og endnu lidt kendt distributionssæt til indenlandsk udvikling. Desværre er der i øjeblikket på Habré kun .
Mere information kan findes på den officielle projekt. De seneste versioner af distributionen er baseret på Hadoop 3.1.2 for version 3 og 2.8.5 for version 2.
Information om køreplanen kan findes .
Arenadata Cluster Manager Interface
Arenadatas kerneprodukt er , som bruges til at installere, konfigurere og overvåge forskellige firmasoftwareløsninger. ADCM distribueres gratis, og dets funktionalitet udvides ved at tilføje bundter, som er et sæt ansible-playbooks. Bundles er opdelt i to typer: virksomhed og samfund. Sidstnævnte er tilgængelige til gratis download fra Arenadata-webstedet. Det er også muligt at udvikle dit eget bundt og forbinde det til ADCM.
Til udrulning og administration af Hadoop 3 tilbydes en fællesskabsversion af bundtet i forbindelse med ADCM, men for Hadoop 2 er der kun som et alternativ. Hvad angår repositories med pakker, er de åbne for offentlig adgang, de kan downloades og installeres på den sædvanlige måde for alle komponenter i klyngen. Overordnet ser fordelingen meget interessant ud. Jeg er sikker på, at der vil være dem, der er vant til løsninger som Cloudera Manager og Ambari, og som vil kunne lide ADCM selv. For nogle vil det også være et kæmpe plus, at fordelingen til importsubstitution.
Hvis vi taler om ulemperne, vil de være de samme som for alle andre Hadoop-distributioner. Nemlig:
- Den såkaldte "vendor lock-in". Ved at bruge eksemplerne fra Cloudera og Hortonworks har vi allerede indset, at der altid er en risiko for at ændre virksomhedens politik.
- Betydelig halt bag Apache opstrøms.
Vanilje Hadoop
Som du ved, er Hadoop ikke et monolitisk produkt, men faktisk en hel galakse af tjenester omkring dets distribuerede filsystem HDFS. Få mennesker vil have nok af én filklynge. Nogle har brug for Hive, andre Presto, og så er der HBase og Phoenix; Spark bruges i stigende grad. Til orkestrering og dataindlæsning findes nogle gange Oozie, Sqoop og Flume. Og hvis spørgsmålet om sikkerhed opstår, så kommer Kerberos i forbindelse med Ranger straks i tankerne.
Binære versioner af Hadoop-komponenter er tilgængelige på webstedet for hvert af økosystemprojekterne i form af tarballs. Du kan downloade dem og begynde installationen, men med én betingelse: udover uafhængigt at samle pakker fra "rå" binære filer, som du højst sandsynligt vil gøre, vil du ikke have nogen tillid til kompatibiliteten af de downloadede versioner af komponenter med hver Andet. Den foretrukne mulighed er at bygge ved hjælp af Apache Bigtop. Bigtop giver dig mulighed for at bygge fra Apache maven repositories, køre test og bygge pakker. Men hvad der er meget vigtigt for os, Bigtop vil samle de versioner af komponenter, der vil være kompatible med hinanden. Vi vil tale om det mere detaljeret nedenfor.
Apache Bigtop
Apache Bigtop er et værktøj til at bygge, pakke og teste en række af
open source-projekter, såsom Hadoop og Greenplum. Bigtop har masser
udgivelser. I skrivende stund var den seneste stabile udgivelse version 1.4,
og i master var der 1.5. Forskellige versioner af udgivelser bruger forskellige versioner
komponenter. For eksempel, for 1.4 Hadoop kernekomponenter har version 2.8.5, og i master
2.10.0. Sammensætningen af understøttede komponenter er også under forandring. Noget forældet og
det ufornyelige går væk, og i stedet kommer noget nyt, mere efterspurgt, og
det er ikke nødvendigvis noget fra Apache-familien selv.
Derudover har Bigtop mange .
Da vi begyndte at stifte bekendtskab med Bigtop, blev vi først og fremmest overraskede over dets beskedne, i sammenligning med andre Apache-projekter, udbredelse og popularitet samt et meget lille samfund. Det følger heraf, at der er minimal information om produktet, og at søge efter løsninger på problemer, der er opstået på fora og mailinglister, giver måske ikke noget som helst. Først viste det sig at være en vanskelig opgave for os at fuldføre den komplette samling af distributionen på grund af funktionerne i selve værktøjet, men vi vil tale om dette lidt senere.
Som en teaser kan de, der på et tidspunkt var interesserede i sådanne projekter af Linux-universet som Gentoo og LFS, finde det nostalgisk behageligt at arbejde med denne ting og huske de "episke" tider, hvor vi selv ledte efter (eller endda skrev) ebuilds og regelmæssigt genopbygget Mozilla med nye patches.
Den store fordel ved Bigtop er åbenheden og alsidigheden af de værktøjer, som den er baseret på. Den er baseret på Gradle og Apache Maven. Gradle er ret kendt som værktøjet Google bruger til at bygge Android. Det er fleksibelt og, som de siger, "kamptestet." Maven er et standardværktøj til byggeprojekter i selve Apache, og da de fleste af dets produkter er udgivet gennem Maven, kunne det heller ikke lade sig gøre uden det her. Det er værd at være opmærksom på POM (projektobjektmodel) - en "fundamental" xml-fil, der beskriver alt, hvad der er nødvendigt for, at Maven kan arbejde med dit projekt, som alt arbejde er bygget op omkring. Præcis kl
dele af Maven, og der er nogle forhindringer, som førstegangsbrugere af Bigtop normalt støder på.
Praksis
Så hvor skal du starte? Gå til downloadsiden og download den seneste stabile version som et arkiv. Du kan også finde binære artefakter indsamlet af Bigtop der. Blandt de almindelige pakkeadministratorer er YUM og APT i øvrigt understøttet.
Alternativt kan du downloade den seneste stabile udgivelse 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-mappe ser nogenlunde sådan ud:
./bigtop-bigpetstore — demoapplikationer, syntetiske eksempler
./bigtop-ci - CI-værktøjer, jenkins
./bigtop-data-generators — datagenerering, syntetiske materialer, til røgtest osv.
./bigtop-deploy - implementeringsværktøjer
./bigtop-packages — konfigurationer, scripts, patches til montering, hoveddelen af værktøjet
./bigtop-test-framework — afprøvningsramme
./bigtop-tests — selve testene, belastning og røg
./bigtop_toolchain — miljø til montering, forberedelse af miljøet til, at værktøjet kan fungere
./build — Byg arbejdsmappe
./dl — bibliotek for downloadede kilder
./docker — indbygning af docker-billeder, test
./gradle - gradle config
./output – biblioteket, hvor byggeartefakter går
./provisioner — forsyning
Det mest interessante for os på dette tidspunkt er hovedkonfigurationen ./bigtop/bigtop.bom, hvor vi ser alle understøttede komponenter med versioner. Det er her, vi kan angive en anden version af produktet (hvis vi pludselig vil prøve at bygge det) eller en build-version (hvis vi f.eks. har tilføjet en væsentlig patch).
Underbiblioteket er også af stor interesse ./bigtop/bigtop-packages, som er direkte relateret til processen med at samle komponenter og pakker med dem.
Så vi downloadede arkivet, pakkede det ud eller lavede en klon fra github, kan vi begynde at bygge?
Nej, lad os forberede miljøet først.
Forberedelse af miljøet
Og her trænger vi til et lille tilbagetog. For at bygge næsten et hvilket som helst mere eller mindre komplekst produkt, har du brug for et bestemt miljø - i vores tilfælde er dette JDK, de samme delte biblioteker, header-filer osv., værktøjer, for eksempel ant, ivy2 og meget mere. En af mulighederne for at få det miljø, du har brug for til Bigtop, er at installere de nødvendige komponenter på build-værten. Jeg kunne tage fejl i kronologien, men det ser ud til, at der med version 1.0 også var en mulighed for at indbygge forudkonfigurerede og tilgængelige Docker-billeder, som kan findes her.
Med hensyn til at forberede miljøet, er der en assistent til dette - Puppet.
Du kan bruge følgende kommandoer, kør fra rodmappen
værktøj, ./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"Desværre kan der opstå vanskeligheder allerede på dette stadium. Det generelle råd her er at bruge en understøttet distribution, opdateret på build-værten, eller prøve docker-ruten.
samling
Hvad kan vi prøve at indsamle? Svaret på dette spørgsmål vil blive givet ved udgangen af kommandoen
./gradlew tasks
I afsnittet Pakkeopgaver er der en række produkter, der er endelige artefakter af Bigtop.
De kan identificeres med suffikset -rpm eller -pkg-ind (i tilfælde af bygning
i docker). I vores tilfælde er det mest interessante Hadoop.
Lad os prøve at bygge vores byggeservers miljø ind:
./gradlew hadoop-rpmBigtop vil selv downloade de nødvendige kilder til en specifik komponent og begynde samlingen. Værktøjets drift er således afhængig af Maven repositories og andre kilder, det vil sige, at det kræver internetadgang.
Under drift genereres standard output. Nogle gange kan det og fejlmeddelelser hjælpe dig med at forstå, hvad der gik galt. Og nogle gange har du brug for at få yderligere oplysninger. I dette tilfælde er det værd at tilføje argumenter --info eller --debug, og kan også være nyttig –stacktrace. Der er en bekvem måde at generere et datasæt for efterfølgende adgang til mailinglister, nøglen --scan.
Med dens hjælp vil bigtop indsamle alle oplysningerne og sætte dem i gradle, hvorefter den giver et link,
hvorefter en kompetent person vil kunne forstå, hvorfor montagen mislykkedes.
Vær opmærksom på, at denne mulighed kan afsløre oplysninger, du ikke ønsker, såsom brugernavne, noder, miljøvariabler osv., så vær forsigtig.
Ofte er fejl en konsekvens af manglende evne til at skaffe de nødvendige komponenter til montering. Typisk kan du løse problemet ved at oprette en patch for at rette noget i kilderne, for eksempel adresser i pom.xml i kildens rodmapp. Dette gøres ved at oprette og placere det i den relevante mappe ./bigtop/bigtop-packages/src/common/oozie/ patch, for eksempel i formen 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 sandsynligt, når du læser denne artikel, behøver du ikke selv at lave ovenstående rettelse.
Når du introducerer patches og ændringer til monteringsmekanismen, skal du muligvis "nulstille" samlingen ved hjælp af oprydningskommandoen:
./gradlew hadoop-clean
> Task :hadoop_vardefines
> Task :hadoop-clean
BUILD SUCCESSFUL in 5s
2 actionable tasks: 2 executedDenne handling vil rulle tilbage alle ændringer i samlingen af denne komponent, hvorefter samlingen vil blive udført igen. Denne gang vil vi prøve at bygge projektet i et docker-billede:
./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 executedBygningen blev udført under CentOS, men kan også udføres under Ubuntu:
./gradlew -POS=ubuntu-16.04 -Pprefix=1.2.1 hadoop-pkg-indUd over at bygge pakker til forskellige Linux-distributioner kan værktøjet oprette et lager med kompilerede pakker, for eksempel:
./gradlew yumDu kan også huske røgtest og implementering i Docker.
Opret en klynge af tre noder:
./gradlew -Pnum_instances=3 docker-provisionerKør røgtest i en klynge af tre noder:
./gradlew -Pnum_instances=3 -Prun_smoke_tests docker-provisionerSlet en klynge:
./gradlew docker-provisioner-destroyFå kommandoer til at forbinde inde i docker-containere:
./gradlew docker-provisioner-sshVis status:
./gradlew docker-provisioner-statusDu kan læse mere om Deployment-opgaver i dokumentationen.
Hvis vi taler om tests, er der et ret stort antal af dem, primært røg og integration. Deres analyse er uden for rammerne af denne artikel. Lad mig bare sige, at det ikke er så vanskeligt at samle et distributionssæt, som det kan se ud ved første øjekast. Vi formåede at samle og bestå test på alle de komponenter, vi bruger i vores produktion, og vi havde heller ingen problemer med at implementere dem og udføre grundlæggende operationer i testmiljøet.
Ud over de eksisterende komponenter i Bigtop er det muligt at tilføje alt andet, endda din egen softwareudvikling. Alt dette er perfekt automatiseret og passer ind i CI/CD-konceptet.
Konklusion
Det er klart, at distributionen, der er kompileret på denne måde, ikke straks skal sendes til produktion. Du skal forstå, at hvis der er et reelt behov for at bygge og understøtte din distribution, så skal du investere penge og tid i dette.
Men i kombination med den rigtige tilgang og et professionelt team er det sagtens muligt at undvære kommercielle løsninger.
Det er vigtigt at bemærke, at selve Bigtop-projektet har behov for udvikling og ikke ser ud til at være aktivt under udvikling i dag. Udsigten til at Hadoop 3 dukker op i den er også uklar. Hvis du i øvrigt har et reelt behov for at bygge Hadoop 3, kan du se på fra Arenadata, hvori der udover standard
Der er en række ekstra komponenter (Ranger, Knox, NiFi).
Hvad angår Rostelecom, er Bigtop for os en af de muligheder, der overvejes i dag. Om vi vælger det eller ej, må tiden vise.
Tillæg
For at inkludere en ny komponent i samlingen skal du tilføje dens beskrivelse til bigtop.bom og ./bigtop-packages. Du kan prøve at gøre dette analogt med de eksisterende komponenter. Prøv at finde ud af det. Det er ikke så svært, som det ser ud ved første øjekast.
Hvad synes du? Vi vil være glade for at se din mening i kommentarerne og tak for din opmærksomhed!
Artiklen er udarbejdet af Rostelecoms datastyringsteam
Kilde: www.habr.com