Revisão do Google Hadoop (dataproc)

Há algum tempo, ativei uma avaliação gratuita no Google para a nuvem deles, não resolvi meu problema, o Google concedeu US $ 300 por 12 meses para uma avaliação, mas, contrariamente às minhas expectativas, outros limites são impostos além do limite de orçamento. Por exemplo, não permiti o uso de máquinas virtuais com mais de 8 vcpu em uma região. Depois de meio ano, decidi usar o orçamento de avaliação para me familiarizar com o dataproc, um cluster de hadup pré-instalado do Google. A tarefa é tentar avaliar como seria fácil lançar um projeto no acesso do Google, se faz sentido ou é melhor me concentrar imediatamente no meu hardware e pensar na administração. Tenho a vaga sensação de que o hardware e as grandes datas modernos devem se adaptar facilmente a pequenos bancos de dados de dezenas ou centenas de GB, carregando brutalmente, se não todo o conjunto de dados, e a grande maioria na memória do cluster. Alguns subdados separados para data marts podem não ser mais necessários.

Em resumo, o dataproc ficou impressionado com a facilidade de inicialização e configurações, comparado ao Oracle e Cloudera. No primeiro estágio, joguei com um cluster de nós em 8 vCpu, o máximo dos quais permite uma avaliação totalmente gratuita. Se você observar a simplicidade, a tecnologia deles já permite que um hindu inicie um cluster em 15 minutos, carregue dados de amostra e prepare relatórios usando uma ferramenta de BI comum, sem sub-janelas intermediárias. Algum conhecimento profundo de Hadoup não é mais necessário.

Em princípio, vi que a coisa é maravilhosa para um início rápido e, com um bom dinheiro, você pode executar um protótipo, avaliar o tipo de hardware necessário para uma tarefa. No entanto, um cluster maior, em dezenas de nós, obviamente consumirá muito mais do que um aluguel + alguns administradores que estão olhando para o cluster. Longe do fato de que a nuvem parecerá economicamente viável. A primeira etapa, tentei avaliar uma opção completamente micro com um cluster de nó 8 vCpu e 0,5 TB de dados brutos. Em princípio, os testes spark + hadoop em clusters maiores já estão completos na Internet, mas pretendo testar a opção um pouco maior posteriormente.

Em apenas uma hora, pesquisei os scripts para criar um backup de cluster, configurar seu firewall e configurar um servidor de poupança, que permitia ao jdbc se conectar ao spark sql no Windows doméstico. Passei mais duas ou três horas otimizando as configurações padrão do spark e carregando algumas pequenas tabelas com cerca de 10 GB de tamanho (o tamanho dos arquivos de dados no Oracle). Coloquei as tabelas inteiras na memória (altere o cache da tabela;) e foi possível trabalhar com elas na máquina Windows do Dbeaver e Tableau (por meio do conector spark sql).

Por padrão, o spark usou apenas 1 executor em 4 vCpu, editei o spark-defaults.conf, instalei 3 executores, 2 vCpu cada e por um longo tempo não entendi por que realmente só tenho 1 executor no meu trabalho. Aconteceu que eu não editei a memória, os outros dois fios simplesmente não conseguiram alocar memória. Defina 6,5 ​​GB no executor, após o qual todos os três começaram a aumentar conforme o esperado.
Em seguida, decidi jogar com um volume um pouco mais sério e uma tarefa mais próxima do DWH dos testes TPC-DS. Para iniciantes, eu gerava oficialmente tabelas com um fator de escala 500 da ferramenta oficial.Eu obtive algo como 480 GB de dados brutos (texto delimitado). O teste TPC-DS é um DWH típico, com fatos e dimensões. Não entendi como gerar dados diretamente no armazenamento do google, tive que gerar máquinas virtuais no disco e copiá-las para o armazenamento do google. O Google, pelo que entendi, acredita que o exaustor funciona perfeitamente com o armazenamento do Google e a velocidade promete um pouco melhor do que se os dados estivessem dentro do cluster no HDFS. Nesse caso, parte da carga vai do HDFS para o armazenamento do Google.

Após conectar-me através do Dbeaver, converti os arquivos de texto em tablets baseados em parquet com empacotamento rápido usando comandos SQL. 480 GB de dados de texto compactados em arquivos parquet de 187 GB. O processo levou cerca de duas horas, a maior tabela do texto ocupava 188 GB, três executores de faísca os transformaram em parquet em 74 minutos, o tamanho do SUV era de 66,8 GB. Na minha área de trabalho, com aproximadamente os mesmos 8 vCpu (i7-3770k), acho que “inserir na tabela selecione * ...” em uma tabela Oracle com um bloco de 8k levaria um dia, e quanto o arquivo de dados levaria é assustador de se imaginar.



Em seguida, verifiquei o desempenho das ferramentas de BI nessa configuração e criei um relatório simples no Tableua



Quanto às consultas, Query1 do teste TPC-DS


concluída em 1:08, Query2 com a participação das maiores tabelas (catalog_sales, web_sales)


concluída em 4:33 minutos, Query3 em 3,6, Query4 em 32 minutos.

Se alguém estiver interessado nas configurações, abaixo do recorte minhas anotações sobre a criação de um cluster. Em princípio, existem apenas alguns comandos do gcloud e a configuração HIVE_SERVER2_THRIFT_PORT.


Para continuar ...