Compressão de parque dentro da Colmeia Apache

p> Num projecto recente, Estava a trabalhar na concepção e implementação de condutas para ingerir dados num aglomerado Hadoop. A localização alvo típica dos dados ingeridos é uma tabela Hadoop. Embora o Hadoop possa lidar com grandes dados, é a melhor prática comprimir os seus dados e utilizar um formato de ficheiro mais avançado, tal como ORC ou Parquet. Uma vez que a estrutura de ingestão é Apache Spark, Parquet é mais adequado para a leitura e escrita de Spark Dataframes. Em termos de compressão, há muitas opções como Bzip, LZO, e SNAPPY. Na prática, SNAPPY é uma boa escolha por defeito, pois comprime bem mas também é relativamente rápido.

Com o formato de ficheiro seleccionado (Parquet) e compressão (SNAPPY), eu queria criar tabelas apropriadas de Colmeia para aproveitar estas opções. A colmeia é bastante robusta e estas estão nativamente disponíveis, o que torna a utilização destas opções tão simples como definir os parâmetros correctos na tabela DDL.

Criei as DDLs e apenas assumi que os dados estavam a ser devidamente comprimidos. Depois de executar as condutas em grandes conjuntos de dados, reparei que a utilização do disco era muito mais elevada do que o previsto. Após uma pesquisa e teste bastante exaustivo, percebi algo interessante com Hive and Spark:

1. Hive table properties are case sensitive. “PARQUET.COMPRESS” não é o mesmo que “parquet.compress” no interior da Metastore.
2. Utilizar tblproperties(“parquet.compression”=”SNAPPY”) e depois descrever a tabela dá-lhe informações mistas. Dirá que o quadro não está comprimido (o que é verdade) mas que está a comprimir o conteúdo dentro dos ficheiros (que a Hive Metastore não rastreia).
3. Spark não utiliza as mesmas bibliotecas que a colmeia, pelo que as tblproperties nem sempre estão alinhadas. Isto significa que o que vemos na Metástore da Colmeia e o que estamos a escrever utilizando o Spark pode não ser o mesmo.

Com toda esta informação recentemente descoberta, descobri que a forma correcta de definir uma tabela da Colmeia de modo a que esta seja comprimida utilizando Parquet e SNAPPY independentemente da aplicação que está a fazer a escrita (Spark ou Colmeia) é definir as propriedades da tabela como o seguinte:

TBLPROPERTIES (“parquet.compressão”=”SNAPPY”)

Nota o nome e o case.

Além desta descoberta, aprendi como verificar se um ficheiro Parquet está comprimido. A maioria das distribuições Hadoop vem com uma ferramenta chamada parquet-tools. Se não o tiver, pode descarregá-lo a partir daqui: https://github.com/apache/parquet-mr/tree/master/parquet-tools. Utilizando esta ferramenta, faça o seguinte:

1. Copiar o seu parquet a partir de HDFS para o nó de borda utilizando hdfs dfs -get <caminho/para/ficheiro>
2. Utilizar as ferramentas de parquet para olhar para o ficheiro. Utilizar este comando: /usr/bin/parquet-tools meta <nome do ficheiro>

A saída conterá linhas como esta se os dados não forem comprimidos:

p>my_col: BINÁRIO NÃO COMPRIMIDO DO:0 FPO:4 SZ:793/793/1.00 VC:100 ENC:BIT_PACKED,PLAIN_DICTIONARY,RLE

e se for comprimido:

my_col: BINÁRIO SNAPPY DO:0 FPO:4 SZ:757/793/1.05 VC:100 ENC:BIT_PACKED,RLE,PLAIN_DICTIONARY

Claramente, se quiser comprimido, quer assegurar-se de que a compressão correcta é indicada para cada coluna.