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 – це один із варіантів, що розглядаються на сьогоднішній день. Зупинимо свій вибір на ньому чи ні – покаже час.

Додаток

Щоб включити новий компонент у складання, потрібно додати його опис у bigtop.bom та ./bigtop-packages. Можна спробувати зробити це за аналогією до наявних компонентів. Спробуйте розібратися. Це не так складно, як здається на перший погляд.

А що ви думаєте? Будемо раді побачити вашу думку в коментарях та дякую за увагу!

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

Джерело: habr.com