Tipos de dados
Folha de revisão · 3 temas · Engenharia de Dados
Feita para a véspera. Imprimir esta página tira o menu e as abas.
Classificação de tipos de dados
É pergunta de abertura fácil de responder mal. Quem lista os três tipos e para aí perde a repergunta, que é sempre 'e o que muda na prática?'. A resposta forte liga classificação a armazenamento, modelagem, cálculo permitido e controle de acesso.
Como cai: Como você armazenaria e consultaria um dado semiestruturado?
Erros comuns
- Chamar JSON e XML de dados não estruturados. Eles são semiestruturados: não têm tabela fixa, mas carregam a própria estrutura em tags e chaves, e é justamente isso que permite consultá-los.
- Confundir tipo de dado do banco com natureza da variável. CPF é armazenado como texto ou número, mas é qualitativo nominal: somar, tirar média ou ordenar não produz informação.
- Achar que dado não estruturado não pode ser analisado. Pode, depois de virar representação estruturada: transcrição de áudio, texto extraído de PDF, embedding de imagem.
- Ignorar a classificação por sensibilidade. Em banco, saber que um campo é dado pessoal muda zona, criptografia, mascaramento e retenção; sem isso o desenho técnico está incompleto.
- Tratar ordinal como quantitativo. Rating de crédito de A a E tem ordem, mas a distância entre A e B não é comparável à distância entre D e E, então média não significa nada.
- Guardar tudo como texto para 'não dar problema'. Perde-se validação, compressão colunar, poda de partição e a chance de o motor pular arquivos pela estatística.
Vocabulário
- dado pessoal sensível
- — Dado sobre origem racial ou étnica, convicção religiosa, opinião política, filiação sindical ou a organização religiosa, filosófica ou política, saúde, vida sexual, além de dado genético ou biométrico ligado a uma pessoa natural.
XML
Cai como pergunta de realidade, não de teoria: o banco tem integração legada e obrigação fiscal em XML. Quem responde 'XML é coisa antiga' mostra que nunca abriu um arquivo de retorno; quem cita nota fiscal e mensageria mostra que conhece o terreno.
Como cai: Onde você ainda encontraria XML dentro de um banco hoje?
Erros comuns
- Dizer que XML é dado não estruturado. É semiestruturado: a estrutura vem nas próprias tags, e é isso que permite validar e consultar por campo.
- Confundir elemento com atributo. Elemento é o nó que carrega conteúdo e pode ter filhos; atributo é um par nome e valor dentro da tag de abertura, sem filhos. Muita integração antiga usa atributo onde hoje se usaria campo.
- Ignorar namespace. Arquivo fiscal e de mensageria financeira declaram namespace, e um parser configurado sem ele simplesmente não acha os nós.
- Achar que XML morreu. Perdeu espaço em API nova, mas segue obrigatório em documento fiscal eletrônico e presente em padrões de mensageria financeira.
- Ler XML linha a linha com expressão regular. XML é hierárquico e permite aninhamento arbitrário; parser de verdade ou leitor nativo do Spark, nunca regex.
Vocabulário
- XSD
- — XML Schema Definition: o arquivo que declara a estrutura esperada do documento, com tipos e obrigatoriedade, permitindo rejeitar o que não obedece.
JSON
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.
Como cai: 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.
Vocabulário
- 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.