Recursos do Zerobus Ingest
Esta página é uma visão geral do que o Zerobus Ingest no Lakeflow Connect oferece. Cada recurso contém um link para sua documentação completa.
- Endpoint sempre ativo: Serverless, ativado por default, escala automaticamente.
- Métodos de autenticação: como os clientes se autenticam, incluindo OAuth de Service Principal e federação de provedor de identidade externo.
- Bloqueio de mensagem: métodos de ingestão e como confirmar a durabilidade.
- Callbacks de reconhecimento: reaja a reconhecimentos e erros de forma assíncrona.
- Recursos da tabela Delta: particionamento, cluster líquido e dados
VARIANT. - Coluna de resgate: capture campos que não se ajustam ao esquema da tabela em vez de rejeitá-los.
- Local de fallback durável: onde os dados são armazenados se não puderem ser publicados.
- Monitoramento do seu uso: tabelas do sistema para uso e gastos.
Endpoint sempre ativo
O Zerobus Ingest é um Endpoint Serverless que fica habilitado por default para Workspace em regiões com suporte. Não há nada para começar, provisionamento ou escala. Depois de ter uma tabela de destino e uma identidade autorizada, você pode começar a enviar dados e a capacidade escala automaticamente. Para começar, consulte Usar o Zerobus Ingest.
Métodos de autenticação
Cada cliente Zerobus autentica com um token OAuth do Databricks de curta duração. Quando você usa um SDK, ele obtém e faz o refresh do token para você. Em outras interfaces, como a API REST, você obtém o token e o fornece com suas solicitações. Para os passos de configuração e código, consulte Configurar autenticação.
OAuth com uma Service Principal (default)
Autentique com um ID de cliente e segredo de Service Principal do Databricks. Este é o método default. É adequado para workloads que podem manter um segredo gerenciado pelo Databricks.
Federação externa de provedores de identidade
Autentique com um token do seu próprio provedor de identidade, como o Microsoft Entra ID, em vez de um segredo do Databricks. O tokens do provedor de identidade é trocado por um tokens do Databricks com escopo Zerobus usando a troca de token RFC 8693, portanto, nenhum segredo do Databricks de longa duração é armazenado no cliente.
A federação suporta dois modelos de identidade:
- Federação de nível de conta : Não há Service Principal do Databricks. Sua identidade do provedor de identidade é sincronizada na account do Databricks por meio da gestão automática de identidades e seu cliente autentica como essa identidade. Isso requer uma política de federação de account que registra seu provedor como um emissor confiável.
- Federação de identidade de Workload : Use uma Service Principal do Databricks que tenha um ID de cliente e nenhum segredo, com uma política de federação anexada.
O Microsoft Entra ID é o exemplo nestas páginas, mas o mesmo fluxo federado funciona com outros provedores de identidade compatíveis com OpenID Connect (OIDC).
Comparar métodos de autenticação
Método | Databricks Service Principal | Segredo do cliente Databricks | Quando usar |
|---|---|---|---|
OAuth Service Principal | Sim | Sim | O seu cliente pode manter um segredo gerenciado pelo Databricks. |
Federação em nível de account | Não | Não | Sua identidade é governada apenas em seu provedor, sem nenhuma Service Principal ou segredo do Databricks. |
Federação de identidades de Workload | Sim, sem segredo | Não | Você deseja uma identidade de Service Principal Databricks sem armazenar um segredo. |
A troca automática de tokens no SDK está disponível no SDK para Python 1.10.0 e acima e no SDK para Rust 2.11.0 e acima. Para os passos de configuração e código, consulte Configurar autenticação.
Recursos da tabela Delta
O Zerobus Ingest grava em tabelas Delta padrão gerenciadas pelo Unity Catalog, portanto, seus dados ingeridos funcionam com os recursos de tabela Delta. Para os requisitos que uma tabela de destino deve atender, consulte Requisitos da tabela.
- Tabelas particionadas : suportadas, sujeitas a um limite de expansão de partição (partition-fan-out). O Databricks recomenda o clustering líquido para chaves de alta cardinalidade. Consulte Tabelas particionadas.
- Tabelas em clusters líquidos : a disposição recomendada, organizando os dados para desempenho de query sem o limite de expansão de partição. Consulte Usar clusters líquidos para tabelas.
- Dados Variant : ingira dados semiestruturados em colunas
VARIANT. Consulte Tipos de dados suportados.
Local de fallback durável
Se uma alteração de tabela disruptiva ocorrer após o Zerobus Ingest tornar seus dados duráveis, mas antes que ele possa publicar os dados na tabela, o Zerobus Ingest grava esses dados como arquivos Parquet em um diretório de fallback dentro do local de armazenamento da sua tabela, em vez de descartá-los. Para encontrar e reprocessar esses dados após corrigir o esquema, consulte Recuperando dados do local de fallback durável.
Monitoramento seu uso
Monitore seu uso e gastos do Zerobus Ingest por meio de tabelas do sistema. Consulte Referência da tabela do sistema do Zerobus Ingest e, para gastos, a tabela do sistema de faturamento em Custo.