Conceitos do Zerobus Ingest

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

Vá direto a um conceito:

• Como funciona o Zerobus Ingest: o fluxo de ponta a ponta, do produtor até a tabela consultável.
• Servidor: pelo que o serviço Zerobus Ingest é responsável.
• Cliente: aquilo pelo qual seu produtor é responsável.
• Streams: a conexão que seu cliente abre para ingerir dados.
• Como o Zerobus Ingest escala: por que ele escala sem planejamento de capacidade.
• Requisitos da mesa: o que sua mesa e espaço de trabalho alvo devem atender.
• Tipos de dados com suporte: mapeamento do tipo Delta para Protobuf.

Como funciona o Zerobus Ingest

Um produtor de dados primeiro abre um fluxo para a API Zerobus Ingest e especifica uma tabela Delta de destino, constrói uma mensagem de acordo com seu esquema e, em seguida, envia a mensagem por esse fluxo. 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 uma etapa separada. O reconhecimento confirma durabilidade, não possibilidade de consulta. Veja Comunicação Assíncrona para saber como isso funciona e o que isso significa para seu cliente.

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

Esta seção também aborda as formas como você se conecta ao Zerobus Ingest e as formas que seus dados podem assumir:

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

Servidor

O serviço Zerobus Ingest não cria ou manipula tabelas automaticamente. Os usuários devem criar a tabela por conta própria. Tabelas e seus esquemas são as fontes autoritativas para as expectativas dos dados de entrada.

O servidor Zerobus Ingest aceita dados enviados por clientes e valida que eles se encaixam no esquema da tabela de destino. Se o registro se encaixar, o servidor o torna persistente e o reconhece para o cliente. Materializar o registro na tabela Delta, para que ele se torne consultável, ocorre como uma etapa separada logo em seguida.

As responsabilidades de serviço incluem:

• Validação do esquema da mensagem em relação à tabela.
• Tornando o registro persistente e confirmando isso ao cliente. O reconhecimento confirma a durabilidade, não que o registro ainda seja consultável.
• Materializar os dados na tabela de destino de forma oportuna, que é quando eles passam a ser consultados. Para números de latência, veja Latência.

Client

Um cliente se conecta ao Zerobus Ingest, envia registros e confirma que são duráveis. Quando você usa o SDK de ingestão da Zerobus, ele cuida da maior parte disso para você, então é útil separar aquilo que você configura daquilo que o SDK faz automaticamente.

Você configura ou implementa:

• Selecionando uma tabela de destino.
• Abrindo um fluxo para o serviço Zerobus Ingest.
• Construir uma mensagem compatível com o esquema e enviá-la.

O SDK lida automaticamente:

• Confirmações de recebimento de mensagens. O SDK executa o loop de confirmação para você e fornece confirmações de durabilidade por meio de offsets ou de um retorno de chamada de confirmação. Você só bloqueia um registro específico quando sua aplicação precisa disso. Veja Comunicação assíncrona.
• Recuperação. Por padrão, o SDK reconecta e reproduz registros não confirmados em falhas transitórias.
  • Você pode desligar a recuperação embutida e implementar seu próprio mecanismo de recuperação. Para saber o que aciona a recuperação, as opções de configuração e os padrões personalizados de recuperação, consulte Padrões de recuperação e nova tentativa.

Você não precisa escrever à mão a lógica de confirmação ou recuperação ao usar um SDK. Para integrações personalizadas que não usam SDK, o repositório Zerobus SDK é uma referência para estrutura de integração e gerenciamento de recuperação.

Fluxos

Um stream é uma conexão direta entre seu cliente e o servidor Zerobus Ingest, estabelecida por meio de uma conexão gRPC persistente e bidirecional. Os SDKs utilizam fluxos para facilitar conexões de longa duração e alta taxa de transferência.

• Os fluxos são usados apenas na API gRPC com os SDKs.
• Um fluxo de dados ingere dados em uma única tabela de destino.
• Abra transmissões adicionais para gravar em tabelas diferentes ou para dimensionar a taxa de transferência de um único cliente até o nível que sua carga de trabalho exigir.

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

Garantias de pedido

A ordenação é garantida por transmissão. Os registros são gravados na tabela de destino na ordem em que são enfileirados em uma única transmissão. Não existe uma ordem global entre os fluxos. Vários pontos de design decorrem disso:

• Se você espalhar os registros entre várias transmissões (por exemplo, round-robin), não há garantia de ordenação entre essas transmissões.
• Se o seu caso de uso exigir uma única ordem total entre muitos produtores ou transmissões, imponha essa ordenação no seu aplicativo (por exemplo, com um carimbo de data/hora ou um número de sequência usado nas consultas) em vez de depender da ordem de ingestão.

Por que transmitir gRPC

Como a conexão gRPC de uma transmissão permanece aberta, o cliente evita o custo de configuração por requisição de um protocolo sem estado e pode enviar um fluxo contínuo e de alto volume de registros por um único canal. É isso que faz com que os SDKs sejam a maneira com maior taxa de transferência para ingestão. Para as outras interfaces (REST e OpenTelemetry) e quando escolher cada uma, veja Protocolos API.

Como o Zerobus Ingest é dimensionado

O Zerobus Ingest foi projetado para alta escalabilidade, e alcança essa escala sem precisar que você planeje a capacidade. Duas escolhas de design tornam isso possível:

• É sem servidor. O serviço adiciona e remove capacidade automaticamente conforme a carga varia, assim, você não precisa dimensionar os brokers nem provisionar partições. Você pode abrir tantos fluxos simultâneos quanto sua carga de trabalho exigir e gravar em tantas tabelas quanto necessário.
• Streams são unidades de particionamento dinâmico. Em vez de um conjunto fixo de partições que precisam ser reparticionadas e rebalanceadas para se expandir, as transmissões podem ser abertas, fechadas e rotacionadas. Rotacionar fluxos permite que o serviço reequilibre a capacidade e os recursos conforme a demanda muda, então você escala abrindo mais fluxos e operando mais produtores enquanto o serviço absorve o restante.

O resultado prático é que um cliente "hello world" e uma carga de trabalho em escala petabyte rodam essencialmente o mesmo código. A diferença está em quantos produtores e streams você administra. Essa arquitetura suportou a ingestão contínua de mais de 1 trilhão de registros em uma única tabela Delta. Para o embasamento técnico, consulte a postagem do blog Ingesting the Milky Way: Petabyte-Scale with Zerobus Ingest.

Requisitos da tabela

O Zerobus Ingest grava dados em uma tabela Delta que você cria e administra. A mesa e o espaço de trabalho alvo devem atender a estes requisitos:

• O Zerobus Ingest escreve apenas em tabelas Delta gerenciadas. Não há suporte para gravar no armazenamento padrão.
• O Zerobus Ingest não grava em um armazenamento protegido por meio de um endpoint privado.
• O Zerobus Ingest não oferece suporte à recriação de uma tabela de destino.
• 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 em uma das regiões suportadas.

Para saber como os registros são validados em relação ao esquema da tabela, veja Gerenciamento de esquemas. Para recursos de tabela, como particionamento e agrupamento líquido, consulte Recursos de tabela Delta.

Tipos de dados com suporte

A tabela a seguir mostra os tipos Delta compatíveis e os tipos Protobuf correspondentes para ingestão.