Apache Bigtop kaj elektante Hadoop-distribuon hodiaŭ

Verŝajne ne estas sekreto, ke la pasinta jaro estis jaro de grandaj ŝanĝoj por Apache Hadoop. Pasintjare, Cloudera kaj Hortonworks kunfandiĝis (esence, la akiro de ĉi-lasta), kaj Mapr, pro gravaj financaj problemoj, estis vendita al Hewlett Packard. Kaj se kelkajn jarojn pli frue, en la kazo de surlokaj instalaĵoj, la elekto ofte devis esti farita inter Cloudera kaj Hortonworks, hodiaŭ, ve, ni ne havas ĉi tiun elekton. Alia surprizo estis la fakto, ke Cloudera anoncis en februaro de ĉi tiu jaro, ke ĝi ĉesos liberigi binarajn asembleojn de sia distribuo en la publikan deponejon, kaj ili nun haveblas nur per pagita abono. Kompreneble, ankoraŭ eblas elŝuti la plej novajn versiojn de CDH kaj HDP publikigitaj antaŭ la fino de 2019, kaj subteno por ili estas atendita dum unu ĝis du jaroj. Sed kion fari poste? Por tiuj, kiuj antaŭe pagis por abono, nenio ŝanĝiĝis. Kaj por tiuj, kiuj ne volas ŝanĝi al la pagita versio de la distribuo, sed samtempe volas povi ricevi la plej novajn versiojn de cluster-komponentoj, same kiel flikojn kaj aliajn ĝisdatigojn, ni preparis ĉi tiun artikolon. En ĝi ni konsideros eblajn eblojn por eliri el ĉi tiu situacio.

La artikolo estas pli de recenzo. Ĝi ne enhavos komparon de distribuoj kaj detalan analizon de ili, kaj ne estos receptoj por instali kaj agordi ilin. Kio okazos? Ni mallonge parolos pri tia distribuo kiel Arenadata Hadoop, kiu ĝuste meritas nian atenton pro sia havebleco, kiu estas tre malofta hodiaŭ. Kaj poste ni parolos pri Vanilla Hadoop, ĉefe pri kiel ĝi povas esti "kuirita" uzante Apache Bigtop. Preta? Tiam bonvenon al kato.

Arenadata Hadoop

Ĉi tio estas tute nova kaj ĝis nun malmulte konata distribua kompleto de hejma disvolviĝo. Bedaŭrinde, nuntempe sur Habré ekzistas nur ĉi tiu artikolo.

Pliaj informoj troveblas ĉe la oficiala ejo projekto. La plej novaj versioj de la distribuo baziĝas sur Hadoop 3.1.2 por versio 3, kaj 2.8.5 por versio 2.

Informoj pri la vojmapo troveblas tie.

Arenadata Cluster Manager Interfaco

La kerna produkto de Arenadata estas Arenadata Cluster Manager (ADCM), kiu estas uzata por instali, agordi kaj monitori diversajn firmaajn softvarsolvojn. ADCM estas distribuita senpage, kaj ĝia funkcieco estas vastigita per aldonado de pakaĵoj, kiuj estas aro de ansible-ludlibroj. Pakoj estas dividitaj en du tipojn: entrepreno kaj komunumo. Ĉi-lastaj estas disponeblaj senpage elŝutebla de la retejo Arenadata. Ankaŭ eblas evoluigi vian propran pakaĵon kaj konekti ĝin al ADCM.

Por deplojo kaj administrado de Hadoop 3, komunuma versio de la pakaĵo estas ofertita kune kun ADCM, sed por Hadoop 2 ekzistas nur Apache Ambari kiel alternativo. Koncerne deponejojn kun pakaĵoj, ili estas malfermitaj al publika aliro, ili povas esti elŝutitaj kaj instalitaj laŭ la kutima maniero por ĉiuj komponantoj de la grapolo. Ĝenerale, la distribuo aspektas tre interesa. Mi certas, ke estos tiuj, kiuj kutimas solvojn kiel Cloudera Manager kaj Ambari, kaj kiuj ŝatos ADCM mem. Por iuj, ĝi ankaŭ estos grandega pluso ke la dissendo inkluzivita en la programara registro por import-anstataŭigo.

Se ni parolas pri la malavantaĝoj, ili estos la samaj kiel por ĉiuj aliaj Hadoop-distribuoj. Nome:

• La tiel nomata "vendlock-in". Uzante la ekzemplojn de Cloudera kaj Hortonworks, ni jam rimarkis, ke ĉiam estas risko ŝanĝi kompanian politikon.
• Signifa malfruo malantaŭ Apache kontraŭflue.

Vanilo Hadoop

Kiel vi scias, Hadoop ne estas monolita produkto, sed, fakte, tuta galaksio da servoj ĉirkaŭ sia distribuita dosiersistemo HDFS. Malmultaj homoj havos sufiĉe da unu dosieraro. Iuj bezonas Hive, aliaj Presto, kaj poste estas HBase kaj Phoenix; Spark estas ĉiam pli uzata. Por instrumentado kaj datumŝarĝado, foje troviĝas Oozie, Sqoop kaj Flume. Kaj se la problemo de sekureco ŝprucas, tiam Kerberos kune kun Ranger tuj venas al la menso.

Binaraj versioj de Hadoop-komponentoj estas haveblaj en la retejo de ĉiu el la ekosistemaj projektoj en formo de tarballs. Vi povas elŝuti ilin kaj komenci la instaladon, sed kun unu kondiĉo: krom sendepende kunmeti pakaĵojn el "krudaj" binaroj, kiujn vi plej verŝajne volas fari, vi ne havos neniun konfidon pri la kongruo de la elŝutitaj versioj de komponantoj kun ĉiu. alia. La preferata opcio estas konstrui per Apache Bigtop. Bigtop permesos al vi konstrui el Apache maven-deponejoj, ruli testojn kaj konstrui pakaĵojn. Sed, kio estas tre grava por ni, Bigtop kunvenos tiujn versiojn de komponantoj, kiuj estos kongruaj unu kun la alia. Ni parolos pri ĝi pli detale sube.

Apache Bigtop

Apache Bigtop estas ilo por konstrui, paki kaj testi kelkajn
malfermkodaj projektoj, kiel ekzemple Hadoop kaj Greenplum. Bigtop havas multe
eldonoj. Dum la skribado, la plej nova stabila eldono estis versio 1.4,
kaj en majstro estis 1.5. Malsamaj versioj de eldonoj uzas malsamajn versiojn
komponantoj. Ekzemple, por 1.4 Hadoop-kernkomponentoj havas version 2.8.5, kaj en majstro
2.10.0. La konsisto de subtenataj komponantoj ankaŭ ŝanĝiĝas. Io malmoderna kaj
la nerenovigebla foriras, kaj anstata?as io nova, pli postulata, kaj
ĝi ne estas nepre io el la Apache-familio mem.

Krome, Bigtop havas multajn forkoj.

Kiam ni komencis konatiĝi kun Bigtop, ni estis antaŭ ĉio surprizitaj de ĝia modesta, kompare kun aliaj Apache-projektoj, ofteco kaj populareco, same kiel tre malgranda komunumo. El tio sekvas, ke ekzistas minimuma informo pri la produkto, kaj serĉado de solvoj al problemoj aperintaj en forumoj kaj dissendolistoj eble tute ne donas ion. Komence, rezultis por ni malfacila tasko kompletigi la kompletan asembleon de la distribuo pro la trajtoj de la ilo mem, sed pri tio ni parolos iom poste.

Kiel teaser, tiuj, kiuj iam interesiĝis pri tiaj projektoj de la Linukso-universo kiel Gentoo kaj LFS eble trovos nostalgie agrable labori kun ĉi tiu afero kaj memori tiujn "epopeajn" tempojn, kiam ni mem serĉis (aŭ eĉ skribis) ebuilds kaj regule rekonstruis Mozilon per novaj pecetoj.

La granda avantaĝo de Bigtop estas la malfermiteco kaj ĉiuflankeco de la iloj sur kiuj ĝi baziĝas. Ĝi estas bazita sur Gradle kaj Apache Maven. Gradle estas sufiĉe konata kiel la ilo kiun Guglo uzas por konstrui Android. Ĝi estas fleksebla, kaj, kiel oni diras, "batalprovita." Maven estas norma ilo por konstrui projektojn en Apache mem, kaj ĉar la plej multaj el ĝiaj produktoj estas liberigitaj per Maven, ĝi ankaŭ ne povus esti farita sen ĝi ĉi tie. Indas atenti la POM (projekta objekta modelo) - la "fundamenta" xml-dosiero priskribanta ĉion necesan por ke Maven funkciu kun via projekto, ĉirkaŭ kiu estas konstruita la tuta laboro. Ĝuste je
partoj de Maven kaj estas iuj obstakloj, kiujn unuafojaj Bigtop-uzantoj kutime renkontas.

Praktiko

Do kie vi devas komenci? Iru al la elŝuta paĝo kaj elŝutu la lastan stabilan version kiel arkivon. Vi ankaŭ povas trovi binarajn artefaktojn kolektitajn de Bigtop tie. Cetere, inter la komunaj pakaj administrantoj, YUM kaj APT estas subtenataj.

Alternative, vi povas elŝuti la lastan stabilan eldonon rekte de
github:

$ git clone --branch branch-1.4 https://github.com/apache/bigtop.git

Klonado en "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), готово.

La rezulta ./bigtop dosierujo aspektas kiel ĉi tio:

./bigtop-bigpetstore — demo-aplikoj, sintezaj ekzemploj
./bigtop-ci - CI-iloj, jenkins
./bigtop-data-generators — datumgenerado, sintezaj, por fumtestoj, ktp.
./bigtop-deploy - disfaldaj iloj
./bigtop-packages — agordoj, skriptoj, pecetoj por kunigo, la ĉefa parto de la ilo
./bigtop-test-framework — prova kadro
./bigtop-tests — la testoj mem, ŝarĝas kaj fumas
./bigtop_toolchain — medio por muntado, preparante la medion por ke la ilo funkciu
./build — konstrui labordosierujon
./dl — dosierujo por elŝutitaj fontoj
./docker — konstrui en docker bildoj, testado
./gradle - gradle agordo
./output - la dosierujo kie konstruaj artefaktoj iras
./provisioner — provizado

La plej interesa afero por ni en ĉi tiu etapo estas la ĉefa agordo ./bigtop/bigtop.bom, en kiu ni vidas ĉiujn subtenatajn komponantojn kun versioj. Jen kie ni povas specifi malsaman version de la produkto (se ni subite volas provi konstrui ĝin) aŭ konstruan version (se, ekzemple, ni aldonis signifan flikaĵon).

La subdosierujo estas ankaŭ tre interesa ./bigtop/bigtop-packages, kiu rekte rilatas al la procezo kunmeti komponantojn kaj pakaĵojn kun ili.

Do, ni elŝutis la arkivon, malpakis ĝin aŭ faris klonon de github, ĉu ni povas komenci konstrui?

Ne, ni unue preparu la medion.

Preparante la Medion

Kaj ĉi tie ni bezonas malgrandan retiriĝon. Por konstrui preskaŭ ajnan pli aŭ malpli kompleksan produkton, vi bezonas certan medion - en nia kazo, ĉi tio estas la JDK, la samaj komunaj bibliotekoj, kapdosieroj ktp., iloj, ekzemple ant, ivy2 kaj multe pli. Unu el la ebloj por akiri la medion, kiun vi bezonas por Bigtop, estas instali la necesajn komponantojn sur la konstrua gastiganto. Mi povus erari en la kronologio, sed ŝajnas, ke ĉe la versio 1.0 ankaŭ estis eblo konstrui antaŭkonfiguritajn kaj alireblajn bildojn de Docker, kiuj troviĝas ĉi tie.

Koncerne prepari la medion, ekzistas asistanto por tio - Marioneto.

Vi povas uzi la jenajn komandojn, rulitajn de la radika dosierujo
ilo, ./bigtop:

./gradlew toolchain
./gradlew toolchain-devtools
./gradlew toolchain-puppetmodules

Aŭ rekte per marioneto:

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"

Bedaŭrinde, malfacilaĵoj povas ekesti jam en ĉi tiu etapo. La ĝenerala konsilo ĉi tie estas uzi subtenan distribuon, ĝisdatigitan pri la konstrua gastiganto, aŭ provi la docker-itineron.

Asembleo

Kion ni povas provi kolekti? La respondo al ĉi tiu demando estos donita de la eligo de la komando

./gradlew tasks

En la sekcio de Pakaj taskoj estas kelkaj produktoj, kiuj estas finaj artefaktoj de Bigtop.
Ili povas esti identigitaj per la sufikso -rpm aŭ -pkg-ind (kaze de konstruaĵo
en docker). En nia kazo, la plej interesa estas Hadoop.

Ni provu konstrui en la medio de nia konstruservilo:

./gradlew hadoop-rpm

Bigtop mem elŝutos la necesajn fontojn necesajn por specifa komponanto kaj komencos muntadon. Tiel, la funkciado de la ilo dependas de Maven-deponejoj kaj aliaj fontoj, tio estas, ĝi postulas Interretan aliron.

Dum operacio, norma eligo estas generita. Foje ĝi kaj erarmesaĝoj povas helpi vin kompreni kio misfunkciis. Kaj foje vi bezonas akiri pliajn informojn. En ĉi tiu kazo indas aldoni argumentojn --info aŭ --debug, kaj ankaŭ povas esti utila –stacktrace. Estas oportuna maniero por generi datuman aron por posta aliro al dissendolistoj, la ŝlosilo --scan.

Kun ĝia helpo, bigtop kolektos ĉiujn informojn kaj metos ĝin en gradle, post kio ĝi provizos ligilon,
sekvante tion, kompetenta persono povos kompreni kial la asembleo malsukcesis.
Bonvolu konscii, ke ĉi tiu opcio povas elmontri informojn, kiujn vi ne volas, kiel uzantnomoj, nodoj, mediovariabloj ktp., do atentu.

Ofte eraroj estas sekvo de la malkapablo akiri iujn ajn komponentojn necesajn por kunigo. Tipe, vi povas ripari la problemon kreante diakilon por ripari ion en la fontoj, ekzemple, adresoj en pom.xml en la radika dosierujo de la fontoj. Ĉi tio estas farita kreante kaj metante ĝin en la taŭgan dosierujon ./bigtop/bigtop-packages/src/common/oozie/ flikaĵo, ekzemple, en la formo 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>

Plej verŝajne, dum la legado de ĉi tiu artikolo, vi ne devos fari la supre ripari vin mem.

Kiam vi enkondukas iujn diakilojn kaj ŝanĝojn al la kunigmekanismo, vi eble bezonos "restarigi" la kunigon per la puriga komando:

./gradlew hadoop-clean
> Task :hadoop_vardefines
> Task :hadoop-clean
BUILD SUCCESSFUL in 5s
2 actionable tasks: 2 executed

Ĉi tiu operacio retroigos ĉiujn ŝanĝojn al la kunigo de ĉi tiu komponanto, post kio la kunigo estos farita denove. Ĉi-foje ni provos konstrui la projekton en docker-bildo:

./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 executed

La konstruo estis farita sub CentOS, sed ankaŭ povas esti farita sub Ubuntu:

./gradlew -POS=ubuntu-16.04 -Pprefix=1.2.1 hadoop-pkg-ind

Krom konstrui pakaĵojn por diversaj Linukso-distribuoj, la ilo povas krei deponejon kun kompilitaj pakaĵoj, ekzemple:

./gradlew yum

Vi ankaŭ povas memori pri fumtestoj kaj deplojo en Docker.

Kreu areton de tri nodoj:

./gradlew -Pnum_instances=3 docker-provisioner

Faru fumtestojn en aro de tri nodoj:

./gradlew -Pnum_instances=3 -Prun_smoke_tests docker-provisioner

Forigi areton:

./gradlew docker-provisioner-destroy

Akiru komandojn por konekti en docker-ujoj:

./gradlew docker-provisioner-ssh

Montri staton:

./gradlew docker-provisioner-status

Vi povas legi pli pri Deplojaj taskoj en la dokumentado.

Se ni parolas pri testoj, ekzistas sufiĉe granda nombro da ili, ĉefe fumo kaj integriĝo. Ilia analizo estas ekster la amplekso de ĉi tiu artikolo. Mi nur diru, ke kunmeti distribuan ilaron ne estas tiel malfacila tasko kiel ĝi povus ŝajni unuavide. Ni sukcesis kunveni kaj pasigi provojn pri ĉiuj komponantoj, kiujn ni uzas en nia produktado, kaj ni ankaŭ havis neniujn problemojn por deploji ilin kaj plenumi bazajn operaciojn en la testa medio.

Krom la ekzistantaj komponantoj en Bigtop, eblas aldoni ion alian, eĉ vian propran programaron. Ĉio ĉi estas perfekte aŭtomatigita kaj konformas al la koncepto CI/CD.

konkludo

Evidente, la distribuo tiel kompilita ne estu tuj sendita al produktado. Vi devas kompreni, ke se estas vera bezono konstrui kaj subteni vian distribuadon, tiam vi devas investi monon kaj tempon en ĉi tio.

Tamen, kombine kun la ĝusta aliro kaj profesia teamo, estas tute eble malhavi komercajn solvojn.

Gravas noti, ke la projekto Bigtop mem bezonas disvolviĝon kaj ne ŝajnas esti aktive disvolvita hodiaŭ. La perspektivo, ke Hadoop 3 aperos en ĝi ankaŭ estas neklara. Cetere, se vi havas veran bezonon konstrui Hadoop 3, vi povas rigardi. forko de Arenadata, en kiu, krom normo
Estas kelkaj pliaj komponantoj (Ranger, Knox, NiFi).

Koncerne Rostelecom, por ni Bigtop estas unu el la ebloj konsiderataj hodiaŭ. Ĉu ni elektos ĝin aŭ ne, la tempo diros.

apendico

Por inkluzivi novan komponanton en la aro, vi devas aldoni ĝian priskribon al bigtop.bom kaj ./bigtop-packages. Vi povas provi fari tion per analogio kun la ekzistantaj komponantoj. Provu eltrovi ĝin. Ĝi ne estas tiel malfacila kiel ŝajnas unuavide.

Kion vi pensas? Ni ĝojos vidi vian opinion en la komentoj kaj dankon pro via atento!

La artikolo estis preparita de la datumadministra teamo de Rostelecom

fonto: www.habr.com