Nie jest chyba tajemnicą, że ubiegły rok był rokiem dużych zmian dla Apache Hadoop. W ubiegłym roku doszło do fuzji Cloudera i Hortonworks (w zasadzie przejęcie tego ostatniego), a Mapr ze względu na poważne problemy finansowe zostało sprzedane firmie Hewlett Packard. I o ile kilka lat wcześniej w przypadku instalacji on-premise często trzeba było dokonywać wyboru pomiędzy Clouderą a Hortonworks, dziś niestety nie mamy takiego wyboru. Kolejną niespodzianką był fakt, że Cloudera ogłosiła w lutym tego roku, że zaprzestanie wypuszczania do publicznego repozytorium binarnych zestawów swojej dystrybucji, które obecnie są dostępne wyłącznie w ramach płatnej subskrypcji. Oczywiście w dalszym ciągu możliwe jest pobranie najnowszych wersji CDH i HDP wydanych przed końcem 2019 roku, a wsparcie dla nich przewidywane jest przez rok do dwóch lat. Ale co dalej? Dla tych, którzy wcześniej zapłacili za abonament, nic się nie zmieniło. A dla tych, którzy nie chcą przechodzić na płatną wersję dystrybucji, ale jednocześnie chcą mieć możliwość otrzymywania najnowszych wersji komponentów klastra, a także łatek i innych aktualizacji, przygotowaliśmy ten artykuł. Rozważymy w nim możliwe opcje wyjścia z tej sytuacji.
Artykuł ma raczej charakter recenzji. Nie będzie w nim porównania dystrybucji i ich szczegółowej analizy, nie będzie też przepisów na ich instalację i konfigurację. Co się stanie? Pokrótce porozmawiamy o takiej dystrybucji jak Arenadata Hadoop, która słusznie zasługuje na naszą uwagę ze względu na jej dostępność, która jest dziś bardzo rzadka. A potem porozmawiamy o Vanilla Hadoop, głównie o tym, jak można ją „ugotować” za pomocą Apache Bigtop. Gotowy? Zatem witaj w kocie.
Arenadata Hadoop
To zupełnie nowy i jeszcze mało znany zestaw dystrybucyjny krajowego rozwoju. Niestety w tej chwili na Habré jest tylko .
Więcej informacji można znaleźć na oficjalnej stronie projekt. Najnowsze wersje dystrybucji bazują na Hadoop 3.1.2 dla wersji 3 i 2.8.5 dla wersji 2.
Można znaleźć informacje na temat planu działania .
Interfejs menedżera klastrów Arenadata
Podstawowym produktem Arenadata jest , który służy do instalowania, konfigurowania i monitorowania różnych rozwiązań oprogramowania firmy. ADCM jest dystrybuowany bezpłatnie, a jego funkcjonalność jest rozszerzana poprzez dodanie pakietów, które stanowią zestaw podręczników ansible. Pakiety dzielą się na dwa typy: korporacyjne i społecznościowe. Te ostatnie można pobrać bezpłatnie ze strony Arenadata. Istnieje także możliwość opracowania własnego pakietu i podłączenia go do ADCM.
Do wdrażania i zarządzania Hadoop 3 oferowana jest społeczność pakietu w połączeniu z ADCM, ale w przypadku Hadoop 2 dostępna jest tylko jako alternatywa. Jeśli chodzi o repozytoria z pakietami, są one ogólnodostępne, można je pobrać i zainstalować w zwykły sposób dla wszystkich komponentów klastra. Ogólnie dystrybucja wygląda bardzo interesująco. Jestem pewien, że znajdą się tacy, którzy są przyzwyczajeni do rozwiązań takich jak Cloudera Manager i Ambari, a którym samo ADCM przypadnie do gustu. Dla niektórych ogromnym plusem będzie także dystrybucja w celu zastąpienia importu.
Jeśli mówimy o wadach, będą one takie same, jak w przypadku wszystkich innych dystrybucji Hadoopa. Mianowicie:
- Tak zwana „blokada sprzedawcy”. Korzystając z przykładów Cloudera i Hortonworks, zdaliśmy sobie już sprawę, że zawsze istnieje ryzyko zmiany polityki firmy.
- Znaczące opóźnienie w stosunku do Apache upstream.
Waniliowy Hadoop
Jak wiadomo, Hadoop nie jest produktem monolitycznym, ale tak naprawdę całą galaktyką usług wokół rozproszonego systemu plików HDFS. Niewiele osób będzie miało dość jednego klastra plików. Niektórzy potrzebują Hive, inni Presto, a potem HBase i Phoenix; Coraz częściej używany jest Spark. Do orkiestracji i ładowania danych czasami można znaleźć Oozie, Sqoop i Flume. A jeśli pojawia się kwestia bezpieczeństwa, od razu przychodzi na myśl Kerberos w połączeniu z Rangerem.
Wersje binarne komponentów Hadoop dostępne są na stronie każdego z projektów ekosystemowych w formie tarballi. Możesz je pobrać i rozpocząć instalację, ale pod jednym warunkiem: oprócz samodzielnego składania pakietów z „surowych” plików binarnych, co najprawdopodobniej będziesz chciał zrobić, nie będziesz miał żadnej pewności co do kompatybilności pobranych wersji komponentów z każdą Inny. Preferowaną opcją jest budowanie przy użyciu Apache Bigtop. Bigtop pozwoli Ci budować z repozytoriów Apache Maven, uruchamiać testy i budować pakiety. Ale co dla nas bardzo ważne, Bigtop zmontuje takie wersje podzespołów, które będą ze sobą kompatybilne. Porozmawiamy o tym bardziej szczegółowo poniżej.
Apache Bigtop
Apache Bigtop to narzędzie do budowania, pakowania i testowania wielu
projekty open source, takie jak Hadoop i Greenplum. Bigtop ma mnóstwo
wydania. W chwili pisania tego tekstu najnowszą stabilną wersją była wersja 1.4,
a u mastera było 1.5. Różne wersje wydań korzystają z różnych wersji
składniki. Na przykład dla wersji 1.4 podstawowe komponenty Hadoopa mają wersję 2.8.5 i wersję master
2.10.0. Zmienia się także skład obsługiwanych komponentów. Coś przestarzałego i
to, co nieodnawialne, odchodzi, a na jego miejsce pojawia się coś nowego, bardziej poszukiwanego, i
niekoniecznie jest to coś z samej rodziny Apache.
Ponadto Bigtop ma wiele .
Kiedy zaczęliśmy poznawać Bigtop, zaskoczył nas przede wszystkim jego skromność w porównaniu z innymi projektami Apache, powszechność i popularność, a także bardzo mała społeczność. Wynika z tego, że informacji o produkcie jest minimalnie, a szukanie rozwiązań problemów, które pojawiły się na forach i listach mailingowych, może nic nie dać. Na początku ukończenie pełnego montażu dystrybucji okazało się dla nas trudnym zadaniem ze względu na cechy samego narzędzia, ale o tym porozmawiamy nieco później.
Tytułem zwiastuna, ci, którzy kiedyś interesowali się takimi projektami z uniwersum Linuksa, jak Gentoo i LFS, mogą uznać pracę z tą rzeczą za nostalgicznie przyjemną i przypomnieć sobie te „epickie” czasy, kiedy sami szukaliśmy (lub nawet pisaliśmy) ebuildy i regularnie przebudowywana Mozilla z nowymi łatkami.
Dużą zaletą Bigtop jest otwartość i wszechstronność narzędzi, na których jest oparty. Opiera się na Gradle i Apache Maven. Gradle jest dość dobrze znanym narzędziem, którego Google używa do tworzenia Androida. Jest elastyczny i, jak to mówią, „przetestowany w boju”. Maven jest standardowym narzędziem do budowania projektów w samym Apache, a ponieważ większość jego produktów jest wydawana za pośrednictwem Mavena, tutaj również nie można by się bez niego obejść. Warto zwrócić uwagę na POM (project object model) – „podstawowy” plik xml opisujący wszystko, co niezbędne Mavenowi do pracy z Twoim projektem, wokół którego zbudowana jest cała praca. Dokładnie o godz
części Mavena i istnieją pewne przeszkody, które zwykle napotykają użytkownicy Bigtop po raz pierwszy.
Praktyka
Od czego więc zacząć? Przejdź do strony pobierania i pobierz najnowszą stabilną wersję jako archiwum. Można tam również znaleźć artefakty binarne zebrane przez Bigtop. Nawiasem mówiąc, wśród popularnych menedżerów pakietów obsługiwane są YUM i APT.
Alternatywnie możesz pobrać najnowszą stabilną wersję bezpośrednio z
githubie:
$ git clone --branch branch-1.4 https://github.com/apache/bigtop.gitKlonowanie w „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), готово.Wynikowy katalog ./bigtop wygląda mniej więcej tak:
./bigtop-bigpetstore — aplikacje demonstracyjne, przykłady syntetyczne
./bigtop-ci - Narzędzia CI, Jenkins
./bigtop-data-generators — generowanie danych, materiały syntetyczne, do testów dymu itp.
./bigtop-deploy - narzędzia wdrażania
./bigtop-packages — konfiguracje, skrypty, poprawki do montażu, główna część narzędzia
./bigtop-test-framework — ramy testowania
./bigtop-tests — same testy, obciążenie i dym
./bigtop_toolchain — środowisko do montażu, przygotowanie środowiska do pracy narzędzia
./build — zbuduj katalog roboczy
./dl — katalog pobranych źródeł
./docker — budowanie obrazów dokerów, testowanie
./gradle - konfiguracja stopniowa
./output – katalog, w którym znajdują się artefakty kompilacji
./provisioner - aprowizacja
Na tym etapie najciekawszą dla nas rzeczą jest główna konfiguracja ./bigtop/bigtop.bom, w którym widzimy wszystkie obsługiwane komponenty wraz z wersjami. Tutaj możemy określić inną wersję produktu (jeśli nagle zapragniemy spróbować go zbudować) lub wersję build (jeśli np. dodaliśmy istotną łatkę).
Podkatalog również cieszy się dużym zainteresowaniem ./bigtop/bigtop-packages, co jest bezpośrednio związane z procesem składania z nimi komponentów i pakietów.
Pobraliśmy więc archiwum, rozpakowaliśmy je lub stworzyliśmy klon z githuba. Czy możemy zacząć budować?
Nie, najpierw przygotujmy środowisko.
Przygotowanie środowiska
I tu przydałby się mały rekolekcje. Aby zbudować niemal każdy mniej lub bardziej skomplikowany produkt, potrzebne jest określone środowisko - w naszym przypadku jest to JDK, te same biblioteki współdzielone, pliki nagłówkowe itp., narzędzia np. ant, ivy2 i wiele więcej. Jedną z opcji uzyskania środowiska potrzebnego dla Bigtop jest zainstalowanie niezbędnych komponentów na hoście kompilacji. Mogę się mylić co do chronologii, ale wydaje się, że w wersji 1.0 istniała również opcja wbudowania wstępnie skonfigurowanych i dostępnych obrazów Dockera, które można znaleźć tutaj.
Jeśli chodzi o przygotowanie otoczenia, jest do tego asystent - Puppet.
Możesz użyć następujących poleceń, uruchom je z katalogu głównego
narzędzie, ./bigtop:
./gradlew toolchain
./gradlew toolchain-devtools
./gradlew toolchain-puppetmodules
Lub bezpośrednio przez marionetkę:
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"Niestety już na tym etapie mogą pojawić się trudności. Ogólna rada jest taka, aby użyć obsługiwanej dystrybucji, zaktualizować ją na hoście kompilacji lub wypróbować trasę dokowaną.
montaż
Co możemy spróbować zebrać? Odpowiedź na to pytanie zostanie udzielona przez wynik polecenia
./gradlew tasks
W sekcji Zadania pakietu znajduje się wiele produktów będących końcowymi artefaktami Bigtop.
Można je rozpoznać po przyrostku -rpm lub -pkg-ind (w przypadku build
w oknie dokowanym). W naszym przypadku najciekawszy jest Hadoop.
Spróbujmy zbudować w środowisku naszego serwera kompilacji:
./gradlew hadoop-rpmBigtop sam pobierze niezbędne źródła potrzebne dla konkretnego komponentu i rozpocznie montaż. Tym samym działanie narzędzia uzależnione jest od repozytoriów Mavena i innych źródeł, czyli wymaga dostępu do Internetu.
Podczas pracy generowane jest standardowe wyjście. Czasami to i komunikaty o błędach mogą pomóc w zrozumieniu, co poszło nie tak. A czasami trzeba uzyskać dodatkowe informacje. W tym przypadku warto dodać argumenty --info lub --debugi też może się przydać –stacktrace. Istnieje wygodny sposób wygenerowania zestawu danych do późniejszego dostępu do list mailingowych, czyli klucza --scan.
Z jego pomocą bigtop zbierze wszystkie informacje i umieści je w gradle, po czym poda link,
postępując według tego, kompetentna osoba będzie w stanie zrozumieć, dlaczego montaż się nie powiódł.
Należy pamiętać, że ta opcja może ujawnić informacje, których nie chcesz, takie jak nazwy użytkowników, węzły, zmienne środowiskowe itp., więc zachowaj ostrożność.
Często błędy są konsekwencją braku możliwości zdobycia jakichkolwiek elementów niezbędnych do montażu. Zwykle można rozwiązać problem, tworząc łatkę naprawiającą coś w źródłach, na przykład adresy w pliku pom.xml w katalogu głównym źródeł. Odbywa się to poprzez utworzenie i umieszczenie go w odpowiednim katalogu ./bigtop/bigtop-packages/src/common/oozie/ patch na przykład w formie 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>
Najprawdopodobniej w momencie czytania tego artykułu nie będziesz musiał samodzielnie wykonywać powyższej naprawy.
Wprowadzając jakiekolwiek poprawki i zmiany w mechanizmie złożenia, może zaistnieć potrzeba „zresetowania” złożenia za pomocą polecenia czyszczenia:
./gradlew hadoop-clean
> Task :hadoop_vardefines
> Task :hadoop-clean
BUILD SUCCESSFUL in 5s
2 actionable tasks: 2 executedTa operacja cofnie wszystkie zmiany w złożeniu tego komponentu, po czym montaż zostanie wykonany ponownie. Tym razem spróbujemy zbudować projekt w obrazie dokera:
./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 executedKompilację przeprowadzono pod CentOS, ale można ją również wykonać pod Ubuntu:
./gradlew -POS=ubuntu-16.04 -Pprefix=1.2.1 hadoop-pkg-indOprócz budowania pakietów dla różnych dystrybucji Linuksa narzędzie może stworzyć repozytorium ze skompilowanymi pakietami, na przykład:
./gradlew yumMożesz także pamiętać o testach dymnych i wdrożeniach w Dockerze.
Utwórz klaster trzech węzłów:
./gradlew -Pnum_instances=3 docker-provisionerUruchom testy dymne w klastrze trzech węzłów:
./gradlew -Pnum_instances=3 -Prun_smoke_tests docker-provisionerUsuń klaster:
./gradlew docker-provisioner-destroyUzyskaj polecenia umożliwiające połączenie wewnątrz kontenerów dokowanych:
./gradlew docker-provisioner-sshPokaż stan:
./gradlew docker-provisioner-statusWięcej informacji na temat zadań wdrożeniowych można znaleźć w dokumentacji.
Jeżeli mówimy o testach to jest ich całkiem sporo, głównie dymne i integracyjne. Ich analiza wykracza poza zakres tego artykułu. Powiem tylko, że złożenie zestawu dystrybucyjnego nie jest tak trudnym zadaniem, jak mogłoby się wydawać na pierwszy rzut oka. Udało nam się złożyć i przejść testy na wszystkich komponentach, które wykorzystujemy w naszej produkcji, nie mieliśmy też problemów z ich wdrożeniem i wykonaniem podstawowych operacji w środowisku testowym.
Oprócz istniejących komponentów w Bigtop możliwe jest dodanie czegokolwiek innego, nawet własnego oprogramowania. Wszystko to jest doskonale zautomatyzowane i wpisuje się w koncepcję CI/CD.
wniosek
Oczywiście tak skompilowanej dystrybucji nie należy od razu wysyłać na produkcję. Musisz zrozumieć, że jeśli istnieje realna potrzeba zbudowania i wspierania Twojej dystrybucji, musisz zainwestować w to pieniądze i czas.
Jednak w połączeniu z odpowiednim podejściem i profesjonalnym zespołem całkiem możliwe jest obejście się bez komercyjnych rozwiązań.
Należy zauważyć, że sam projekt Bigtop wymaga rozwoju i obecnie nie wydaje się, aby był aktywnie rozwijany. Niejasna jest także perspektywa pojawienia się w nim Hadoopa 3. Swoją drogą, jeśli naprawdę masz potrzebę zbudowania Hadoopa 3, możesz zajrzeć do od Arenadata, w którym oprócz standardu
Istnieje szereg dodatkowych komponentów (Ranger, Knox, NiFi).
Jeśli chodzi o Rostelecom, dla nas Bigtop jest jedną z rozważanych dziś opcji. Czy się na to zdecydujemy, czy nie, czas pokaże.
dodatek
Aby dołączyć nowy komponent do złożenia, należy dodać jego opis do bigtop.bom i ./bigtop-packages. Możesz spróbować to zrobić analogicznie do istniejących komponentów. Spróbuj to rozgryźć. To nie jest tak trudne, jak się wydaje na pierwszy rzut oka.
Co myślisz? Będzie nam miło poznać Twoją opinię w komentarzach i dziękujemy za uwagę!
Artykuł został przygotowany przez zespół zarządzający danymi Rostelecom
Źródło: www.habr.com