Apache Bigtop e escolhendo uma distribuição 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 fundiram-se (essencialmente, a aquisição desta última), e a Mapr, devido a graves problemas financeiros, foi vendida à Hewlett Packard. E se alguns anos antes, no caso de instalações on-premises, muitas vezes a escolha tinha que ser feita entre Cloudera e Hortonworks, hoje, infelizmente, não temos essa escolha. Outra surpresa foi o fato de a Cloudera ter anunciado em fevereiro deste ano que deixaria de liberar assemblies binários de sua distribuição no repositório público, e agora eles estão disponíveis apenas por meio de assinatura paga. Claro, ainda é possível baixar as versões mais recentes do CDH e HDP lançadas antes do final de 2019, e o suporte para elas é esperado por um a dois anos. Mas o que fazer a seguir? Para quem já pagou por assinatura, nada mudou. E para quem não deseja mudar para a versão paga da distribuição, mas ao mesmo tempo deseja receber as versões mais recentes dos componentes do cluster, além de patches e outras atualizações, preparamos este artigo. Nele consideraremos possíveis opções para sair desta situação.

O artigo é mais uma revisão. Não conterá uma comparação de distribuições e uma análise detalhada delas, e não haverá receitas para instalá-las e configurá-las. O que vai acontecer? Falaremos brevemente sobre uma distribuição como o Arenadata Hadoop, que merece nossa atenção por sua disponibilidade, hoje muito rara. E depois falaremos sobre o Vanilla Hadoop, principalmente sobre como ele pode ser “cozido” usando o Apache Bigtop. Preparar? Então seja bem-vindo ao gato.

Arenadata Hadoop

Este é um kit de distribuição de desenvolvimento doméstico completamente novo e ainda pouco conhecido. Infelizmente, neste momento em Habré só existe este artigo.

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

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

Interface do Gerenciador de Cluster Arenadata

O principal produto da Arenadata é Gerenciador de cluster Arenadata (ADCM), que é usado para instalar, configurar e monitorar diversas soluções de software da empresa. O ADCM é distribuído gratuitamente e sua funcionalidade é expandida com a adição de pacotes, que são um conjunto de playbooks ansible. Os pacotes são divididos em dois tipos: empresariais e comunitários. Estes últimos estão disponíveis para download gratuito no site da Arenadata. Também é possível desenvolver seu próprio pacote e conectá-lo ao ADCM.

Para implantação e gerenciamento do Hadoop 3, uma versão comunitária do pacote é oferecida em conjunto com o ADCM, mas para o Hadoop 2 há apenas apache ambari como uma alternativa. Já os repositórios com pacotes são abertos ao acesso público, podendo ser baixados e instalados da forma usual para todos os componentes do cluster. No geral, a distribuição parece muito interessante. Tenho certeza que haverá quem esteja acostumado com soluções como Cloudera Manager e Ambari, e que goste do próprio ADCM. Para alguns, será também uma enorme vantagem que a distribuição incluído no registro do software para substituição de importações.

Se falarmos sobre as desvantagens, elas serão as mesmas de todas as outras distribuições do Hadoop. Nomeadamente:

• O chamado “aprisionamento do fornecedor”. Usando os exemplos da Cloudera e da Hortonworks, já percebemos que sempre existe o risco de mudar a política da empresa.
• Atraso significativo em relação ao upstream do Apache.

Hadoop baunilha

Como você sabe, o Hadoop não é um produto monolítico, mas, na verdade, toda uma galáxia de serviços em torno de seu sistema de arquivos distribuído HDFS. Poucas pessoas terão o suficiente de um cluster de arquivos. Alguns precisam do Hive, outros do Presto, e depois há o HBase e o Phoenix; o Spark é cada vez mais usado. Para orquestração e carregamento de dados, às vezes são encontrados Oozie, Sqoop e Flume. E se surgir a questão da segurança, então o Kerberos em conjunto com o Ranger vem imediatamente à mente.

Versões binárias dos componentes do Hadoop estão disponíveis no site de cada um dos projetos do ecossistema na forma de tarballs. Você pode baixá-los e iniciar a instalação, mas com uma condição: além de montar pacotes de forma independente a partir de binários “brutos”, o que você provavelmente deseja fazer, você não terá nenhuma confiança na compatibilidade das versões baixadas dos componentes com cada outro. A opção preferida é construir usando Apache Bigtop. Bigtop permitirá que você construa a partir de repositórios Apache Maven, execute testes e construa pacotes. Mas, o que é muito importante para nós, a Bigtop montará aquelas versões de componentes que serão compatíveis entre si. Falaremos sobre isso com mais detalhes a seguir.

Apache Grande Topo

Apache Bigtop é uma ferramenta para construir, empacotar e testar uma série de
projetos de código aberto, como Hadoop e Greenplum. Bigtop tem muito
lançamentos. No momento em que este artigo foi escrito, a versão estável mais recente era a versão 1.4,
e no master havia 1.5. Diferentes versões de lançamentos usam versões diferentes
componentes. Por exemplo, para 1.4 os componentes principais do Hadoop têm a versão 2.8.5 e no master
2.10.0. A composição dos componentes suportados também está mudando. Algo desatualizado e
o não renovável desaparece e em seu lugar surge algo novo, mais procurado e
não é necessariamente algo da própria família Apache.

Além disso, Bigtop tem muitos garfos.

Quando começamos a conhecer o Bigtop, ficamos surpresos em primeiro lugar com sua modesta prevalência e popularidade em comparação com outros projetos Apache, bem como com uma comunidade muito pequena. Conclui-se que há informações mínimas sobre o produto, e a busca por soluções para problemas que surgiram em fóruns e listas de discussão pode não render nada. A princípio foi uma tarefa difícil concluir a montagem completa da distribuição devido às características da própria ferramenta, mas falaremos sobre isso um pouco mais tarde.

A título de teaser, quem já se interessou por projetos do universo Linux como Gentoo e LFS pode achar nostalgicamente agradável trabalhar com isso e relembrar aqueles momentos “épicos” em que nós mesmos procurávamos (ou mesmo escrevíamos) ebuilds e reconstrui regularmente o Mozilla com novos patches.

A grande vantagem do Bigtop é a abertura e versatilidade das ferramentas nas quais se baseia. É baseado em Gradle e Apache Maven. Gradle é bastante conhecido como a ferramenta que o Google usa para construir o Android. É flexível e, como dizem, “testado em batalha”. Maven é uma ferramenta padrão para construção de projetos no próprio Apache e, como a maioria de seus produtos são lançados por meio do Maven, também não poderia ser feito sem ele aqui. Vale a pena prestar atenção ao POM (modelo de objeto de projeto) - o arquivo xml “fundamental” que descreve tudo o que é necessário para o Maven trabalhar com seu projeto, em torno do qual todo o trabalho é construído. Exatamente em
partes do Maven e existem alguns obstáculos que os usuários iniciantes do Bigtop geralmente encontram.

Prática

Então, por onde você deve começar? Vá para a página de download e baixe a versão estável mais recente como um arquivo. Lá você também pode encontrar artefatos binários coletados pelo Bigtop. A propósito, entre os gerenciadores de pacotes comuns, YUM e APT são suportados.

Alternativamente, você pode baixar a versão estável mais recente diretamente de
GitHub:

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

Clonagem em “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 se parece com isto:

./bigtop-bigpetstore — aplicações 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 — os próprios testes, carga e fumaça
./bigtop_toolchain — ambiente para montagem, preparando o ambiente para a ferramenta funcionar
./build - construir diretório de trabalho
./dl — diretório para fontes baixadas
./docker - construção de imagens docker, testes
./gradle - configuração gradle
./output – o diretório para onde vão os artefatos de construção
./provisioner - provisionamento

O mais interessante para nós nesta fase é a configuração principal ./bigtop/bigtop.bom, no qual vemos todos os componentes suportados com versões. É aqui que podemos especificar uma versão diferente do produto (se de repente quisermos tentar construí-lo) ou uma versão de construção (se, por exemplo, adicionamos um patch significativo).

O subdiretório também é de grande interesse ./bigtop/bigtop-packages, que está diretamente relacionado ao processo de montagem de componentes e embalagens com eles.

Então, baixamos o arquivo, descompactamos ou fizemos um clone do github, podemos começar a construir?

Não, vamos preparar o ambiente primeiro.

Preparando o Ambiente

E aqui precisamos de um pequeno retiro. Para construir quase qualquer produto mais ou menos complexo, você precisa de um determinado 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 construção. Posso estar errado na cronologia, mas parece que com a versão 1.0 também houve a opção de construir imagens Docker pré-configuradas e acessíveis, que podem ser encontradas aqui.

Quanto à preparação do ambiente, existe um auxiliar para isso - o Puppet.

Você pode usar os seguintes comandos, executados no diretório raiz
instrumento, ./bigtop:

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

Ou diretamente via 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, podem surgir dificuldades já nesta fase. O conselho geral aqui é usar uma distribuição suportada, atualizada no host de compilação, ou tentar a rota docker.

montagem

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

./gradlew tasks

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

Vamos tentar construir no ambiente do nosso servidor de construção:

./gradlew hadoop-rpm

O próprio Bigtop baixará as fontes necessárias para um componente específico e iniciará a montagem. Assim, o funcionamento da ferramenta depende de repositórios Maven e outras fontes, ou seja, necessita de acesso à Internet.

Durante a operação, a saída padrão é gerada. Às vezes, isso e mensagens de erro podem ajudá-lo a entender o que deu errado. E às vezes você precisa obter informações adicionais. Neste caso vale a pena adicionar argumentos --info ou --debug, e também pode ser útil –stacktrace. Existe uma maneira conveniente de gerar um conjunto de dados para acesso posterior às listas de discussão, a chave --scan.

Com a ajuda dele, o bigtop irá coletar todas as informações e colocá-las no gradle, após o que fornecerá um link,
seguindo isso, uma pessoa competente será capaz de entender por que a montagem falhou.
Esteja ciente de que esta opção pode expor informações que você não deseja, como nomes de usuário, nós, variáveis ​​de ambiente, etc., portanto, tome cuidado.

Freqüentemente, os erros são consequência da incapacidade de obter quaisquer componentes necessários para a montagem. Normalmente, você pode corrigir o problema criando um patch para corrigir algo nas fontes, por exemplo, endereços em pom.xml no diretório raiz das fontes. Isso é feito criando-o e colocando-o no diretório apropriado ./bigtop/bigtop-packages/src/common/oozie/ patch, por exemplo, no formato 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>

Provavelmente, no momento da leitura deste artigo, você não precisará fazer a correção acima sozinho.

Ao introduzir quaisquer patches e alterações no mecanismo de montagem, pode ser necessário “redefinir” a montagem usando o comando cleanup:

./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 o que a montagem será realizada novamente. Desta vez tentaremos construir o projeto em uma imagem 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 realizada no CentOS, mas também pode ser feita no Ubuntu:

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

Além de construir pacotes para diversas distribuições Linux, a ferramenta pode criar um repositório com pacotes compilados, por exemplo:

./gradlew yum

Você também pode se lembrar dos testes de fumaça e da implantação no Docker.

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

Exclua um cluster:

./gradlew docker-provisioner-destroy

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

./gradlew docker-provisioner-ssh

Mostrar status:

./gradlew docker-provisioner-status

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

Se falamos de testes, há um grande número deles, principalmente fumaça e integração. Sua análise foge ao escopo deste artigo. Deixe-me apenas dizer que montar um kit de distribuição não é uma tarefa tão difícil quanto pode parecer à primeira vista. Conseguimos montar e passar nos testes todos os componentes que utilizamos em nossa produção, e também não tivemos problemas para implantá-los e realizar operações básicas no ambiente de testes.

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

Conclusão

Obviamente, a distribuição assim compilada não deve ser enviada imediatamente para produção. Você precisa entender que se há uma necessidade real de construir e apoiar sua distribuição, então você precisa investir tempo e dinheiro nisso.

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

É importante notar que o próprio projecto Bigtop necessita de desenvolvimento e não parece estar actualmente a ser desenvolvido activamente. A perspectiva de o Hadoop 3 aparecer nele também não é clara. A propósito, se você realmente precisa construir o Hadoop 3, você pode dar uma olhada garfo da Arenadata, na qual, além do padrão
Existem vários componentes adicionais (Ranger, Knox, NiFi).

Quanto à Rostelecom, para nós o Bigtop é uma das opções que estão sendo consideradas hoje. Quer escolhamos 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. 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 pela atenção!

O artigo foi elaborado pela equipe de gerenciamento de dados da Rostelecom

Fonte: habr.com