Apache Impala: My Insights and Best Practices

>>

Usamos Impala para alguns fins:

• Deixe que os analistas consultem novos tipos de dados que os engenheiros de dados ainda não criaram nenhum ETL.
• Deixe que os analistas consultem dados que seu destino final (após o processo ETL) seja HDFS.
• Geração de relatórios (com nossas próprias ferramentas).
• Monitoramento &Sistemas de alerta (sobre novos dados que estão chegando a cada hora).

Temos dezenas de milhares de consultas por dia, cada consulta escaneia em média alguns gigabytes de dados e leva 10 segundos. O nosso cluster não é enorme em termos de hardware e número de nós que temos. Sem mencionar que temos centenas de outros fluxos de trabalho (Faísca, Porco, Colmeia) rodando todos os dias no mesmo cluster.

Neste artigo vou compartilhar o conhecimento e as conclusões que aprendemos com nosso projeto de otimização Impala.

O que é Impala?

Se você não sabe o que é – leia sobre isso no Cloudera Impala Guide, e depois volte aqui para as coisas interessantes.

Impala Vs. Outras Soluções SQL-on-Hadoop

Não há nada para comparar aqui. Hoje em dia, a Colmeia é apenas para ETLs e processamento de lotes. Os seus analistas terão a sua resposta muito mais rapidamente utilizando a Impala, embora, ao contrário da Colmeia, a Impala não seja tolerante a falhas. Mas não há problema para um motor MPP (Massive Parallel Processing).

Impala é mais rápido que a Colmeia porque é um motor totalmente diferente e a Colmeia está sobre o MapReduce (que é muito lento devido às suas demasiadas operações de E/S em disco).

Impala Vs. SparkSQL

Yes, SparkSQL é muito mais rápido que a Colmeia, especialmente se executa apenas computações in-memory, mas o Impala ainda é mais rápido que o SparkSQL.

É mais rápido porque o Impala é um motor desenhado especialmente para a missão de SQL interactivo sobre HDFS, e tem conceitos de arquitectura que o ajudam a conseguir isso. Por exemplo, os daemons ‘always-on’ do Impala estão a funcionar e à espera de consultas 24/7 – algo que não faz parte do SparkSQL. E mais algumas razões como o mecanismo codegen do Impala, a optimização do formato Parquet, estatísticas, cache de metadados, etc.

O JDBC/ODBC Thrift Server do SparkSQL pode ser um concorrente comparável ao Impala, mas como eu não consegui encontrar muito sobre ele na web – vou apenas dizer aqui e se você tem algum conhecimento e experiência sobre este assunto, por favor escreva um post médio sobre ele. Talvez eu escreva um num futuro próximo.

Impala Vs. Presto

Presto é uma tecnologia muito similar com arquitetura similar. De acordo com quase todos os benchmarks da web – o Impala é mais rápido que o Presto, mas o Presto é muito mais plugável que o Impala. Impala supõe ser mais rápido quando você precisa de SQL sobre Hadoop, mas se você precisa consultar várias fontes de dados com o mesmo mecanismo de consulta – Presto é melhor do que Impala. Basta ver esta lista de Conectores Presto. Impala também pode consultar o Amazon S3, Kudu, HBase e é basicamente isso.

Para ler mais sobre Presto- este é um PrestoDB revisão completa que eu fiz.

Impala Best Practices

Impala executa melhor quando consulta arquivos armazenados como formato Parquet. Toda a tecnologia em que o Cloudera Impala se baseia vem do Whitepaper do Google Dremel e nesse artigo você pode encontrar o conceito em que o Parquet se baseia. Portanto, lembre-se apenas de não consultar arquivos json, csv ou seqüência – parquet seus arquivos antes de deixar os analistas consultá-los.

Work With Partitions

Particionar seus dados de acordo com as consultas dos seus analistas. A Impala não tem nenhum índice, então essa é a única maneira de reduzir a quantidade de dados que você processa em cada consulta. Nós usamos DT (date time) como o principal método de particionamento para a maioria de nossas tabelas. O sobre particionamento pode ser perigoso (continue lendo para mais detalhes).

A declaração REFRESH

A declaração REFRESH pode ser uma operação cara, especialmente se você tiver milhares de tabelas com dados adicionados a elas a cada hora. Executamos mais de 10.000 actualizações por dia. Essas são as minhas melhores práticas para atualizações:

• Desde Impala 2.7 você pode fazer uma atualização em uma partição específica, use isso para tornar o comando REFRESH muito mais leve.
• Hot & Arquivada arquitetura de tabelas – cada tabela terá uma versão hot e uma versão arquivada. A versão hot terá as últimas 24 horas e uma atualização nessa tabela ocorrerá a cada hora e será muito mais leve. A cada dia a tabela quente será unida à tabela arquivada e um refresh mais pesado sobre aquela tabela ocorrerá. E, claro, uma VISÃO acima daquelas 2 que as une para que os usuários nem mesmo estejam cientes disso.
• Não tenha muitos metadados (arquivos e partições) por tabela (veja a seção ‘Tamanho Ótimo do Arquivo’).

Estatísticas de Cálculo

Estatisticas tornarão suas consultas muito mais eficientes, especialmente as que envolvem mais de uma tabela (joins). Portanto, você deve calcular as estatísticas de todas as suas tabelas e manter um fluxo de trabalho que as mantenha atualizadas com estatísticas incrementais. Para mais detalhes técnicos leia sobre a Tabela Impala da Cloudera e as Estatísticas das Colunas.

Optimal File Size – 256MB/File

TL;DR: Certifique-se de que não tem demasiados ficheiros pequenos – vai prejudicar muito o seu servidor de catálogos, actualizações e desempenho das suas consultas.

Notamos que o nosso servidor de catálogos Impala continua a falhar 4 vezes por semana e que as nossas consultas demoraram muito tempo. Então percebemos que temos muitos arquivos e partições. Estávamos trabalhando com partições DT de hora em hora, não importa o tamanho das partições.

Assim, após 2 anos, tínhamos tabelas com 17GB de dados e 17.000 partições – o que significa que cada partição tem cerca de 1mb. Tivemos tabelas com partições do tamanho de 50KB. E se isso não for suficiente, algumas dessas partições pequenas tinham vários arquivos nelas.

No início pensamos que essa quantidade desarrazoada de arquivos só está fazendo com que nossos metadados sejam muito grandes e é por isso que as atualizações são tão pesadas e o servidor de catálogo está falhando. Mas então percebemos que a quantidade de arquivos também afeta muito a performance da nossa consulta (porque o número de threads do scanner necessários para ler tantos arquivos de parquet).

Quão mal? Nós fizemos um teste em uma tabela real de 500MB que temos, com 17.280(!) partições e arquivos. Criamos uma nova versão mesclada desta tabela com apenas 2 arquivos, 1 por ano. A parte do SCAN HDFS no resumo de execução da consulta foi 2.000 vezes mais rápida. Essa foi a parte que entendemos o quanto nossos pequenos arquivos estão nos prejudicando.

Então começamos a gerenciar nossas partições e fundi-las no tamanho ideal do arquivo que é cerca de 256mb.

Tabelas com particionamento de hora em hora tornaram-se particionadas diariamente, mensalmente ou anualmente. Cada partição tem apenas 1 arquivo (a menos que seu tamanho seja > 256mb)

Configure Coordinators & Executors Per Daemon

Desde Impala 2.9 você pode determinar quais daemons impala são coordenadores e quais são executores. Isso é uma enorme mudança porque antes disso – todos os daemons eram coordenadores e executores e a sobrecarga de ser um coordenador é muito consumidora de recursos para grandes clusters.

Significa, por exemplo, que cada nó mantém todo o cache de metadados em sua RAM. E se você tiver, por exemplo, 20GB de metadados e 50 nós – isso significa um desperdício de 1TB de RAM só porque todos os nós também são coordenadores!

Teste qual é a melhor taxa de coordenadores/executores para você e use-a. Dica: comece com 2 coordenadores por cluster.

Tipos de dados das colunas

No início usamos STRING para todas as nossas colunas em todas as tabelas. É uma prática muito ruim que prejudica muito o desempenho. Você deve tentar escolher o tipo mais adequado à coluna entre todos os tipos de dados que a Impala suporta.

Impala Query Limits

Você deve usar o Impala Admission Control para definir diferentes pools para diferentes grupos de usuários, a fim de limitar o uso de alguns usuários a X consultas simultâneas ou memória Y. Mas ainda mais do que isso – nós construímos nosso próprio sistema para lidar com usuários e consultas problemáticas.

Nosso sistema mostra as consultas atualmente em execução a cada 10 segundos e se uma consulta estiver em execução por mais de 30 minutos – ela está sendo morta. Se o mesmo template de consulta foi morto 90% das vezes no mês passado porque demorou mais de 30 minutos – nosso sistema irá matá-lo imediatamente ao reconhecer o template, a fim de proteger a nossa infra-estrutura.

Morte de consultas não é um conceito novo – Amazon Athena fez isso antes de nós, mas matar consultas somente por padrão problemático – isso é algo que ninguém mais faz e essa é a única maneira de lidar com milhares de analistas famintos.

Sumário

Se você precisar deixar seus analistas realizarem consultas SQL ad-hoc interativas sobre o seu Hadoop – Impala é uma ótima solução. Você deve ler o Guia Impala da Cloudera para se tornar um administrador Impala realmente bom e lembre-se de trabalhar com as melhores práticas que eu expliquei aqui.