Comparativo de arquivos em Bigdata

Comparando qual o melhor para cada caso

Esse artigo conclui a serie em que falo sobre Datalake, armazenamentos, tipos de arquivos e agora a vantagem de cada um deles. Acho que pra quem não sabia nada já dá um norte danado e se você não acompanhou esse material, antes dá um Follow no botão verde ai em cima e agora, segue o link de cada um deles:

• Conceito de Data Lake e possíveis armazenamentos
• Tipos de arquivos de Bigdata

Esse terceiro post serve pra fechar falando da vantagem do uso de cada um dos tipos de arquivos de acordo com os cenários. Todo o processo vai depender de como você vai armazenar seus arquivos, lembra dos tipos de armazenamento em HDFS e Deep Storage? Se não lembra é o primeiro link dos 2 que coloquei ai.

Os pontos que devem ser observados

• Formato: Foi explicado no artigo anterior o formato de cada um dos arquivos, formato de tabela, chave valor, log, se é legivel, se é compilado no formato binário, tudo isso deve ser levado em consideração de início.
• Compactação: Isso vai de encontro ao tipo de arquivo que você vai usar, geralmente os formatos legíveis geralmente não possuem compactação em tempo de leitura, já os binários sim, isso reflete no tempo de leitura do dados e no tempo de armazenamento, isso pode refletir muito na sua performance.
• Particionamento: Assim como o exemplo acima, arquivos legíveis não trabalham com particionamento, levando em consideração o tipo de armazenamento, por padrão esse arquivo é replicado mas pode também ser particionado, permitindo assim que cada parte dele seja lida e processada em separado, sem a necessidade da leitura do arquivo como um todo.

Segue abaixo uma tabelinha que compara os arquivos no formato não legível, que são realmente os mais utilizados (Avro, Parquet e ORC), a divisão do menor pro maior seria (bom >muito bom > excelente) e no caso dos 2 últimos você entendeu vai…

Tabelinha de como extrair o melhor do seu formato

Minhas considerações

Lembrando que são minhas considerações, umas já testei outras não, mas reuni informações da Web sobre.

Nested

Primeiro preciso explicar um ponto sobre dados do tipo "nested", o que eles seriam? Lembra dos formatos do tipo JSON? Eles são do tipo chave/valor, porém um consigo criar sub-itens por exemplo:

{
   "id": 1,
   "dados: {
      "nome": "Anselmo",
      "sobrenome": "Borges
      },
   "função": "Alcoolatra"
}

Bom, se liga no exemplo, no "id" tenho uma informação padrão de chave valor, porém em "dados", eu tenho mais 2 itens, que se fosse outro exemplo eu poderia ter mais um sub item e tal… O lance é o seguinte, numa busca, quanto mais pra "direita" (falando de forma mais visual) o dado está mais CPU vai ser usada pra buscar a informação.

Mas o parquet não é de coluna? Sim, mas ele pode trabalhar com família de colunas assim como o Cassandra faz, nunca usei mas disseram que dá, vou te mostrar um exemplo de como ficaria.

Parece estranho mas funciona bem, você ja deve ter visto no Excel

Bom por que estou falando disso? Esse formato é mais performático em um Avro, em um JSON também funciona legal mas a ideia é quanto menos "nested"o arquivo for melhor, já o Avro performa melhor. Posso usar o Parquet mas ele não performa legal em buscas do tipo "nested", até faz mas não com rapidez.

Só esse exemplo vc já se liga qual usar de acordo com a estrutura dos seus dados.

Legibilidade

Vamos supor que você precisa ter acesso fácil ao tipo de dados, plotar seu RDD em algum lugar, não está ligando muito pra performance, nesse caso os tipos CSV e JSON são seus melhores amigos. Fácil leitura, fácil acesso, pouca frescura.

Compactação

"Pô, não tenho muito espaço de armazenamento, meus arquivos são muito grandes." Para arquivos grandes já descartaria os 2 formatos acima, agora com os formatos que sobraram um as taxas de compactação mudam e veremos mais no final desse post.

Evolução do Schema

O que é isso?

que p**** é essa?

Vamos lá migs, quando você tem um dado no S3 por exemplo lembre que ele não é um banco de dados e sim um arquivo, quando falamos de arquivos do tipo Avro e Parquet por exemplo ele tem uma facilidade de remover ou alterar campos, ver os tipos de dados e tal. Portanto essa tal modificação é a evolução do Schema. Existem algumas ferramentas tipo o Apache Hudi que fazem meio que um "Delta Lake" e trabalham super bem com esses tipos de alterações, criando meio que um histórico de ações (que cobram um espacinho em disco, mas vale o preço).

Sobre a compactação do arquivo

Essa parte eu roubei na larga de outro post que ví do assunto.

Tava em inglês, estou testando meus dotes de tradutor

Bom, alguns tipos de compactação usam mais CPU, outros menos, outros alem de compactados leem mais rápido, outros escrevem mais rápido, enfim. O esquema e colar dessa tabelinha qual usar e quando, pois um tipo de arquivo tem um ou mais algoritmo de compactação.

Tipos de algoritmo de compactação

Últimas dicas

• Vai gravar, fazer ingestão de dados use o Avro
• Vai ler fazer consultas grandes, use o Parquet, mas se quiser trabalhar com o que tem de melhor hoje use o ORC, basta ver a tabela e o post anterior.
• Vai criar uma tabela no Hive? O Parquet sempre foi mais usado como formato final de uma external table, mas tente usar o ORC =).
• Vai gravar o resultado de uma fila Kafka? Vai fazer um ETL? Use o Avro.
• Vai usar um modelo de compactação e quer um que use pouca CPU? Use o Snappy.
• Use sempre que der Particionamento, tanto em deep storage como no HDFS, mas não precisa criar 100, 200 partições como já ví muito por ai.
• Vai trabalhar com API? Use o Avro.
• Se não for usar no Hive e for realizar uma consulta via Impala, Spark, dados de analytics e consultas o Parquet funciona melhor que o Avro.

Vou ficando por aqui, espero que tenham gostado e deixe ai em baixo a sua palminha se curtiu, assim fico sabendo se devo continuar ou não os posts.

Até o próximo!

Anselmo Borges
Rescue Point