Gerenciamento de esquemas

Esta análise detalhada explica como o Zerobus Ingest no Lakeflow Connect valida os registros recebidos em relação ao esquema da sua tabela Delta e como projetar seu esquema para dados parciais ou em evolução.

A tabela é o contrato

O esquema da sua tabela Delta é o contrato autoritativo para o que o Zerobus Ingest aceita. O Zerobus Ingest avalia cada registro em relação a esse contrato, mas você escolhe quão rigoroso ou quão permissivo o contrato é. O mesmo serviço pode impor um esquema rígido, aceitar um subconjunto flexível de colunas ou capturar tudo o que não se encaixa, dependendo de como você define sua tabela.

• O Zerobus Ingest controla os dados. Ele valida cada registro em relação à tabela de destino e rejeita tudo o que não se encaixa. Ele nunca adivinha ou descarta colunas silenciosamente.
• Você define o contrato. Marcar colunas como obrigatórias ou anuláveis, e adicionar uma coluna de resgate, é como você decide o que “se encaixa”.
• O Zerobus Ingest nunca aumenta sua tabela. Ele não adiciona colunas, altera tipos ou evolui o esquema para acomodar um registro. Você evolui o que o Zerobus Ingest aceita evoluindo a tabela, e não o contrário.

A próxima seção mostra três maneiras de moldar esse contrato, desde a mais aceitável até a mais rigorosa e a abrangente.

Como os registros são correspondidos à tabela

Um registro deve se ajustar à tabela de destino: ele deve conter, no mínimo, todas as colunas não anuláveis da tabela. Colunas que são anuláveis na tabela podem ser omitidas do registro e são gravadas como NULL. A omissão de uma coluna anulável é tratada como uma alteração não disruptiva, portanto, você pode adicionar colunas anuláveis a uma tabela e continuar ingerindo registros mais antigos que não as incluem.

O Zerobus Ingest retorna um erro quando um registro não se encaixa na tabela. Isso inclui:

• Uma coluna não anulável ausente.
• Um nome de coluna que não existe na tabela Delta (a menos que você configure uma coluna de resgate).
• Uma coluna cujo tipo não é compatível com a tabela Delta. Para os tipos de dados Delta e Protobuf compatíveis, consulte Tipos de dados compatíveis.

Três maneiras de moldar o contrato

A forma como você define a tabela determina o quão rigorosa ou permissiva é a ingestão. Os três cenários abaixo vão do mais aceitável ao rigoroso e ao abrangente.

Cenário 1: Todas as colunas opcionais (aceitar um subconjunto)

Torne todas as colunas anuláveis. Os produtores podem então enviar qualquer subconjunto das colunas, e as colunas omitidas são gravadas como NULL. Registros que incluem uma coluna que a tabela não possui ainda são rejeitados.

SQL

CREATE TABLE main.default.air_quality (
  device_name STRING,
  temp INT,
  humidity INT);

• {"device_name": "sensor-1", "temp": 22, "humidity": 55}: aceito. Todas as colunas presentes.
• {"device_name": "sensor-1"}: aceito. temp e humidity são anuláveis, portanto, são gravados como NULL.
• {"device_name": "sensor-1", "temp": 22, "region": "us-west"}: rejeitado. region não existe na tabela.

Cenário 2: Colunas obrigatórias (impor campos específicos)

Marque as colunas NOT NULL para torná-las obrigatórias. Todo registro deve fornecer essas colunas, ou será rejeitado. Esta é a extremidade rigorosa do espectro: use-a quando um campo precisar estar sempre presente.

SQL

CREATE TABLE main.default.air_quality (
  device_name STRING NOT NULL,
  temp INT NOT NULL,
  humidity INT);

• {"device_name": "sensor-1", "temp": 22, "humidity": 55}: aceito. Todas as colunas obrigatórias estão presentes.
• {"device_name": "sensor-1", "temp": 22}: aceito. humidity é anulável, portanto, é gravado como NULL.
• {"device_name": "sensor-1"}: rejeitado. temp não é anulável e está ausente.

Cenário 3: Coluna de resgate (capturar todo o resto)

Adicione uma coluna de resgate VARIANT para capturar campos que não se ajustam ao esquema, em vez de rejeitar o registro. Os campos que correspondem à tabela são gravados em suas colunas como de costume. Quaisquer campos extras ou não conformes são agrupados na coluna de resgate como um objeto JSON. Esta é a extremidade mais permissiva do espectro: campos extras e incompatibilidades de tipo em colunas anuláveis são capturados em vez de serem rejeitados. Um registro ainda é rejeitado se omitir uma coluna obrigatória (não anulável), porque a coluna de resgate não pode fornecer um valor que o esquema exige. A coluna de resgate está em versão Beta e atualmente oferece suporte à ingestão em formato JSON.

• {"device_name": "sensor-1", "temp": 22, "region": "us-west"}: aceito. region não existe na tabela, portanto, é capturado na coluna de resgate em vez de ser rejeitado.

Para saber como configurar uma coluna de resgate e as regras exatas, consulte Coluna de resgate do Zerobus.

evolução do esquema

O Zerobus Ingest não evolui automaticamente sua tabela de destino. Quando o formato dos seus dados mudar, evolua a tabela primeiro (por exemplo, com ALTER TABLE) e, em seguida, envie registros para o novo esquema.

Adicionar uma coluna anulável é uma alteração não disruptiva: os produtores existentes que não enviam a nova coluna continuam funcionando, e seus registros recebem NULL para ela. Isso permite que você implemente alterações de esquema e alterações de produtor de forma independente.

Esquema Protobuf

Ao realizar a ingestão com Protocol Buffers (protobuf), a mesma regra de ajuste se aplica à sua definição de mensagem protobuf: ela deve conter, no mínimo, todas as colunas não anuláveis na tabela Delta, e pode omitir as anuláveis.

O seguinte também se aplica ao esquema protobuf:

• O Zerobus Ingest não suporta esquemas proto com mais de 2000 colunas.
• O Zerobus Ingest oferece suporte apenas a nomes de tabela e coluna com letras ASCII, dígitos e underscores.
• O Zerobus Ingest não suporta o uso de um esquema proto diferente para operações de "criação de transmissão" e "ingestão de registro".