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 core-компоненты 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: 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 — генерация данных, синтетика, для smoke-тестов и т.д.
./bigtop-deploy — инструменты для деплоя
./bigtop-packages — конфиги, скрипты, патчи для сборки, основная часть инструмента
./bigtop-test-framework — фреймворк тестирования
./bigtop-tests — сами тесты, нагрузочные и smoke
./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
./gradlew toolchain-devtools
./gradlew toolchain-puppetmodules

Или непосредственно через 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"

К сожалению, уже на этом этапе могут возникнуть сложности. Общий совет тут – использовать поддерживаемый дистрибутив, в актуальном состоянии на хосте сборки либо пробовать путь с docker.

Сборка

Что же мы можем попробовать собрать? Ответ на этот вопрос даст вывод команды

./gradlew tasks

В разделе Package tasks есть ряд продуктов являющихся конечными артефактами Bigtop.
Их можно определить по суффиксу -rpm или -pkg-ind (в случае сборки
в docker). В нашем случае самым интересным является 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

Эта операция откатит все изменения по сборке данного компонента, после чего сборка выполнится заново. В этот раз попробуем собрать проект в docker-образе:

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

Также можно вспомнить про 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. Можно попробовать сделать это по аналогии с имеющимися компонентами. Попробуйте разобраться. Это не так сложно, как кажется на первый взгляд.

А что думаете вы? Будем рады увидеть ваше мнение в комментариях и спасибо за внимание!

Статья подготовлена командой управления данными «Ростелекома»