DataLab | Como devemos usar o formato Parquet?
Como devemos usar o formato Parquet?
Por: DataLab Serasa Experian 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:
Em agregações envolvendo apenas um subconjunto dos campos do esquema, esse formato reduz substancialmente a quantidade de dados lidos, pois apenas as colunas interessantes são lidas;
Como cada coluna tende a ser uniforme, elas podem ser compactadas, encodadas de forma individual, por exemplo: Uma coluna que possui apenas dois valores possíveis pode ser mapeada para apenas 1 bit de dado (0 ou 1); Colunas com texto podem ser compactadas usando pequenos dicionários.
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:
Estruturas de Dados Complexas: Uma das premissas do projeto do Parquet foi o suporte a estruturas de dados complexas e infinitamente encadeáveis. Essa característica foi viabilizada pelo uso do algoritmo Dremel, desenvolvido pelo Google;
Compactação e Enconding: Para conseguir uma compressão avançada das colunas, o Paquet implementa várias tecnicas de codificação [4] e suporta alguns algoritmos de compressão, como: gzip e snappy;
Null Values: Valores Nulos ficam de fora do formato parquet. Isso ajuda a economizar ainda mais dados;
Filter Pushdown: Como forma de otimizar ainda mais a quantidade de dados lidos, alguns filtros podem ser resolvidos antes mesmo de baixar os dados. O Parquet possui uma série de metadados sobre cada coluna em cada arquivo. Dessa forma, pode-se evitar o download de um chuck de coluna do Parquet por ele estar fora do interesse da consulta.
Em contrapartida, o Parquet possui algumas limitações. As principais são relacionadas a escrita de dados:
Tempo de Escrita: Todas essas facilidades do Parquet vêm com um custo, que é pago majoritariamente durante a escrita dos arquivos. Isso faz com que a escrita do Parquet tenha um custo superior se comparado a outros formatos, como CSV, por exemplo. Mas devemos levar em consideração que na maioria dos casos os dados são escritos uma vez e apenas lidos após isso;
Imutabilidade: Não deve ser surpresa que para que todos os mecanismos de compressão e codificação se mantenham eficientes as colunas não devem ter seus dados atualizados. Os dados escritos em Parquet são imutáveis.
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.