Formatos de serialização para bigdata

Quando trabalhamos com dados em grande escala, percebemos que os formatos mais tradicionais podem não oferecer eficiência no processo de leitura e escrita, resultando em desafios significativos. Além disso, mal definidos, os arquivos podem apresentar baixa compressão ou lentidão na descompressão. Nesse contexto, o artigo Formatos de serialização para big data explora os principais formatos de forma acessível e compreensível, fornecendo uma visão detalhada das características e peculiaridades de cada um em relação à manipulação de grandes volumes de dados.

Aqui no blog temos além do Formatos de serialização para bigdata, outros artigos sobre dados, devops, kubernetes, ddd, e outros. Selecionamos uma pequena lista de arquivos que podem complementar a leitura desse:

• Banco de dados: Teorema CAP
• Os 14 tipos de bancos de dados
• Arquitetura Lambda e Arquitetura Kappa
• O Essencial do Hadoop

Serialização / Desserialização

Para contextualizar é importante entender que os dados são para o computador um conjunto de bits, bytes, words, dwords, e assim por diante. Na momória eles podem assumir uma determinada forma, no HD outra, em transferência por rede ainda outra. O fato é que é necessário que esses dados sejam coerentes nos locais em que eles ficam ou trafegam. Para tal há formatos que os amparam.

Um desenvolvedor pode criar um arquivo em um formato qualquer que ele inventar e salvar em disco. Mas, apoiado a isso ele precisa criar ferramentas capazes de ler e escrever neles. Se todo o ecossistema estiver ok pode ser que valha a pena.

Há formatos feitos para leitura humana ou outros que não. Um arquivo TXT, um JSON, XML ou YAML são formatos legíveis por humanos, mas podem ter muitas informações de controle, adicionando custo computacional ao cenário. Entretanto os formatos binários são mais eficientes para leitura e escrita, mas que não são bons para nós humanos.

Por fim, alguns formatos são referência no mercado. Pode ser muito incomodo que uma aplicação utilize um arquivo num formato mas nenhum outro sistema saiba lidar com ele.

CSV – Comma Separated Value

Esse é um dos formatos mais populares, amplamente utilizados há muitos anos. Ele é um formato legível para humanos, o que facilita a manipulação até certo nível. Entretanto, os arquivos são muito grandes quando lidamos com grandes massas de dados, tornando a pesquisa mais difícil.

CSV significa Comma Separated Values (valores separador por vírgula), podendo ter variações na sua forma. Veja a seguir um pequeno exemplo de arquivos CSV (o bob não tem e-mail mesmo. Isso é uma possibilidade)

Name,Age,Email
John,30,[email protected]
Alice,25,[email protected]
Bob,35,

JSON – JavaScript Object Notation

Outro formato bastante consolidado e conhecido é o JSON. É muito comum encontrar APIs que retornam dados sob essa estrutura. O JSON é uma estrutura de objetos do JavaScript que não possui tipagem, mas pode representar árvores complexas de objetos.

Esse é um formato legível por humanos, como o CSV, mas com o diferencial de representar dados em outros esquemas. Vaja a seguir um exemplo:

{
  "name": "John Doe",
  "age": 30,
  "email": "[email protected]",
  "address": {
    "street": "123 Main Street",
    "city": "New York",
    "country": "USA"
  },
  "hobbies": ["reading", "traveling", "cooking"]
}

Outros formatos human readable

Citamos os formatos CSV e JSON. Temos também o formato XML que já foi muito popular mas hoje assombra sistemas legados. Dificulmente esse formato será encontrado em sistemas mais modernos. Além disso ele é muito verboso, mas muito rico. Veja um exemplo:

<person>
  <name>John Doe</name>
  <age>30</age>
  <email>[email protected]</email>
  <address>
    <street>123 Main Street</street>
    <city>New York</city>
    <country>USA</country>
  </address>
  <hobbies>
    <hobby>reading</hobby>
    <hobby>traveling</hobby>
    <hobby>cooking</hobby>
  </hobbies>
</person>

Já o formato YAML (ou YML) é bastante utilizado para configurações de sistemas, em devops, ou no kubernetes, etc., mas não habitualmente utilizado para dados. Ele se baseia na posição dos tabs de indentação para indicar se um item pertence a outro. Esse modelo torna o arquivo legível, porém pouco verboso.

name: John Doe
age: 30
email: [email protected]
address:
  street: 123 Main Street
  city: New York
  country: USA
hobbies:
  - reading
  - traveling
  - cooking

Apache Avro

O projeto Apache AVRO é um formato binário de dados, portanto não é feito para leitura humana. Entretanto normalmente é gerado a partir de um documento JSON. Esse formato suporta tipagem com: inteiros, strings, pontos flutuantes, booleanos ou mesmo objetos complexos. Ou seja, ele possui tanto dados quanto o esquema na mesma estrutura.

Por ele ser um formato binário ele é muito eficiente para leitura e escrita, além de ser muito compacto, lidando com tipos complexos. Esse tipo funciona muito bom para lidar com streams de eventos. Veja a seguir a construção de um arquivo AVRO de exemplo.

{
  "type": "record",
  "name": "Person",
  "doc": "Schema for representing information about a person",
  "fields": [
    {
      "name": "name",
      "type": "string",
      "doc": "The name of the person"
    },
    {
      "name": "age",
      "type": "int",
      "doc": "The age of the person"
    },
    {
      "name": "email",
      "type": ["null", "string"],
      "default": null,
      "doc": "The email address of the person (optional)"
    }
  ]
}

Essa é uma aplicação em C# que possui uma classe Person que é serializada em AVRO.

using Avro;
using Avro.Schema;

public class Person
{
    [AvroSchema("name")]
    public string Name { get; set; }

    [AvroSchema("age")]
    public int Age { get; set; }

    [AvroSchema("email")]
    public string Email { get; set; }
}

A seguir veja uma aplicação que escreve os dados em disco de uma Person

using Avro.IO;

// Exemplo de serialização
var person = new Person
{
    Name = "John",
    Age = 30,
    Email = "[email protected]"
};

using (var stream = new MemoryStream())
{
    // Agora, 'avroBytes' contém o objeto serializado em formato AVRO.
    var serializer = AvroSerializer.Create<Person>();
    serializer.Serialize(stream, person);
    byte[] avroBytes = stream.ToArray();
}

// Exemplo de desserialização
using (var stream = new MemoryStream(avroBytes))
{
    // 'deserializedPerson' agora contém o objeto desserializado da classe Person.
    var deserializer = AvroSerializer.Create<Person>();
    var deserializedPerson = deserializer.Deserialize(stream);
}

Apache Parquet

Esse é outro formato muito relevante para o ambiente de bigdata, o Parquet. Esse formato também é binário e se ampara em ser de rápida leitura e escrita, porém ele é chamado de um formato colunar. Ao contrário do Avro, ao invés dele armazenar um item e depois outro, na verdade ele guarda os dados de um coluna inteira e depois armazena outra.

FirstName,Age,Email
John,30,[email protected]
Alice,25,[email protected]
Bob,35,

Vamos considerar como exemplo um banco de dados de pessoas como o que pode ser visto acima. Mas vamos considerar que ele tem 10 milhões de linhas. Note que muitos FirstName irão e repetir, bem como as idades. Ou seja, nesse caso, quando guardo uma coluna eu posso gerar uma grande compressão pela reincidência dos dados.

O formato possui outras estratégias para ter mais eficiência, se dividindo internamente em blocos além de suportar um conceito chamado particionamento. Ele é um formato especialmente útil para lidar com dados tabulares.

Além disso, esse formato é integrável com o Hive, Spark ou Pandas (Python), de modo que ele pode ser facilmente consultado. Em alguns casos ele pode ser consultado com estruturas semelhante ao SQL.

Apache ORC

Enquanto o padrão ORC (Optimized Row Columnar) foi criado pela Hortonworks e o Facebook, o padrão Parquet foi feito pela Cloudera com o Twitter. Ele é um formato colunar mantido pela Apache Foundation, criado para melhorar o desempenho de leitura e escrita em ambientes de bigdata. Ele suporta alta compactação, processamento paralelo (hadoop, spark, etc.), tipos complexos e estatísticas incorporadas (como sum, min, max, desvio, etc.).

RC File

A Apache Foundation mantém o RCFile (Record Columnar File), que é outro padrão binário e colunar. Eles o criaram inicialmente para uso com o Hive, uma plataforma estruturada especialmente para o gerenciamento de Datawarehouses. Este padrão, em particular, se destaca por sua abordagem colunar, o que o torna especialmente vantajoso para consultas e análises em ambientes de Datawarehousing.

O RCFile proporciona uma forma eficiente de armazenar e recuperar informações, tornando-o uma escolha valiosa para lidar com grandes volumes de dados de forma otimizada e ágil. Sua arquitetura colunar permite uma leitura mais eficiente dos dados necessários para as tarefas analíticas, minimizando o esforço de processamento e acelerando as operações de consulta. Isso faz com que o RCFile seja uma peça fundamental no ecossistema do Hive, auxiliando as organizações a obter insights valiosos a partir de suas informações armazenadas em Datawarehouses.

SequenceFile

Esse é mais um formato mantido pela Apache Foundation, mas ele não é colunar. Ele armazena sequencialmente dados de chave-valor. Por ser binário ele é otimizado para o uso em sistemas mas não para leitura humana. Como ele não lida nem com linhas e nem com colunas em si, sua formatação é ligeiramente particular. Ele suporta tipos como inteiros e strings, mas também suporta tipos personalizados.

Conclusão de Formatos de serialização para bigdata

O conceito de bigdata pressupõe a variedade dos tipos de dados. Temos imagens, vídeos, músicas, mas também temos postagens em redes sociais, e temos sistemas tradicionais com dados tabulares. Lidar com essa variedade exige formas diferentes. Os formatos Parquet, Orc e Avro têm especial destaque por serem binários, suportando escritas e leituras rápidas, mesmo com o dado bruto (ou quase). O artigo Formatos de serialização para bigdata fala sobre esses formatos e alguns outros e como eles podem ser utilizados.