Pular para o conteúdo principal

Transmissão em compute serverless

Esta página descreve como escolher a configuração certa para cargas de trabalho de transmissão serverless no Databricks, incluindo pipelines contínuos, ingestão incremental e conectores gerenciados. A escolha da configuração correta depende da origem da transmissão, do formato e das necessidades de latência.

O que é considerado uma carga de trabalho de transmissão

Uma carga de trabalho de transmissão lê dados ilimitados de uma fonte (como armazenamento de objetos na cloud, um barramento de mensagens ou um feed de alterações) e grava em um coletor incrementalmente. O Databricks oferece suporte para dois padrões de cargas de trabalho de transmissão:

  • Contínuo : uma pipeline que é executada continuamente e processa novos dados à medida que chegam. A latência é medida em segundos.
  • Incremental (também chamado de acionado): Um pipeline que é executado em uma programação ou um gatilho, processa todos os dados que chegaram desde a última execução e para. A latência é medida em minutos.

Algumas cargas de trabalho parecem ser pipelines de transmissão, mas não são tecnicamente pipelines. Exemplos incluem um serviço que mantém um websocket aberto para ouvir eventos, um aplicativo de chat que mantém uma conexão persistente por usuário, ou um receptor de webhook que lida com requisições HTTP de entrada. Estas são aplicações, não pipelines de transmissão. Para a opção serverless certa para essas cargas de trabalho, consulte Cargas de trabalho que não são pipelines de transmissão.

Escolha a configuração de transmissão correta

Esta tabela mapeia os casos de uso para as configurações serverless que melhor se adequam a eles. As seções a seguir nesta página fornecem informações mais detalhadas sobre estas recomendações.

Caso de uso

Configuração recomendada

Por quê?

ETL de transmissão contínua de baixa latência ou transformações

LakeFlow Spark Declarative Pipelines em modo contínuo

O modo contínuo é projetado para transmissões sempre ativas. Pipelines de transmissão executam microlotes simultaneamente, melhorando a taxa de transferência e a latência. O estado gerenciado mantém a recuperação automática.

Ingestão incremental do armazenamento na nuvem

Use o Auto Loader dentro do Lakeflow Spark Declarative Pipelines (para baixa latência) ou em um Job serverless com Trigger.AvailableNow() (se uma latência menor for aceitável).

O Auto Loader rastreia novos arquivos com eficiência. Trigger.AvailableNow() processa o backlog de dados, e em seguida é encerrado, o que se adapta a uma cadência agendada ou sob demanda.

Ingestão gerenciada de fontes SaaS ou CDC de banco de dados

Conectores padrão no LakeFlow Connect

Conectores totalmente gerenciados com pipelines de ingestão serverless. Nenhum código é necessário para fontes compatíveis.

Transmissão SQL sobre tabelas Delta

Tabelas de streaming

Processamento incremental nativo de SQL para fontes orientadas a anexação, com pipelines gerenciados e refresh.

Processamento periódico de micro-lotes em um Notebook ou Job

job serverless com Trigger.AvailableNow()

Econômico quando a atualização a nível de minuto é suficiente. Compute serverless começa rapidamente e é encerrado quando o lote é concluído.

Transmissão contínua

Para transmissão contínua em compute serverless, utilize Lakeflow Spark Declarative Pipelines no modo contínuo. O pipeline continua em execução, processa registros à medida que chegam e se recupera automaticamente de falhas.

Para configurar uma transmissão contínua:

dica

A pipeline de transmissão está habilitada por default em pipelines declarativos do LakeFlow Spark serverless. Microlotes são executados simultaneamente em vez de sequencialmente, o que melhora a taxa de transferência para transmissões com muita ingestão.

Acionadores de transmissão estructurada baseados em tempo, como Trigger.ProcessingTime(interval) e Trigger.Continuous(interval), não estão disponíveis em Notebooks ou Jobs serverless. Use Lakeflow Spark Declarative Pipelines no modo contínuo para o padrão sempre ativo. Consulte limitações de transmissão. Trigger.Once() é compatível, mas descontinuado — migre as consultas existentes para Trigger.AvailableNow().

Transmissão incremental e com trigger

Para transmissão incremental, execute transmissão estructurada com Trigger.AvailableNow() em um Job serverless. Cada execução processa todos os dados que chegaram desde o último ponto de verificação e depois é encerrada.

Para configurar um job serverless com transmissão incremental:

O exemplo a seguir lê novos arquivos do armazenamento em nuvem (source_path) com o Auto Loader, processa todos os dados disponíveis no momento da execução e grava em uma tabela Delta:

Python
(spark.readStream
.format("cloudFiles")
.option("cloudFiles.format", "json")
.option("cloudFiles.maxFilesPerTrigger", 1000)
.load(source_path)
.writeStream
.trigger(availableNow=True)
.option("checkpointLocation", checkpoint_path)
.toTable("catalog.schema.target_table"))

Um Trigger.AvailableNow() job agendado é o padrão de transmissão mais econômico em compute serverless quando uma latência em nível de minuto é aceitável. Compute começa em segundos, executa os lotes e desliga.

Ingestão gerenciada

Se a fonte for um aplicativo SaaS ou um banco de dados operacional, use o LakeFlow Connect em vez de escrever código de transmissão estructurada. LakeFlow Connect executa pipelines de ingestão serverless para conectores como Salesforce, Workday, CDC do SQL Server e CDC do PostgreSQL. Consulte conectores gerenciados no LakeFlow Connect.

Este caminho é a resposta correta quando:

  • Um conector existe para sua fonte.
  • É preferível um pipeline gerenciado em vez de código personalizado.
  • Você precisa de recursos integrados de evolução de esquema, linhagem e monitoramento.

Processamento incremental de dados gerenciado por SQL

Para equipes com foco em SQL, use tabelas de transmissão para cargas de trabalho de transmissão nativas de SQL. Você pode definir tabelas de transmissão dentro de LakeFlow Spark Pipelines Declarativos ou como tabelas de transmissão autônomas.

Para tabelas de transmissão autônomas criadas com a declaração SQL CREATE OR REFRESH STREAMING TABLE, o refresh inicial dos dados e o preenchimento começam imediatamente. Um pipeline serverless dedicado é automaticamente criado e gerenciado pelo sistema para cada tabela de transmissão.

Caso precise de resultados de query com semântica de lotes e refresh gerenciado, utilize visualizações materializadas. Consulte Visualizações materializadas.

Cargas de trabalho que não são pipelines de transmissão

Uma carga de trabalho que precisa manter uma conexão de longa duração, ouvir em uma porta ou responder a requisições HTTP de entrada não é um pipeline de transmissão; é uma aplicação. Não execute estas cargas de trabalho em um job serverless. As configurações corretas do Databricks são:

  • Serviços de longa duração que precisam de uma conexão persistente ou endpoint HTTP : Crie o serviço com o Databricks Apps. O Databricks Apps é a plataforma serverless para hospedar aplicativos personalizados no Databricks, incluindo FastAPI, Flask, Streamlit, Dash, Gradio, Node.js e aplicativos Shiny. See Databricks Apps.
  • Webhooks de entrada ou ouvintes de eventos : Exponha um endpoint HTTP no Databricks Apps ou encerre o webhook em um serviço externo e grave eventos no armazenamento em cloud ou em um barramento de mensagens; em seguida, colete-os com um pipeline de transmissão serverless.
  • Troca personalizada de tokens ou credenciais : Use entidades de serviço com OAuth, ou chame as APIs REST do Databricks a partir de um aplicativo. Pipelines de transmissão não mantêm sessões por usuário ou estado de token personalizado.

Se estiver avaliando se sua carga de trabalho se encaixa em um pipeline de transmissão, pergunte:

  • A carga de trabalho lê de uma fonte de dados ilimitada e grava em um coletor? Se sim, é um pipeline de transmissão.
  • A carga de trabalho precisa manter uma conexão aberta com um cliente? Caso afirmativo, é um aplicativo; use o Databricks Apps.

Limitações

Compute serverless impõe as seguintes restrições à transmissão. Nenhuma delas impede as cargas de trabalho acima quando combinadas com o produto certo.

  • Gatilhos de transmissão estructurada baseados em tempo (Trigger.ProcessingTime(interval) e Trigger.Continuous(interval)) não são suportados em Notebooks ou Jobs serverless. Use LakeFlow Spark Declarative pipeline no modo contínuo para transmissões sempre ativas ou Trigger.AvailableNow() para execuções acionadas. Consulte Limitações de transmissão.
  • Consultas de transmissão sem um gatilho explícito falham com INFINITE_STREAMING_TRIGGER_NOT_SUPPORTED. O Apache Spark tem Trigger.ProcessingTime("0 seconds") como default, o que não tem suporte em compute serverless. Sempre defina Trigger.AvailableNow() em cada consulta de transmissão, ou use os Lakeflow Spark Declarative Pipelines no modo contínuo.
  • Todas as limitações para transmissão no modo de acesso padrão também se aplicam a compute serverless. Consulte limitações de transmissão.

Passos seguintes