Por que o processamento de transmissão incremental?

data-driven As empresas de hoje em dia produzem dados continuamente, o que exige a engenharia de pipeline de dados que ingere e transforma continuamente esses dados. Esse pipeline deve ser capaz de processar e fornecer dados exatamente uma vez, produzir resultados com latências inferiores a 200 milissegundos e sempre tentar minimizar os custos.

Este artigo descreve as abordagens de processamento de transmissão incremental e de lotes para engenharia de pipeline de dados, por que o processamento de transmissão incremental é a melhor opção e, a seguir, os passos para começar com as ofertas de processamento de transmissão incremental do Databricks, transmissão em Databricks e o que é Delta Live Tables? Esses recursos permitem que o senhor escreva e execute rapidamente pipelines que garantam a semântica de entrega, a latência, o custo e muito mais.

As armadilhas do trabalho repetido em lote

Ao configurar o site pipeline de dados, o senhor pode inicialmente escrever trabalhos repetidos em lote para ingerir seus dados. Por exemplo, a cada hora o senhor poderia executar um trabalho Spark que lê da sua fonte e grava dados em um sink como Delta Lake. O desafio dessa abordagem é o processamento incremental do código-fonte, pois o Spark Job que o senhor executa a cada hora precisa começar onde o último terminou. Você pode gravar o registro de data e hora mais recente dos dados processados e 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 contínuo de dados, o senhor pode tentar programar um trabalho em lote de hora em hora que leia de forma incremental a sua fonte, faça transformações e grave o resultado em um sink, como Delta Lake. Essa abordagem pode ter armadilhas:

  • Um trabalho Spark que consulta todos os novos dados após um carimbo de data/hora perderá dados atrasados.

  • Um trabalho Spark que falhe pode levar à quebra de garantias de exatamente uma vez, se não for tratado com cuidado.

  • Um trabalho do Spark que lista o conteúdo dos locais de armazenamento do cloud para localizar novos arquivos se tornará caro.

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

Um exemplo de lotes

Para entender completamente as armadilhas da ingestão de lotes e transformações para seu pipeline, considere os exemplos a seguir.

Dados perdidos

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

  1. Seu primeiro lote tem dois registros, às 8h e às 8h30.

  2. Você atualiza o timestamp mais recente para 8:30.

  3. Você obtém outro recorde às 8h15.

  4. Seu segundo lote consulta tudo depois das 8h30, então o senhor perde o registro às 8h15.

Além disso, você não quer sobrecarregar ou subcobrar seus usuários, então você deve garantir que está ingerindo cada registro exatamente uma vez.

Processamento redundante

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

exemplo de ingestão de lotes

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

exemplo de ingestão de lotes

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 talvez já tenha processado.

Sem armadilhas com o processamento de transmissão incremental

O processamento de transmissão incremental facilita a prevenção de todas as armadilhas do trabalho repetido em lote para ingestão e transformação de dados. Databricks transmissão estruturada e Delta Live Tables gerenciar as complexidades de implementação da transmissão para permitir que o senhor se concentre apenas na sua lógica de negócios. O senhor só precisa especificar a qual fonte se conectar, quais transformações devem ser feitas nos dados e onde escrever o resultado.

Ingestão incremental

A ingestão incremental em Databricks é alimentada pela Apache Spark transmissão estructurada, que pode consumir de forma incremental uma fonte de dados e gravá-la em um coletor. O mecanismo de transmissão estruturada pode consumir dados exatamente uma vez, e o mecanismo pode lidar com dados fora de ordem. O mecanismo pode ser executado no Notebook ou usando tabelas de transmissão em Delta Live Tables.

O mecanismo de transmissão estruturada no site Databricks fornece fontes de transmissão proprietárias, como o AutoLoader, que pode processar arquivos cloud de forma incremental e econômica. A Databricks também fornece conectores para outros barramentos de mensagens populares, como Apache Kafka, Amazon Kinesis, Apache Pulsar e Google Pub/Sub.

Transformações incrementais

As transformações incrementais em Databricks com transmissão estruturada permitem que o senhor especifique transformações para DataFrames com o mesmo API que uma consulta de lotes, mas rastreia dados em lotes e valores agregados ao longo do tempo para que o senhor não precise fazer isso. Ele nunca precisa reprocessar os dados, portanto é mais rápido e econômico do que o trabalho repetido em lote. A transmissão estruturada produz uma transmissão de dados que pode ser anexada ao seu coletor, como Delta Lake, Kafka, ou qualquer outro conector compatível.

transmissão estructurada ou Delta Live Tables?

A diferença significativa entre a transmissão estruturada e o site Delta Live Tables é a forma como o senhor operacionaliza suas consultas de transmissão. Na transmissão estruturada, o senhor especifica manualmente muitas configurações e precisa unir as consultas manualmente. O senhor deve iniciar explicitamente as consultas, esperar que elas terminem, cancelá-las em caso de falha e outras ações. No site Delta Live Tables, o senhor declara que dá ao Delta Live Tables seu pipeline para execução, e ele o mantém em execução.

Para obter mais informações sobre esses recursos, consulte a transmissão em Databricks e o que é Delta Live Tables?

Próximos passos