Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Esta página fornece informações de referência para o modo em tempo real no Structured Streaming, incluindo ambientes, linguagens, fontes, sinks e operadores suportados. Para limitações conhecidas, veja Limitações do modo em tempo real.
Idiomas suportados
O modo em tempo real suporta Scala, Java e Python.
Tipos de computação
O modo em tempo real suporta os seguintes tipos de computação:
| Tipo de computação | Suportado |
|---|---|
| Dedicado (anteriormente: usuário único) | ✓ |
| Padrão (anteriormente: compartilhado) | ✓ (apenas Python) |
| Lakeflow Spark Oleodutos Declarativos Classic | Não suportado |
| Lakeflow Spark Pipelines Declarativos Sem Servidor | Não suportado |
| Sem servidor | Não suportado |
Modos de execução
O modo em tempo real suporta apenas o modo de atualização:
| Modo de execução | Suportado |
|---|---|
| Modo de atualização | ✓ |
| modo de acrescento | Não suportado |
| Modo completo | Não suportado |
Fontes e sumidouros
O modo em tempo real suporta as seguintes fontes e suturas:
| Fonte ou sumidouro | Como fonte | Como sumidouro |
|---|---|---|
| Apache Kafka | ✓ | ✓ |
| Centros de Eventos (usando conector Kafka) | ✓ | ✓ |
| Kinesis | ✓ (apenas modo EFO) | Não suportado |
| AWS MSK | ✓ | Não suportado |
| Delta | Não suportado | Não suportado |
| Google Pub/Sub | Não suportado | Não suportado |
| Apache Pulsar | Não suportado | Não suportado |
Sumidouros arbitrários (usando forEachWriter) |
Não aplicável | ✓ |
Operadores
O modo em tempo real suporta a maioria dos operadores de Streaming Estruturado:
Operações apátridas
| Operador | Suportado |
|---|---|
| Seleção | ✓ |
| Projeção | ✓ |
UDFs
| Operador | Suportado |
|---|---|
| Scala UDF | ✓ (com algumas limitações) |
| Python UDF | ✓ (com algumas limitações) |
Agregação
| Operador | Suportado |
|---|---|
| sum | ✓ |
| contagem | ✓ |
| max | ✓ |
| min | ✓ |
| avg | ✓ |
| Funções de agregação | ✓ |
Técnica de Janelação
| Operador | Suportado |
|---|---|
| Tumbling | ✓ |
| Deslizamento | ✓ |
| Sessão | Não suportado |
Deduplication
| Operador | Suportado |
|---|---|
| dropDuplicates | ✓ (o estado é ilimitado) |
| dropDuplicatesWithinWatermark | Não suportado |
Junção de fluxo para mesa
| Operador | Suportado |
|---|---|
| Junção de tabela de broadcast (a tabela deve ser pequena) | ✓ |
| Junção de fluxo para fluxo | Não suportado |
| (plano)MapGroupsWithState | Não suportado |
| transformWithState | ✓ (com algumas diferenças) |
| união | ✓ (com algumas limitações) |
| forEach | ✓ |
| paraCadaLote | Não suportado |
| mapPartitions | Não suportado (ver limitação) |
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 em 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
inputRowsiterador retorna um único valor. O modo micro-batch chama-o uma vez para cada chave, e oinputRowsiterador devolve todos os valores de uma chave no micro batch. - Tenha em conta esta diferença ao escrever o seu código
- O
- 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.
Python UDFs em modo em tempo real
O Databricks suporta a maioria das funções Python definidas pelo utilizador (UDFs) em modo de tempo real:
Sem estado
| Tipo UDF | Suportado |
|---|---|
| Python UDF escalar (Funções escalares definidas pelo utilizador - Python) | ✓ |
| Seta escalar UDF | ✓ |
| Pandas scalar UDF (pandas funções definidas pelo utilizador) | ✓ |
Função de seta (mapInArrow) |
✓ |
| Função Pandas (Mapa) | ✓ |
Agrupamento estadual (UDAF)
| Tipo UDF | Suportado |
|---|---|
transformWithState (apenas Row interface) |
✓ |
applyInPandasWithState |
Não suportado |
Agrupamento não estadual (UDAF)
| Tipo UDF | Suportado |
|---|---|
apply |
Não suportado |
applyInArrow |
Não suportado |
applyInPandas |
Não suportado |
Funções de tabela
| Tipo UDF | Suportado |
|---|---|
| UDTF (Python funções de tabela definidas pelo utilizador (UDTFs)) | Não suportado |
| UC UDF | Não suportado |
Existem vários pontos a considerar ao usar UDFs Python em 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.