Fala, galerinha dos dados!
Nas últimas 2 semanas, chegou uma demanda interessante aqui para minha equipe. Apesar de não sermos o time específico de arquitetura de dados da organização, vira e mexe chega umas demandas legais para apoiarmos outras áreas, fugindo dos tradicionais reports do assunto de ITSM.
A demanda era, basicamente, para levar para o Power BI, em um visual de mapa nativo, os mesmos pontos que o solicitante estava visualizando localmente na sua máquina com o programa Google Earth. Não vou entrar em detalhes aqui do que se tratava os dados, pois são dados estratégicos e importantes para organização e o foco não é a análise e sim a engenharia dos dados. Digo isso, pois o Google Earth lê os arquivos localmente de uma extensão que nunca ouvi falar: “.kml”. Mas que facilmente, a gente vê que é apenas um XML específico para esse fim.
Eu trabalho, na maior parte do tempo, cuidando justamente da criação e manutenção dos fluxos de ingestão de dados da minha área. Porém, a Stack envolve o famoso SSIS para orquestração e nosso querido SQL Server para fazer todo o trabalho. Apesar de conhecer, gostar e estudar muito Python, Spark, AirFlow e as maravilhas da engenharia de dados, a gente não pode ainda usá-las na área por questões internas da organização. Ah, e quando eu preciso fazer análises exploratórias e entregar um dashboard, é com o famoso Power BI ou até o Excel Raiz. Ou seja, essa solução, certamente não é escalável utilizando somente Pastas no Sharepoint (o que normalmente o meu time faz quando há dados vindo de arquivos) e nosso querido Power Query para tocar o ETL.
O solicitante foi informado por mim de que eu poderia fazer uma POC mas que teria que envolver o time de arquitetura da organização no futuro para seguir com o projeto em escala. Comecei a entender como funcionava esse XML e fiz como faço com múltiplos arquivos em pastas no Sharepoint: crio uma função para um arquivo e depois combino tudo. Pedi a ele dois arquivos de exemplo para testar. Deu certo. Eu plotei no visual de mapa, ajustamos as regras das cores e o solicitante aprovou continuarmos com mais arquivos. Quando o solicitante subiu mais alguns arquivos, como algo que é raro mas que acontece sempre, os dados estavam em um formato diferente. A extensão continuava sendo “.kml” mas o texto escrito tinha tags diferentes, em ordens diferentes… quebrou meu querido Power Query. Então, verifiquei com ele e combinamos uma forma padrão de realizar o import/export dos arquivos no Google Earth. Feito isso, coloquei no DataFlow para rodar o processo.
Com o fluxo no DataFlow, tava tudo simples. Ele preparava novos arquivos, subia e eu atualizava. Porém, à medida que a quantidade dos arquivos foi crescendo, o tempo de atualização aumentava exponencialmente, chegando à incríveis 7h e não é brincadeira. O Fluxo não dava erro, somente demorava mesmo. Era um sinal para que eu experimentasse algo diferente rs
O fluxo lento dessa maneira, fazia com que ficássemos presos ao tempo de atualização para conseguir validar os dados. Eu comuniquei ao solicitante que tentaria uma nova forma: nosso querido Python. A ideia que pensei logo era mudar o formato dos arquivos e passá-los para o “.parquet”. E foi isso que eu fiz. Com a biblioteca Pandas, a xml.etree.ElementTree e algumas outras para manipular os arquivos e subpastas.
O código inicia lendo de uma pasta “landing-zone” com os arquivos “.kml” já segmentados em subpastas referente as regras do negócio e exporta em “.parquet” para a pasta “bronze-zone”. O código encontra cada arquivo em sua respectiva estrutura de subpastas e replica essa mesma estrutura numa segunda camada (pasta) de dados “.parquet”. E mesmo não havendo nenhum filtro nessa primeira parte do código, exceto o filtro de busca de somente arquivos “.kml”, a landing-zone saiu de 188 MB para 3.88 MB na bronze-zone com os arquivos “.parquet”. O arquivo binário gerado (.parquet) consegue ter os dados de forma comprimida e mais rapidamente acessível. Por isso, ele é tão utilizando em grandes volumes de dados. Nesse cenário, sem foram tantos dados, o ganho de performance de um formato como XML para PARQUET é absurdo!
Após essa camada, bronze eu já fiz o restando do ETL que eu precisava, filtrando e adicionando novas colunas. No final das transformações, o meu código .py junto tudo em um único dataframe e exporta para “.parquet”. Com isso, nossa “silver-zone” fica com apenas 1.35 MB. O código ainda exporta pra mim um csv com uma lista de arquivos que precisam ser revisados por conta de estarem ordenados fora do padrão da estrutura combinada. Após isso, joguei no Power BI e foi sucesso.
Enfim, esse é o meu primeiro cenário prático de experimentar a maravilha da compressão e performance dos arquivos PARQUET.
Observações: o projeto apesar de bacana, no meu contexto continua sendo apenas uma POC pois provavelmente, escalar essa solução envolve um datalake de fato, estruturar rotinas de atualização e etc. Tudo isso, o time de arquitetura deve tocar. Mas o solicitante está bem feliz com a POC.
