Conceitos de ingestão do Zerobus

Esta página descreve os conceitos centrais do Zerobus Ingest no Lakeflow Connect: como funciona o serviço, os seus fluxos, servidor e clientes, e os tipos de dados que suporta.

Vamos direto a um conceito:

• Como funciona o Zerobus Ingest: o fluxo de ponta a ponta, do produtor até à tabela consultável.
• Servidor: pelo que o serviço Zerobus Ingest é responsável.
• Cliente: pelo que o seu produtor é responsável.
• Streams: a ligação que o seu cliente abre para ingerir dados.
• Como o Zerobus Ingest escala: porque é que escala sem planeamento de capacidade.
• Requisitos da mesa: o que a sua mesa e espaço de trabalho alvo devem cumprir.
• Tipos de dados suportados: o mapeamento do tipo Delta-para-Protobuf.

Como funciona o Zerobus Ingest

Um produtor de dados abre primeiro um fluxo para a API Zerobus Ingest e especifica uma tabela Delta alvo, constrói uma mensagem que corresponde ao seu esquema e depois envia a mensagem através do fluxo aberto. O serviço torna os dados duráveis e reconhece a mensagem do cliente. Depois, materializa os dados na tabela Delta, de forma otimizada, como um passo separado. O reconhecimento confirma a durabilidade, não a possibilidade de consulta. Veja Comunicação Assíncrona para saber como isto funciona e o que significa para o seu cliente.

O Zerobus Ingest é um serviço serverless que escala elasticamente com a sua carga de trabalho. Para saber como escala, veja Como o Zerobus Ingest escala abaixo.

Esta secção também aborda as formas como se liga ao Zerobus Ingest e as formas que os seus dados podem assumir:

• Protocolos API: Os protocolos API, gRPC com SDKs, REST e OpenTelemetry, e quando usar cada um.
• Tipos de mensagem: Os formatos de registo, JSON, Protocol Buffers (protobuf) e Apache Arrow, e quando usar cada um.

Server

O serviço Zerobus Ingest não cria nem manipula automaticamente tabelas. Os utilizadores devem criar a tabela eles próprios. As tabelas e os seus esquemas são as fontes de referência para as expectativas dos dados recebidos.

O servidor Zerobus Ingest aceita os dados enviados pelos clientes e valida que se enquadram no esquema da tabela de destino. Se o registo encaixar, o servidor torna-o durável e reconhece-o ao cliente. Materializar o registo na tabela Delta, para que se torne consultável, ocorre como uma etapa separada pouco depois.

As responsabilidades do serviço incluem:

• Validação do esquema da mensagem em relação à tabela.
• Tornar o disco durável e reconhecê-lo perante o cliente. O reconhecimento confirma a durabilidade, embora o registo ainda não seja consultável.
• Materializar os dados na tabela alvo de forma atempada, que é quando se tornam consultáveis. Para valores de latência, veja Latência.

Client

Um cliente liga-se ao Zerobus Ingest, envia registos e confirma que são duráveis. Quando usas um SDK Zerobus Ingest, o SDK trata da maior parte disto por ti, por isso ajuda separar automaticamente o que configuras do que o SDK faz.

Você configura ou implementa:

• Seleção de uma tabela de destino.
• Abrir um stream para o serviço Zerobus Ingest.
• Construir uma mensagem compatível com o esquema e enviá-la.

O SDK gere automaticamente:

• Confirmações de receção de mensagens. O SDK gere o ciclo de confirmação por si só e disponibiliza confirmações de durabilidade através de offsets ou de um callback de confirmação. Só bloqueia um registo específico quando a sua aplicação precisa disso. Ver Comunicação assíncrona.
• Recuperação Por defeito, o SDK restabelece a ligação e reenvia registos não confirmados em caso de falhas transitórias.
  • Podes desligar a recuperação incorporada e implementar o teu próprio mecanismo de recuperação. Para saber o que desencadeia a recuperação, as opções de configuração e os padrões de recuperação personalizados, consulte Recuperação e padrões de repetição.

Não é necessário escrever à mão a lógica de reconhecimento ou recuperação quando usa um SDK. Para integrações personalizadas que não utilizam SDK, o repositório Zerobus SDK é uma referência para estrutura de integração e gestão de recuperação.

Fluxos

Um stream é uma ligação direta entre o seu cliente e o servidor Zerobus Ingest, estabelecida através de uma ligação gRPC persistente e bidirecional. Os SDKs utilizam fluxos para facilitar ligações duradouras e de alto rendimento.

• Os fluxos são usados apenas na API gRPC com os SDKs.
• Um fluxo ingere dados para uma única tabela alvo.
• Abre fluxos adicionais para escrever em diferentes tabelas, ou para escalar o throughput de um único cliente ao máximo que a tua carga de trabalho exigir.

Os fluxos são também a unidade de ordenação (ver Garantias de ordenação) e a unidade pela qual o Zerobus Ingest escala ( ver Como o Zerobus Ingest escala).

Garantias de encomenda

A encomenda é garantida por stream. Os registos são gravados na tabela de destino pela ordem em que são colocados em fila num único fluxo. Não existe uma ordenação global entre os fluxos. Seguem-se vários pontos de design a partir disto:

• Se distribuir os registos por vários fluxos (por exemplo, round-robin), não há garantia de ordenação entre esses fluxos.
• Se o seu caso de uso exigir uma única ordenação total entre vários produtores ou fluxos, garanta essa ordenação na sua aplicação (por exemplo, com uma marca temporal ou um número de sequência pelos quais possa consultar), em vez de depender da ordem de ingestão.

Porquê o streaming do gRPC

Como a ligação gRPC de um fluxo permanece aberta, o cliente evita o custo de configuração associado a cada pedido de um protocolo sem estado e pode enviar um fluxo contínuo e de alto volume de registos através de um único canal. É isto que torna os SDKs a forma de ingerir com maior rendimento. Para as outras interfaces (REST e OpenTelemetry) e quando escolher cada uma, veja protocolos API.

Como o Zerobus Ingest se dimensiona

O Zerobus Ingest foi concebido para uma elevada escalabilidade e atinge essa escala sem exigir que planeie a capacidade. Duas escolhas de design tornam isto possível:

• É sem servidor. O serviço adiciona e remove capacidade automaticamente à medida que a carga varia, pelo que não precisa de dimensionar os brokers nem de aprovisionar partições. Podes abrir tantos fluxos concorrentes e escrever em tantas tabelas quanto a tua carga de trabalho precisar.
• Os fluxos são unidades de partição dinâmica. Em vez de um conjunto fixo de partições que precisam de ser reparticionadas e reequilibradas para aumentar a escala, os fluxos podem ser abertos, fechados e rotacionados. Rotacionar fluxos permite que o serviço reequilibre a capacidade e os recursos à medida que a procura muda, por isso escalas abrindo mais fluxos e operando mais produtores enquanto o serviço absorve o resto.

O resultado prático é que um cliente "hello world" e uma carga de trabalho à escala de petabytes executam essencialmente o mesmo código. A diferença está no número de produtores e streams que geres. Esta arquitetura suportou a ingestão sustentada de mais de 1 bilião de registos numa única tabela Delta. Para o contexto técnico, veja o artigo do blogue Ingerir a Via Láctea: Petabyte-Scale com o Zerobus Ingest .

Requisitos da tabela

O Zerobus Ingest escreve numa tabela Delta que tu crias e possui. A mesa e o espaço de trabalho alvo devem cumprir estes requisitos:

• O Zerobus Ingest escreve apenas para tabelas Delta geridas. A escrita para armazenamento predefinido não é suportada.
• O Zerobus Ingest não escreve em armazenamento protegido através de um endpoint privado.
• O Zerobus Ingest não suporta a recriação de uma tabela de alvo.
• Os nomes das tabelas suportam apenas letras, dígitos e sublinhados ASCII.
• O espaço de trabalho e a tabela de destino devem estar ambos numa das regiões suportadas.

Para saber como os registos são validados em relação ao esquema da tabela, veja Gestão de esquemas. Para funcionalidades de tabela como particionamento e agrupamento de líquidos, veja características de tabela Delta.

Tipos de dados suportados

A tabela seguinte mostra os tipos Delta suportados e os respetivos tipos Protobuf para ingestão.