Conceitos do Zerobus Ingest
Esta página descreve os conceitos fundamentais do Zerobus Ingest no Lakeflow Connect: como o serviço funciona, suas transmissões, servidor e clientes, e os tipos de dados que ele oferece suporte.
Ir para um conceito:
- Como o Zerobus Ingest funciona: o fluxo de ponta a ponta, do produtor à tabela consultável.
- Servidor: do que o serviço Zerobus Ingest é responsável.
- Cliente: do que seu produtor é responsável.
- Transmissões: a conexão que seu cliente abre para ingerir dados.
- Como o Zerobus Ingest escala: por que ele escala sem planejamento de capacidade.
- Requisitos de tabela: o que sua tabela de destino e seu workspace devem satisfazer.
- Limitações: tipos de tabela incompatíveis, operações de tabela e ordenação entre transmissões.
- Tipos de dados compatíveis: o mapeamento de tipos de Delta para Protobuf.
Como o Zerobus Ingest funciona
Primeiro, um produtor de dados se conecta a uma API do Zerobus Ingest e especifica uma tabela Delta de destino, constrói uma mensagem que corresponde ao seu esquema e, em seguida, envia a mensagem. O serviço torna os dados duráveis e, para interfaces que fornecem confirmações de durabilidade, envia uma confirmação para a mensagem do cliente. Em seguida, ele materializa os dados na tabela Delta, de forma otimizada, como um passo separado. Uma confirmação de durabilidade confirma a durabilidade, não a capacidade de consulta. Consulte Comunicação assíncrona para saber como isso funciona e o que significa para o seu cliente.
O Zerobus Ingest é um serviço serverless que escala elasticamente com sua carga de trabalho. Para saber como ele escala, consulte Como o Zerobus Ingest escala abaixo.
Esta seção também aborda as maneiras de se conectar ao Zerobus Ingest e os formatos que seus dados podem assumir:
- Protocolos de API: os protocolos de API, gRPC com SDKs, REST, OpenTelemetry, MQTT e APIs compatíveis com Kafka, 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. As tabelas e seus esquemas são as fontes autoritativas para as expectativas de dados recebidos.
O servidor Zerobus Ingest aceita dados enviados a ele por clientes e valida se eles se ajustam ao esquema da tabela de destino. Se o registro se encaixar, o servidor o tornará durável e, quando a interface fornecer uma confirmação de durabilidade, confirmará isso ao cliente. A materialização do registro na tabela Delta, para que ela possa ser consultada, ocorre como o passo separado pouco depois.
As responsabilidades do serviço incluem:
- Validação do esquema da mensagem em relação à tabela.
- Tornar o registro durável e, quando a interface fornecer uma confirmação de durabilidade, confirmá-la ao cliente. A confirmação confirma a durabilidade, mas não se o registro já pode ser consultado.
- Materialização dos dados na tabela de destino de maneira oportuna, que é quando eles se tornam consultáveis. Para números de latência, consulte Latência.
Cliente
A client connects to Zerobus Ingest, sends records, and, when the interface supports it, confirms they are durable. When you use a Zerobus Ingest SDK, the SDK handles most of this for you, so it helps to separate what you configure from what the SDK does automatically.
Você configura ou implementa:
- Selecionando uma tabela de destino.
- Abrindo uma transmissão para o serviço Zerobus Ingest.
- Construção de uma mensagem compatível com o esquema e seu envio.
O SDK lida automaticamente com:
- Reconhecimentos de mensagem. O SDK executa o loop de reconhecimento para você e apresenta confirmações de durabilidade por meio de offsets ou um callback de reconhecimento. Você só bloqueia em um registro específico quando sua aplicação precisa. Consulte Comunicação assíncrona.
- Recuperação. Por default, o SDK reconecta e repete registros não confirmados em falhas transitórias.
- Você pode desativar a recuperação integrada 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 de recuperação personalizados, consulte Padrões de recuperação e repetição.
Você não precisa escrever manualmente a lógica de confirmação ou recuperação ao usar um SDK. Para integrações personalizadas que não usam um SDK, o repository do Zerobus SDK serve como referência para a estrutura de integração e o tratamento de recuperação.
Stream
Uma transmissão é 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 usam transmissões para facilitar conexões de longa duração e alto throughput.
- As transmissões são usadas apenas na API gRPC com os SDKs.
- Uma transmissão ingere dados em uma única tabela de destino.
- Abra transmissões adicionais para gravar em tabelas diferentes ou para escalar o throughput de um único cliente conforme a necessidade da sua carga de trabalho.
As transmissões também são a unidade de ordenação (consulte Garantias de ordenação) e a unidade pela qual o Zerobus Ingest escala (consulte Como o Zerobus Ingest escala).
Garantias de ordenação
A ordenação é garantida por transmissão. Os registros são confirmados na tabela de destino na ordem em que são enfileirados em uma única transmissão. Não há ordenação global entre transmissões. Vários pontos de design decorrem disso:
- Se você distribuir registros entre várias transmissões (por exemplo, round-robin), não haverá garantia de ordenação entre essas transmissões.
- Se o seu caso de uso exigir uma ordem total única entre muitos produtores ou transmissões, aplique essa ordenação em sua aplicação (por exemplo, com um timestamp ou número de sequência no qual você faz uma query) em vez de depender da ordem de ingestão.
Por que usar a transmissão gRPC
Como a conexão gRPC de uma transmissão permanece aberta, o cliente evita o custo de configuração por request de um protocolo sem estado e pode enviar um fluxo contínuo e de alto volume de registros por um único canal. É isso que torna os SDKs a opção com o maior throughput para ingestão. Para as outras interfaces (REST, OpenTelemetry, MQTT e APIs compatíveis com Kafka) e para saber quando escolher cada uma, consulte API protocols.
Como o Zerobus Ingest escala
O Zerobus Ingest foi projetado para alta escalabilidade e atinge essa escala sem exigir que você planeje a capacidade. Duas escolhas de design tornam isso possível:
- É serverless. O serviço adiciona e remove capacidade automaticamente conforme a carga muda, portanto, você não precisa dimensionar brokers ou realizar o provisionamento de partições. Você pode abrir quantas transmissões concorrentes quiser e gravar em quantas tabelas sua carga de trabalho precisar.
- As transmissões são unidades de particionamento dinâmico. Em vez de um conjunto fixo de partições que deve ser reparticionado e rebalanceado para escalar, as transmissões podem ser abertas, fechadas e rotacionadas. A rotação de transmissões permite que o serviço rebalanceie a capacidade e os recursos conforme a demanda muda, de modo que você escala abrindo mais transmissões e executando 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 de petabytes executam essencialmente o mesmo código. A diferença é quantos produtores e transmissões você executa. Este design sustentou a ingestão de mais de 1 trilhão de registros em uma única tabela Delta. Para obter o contexto técnico, consulte a postagem no blog Ingesting the Milky Way: Petabyte-escala with Zerobus Ingest.
Requisitos da tabela
O Zerobus Ingest grava em uma tabela Delta que você cria e possui. A tabela de destino e o workspace devem atender a estes requisitos:
- A tabela de destino deve ser uma tabela Delta gerenciada ou uma tabela de transmissão.
- Os nomes das tabelas devem usar apenas letras ASCII, dígitos e underscores.
- O Workspace e a tabela de destino devem estar em uma das regiões suportadas.
Para saber como os registros são validados em relação ao esquema da tabela, consulte Gerenciamento de esquemas. Para recursos de tabela como particionamento e clustering líquido, consulte Recursos de tabela Delta. Para ver os tipos de tabela e operações sem suporte, consulte Limitations.
Limitações
O Zerobus Ingest tem as seguintes limitações:
- Zerobus Ingest não grava em tabelas ou views externas.
- O Zerobus Ingest não grava no armazenamento protegido por meio de um endpoint privado.
- O Zerobus Ingest não cria tabelas de destino nem altera o esquema delas. Você cria a tabela e evolui seu esquema. Consulte evolução do esquema.
- O Zerobus Ingest não oferece suporte à recriação de uma tabela de destino.
- O Zerobus Ingest não oferece suporte à renomeação ou substituição de uma tabela de destino enquanto a ingestão estiver ativa. Consulte Renomear ou substituir uma tabela de destino.
- O Zerobus Ingest não oferece suporte a nomes de tabela que contenham caracteres que não sejam letras ASCII, dígitos e underscores.
- O Zerobus Ingest não garante a ordenação entre transmissões. A ordenação é garantida apenas em uma única transmissão. Consulte Garantias de ordenação.
Para limites numéricos como throughput, tamanho do registro e distribuição de partições (fan-out), consulte as cotas do Zerobus Ingest.
Renomear ou substituir uma tabela de destino
Não renomeie, remova e recrie ou substitua uma tabela de destino por outro objeto, como uma view, enquanto as transmissões estiverem gravando nela. O Zerobus Ingest não pode descarregar os dados armazenados em buffer para uma tabela que foi renomeada ou substituída, portanto, as transmissões afetadas param de progredir e os registros que ainda não foram confirmados não podem ser descarregados. Os dados que permanecem sem descarga são excluídos após o período de retenção de dados em buffer.
Alterações de esquema, como a adição de uma coluna com ALTER TABLE, são compatíveis. Consulte Evolução do esquema.
Para renomear ou migrar uma tabela de destino com segurança:
- Pare seus produtores, limpe (flush) e feche cada transmissão que grava na tabela. Consulte Liberação (flushing) e fechamento elegante.
- Confirme se os registros mais recentes aparecem na tabela.
- Renomear ou migrar a tabela.
- Conceda ao service principal que ingere os dados
USE CATALOG,USE SCHEMA,SELECTeMODIFYna nova tabela. Consulte Criar um service principal e conceder permissões. - Atualize seus produtores para usar o novo nome da tabela e, em seguida, abra novas transmissões. Se os seus produtores solicitarem tokens OAuth com escopo para uma tabela, solicite-os para a nova tabela.
Tipos de dados compatíveis
A tabela a seguir mostra os tipos Delta compatíveis e seus tipos Protobuf correspondentes para ingestão.
Tipos Delta | Tipos Protobuf |
|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
Texto decimal, por exemplo, "123.45", "1e2", etc. |
|
|
|
|
|
|
|
Deve ser convertido para |
|
Deve ser convertido para |
|
Deve ser convertido para |
|
|
|
|
O açúcar sintático |
|
|
Por meio dos SDKs gRPC e REST, ingira um valor Variant como uma strings codificada em JSON com chaves do tipo Formatos compatíveis incluem:
|
|