Apache Bigtop i wybór dystrybucji Hadoop dzisiaj

Pewnie dla nikogo nie jest tajemnicą, że miniony rok był dla Apache Hadoop rokiem wielkich zmian. W zeszłym roku doszło do połączenia Cloudera i Hortonworks (w zasadzie przejęcia drugiego), a MapR, z powodu poważnych problemów finansowych, został sprzedany Hewlett Packard. Jeszcze kilka lat temu, w przypadku instalacji on-premises, wybór najczęściej sprowadzał się do Cloudera lub Hortonworks, dziś niestety tego wyboru już nie mamy. Zaskoczeniem była także wiadomość, że Cloudera od lutego tego roku ogłosiła zaprzestanie publikowania binarnych wersji swojego dystrybucji w publicznym repozytorium, a teraz są one dostępne tylko za płatną subskrypcją. Oczywiście, możliwość pobrania najnowszych wersji CDH i HDP, wydanych do końca 2019 roku, jeszcze jest, a wsparcie dla nich przewidziano na okres jednego lub dwóch lat. Ale co robić dalej? Dla tych, którzy wcześniej płacili za subskrypcję, nic się nie zmieniło. A dla tych, którzy nie chcą przechodzić na płatną wersję dystrybucji, ale chcą mieć możliwość otrzymywania świeżych wersji komponentów klastra, a także poprawek i innych aktualizacji, przygotowaliśmy ten artykuł. W nim omówimy możliwe opcje wyjścia z zaistniałej sytuacji.

Artykuł ma charakter wprowadzający. Nie będzie w nim porównania dystrybucji ani szczegółowej analizy, ani przepisów na ich instalację i konfigurację. A co więc będzie? W skrócie opowiemy o dystrybucji o nazwie Arenadata Hadoop, która z pewnością zasługuje na naszą uwagę ze względu na swoją dostępność, co jest dzisiaj rzadkością. Następnie porozmawiamy o Vanilla Hadoop, głównie o tym, jak można go 'przygotować' za pomocą Apache Bigtop. Gotowi? To zapraszamy pod kat.

Arenadata Hadoop

To całkowicie nowa i, jak dotąd, mało znana dystrybucja rodzimego rozwoju. Niestety, w chwili obecnej na Hubie można znaleźć o niej tylko artykuł.

Szczegółowe informacje można znaleźć na oficjalnym stronie projekcie. Ostatnie wersje dystrybucji opierają się na Hadoop 3.1.2 dla wersji 3 oraz 2.8.5 dla wersji 2.

Informacje o roadmapie można znaleźć tutaj.

Interfejs Arenadata Cluster Manager

Kluczowym produktem Arenadata jest Arenadata Cluster Manager (ADCM), który jest używany do instalacji, konfiguracji i monitorowania różnych rozwiązań programowych firmy. ADCM jest rozpowszechniany bezpłatnie, a jego funkcjonalność rozszerza się poprzez dodawanie zestawów, które stanowią zbiór ansible-playbooków. Zestawy dzielą się na dwa rodzaje: enterprise i community. Te drugie są dostępne do bezpłatnego pobrania ze strony Arenadata. Istnieje także możliwość opracowania własnego zestawu i podłączenia go do ADCM.

Do wdrożenia i zarządzania Hadoop 3 oferowana jest wersja community zestawu w połączeniu z ADCM, a dla Hadoop 2 dostępna jest tylko Apache Ambari jako alternatywa. Jeśli chodzi o repozytoria z pakietami, są one otwarte dla publicznego dostępu, można je pobrać i zainstalować w tradycyjny sposób dla wszystkich komponentów klastra. Ogólnie rzecz biorąc, dystrybucja wygląda bardzo interesująco. Jestem pewien, że znajdą się tacy, którzy przywykli do takich rozwiązań jak Cloudera Manager i Ambari, i którzy docenią sam ADCM. Dla niektórych ogromnym plusem będzie również fakt, że dystrybucja jest wpisana do rejestru oprogramowania dla importu zamienników.

Jeśli chodzi o wady, będą one takie same jak dla wszystkich innych dystrybucji Hadoop. A mianowicie:

• Tak zwany «vendor lock-in». Na przykładzie Cloudera i Hortonworks już zrozumieliśmy, że zawsze istnieje ryzyko zmiany polityki firmy.
• Znaczne opóźnienie w stosunku do apstrima Apache.

Vanilla Hadoop

Jak wiecie, Hadoop to nie monolityczny produkt, a właściwie cała gama usług wokół jego rozproszonego systemu plików HDFS. Niewielu osobom wystarczy tylko jeden klaster plików. Niektórzy potrzebują Hive, inni Presto, są jeszcze HBase i Phoenix, coraz częściej używa się Sparka. Do orkiestracji i załadunku danych czasami stosuje się Oozie, Sqoop i Flume. A gdy pojawia się pytanie o zapewnienie bezpieczeństwa, to natychmiast przypomina się o Kerberosie w połączeniu z Rangerem.

Binarnie wersje komponentów Hadoop są dostępne na stronie każdego z projektów ekosystemu w postaci tarballi. Można je pobrać i rozpocząć instalację, ale z jednym zastrzeżeniem: oprócz samodzielnej budowy pakietów z „surowych” binariów, co prawdopodobnie będziesz chciał zrobić, nie będziesz mieć żadnej pewności co do kompatybilności pobranych wersji komponentów między sobą. Bardziej preferowanym rozwiązaniem jest budowa za pomocą Apache Bigtop. Bigtop pozwoli na wykonanie budowy z maven-repozytoriów Apache, przeprowadzenie testów i zebranie pakietów. Ale, co jest dla nas bardzo ważne, Bigtop zbierze te wersje komponentów, które będą ze sobą kompatybilne. O nim opowiemy bardziej szczegółowo później.

Apache Bigtop

Apache Bigtop to narzędzie do budowy, pakowania i testowania szeregu
projektów open source, takich jak Hadoop i Greenplum. Bigtop ma wiele
wydania. W momencie pisania artykułu ostatnie stabilne wydanie to wersja 1.4,
a w gałęzi master znajdowała się wersja 1.5. W różnych wersjach wydań używane są różne wersje
komponentów. Na przykład, dla wersji 1.4 core-komponenty Hadoop mają wersję 2.8.5, a w gałęzi master
2.10.0. Zmienia się również skład wspieranych komponentów. Coś przestarzałego i
niewspieranego znika, a na jego miejsce pojawia się coś nowego, bardziej pożądanego, i
niekoniecznie musi to być coś z rodziny samego Apache.

Dodatkowo, Bigtop ma wiele forków.

Kiedy zaczęliśmy poznawać Bigtop, przede wszystkim zdziwiła nas jego skromna, w porównaniu do innych projektów Apache, obecność i rozpoznawalność, a także bardzo mała społeczność. Z tego wynika, że informacji na temat produktu jest minimum, a wyszukiwanie rozwiązań pojawiających się problemów na forach i listach dyskusyjnych może w ogóle nie przynieść rezultatów. Na początku okazało się dla nas trudnym zadaniem przeprowadzenie pełnej budowy dystrybucji ze względu na specyfikę samego narzędzia, ale o tym opowiemy trochę później.

Jako zapowiedź — tym, którzy kiedyś korzystali z takich projektów w świecie Linuksa, jak Gentoo i LFS, może się wydawać nostalgicznie miło znów pracować z tym narzędziem i przypomnieć sobie te «epickie» czasy, kiedy sami szukaliśmy (a nawet pisaliśmy) ebuildy i regularnie rekonstruowaliśmy z nowymi łatkami Mozillę.

Dużym plusem Bigtop jest otwartość i wszechstronność narzędzi, na których jest oparty. Jego fundamentem są Gradle i Apache Maven. Gradle jest dość dobrze znanym narzędziem, którego Google używa do kompilacji Androida. Jest elastyczny i, jak to się mówi, „sprawdzony w boju”. Maven to natywny instrument do budowania projektów w Apache, i ponieważ większość jego produktów jest wydawana właśnie przez Maven, tutaj również nie mogło się bez niego obejść. Warto zwrócić uwagę na POM (model obiektów projektu) – „fundamentalny” plik xml opisujący wszystko, co potrzebne do pracy Mavena z Twoim projektem, wokół którego opiera się cała praca. To właśnie w
części Mavena pojawiają się pewne przeszkody, na które zazwyczaj natrafiają osoby, które pierwszy raz zabierają się za Bigtop.

Praktyka

Więc od czego zacząć? Przechodzimy na stronę pobierania i ściągamy najnowszą stabilną wersję w formie archiwum. Tam można znaleźć również artefakty binarne zbudowane przez Bigtop. A tak przy okazji, z popularnych menedżerów pakietów wspierane są YUM i APT.

Alternatywnym sposobem jest pobranie najnowszego stabilnego wydania bezpośrednio z
github:

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

Klonowanie do „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
Otrzymanie obiektów: 100% (40217/40217), 43.54 MiB | 1.05 MiB/s, gotowe.
Określenie zmian: 100% (20503/20503), gotowe.
Aktualizacja plików: 100% (1998/1998), gotowe.

Powstały katalog ./bigtop wygląda mniej więcej tak:

./bigtop-bigpetstore — aplikacje demonstracyjne, sztuczne przykłady
./bigtop-ci — narzędzia CI, Jenkins
./bigtop-data-generators — generowanie danych, sztuczne dane dla testów smoke itp.
./bigtop-deploy — narzędzia do wdrażania
./bigtop-packages — konfiguracje, skrypty, łatki do budowy, główna część narzędzia
./bigtop-test-framework — framework testowy
./bigtop-tests — same testy, obciążeniowe i smoke
./bigtop_toolchain — środowisko do budowy, przygotowanie środowiska do pracy narzędzia
./build — roboczy katalog budowy
./dl — katalog dla pobranych źródeł
./docker — budowa w obrazach dockera, testowanie
./gradle — konfiguracja gradle
./output – katalog, do którego trafiają artefakty budowy
./provisioner — provisioning

Najciekawszym na tym etapie dla nas jest główny config ./bigtop/bigtop.bom, w którym widzimy wszystkie wspierane komponenty wraz z ich wersjami. Tutaj możemy wskazać inną wersję produktu (jeśli chcemy ją przetestować) lub wersję budowy (na przykład, jeśli dodaliśmy znaczącą poprawkę).

Interesujący jest również podkatalog . /bigtop/bigtop-packages, który ma bezpośredni związek z procesem budowania komponentów i pakietów z nimi.

Czyli pobraliśmy archiwum, rozpakowaliśmy je lub zrobiliśmy klon z github, możemy zaczynać budowę?

Nie, najpierw przygotujemy środowisko.

Przygotowanie środowiska

I tutaj potrzebne będzie małe dygresja. Do budowy prawie każdego bardziej lub mniej skomplikowanego produktu potrzebne jest określone środowisko - w naszym przypadku jest to JDK, te same biblioteki współdzielone, pliki nagłówkowe itp., narzędzia, na przykład, ant, ivy2 i wiele innych. Jednym z sposobów uzyskania odpowiedniego dla Bigtop środowiska jest zainstalowanie potrzebnych komponentów na hoście budowy. Mogę się mylić co do chronologii, ale wydaje mi się, że od wersji 1.0 pojawiła się również opcja budowy w wstępnie skonfigurowanych i dostępnych obrazach docker, które można znaleźć tutaj.

Jeśli chodzi o przygotowanie środowiska, to mamy pomocnika - Puppet.

Można skorzystać z następujących poleceń, uruchomienie odbywa się z głównego katalogu
narzędzia, . /bigtop:

. /gradlew toolchain
. /gradlew toolchain-devtools
. /gradlew toolchain-puppetmodules

Lub bezpośrednio przez puppet:

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

Niestety, już na tym etapie mogą pojawić się trudności. Ogólna rada - używać wspieranego dystrybucji, będącego w aktualnym stanie na hoście budowy lub próbować drogi z docker.

Kompilacja

Co takiego możemy spróbować zbudować? Odpowiedź na to pytanie da wynik polecenia

. /gradlew tasks

W sekcji Package tasks znajduje się szereg produktów będących końcowymi artefaktami Bigtop.
Można je zidentyfikować po sufiksie -rpm lub -pkg-ind (w przypadku budowy
w docker). W naszym przypadku najciekawszym jest Hadoop.

Spróbujmy wykonać budowę w środowisku naszego serwera budującego:

. /gradlew hadoop-rpm

Bigtop sam pobierze potrzebne źródła, potrzebne do konkretnego komponentu, i zacznie budowę. W ten sposób praca narzędzia jest związana z repozytoriami Maven i innymi źródłami, co oznacza, że potrzebuje dostępu do Internetu.

W trakcie pracy generowany jest standardowy wynik. Czasami na jego podstawie oraz na podstawie komunikatów o błędach można zrozumieć, co poszło nie tak. Czasami jednak potrzebne są dodatkowe informacje. W takim przypadku warto dodać argumenty --info lub --debug, a także może być pomocne –stacktrace. Istnieje wygodny sposób na utworzenie zestawu danych do późniejszych zgłoszeń na listach mailingowych, klucz --scan.

Dzięki niemu bigtop zbierze wszystkie informacje i zapisze w gradle, a następnie wygeneruje link,
po kliknięciu którego kompetentna osoba będzie mogła zrozumieć, dlaczego budowa się nie powiodła.
Należy pamiętać, że ta opcja może ujawnić niepożądane dla Ciebie informacje, na przykład nazwy użytkowników, węzłów, zmienne środowiskowe itd., więc bądź ostrożny.

Często błędy są wynikiem niezdolności do uzyskania niektórych niezbędnych komponentów do budowy. Zazwyczaj można rozwiązać problem poprzez stworzenie łatki do poprawienia czegoś w źródłach, na przykład adresu w pom.xml w głównym katalogu źródeł. Robi się to przez stworzenie i umieszczenie jej w odpowiednim katalogu .\/bigtop\/bigtop-packages\/src\/common\/oozie\/ łatki, na przykład w postaci 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

Najprawdopodobniej w momencie czytania tego artykułu, podana powyżej poprawka nie będzie wymagana do samoistnego wykonania.

Wprowadzając jakiekolwiek łatki i poprawki w mechanizmie budowy, może być konieczne "resetowanie" budowy za pomocą polecenia czyszczenia:

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

Operacja ta cofnie wszystkie zmiany w budowie tego komponentu, po czym budowa zostanie powtórzona. Tym razem spróbujemy zbudować projekt w obrazie docker:

.\/gradlew -POS=centos-7 -Pprefix=1.2.1 hadoop-pkg-ind
> Zadań :hadoop-pkg-ind
Budowanie 1.2.1 hadoop-pkg na centos-7 w Dockerze...
+++ 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
....
mnóstwo wyjścia
....
Zapisano: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-2.8.5-1.el7.x86_64.rpm
Zapisano: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-hdfs-2.8.5-1.el7.x86_64.rpm
Zapisano: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-yarn-2.8.5-1.el7.x86_64.rpm
Zapisano: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-mapreduce-2.8.5-1.el7.x86_64.rpm
Zapisano: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-hdfs-namenode-2.8.5-1.el7.x86_64.rpm
Zapisano: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-hdfs-secondarynamenode-2.8.5-
1.el7.x86_64.rpm
Zapisano: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-hdfs-zkfc-2.8.5-1.el7.x86_64.rpm
Zapisano: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-hdfs-journalnode-2.8.5-
1.el7.x86_64.rpm
Zapisano: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-hdfs-datanode-2.8.5-1.el7.x86_64.rpm
Zapisano: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-httpfs-2.8.5-1.el7.x86_64.rpm
Zapisano: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-yarn-resourcemanager-2.8.5-
1.el7.x86_64.rpm
Zapisano: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-yarn-nodemanager-2.8.5-
1.el7.x86_64.rpm
Zapisano: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-yarn-proxyserver-2.8.5-
1.el7.x86_64.rpm
Zapisano: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-yarn-timelineserver-2.8.5-
1.el7.x86_64.rpm
Zapisano: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-mapreduce-historyserver-2.8.5-
1.el7.x86_64.rpm
Zapisano: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-client-2.8.5-1.el7.x86_64.rpm
Zapisano: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-conf-pseudo-2.8.5-1.el7.x86_64.rpm
Zapisano: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-doc-2.8.5-1.el7.x86_64.rpm
Zapisano: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-libhdfs-2.8.5-1.el7.x86_64.rpm
Zapisano: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-libhdfs-devel-2.8.5-1.el7.x86_64.rpm
Zapisano: \/bigtop\/build\/hadoop\/rpm\/RPMS\/x86_64\/hadoop-hdfs-fuse-2.8.5-1.el7.x86_64.rpm
Zapisano: \/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
Wykonanie(%clean): \/bin\/sh -e \/var\/tmp\/rpm-tmp.uQ2FCn
+ exit 0
+ umask 022
Wykonanie(--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] Tworzenie \/bigtop\/build\/hadoop\/ .rpm
:hadoop-rpm (Thread[Zadanie pracownika dla ':',5,główne]) zakończone. Zajęło 38 minut 1.151 sek.
:hadoop-pkg (Thread[Zadanie pracownika dla ':',5,główne]) rozpoczęte.
> Zadań :hadoop-pkg
Zadanie ':hadoop-pkg' nie jest aktualne, ponieważ:
Zadanie nie zadeklarowało żadnych wyników pomimo wykonania działań.
:hadoop-pkg (Thread[Zadanie pracownika dla ':',5,główne]) zakończone. Zajęło 0.0 sek.
BUDOWA UDANA w 40m 37s
6 działań do zrealizowania: 6 zrealizowano
+ 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
Błąd: Brak takiego kontenera:
ac46014fd9501bdc86b6c67d08789fbdc6ee46a2645550ff6b6712f7d02ffebb
BUDOWA UDANA w 41m 24s
1 zadanie do zrealizowania: 1 zrealizowano

Zbudowano pod CentOS, ale można również wykonać pod Ubuntu:

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

Oprócz budowy pakietów dla różnych dystrybucji Linuxa, narzędzie potrafi tworzyć repozytorium z zbudowanymi pakietami, na przykład:

.\/gradlew yum

Można również wspomnieć o testach smoke i wdrażaniu w docker.

Utwórz klaster składający się z trzech węzłów:

.\/gradlew -Pnum_instances=3 docker-provisioner

Uruchom testy smoke w klastrze składającym się z trzech węzłów:

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

Usuń klaster:

.\/gradlew docker-provisioner-destroy

Pobierz polecenia do łączenia się z wewnątrz kontenerów docker:

.\/gradlew docker-provisioner-ssh

Pokaż stan:

.\/gradlew docker-provisioner-status

Więcej informacji na temat zadań wdrożeniowych można znaleźć w dokumentacji.

Jeśli chodzi o testy, jest ich dość dużo, głównie testy smoke i integracyjne. Ich omówienie przekracza zakres tego artykułu. Powiem tylko, że budowa dystrybucji nie jest tak skomplikowanym zadaniem, jak może się wydawać na pierwszy rzut oka. Wszystkie komponenty, których używamy w produkcji, udało nam się zbudować i przejść przez nie testy, a także nie napotkaliśmy problemów z ich wdrożeniem i wykonywaniem podstawowych operacji w środowisku testowym.

Oprócz istniejących komponentów w Bigtop, istnieje możliwość dodania czegokolwiek innego, nawet własnego oprogramowania. Wszystko to jest doskonale automatyzowane i wpisuje się w koncepcję CI/CD.

Podsumowanie

Oczywiście, że zbudowany w ten sposób dystrybucja nie powinna być od razu wysyłana do produkcji. Należy zrozumieć, że jeśli istnieje rzeczywista potrzeba budowy i wsparcia własnej dystrybucji, to trzeba w to inwestować finansowo i czasowo.

Jednak w połączeniu z odpowiednim podejściem i profesjonalnym zespołem można poradzić sobie również bez komercyjnych rozwiązań.

Warto zaznaczyć, że sam projekt Bigtop wymaga rozwoju i, jak się wydaje, na dziś nie prowadzi się w nim aktywnego rozwoju. Nie jest również jasna perspektywa pojawienia się w nim Hadoop 3. Swoją drogą, jeśli masz rzeczywistą potrzebę budowy Hadoop 3, możesz spojrzeć na forka od Arenadata, w którym oprócz standardowych
komponentów znajduje się również cały szereg dodatkowych (Ranger, Knox, NiFi).

Jeśli chodzi o Rostelekom, to dla nas Bigtop to jedna z rozważanych opcji na dziś. To, czy wybierzemy go, czy nie, pokaże czas.

Aneks

Aby włączyć nowy komponent do budowy, należy dodać jego opis do bigtop.bom i ./bigtop-packages. Można spróbować zrobić to na podstawie istniejących komponentów. Spróbuj to zrozumieć. To nie jest tak trudne, jak się wydaje na pierwszy rzut oka.

A co o tym myślisz? Z przyjemnością zobaczymy Twoją opinię w komentarzach i dziękujemy za uwagę!

Artykuł przygotowany przez zespół zarządzania danymi „Rosnieft”

Źródło: habr.com