Recentemente, dei uma palestra no LA Hadoop User Group sobre o que fazer e o que não fazer no Apache HBase. O público foi excelente e teve perguntas muito informadas e bem articuladas. Jody do Shopzilla foi um excelente anfitrião e devo muito a ele por dar a oportunidade de falar com mais de 60 Hadoopers de LA. Como nem todo mundo mora em Los Angeles ou pode comparecer ao encontro, resumi alguns pontos importantes aqui. Para aqueles de vocês com um dia agitado, aqui está o tl;dr:
- HBase é bom, mas não substitui RDBMS ou HDFS
- Boa configuração significa boa operação
- Monitor monitor monitor monitor monitor
Nós da Cloudera somos grandes fãs do HBase. Adoramos a tecnologia, adoramos a comunidade e descobrimos que é uma ótima opção para muitas aplicações. Os usos bem-sucedidos do HBase foram bem documentados e, como resultado, muitas organizações estão considerando se o HBase é uma boa opção para alguns de seus aplicativos. O impulso para minha palestra e esta postagem de blog de acompanhamento é esclarecer alguns dos bons aplicativos para o HBase, alertar contra alguns aplicativos ruins e destacar etapas importantes para uma implantação bem-sucedida do HBase.
Quando usar o HBase
A consideração mais importante ao analisar o HBase é que, embora seja uma ótima solução para muitos problemas, não é uma bala de prata. O HBase não é otimizado para aplicativos transacionais clássicos ou mesmo para análises relacionais. Também não é um substituto completo para HDFS ao fazer MapReduce em lotes grandes. Dê uma olhada em alguns dos casos de uso neste post para ter uma ideia de quais aplicativos são adequados para o HBase e se você tiver dúvidas, vá em frente e poste nas listas. Já mencionei que a comunidade é fantástica?
Com essa ressalva fora do caminho – por que você deve usar o HBase? Se o seu aplicativo tiver um esquema de variável em que cada linha é um pouco diferente, você deve examinar o HBase. Como exemplo, fazer um exercício de modelagem usando um esquema relacional padrão; Quando você não pode adicionar colunas com rapidez suficiente e a maioria delas é NULL em cada linha, você deve considerar o HBase. Se você achar que seus dados estão armazenados em coleções, por exemplo, alguns metadados, dados de mensagens ou dados binários que são todos inseridos no mesmo valor, você deve considerar o HBase. Se você precisar de acesso baseado em chave aos dados ao armazenar ou recuperar, considere o HBase.
Serviços de suporte
Supondo que você esteja convencido de que o HBase é adequado para seu aplicativo, aqui estão algumas dicas que você precisa considerar ao implantá-lo. Existem alguns serviços de suporte que são importantes e um que é necessário. Se você ainda não viu o ZooKeeper, agora é a hora. O HBase usa o ZooKeeper para vários serviços de coordenação distribuídos, como eleição de mestre. À medida que o HBase se desenvolve e cresce, ele continua a depender do ZooKeeper para obter funcionalidades adicionais, tornando-o uma parte essencial do sistema. Além disso, você deve ter serviços de rede adequados, como NTP e DNS. O HBase depende de todos os nós do cluster terem relógios bem sincronizados e se referirem uns aos outros de forma consistente. O uso de NTP e DNS garante que você não se depare com comportamentos estranhos quando um nó A pensa que a hora é amanhã e o nó B pensa que é ontem. Você também evitará situações em que o nó mestre diz ao nó C para atender a uma região, mas o nó C não sabe seu próprio nome e não responde. O uso de NTP e DNS economizará muitas dores de cabeça quando você começar.
Eu disse que a consideração mais importante ao selecionar o HBase é garantir que você tenha um caso de uso adequado. A coisa mais importante a fazer ao usar o HBase é monitorar o sistema. O monitoramento é fundamental para o sucesso das operações do HBase. Como é o caso de muitos sistemas distribuídos, o HBase é suscetível a falhas em cascata. Se um nó começar a trocar, ele pode perder contato com o mestre, fazendo com que outro servidor pegue a carga e fique sobrecarregado. Esse segundo servidor falhará e a falha ocorrerá em cascata. Você precisa monitorar a memória, a CPU, a E/S e a latência e largura de banda da rede em cada um de seus nós HBase para garantir que eles estejam operando dentro de parâmetros íntegros. O monitoramento é a prática mais importante para operar um cluster HBase íntegro.
Boas práticas para arquitetura HBase
Avance rapidamente para seu cluster HBase bem monitorado executando um caso de uso perfeito, aqui estão algumas boas práticas. Use um prefixo de chave que distribua bem com base em seu caso de uso. Se você prefixar sua chave por carimbo de data/hora ou qualquer valor semelhante que, quando classificado, é armazenado ou consultado em um lote, provavelmente sobrecarregará cada servidor de região em vez de distribuir uniformemente a carga. Você também deve manter o número de regiões em um número razoável com base no tamanho do memstore e na quantidade de RAM e a JVM RegionServer deve ser limitada a 12 GB de heap java para minimizar longas pausas de GC. Por exemplo, uma máquina com 36 GB de RAM que também executa um daemon DataNode pode lidar com aproximadamente 100 regiões com gravações ativas e um memstore de 48 MB cada. Isso permite espaço suficiente para os requisitos de memória DataNode e RegionServer, espaço de buffer de arquivo Linux e um tamanho de liberação razoável para cada RegionServer.
Algumas recomendações de configuração incluem desabilitar a compactação automática (por padrão, isso acontece a cada 24 horas a partir do momento em que você inicia HBase) e programe-o para ser executado todos os dias em um horário fora de pico. Você também deve configurar a compactação (como LZO) e colocar explicitamente o diretório conf do HBase configurado corretamente em seu CLASSPATH.
O que não fazer no HBase
Cobrimos uma ampla gama de boas práticas para o HBase. Existem também alguns padrões de uso a serem evitados. Por exemplo, não espere usar o HBase como um substituto por atacado para cada um de seus bancos de dados relacionais. O HBase é ótimo em muitas coisas, mas não substitui os bancos de dados relacionais. Para começar, ele não fala SQL, não possui um otimizador, não suporta transações de registro cruzado ou junções. Se você não usa nenhum desses em seu aplicativo de banco de dados, o HBase pode muito bem ser o ajuste perfeito.
Tenha cuidado ao executar cargas de trabalho mistas em um cluster HBase. Quando você tiver SLAs no acesso ao HBase independente de qualquer tarefa MapReduce (por exemplo, uma transformação no Pig e fornecer dados do HBase), execute-os em clusters separados. O HBase é intensivo em CPU e memória com acesso de E/S sequencial grande esporádico, enquanto os trabalhos MapReduce são principalmente vinculados a E/S com memória fixa e CPU esporádica. Combinados, eles podem levar a latências imprevisíveis para HBase e contenção de CPU entre os dois. Um cluster compartilhado também requer menos slots de tarefa por nó para acomodar os requisitos de CPU do HBase (geralmente metade dos slots em cada nó que você alocaria sem o HBase). Fique de olho também na troca de memória. Se o HBase começar a trocar, há uma boa chance de que ele perca uma pulsação e seja descartado do cluster. Em um cluster ocupado, isso pode sobrecarregar outra região, causando troca e uma cascata de falhas.
Considerações finais
Um último conselho antes de resumir. Ao carregar o HBase, use HFileOuputFormat se estiver carregando por meio de um trabalho MapReduce ou uma coleção de servidores usando puts em lote. O carregamento com um único cliente causará gargalos nesse cliente e não aproveitará a escalabilidade oferecida pelo HBase.
Em resumo, considere o HBase quando estiver carregando dados por chave, pesquisando dados por chave (ou intervalo), servindo dados por chave, consultando dados por chave ou ao armazenar dados por linha que não estejam em conformidade com um esquema.
Casos de uso
- Apache HBase:desenvolvido pelo HBase Wiki
- Mozilla:movendo o Socorro para o HBase
- Facebook:o novo sistema de mensagens em tempo real do Facebook:HBase
- StumbleUpon:HBase no StumbleUpon
