Esta postagem do blog foi publicada no Hortonworks.com antes da fusão com a Cloudera. Alguns links, recursos ou referências podem não ser mais precisos.
Agradecimentos especiais a Bill Preachuk e Brandon Wilson por revisar e fornecer seus conhecimentos
Introdução
O armazenamento colunar é um tópico frequentemente discutido no mundo de processamento e armazenamento de big data hoje – existem centenas de formatos, estruturas e otimizações nos quais você pode armazenar seus dados e ainda mais maneiras de recuperá-los, dependendo do que você planeja fazer com isso. Essa infinidade de opções surgiu devido à necessidade não só de ingerir dados rapidamente usando ferramentas de Processamento Transacional On-Line (OLTP), mas também pela necessidade de consumir e analisar dados com maior eficiência usando Processamento Analítico On-Line (OLAP) Ferramentas. Milhares de casos de uso diferentes, cada um tem suas próprias necessidades específicas e, portanto, muitas opções surgiram. Por exemplo, ler os dados do ticker do mercado de ações requer uma mentalidade completamente diferente da análise de métricas de qualidade em uma linha de fabricação. Com todas essas opções, é fácil se perder ao navegar para seu objetivo final:escolher uma ferramenta que funcione para você.
O HDP incorpora várias soluções de armazenamento, cada uma feita sob medida para casos de uso específicos. Queremos iniciar esta série de blogs falando sobre as três ferramentas/motores a seguir e seus formatos de armazenamento associados:
- O Apache Hive usa o Apache ORC como um formato de armazenamento colunar eficiente que permite desempenho para processamento de consultas OLAP e SQL profundo
- Apache Phoenix/Apache HBase juntos formam um banco de dados OLTP que permite consultas em tempo real em bilhões de registros e oferece pesquisas aleatórias rápidas baseadas em chaves, bem como atualizações
- Apache Druid é um armazenamento de dados de alto desempenho que permite análises de séries temporais em tempo real em fluxos de eventos e análises OLAP sobre dados históricos com latência extremamente baixa
Neste artigo, pretendemos articular qual ferramenta é apropriada para um determinado caso de uso, comparar e contrastar as várias ferramentas e fornecer uma diretriz básica para escolher a ferramenta ou conjunto de ferramentas apropriado para atender ao seu caso de uso.
Isso é como jogar Tetris – cada peça tem um nicho diferente, mas cada uma delas adiciona valor único à estrutura maior
Processamento de Big Data e suas semelhanças
Os dados são agrupados por colunas no armazenamento porque muitas vezes estamos tentando restringir somas, médias ou outros cálculos em uma coluna específica. Imagine que você é uma companhia aérea tentando entender quanto combustível fornecer a um avião quando ele está ancorado – você pode querer calcular a média de milhas voadas por cada voo a partir de uma tabela de dados de viagem de voo. Isso exigiria a execução da função média em uma única coluna. Armazenaríamos esses dados em formato colunar porque as leituras sequenciais no disco são rápidas, e o que queremos fazer nesse caso é ler uma coluna inteira da tabela sequencialmente (e depois realizar um cálculo médio).
Existem muitas diferenças entre esses mecanismos, mas independentemente de qual mecanismo de processamento de dados você escolher, você se beneficiará de alguns pontos em comum. Um deles é o recurso compartilhado de cache. Cada um desses três mecanismos trabalha lado a lado com o cache na memória para melhorar o desempenho de seu processamento sem alterar o formato de armazenamento de back-end, alcançando tempos de resposta de menos de um segundo. O HBase tem o BlockCache, o Hive tem a camada LLAP IO e o Druid tem várias opções de cache na memória. Muitas vezes, a parte cara de atender a uma consulta envolve analisar a solicitação e ir ao armazenamento persistente para recuperar o subconjunto de dados no qual o usuário está interessado. Essa etapa inteira, no entanto, pode ser evitada ao usar um mecanismo de cache na memória como muitos formatos de armazenamento colunar uso, permitindo que o processo alcance a memória para dados consultados anteriormente em frações de segundo. Vamos voltar ao nosso exemplo de cálculo de combustível:digamos que acabei de pedir a média de milhas voadas para todos os voos da minha empresa, mas percebo que os voos domésticos terão requisitos de combustível muito diferentes dos voos internacionais. Em seguida, vou querer filtrar minha consulta anterior com uma cláusula WHERE country='US' (ou código de país equivalente). Esse padrão de consulta é muito comum para exploração de dados. Como já temos os dados da consulta anterior na memória, os resultados dessa consulta podem ser retornados sem a necessidade de realizar uma leitura de disco cara.
A estrutura da camada LLAP do Hive – parte de seu espaço de memória é usado para armazenamento em cache, enquanto o armazenamento de longo prazo está em HDFS. HBase e Druid também têm um conceito semelhante de cache e armazenamento.
Outra semelhança existe nos atalhos que cada um desses mecanismos usa para se concentrar nos dados específicos que estão sendo consultados. O HBase tem acesso aleatório O(1) baseado em HashMap, o Druid usa índices de bitmap invertidos para descobrir quais valores de coluna estão em quais linhas e as tabelas Hive têm estatísticas, índices e particionamento para acesso a dados de atalho. Esses recursos permitem que os mecanismos combinem a maneira como os dados são armazenados com a maneira como são acessados, permitindo análises rápidas, otimizando a eficiência do hardware e aproveitando ao máximo a CPU e a RAM disponíveis.
A última semelhança é a prontidão empresarial de cada um desses mecanismos. No lado da redundância de dados, todos esses três mecanismos usam HDFS como mecanismo de armazenamento profundo; o fator de replicação HDFS de 3x garante que as cópias dos dados existam em outro lugar, mesmo que dois nós falhem simultaneamente. Os dados podem ser replicados imediatamente novamente para nós íntegros para manter a redundância. No tópico de tolerância a falhas em um cluster, cada ferramenta preenche a lacuna de alguma forma. O HBase oferece replicação de região, o Druid tem duplicação de componentes mestre e de trabalho, bem como maior fator de replicação no HDFS, e o Hive tem HDFS juntamente com a lógica tolerante a falhas da estrutura YARN. A prontidão corporativa garante que esses mecanismos sejam resilientes a falhas e estejam prontos para funcionar na produção desde o primeiro dia.
As diferenças entre nossos mecanismos de processamento de Big Data
Qual é a melhor maneira de ingerir dados? Depois de ingerir seus dados, como você extrai rapidamente insights deles? Vamos nos aprofundar em como esses três mecanismos de processamento de big data suportam esse conjunto de tarefas de processamento de dados
Esses mecanismos às vezes são agrupados mentalmente e pensados de maneira semelhante por causa de sua capacidade de armazenar e processar Big Data, mas, como descobriremos, eles são escolhidos para casos de uso e propósitos especificamente adequados aos seus pontos fortes. Você verá que a coleção de ferramentas que a Hortonworks Data Platform contém é adequada para qualquer carga de trabalho de big data que você possa usar, especialmente com HDP 3.0 e os recursos de banco de dados em tempo real que introduzimos.
Hive é o mecanismo OLAP que representa a maior variedade de casos de uso, mais comumente empregando o Hadoop Distributed File System (HDFS) como sua camada de armazenamento para permitir o armazenamento de praticamente qualquer tipo de dados. Ele pode consultar, processar e analisar dados de texto não estruturados, arquivos CSV, XML, JSON semiestruturado, Parquet colunar e vários outros formatos. O Hive também oferece suporte a meios de armazenamento alternativos, como armazenamento em nuvem, Isilon e outros. O padrão de armazenamento de fato para o Hive é o ORC, que otimiza com mais eficiência e colhe os benefícios do armazenamento colunar. Uma vez convertidos para ORC, seus dados são compactados e as colunas em sua tabela são armazenadas sequencialmente no disco, permitindo que a camada de cache na memória LLAP do Hive extraia os dados do disco uma vez e os sirva da memória várias vezes. A combinação de Hive+LLAP é usada para análise ad hoc, cálculo de grandes agregações e relatórios de baixa latência. Um ótimo caso de uso para o Hive é executar um conjunto de relatórios de painel para usuários diariamente; as consultas repetitivas não apenas aproveitam o cache LLAP, mas também o recurso 'Cache de resultados de consulta' - que retorna resultados quase instantâneos se os dados não foram alterados (além:o cache de resultados de consulta é um recurso disponível no Hive 3.0 - lançado em HDP 3.0). Além disso, um Hive Data Warehouse é um ótimo uso da análise ad-hoc de que o Hive é capaz; os usuários podem juntar dados, executar consultas simultâneas e executar transações ACID. Considere o Hive como um valete SQL para todos os negócios a esse respeito, enquanto os outros dois mecanismos fornecem desempenho extremamente rápido para casos de uso de nicho específicos.
Nosso segundo mecanismo, HBase, é um armazenamento de chave-valor distribuído que possui recursos aleatórios de leitura, gravação, atualização e exclusão. O HBase (uma variante NoSQL) foi projetado para ser um mecanismo OLTP, permitindo uma arquitetura de operações transacionais de alto volume – pense em plataformas de mensagens com troca constante de mensagens entre usuários ou transações sendo geradas em um sistema financeiro. O HBase é extremamente eficiente em trazer dados rapidamente, armazená-los e servi-los de volta – inserções/atualizações/exclusões aleatórias de latência ultrabaixa. O que ele não foi projetado para agregar e juntar dados – essa funcionalidade é realizada por meio do Phoenix, uma camada e mecanismo SQL em cima do HBase, mas não é recomendado para grandes quantidades de dados, pois os dados não são estruturados de maneira a atingir o nível ideal. desempenho (use Hive em vez disso). Para resumir, o HBase é ótimo no processamento de grandes volumes de operações Create-Update-Delete, mas fica aquém quando chega a hora de apresentar esses dados em um formato consumível para os usuários.
Por fim, o Druid é o terceiro mecanismo e adequado para cargas de trabalho de série temporal OLAP de baixa latência, bem como indexação em tempo real de dados de streaming. O Druid fornece consultas OLAP de velocidade de cubo para seu cluster. A natureza de série temporal do Druid é uma pedra angular do motor; ele é projetado dessa maneira porque o tempo é um filtro primário quando os dados baseados em tempo são analisados. Pense em quando você está analisando os horários dos voos para reservar uma viagem – eu quero saber o voo de menor custo para a Itália dentro desse período específico de 2 semanas. O Druid se encaixa no nicho de ser muito rápido para ingerir dados e localizá-los quando solicitado. Por outro lado, também permite que usuários de negócios e analistas consultem os dados e os entendam por meio do Superset, uma camada de visualização intimamente ligada ao Druid. Druid se destaca em identificar um punhado de linhas de dados entre centenas de milhões ou bilhões em menos de um segundo, e também se destaca no cálculo de valores agregados sobre o mesmo volume de dados de forma extremamente rápida. No entanto, ele não faz junções e, portanto, não pode ser usado para combinar conjuntos de dados para análise. Se você planeja analisar uma combinação de conjuntos de dados no Druid, seria aconselhável pré-juntar os dados antes de inseri-los no Druid ou usar Hive (e tabelas Hive com suporte de Druid) para realizar junções. Dito em outras palavras, o Druid se encaixa bem no papel de ser a última parada para seus dados após serem processados e transformados em como seus usuários de negócios os acessarão. O Druid é ótimo para analistas de negócios, pois eles podem fazer login no Superset e visualizar métricas em forma de painel sem precisar escrever nenhuma consulta; eles simplesmente usam uma GUI para selecionar a fonte de dados e os filtros da consulta. Também é ótimo como fonte de dados de apoio para painéis do sistema, sejam operacionais ou analíticos, devido aos tempos de consulta rápidos.
Aqui está uma maneira de detalhar a tomada de decisão sobre qual ferramenta usar para sua carga de trabalho:
| HBase | Colmeia | Druida |
| Acesso aleatório de latência ultrabaixa (pesquisa baseada em chave) | ACID, banco de dados em tempo real, EDW | OLAP de baixa latência, consultas simultâneas |
| OLTP de grande volume | Interface SQL unificada, JDBC | Agregações, detalhamentos |
| Atualizações | Relatórios, lote | Série temporal |
| Exclui | Jussões, grandes agregados, ad-hoc | Ingestão em tempo real |
SQL unificado
Discutimos vários sistemas até este ponto e cada um deles tem suas próprias maneiras de acessar seus dados. Isso é ótimo quando seus usuários sabem como todas essas ferramentas funcionam, mas podem estar em uma curva de aprendizado antes de atingir a produtividade total se vierem de um mundo de SQL, SQL e mais SQL como a maioria dos analistas. É por isso que tentamos tornar essa interação o mais simples possível; com o Hive 3.0 no HDP 3.0, você pode usar a sintaxe HQL semelhante a SQL do Hive para interagir com tantos armazenamentos de dados diferentes neste espaço. O Hive pode ser usado como um portal para acessar e modificar Druid, HBase e qualquer coisa que forneça uma interface e driver JDBC. O Hive pode ser usado para administrar uma tarefa de ingestão de Druidas que ouve Kafka, fornecendo uma maneira simples de ingestão em tempo real. E, finalmente, o Hive pode ser usado para reunir tudo – armazene seus dados onde fizer mais sentido e acesse-os de um só lugar. Junte-os, talvez até armazene esse novo resultado em outro local. As possibilidades são muitas, mas a interface foi bastante simplificada para que sua base de usuários gaste menos tempo aprendendo outra ferramenta e mais tempo agregando valor aos negócios.
Conclusão
Hive, Druid e HBase têm lugares diferentes em uma arquitetura de dados, como vimos na análise anterior. No entanto, são ferramentas complementares; você pode ingerir dados transacionais com o HBase com suas pesquisas rápidas, mover esses dados para o Druid para uma rápida busca detalhada/agregação e fazer com que o Hive integre os dois com seus próprios dados gerenciados pelo Hive para permitir que os usuários combinem dados onde quer que eles residam uma visão única e uma riqueza de insights. Com essa abordagem, o Druid armazena dados que podem ser acessados por conta própria, mas essa funcionalidade é aumentada pelo Hive, que pode extrair dados do Druid e juntá-los com dados adicionais. Adicione a isso os principais aprimoramentos que entraram em jogo com o Hive 3.0, incluindo visualizações materializadas, integrações aprimoradas com Druid, bem como muitos outros mecanismos, e maior funcionalidade semelhante a data warehouse, e você tem um grupo de ferramentas que podem resolver praticamente qualquer caso de uso.
Arquiteturas como as mencionadas trazem o melhor de cada ferramenta para otimizar seu fluxo de trabalho e ao mesmo tempo abstrair os detalhes para aqueles usuários preocupados apenas com os dados. Os arquitetos configuram os pipelines, colocando os dados onde eles pertencem com base no caso de uso. Isso leva aos analistas de dados, que usam o Hive como sua única interface para obter conhecimento e insights. Eles são capazes de encontrar padrões interessantes nos dados em vez de se preocupar com onde os dados estão armazenados ou aprender uma nova sintaxe para acessá-los – você ficaria surpreso ao descobrir com que frequência vemos isso no mundo.
Neste ponto, demonstramos os pontos fortes, fracos e as melhores práticas de cada ferramenta; esperamos que você saia com uma melhor compreensão do que se encaixa onde, bem como a visão geral de combinar os três para obter os melhores resultados.
