Det är nog ingen hemlighet att förra året var ett år av stora förändringar för Apache Hadoop. Förra året gick Cloudera och Hortonworks samman (i huvudsak förvärvet av det senare), och Mapr såldes på grund av allvarliga ekonomiska problem till Hewlett Packard. Och om det några år tidigare, när det gäller installationer på plats, ofta behövt göras mellan Cloudera och Hortonworks, har vi idag tyvärr inte detta val. En annan överraskning var det faktum att Cloudera meddelade i februari i år att de skulle sluta släppa binära sammansättningar av dess distribution till det offentliga förvaret, och de är nu endast tillgängliga via ett betalabonnemang. Naturligtvis är det fortfarande möjligt att ladda ner de senaste versionerna av CDH och HDP som släppts före slutet av 2019, och stöd för dem förväntas under ett till två år. Men vad ska man göra härnäst? För de som tidigare betalat för ett abonnemang har ingenting förändrats. Och för de som inte vill byta till den betalda versionen av distributionen, men samtidigt vill kunna ta emot de senaste versionerna av klusterkomponenter, såväl som patchar och andra uppdateringar, har vi förberett denna artikel. I den kommer vi att överväga möjliga alternativ för att komma ur denna situation.
Artikeln är mer en recension. Den kommer inte att innehålla en jämförelse av distributioner och en detaljerad analys av dem, och det kommer inte att finnas några recept för att installera och konfigurera dem. Vad kommer att hända? Vi kommer kort att prata om en sådan distribution som Arenadata Hadoop, som med rätta förtjänar vår uppmärksamhet på grund av dess tillgänglighet, vilket är mycket sällsynt idag. Och sedan ska vi prata om Vanilla Hadoop, främst om hur det kan "tillagas" med Apache Bigtop. Redo? Då välkommen till katt.
Arenadata Hadoop
Detta är ett helt nytt och ännu föga känt distributionspaket för inhemsk utveckling. Tyvärr, för tillfället på Habré finns det bara .
Mer information finns på tjänstemannen projekt. De senaste versionerna av distributionen är baserade på Hadoop 3.1.2 för version 3 och 2.8.5 för version 2.
Information om färdplanen finns .
Arenadata Cluster Manager-gränssnitt
Arenadatas kärnprodukt är , som används för att installera, konfigurera och övervaka olika företags mjukvarulösningar. ADCM distribueras gratis, och dess funktionalitet utökas genom att lägga till buntar, som är en uppsättning ansible-playbooks. Paket är indelat i två typer: företag och gemenskap. De senare är tillgängliga för gratis nedladdning från Arenadatas webbplats. Det är också möjligt att utveckla ett eget paket och koppla det till ADCM.
För distribution och hantering av Hadoop 3 erbjuds en communityversion av paketet tillsammans med ADCM, men för Hadoop 2 finns det endast som ett alternativ. När det gäller arkiv med paket är de öppna för allmänheten, de kan laddas ner och installeras på vanligt sätt för alla komponenter i klustret. Överlag ser fördelningen väldigt intressant ut. Jag är säker på att det kommer att finnas de som är vana vid lösningar som Cloudera Manager och Ambari, och som kommer att gilla ADCM själv. För vissa blir det också ett stort plus att fördelningen för importsubstitution.
Om vi pratar om nackdelarna kommer de att vara desamma som för alla andra Hadoop-distributioner. Nämligen:
- Den så kallade "leverantörslåsningen". Med hjälp av exemplen Cloudera och Hortonworks har vi redan insett att det alltid finns en risk att ändra företagets policy.
- Betydande eftersläpning efter Apache uppströms.
Vanilj Hadoop
Som ni vet är Hadoop inte en monolitisk produkt, utan i själva verket en hel galax av tjänster runt sitt distribuerade filsystem HDFS. Få människor kommer att ha tillräckligt med ett filkluster. Vissa behöver Hive, andra Presto, och så finns det HBase och Phoenix, Spark används allt mer. För orkestrering och dataladdning hittas ibland Oozie, Sqoop och Flume. Och om frågan om säkerhet uppstår, kommer Kerberos i samband med Ranger omedelbart att tänka på.
Binära versioner av Hadoop-komponenter finns tillgängliga på webbplatsen för vart och ett av ekosystemprojekten i form av tarballs. Du kan ladda ner dem och börja installationen, men med ett villkor: förutom att självständigt sätta ihop paket från "rå" binärer, vilket du troligen vill göra, kommer du inte att ha något förtroende för kompatibiliteten för de nedladdade versionerna av komponenter med varje Övrig. Det föredragna alternativet är att bygga med Apache Bigtop. Bigtop låter dig bygga från Apache maven-förråd, köra tester och bygga paket. Men vad som är väldigt viktigt för oss, Bigtop kommer att montera de versioner av komponenter som kommer att vara kompatibla med varandra. Vi kommer att prata om det mer i detalj nedan.
Apache Bigtop
Apache Bigtop är ett verktyg för att bygga, paketera och testa ett antal
öppen källkodsprojekt, som Hadoop och Greenplum. Bigtop har massor
släpper. I skrivande stund var den senaste stabila utgåvan version 1.4,
och i master var det 1.5. Olika versioner av utgåvor använder olika versioner
komponenter. Till exempel, för 1.4 Hadoop kärnkomponenter har version 2.8.5, och i master
2.10.0. Sammansättningen av understödda komponenter förändras också. Något föråldrat och
det oförnybara försvinner, och i dess ställe kommer något nytt, mer efterfrågat, och
det är inte nödvändigtvis något från själva Apache-familjen.
Dessutom har Bigtop många .
När vi började bekanta oss med Bigtop blev vi först och främst förvånade över dess blygsamma, i jämförelse med andra Apache-projekt, utbredning och berömmelse, samt ett mycket litet samhälle. Av detta följer att det finns minimal information om produkten och att söka efter lösningar på problem som har uppstått på forum och e-postlistor kanske inte ger någonting alls. Till en början visade det sig vara en svår uppgift för oss att slutföra den fullständiga monteringen av distributionen på grund av funktionerna i själva verktyget, men vi kommer att prata om detta lite senare.
Som en teaser kan de som en gång var intresserade av sådana projekt av Linux-universum som Gentoo och LFS tycka att det är nostalgiskt trevligt att arbeta med den här saken och komma ihåg de "episka" tiderna när vi själva letade efter (eller till och med skrev) ebuilds och regelbundet ombyggda Mozilla med nya patchar.
Den stora fördelen med Bigtop är öppenheten och mångsidigheten hos de verktyg som den är baserad på. Den är baserad på Gradle och Apache Maven. Gradle är ganska välkänt som verktyget Google använder för att bygga Android. Den är flexibel och, som de säger, "stridstestad." Maven är ett standardverktyg för att bygga projekt i själva Apache, och eftersom de flesta av dess produkter släpps genom Maven kunde det inte göras utan det här heller. Det är värt att uppmärksamma POM (projektobjektmodell) - en "grundläggande" xml-fil som beskriver allt som behövs för att Maven ska kunna arbeta med ditt projekt, runt vilket allt arbete är uppbyggt. Exakt kl
delar av Maven och det finns några hinder som förstagångsanvändare av Bigtop brukar stöta på.
Praxis
Så var ska du börja? Gå till nedladdningssidan och ladda ner den senaste stabila versionen som ett arkiv. Du kan också hitta binära artefakter som samlats in av Bigtop där. Förresten, bland de vanliga pakethanterarna stöds YUM och APT.
Alternativt kan du ladda ner den senaste stabila versionen direkt från
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 resulterande ./bigtop-katalogen ser ut ungefär så här:
./bigtop-bigpetstore — Demoapplikationer, syntetiska exempel
./bigtop-ci - CI-verktyg, jenkins
./bigtop-data-generators — datagenerering, syntetmaterial, för röktester etc.
./bigtop-deploy - distributionsverktyg
./bigtop-packages — konfigurationer, skript, patchar för montering, huvuddelen av verktyget
./bigtop-test-framework — Testram
./bigtop-tests — själva proven, last och rök
./bigtop_toolchain — miljö för montering, förbereda miljön för att verktyget ska fungera
./build — bygga arbetskatalog
./dl — katalog för nedladdade källor
./docker — bygga in docker-bilder, testning
./gradle - gradle config
./output – katalogen där byggartefakter finns
./provisioner — försörjning
Det mest intressanta för oss i detta skede är huvudkonfigurationen ./bigtop/bigtop.bom, där vi ser alla komponenter som stöds med versioner. Det är här vi kan specificera en annan version av produkten (om vi plötsligt vill försöka bygga den) eller en byggversion (om vi till exempel lagt till en betydande patch).
Underkatalogen är också av stort intresse ./bigtop/bigtop-packages, som är direkt relaterad till processen att montera komponenter och paket med dem.
Så vi laddade ner arkivet, packade upp det eller gjorde en klon från github, kan vi börja bygga?
Nej, låt oss förbereda miljön först.
Att förbereda miljön
Och här behöver vi en liten reträtt. För att bygga nästan vilken mer eller mindre komplex produkt som helst behöver du en viss miljö - i vårt fall är detta JDK, samma delade bibliotek, header-filer, etc., verktyg, till exempel ant, ivy2 och mycket mer. Ett av alternativen för att få den miljö du behöver för Bigtop är att installera de nödvändiga komponenterna på byggvärden. Jag kan ha fel i kronologin, men det verkar som att det med version 1.0 också fanns en möjlighet att bygga in förkonfigurerade och tillgängliga Docker-bilder, som finns här.
När det gäller att förbereda miljön finns det en assistent för detta - Puppet.
Du kan använda följande kommandon, kör från rotkatalogen
verktyg, ./bigtop:
./gradlew toolchain
./gradlew toolchain-devtools
./gradlew toolchain-puppetmodules
Eller direkt via docka:
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"Tyvärr kan svårigheter uppstå redan i detta skede. Det allmänna rådet här är att använda en distribution som stöds, uppdaterad på byggvärden, eller prova docker-rutten.
aggregatet
Vad kan vi försöka samla in? Svaret på denna fråga kommer att ges av utmatningen av kommandot
./gradlew tasks
I avsnittet Paketuppgifter finns ett antal produkter som är slutliga artefakter av Bigtop.
De kan identifieras med suffixet -rpm eller -pkg-ind (när det gäller byggnad
i docker). I vårt fall är det mest intressanta Hadoop.
Låt oss försöka bygga in miljön för vår byggserver:
./gradlew hadoop-rpmBigtop kommer själv att ladda ner de nödvändiga källorna som behövs för en specifik komponent och påbörja monteringen. Verktygets funktion är alltså beroende av Maven-förråd och andra källor, det vill säga det kräver internetåtkomst.
Under drift genereras standardutgång. Ibland kan det och felmeddelanden hjälpa dig att förstå vad som gick fel. Och ibland behöver du få ytterligare information. I det här fallet är det värt att lägga till argument --info eller --debug, och kan också vara användbar –stacktrace. Det finns ett bekvämt sätt att generera en datauppsättning för efterföljande tillgång till e-postlistor, nyckeln --scan.
Med sin hjälp kommer bigtop att samla in all information och lägga den i gradle, varefter den ger en länk,
genom att följa vilket kommer en kompetent person att kunna förstå varför monteringen misslyckades.
Var medveten om att det här alternativet kan avslöja information som du inte vill ha, såsom användarnamn, noder, miljövariabler etc., så var försiktig.
Ofta är fel en följd av oförmågan att få tag på de komponenter som krävs för montering. Vanligtvis kan du åtgärda problemet genom att skapa en patch för att fixa något i källorna, till exempel adresser i pom.xml i källornas rotkatalog. Detta görs genom att skapa och placera det i lämplig katalog ./bigtop/bigtop-packages/src/common/oozie/ patch, till exempel 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>
Troligtvis, när du läser den här artikeln, behöver du inte fixa ovanstående själv.
När du introducerar några patchar och ändringar av monteringsmekanismen kan du behöva "återställa" sammansättningen med hjälp av cleanup-kommandot:
./gradlew hadoop-clean
> Task :hadoop_vardefines
> Task :hadoop-clean
BUILD SUCCESSFUL in 5s
2 actionable tasks: 2 executedDenna operation kommer att rulla tillbaka alla ändringar i sammansättningen av denna komponent, varefter sammansättningen kommer att utföras igen. Den här gången ska vi försöka bygga projektet i en docker-bild:
./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 executedBygget utfördes under CentOS, men kan också göras under Ubuntu:
./gradlew -POS=ubuntu-16.04 -Pprefix=1.2.1 hadoop-pkg-indFörutom att bygga paket för olika Linux-distributioner kan verktyget skapa ett arkiv med kompilerade paket, till exempel:
./gradlew yumDu kan också komma ihåg röktester och distribution i Docker.
Skapa ett kluster med tre noder:
./gradlew -Pnum_instances=3 docker-provisionerKör röktester i ett kluster med tre noder:
./gradlew -Pnum_instances=3 -Prun_smoke_tests docker-provisionerTa bort ett kluster:
./gradlew docker-provisioner-destroyFå kommandon för att ansluta inuti dockarcontainrar:
./gradlew docker-provisioner-sshVisa status:
./gradlew docker-provisioner-statusDu kan läsa mer om implementeringsuppgifter i dokumentationen.
Om vi pratar om tester så finns det ganska många av dem, främst rök och integration. Deras analys ligger utanför ramen för denna artikel. Låt mig bara säga att montering av ett distributionspaket inte är en så svår uppgift som det kan tyckas vid första anblicken. Vi lyckades montera och klara tester på alla komponenter som vi använder i vår produktion, och vi hade heller inga problem med att implementera dem och utföra grundläggande operationer i testmiljön.
Utöver de befintliga komponenterna i Bigtop är det möjligt att lägga till vad som helst, även din egen mjukvaruutveckling. Allt detta är perfekt automatiserat och passar in i CI/CD-konceptet.
Slutsats
Uppenbarligen bör distributionen som sammanställts på detta sätt inte omedelbart skickas till produktion. Du måste förstå att om det finns ett verkligt behov av att bygga och stödja din distribution så måste du investera pengar och tid i detta.
Men i kombination med rätt tillvägagångssätt och ett professionellt team är det fullt möjligt att klara sig utan kommersiella lösningar.
Det är viktigt att notera att själva Bigtop-projektet är i behov av utveckling och inte verkar vara aktivt utvecklat idag. Utsikterna att Hadoop 3 ska dyka upp i den är också oklart. Om du har ett verkligt behov av att bygga Hadoop 3 kan du förresten titta på från Arenadata, där, förutom standard
Det finns ett antal ytterligare komponenter (Ranger, Knox, NiFi).
När det gäller Rostelecom är Bigtop för oss ett av alternativen som övervägs idag. Om vi väljer det eller inte får tiden utvisa.
Appendix
För att inkludera en ny komponent i sammansättningen måste du lägga till dess beskrivning till bigtop.bom och ./bigtop-paket. Du kan försöka göra detta analogt med de befintliga komponenterna. Försök ta reda på det. Det är inte så svårt som det verkar vid första anblicken.
Vad tror du? Vi kommer att vara glada att se din åsikt i kommentarerna och tack för din uppmärksamhet!
Artikeln utarbetades av Rostelecoms datahanteringsteam
Källa: will.com