Apache Bigtop и избор на Hadoop дистрибуција денес

Веројатно не е тајна дека минатата година беше година на големи промени за Apache Hadoop. Минатата година, Cloudera и Hortonworks се споија (во суштина, купувањето на вториот), а Mapr, поради сериозни финансиски проблеми, беше продаден на Hewlett Packard. И ако неколку години порано, во случај на инсталации во просториите, изборот често мораше да се направи помеѓу Cloudera и Hortonworks, денес, за жал, го немаме овој избор. Друго изненадување беше фактот што Cloudera објави во февруари оваа година дека ќе престане да објавува бинарни склопови од неговата дистрибуција во јавното складиште, а тие сега се достапни само преку платена претплата. Се разбира, сè уште е можно да се преземат најновите верзии на CDH и HDP објавени пред крајот на 2019 година, а поддршката за нив се очекува од една до две години. Но, што да се прави следно? За оние кои претходно платиле за претплата, ништо не се променило. И за оние кои не сакаат да се префрлат на платената верзија на дистрибуцијата, но во исто време сакаат да можат да ги добиваат најновите верзии на компоненти на кластерот, како и закрпи и други ажурирања, го подготвивме овој напис. Во него ќе ги разгледаме можните опции за излез од оваа ситуација.

Написот е повеќе од преглед. Нема да содржи споредба на дистрибуции и нивна детална анализа и нема да има рецепти за нивно инсталирање и конфигурирање. Што ќе се случи? Накратко ќе зборуваме за таква дистрибуција како Arenadata Hadoop, која со право го заслужува нашето внимание поради неговата достапност, што е многу ретко денес. И тогаш ќе зборуваме за Vanilla Hadoop, главно за тоа како може да се „готви“ со помош на Apache Bigtop. Подготвени? Потоа добредојде во мачка.

Аренаподатоци Хадуп

Ова е сосема нов и досега малку познат комплет за дистрибуција на домашниот развој. За жал, во моментов на Хабре има само Оваа статија.

Повеќе информации можете да најдете на официјалната Онлајн проект. Најновите верзии на дистрибуцијата се базирани на Hadoop 3.1.2 за верзија 3 и 2.8.5 за верзија 2.

Може да се најдат информации за патоказот тука.

Интерфејс за менаџер на кластерот Аренадата

Основниот производ на Arenadata е Менаџер на кластерот Аренадата (ADCM), кој се користи за инсталирање, конфигурирање и следење на различни софтверски решенија на компанијата. ADCM се дистрибуира бесплатно, а неговата функционалност се проширува со додавање на пакети, кои се збир од ansible-playbooks. Пакетите се поделени на два вида: претпријатие и заедница. Последните се достапни за бесплатно преземање од веб-страницата на Аренадата. Исто така, можно е да развиете сопствен пакет и да го поврзете со ADCM.

За распоредување и управување со Hadoop 3, верзијата на заедницата на пакетот се нуди заедно со ADCM, но за Hadoop 2 постои само Апачи Амбари како алтернатива. Што се однесува до складиштата со пакети, тие се отворени за јавен пристап, може да се преземат и инсталираат на вообичаен начин за сите компоненти на кластерот. Генерално, дистрибуцијата изгледа многу интересно. Сигурен сум дека ќе има такви кои се навикнати на решенија како што се Cloudera Manager и Ambari, и на кои ќе им се допадне самиот ADCM. За некои, исто така, ќе биде огромен плус што дистрибуцијата вклучени во софтверскиот регистар за замена на увозот.

Ако зборуваме за недостатоците, тие ќе бидат исти како и за сите други дистрибуции на Hadoop. Имено:

• Таканареченото „заклучување на продавачот“. Користејќи ги примерите на Cloudera и Hortonworks, веќе сфативме дека секогаш постои ризик од промена на политиката на компанијата.
• Значително заостанување зад Апачи возводно.

Ванила Хадуп

Како што знаете, Hadoop не е монолитен производ, туку, всушност, цела галаксија на услуги околу неговиот дистрибуиран датотечен систем HDFS. Малку луѓе ќе имаат доволно од еден кластер на датотеки. На некои им треба Hive, на други Presto, а потоа се HBase и Phoenix; Spark се повеќе се користи. За оркестрација и вчитување податоци, понекогаш се наоѓаат Oozie, Sqoop и Flume. И ако се појави прашањето за безбедноста, тогаш Керберос во врска со Ренџер веднаш доаѓа на ум.

Бинарни верзии на 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, распространетоста и популарноста, како и многу малата заедница. Од ова произлегува дека има минимални информации за производот, а барањето решенија за проблемите што се појавиле на форумите и листите за испраќање можеби нема да донесе ништо. Отпрвин, се покажа како тешка задача за нас да го завршиме целосното склопување на дистрибуцијата поради карактеристиките на самата алатка, но за ова ќе разговараме малку подоцна.

Како најава, на оние кои своевремено беа заинтересирани за проекти од универзумот Линукс како што се Gentoo и LFS може да им биде носталгично пријатно да работат со оваа работа и да се сетат на оние „епски“ времиња кога ние самите баравме (или дури и пишувавме) ebuilds и редовно ја обновува Mozilla со нови закрпи.

Големата предност на 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

Клонирање во „големиот топ“…

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, истите споделени библиотеки, датотеки со заглавија итн., Алатки, на пример, мравка, ivy2 и многу повеќе. Една од опциите за да ја добиете околината што ви треба за Bigtop е да ги инсталирате потребните компоненти на build-домаќинот. Може да грешам во хронологијата, но се чини дека со верзијата 1.0 имаше и опција за вградување на претходно конфигурирани и достапни слики на Docker, кои може да се најдат овде.

Што се однесува до подготовката на околината, за ова има асистент - Кукла.

Можете да ги користите следните команди, стартувајте од root директориумот
инструмент, ./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"

За жал, веќе во оваа фаза може да се појават тешкотии. Општиот совет овде е да користите поддржана дистрибуција, ажурирана на build-домаќинот или да ја испробате маршрутата на докер.

Собрание

Што можеме да се обидеме да собереме? Одговорот на ова прашање ќе го даде излезот од командата

./gradlew tasks

Во делот Пакет задачи има голем број производи кои се финални артефакти на Bigtop.
Тие можат да се идентификуваат со наставката -rpm или -pkg-ind (во случај на градење
во докер). Во нашиот случај, најинтересен е Hadoop.

Ајде да се обидеме да изградиме во околината на нашиот сервер за изградба:

./gradlew hadoop-rpm

Самиот Bigtop ќе ги преземе потребните извори потребни за одредена компонента и ќе започне со склопување. Така, работата на алатката зависи од складиштата на Maven и други извори, односно бара пристап до Интернет.

За време на работата, се генерира стандарден излез. Понекогаш тоа и пораките за грешка можат да ви помогнат да разберете што тргнало наопаку. И понекогаш треба да добиете дополнителни информации. Во овој случај вреди да се додадат аргументи --info или --debug, а исто така може да биде корисно –stacktrace. Постои пригоден начин да се генерира збир на податоци за последователен пристап до листите за пошта, клучот --scan.

Со негова помош, bigtop ќе ги собере сите информации и ќе ги стави во gradle, по што ќе обезбеди линк,
следејќи го тоа, компетентно лице ќе може да разбере зошто собранието пропаднало.
Имајте предвид дека оваа опција може да открие информации што не ги сакате, како што се кориснички имиња, јазли, променливи на околината итн., затоа бидете внимателни.

Честопати грешките се последица на неможноста да се добијат сите компоненти неопходни за склопување. Вообичаено, можете да го решите проблемот со создавање на закрпа за да поправите нешто во изворите, на пример, адресите во pom.xml во root директориумот на изворите. Ова се прави со креирање и ставање во соодветниот директориум ./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, можете да погледнете вилушка од Аренадата, во која покрај стандардните
Постојат голем број дополнителни компоненти (Ranger, Knox, NiFi).

Што се однесува до Ростелеком, за нас Bigtop е една од опциите што се разгледуваат денес. Дали ќе го избереме или не, времето ќе покаже.

Додаток

За да вклучите нова компонента во склопот, треба да го додадете нејзиниот опис на bigtop.bom и ./bigtop-packages. Може да се обидете да го направите ова по аналогија со постоечките компоненти. Обидете се да го сфатите. Не е толку тешко како што изгледа на прв поглед.

Што мислиш? Ќе ни биде мило да го видиме вашето мислење во коментарите и да ви благодариме за вниманието!

Написот е подготвен од тимот за управување со податоци на Ростелеком

Извор: www.habr.com