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

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

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

Arenadata Hadoop

Това е съвсем нов и, за момента, малко известен дистрибутив от отечествена разработка. За съжаление, в момента в хабра за него има само тази статия.

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

Информация за roadmap може да се намери тук.

Интерфейсът на Arenadata Cluster Manager

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

За деплой и управление на Hadoop 3 се предлага community версия на бандла в комбинация с ADCM, а за hadoop 2 има само Apache Ambari като алтернатива. Що се отнася до хранилищата с пакети, те са отворени за публичен достъп, могат да се изтеглят и инсталират по обичайния начин за всички компоненти на клъстера. В общи линии, дистрибуцията изглежда много интересно. Уверен съм, че ще се намерят хора, които са свикнали с решения като Cloudera Manager и Ambari и които ще оценят самия ADCM. За някои ще бъде огромен плюс и фактът, че дистрибуцията влиза в регистъра на софтуерното за заместване на вноса.

Ако говорим за недостатъците, те ще бъдат същите, както и за всички останали дистрибуции на Hadoop. А именно:

• Така нареченият «vendor lock-in». На примера с Cloudera и Hortonworks вече разбрахме, че винаги съществува риск от промяна на политиката на компанията.
• Съществено изоставане от апстрима на Apache.

Vanilla Hadoop

Както знаете, Hadoop не е монолитен продукт, а всъщност цяла палитра от услуги около неговата разпределена файловата система HDFS. Малко на кого ще му е достатъчен само един файлов клъстер. На едни им трябва Hive, на други Presto, а има и HBase и Phoenix, все по-често се използва Spark. За оркестрация и зареждане на данни понякога се срещат Oozie, Sqoop и Flume. А ако възникне въпросът за осигуряване на безопасност, веднага се сещаме за Kerberos в комбинация с Ranger.

Бинарните версии на компонентите на Hadoop са достъпни на сайта на всеки от проектите в екосистемата под формата на тарболи. Можете да ги изтеглите и да започнете инсталацията, но с едно условие: освен самостоятелно компилиране на пакети от "сурови" бинарници, в което вероятно ще искате да се занимавате, вие няма да имате никаква увереност за съвместимостта между изтеглените версии на компонентите. По-предпочитан вариант е компилацията с помощта на Apache Bigtop. Bigtop ще позволи да се компилират версии от maven хранилищата на Apache, да се изпълнят тестовете и да се съберат пакетите. Но, което е много важно за нас, Bigtop ще събере тези версии на компонентите, които ще бъдат съвместими помежду си. За него ще разкажем по-подробно по-късно.

Apache Bigtop

Apache Bigtop е инструмент за компилиране, пакетиране и тестване на редица
open source проекти, като например 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, може да им се стори носталгично приятно да работят с това и да си спомнят онези "легендарни" времена, когато сами търсихме (а дори и писахме) ебилди и редовно преизграждахме с нови пачове Мозила.

Големият плюс на Bigtop е отвореността и универсалността на инструментите, на които е основан. В основата му стоят Gradle и Apache Maven. Gradle е доста известен инструмент, чрез който Google събира Android. Той е гъвкав и, както се казва, "проверен в действие". Maven е стандартният инструмент за изграждане на проекти в самия Apache, а тъй като повечето от неговите продукти се пускат именно чрез Maven, тук също не може да мина без него. Струва си да обърнем внимание на POM (project object model) – "фундаментален" xml-файл с описание на всичко необходимо за работа с Maven с вашия проект, около който се изгражда цялата работа. Именно в
частта на Maven възникват някои пречки, на които обикновено се натъкват за първи път, когато започват работа с Bigtop.

Практика

И така, откъде да започнем? Преминаваме на страницата за изтегляне и сваляме последната стабилна версия под формата на архив. Там можете да намерите и бинарните артефакти, събрани от Bigtop. Между другото, от популярните пакетни мениджъри се поддържат YUM и APT.

Алтернативно, можете да изтеглите последния стабилен релиз директно от
github:

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

Клонира се в "bigtop"...

remote: Изброяване на обекти: 46, готово.
remote: Броене на обекти: 100% (46/46), готово.
remote: Сжатие на обекти: 100% (41/41), готово.
remote: Общо 40217 (delta 14), повторно използвани 10 (delta 1), повтарящи се 40171
Получаване на обекти: 100% (40217/40217), 43.54 MiB | 1.05 MiB/s, готово.
Определяне на промени: 100% (20503/20503), готово.
Актуализиране на файлове: 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 — изграждане в docker образи, тестване
./gradle — конфигурация на gradle
./output – директория, в която попадат артефакти от изграждането
./provisioner — провижининг

Най-интересното на този етап за нас е основната конфигурация ./bigtop/bigtop.bom, в което виждаме всички поддържани компоненти с версии. Именно тук можем да посочим друга версия на продукта (ако искаме да опитаме да я съберем) или версия на сборката (например, ако сме добавили значителен пач).

Също така голям интерес предизвиква подкаталогът .\/bigtop\/bigtop-packages, което има пряко отношение към процеса на сглобяване на компоненти и пакетите с тях.

И така, изтеглихме архива, разархивирахме го или направихме клон от github, можем ли да започнем сглобяването?

Не, първо трябва да подготвим околната среда.

Подготовка на околната среда

Тук ще направим малко отклонение. За сглобяване на почти всеки по-сложен продукт е необходимо определено обкръжение — в нашия случай това е JDK, същите споделени библиотеки, заглавни файлове и т.н., инструменти като ant, ivy2 и много други. Един от вариантите за полученият необходим за Bigtop сетъп е инсталирането на нужните компоненти на хостинга за сборка. Може да бъркам в хронологията, но изглежда, че от версия 1.0 също е наличен вариант за сглобяване в предварително конфигурирани и налични docker образи, с които можете да се запознаете тук.

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

Можем да използваме следните команди, стартирането се извършва от кореновата директория
на инструмента, .\/bigtop:

.\/gradlew toolchain\n.\/gradlew toolchain-devtools\n.\/gradlew toolchain-puppetmodules

Или директно през puppet:

puppet apply --modulepath= -e "include bigtop_toolchain::installer"\npuppet apply --modulepath= -e "include bigtop_toolchain::deployment-tools"\npuppet apply --modulepath= -e "include bigtop_toolchain::development-tools"

За съжаление, вече на този етап могат да възникнат трудности. Общият съвет е – да се използва поддържан дистрибутив, актуален на хостинга за сборка или да се опита пътят с docker.

Сглобяване

Какво можем да опитаме да сглобим? Отговорът на този въпрос ще даде изходът от командата

.\/gradlew tasks

В раздела Package tasks има редица продукти, които са крайни артефакти на Bigtop.
Можем да ги определим по суфикса -rpm или -pkg-ind (в случай на сглобяване
в docker). В нашия случай най-интересен е Hadoop.

Нека опитаме да изпълним сглобяването в средата на нашия dev-сървър:

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


central
- http:\/\/repo1.maven.org\/maven2
+ https:\/\/repo1.maven.org\/maven2

false

Скорее всего, в момент чтения этой статьи указанное выше исправление вам не придется делать самостоятельно.

При внедрении каких-либо патчей и правок в механизм сборки может понадобиться «сбросить» сборку через команду очистки:

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

Операцията ще откати всички промени в компилацията на този компонент, след което компилацията ще се извърши отново. Този път ще опитаме да компилираме проекта в docker-образ:

.\/gradlew -POS=centos-7 -Pprefix=1.2.1 hadoop-pkg-ind
> Task :hadoop-pkg-ind
Строим 1.2.1 hadoop-pkg на centos-7 в 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
....
много вывода
....
Записано: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-2.8.5-1.el7.x86_64.rpm
Записано: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-hdfs-2.8.5-1.el7.x86_64.rpm
Записано: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-yarn-2.8.5-1.el7.x86_64.rpm
Записано: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-mapreduce-2.8.5-1.el7.x86_64.rpm
Записано: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-hdfs-namenode-2.8.5-1.el7.x86_64.rpm
Записано: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-hdfs-secondarynamenode-2.8.5-
1.el7.x86_64.rpm
Записано: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-hdfs-zkfc-2.8.5-1.el7.x86_64.rpm
Записано: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-hdfs-journalnode-2.8.5-
1.el7.x86_64.rpm
Записано: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-hdfs-datanode-2.8.5-1.el7.x86_64.rpm
Записано: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-httpfs-2.8.5-1.el7.x86_64.rpm
Записано: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-yarn-resourcemanager-2.8.5-
1.el7.x86_64.rpm
Записано: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-yarn-nodemanager-2.8.5-
1.el7.x86_64.rpm
Записано: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-yarn-proxyserver-2.8.5-
1.el7.x86_64.rpm
Записано: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-yarn-timelineserver-2.8.5-
1.el7.x86_64.rpm
Записано: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-mapreduce-historyserver-2.8.5-
1.el7.x86_64.rpm
Записано: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-client-2.8.5-1.el7.x86_64.rpm
Записано: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-conf-pseudo-2.8.5-1.el7.x86_64.rpm
Записано: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-doc-2.8.5-1.el7.x86_64.rpm
Записано: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-libhdfs-2.8.5-1.el7.x86_64.rpm
Записано: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-libhdfs-devel-2.8.5-1.el7.x86_64.rpm
Записано: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-hdfs-fuse-2.8.5-1.el7.x86_64.rpm
Записано: \/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
Изпълнение(%clean): \/bin\/sh -e \/var\/tmp\/rpm-tmp.uQ2FCn
+ exit 0
+ umask 022
Изпълнение(--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] Създаване на \/bigtop\/build\/hadoop\/ .rpm
:hadoop-rpm (Thread[Task worker for ':',5,main]) завършено. Отне 38 мин 1.151 сек.
:hadoop-pkg (Thread[Task worker for ':',5,main]) започнат.
> Task :hadoop-pkg
Task ':hadoop-pkg' не е актуален, защото:
Task не е декларирал изходи, въпреки че е изпълнил действия.
:hadoop-pkg (Thread[Task worker for ':',5,main]) завършено. Отне 0.0 сек.
BUILD УСПЕШЕН за 40м 37с
6 действия: 6 изпълнени
+ 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
Грешка: Няма такъв контейнер:
ac46014fd9501bdc86b6c67d08789fbdc6ee46a2645550ff6b6712f7d02ffebb
BUILD УСПЕШЕН за 41м 24с
1 действия: 1 изпълнена

Сглобяването беше извършено под CentOS, но може да се извърши и под Ubuntu:

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

Освен сглобяването на пакети под различни дистрибуции на Linux, инструментът умеe да формира хранилище с сглобени пакети, например:

.\/gradlew yum

Също така, може да се спомене за smoke тестовете и разгръщането в docker.

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

.\/gradlew -Pnum_instances=3 docker-provisioner

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

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

Изтрийте клъстера:

.\/gradlew docker-provisioner-destroy

Получете командите за свързване вътре в docker контейнерите:

.\/gradlew docker-provisioner-ssh

Показване на състоянието:

.\/gradlew docker-provisioner-status

По-подробно за Deployment tasks може да се чете в документацията.

Ако говорим за тестовете, те са в голямо количество, основно smoke и интеграционни. Анализът им е извън рамките на тази статия. Ще кажа само, че сглобяването на дистрибуцията не е толкова сложна задача, колкото може да изглежда на пръв поглед. Всички компоненти, които използваме в продукцията ни, успяхме да сглобим и да преминем тестове, а също така не срещнахме проблеми с тяхното разгръщане и извършване на основни операции в тестовата среда.

Освен наличните компоненти в Bigtop, има възможност да добавите нещо още, дори собствена софтуерна разработка. Всичко това се автоматизира отлично и се вписва в концепцията CI/CD.

Заключение

Очевидно е, че сглобената по този начин дистрибуция не бива веднага да се изпраща в продукция. Трябва да се разбира, че ако има реална нужда от сглобяване и поддръжка на своя дистрибуция, трябва да се вложат средства и време.

Все пак, в комбинация с правилния подход и професионален екип, е възможно да се мине и без търговски решения.

Важно е да се отбележи, че самият проект Bigtop има нужда от развитие и, изглежда, към момента активна разработка в него не се извършва. Също така не е ясна перспективата за появата на Hadoop 3 в него. Към думите, ако имате реална нужда от сглобяване на Hadoop 3, можете да погледнете на форка от Arenadata, в който освен стандартните
компоненти има и редица допълнителни (Ranger, Knox, NiFi).

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

Appendix

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

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

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

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