Apache Bigtop և ընտրել Hadoop բաշխում այսօր

Երևի գաղտնիք չէ, որ անցյալ տարի Apache Hadoop-ի համար մեծ փոփոխությունների տարի էր։ Անցյալ տարի Cloudera-ն և Hortonworks-ը միավորվեցին (ըստ էության՝ վերջինիս ձեռքբերումը), և Mapr-ը, ֆինանսական լուրջ խնդիրների պատճառով, վաճառվեց Hewlett Packard-ին։ Եվ եթե մի քանի տարի առաջ, տարածքներում տեղադրումների դեպքում, հաճախ ընտրությունը պետք է կատարվեր Cloudera-ի և Hortonworks-ի միջև, ապա այսօր, ավաղ, մենք չունենք այս ընտրությունը: Մեկ այլ անակնկալ էր այն փաստը, որ Cloudera-ն այս տարվա փետրվարին հայտարարեց, որ կդադարեցնի իր բաշխման երկուական հավաքների թողարկումը հանրային պահեստում, և դրանք այժմ հասանելի են միայն վճարովի բաժանորդագրության միջոցով: Իհարկե, դեռևս հնարավոր է ներբեռնել CDH-ի և HDP-ի վերջին տարբերակները, որոնք թողարկվել են մինչև 2019 թվականի ավարտը, և դրանց աջակցությունը սպասվում է մեկից երկու տարի: Բայց ի՞նչ անել հետո: Նրանց համար, ովքեր նախկինում վճարել են բաժանորդագրության համար, ոչինչ չի փոխվել: Իսկ նրանց համար, ովքեր չեն ցանկանում անցնել բաշխման վճարովի տարբերակին, բայց միևնույն ժամանակ ցանկանում են ստանալ կլաստերի բաղադրիչների վերջին տարբերակները, ինչպես նաև patches և այլ թարմացումներ, մենք պատրաստել ենք այս հոդվածը։ Դրանում մենք կդիտարկենք այս իրավիճակից դուրս գալու հնարավոր տարբերակները։

Հոդվածն ավելի շատ ակնարկ է: Այն չի պարունակի բաշխումների համեմատություն և դրանց մանրամասն վերլուծություն, և դրանք տեղադրելու և կարգավորելու բաղադրատոմսեր չեն լինի: Ի՞նչ է լինելու։ Մենք հակիրճ կխոսենք այնպիսի բաշխման մասին, ինչպիսին է Arenadata Hadoop-ը, որն իրավամբ արժանի է մեր ուշադրությանը իր հասանելիության պատճառով, որն այսօր շատ հազվադեպ է: Եվ հետո մենք կխոսենք Vanilla Hadoop-ի մասին, հիմնականում այն ​​մասին, թե ինչպես կարելի է այն «եփել» Apache Bigtop-ի միջոցով: Պատրա՞ստ եք: Ապա բարի գալուստ կատու:

Arenadata Hadoop

Սա ներքին զարգացման բոլորովին նոր և, առայժմ, քիչ հայտնի բաշխման հավաքածու է: Ցավոք, այս պահին Habré-ում կա միայն այս հոդվածը.

Լրացուցիչ տեղեկություններ կարելի է գտնել պաշտոնական կայքում Առցանց նախագիծը։ Բաշխման վերջին տարբերակները հիմնված են Hadoop 3.1.2-ի վրա՝ 3-րդ տարբերակի համար, և 2.8.5-ի՝ 2-րդ տարբերակի համար:

Ճանապարհային քարտեզի մասին տեղեկություններ կարելի է գտնել այստեղ.

Arenadata Cluster Manager ինտերֆեյս

Arenadata-ի հիմնական արտադրանքն է Arenadata Cluster Manager (ADCM), որն օգտագործվում է ընկերության տարբեր ծրագրային լուծումների տեղադրման, կազմաձևման և մոնիտորինգի համար: ADCM-ը բաշխվում է անվճար, և դրա ֆունկցիոնալությունն ընդլայնվում է՝ ավելացնելով փաթեթներ, որոնք ansible-playbooks-ի հավաքածու են: Փաթեթները բաժանվում են երկու տեսակի՝ ձեռնարկություն և համայնք։ Վերջիններս հասանելի են անվճար ներբեռնման համար Arenadata կայքից։ Հնարավոր է նաև մշակել ձեր սեփական փաթեթը և միացնել այն ADCM-ին:

Hadoop 3-ի տեղակայման և կառավարման համար փաթեթի համայնքային տարբերակը առաջարկվում է ADCM-ի հետ համատեղ, բայց Hadoop 2-ի համար կա միայն Ապաչի Ամբարի որպես այլընտրանք։ Ինչ վերաբերում է փաթեթներով պահեստներին, ապա դրանք բաց են հանրային հասանելիության համար, դրանք կարելի է ներբեռնել և տեղադրել կլաստերի բոլոր բաղադրիչների համար սովորական եղանակով։ Ընդհանուր առմամբ, բաշխումը շատ հետաքրքիր է թվում: Համոզված եմ, որ կլինեն այնպիսիք, ովքեր սովոր են լուծումների, ինչպիսիք են Cloudera Manager-ը և Ambari-ն, և ում դուր կգա հենց ADCM-ն: Ոմանց համար դա կլինի նաև հսկայական գումարած, որ բաշխումը ներառված է ծրագրային գրանցամատյանում ներմուծման փոխարինման համար։

Եթե ​​խոսենք թերությունների մասին, ապա դրանք կլինեն նույնը, ինչ մյուս բոլոր Hadoop բաշխումների համար: Այսինքն:

• Այսպես կոչված «վաճառողի կողպեքը»: Օգտվելով Cloudera-ի և Hortonworks-ի օրինակներից՝ մենք արդեն հասկացել ենք, որ ընկերության քաղաքականությունը փոխելու ռիսկ միշտ կա։
• Զգալի զիջում Apache-ից հոսանքին հակառակ:

Vanilla Hadoop

Ինչպես գիտեք, Hadoop-ը մոնոլիտ արտադրանք չէ, այլ, ըստ էության, ծառայությունների մի ամբողջ գալակտիկա՝ իր բաշխված HDFS ֆայլային համակարգի շուրջ: Քչերին կբավականացնի մեկ ֆայլի կլաստեր: Ոմանք Hive-ի կարիք ունեն, մյուսներին Presto-ն, իսկ հետո կան HBase-ը և Phoenix-ը, Spark-ն ավելի ու ավելի է օգտագործվում: Նվագախմբի և տվյալների բեռնման համար երբեմն հանդիպում են Oozie, Sqoop և Flume: Իսկ եթե անվտանգության խնդիր է առաջանում, ապա անմիջապես գլխի է ընկնում Kerberos-ը Ranger-ի հետ համատեղ։

Hadoop բաղադրիչների երկուական տարբերակները հասանելի են էկոհամակարգի նախագծերից յուրաքանչյուրի կայքում՝ tarballs-ի տեսքով: Դուք կարող եք ներբեռնել դրանք և սկսել տեղադրումը, բայց մեկ պայմանով. ի լրումն «հում» բինարներից փաթեթներ ինքնուրույն հավաքելուց, ինչը, ամենայն հավանականությամբ, ցանկանում եք անել, դուք որևէ վստահություն չեք ունենա բաղադրիչների ներբեռնված տարբերակների համատեղելիության մեջ յուրաքանչյուրի հետ: այլ. Նախընտրելի տարբերակն է կառուցել Apache Bigtop-ի միջոցով: Bigtop-ը թույլ կտա ստեղծել Apache maven պահեստներից, թեստեր անցկացնել և փաթեթներ ստեղծել: Բայց, ինչ շատ կարևոր է մեզ համար, Bigtop-ը կհավաքի բաղադրիչների այն տարբերակները, որոնք համատեղելի կլինեն միմյանց հետ։ Դրա մասին ավելի մանրամասն կխոսենք ստորև։

Apache Bigtop

Apache Bigtop-ը գործիք է մի շարք սարքերի կառուցման, փաթեթավորման և փորձարկման համար
բաց կոդով նախագծեր, ինչպիսիք են Hadoop-ը և Greenplum-ը: Bigtop-ը շատ բան ունի
թողարկումներ. Գրելու պահին վերջին կայուն թողարկումը 1.4 տարբերակն էր,
իսկ վարպետում եղել է 1.5։ Թողարկումների տարբեր տարբերակներում օգտագործվում են տարբեր տարբերակներ
բաղադրիչները. Օրինակ, 1.4-ի համար Hadoop-ի հիմնական բաղադրիչներն ունեն 2.8.5 տարբերակ, իսկ վարպետում
2.10.0. Փոխվում է նաև օժանդակ բաղադրիչների կազմը։ Ինչ-որ բան հնացած և
չվերականգնվողը հեռանում է, և նրա փոխարեն գալիս է մի նոր բան, ավելի պահանջված և
դա պարտադիր չէ, որ դա հենց Ապաչի ընտանիքից լինի:

Բացի այդ, Bigtop-ը շատ ունի պատառաքաղներ.

Երբ մենք սկսեցինք ծանոթանալ Bigtop-ի հետ, մեզ առաջին հերթին զարմացրեց նրա համեստությունը՝ համեմատած այլ Apache նախագծերի, տարածվածության և հանրաճանաչության, ինչպես նաև շատ փոքր համայնքի վրա։ Սրանից հետևում է, որ ապրանքի վերաբերյալ կա նվազագույն տեղեկատվություն, և ֆորումներում և փոստային ցուցակներում առաջացած խնդիրների լուծումների որոնումը կարող է ընդհանրապես ոչինչ չտալ: Սկզբում պարզվեց, որ մեզ համար բարդ խնդիր էր բաշխման ամբողջական հավաքումն ավարտելը հենց գործիքի առանձնահատկությունների պատճառով, բայց մենք այս մասին կխոսենք մի փոքր ուշ:

Որպես թիզեր, նրանք, ովքեր մի ժամանակ հետաքրքրված էին Linux տիեզերքի այնպիսի նախագծերով, ինչպիսիք են Gentoo-ն և LFS-ը, կարող են նոստալգիկորեն հաճելի համարել այս բանի հետ աշխատելը և հիշել այն «էպիկական» ժամանակները, երբ մենք ինքներս էինք փնտրում (կամ նույնիսկ գրում) ebuilds և պարբերաբար վերակառուցում Mozilla-ն նոր patches-ով:

Bigtop-ի մեծ առավելությունն այն գործիքների բացությունն ու բազմակողմանիությունն է, որոնց վրա այն հիմնված է: Այն հիմնված է Gradle-ի և Apache Maven-ի վրա: Gradle-ը բավականին հայտնի է որպես գործիք, որն օգտագործում է Google-ը Android-ի ստեղծման համար: Այն ճկուն է և, ինչպես ասում են, «մարտական ​​փորձարկված»: Maven-ը ստանդարտ գործիք է հենց Apache-ում նախագծեր կառուցելու համար, և քանի որ նրա արտադրանքի մեծ մասը թողարկվում է Maven-ի միջոցով, առանց դրա այստեղ նույնպես դա հնարավոր չէր անել: Արժե ուշադրություն դարձնել POM-ին (նախագծի օբյեկտի մոդելը)՝ «հիմնական» xml ֆայլը, որը նկարագրում է այն ամենը, ինչ անհրաժեշտ է Maven-ին ձեր նախագծի հետ աշխատելու համար, որի շուրջ կառուցված է ամբողջ աշխատանքը: Ճիշտ ժամը
Maven-ի մասերը և կան որոշ խոչընդոտներ, որոնց սովորաբար հանդիպում են առաջին անգամ Bigtop օգտվողները:

Պրակտիկա

Այսպիսով, որտեղից պետք է սկսել: Գնացեք ներբեռնման էջ և ներբեռնեք վերջին կայուն տարբերակը որպես արխիվ: Այնտեղ կարող եք գտնել նաև Bigtop-ի կողմից հավաքված երկուական արտեֆակտներ: Ի դեպ, ընդհանուր փաթեթների կառավարիչների շարքում YUM-ը և APT-ն ապահովված են։

Որպես այլընտրանք, դուք կարող եք ներբեռնել վերջին կայուն թողարկումը անմիջապես այստեղից
github:

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

Կլոնավորում «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), готово.

Ստացված ./bigtop գրացուցակը մոտավորապես այսպիսի տեսք ունի.

./bigtop-bigpetstore — դեմո հավելվածներ, սինթետիկ օրինակներ
./bigtop-ci - CI գործիքներ, ջենկիններ
./bigtop-data-generators — տվյալների ստեղծում, սինթետիկներ, ծխի թեստերի համար և այլն:
./bigtop-deploy - տեղակայման գործիքներ
./bigtop-packages — կոնֆիգուրացիաներ, սկրիպտներ, հավաքման պատչեր, գործիքի հիմնական մասը
./bigtop-test-framework - թեստավորման շրջանակ
./bigtop-tests — թեստերն իրենք են, բեռը և ծուխը
./bigtop_toolchain — հավաքման միջավայր, գործիքի աշխատանքի համար միջավայր պատրաստելը
./build - ստեղծել աշխատանքային գրացուցակ
./dl — ներբեռնված աղբյուրների գրացուցակ
./docker — դոկերի պատկերների կառուցում, փորձարկում
./gradle - gradle կոնֆիգուրացիա
./output – գրացուցակը, որտեղ գնում են շինարարական արտեֆակտները
./provisioner - ապահովում

Այս փուլում մեզ համար ամենահետաքրքիրը հիմնական կոնֆիգուրան է ./bigtop/bigtop.bom, որում մենք տեսնում ենք բոլոր աջակցվող բաղադրիչները տարբերակներով: Այստեղ մենք կարող ենք նշել արտադրանքի այլ տարբերակ (եթե մենք հանկարծ ուզում ենք փորձել այն կառուցել) կամ կառուցապատման տարբերակ (եթե, օրինակ, մենք ավելացրել ենք նշանակալի կարկատել):

Ենթագրատունը նույնպես մեծ հետաքրքրություն է ներկայացնում ./bigtop/bigtop-packages, որն ուղղակիորեն կապված է դրանցով բաղադրիչների և փաթեթների հավաքման գործընթացի հետ։

Այսպիսով, մենք ներբեռնեցինք արխիվը, բացեցինք այն կամ github-ից կլոն արեցինք, կարո՞ղ ենք սկսել կառուցել:

Չէ, նախ միջավայրը պատրաստենք։

Շրջակա միջավայրի նախապատրաստում

Եվ այստեղ մեզ անհրաժեշտ է մի փոքր նահանջ: Գրեթե ցանկացած քիչ թե շատ բարդ արտադրանք ստեղծելու համար ձեզ անհրաժեշտ է որոշակի միջավայր. մեր դեպքում սա JDK-ն է, նույն ընդհանուր գրադարանները, վերնագրերի ֆայլերը և այլն, գործիքներ, օրինակ՝ ant, ivy2 և շատ ավելին: Bigtop-ի համար անհրաժեշտ միջավայրը ստանալու տարբերակներից մեկը build host-ի վրա անհրաժեշտ բաղադրիչների տեղադրումն է։ Ես կարող էի սխալվել ժամանակագրության մեջ, բայց թվում է, որ տարբերակ 1.0-ի դեպքում կար նաև նախապես կազմաձևված և մատչելի Docker պատկերներ կառուցելու տարբերակ, որը կարելի է գտնել այստեղ:

Ինչ վերաբերում է միջավայրը պատրաստելուն, ապա դրա համար կա օգնական՝ Տիկնիկը։

Դուք կարող եք օգտագործել հետևյալ հրամանները՝ գործարկել արմատային գրացուցակից
գործիք, ./bigtop:

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

Կամ ուղղակիորեն տիկնիկային միջոցով.

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"

Ցավոք, դժվարություններ կարող են առաջանալ արդեն այս փուլում։ Այստեղ ընդհանուր խորհուրդն այն է, որ օգտագործեք աջակցվող բաշխում, թարմացված կառուցման հոսթի վրա կամ փորձեք դոկերի երթուղին:

Ասամբլեան

Ի՞նչ կարող ենք փորձել հավաքել: Այս հարցի պատասխանը կտա հրամանի ելքը

./gradlew tasks

Փաթեթի առաջադրանքների բաժնում կան մի շարք ապրանքներ, որոնք Bigtop-ի վերջնական արտեֆակտ են:
Նրանք կարող են նույնականացվել -rpm կամ -pkg-ind վերջածանցով (շենքի դեպքում
դոկերում): Մեր դեպքում ամենահետաքրքիրը Hadoop-ն է։

Փորձենք կառուցել մեր build սերվերի միջավայրում.

./gradlew hadoop-rpm

Bigtop-ն ինքը կներբեռնի որոշակի բաղադրիչի համար անհրաժեշտ աղբյուրները և կսկսի հավաքումը: Այսպիսով, գործիքի աշխատանքը կախված է Maven պահեստներից և այլ աղբյուրներից, այսինքն՝ այն պահանջում է ինտերնետ հասանելիություն:

Գործողության ընթացքում ստացվում է ստանդարտ ելք: Երբեմն դա և սխալ հաղորդագրությունները կարող են օգնել ձեզ հասկանալ, թե ինչն է սխալ եղել: Եվ երբեմն անհրաժեշտ է լրացուցիչ տեղեկություններ ստանալ: Այս դեպքում արժե փաստարկներ ավելացնել --info կամ --debug, և կարող է նաև օգտակար լինել –stacktrace. Կա հարմար միջոց ստեղծելու տվյալների հավաքածու հետագա փոստային ցուցակների մուտքի համար, բանալին --scan.

Bigtop-ն իր օգնությամբ կհավաքի ամբողջ տեղեկատվությունը և կդնի gradle-ում, որից հետո կտրամադրի հղում,
որին հետևելով իրավասու անձը կկարողանա հասկանալ, թե ինչու տապալվեց հավաքը:
Խնդրում ենք տեղյակ լինել, որ այս տարբերակը կարող է բացահայտել այն տեղեկությունները, որոնք դուք չեք ցանկանում, ինչպիսիք են օգտվողի անունները, հանգույցները, շրջակա միջավայրի փոփոխականները և այլն, ուստի զգույշ եղեք:

Հաճախ սխալները հետևանք են հավաքման համար անհրաժեշտ որևէ բաղադրիչ ձեռք բերելու անկարողության: Սովորաբար, դուք կարող եք շտկել խնդիրը՝ ստեղծելով կարկատել՝ աղբյուրներում ինչ-որ բան շտկելու համար, օրինակ՝ pom.xml-ի հասցեները աղբյուրների արմատային գրացուցակում: Դա արվում է՝ ստեղծելով և տեղադրելով այն համապատասխան գրացուցակում ./bigtop/bigtop-packages/src/common/oozie/ կարկատել, օրինակ, ձեւով 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>

Ամենայն հավանականությամբ, այս հոդվածը կարդալու պահին դուք ստիպված չեք լինի ինքներդ անել վերը նշված ուղղումը:

Հավաքման մեխանիզմում որևէ կարկատան և փոփոխություն մտցնելիս ձեզ կարող է անհրաժեշտ լինել «վերակայել» ժողովը՝ օգտագործելով մաքրման հրամանը.

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

Այս գործողությունը կվերադարձնի այս բաղադրիչի հավաքման բոլոր փոփոխությունները, որից հետո հավաքումը նորից կկատարվի: Այս անգամ մենք կփորձենք նախագիծը կառուցել դոկերի պատկերով.

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

Կառուցումն իրականացվել է CentOS-ի ներքո, բայց կարող է իրականացվել նաև Ubuntu-ի ներքո.

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

Բացի Linux-ի տարբեր բաշխումների համար փաթեթներ կառուցելուց, գործիքը կարող է ստեղծել պահեստ՝ կազմված փաթեթներով, օրինակ՝

./gradlew yum

Կարող եք նաև հիշել ծխի թեստերի և Docker-ում տեղակայման մասին:

Ստեղծեք երեք հանգույցներից բաղկացած կլաստեր.

./gradlew -Pnum_instances=3 docker-provisioner

Ծխի թեստեր կատարեք երեք հանգույցներից բաղկացած կլաստերում.

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

Ջնջել կլաստերը՝

./gradlew docker-provisioner-destroy

Ստացեք հրամաններ դոկերի բեռնարկղերի ներսում միանալու համար.

./gradlew docker-provisioner-ssh

Ցուցադրել կարգավիճակը՝

./gradlew docker-provisioner-status

Տեղակայման առաջադրանքների մասին ավելին կարող եք կարդալ փաստաթղթերում:

Եթե ​​խոսենք թեստերի մասին, ապա դրանք բավականին մեծ են, հիմնականում ծխի և ինտեգրացիայի մասին: Նրանց վերլուծությունը դուրս է այս հոդվածի շրջանակներից: Ասեմ միայն, որ բաշխիչ հավաքածու հավաքելը այնքան էլ բարդ խնդիր չէ, որքան կարող է թվալ առաջին հայացքից: Մեզ հաջողվեց հավաքել և թեստեր հանձնել բոլոր այն բաղադրիչների վրա, որոնք մենք օգտագործում ենք մեր արտադրության մեջ, և մենք նաև խնդիրներ չունեինք դրանք տեղակայելու և փորձարկման միջավայրում հիմնական գործողություններ կատարելու համար:

Բացի Bigtop-ում առկա բաղադրիչներից, հնարավոր է ավելացնել ցանկացած այլ բան, նույնիսկ ձեր սեփական ծրագրային ապահովման մշակումը: Այս ամենը կատարյալ ավտոմատացված է և տեղավորվում է CI/CD հայեցակարգի մեջ:

Ամփոփում

Ակնհայտ է, որ այս ձևով կազմված բաշխումը չպետք է անմիջապես ուղարկվի արտադրություն։ Դուք պետք է հասկանաք, որ եթե ձեր բաշխումը կառուցելու և աջակցելու իրական կարիք կա, ապա դրա մեջ պետք է գումար և ժամանակ ներդնեք:

Սակայն, ճիշտ մոտեցման և պրոֆեսիոնալ թիմի հետ համատեղ, միանգամայն հնարավոր է անել առանց կոմերցիոն լուծումների։

Կարևոր է նշել, որ Bigtop նախագիծն ինքնին զարգացման կարիք ունի և կարծես թե այսօր ակտիվորեն չի մշակվում: Դրանում Hadoop 3-ի հայտնվելու հեռանկարը նույնպես անհասկանալի է: Ի դեպ, եթե դուք իրական կարիք ունեք կառուցելու Hadoop 3, կարող եք նայել. պատառաքաղ Arenadata-ից, որում, բացի ստանդարտից
Կան մի շարք լրացուցիչ բաղադրիչներ (Ranger, Knox, NiFi):

Ինչ վերաբերում է Ռոստելեկոմին, ապա մեզ համար Bigtop-ը այսօր դիտարկվող տարբերակներից մեկն է։ Ընտրենք, թե ոչ, ժամանակը ցույց կտա։

Հավելված

Համագումարում նոր բաղադրիչ ներառելու համար հարկավոր է դրա նկարագրությունը ավելացնել bigtop.bom և ./bigtop-packages-ում: Դուք կարող եք փորձել դա անել գոյություն ունեցող բաղադրիչների անալոգիայի միջոցով: Փորձեք պարզել այն: Դա այնքան էլ դժվար չէ, որքան թվում է առաջին հայացքից:

Ինչ ես կարծում? Մենք ուրախ կլինենք տեսնել ձեր կարծիքը մեկնաբանություններում և շնորհակալություն ուշադրության համար:

Հոդվածը պատրաստվել է Ռոստելեկոմի տվյալների կառավարման թիմի կողմից

Source: www.habr.com