Referência do modo em tempo real

Esta página fornece informações de referência para o modo em tempo real em Structured Streaming, incluindo ambientes, línguas, fontes, sumidouros, operadores e limitações conhecidas suportadas.

Ambientes, linguagens e modos suportados

Línguas suportadas: O modo em tempo real suporta Scala, Java e Python.

Tipos de computação suportados:

Modos de execução suportados:

Suporte de fonte e sumidouro

Operadores suportados

Considerações especiais

Alguns operadores e funcionalidades têm considerações ou diferenças específicas quando usados em modo em tempo real.

transformWithState em modo de tempo real

Para a criação de aplicativos baseados em estado personalizados, o Databricks suporta transformWithState, uma API no Apache Spark Structured Streaming. Consulte Criar um aplicativo com monitoração de estado personalizado para obter mais informações sobre a API e trechos de código.

No entanto, há algumas diferenças entre como a API se comporta no modo de tempo real e as consultas de streaming tradicionais que aproveitam a arquitetura de microlote.

• O modo em tempo real chama o método handleInputRows(key: String, inputRows: Iterator[T], timerValues: TimerValues) para cada linha.
  • O inputRows iterador retorna um único valor. O modo micro-batch chama-o uma vez para cada chave, e o inputRows iterador devolve todos os valores de uma chave no micro batch.
  • Tenha em conta esta diferença ao escrever o seu código
• Os temporizadores de tempo de evento não são suportados no modo de tempo real.
• No modo em tempo real, os temporizadores atrasam o disparo dependendo da chegada dos dados:
  • Se um temporizador estiver agendado para as 10:00:00, mas não houver dados disponíveis, o temporizador não aciona imediatamente.
  • Se os dados chegarem às 10:00:10, o temporizador dispara com um atraso de 10 segundos.
  • Se não chegarem dados e o processo de longa duração estiver a terminar, o temporizador dispara antes do processo terminar.

UDFs em Python em modo em tempo real

O Databricks suporta a maioria das funções definidas pelo usuário (UDFs) do Python no modo em tempo real:

Há vários pontos a considerar ao usar UDFs Python no modo de tempo real:

• Para minimizar a latência, configure o tamanho do lote Arrow (spark.sql.execution.arrow.maxRecordsPerBatch) para 1.
  • Compensação: essa configuração otimiza a latência em detrimento da taxa de transferência. Para a maioria das cargas de trabalho, essa configuração é recomendada.
  • Aumente o tamanho do lote somente se uma taxa de transferência maior for necessária para acomodar o volume de entrada, aceitando o potencial aumento na latência.
• Pandas UDFs e funções não têm um bom desempenho com um tamanho de lote de Arrow de 1.
  • Se utilizares UDFs de pandas ou funções, define o tamanho de conjunto do Arrow para um valor mais alto (por exemplo, 100 ou superior).
  • Isto implica uma latência mais elevada. O Databricks recomenda usar um Arrow UDF ou função, se possível.
• Devido ao problema de desempenho com pandas, transformWithState só é suportado com a interface Row.

Limitações

Limitações da fonte

Para o Kinesis, o modo em tempo real não suporta o modo de sondagem. Além disso, as repartições frequentes podem afetar negativamente a latência.

Limitações sindicais

O operador da União tem algumas limitações:

• O modo em tempo real não suporta autounição:
  • Kafka: Não podes usar o mesmo objeto de data frame de origem e unir dataframes derivados dele. Solução alternativa: Use DataFrames diferentes que leiam da mesma fonte.
  • Kinese: Não se podem unir quadros de dados derivados da mesma fonte Kinesis com a mesma configuração. Solução alternativa: Além de usar DataFrames diferentes, pode atribuir uma opção diferente de 'Nome do consumidor' a cada DataFrame.
• O modo em tempo real não suporta operadores com estado (por exemplo, aggregate, deduplicate, transformWithState) definidos antes da União.
• O modo em tempo real não suporta união com fontes em lote.

Limitação do MapPartitions

mapPartitions em Scala e APIs Python semelhantes (mapInPandas, mapInArrow) pega num iterador de toda a partição de entrada e produz um iterador de toda a saída com mapeamento arbitrário entre entrada e saída. Estas APIs podem causar problemas de desempenho no Modo Real-Time de Streaming ao bloquear toda a saída, o que aumenta a latência. A semântica destas APIs não suporta bem a propagação de metadados.

Use UDFs escalares combinados com Transform tipos de dados complexos ou filter para obter funcionalidades semelhantes.