O time de analytics quer consultar direto os arquivos JSON de eventos na camada analítica, para não esperar o pipeline. Qual sua posição?

Eu entendo a pressa, mas seria caro e frágil. JSON é texto: cada consulta reparsa registro por registro, não há compressão colunar, não dá para ler só as colunas necessárias e não existe estatística por arquivo para o motor pular blocos. Na prática, a mesma pergunta custa várias vezes mais que sobre uma tabela Delta, e o custo aparece toda vez que alguém roda. Além disso, sem schema declarado, cada analista interpreta o aninhamento do seu jeito e os números começam a divergir. Minha proposta é entregar rápido o que eles precisam: uma tabela Delta na trusta com o núcleo estável achatado, particionada por data, e o que for genuinamente variável em um campo de mapa. Se a urgência for de horas, eu crio uma view temporária sobre a raw, com prazo e dono definidos, e trato como dívida com data de vencimento, não como arquitetura.

Tipos de dados

Tipos de dados · tema 16 de 30

JSON

Q: Como você trata um JSON cujo schema muda sem aviso?

Primeiro eu paro de tratar isso como incidente: campo novo é o comportamento normal de um produtor de eventos, então o pipeline precisa ter política definida antes de acontecer. Na raw eu guardo o JSON cru, então nunca perco a versão original. Na leitura eu declaro o schema em vez de inferir, porque inferência muda de resultado conforme a amostra e me dá tipos diferentes em dias diferentes. O que não bate com o contrato vai para uma coluna de dado resgatado, em vez de ser descartado: o pipeline não quebra, o dado não some e eu ganho um sinal de que a origem mudou. Aí eu separo os casos: campo novo opcional gera alerta e entra no contrato quando o negócio precisar dele; campo obrigatório ausente ou mudança de tipo em campo do núcleo eu falho ou quarentena, porque deixar passar com nulo propaga erro silencioso. E fecho o ciclo com contrato de dados versionado e conversa com o time produtor, que é a parte que resolve de verdade.

32 min · 2 vídeos · 13 cards · 2 drill

Por que cai

Praticamente toda ingestão de evento no banco chega em JSON: autorização de cartão, evento de app, resposta de API interna. A banca usa o tema para chegar em evolução de schema, que é o problema que mais quebra pipeline em produção.

Pré-teste · 1 de 2

responda antes de ver

Um pipeline lê JSON de eventos com inferência de schema. Numa madrugada, o campo 'valor' passa a chegar como texto em alguns registros. O que tende a acontecer?

Confiança:

Vídeo · português · 7 min

Base rápida de sintaxe e propósito, para você não gastar tempo no que já sabe. Vá direto ao segundo vídeo se a parte conceitual já estiver resolvida.

Em uma frase

JSON é um formato de texto auto-descrito e hierárquico que virou o padrão de troca entre sistemas, e o trabalho da engenharia de dados é transformá-lo em tabela colunar sem perder o original nem quebrar quando o schema muda.

Por que ele venceu

JSON tem seis tipos: string, número, booleano, null, objeto e array. Só isso. A simplicidade é o argumento: um objeto JSON mapeia direto em dicionário e lista nas linguagens usadas em API web, então o custo de adotar é quase zero.

Note duas ausências que causam problema em banco: não existe tipo de data, que trafega como string por convenção, e não existe decimal exato, o que exige cuidado ao tipar valor monetário para não herdar erro de ponto flutuante.

JSON Schema: o contrato que quase ninguém escreve

JSON Schema descreve a estrutura esperada de um documento: campos obrigatórios, tipos, formatos e restrições. É o equivalente ao XSD do mundo XML.

Ele raramente vem pronto de um produtor interno. Quando não vem, o substituto prático é um conjunto de regras de qualidade na ingestão: campo obrigatório presente, tipo esperado, domínio permitido e volume dentro da faixa. O ponto não é a ferramenta; é ter contrato.

Aninhamento: struct e array não são a mesma coisa

Estrutura	Como tratar	Efeito na tabela
Objeto (struct)	Selecionar por caminho e achatar em colunas nomeadas	Número de linhas não muda
Array	Explode: uma linha por elemento	Muda a granularidade da tabela
Parte genuinamente variável	Mapa ou string JSON preservada	Mantém flexibilidade sem criar coluna por variação

JSON no Spark: declare o schema

Inferência de schema é conveniente no notebook e perigosa em produção, por dois motivos. Ela custa uma passada extra pelos dados, o que pesa em volume alto. E ela depende da amostra: se numa madrugada alguns registros vierem com o campo valor como texto, o tipo resolvido muda, e o mesmo pipeline entrega contratos diferentes em dias diferentes.

Declarar o schema transforma isso em algo visível: o que não bate vira erro ou vai para uma coluna de dado resgatado— Coluna onde o leitor guarda os campos que não batem com o schema declarado, para que nada se perca e a mudança de origem fique registrada.

Sobre o formato do arquivo: prefira JSON Lines, um objeto completo por linha. É o que permite dividir o arquivo em blocos e ler em paralelo. Um documento multiLine grande precisa ser lido por uma tarefa só e vira gargalo.

Evolução de schema: o problema de verdade

Campo novo não é incidente, é rotina de quem consome evento. A política precisa existir antes:

1Grave o JSON cru na raw, sempre: é o que permite reprocessar depois de descobrir a mudança.
2Declare o schema na leitura e resgate o desconhecido em vez de descartar.
3Campo novo opcional: alerte o dono do dado e promova ao contrato só quando o negócio precisar.
4Campo obrigatório ausente ou tipo alterado no núcleo: falhe ou quarentene, nunca preencha com nulo em silêncio.
5Versione o contrato e leve a mudança para o time produtor: é lá que o problema se resolve de fato.

Quando NÃO guardar JSON cru na camada analítica

A única exceção razoável é o trecho genuinamente variável do documento, que pode viver em uma coluna de mapa ou string. Modele o núcleo estável em colunas tipadas e deixe o caso raro fora do caminho do consumidor comum.

Se quiser outro ângulo

É a parte que a sabatina cobra: leitura no Spark, schema, aninhamento e achatamento. Assista com o código aberto e repita o explode em um exemplo seu.

Como cai na sabatina

“Como você trata um JSON cujo schema muda sem aviso?”

Erros comuns

Deixar o Spark inferir o schema em produção. Inferência custa uma passada extra pelos dados e, pior, muda de resultado quando a amostra muda: o mesmo pipeline entrega tipos diferentes em dias diferentes.
Guardar JSON cru na camada analítica. Ler JSON é caro: parsing linha a linha, sem compressão colunar, sem estatística por arquivo e sem data skipping. Cru é para a raw; a trusted é colunar.
Confundir array com struct. Struct vira colunas aninhadas e se resolve com seleção por caminho; array precisa de explode e multiplica linhas, o que muda a granularidade da tabela.
Tratar campo novo como incidente. Campo novo é o comportamento normal de um produtor de eventos; o pipeline precisa ter uma política para isso antes de acontecer.
Achar que JSON Lines é um formato diferente de JSON. É a convenção de um objeto JSON completo por linha, que é o que permite ler o arquivo em paralelo e por pedaços.
Deixar o campo aninhado inteiro como string para 'resolver depois'. Depois vira nunca, e o consumidor acaba parseando string em SQL, que é o pior lugar para fazer isso.

Flashcards

Card 1 de 13

0 certos · 0 a rever

Drill

Struct, array ou campo variável?

Para cada estrutura de um evento de autorização de cartão, diga como você modelaria na trusted e por quê.

1.Objeto 'cartao' com bin, bandeira e ultimos_digitos.
2.Array 'parcelas', com número e valor de cada parcela.
3.Objeto 'metadados_adquirente', diferente para cada adquirente e sem contrato.
4.Campo 'valor' com o montante autorizado.
5.Array 'tags_antifraude' com rótulos aplicados pelo motor de regras.

Drill

O schema mudou. O que você faz?

Diga a conduta para cada mudança, pensando em não derrubar consumidor e em não perder dado.

1.Chegou um campo novo, opcional, que ninguém pediu.
2.Um campo obrigatório sumiu dos eventos.
3.O campo 'valor' passou de número para texto em parte dos registros.
4.O produtor renomeou um campo sem avisar.

Quiz · 1 de 2

Por que JSON Lines importa para processamento distribuído?

Explique para um gerente

Explique para o time de produto por que o campo novo que eles adicionaram na API derrubou o painel, sem culpar ninguém e propondo o que fazer.

Responda em voz alta antes de seguir. Se travar numa palavra técnica, é sinal de que ainda não entendeu essa parte.

Perguntas de sabatina deste tema

· Como você trata um JSON cujo schema muda sem aviso?
· O time de analytics quer consultar direto os arquivos JSON de eventos na camada analítica, para não esperar o pipeline. Qual sua posição?

Responder no simulado

Para ir além

PróximoGovernança de dados