Comprimindo dados em Hadoop - dummies

Os enormes volumes de dados que são realidades em uma implantação Hadoop típica tornam a compressão uma necessidade. A compressão de dados definitivamente lhe poupa uma grande quantidade de espaço de armazenamento e é certo acelerar o movimento desses dados em todo o cluster. Não surpreendentemente, uma série de esquemas de compressão disponíveis, chamados de codecs, estão lá para você considerar.

Em uma implantação Hadoop, você está lidando (potencialmente) com um grande número de nós escravos individuais, cada um dos quais possui várias unidades de disco grandes. Não é incomum que um nó escravo individual tenha mais de 45 TB de espaço de armazenamento bruto disponível para HDFS.

Mesmo que os nós escravos Hadoop são projetados para serem baratos, não são gratuitos e com grandes volumes de dados que tendem a crescer a taxas crescentes, a compressão é uma ferramenta óbvia para controlar o extremo volumes de dados.

Em primeiro lugar, alguns termos básicos: um codec , , que é uma forma abreviada de co mpressor / dec ompressor, é tecnologia (software ou hardware, ou ambos) para comprimir e descomprimir dados; É a implementação de um algoritmo de compressão / descompressão.

Você precisa saber que alguns codecs suportam algo chamado de compressão dividível e que os codecs diferem tanto na velocidade com que eles podem comprimir e descomprimir dados quanto no grau em que eles podem comprimi-lo.

Compressão dividível é um conceito importante em um contexto Hadoop. A maneira como o Hadoop funciona é que os arquivos são divididos se forem maiores que a configuração do tamanho do bloco do arquivo, e as separações de arquivos individuais podem ser processadas em paralelo por mapeadores diferentes.

Com a maioria dos códecs, as divisões de arquivos de texto não podem ser descompactadas independentemente de outras divisões do mesmo arquivo, de modo que os codecs não sejam dividíveis, de modo que o processamento MapReduce é limitado a um único mapeador.

Como o arquivo pode ser descompactado somente como um todo, e não como partes individuais com base em divisões, não pode haver processamento paralelo desse arquivo, e o desempenho pode ter um grande sucesso como um trabalho aguarda um único mapeador para processe vários blocos de dados que não podem ser descomprimidos de forma independente.

A compressão dividível é apenas um fator para arquivos de texto. Para arquivos binários, os codecs de compressão Hadoop comprimem dados dentro de um contêiner codificado em binário, dependendo do tipo de arquivo (por exemplo, um SequenceFile, Avro ou ProtocolBuffer).

Falando de desempenho, há um custo (em termos de recursos e tempo de processamento) associado à compressão dos dados que estão sendo gravados em seu cluster Hadoop.

Com os computadores, como com a vida, nada é gratuito. Ao comprimir dados, você está trocando ciclos de processamento por espaço em disco. E quando esses dados estão sendo lidos, há um custo associado à descompressão dos dados também. Certifique-se de pesar as vantagens das economias de armazenamento contra a sobrecarga de desempenho adicional.

Se o arquivo de entrada para um trabalho MapReduce contiver dados compactados, o tempo necessário para ler esses dados do HDFS é reduzido e o desempenho do trabalho é aprimorado. Os dados de entrada são descomprimidos automaticamente quando está sendo lido pelo MapReduce.

A extensão do nome do arquivo de entrada determina qual codec suportado é usado para descomprimir automaticamente os dados. Por exemplo, a. A extensão gz identifica o arquivo como um arquivo comprimido com gzip.

Também pode ser útil para comprimir a saída intermediária da fase do mapa no fluxo de processamento MapReduce. Como a saída da função do mapa é gravada no disco e enviada através da rede para reduzir as tarefas, a compressão da saída pode resultar em melhorias de desempenho significativas.

E se você deseja armazenar a saída MapReduce como arquivos de histórico para uso futuro, a compressão desses dados pode reduzir significativamente a quantidade de espaço necessário no HDFS.

Existem muitos algoritmos e ferramentas de compressão diferentes, e suas características e pontos fortes variam. O trade-off mais comum é entre as proporções de compressão (o grau em que um arquivo é compactado) e as velocidades de compressão / descompressão. O framework Hadoop oferece suporte a vários codecs. A estrutura comprime e descompacta transparentemente a maioria dos formatos de arquivos de entrada e saída.

A lista a seguir identifica alguns codecs comuns que são suportados pelo framework Hadoop. Certifique-se de escolher o codec que mais corresponda às demandas de seu caso de uso específico (por exemplo, com cargas de trabalho onde a velocidade de processamento é importante, escolha um codec com altas velocidades de descompressão):

• Compressão Gzip: A utilitário que foi adotado pelo projeto GNU, o Gzip (abreviação de zip GNU) gera arquivos compactados que possuem um. extensão GZ. Você pode usar o comando gunzip para descompactar arquivos que foram criados por uma série de utilitários de compressão, incluindo o Gzip.

• Bzip2: Do ponto de vista da usabilidade, Bzip2 e Gzip são semelhantes. O Bzip2 gera uma melhor taxa de compressão do que o Gzip, mas é muito mais lento. Na verdade, de todos os codecs de compressão disponíveis no Hadoop, o Bzip2 é de longe o mais lento.

  Se você estiver configurando um arquivo que você raramente precisará consultar e o espaço está em um prémio alto, então, talvez o Bzip2 valesse a pena considerar.

• Snappy: O codec Snappy do Google oferece taxas de compressão modestas, mas velocidades de compressão e descompressão rápidas. (De fato, tem as velocidades de descompressão mais rápidas, o que torna altamente desejável para conjuntos de dados que provavelmente serão consultados com freqüência.)

  O codec Snappy está integrado no Hadoop Common, um conjunto de utilitários comuns que suporta outros subprojetos Hadoop. Você pode usar Snappy como um complemento para versões mais recentes do Hadoop que ainda não fornecem suporte a codec Snappy.

• LZO: Semelhante a Snappy, LZO (abreviação de Lempel-Ziv-Oberhumer, o trio de cientistas da informática que surgiu com o algoritmo) fornece taxas de compressão modestas, mas velocidades de compressão e descompressão rápidas. O LZO é licenciado sob a GNU Public License (GPL).

  O LZO suporta compressão dividível, o que permite o processamento paralelo de divisões de arquivos de texto comprimido por seus trabalhos MapReduce. O LZO precisa criar um índice quando comprime um arquivo, porque com blocos de compressão de comprimento variável, é necessário um índice para indicar ao mapeador onde ele pode dividir com segurança o arquivo compactado. LZO só é realmente desejável se você precisa compactar arquivos de texto.

Hadoop Codecs

Codec	Extensão de arquivo	Splittable?	Grau de Compressão	Velocidade de Compressão
Gzip	. gz	Não	Médio	Médio
Bzip2	. bz2	Sim	Alto	Lento
Snappy	. Snappy	Não	Médio	Rápido
LZO	. lzo	Não, a menos que seja indexado	Médio	Rápido

Todos os algoritmos de compressão devem fazer compensações entre o grau de compressão e a velocidade de compressão que podem alcançar. Os codecs que estão listados fornecem um controle sobre o que o equilíbrio entre a taxa de compressão e a velocidade deve ser no tempo de compressão.

Por exemplo, o Gzip permite regular a velocidade de compressão especificando um inteiro (ou palavra-chave) negativa, onde -1 indica o nível de compressão mais rápido e -9 indica o nível de compressão mais lento. O nível de compressão padrão é -6.