No mundo corporativo, houve uma saciedade com sistemas front-end, barramentos de dados e outros sistemas clássicos que foram implementados por todos nos últimos 10 a 15 anos. Mas há um segmento que, até recentemente, estava no status de "todo mundo quer, mas ninguém sabe o que é". E isso é Big Data. Parece lindamente, promovido pelas principais empresas ocidentais - como não se tornar um petisco?
Mas enquanto a maioria está apenas observando e perguntando, algumas empresas começaram a implementar ativamente soluções baseadas nessa pilha de tecnologia em seu cenário de TI. Um papel importante foi desempenhado pelo surgimento de distribuições comerciais do Apache Hadoop, cujos desenvolvedores fornecem suporte técnico aos seus clientes. Sentindo a necessidade dessa solução, um de nossos clientes decidiu organizar um data warehouse distribuído no conceito Data Lake baseado no Apache Hadoop.
Objetivos do projeto
Primeiro, otimize o trabalho do departamento de gerenciamento de riscos. Antes de iniciar o trabalho, todo um departamento estava envolvido no cálculo dos fatores de risco de crédito (FCR) e todos os cálculos foram realizados manualmente. O recálculo levava cerca de um mês a cada vez, e os dados nos quais era baseado tinham tempo para ficar desatualizados. Portanto, as tarefas da solução incluíam o carregamento diário do delta de dados no repositório, recalculando o FCD e construindo data marts na ferramenta de BI (a funcionalidade SpagoBI era suficiente para esta tarefa) para visualizá-los.
Em segundo lugar, fornecer ferramentas de mineração de dados de alto desempenho para funcionários de bancos envolvidos na ciência de dados. Essas ferramentas, como Jupyter e Apache Zeppelin, podem ser instaladas localmente e também podem ser usadas para explorar dados e construir modelos. Mas sua integração com o cluster Cloudera permite usar os recursos de hardware dos nós de sistema mais produtivos para cálculos, o que acelera as tarefas de análise de dados em dezenas ou mesmo centenas de vezes.
O rack Oracle Big Data Appliance foi escolhido como a solução de hardware de destino; portanto, a distribuição Clachede do Apache Hadoop foi tomada como base. O rack ficou em funcionamento por algum tempo e, para acelerar o processo, os servidores na nuvem privada do cliente foram alocados para este projeto. A solução é razoável, mas houve vários problemas, os quais discutirei abaixo.
As seguintes tarefas foram planejadas dentro do projeto:
- Implante o CDH da Cloudera (distribuição da Cloudera, incluindo Apache Hadoop) e serviços adicionais necessários para o trabalho.
- Configure o software instalado.
- Configure a integração contínua para acelerar o processo de desenvolvimento (será abordado em um artigo separado).
- Instale ferramentas de BI para criar relatórios e ferramentas de descoberta de dados para garantir o trabalho do datacenter (será abordado em uma postagem separada).
- Desenvolver aplicativos para baixar os dados necessários dos sistemas finais, bem como suas atualizações regulares.
- Desenvolva formulários de relatório para visualizar dados em uma ferramenta de BI.
Não é o primeiro ano em que a Neoflex desenvolve e implementa sistemas baseados no Apache Hadoop e ainda possui seu próprio produto para o desenvolvimento visual dos processos de ETL - o Neoflex Datagram. Durante muito tempo, quis participar de um dos projetos desta classe e fiquei feliz em administrar esse sistema. A experiência acabou sendo muito valiosa e motivadora para um estudo mais aprofundado do assunto, por isso apresso-me a compartilhá-lo com você. Espero que seja interessante.
Recursos
Antes de iniciar a instalação, é recomendável que você prepare tudo o que precisa.
A quantidade e a potência do ferro dependem diretamente de quantas e quais mídias precisarão ser implantadas. Para fins de desenvolvimento, você pode instalar todos os componentes em pelo menos uma máquina virtual frágil, mas essa abordagem não é bem-vinda.
Na fase de pilotagem do projeto e desenvolvimento ativo, quando o número de usuários do sistema era mínimo, um ambiente principal era suficiente - o que podia ser acelerado reduzindo o tempo de carregamento de dados dos sistemas finais (o procedimento mais frequente e longo para o desenvolvimento de data warehouses). Agora que o sistema se estabilizou, chegamos a uma configuração com três ambientes - teste, pré-produto e produto (principal).
Em uma nuvem privada, os servidores foram alocados para organizar 2 ambientes - o principal e o de teste. As especificações de mídia são mostradas na tabela abaixo:
| Nomeação | Quantidade | vCPU | vRAM, Gb | Discos, Gb |
|---|
| Ambiente principal, serviços Cloudera | 3 | 8 | 64 | 2.200 |
| Ambiente primário, HDFS | 3 | 22 | 288 | 5000 |
| Ambiente principal, Ferramentas de descoberta de dados | 1 | 16 | 128 | 2200 |
| Ambiente de teste, serviços Cloudera | 1 | 8 | 64 | 2200 |
| Ambiente de teste, HDFS | 2 | 22 | 256 | 4000 |
| Ambiente principal, Ferramentas de descoberta de dados | 1 | 16 | 128 | 2200 |
| Ci | 2 | 6 | 48. | 1000 |
Posteriormente, o ambiente principal foi migrado para o Oracle BDA e os servidores foram usados para organizar o ambiente de pré-produção.
A decisão sobre a migração foi justificada - os recursos alocados para servidores HDFS estavam objetivamente ausentes. Os gargalos eram pequenos discos (o que significa 5 TB para Big Data?) E processadores insuficientemente poderosos, que eram carregados de maneira estável a 95% durante o trabalho regular de tarefas de carregamento de dados. Com outros servidores, a situação é oposta - quase o tempo todo eles ficam ociosos e seus recursos podem ser usados com grande vantagem em outros projetos.
Com o software, as coisas não foram fáceis - devido ao fato de o desenvolvimento ter sido realizado em uma nuvem privada sem acesso à Internet, todos os arquivos tiveram que ser transferidos através do serviço de segurança e somente mediante acordo. Nesse sentido, eu tive que pré-carregar todas as distribuições, pacotes e dependências necessários.
Definir keepcache = 1 no arquivo /etc/yum.conf (o RHEL 7.3 foi usado como sistema operacional) ajudou muito nessa tarefa difícil - instalar o software necessário em uma máquina com acesso à rede é muito mais fácil do que baixá-lo manualmente dos repositórios junto com as dependências;)
O que você precisa implantar:
- Oracle JDK (sem Java em qualquer lugar).
- Um banco de dados para armazenar informações criadas e usadas pelos serviços CDH (por exemplo, Hive Metastore). No nosso caso, o PostgreSQL versão 9.2.18 foi instalado, mas qualquer um dos serviços Cloudera suportados pode ser usado (a lista é diferente para diferentes versões da distribuição, consulte a seção Requisitos e versões suportadas do site oficial). Aqui, note-se que a escolha do banco de dados não foi totalmente bem-sucedida - o Oracle BDA vem com o banco de dados MySQL (um de seus produtos, que foi adquirido pela Sun) e seria mais lógico usar um banco de dados semelhante para outros ambientes, o que simplificaria o processo de migração. É recomendável escolher uma distribuição com base na solução de hardware de destino.
- Daemon Chrony para sincronização de horário nos servidores.
- Servidor Cloudera Manager.
- Gerente de Demônios Cloudera.
Preparação para instalação
Antes de iniciar a instalação do CDH, vários trabalhos preparatórios devem ser feitos. Uma parte é útil durante a instalação, a outra simplifica a operação.
Instalação e configuração do SO
Antes de tudo, vale a pena preparar as máquinas virtuais (e reais) que hospedarão o sistema: instale a versão suportada em cada uma delas (a lista é diferente para diferentes versões da distribuição, consulte a seção "Requisitos e versões suportadas" do site oficial), atribua nomes de host são nomes compreensíveis (por exemplo, <system_name> master1,2,3 ..., <system_name> slave1,2,3 ...), além de marcar discos para armazenamento de arquivos e arquivos temporários criados durante a operação do sistema.
As recomendações de marcação são as seguintes:
- Em servidores com HDFS, crie um volume de pelo menos 500 Gb para arquivos criados pelo YARN durante o curso das tarefas e coloque-o no diretório / yarn (onde esse volume deve ser montado após a instalação do CDH). Um pequeno volume (cerca de 100 Gb) deve ser alocado para o sistema operacional, serviços Cloudera, logs e outras instalações. Todo o espaço livre que permanecerá após essas manipulações deverá ser combinado em um grande volume e montado no diretório / dfs antes de carregar os dados no armazenamento. O HDFS armazena dados na forma de blocos bastante pequenos e é melhor não se envolver na transferência novamente. Além disso, para a conveniência de adicionar discos posteriormente, é recomendável usar o LVM - será mais fácil expandir o armazenamento (especialmente quando se tornar realmente GRANDE).
- Em servidores com serviços Cloudera, você pode montar todo o espaço disponível no diretório raiz - não deve haver problemas com grandes volumes de arquivos, principalmente se você limpar regularmente os logs. A única exceção é o servidor com o banco de dados, que os serviços Cloudera usam para suas necessidades - nesse servidor, faz sentido marcar um volume separado no diretório em que os arquivos desse banco de dados são armazenados (isso dependerá da distribuição selecionada). Os serviços gravam com moderação e 500 Gb devem ser mais que suficientes. Por segurança, você também pode usar o LVM.
Configurando o servidor http e a instalação offline dos pacotes yum e CDH
Como o software é instalado sem acesso à Internet, para simplificar a instalação de pacotes, é recomendável aumentar o servidor HTTP e usá-lo para criar um repositório local que será acessível pela rede. Você pode instalar todo o software localmente usando, por exemplo, rpm, mas com um grande número de servidores e a aparência de vários ambientes, é conveniente ter um único repositório a partir do qual você pode instalar pacotes sem precisar transferi-los manualmente de máquina para máquina.
A instalação foi realizada no sistema operacional Red Hat 7.3; portanto, o artigo conterá comandos específicos a ele e a outros sistemas operacionais baseados no CentOS. Quando instalada em outros sistemas operacionais, a sequência será semelhante, apenas os gerenciadores de pacotes serão diferentes.
Para não escrever em qualquer lugar sudo, assumimos que a instalação é da raiz.
Aqui está o que você precisa fazer:
1. A máquina na qual o servidor HTTP e as distribuições estarão localizadas está selecionada.
2. Em uma máquina com sistema operacional semelhante, mas conectado à Internet, defina o sinalizador keepcache = 1 no arquivo /etc/yum.conf e o httpd com todas as dependências está instalado:
yum install httpd
Se esse comando não funcionar, você precisará adicionar à lista de repositórios yum um repositório que contenha esses pacotes, por exemplo, este é
centos.excellmedia.net/7/os/x86_64 :
echo -e "\n[centos.excellmedia.net]\nname=excellmedia\nbaseurl=http://centos.excellmedia.net/7/os/x86_64/\nenabled=1\ngpgcheck=0" > /etc/yum.repos.d/excell.repo
Depois disso,
usando o comando
yum repolist , verificamos que o repositório foi exibido - um repositório adicionado deve aparecer na lista de repositórios (repo id - centos.excellmedia.net; repo name - excellmedia).
Agora verifique se o yum viu os pacotes que precisamos:
yum list | grep httpd
Se a saída contiver os pacotes necessários, você poderá instalá-los com o comando acima.
3. Para criar o repositório yum, precisamos do pacote createrepo. Também está no repositório acima e é definido da mesma forma:
yum install createrepo
4. Como eu disse antes, os serviços CDH exigem um banco de dados para funcionar. Instale o PostgreSQL para estes propósitos:
yum install postgresql-server
5. Um dos pré-requisitos para a operação correta do CDH é a sincronização de horário em todos os servidores incluídos no cluster. Para esses propósitos, o pacote
chronyd é
usado (nos sistemas operacionais em que eu tive que implantar o CDH, ele foi instalado por padrão). Verifique sua disponibilidade:
chronyd -v
Se não estiver instalado, instale:
yum install chrony
Se instalado, faça o download:
yumdownloader --destdir=/var/cache/yum/x86_64/7Server/<repo id>/packages chrony
6. Ao mesmo tempo, baixe imediatamente os pacotes necessários para instalar o CDH. Eles estão disponíveis em
archive.cloudera.com -
archive.cloudera.com/cm <versão principal do CDH> / <nome do seu sistema operacional> / <versão do seu sistema operacional> / x86_64 / cm / <versão completa do CDH> / RPMS / x86_64 /. Você pode baixar pacotes manualmente (cloudera-manager-server e cloudera-manager-daemons) ou adicionar um repositório por analogia e instalá-los:
yum install cloudera-manager-daemons cloudera-manager-server
7. Após a instalação, os pacotes e suas dependências são armazenados em cache na pasta / var / cache / yum / x86_64 / 7Server / \ <repo id \> / packages. Nós os transferimos para a máquina selecionada para o servidor HTTP e as distribuições e instalamos:
rpm -ivh < >
8. Execute o httpd, torne-o visível a partir de outros hosts em nosso cluster e adicione-o à lista de serviços que são iniciados automaticamente após o carregamento:
systemctl start httpd systemctl enable httpd systemctl stop firewalld
9. Agora temos um servidor HTTP funcionando. Seu diretório de trabalho é
/ var / www / html . Crie duas pastas nele - uma para o repositório yum e a outra para os analisadores Cloudera (mais sobre isso mais tarde):
cd /var/www/html mkdir yum_repo parcels
10. Para os serviços da Cloudera, precisamos de
Java . Todas as máquinas requerem a mesma versão do JDK instalada; Cloudera recomenda o Hot Spot da Oracle. Faça o download do pacote de distribuição no site oficial (http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html) e transfira-o para a pasta
yum_repo .
11. Crie o repositório yum na pasta yum_repo usando o utilitário createrepo para que o pacote JDK esteja disponível para instalação nas máquinas de cluster:
createrepo -v /var/www/html/yum_repo/
12. Depois de criar nosso repositório local em cada um dos hosts, você precisa adicionar sua descrição, semelhante ao parágrafo 2:
echo -e "\n[yum.local.repo]\nname=yum_repo\nbaseurl=http://< httpd>/yum_repo/\nenabled=1\ngpgcheck=0" > /etc/yum.repos.d/yum_repo.repo
Você também pode fazer verificações semelhantes ao parágrafo 2.
13. O JDK está disponível, instale:
yum install jdk1.8.0_161.x86_64
Para usar Java, você precisa configurar a variável JAVA_HOME. Eu recomendo que você exporte-o imediatamente após a instalação, bem como
grave-o nos arquivos / etc / environment e
/ etc / default / bigtop-utils, para que seja exportado automaticamente após a reinicialização dos servidores e sua localização seja fornecida aos serviços CDH:
export JAVA_HOME=/usr/java/jdk1.8.0_161 echo "JAVA_HOME=/usr/java/jdk1.8.0_161" >> /etc/environment export JAVA_HOME=/usr/java/jdk1.8.0_144 >> /etc/default/bigtop-utils
14. Da mesma maneira, instale o chronyd em todas as máquinas do cluster (a menos que, é claro, esteja ausente):
yum install chrony
15. Selecione o host no qual o PostgreSQL funcionará e instale-o:
yum install postgresql-server
16. Da mesma forma, selecione o host no qual o Cloudera Manager será executado e instale-o:
yum install cloudera-manager-daemons cloudera-manager-server
17. Os pacotes estão instalados, você pode começar a configurar o software antes da instalação.
Adição:
Durante o desenvolvimento e operação do sistema, você precisará adicionar pacotes ao repositório yum para instalá-los nos hosts do cluster (por exemplo, distribuição Anaconda). Para fazer isso, além de transferir os arquivos para a pasta yum_repo, é necessário executar as seguintes ações:
Configurando Software Auxiliar
É hora de configurar o PostgreSQL e criar bancos de dados para nossos futuros serviços. Essas configurações são relevantes para o CDH versão 5.12.1. Ao instalar outras versões da distribuição, é recomendável que você leia a seção "Armazenamento de dados do Cloudera Manager e Managed Service Datastores" no site oficial.
Para começar, vamos inicializar o banco de dados:
postgresql-setup initdb
Agora configuramos a interação da rede com o banco de dados. No arquivo
/var/lib/pgsql/data/pg_hba.conf na seção de conexões locais IPv4, altere o método para o endereço 127.0.0.1/32 para o método md5, adicione o método trust e a sub-rede do cluster com o método trust :
vi /var/lib/pgsql/data/pg_hba.conf pg_hba.conf:
Em seguida, faremos alguns ajustes no arquivo /var/lib/pgsql/data/postgres.conf (darei apenas as linhas que precisam ser alteradas ou verificadas quanto à conformidade:
vi /var/lib/pgsql/data/postgres.conf postgres.conf: ----------------------------------------------------------------------- listen_addresses = '*' max_connections = 100 shared_buffers = 256MB checkpoint_segments = 16 checkpoint_completion_target = 0.9 logging_collector = on log_filename = 'postgresql-%a.log' log_truncate_on_rotation = on log_rotation_age = 1d log_rotation_size = 0 log_timezone = 'W-SU' datestyle = 'iso, mdy' timezone = 'W-SU' lc_messages = 'en_US.UTF-8' lc_monetary = 'en_US.UTF-8' lc_numeric = 'en_US.UTF-8' lc_time = 'en_US.UTF-8' default_text_search_config = 'pg_catalog.english' -----------------------------------------------------------------------
Após a conclusão da configuração, você precisa criar bancos de dados (para aqueles que estão mais próximos da terminologia Oracle - esquemas) para os serviços que instalaremos. No nosso caso, os seguintes serviços foram instalados: Serviço de Gerenciamento Cloudera, HDFS, Hive, Hue, Impala, Oozie, Yarn e ZooKeeper. Destas, Hive, Hue e Oozie precisam de bancos de dados e são necessárias duas bases para as necessidades dos serviços Cloudera - uma para o servidor Cloudera Manager e a outra para o gerenciador de relatórios, que faz parte do Cloudera Management Service. Inicie o PostgreSQL e adicione-o ao carregamento automático:
systemctl start postgresql systemctl enable postgresql
Agora podemos conectar e criar os bancos de dados necessários:
sudo -u postgres psql > CREATE ROLE scm LOGIN PASSWORD '<password>'; > CREATE DATABASE scm OWNER scm ENCODING 'UTF8'; # Cloudera Manager > CREATE ROLE rman LOGIN PASSWORD '<password>'; > CREATE DATABASE rman OWNER rman ENCODING 'UTF8'; # > CREATE ROLE hive LOGIN PASSWORD '<password>'; > CREATE DATABASE metastore OWNER hive ENCODING 'UTF8'; # Hive Metastore > ALTER DATABASE metastore SET standard_conforming_strings = off; # PostgreSQL 8.2.23 > CREATE ROLE hue_u LOGIN PASSWORD '<password>'; > CREATE DATABASE hue_d OWNER hue_u ENCODING 'UTF8'; # Hue > CREATE ROLE oozie LOGIN ENCRYPTED PASSWORD '<password>' NOSUPERUSER INHERIT CREATEDB NOCREATEROLE; > CREATE DATABASE "oozie" WITH OWNER = oozie ENCODING = 'UTF8' TABLESPACE = pg_default LC_COLLATE = 'en_US.UTF-8' LC_CTYPE = 'en_US.UTF-8' CONNECTION LIMIT = -1; # Oozie : > \q
Para outros serviços, os bancos de dados são criados da mesma maneira.
Não se esqueça de executar o script para preparar o banco de dados do servidor Cloudera Manager, passando os dados de entrada para conectar-se ao banco de dados criado para ele:
. /usr/share/cmf/schema/scm_prepare_database.sh postgresql scm scm <password>
Criando um repositório com arquivos CDH
O Cloudera fornece 2 maneiras de instalar o CDH - usando pacotes e usando pacotes. A primeira opção envolve o download de um conjunto de pacotes com serviços das versões necessárias e sua instalação subsequente. Este método fornece grande flexibilidade na configuração do cluster, mas o Cloudera não garante sua compatibilidade. Portanto, a segunda versão da instalação usando parsels é mais popular - conjuntos pré-formados de pacotes de versões compatíveis. As versões mais recentes estão disponíveis no seguinte link: archive.cloudera.com/cdh5/parcels/latest . Anteriormente, pode ser encontrado um nível superior. Além do parsel do CDH, você precisa fazer o download do manifest.json do mesmo diretório do repositório.
Para usar a funcionalidade desenvolvida, também precisamos do Spark 2.2, que não está incluído no pacote CDH (a primeira versão deste serviço está disponível lá). Para instalá-lo, é necessário fazer o download de um pacote separado com este serviço e o manifest.json correspondente, também disponível no arquivo Cloudera .
Depois de carregar os parsels e manifest.json, você precisa transferi-los para as pastas apropriadas em nosso repositório. Crie pastas separadas para arquivos CDH e Spark:
cd /var/www/html/parcels mkdir cdh spark
Transfira os arquivos parsels e manifest.json para as pastas criadas. Para disponibilizá-los para instalação na rede, emitimos a pasta de permissões de acesso correspondente com parsels:
chmod -R ugo+rX /var/www/html/parcels
Você pode começar a instalar o CDH, que discutirei no próximo post.