Apache Bigtop at pumipili ng pamamahagi ng Hadoop ngayon

Apache Bigtop at pumipili ng pamamahagi ng Hadoop ngayon

Malamang na hindi lihim na ang nakaraang taon ay isang taon ng malalaking pagbabago para sa Apache Hadoop. Noong nakaraang taon, pinagsama ang Cloudera at Hortonworks (sa pangkalahatan, ang pagkuha ng huli), at ang Mapr, dahil sa malubhang problema sa pananalapi, ay naibenta sa Hewlett Packard. At kung ilang taon na ang nakalilipas, sa kaso ng mga nasa nasasakupang pag-install, madalas na kailangang gawin ang pagpili sa pagitan ng Cloudera at Hortonworks, ngayon, sayang, wala kaming pagpipiliang ito. Ang isa pang sorpresa ay ang katotohanan na inanunsyo ng Cloudera noong Pebrero ng taong ito na ititigil nito ang pagpapalabas ng mga binary assemblies ng pamamahagi nito sa pampublikong imbakan, at magagamit na lamang ang mga ito sa pamamagitan ng isang bayad na subscription. Siyempre, posible pa ring i-download ang pinakabagong mga bersyon ng CDH at HDP na inilabas bago matapos ang 2019, at inaasahan ang suporta para sa mga ito sa loob ng isa hanggang dalawang taon. Ngunit ano ang susunod na gagawin? Para sa mga naunang nagbayad para sa isang subscription, walang nagbago. At para sa mga hindi gustong lumipat sa bayad na bersyon ng pamamahagi, ngunit nais pa ring makatanggap ng mga pinakabagong bersyon ng mga bahagi ng cluster, pati na rin ang mga patch at iba pang mga update, inihanda namin ang artikulong ito. Sa loob nito ay isasaalang-alang namin ang mga posibleng opsyon para makaalis sa sitwasyong ito.

Ang artikulo ay higit pa sa isang pagsusuri. Hindi ito maglalaman ng paghahambing ng mga pamamahagi at isang detalyadong pagsusuri ng mga ito, at walang mga recipe para sa pag-install at pag-configure ng mga ito. Ano ang mangyayari? Sa madaling sabi ay pag-uusapan natin ang tungkol sa naturang pamamahagi tulad ng Arenadata Hadoop, na nararapat sa ating pansin dahil sa pagkakaroon nito, na napakabihirang ngayon. At pagkatapos ay pag-uusapan natin ang tungkol sa Vanilla Hadoop, higit sa lahat tungkol sa kung paano ito maaaring "luto" gamit ang Apache Bigtop. handa na? Pagkatapos ay maligayang pagdating sa pusa.

Arenadata Hadoop

Apache Bigtop at pumipili ng pamamahagi ng Hadoop ngayon

Ito ay isang ganap na bago at, sa ngayon, hindi gaanong kilalang distribution kit ng domestic development. Sa kasamaang palad, sa sandaling ito sa HabrΓ© mayroon lamang ang artikulong ito.

Higit pang impormasyon ay matatagpuan sa opisyal Online proyekto. Ang mga pinakabagong bersyon ng pamamahagi ay batay sa Hadoop 3.1.2 para sa bersyon 3, at 2.8.5 para sa bersyon 2.

Ang impormasyon tungkol sa roadmap ay matatagpuan dito.

Apache Bigtop at pumipili ng pamamahagi ng Hadoop ngayon
Arenadata Cluster Manager Interface

Ang pangunahing produkto ng Arenadata ay Arenadata Cluster Manager (ADCM), na ginagamit upang i-install, i-configure at subaybayan ang iba't ibang mga solusyon sa software ng kumpanya. Ang ADCM ay ipinamamahagi nang walang bayad, at ang pagpapagana nito ay pinalawak sa pamamagitan ng pagdaragdag ng mga bundle, na isang hanay ng mga ansible-playbook. Ang mga bundle ay nahahati sa dalawang uri: enterprise at community. Ang huli ay magagamit para sa libreng pag-download mula sa website ng Arenadata. Posible ring bumuo ng sarili mong bundle at ikonekta ito sa ADCM.

Para sa pag-deploy at pamamahala ng Hadoop 3, isang bersyon ng komunidad ng bundle ay inaalok kasabay ng ADCM, ngunit para sa Hadoop 2 mayroon lamang Apache Ambari bilang kapalit. Tulad ng para sa mga repositoryo na may mga pakete, bukas sila sa pampublikong pag-access, maaari silang ma-download at mai-install sa karaniwang paraan para sa lahat ng mga bahagi ng kumpol. Sa pangkalahatan, ang pamamahagi ay mukhang napaka-interesante. Sigurado ako na may mga bihasa sa mga solusyon tulad ng Cloudera Manager at Ambari, at magugustuhan mismo ang ADCM. Para sa ilan, ito rin ay magiging isang malaking plus na ang pamamahagi kasama sa rehistro ng software para sa pagpapalit ng import.

Kung pag-uusapan natin ang mga disadvantages, magiging pareho ang mga ito sa lahat ng iba pang distribusyon ng Hadoop. Namely:

  • Ang tinatawag na "vendor lock-in". Gamit ang mga halimbawa ng Cloudera at Hortonworks, napagtanto na namin na palaging may panganib na baguhin ang patakaran ng kumpanya.
  • Malaking lag sa likod ng Apache upstream.

Vanilla Hadoop

Apache Bigtop at pumipili ng pamamahagi ng Hadoop ngayon

Tulad ng alam mo, ang Hadoop ay hindi isang monolitikong produkto, ngunit, sa katunayan, isang buong kalawakan ng mga serbisyo sa paligid ng ipinamamahaging file system na HDFS. Ilang tao ang magkakaroon ng sapat na isang file cluster. Ang ilan ay nangangailangan ng Hive, ang iba ay Presto, at pagkatapos ay mayroong HBase at ang Phoenix ay lalong ginagamit. Para sa orkestrasyon at pag-load ng data, minsan ay matatagpuan ang Oozie, Sqoop at Flume. At kung ang isyu ng seguridad ay lumitaw, pagkatapos ay Kerberos kasabay ng Ranger ang agad na pumasok sa isip.

Ang mga binary na bersyon ng mga bahagi ng Hadoop ay makukuha sa website ng bawat isa sa mga proyekto ng ecosystem sa anyo ng mga tarball. Maaari mong i-download ang mga ito at simulan ang pag-install, ngunit may isang kundisyon: bilang karagdagan sa independiyenteng pag-assemble ng mga pakete mula sa "raw" na mga binary, na malamang na gusto mong gawin, hindi ka magkakaroon ng anumang kumpiyansa sa pagiging tugma ng mga na-download na bersyon ng mga bahagi sa bawat isa. iba pa. Ang ginustong opsyon ay ang bumuo gamit ang Apache Bigtop. Bigtop ay magbibigay-daan sa iyo upang bumuo mula sa Apache maven repositoryo, magpatakbo ng mga pagsubok at bumuo ng mga pakete. Ngunit, ang napakahalaga para sa amin, bubuuin ng Bigtop ang mga bersyon ng mga bahaging iyon na magkatugma sa isa't isa. Pag-uusapan natin ito nang mas detalyado sa ibaba.

Apache Bigtop

Apache Bigtop at pumipili ng pamamahagi ng Hadoop ngayon

Ang Apache Bigtop ay isang tool para sa pagbuo, pag-iimpake at pagsubok ng ilang
mga open source na proyekto, tulad ng Hadoop at Greenplum. Marami ang Bigtop
naglalabas. Sa oras ng pagsulat, ang pinakabagong stable na release ay bersyon 1.4,
at sa master mayroong 1.5. Iba't ibang bersyon ng mga release ang gumagamit ng iba't ibang bersyon
mga bahagi. Halimbawa, para sa 1.4 Hadoop core na mga bahagi ay may bersyon 2.8.5, at sa master
2.10.0. Ang komposisyon ng mga sinusuportahang bahagi ay nagbabago din. Isang bagay na hindi napapanahon at
ang hindi nababago ay nawawala, at sa lugar nito ay may bago, higit na hinihiling, at
ito ay hindi kinakailangang isang bagay mula sa pamilya Apache mismo.

Bilang karagdagan, marami ang Bigtop mga tinidor.

Noong nagsimula kaming makilala ang Bigtop, una sa lahat, nagulat kami sa katamtaman nito, kung ihahambing sa iba pang mga proyekto ng Apache, pagkalat at katanyagan, pati na rin ang napakaliit na komunidad. Ito ay sumusunod mula dito na mayroong kaunting impormasyon sa produkto, at ang paghahanap ng mga solusyon sa mga problema na lumitaw sa mga forum at mga mailing list ay maaaring hindi magbunga ng anuman. Sa una, ito ay naging isang mahirap na gawain para sa amin upang makumpleto ang kumpletong pagpupulong ng pamamahagi dahil sa mga tampok ng tool mismo, ngunit pag-uusapan natin ito sa ibang pagkakataon.

Bilang isang teaser, ang mga taong minsan ay interesado sa mga proyekto ng uniberso ng Linux gaya ng Gentoo at LFS ay maaaring makitang kaaya-aya sa nostalgic na magtrabaho kasama ang bagay na ito at alalahanin ang mga "epiko" na oras na tayo mismo ay naghahanap (o kahit na nagsusulat) ebuild at regular na itinayong muli ang Mozilla gamit ang mga bagong patch.

Ang malaking bentahe ng Bigtop ay ang pagiging bukas at versatility ng mga tool kung saan ito nakabatay. Ito ay batay sa Gradle at Apache Maven. Kilala ang Gradle bilang tool na ginagamit ng Google para bumuo ng Android. Ito ay nababaluktot, at, gaya ng sinasabi nila, "nasubok sa labanan." Ang Maven ay isang karaniwang tool para sa pagbuo ng mga proyekto sa Apache mismo, at dahil karamihan sa mga produkto nito ay inilabas sa pamamagitan ng Maven, hindi rin ito magagawa kung wala ito dito. Ito ay nagkakahalaga ng pagbibigay pansin sa POM (modelo ng object ng proyekto) - isang "pangunahing" xml file na naglalarawan ng lahat ng kailangan para sa Maven upang gumana sa iyong proyekto, kung saan ang lahat ng trabaho ay binuo. Eksakto sa
bahagi ng Maven at may ilang mga hadlang na kadalasang nararanasan ng mga user ng Bigtop sa unang pagkakataon.

Pagsasanay

Kaya saan ka dapat magsimula? Pumunta sa pahina ng pag-download at i-download ang pinakabagong stable na bersyon bilang isang archive. Makakakita ka rin ng mga binary artifact na kinokolekta ng Bigtop doon. Sa pamamagitan ng paraan, kabilang sa mga karaniwang manager ng package, ang YUM at APT ay sinusuportahan.

Bilang kahalili, maaari mong i-download ang pinakabagong stable na release nang direkta mula sa
github:

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

Pag-clone sa "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), Π³ΠΎΡ‚ΠΎΠ²ΠΎ.

Ang resultang ./bigtop na direktoryo ay ganito ang hitsura:

./bigtop-bigpetstore β€” mga demo application, mga sintetikong halimbawa
./bigtop-ci - Mga tool sa CI, jenkins
./bigtop-data-generators β€” pagbuo ng data, synthetics, para sa mga pagsubok sa usok, atbp.
./bigtop-deploy - mga tool sa pag-deploy
./bigtop-packages β€” mga config, script, patch para sa pagpupulong, ang pangunahing bahagi ng tool
./bigtop-test-framework - balangkas ng pagsubok
./bigtop-tests β€” ang mga pagsubok mismo, nag-load at naninigarilyo
./bigtop_toolchain β€” kapaligiran para sa pagpupulong, paghahanda ng kapaligiran para gumana ang tool
./build β€” bumuo ng gumaganang direktoryo
./dl β€” direktoryo para sa mga na-download na mapagkukunan
./docker β€” pagbuo sa mga docker na imahe, pagsubok
./gradle - gradle config
./output – ang direktoryo kung saan napupunta ang mga build artifact
./provisioner β€” paglalaan

Ang pinaka-kagiliw-giliw na bagay para sa amin sa yugtong ito ay ang pangunahing config ./bigtop/bigtop.bom, kung saan nakikita namin ang lahat ng sinusuportahang bahagi na may mga bersyon. Dito natin matutukoy ang ibang bersyon ng produkto (kung biglang gusto nating subukang buuin ito) o isang bersyon ng build (kung, halimbawa, nagdagdag kami ng makabuluhang patch).

Malaki rin ang interes ng subdirectory ./bigtop/bigtop-packages, na direktang nauugnay sa proseso ng pag-assemble ng mga bahagi at mga pakete sa kanila.

Kaya, na-download namin ang archive, na-unpack ito o gumawa ng isang clone mula sa github, maaari ba naming simulan ang pagbuo?

Hindi, ihanda muna natin ang kapaligiran.

Paghahanda sa Kapaligiran

At dito kailangan namin ng isang maliit na pag-urong. Upang makabuo ng halos anumang higit pa o hindi gaanong kumplikadong produkto, kailangan mo ng isang tiyak na kapaligiran - sa aming kaso, ito ang JDK, ang parehong mga nakabahaging aklatan, mga file ng header, atbp., Mga tool, halimbawa, ant, ivy2 at marami pa. Isa sa mga opsyon para makuha ang environment na kailangan mo para sa Bigtop ay ang pag-install ng mga kinakailangang component sa build host. Maaaring mali ako sa kronolohiya, ngunit tila sa bersyon 1.0 ay mayroon ding opsyon na bumuo ng mga pre-configure at naa-access na mga imahe ng Docker, na makikita dito.

Tulad ng para sa paghahanda ng kapaligiran, mayroong isang katulong para dito - Puppet.

Maaari mong gamitin ang mga sumusunod na command, tumakbo mula sa root directory
kasangkapan, ./bigtop:

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

O direkta sa pamamagitan ng puppet:

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"

Sa kasamaang palad, ang mga paghihirap ay maaaring lumitaw na sa yugtong ito. Ang pangkalahatang payo dito ay gumamit ng suportadong pamamahagi, napapanahon sa build host, o subukan ang ruta ng docker.

Assembly

Ano ang maaari nating subukang kolektahin? Ang sagot sa tanong na ito ay ibibigay ng output ng command

./gradlew tasks

Sa seksyong Mga gawain sa Package mayroong ilang mga produkto na panghuling artifact ng Bigtop.
Maaari silang makilala sa pamamagitan ng suffix -rpm o -pkg-ind (sa kaso ng gusali
sa pantalan). Sa aming kaso, ang pinaka-kawili-wili ay Hadoop.

Subukan nating bumuo sa kapaligiran ng ating build server:

./gradlew hadoop-rpm

Ang Bigtop mismo ang magda-download ng mga kinakailangang source na kailangan para sa isang partikular na component at magsisimulang mag-assemble. Kaya, ang pagpapatakbo ng tool ay nakasalalay sa mga repositoryo ng Maven at iba pang mga mapagkukunan, iyon ay, nangangailangan ito ng pag-access sa Internet.

Sa panahon ng operasyon, ang karaniwang output ay nabuo. Minsan ito at ang mga mensahe ng error ay makakatulong sa iyo na maunawaan kung ano ang naging mali. At kung minsan kailangan mong makakuha ng karagdagang impormasyon. Sa kasong ito ito ay nagkakahalaga ng pagdaragdag ng mga argumento --info o --debug, at maaari ding maging kapaki-pakinabang –stacktrace. Mayroong isang maginhawang paraan upang makabuo ng set ng data para sa kasunod na pag-access sa mga mailing list, ang susi --scan.

Sa tulong nito, kukunin ng bigtop ang lahat ng impormasyon at ilalagay ito sa gradle, pagkatapos nito ay magbibigay ito ng link,
sa pamamagitan ng pagsunod sa kung saan, ang isang karampatang tao ay magagawang maunawaan kung bakit nabigo ang pagpupulong.
Mangyaring magkaroon ng kamalayan na ang opsyong ito ay maaaring maglantad ng impormasyong hindi mo gusto, tulad ng mga username, node, environment variable, atbp., kaya mag-ingat.

Kadalasan ang mga pagkakamali ay bunga ng kawalan ng kakayahang makakuha ng anumang mga sangkap na kinakailangan para sa pagpupulong. Karaniwan, maaari mong ayusin ang problema sa pamamagitan ng paggawa ng patch upang ayusin ang isang bagay sa mga pinagmulan, halimbawa, mga address sa pom.xml sa root directory ng mga source. Ginagawa ito sa pamamagitan ng paglikha at paglalagay nito sa naaangkop na direktoryo ./bigtop/bigtop-packages/src/common/oozie/ patch, halimbawa, sa form 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>

Malamang, sa oras ng pagbabasa ng artikulong ito, hindi mo na kailangang gawin ang itaas na ayusin ang iyong sarili.

Kapag nagpapakilala ng anumang mga patch at pagbabago sa mekanismo ng pagpupulong, maaaring kailanganin mong "i-reset" ang pagpupulong gamit ang command ng paglilinis:

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

Ibabalik ng operasyong ito ang lahat ng mga pagbabago sa pagpupulong ng sangkap na ito, pagkatapos ay isasagawa muli ang pagpupulong. Sa pagkakataong ito susubukan naming buuin ang proyekto sa isang docker na imahe:

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

Ginawa ang build sa ilalim ng CentOS, ngunit maaari ding gawin sa ilalim ng Ubuntu:

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

Bilang karagdagan sa pagbuo ng mga pakete para sa iba't ibang mga distribusyon ng Linux, ang tool ay maaaring lumikha ng isang repositoryo na may pinagsama-samang mga pakete, halimbawa:

./gradlew yum

Maaari mo ring tandaan ang tungkol sa mga pagsubok sa usok at pag-deploy sa Docker.

Lumikha ng isang kumpol ng tatlong node:

./gradlew -Pnum_instances=3 docker-provisioner

Magpatakbo ng mga pagsubok sa usok sa isang kumpol ng tatlong node:

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

Magtanggal ng cluster:

./gradlew docker-provisioner-destroy

Kumuha ng mga utos para sa pagkonekta sa loob ng mga lalagyan ng docker:

./gradlew docker-provisioner-ssh

Ipakita ang katayuan:

./gradlew docker-provisioner-status

Maaari kang magbasa nang higit pa tungkol sa mga gawain sa Pag-deploy sa dokumentasyon.

Kung pinag-uusapan natin ang tungkol sa mga pagsubok, mayroong isang malaking bilang ng mga ito, pangunahin ang usok at pagsasama. Ang kanilang pagsusuri ay lampas sa saklaw ng artikulong ito. Sabihin ko lang na ang pag-assemble ng distribution kit ay hindi kasing hirap ng isang gawain na tila sa unang tingin. Nagawa naming mag-assemble at pumasa sa mga pagsubok sa lahat ng mga bahagi na ginagamit namin sa aming produksyon, at wala rin kaming problema sa pag-deploy ng mga ito at pagsasagawa ng mga pangunahing operasyon sa kapaligiran ng pagsubok.

Bilang karagdagan sa mga umiiral na bahagi sa Bigtop, posibleng magdagdag ng anupaman, maging ang sarili mong software development. Ang lahat ng ito ay ganap na awtomatiko at akma sa konsepto ng CI/CD.

Konklusyon

Malinaw, ang pamamahagi na pinagsama-sama sa ganitong paraan ay hindi dapat agad na ipadala sa produksyon. Kailangan mong maunawaan na kung mayroong isang tunay na pangangailangan upang bumuo at suportahan ang iyong pamamahagi, pagkatapos ay kailangan mong mamuhunan ng pera at oras dito.

Gayunpaman, sa kumbinasyon ng tamang diskarte at isang propesyonal na koponan, posible na gawin nang walang mga komersyal na solusyon.

Mahalagang tandaan na ang proyekto mismo ng Bigtop ay nangangailangan ng pagpapaunlad at mukhang hindi aktibong binuo ngayon. Ang pag-asam ng Hadoop 3 na lumilitaw dito ay hindi rin malinaw, kung mayroon kang tunay na pangangailangan upang bumuo ng Hadoop 3, maaari mong tingnan tinidor mula sa Arenadata, kung saan, bilang karagdagan sa pamantayan
Mayroong ilang mga karagdagang bahagi (Ranger, Knox, NiFi).

Tulad ng para sa Rostelecom, para sa amin ang Bigtop ay isa sa mga opsyon na isinasaalang-alang ngayon. Pipiliin man natin o hindi, oras ang magsasabi.

Apendiks

Upang magsama ng bagong bahagi sa assembly, kailangan mong idagdag ang paglalarawan nito sa bigtop.bom at ./bigtop-packages. Maaari mong subukang gawin ito sa pamamagitan ng pagkakatulad sa mga umiiral na bahagi. Subukan upang malaman ito. Ito ay hindi kasing hirap na tila sa unang tingin.

Ano sa tingin mo? Natutuwa kaming makita ang iyong opinyon sa mga komento at salamat sa iyong pansin!

Ang artikulo ay inihanda ng pangkat ng pamamahala ng data ng Rostelecom

Pinagmulan: www.habr.com

Magdagdag ng komento