Por que processamento de fluxo incremental?

As empresas orientadas por dados de hoje produzem dados continuamente, o que exige pipelines de dados de engenharia que ingerem e transformam continuamente esses dados. Esses pipelines devem ser capazes de processar e entregar dados exatamente uma vez, produzir resultados com latências inferiores a 200 milissegundos e sempre tentar minimizar os custos.

Este artigo descreve abordagens de processamento de fluxo incremental e em lote para pipelines de dados de engenharia, por que o processamento de fluxo incremental é a melhor opção e as próximas etapas para começar a usar as ofertas de processamento de fluxo incremental do Databricks, Streaming no Azure Databricks e O que é Delta Live Tables?. Esses recursos permitem que você escreva e execute pipelines rapidamente que garantem semântica de entrega, latência, custo e muito mais.

As armadilhas de trabalhos em lote repetidos

Ao configurar seu pipeline de dados, você pode, a princípio, gravar trabalhos em lotes repetidos para ingerir seus dados. Por exemplo, a cada hora você pode executar um trabalho do Spark que lê de sua origem e grava dados em um coletor como o Delta Lake. O desafio com essa abordagem é processar incrementalmente sua origem, pois o trabalho do Spark que é executado a cada hora precisa começar de onde o último terminou. Você pode registrar o carimbo de data/hora mais recente dos dados processados e, em seguida, selecionar todas as linhas com carimbos de data/hora mais recentes do que esse carimbo de data/hora, mas há armadilhas:

Para executar um pipeline de dados contínuo, você pode tentar agendar um trabalho em lotes por hora que lê incrementalmente de sua origem, faz transformações e grava o resultado em um coletor, como o Delta Lake. Essa abordagem pode ter armadilhas:

• Um trabalho do Spark que consulta todos os novos dados após um carimbo de data/hora perderá dados atrasados.
• Um trabalho do Spark que falha pode levar à quebra de garantias exatamente uma vez, se não for tratado com cuidado.
• Um trabalho do Spark que lista o conteúdo de locais de armazenamento em nuvem para encontrar novos arquivos se tornará caro.

Em seguida, você ainda precisa transformar repetidamente esses dados. Você pode escrever trabalhos em lotes repetidos que agregam seus dados ou aplicam outras operações, o que complica e reduz ainda mais a eficiência do pipeline.

Um exemplo de lote

Para entender completamente as armadilhas da ingestão e transformação em lote para seu pipeline, considere os exemplos a seguir.

Dados perdidos

Dado um tópico do Kafka com dados de uso que determina quanto cobrar de seus clientes e seu pipeline está ingerindo em lotes, a sequência de eventos pode ser semelhante a esta:

1. Seu primeiro lote tem dois registros às 8h e 8h30.
2. Você atualiza o carimbo de data/hora mais recente para 8h30.
3. Você recebe outro recorde às 8h15.
4. Seu segundo lote consulta tudo depois das 8h30, então você perde o registro às 8h15.

Além disso, você não deseja sobrecarregar ou cobrar de menos que seus usuários, portanto, deve garantir que está ingerindo todos os registros exatamente uma vez.

Processamento redundante

Em seguida, suponha que seus dados contenham linhas de compras de usuários e você queira agregar as vendas por hora para saber os horários mais populares em sua loja. Se as compras para a mesma hora chegarem em lotes diferentes, você terá vários lotes que produzem saídas para a mesma hora:

A janela das 8h às 9h tem dois elementos (a saída do lote 1), um elemento (a saída do lote 2) ou três (a saída de nenhum dos lotes)? Os dados necessários para produzir uma determinada janela de tempo aparecem em vários lotes de transformação. Para resolver isso, você pode particionar seus dados por dia e reprocessar toda a partição quando precisar calcular um resultado. Em seguida, você pode substituir os resultados em seu coletor:

No entanto, isso ocorre às custas da latência e do custo, porque o segundo lote precisa fazer o trabalho desnecessário de processar dados que já pode ter processado.

Sem armadilhas com processamento de fluxo incremental

O processamento de fluxo incremental facilita a prevenção de todas as armadilhas de trabalhos em lote repetidos para ingerir e transformar dados. O Databricks Structured Streaming e o Delta Live Tables gerenciam as complexidades de implementação do streaming para permitir que você se concentre apenas na lógica de negócios. Você só precisa especificar a qual fonte se conectar, quais transformações devem ser feitas nos dados e onde gravar o resultado.

Ingestão incremental

A ingestão incremental no Databricks é alimentada pelo Apache Spark Structured Streaming, que pode consumir incrementalmente uma fonte de dados e gravá-la em um coletor. O mecanismo de Streaming Estruturado pode consumir dados exatamente uma vez e o mecanismo pode lidar com dados fora de ordem. O mecanismo pode ser executado em notebooks ou usando tabelas de streaming em Delta Live Tables.

O mecanismo de Streaming Estruturado no Databricks fornece fontes de streaming proprietárias, como o AutoLoader, que pode processar incrementalmente arquivos de nuvem de maneira econômica. O Databricks também fornece conectores para outros barramentos de mensagens populares, como Apache Kafka, Amazon Kinesis, Apache Pulsar e Google Pub/Sub.

Transformação incremental

A transformação incremental no Databricks com Streaming Estruturado permite que você especifique transformações para DataFrames com a mesma API de uma consulta em lote, mas rastreia dados entre lotes e valores agregados ao longo do tempo para que você não precise fazer isso. Ele nunca precisa reprocessar dados, por isso é mais rápido e econômico do que trabalhos em lote repetidos. O Streaming Estruturado produz um fluxo de dados que pode ser anexado ao coletor, como Delta Lake, Kafka ou qualquer outro conector compatível.

As exibições materializadas no Delta Live Tables são alimentadas pelo mecanismo Enzyme. O Enzyme ainda processa incrementalmente sua origem, mas em vez de produzir um fluxo, ele cria uma exibição materializada, que é uma tabela pré-computada que armazena os resultados de uma consulta que você fornece. O Enzyme é capaz de determinar com eficiência como os novos dados afetam os resultados da sua consulta e mantém a tabela pré-computada atualizada.

As Exibições Materializadas criam uma exibição sobre sua agregação que está sempre se atualizando com eficiência para que, por exemplo, no cenário descrito acima, você saiba que a janela das 8h às 9h tem três elementos.

Streaming estruturado ou tabelas delta ao vivo?

A diferença significativa entre o Streaming Estruturado e as Tabelas Dinâmicas Delta é a maneira como você operacionaliza suas consultas de streaming. No Streaming Estruturado, você especifica manualmente muitas configurações e precisa unir manualmente as consultas. Você deve iniciar explicitamente as consultas, aguardar o término, cancelá-las em caso de falha e outras ações. No Delta Live Tables, você fornece declarativamente ao Delta Live Tables seus pipelines para serem executados e os mantém em execução.

O Delta Live Tables também tem recursos como Exibições Materializadas, que pré-calculam de forma eficiente e incremental as transformações de seus dados.

Para obter mais informações sobre esses recursos, consulte Streaming no Azure Databricks e O que é Delta Live Tables?.

Próximas etapas

• Crie seu primeiro pipeline com o Delta Live Tables. Consulte Tutorial: como executar seu primeiro pipeline do Delta Live Tables.

• Execute suas primeiras consultas de Streaming Estruturado no Databricks. Consulte Executar sua primeira carga de trabalho do Structured Streaming.

• Use uma exibição materializada. Confira Usar exibições materializadas no Databricks SQL.