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

Вероятно не е тайна, че миналата година беше година на големи промени за Apache Hadoop. Миналата година Cloudera и Hortonworks се сляха (по същество придобиването на последния), а Mapr, поради сериозни финансови проблеми, беше продаден на Hewlett Packard. И ако няколко години по-рано, в случай на локални инсталации, често трябваше да се прави избор между Cloudera и Hortonworks, днес, уви, нямаме този избор. Друга изненада беше фактът, че Cloudera обяви през февруари тази година, че ще спре да пуска двоични сборки от своята дистрибуция в публичното хранилище и те вече са достъпни само чрез платен абонамент. Разбира се, все още е възможно да изтеглите най-новите версии на CDH и HDP, пуснати преди края на 2019 г., и поддръжката за тях се очаква от една до две години. Но какво да правим след това? За тези, които преди това са платили за абонамент, нищо не се е променило. А за тези, които не искат да преминат към платената версия на дистрибуцията, но в същото време искат да могат да получават най-новите версии на компонентите на клъстера, както и корекции и други актуализации, подготвихме тази статия. В него ще разгледаме възможните варианти за излизане от тази ситуация.

Статията е по-скоро обзорна. Няма да сравнява дистрибуции и да ги анализира в детайли и няма да има рецепти за инсталирането и конфигурирането им. Но какво ще стане? Ще говорим накратко за такъв комплект за разпространение като Arenadata Hadoop, който с право заслужава вниманието ни поради наличието си, което днес е рядкост. И тогава ще говорим за Vanilla Hadoop, главно за това как може да бъде „сготвен“ с помощта на Apache Bigtop. Готов? Тогава добре дошли под кат.

Arenadata Hadoop

Това е напълно нов и засега малко известен комплект за разпространение на вътрешното развитие. За съжаление в момента на Хабре има само за него тази статия.

Повече информация можете да намерите на официалния уебсайт проект. Последните версии на дистрибуцията са базирани на Hadoop 3.1.2 за версия 3 и 2.8.5 за версия 2.

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

Интерфейс на мениджъра на клъстер Arenadata

Ключовият продукт на Arenadata е Arenadata Cluster Manager (ADCM), който се използва за инсталиране, конфигуриране и наблюдение на различни софтуерни решения на компанията. ADCM се разпространява безплатно и функционалността му се разширява чрез добавяне на пакети към него, които са набор от ansible-playbooks. Пакетите са разделени на два типа: корпоративни и общностни. Последните са достъпни за безплатно изтегляне от уебсайта на Arenadata. Също така е възможно да разработите свой собствен пакет и да го свържете към ADCM.

За внедряване и управление на Hadoop 3 се предлага общностна версия на пакета във връзка с ADCM, а за hadoop 2 има само Apache Ambari като алтернатива. Що се отнася до хранилищата с пакети, те са отворени за публичен достъп, могат да бъдат изтеглени и инсталирани по обичайния начин за всички компоненти на клъстера. Като цяло разпределението изглежда много интересно. Сигурен съм, че ще има хора, които са свикнали с решения като 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,
и в master беше 1.5. Различните версии на версиите използват различни версии
компоненти. Например за 1.4 Hadoop основните компоненти имат версия 2.8.5 и в master
2.10.0. Списъкът с поддържаните компоненти също се променя. Нещо старо и
невъзобновяемото си отива и на негово място идва нещо ново, по-търсено и
не непременно нещо от самото семейство Apache.

Освен това Bigtop има много вилици.

Когато започнахме да се запознаваме с Bigtop, преди всичко бяхме изненадани от неговата скромност, в сравнение с други проекти на Apache, разпространение и слава, както и много малка общност. От това следва, че има минимум информация за продукта и търсенето на решения на проблеми, възникнали във форуми и пощенски списъци, може да не даде нищо. Първоначално се оказа трудна задача за нас да завършим пълното сглобяване на дистрибуцията поради характеристиките на самия инструмент, но ще говорим за това малко по-късно.

Като тийзър, онези, които веднъж са посетили такива проекти от вселената на Linux като Gentoo и LFS, може да намерят за носталгично приятно да работят с това нещо и да си спомнят онези „епични“ времена, когато ние самите търсихме (или дори пишехме) електронни компилации и редовно възстановявахме 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

Клониране към "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 инструментариум, jenkins
./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 е да инсталирате правилните компоненти на хоста за изграждане. Може да греша в хронологията, но изглежда, че от версия 1.0 има и опция за изграждане в предварително конфигурирани и налични докер изображения, можете да ги намерите тук.

Що се отнася до подготовката на средата, има помощник за това - Puppet.

Можете да използвате следните команди, стартирането се извършва от основната директория
инструмент, ./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.

Нека се опитаме да изградим в нашата сървърна среда за изграждане:

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

Можете също да си спомните за димни тестове и внедряване в докер.

Създайте клъстер от три възела:

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

Що се отнася до Rostelecom, за нас Bigtop е една от опциите, които се разглеждат днес. Дали ще се решим или не, само времето ще покаже.

Апендикс

За да включите нов компонент в сборката, трябва да добавите описанието му към bigtop.bom и ./bigtop-packages. Можете да опитате да направите това по аналогия със съществуващите компоненти. Опитайте се да го разберете. Не е толкова трудно, колкото изглежда на пръв поглед.

Какво мислиш? Ще се радваме да видим вашето мнение в коментарите и ви благодарим за вниманието!

Статията е изготвена от екипа за управление на данни на Ростелеком

Източник: www.habr.com