🍹 ☄️ 🍩 Apache Bigtop e a escolha da distribuição do Hadoop hoje 🌅 🏥 🔕

Provavelmente não é segredo que o ano passado foi um ano de grandes mudanças para o Apache Hadoop. No ano passado, a Cloudera e a Hortonworks se fundiram (essencialmente a aquisição da segunda), e a Mapr, devido a sérios problemas financeiros, foi vendida à Hewlett Packard. E, se alguns anos antes, no caso de instalações locais, muitas vezes era necessário fazer uma escolha entre Cloudera e Hortonworks, hoje, infelizmente, não tínhamos essa opção. Outra surpresa foi o fato de que, desde fevereiro deste ano, a Cloudera anunciou o término do lançamento de assemblies binários de sua distribuição em um repositório público, e agora eles estão disponíveis apenas por assinatura paga. Obviamente, a capacidade de baixar as versões mais recentes do CDH e HDP, lançadas antes do final de 2019, ainda existe, e o suporte a elas é esperado por um a dois anos. Mas o que fazer a seguir? Para aqueles,quem pagou anteriormente pela assinatura, nada mudou. E para aqueles que não desejam mudar para uma versão paga do kit de distribuição, mas desejam obter as versões mais recentes dos componentes do cluster, além de patches e outras atualizações, preparamos este artigo. Nele, consideraremos possíveis maneiras de sair dessa situação.

. , . ? Arenadata Hadoop, , . Vanilla Hadoop, , “” Apache Bigtop. ? .

Arenadata Hadoop

Esta é uma distribuição completamente nova e, até agora, pouco conhecida do desenvolvimento doméstico. Infelizmente, no momento há apenas este artigo sobre Habré .

Mais informações podem ser encontradas no site oficial do projeto. As distribuições mais recentes são baseadas no Hadoop 3.1.2 para versão 3 e 2.8.5 para versão 2.

Informações sobre o roteiro podem ser encontradas aqui .

Interface do Arenadata Cluster Manager O

principal produto da Arenadata é o Arenadata Cluster Manager (ADCM), que é usado para instalar, configurar e monitorar várias soluções de software da empresa. O ADCM é gratuito e sua funcionalidade é expandida adicionando pacotes a ele, que são um conjunto de manuais de instruções. Os pacotes são divididos em dois tipos: empresa e comunidade. Estes últimos estão disponíveis para download gratuito no Arenadata. Também é possível desenvolver seu próprio pacote e conectá-lo ao ADCM.

Para a implantação e o gerenciamento do Hadoop 3, é oferecida uma versão comunitária do pacote em conjunto com o ADCM e, para o hadoop 2, existe apenas o Apache Ambaricomo uma alternativa. Quanto aos repositórios com pacotes, eles estão abertos para acesso público, podem ser baixados e instalados da maneira usual para todos os componentes do cluster. Em geral, a distribuição parece muito interessante. Tenho certeza de que há pessoas acostumadas a soluções como Cloudera Manager e Ambari e que gostarão da própria ADCM. Para alguns, o fato de o kit de distribuição estar incluído no registro do software de substituição de importação será uma grande vantagem .

Se falarmos sobre os contras, eles serão os mesmos de todas as outras distribuições do Hadoop. Nomeadamente:

O chamado "bloqueio de fornecedor". Usando os exemplos de Cloudera e Hortonworks, já percebemos que sempre há o risco de alterar as políticas da empresa.
Atraso significativo atrás do Apache a montante.

Baunilha hadoop

Como você sabe, o Hadoop não é um produto monolítico, mas, de fato, toda uma galáxia de serviços em torno de seu sistema de arquivos HDFS distribuído. Poucas pessoas precisarão de um cluster de arquivos. Um precisa do Hive e o outro Presto, e há o HBase e o Phoenix, o Spark é cada vez mais usado. Às vezes, é encontrado Oozie, Sqoop e Flume para orquestrar e baixar dados. E se surgir o problema de segurança, o Kerberos em conjunto com o Ranger será lembrado imediatamente.

Versões binárias dos componentes do Hadoop estão disponíveis no site de cada projeto de ecossistema na forma de tarballs. Eles podem ser baixados e a instalação iniciada, mas com uma condição: além da automontagem de pacotes de binários "brutos", que você provavelmente deseja executar, você não confia na compatibilidade das versões baixadas dos componentes entre si. A opção preferida é construir usando o Apache Bigtop. O Bigtop permite que você construa a partir dos repositórios maven do Apache, execute testes e construa pacotes. Mas, o que é muito importante para nós, o Bigtop coletará as versões de componentes que serão compatíveis entre si. Falaremos sobre isso em mais detalhes abaixo.

Apache bigtop

O Apache Bigtop é uma ferramenta para criar, empacotar e testar vários
projetos de código aberto, como, por exemplo, Hadoop e Greenplum. Bigtop tem muitos
lançamentos. No momento da redação deste artigo, a versão estável mais recente era a versão 1.4
e a versão master era 1.5. Versões diferentes de releases usam versões diferentes de
componentes. Por exemplo, para o 1.4, os componentes principais do Hadoop são a versão 2.8.5 e no master
2.10.0. A composição dos componentes suportados também está mudando. Algo ultrapassado e
não renovável sai, e em seu lugar surge algo novo, mais procurado, e
não necessariamente algo da família Apache.

Bigtop também tem muitos garfos .

Quando começamos a nos familiarizar com o Bigtop, ficamos surpresos principalmente com seu modesto, em comparação com outros projetos Apache, prevalência e fama, além de uma comunidade muito pequena. Daqui resulta que há um mínimo de informações sobre o produto, e uma busca por soluções para problemas surgidos por meio de fóruns e boletins pode não produzir nada. No começo, acabou sendo uma tarefa difícil concluirmos a montagem do kit de distribuição devido aos recursos da própria ferramenta, mas falaremos sobre isso um pouco mais tarde.

Como um teaser, para quem já visitou projetos do universo Linux como o Gentoo e o LFS, pode parecer nostalgicamente agradável trabalhar com essa coisa e relembrar aqueles tempos "passados" em que nós próprios pesquisamos (ou até escrevemos) ebuilds e reconstruído regularmente com novos patches mozilla.

A grande vantagem do Bigtop pode ser considerada a abertura e versatilidade das ferramentas nas quais se baseia. Sua fundação é Gradle e Apache Maven. Gradle é razoavelmente bem conhecido como a ferramenta pela qual o Google coleta o Android. É flexível e, como se costuma dizer, "testado em batalha". O Maven é uma ferramenta em tempo integral para a construção de projetos no próprio Apache e, como a maioria de seus produtos é lançada pelo Maven, ela não poderia ficar sem ela. Vale a pena prestar atenção ao POM (modelo de objeto do projeto) - um arquivo xml “fundamental” com uma descrição de tudo o que é necessário para o Maven trabalhar com seu projeto, em torno do qual todo o trabalho é construído. É na
parte do Maven que surgem alguns obstáculos que geralmente são encontrados pela primeira vez quando eles assumem o Bigtop.

Prática

Então por onde começar? Vamos para a página de download e baixamos a versão estável mais recente como um arquivo. Artefatos binários coletados pelo Bigtop também podem ser encontrados lá. A propósito, dos gerenciadores de pacotes comuns, YUM e APT são suportados.

Como alternativa, você pode baixar a última versão estável diretamente do
github:

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

Clonando no "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), .

O diretório ./bigtop resultante é mais ou menos assim:

./bigtop-bigpetstore- aplicativos de demonstração, exemplos sintéticos
./bigtop-ci- ferramentas de CI, jenkins
./bigtop-data-generators- geração de dados, sintéticos, para testes de fumaça, etc.
./bigtop-deploy- ferramentas de implantação
./bigtop-packages- configurações, scripts, patches para montagem, a parte principal da ferramenta
./bigtop-test-framework- estrutura de teste
./bigtop-tests- testes, estresse e fumaça
./bigtop_toolchain- ambiente para montagem, preparação do ambiente para a ferramenta funcionar
./build- diretório de trabalho da montagem
./dl- diretório para fontes baixadas
./docker- montagem em docker- images, testing
./gradle- gradle config
./output - o diretório no qual os artefatos de montagem entram
./provisioner- provisionamento

O mais interessante para nós, neste estágio, é a principal config./bigtop/bigtop.bom, na qual vemos todos os componentes suportados com versões. É aqui que podemos especificar uma versão diferente do produto (se de repente queremos tentar construí-lo) ou uma versão do assembly (se, por exemplo, adicionamos um patch significativo).

Também é de grande interesse o subdiretório ./bigtop/bigtop-packages, que está diretamente relacionado ao processo de montagem dos componentes e pacotes com eles.

Então, baixamos o arquivo, descompactamos ou clonamos com o github. Podemos iniciar a montagem?

Não, primeiro prepare o ambiente.

Preparação do ambiente

E aqui é necessária uma pequena digressão. Para criar quase qualquer produto mais ou menos complexo, você precisa de um certo ambiente - no nosso caso, é o JDK, as mesmas bibliotecas compartilhadas, arquivos de cabeçalho etc., ferramentas, por exemplo, ant, ivy2 e muito mais. Uma das opções para obter o ambiente necessário para o Bigtop é instalar os componentes necessários no host de montagem. Posso estar enganado na cronologia, mas parece que a partir da versão 1.0 também havia uma opção de construção em imagens de janela de encaixe pré-configuradas e acessíveis, você pode encontrá-las aqui.

Quanto à preparação do ambiente, há um assistente para isso - Puppet.

Você pode usar os seguintes comandos, o lançamento é feito no diretório raiz da
ferramenta,./bigtop:

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

Ou diretamente através do fantoche:

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"

Infelizmente, já podem surgir dificuldades nesta fase. O conselho geral aqui é usar uma distribuição suportada, atualizada no host de construção ou tentar o caminho com a janela de encaixe.

Montagem

O que podemos tentar coletar? A resposta a esta pergunta dará a saída do comando

./gradlew tasks

A seção Tarefas do pacote possui vários produtos que são os artefatos finais do Bigtop.
Eles podem ser identificados pelo sufixo -rpm ou -pkg-ind (no caso de montagem
na janela de encaixe). No nosso caso, o mais interessante é o Hadoop.

Vamos tentar compilar no ambiente do nosso servidor de compilação:

./gradlew hadoop-rpm

O próprio Bigtop fará o download das fontes necessárias para um componente em particular e começará a ser construído. Portanto, a ferramenta está vinculada aos repositórios Maven e outras fontes, ou seja, precisa de acesso à Internet.

No processo, uma saída padrão é formada. Às vezes, você pode entender e as mensagens de erro que deram errado. E às vezes você precisa de mais informações. Nesse caso, vale a pena adicionar os argumentos --info ou --debug, e também pode ser útil –stacktrace. Existe uma maneira conveniente de gerar um conjunto de dados para referência subsequente às listas de discussão, a chave --scan.

Com ele, o bigtop coletará todas as informações e as colocará em gradle, após o que fornecerá um link,
após o qual uma pessoa competente será capaz de entender por que a montagem falhou.
Você deve ter em mente que esta opção pode tornar públicas informações indesejáveis para você, como nomes de usuário, nós, variáveis de ambiente etc., portanto, tenha cuidado.

Muitas vezes, os erros resultam da incapacidade de obter quaisquer componentes necessários para a montagem. Como regra, você pode corrigir o problema criando um patch para corrigir algo na fonte, por exemplo, o endereço em pom.xml no diretório raiz da fonte. Isso é feito criando e colocando-o no diretório de ./bigtop/bigtop-packages/src/common/oozie/patch apropriado , por exemplo, na forma de 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>

Muito provavelmente, no momento da leitura deste artigo, a correção acima não será necessária.

Ao introduzir patches e edições no mecanismo de montagem, pode ser necessário "redefinir" a montagem através do comando de limpeza:

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

Esta operação reverterá todas as alterações na montagem deste componente, após as quais a montagem será executada novamente. Desta vez, tentaremos criar o projeto em uma imagem do 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

A compilação foi feita no CentOS, mas você também pode fazê-lo no Ubuntu:

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

Além de montar pacotes para várias distribuições Linux, a ferramenta pode criar um repositório com pacotes montados, por exemplo:

./gradlew yum

Você também pode se lembrar de testes de fumaça e implantação na janela de encaixe.

Crie um cluster de três nós:

./gradlew -Pnum_instances=3 docker-provisioner

Execute testes de fumaça em um cluster de três nós:

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

Excluir cluster:

./gradlew docker-provisioner-destroy

Obtenha comandos para conectar-se dentro de contêineres do docker

./gradlew docker-provisioner-ssh

Mostrar status:

./gradlew docker-provisioner-status

Você pode ler mais sobre as tarefas de implantação na documentação.

Se falamos de testes, há um número bastante grande deles, principalmente os de fumaça e de integração. Sua análise está além do escopo deste artigo. Só posso dizer que a construção do kit de distribuição não é tão difícil quanto parece à primeira vista. Conseguimos coletar e passar todos os componentes que usamos em nossos produtos nos testes e também não tivemos problemas com a implantação e as operações básicas no ambiente de teste.

Além dos componentes existentes no Bigtop, é possível adicionar outra coisa, até mesmo o seu próprio desenvolvimento de software. Tudo isso é perfeitamente automatizado e se encaixa no conceito de CI / CD.

Conclusão

Obviamente, uma distribuição criada dessa maneira não deve ser imediatamente enviada para produção. Você precisa entender que, se houver uma necessidade real de criar e manter sua distribuição, você precisará investir tempo e dinheiro.

No entanto, em combinação com a abordagem correta e uma equipe profissional, é perfeitamente possível prescindir de soluções comerciais.

É importante notar que o próprio projeto Bigtop precisa ser desenvolvido e parece que hoje não há desenvolvimento ativo nele. Além disso, a perspectiva da aparência do Hadoop 3. não é clara.A propósito, se você realmente precisa criar o Hadoop 3, pode ver a bifurcação da Arenadata, na qual, além dos
componentes padrão , existem vários componentes adicionais (Ranger, Knox, NiFi).

Quanto à Rostelecom, para nós o Bigtop é uma das opções consideradas hoje. Independentemente de pararmos ou não, o tempo dirá.

Apêndice

Para incluir um novo componente na montagem, você precisa adicionar sua descrição em bigtop.bom e ./bigtop-packages. Você pode tentar fazer isso por analogia com os componentes existentes. Tente descobrir isso. Não é tão difícil quanto parece à primeira vista.

O que você acha? Teremos o maior prazer em ver sua opinião nos comentários e obrigado por sua atenção!

Este artigo foi preparado pela equipe de gerenciamento de dados Rostelecom

Apache Bigtop e a escolha da distribuição do Hadoop hoje