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