Tipos de arquivos em Bigdata

Conhecendo os tipos e familiaridades de cada um deles

Dando continuidade no assunto de Datalake e as possibilidades, precisamos ainda conhecer como é o nosso dado, informações, estrutura, peso em armazenamento e performance de acesso entre outras coisas. Os formatos de arquivos em que você vai armazenar, consultar e as vezes até manipular as informações podem ser dos mais variados tipos possíveis.

Alguns dos principais tipos de dados que você vai encontrar

Quando estamos falando em Datalake, estamos falando em armazenamento de informações, informações essas que devem ser legíveis no formato humano ou através de ferramentas de dados como Hive, Spark, Big Query, Athena e outras.

Vou começar com 3 tipos de formatos que não são muito usados no Hadoop/HDFS em si (depois explico o porque) mas podem dar informações bem relevantes de dados que são o XML o LOG e o CSV.

XML

O formato XML é muito comum em ferramentas de ERP que trabalham com dados de notas fiscais por exemplo. O XML é um formato bem antigo criado em 1996, ele usa o conceito de chave e valor mas diferente do JSON, as chaves são TAGS e o valores vão dentro das TAGS, bem parecido com HTML até por isso se tornou uma tendencia por desenvolvedores.

Segue abaixo um exemplo com dados de um filme:

Exemplo de um filme e características dele no formato XML

Tem basicamente as mesmas características do JSON, para processamentos de pequenos grupos de dados é extremamente funcional com a ferramenta correta.

LOGS

Todo sistema possui um log, no sistema operacional, no Apache, no SSH, enfim, neles rastreamos acessos indevidos, uso de CPU, espaço em disco, se você é ou ja foi um SysAdmin, sabe do que estou falando. Esses tipos de arquivos tem um formato de linha do tempo, eles sempre possuem um campo timestamp com data e hora e as informações a seguir.

Trabalho muito com logs mas no Elasticsearch, onde com esses dados posso realizar analises preditivas e diversas agregações que podem me levar a resultados impressionantes. Outro exemplo além de logs de sistema, podem ser logs de sensores ou de satelites que fazem monitoramentos constantes.

A Elastic usa um padrão de formatação de logs chamado ISO 8601, que cria um padrão em todos os logs inseridos para consulta, o que facilita todo o a leitura e manipulação. Segue abaixo um exemplo de arquivo de log.

03/22 08:51:01 INFO   :.main: *************** RSVP Agent started ***************
 02 
03/22 08:51:01 INFO   :...locate_configFile: Specified configuration file: /u/user10/rsvpd1.conf
03/22 08:51:01 INFO   :.main: Using log level 511
03/22 08:51:01 INFO   :..settcpimage: Get TCP images rc - EDC8112I Operation not supported on socket.
 03 
03/22 08:51:01 INFO   :..settcpimage: Associate with TCP/IP image name = TCPCS
03/22 08:51:02 INFO   :..reg_process: registering process with the system
03/22 08:51:02 INFO   :..reg_process: attempt OS/390 registration
03/22 08:51:02 INFO   :..reg_process: return from registration rc=0
 04 
03/22 08:51:06 TRACE  :...read_physical_netif: Home list entries returned = 7
03/22 08:51:06 INFO   :...read_physical_netif: index #0, interface VLINK1 has address 129.1.1.1, ifidx 0
03/22 08:51:06 INFO   :...read_physical_netif: index #1, interface TR1 has address 9.37.65.139, ifidx 1
03/22 08:51:06 INFO   :...read_physical_netif: index #2, interface LINK11 has address 9.67.100.1, ifidx 2
03/22 08:51:06 INFO   :...read_physical_netif: index #3, interface LINK12 has address 9.67.101.1, ifidx 3
03/22 08:51:06 INFO   :...read_physical_netif: index #4, interface CTCD0 has address 9.67.116.98, ifidx 4
03/22 08:51:06 INFO   :...read_physical_netif: index #5, interface CTCD2 has address 9.67.117.98, ifidx 5
03/22 08:51:06 INFO   :...read_physical_netif: index #6, interface LOOPBACK has address 127.0.0.1, ifidx 0
03/22 08:51:06 INFO   :....mailslot_create: creating mailslot for timer
03/22 08:51:06 INFO   :...mailbox_register: mailbox allocated for timer
 05 
03/22 08:51:06 INFO   :.....mailslot_create: creating mailslot for RSVP
03/22 08:51:06 INFO   :....mailbox_register: mailbox allocated for rsvp
03/22 08:51:06 INFO   :.....mailslot_create: creating mailslot for RSVP via UDP

Note que ele tem um campo de data, logo mais a frente o tipo de log, INFO, TRACE e etc. No próximo campo ele vem uma mensagem sobre o que ocorreu, podem existir mais campos mas basicamente é essa a estrutura.

Algumas pessoas usam pipelines para transformar os dados de log em tabela e fazer analises, mas hoje existem ferramentas que trabalha bem na leitura e manipulação deles uma delas é o Elasticsearch e suas sub ferramentas, Logstash e Beats.

CSV

Bom se você ja mexeu com Excel conhece um CSV, a estrutura dele é de um armazenamento de dados no formato de tabela, colunas e linhas, mais focado nas 2 ultimas, levando em consideração que o arquivo é a tabela.

sim o arquivo é a tabela.

Bom depois da minha brilhante colocação, como fica a estrutura de um .CSV?

Considere a tabela, a primeira linha com as informações de cada coluna é o chamado "HEADER/CABEÇALHO", que pode existir ou não, todas essas colunas são separados por 3 tipos de caracteres que podem ser:

• Virgula (,)
• Ponto e Virgula(;)
• TAB (caracter vazio mas dá pra ver que ele tá lá)

Esses caras são os chamados "espaçadores" (nem sei se é assim que escreve), mas eles determinam quando inicia uma nova coluna, se liga no exemplo abaixo:

nome;sobrenome;endereço;telefone;email

Coloquei o cabeçalho com cada uma das colunas separadas por um espaçador que é o ";". bom mas quando começa a nova linha, exatamente com a quebra de linha. A quebra de linha é considerado um caracter que não é exibido mas tá la. Logo ele reconhece a nova linha:

nome;sobrenome;endereço;telefone;email
Anselmo;Borges;rua ramalho;999223929;anselmo@rescuepoint.com.br

Bom, se eu abrisse um editor de texto qualquer, colasse isso e salvasse no formato .csv eu poderia abrir no Excel e com uma pequena customização abrir como tabela.

JSON

Fui DBA por 8 anos quase, esse formato era tudo que um DBA odiava ouvir, as frases eram do tipo "Duvido o banco funcionar só em cima de um arquivo assim", "e a integridade referencial", "essa parada não vai vingar", eu mesmo relutei muuuuuitoooo com esse formato mas hoje eu PAGO UM PAU.

Vou dar o exemplo do SPC que é a empresa que eu trabalho, no modelo de tabelas temos varias tabelas distintas, com dados de bancos, empresas, fontes e os dados do seu básicos da sua pessoa, mas cruzamos esse dados com as outras tabelas citadas, fazendo um processo de join e enfim trazendo todas as suas informações. Pensando na arquitetura de banco da dados como era, se cresce o volume, cresce a maquina e vamo que vamo. Agora imagina se todos os seus dados estivesses num único documento, inclusive os das outras tabelas que falei? Isso é que o JSON oferece.

O JSON bem parecido com o XML no conceito de chaves e valor mas funciona num modelo diferente:

{
   nome: Anselmo,
   sobrenome: Borges
}

Se ligou? Alem disse eu posso criar listas (arrays) dentro desse documento o que não daria em tabelas.

{
   nome: Anselmo,
   sobrenome: Borges,
   bebidas: [suco,cerveja,vinho,agua]
}

Essa funcionalidade me traz uma facilidade absurda de busca de dados desde que a aplicação seja desenhada para formatos "Não Estruturados/NoSQL", ou seja, não no formato convencional de tabelas.

Os principais bancos de dados que trabalham com esses formatos que eu conheço são MongoDB e Elasticsearch e funcionam super bem, pois diferentes dos bancos convencionais são clusterizados e tem escalabilidade horizontal diferentes dos convencionais.

Outro lugar onde você vai encontrar muito esse formato, com o crescimento de aplicações que usam API, a resposta das solicitações do API volta no formato JSON.

Evolução dos Formatos citados

Bom todos esses formatos já existem a alguns anos, com excessão do JSON que é o mais jovem. Mas estamos aqui pra falar de arquivos de um ambiente Bigdata, Data Lake, logo, temos que falar de tipos relativamente novos, ai onde entram:

• Parquet
• Avro
• ORC

Parquet

O CSV existe desde os anos 70, eu nem nascido era e olha que já sou velho, quando você faz uma consulta de uma coluna por exemplo num arquivo CSV, você leu ele todo, agora imagina se o seu CSV tem 1TB por exemplo. Por favor nesse minuto pare de pensar no Excel e que no XSLx ele é mais rápido, estamos falando de 1TB de dados.

Eu dei uma pesquisada em 2010 o Google lançou um formato de arquivo, que tinha a estrutura de colunas, porém quando você fazia uma pesquisa por exemplo, não pegava o arquivo todo e sim só a coluna que você precisava, vamos supor que esse .csv tivesse 20 bilhoes de linhas e 300 colunas e você precisasse apenas de uma coluna que tem 100 mil linhas.

O quanto isso traria de rapidez pra você?

So FAST!

Pois é, mas parece o que o Google colocou na meia o código desse cara, mas o Twitter e a Cloudera foram atras disso e em 2012 lançaram o Parquet e em 2015 ele já era Top Level project da Apache.

Bom basicamente é isso sobre o Parquet, falaremos mais sobre as suas vantagens no próximo post, mas um ponto dele que já é um tapa na cara do CSV é a possibilidade de compactação. Digamos que o CSV é uma musica no CD e o Parquet é um MP3, se você passou pela minha fase de converter CD para MP3 vai saber o que eu estou falando. Segue abaixo a estrutura de um arquivo Parquet.

Estrutura arquivo Parquet

AVRO

Eu geralmente usava a expressão o Avro é o Parquet do JSON, mas na real é bem errado dizer isso. Ele é sim uma evolução de um tipo de arquivo, usa o formato JSON internamente mas só pra fazer um papel de Metadado. Vamos começar dizendo que dentro do avro file existe um schema file, que fala os data types de cada campo, ou seja, nome/string, idade/number ou um campo booleano por exemplo. Isso no JSON não existe, ponto para o Avro.

O Avro funciona com uma estrutura de sub itens de um item assim como o JSON, isso até existe no Parquet como família de colunas (estilo Cassandra) mas não funciona muito bem, o Avro é o melhor arquivo pra isso assim como o JSON.

Segue um desenho de arquitetura da composição de um arquivo AVRO.

Estrutura de um arquivo Avro.

Um outro ponto legal tanto para o Parquet quanto para o Avro é que ambos possuem um sistema de particionamento o que acelera absurdamente na consulta de dados. Um ponto negativo para o Avro perto do Parquet é que pelo seu sistema diferente de armazenamento e consulta, quando uma informação é requerida ele lê todo o arquivo e não só a parte que precisa como é no Parquet. Portanto o Avro é um arquivo mais indicado para gravação do que para Leitura.

Não vou entrar em muitos detalhes sobre o Avro, senão esse post vai ficar enorme, mas já deu pra ter uma base.

ORC

Eu não usei o ORC ainda mas estou estudando sobre ele, dizem que o ORC é uma evolução do Parquet e trabalha de uma forma mais rápida e com menor armazenamento. O projeto do ORC nasceu em 2013 como uma iniciativa de acelerar o Hive e reduzir armazenamento no Hadoop. Ele também utiliza o modelo colunar do Parquet e os mesmos princípios de trazer só o realmente necessário.

2 dos grandes usuários de arquivos ORC são o Facebook e o Yahoo que migraram boa parte dos seus Parquet para esse formato. Nesses slides abaixo tem o Benchmark que o Yahoo fez mostrando a sua migração de arquivos Parquet para ORC e os ganhos.

Um ponto bem interessante é que o Hive funciona nativamente com o ORC e o mesmo aceita a estrutura de SQL tranquilamente. Segue abaixo a estrutura de um arquivo ORC.

Estrutura arquivo ORC

Pontos finais

Vale lembrar que existem os arquivos legíveis, onde consigo visualizar o conteúdo rodando um cat ou qualquer outro editor de texto:

• LOGS
• XML
• JSON
• CSV

E os arquivos binários, que são compilados e precisam de bibliotecas pra que sejam lidos, a maioria delas nativas de ambientes Hadoop:

• Parquet
• Avro
• ORC

Como esse post ficou bem grande, fica como apresentação desses tipos de arquivos e no próximo falo sobre as vantagens e desvantagens no uso de cada um deles nos mais diversos cenários dentro de um ambiente Bigdata HDFS ou Data Lake de deep storage.

Sinta-se a vontade de compartilhar esse post e deixa sua palminha ae pra fortalecer! rs

Até ó próximo.

Anselmo Borges
DataOps Engineer