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.
- Tipos de dados compatíveis: o mapeamento de tipos de Delta para Protobuf.
Como o Zerobus Ingest funciona
Um produtor de dados primeiro abre uma transmissão para a API do Zerobus Ingest e especifica uma tabela Delta de destino, constrói uma mensagem correspondente ao seu esquema e, em seguida, envia a mensagem através da transmissão aberta. O serviço torna os dados duráveis e reconhece a mensagem do cliente. Em seguida, ele materializa os dados na tabela Delta, de forma otimizada, como um passo separado. O reconhecimento 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 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. As tabelas e seus esquemas são as fontes autoritativas para as expectativas de dados recebidos.
O servidor do Zerobus Ingest aceita os dados enviados pelos clientes e valida se eles estão adequados ao esquema da tabela de destino. Se o registro estiver adequado, o servidor o torna durável e o reconhece para o cliente. A materialização do registro na tabela Delta, para que se torne consultável, ocorre como o passo separado logo em seguida.
As responsabilidades do serviço incluem:
- Validação do esquema da mensagem em relação à tabela.
- Tornando o registro durável e reconhecendo-o para o cliente. O reconhecimento confirma a durabilidade, não que o registro já possa 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
Um cliente se conecta ao Zerobus Ingest, envia registros e confirma que eles são duráveis. Ao usar um SDK do Zerobus Ingest, o SDK lida com a maior parte disso para você, portanto, é útil separar o que você configura do que o SDK faz automaticamente.
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 solicitação de um protocolo sem estado e pode enviar um fluxo contínuo de registros de alto volume por um único canal. É isso que torna os SDKs a maneira de maior throughput para realizar a ingestão. Para as outras interfaces (REST e OpenTelemetry) e quando escolher cada uma, consulte protocolos de API.
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:
- O Zerobus Ingest grava apenas em tabelas Delta gerenciadas. A gravação no armazenamento default não é suportada.
- O Zerobus Ingest não grava em armazenamento protegido por um endpoint privado.
- O Zerobus Ingest não oferece suporte à recriação de uma tabela de destino.
- Os nomes das tabelas suportam 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 esquema. Para recursos de tabela como particionamento e cluster líquido, consulte recursos de tabela Delta.
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:
|
|