Como devemos usar o formato Parquet?

Por: em 6 de agosto de 2018

O termo Big Data está cada vez mais presente no mundo digital. Todos os dias, petabytes de dados são criados [1] e um percentual cada vez maior dessa enorme quantidade de dados é armazenada para posterior processamento e análise. Nesse sentido, já existe uma série de soluções para armazenamento e processamento de enormes quantidades de dados, dados esses com diferentes níveis de estruturação, como Hadoop/HDFS, Amazon S3/EMR, Azure HDInsight entre outros.

Entretanto, independentemente da solução adotada, a variável “custo” continua sendo importante nesse ambiente tão cheio de superlativos. Entre os custos importantes podemos citar: armazenamento, acesso aos dados, processamento e tempo de resposta. Algumas estratégias comuns para reduzir esses custos vão desde algoritmos para compressão e codificação à melhor estruturação dos dados de interesse.

Neste post vamos falar sobre um formato de arquivos chamado Apache Parquet. Esse formato ataca as principais dores na hora de processar esse tipo de volumes dados, como: compressão, codificação, redução da quantidade de dados por query, armazenamento de esquemas, etc. Mas primeiro vamos falar um pouco sobre dois tipos de armazenamento de dados: os baseados em linha (ou registro) e os baseados em coluna.

 

Formatos baseados em Linha vs Coluna

Certamente você já deve ter usado alguns dos formatos baseados em linha existente: CSV, TSV e TXT são todos formatos baseados em linha. Nesse tipo de formato, cada registro dos seus dados é armazenado contiguamente. Um grande atrativo para esse tipo de formato é a simplicidade tanto na leitura quanto na escrita e todos os dados de um mesmo registro podem ser recuperados simultaneamente. Infelizmente, essas facilidades são pouco aproveitadas em um ambiente majoritariamente analítico, como é o de Big Data. No nosso contexto, muitas vezes queremos agregar um subconjunto das colunas e precisar ler todo o registro acaba consumir recursos (aumentar custos) desnecessariamente.

Dado esse contexto, uma estrutura colunar tende a possuir enormes vantagens sobre a alternativa citada anteriormente.

Trabalhando no universo colunar, não mais os registros são armazenados contiguamente, mas os campos de cada registro que o são.

 

 

A figura acima mostra a diferença entre as abordagens. Nela podemos ver os campos session_id (em azul), timestamp (em verde) e source_ip armazenados em uma formato em linha (a esquerda) e em coluna (a direita). [2]

Como vantagem do formato colunar, podemos destacar:

 

 

Apache Parquet

O Parquet é um formato colunar e binário que foi desenvolvido em uma cooperação entre o Twitter e Cloudera para criar uma representação colunar eficiente para qualquer projeto para o ecosistema Hadoop [3].

Além das vantagens em utilizar uma representação colunar, o formato Parquet possui as seguintes vantagens/funcionalidades:

 

 

 

 

Em contrapartida, o Parquet possui algumas limitações. As principais são relacionadas a escrita de dados:

 

 

Conclusão

Mesmo com todo o ecossistema Hadoop/HDFS e cloud que tivemos acesso nos últimos anos, a escalada no volume de dados que temos que lidar diariamente ainda impõe desafios tanto do ponto de vista técnico quanto do ponto de vista econômico.

O formato Parquet se propõe a ser uma importante ferramenta para tornar mais eficiente o armazenamento e processamento de grandes volumes de dados.

No DataLab, desde quando adotamos Parquet como formato padrão de armazenamento de dados conseguimos reduzir nosso volume armazenado em mais de 80% e as consultas ficaram cerca de 2x mais rápidas.

 

Referências

[1] https://www.domo.com/learn/data-never-sleeps-5

[2] https://www.kdnuggets.com/2017/02/apache-arrow-parquet-columnar-data.html

[3] https://parquet.apache.org/

[4] https://acadgild.com/blog/parquet-file-format-hadoop

[5] https://developer.ibm.com/hadoop/2016/01/14/5-reasons-to-choose-parquet-for-spark-sql/

[6] https://dzone.com/articles/understanding-how-parquet

[7] https://databricks.com/session/spark-parquet-in-depth

 

 

6 de agosto de 2018