O que são Lakeflow Spark Declarative Pipelines
LakeFlow Spark Declarative Pipelines (SDP) é uma estrutura declarativa para criar pipelines de dados em lote e transmissão em SQL e Python. Seus conceitos centrais são pipelines, fluxos, tabelas de transmissão, visualizações materializadas e coletores, que trabalham juntos para processar dados com orquestração automática e atualizações incrementais.
O que é SDP?
Lakeflow Spark Declarative Pipelines é uma estrutura declarativa para desenvolver e executar pipelines de dados em lote e em transmissão em SQL e Python. O LakeFlow SDP estende e é interoperável com o Apache Spark Declarative Pipelines, enquanto é executado no Databricks Runtime otimizado para desempenho, e a API LakeFlow Spark Declarative Pipelines flows usa a mesma API DataFrame que o Apache Spark e a transmissão estructurada.
Casos de uso comuns para SDP incluem:
- Ingestão de dados incremental de fontes como armazenamento em nuvem (Amazon S3, Azure ADLS Gen2 e Google Cloud Storage) e barramentos de mensagem (Apache Kafka, Amazon Kinesis, Google Pub/Sub, Azure EventHub e Apache Pulsar).
- Transformações incrementais de lotes e transmissão com operadores sem estado e com estado.
- Processamento de transmissão em tempo real entre repositórios transacionais, como barramentos de mensagens e bancos de dados.
Para obter mais detalhes sobre processamento de dados declarativo, consulte Processamento de dados processual vs. declarativo no Databricks.
Quais são os benefícios do SDP?
A natureza declarativa do SDP oferece os seguintes benefícios em comparação com o desenvolvimento de processos de dados com as APIs do Apache Spark e da transmissão estructurada do Spark e executá-los com o Databricks Runtime usando orquestração manual via Lakeflow Jobs.
- Orquestração automática : O SDP orquestra as etapas de processamento (chamadas de "fluxos") automaticamente para garantir a ordem de execução correta e o nível máximo de paralelismo para um desempenho ideal. Além disso, os pipelines repetem as tentativas de forma automática e eficiente em caso de falhas transitórias. O processo de repetição começa com a unidade mais granular e econômica: a tarefa Spark. Se a nova tentativa no nível da tarefa falhar, o SDP prossegue para tentar novamente o fluxo e, em seguida, finalmente o pipeline inteiro, se necessário.
- Processamento declarativo : O SDP fornece funções declarativas que podem reduzir centenas ou até milhares de linhas de código manual do Spark e do Transmissão Estructurada para apenas algumas linhas. A API SDP AUTO CDC simplifica o processamento de eventos de captura de dados de alterações (CDC) com suporte para SCD Tipo 1 e SCD Tipo 2. Ela elimina a necessidade de código manual para lidar com eventos fora de ordem e não exige conhecimento de semântica de transmissão ou conceitos como marcas d'água.
- Processamento incremental : O SDP oferece um mecanismo de processamento incremental para views materializadas. Para utilizá-lo, escreve-se a lógica de transformação com semântica de lotes, e o motor somente processa novos dados e alterações nas fontes de dados sempre que possível. O processamento incremental reduz o reprocessamento ineficiente quando novos dados ou alterações ocorrem nas fontes e elimina a necessidade de código manual para lidar com o processamento incremental.
Conceitos fundamentais
O diagrama abaixo ilustra os conceitos mais importantes dos Pipelines Declarativos do Lakeflow Spark.
dataset
Um pipeline produz três tipos de conjuntos de dados, cada um com semântica de processamento diferente:
Tipo de dataset | Como os registros são processados |
|---|---|
Tabela de transmissão | Cada registro é processado exatamente uma vez, pressupondo uma origem somente de acréscimo. As tabelas de transmissão são ideais para ingestão e processamento incremental de dados em crescimento contínuo. |
Visualização materializada | Os resultados são recalculados conforme necessário para refletir o estado atual dos dados. As visualizações materializadas são adequadas para transformações, agregações ou pré-computação de resultados consumidos por múltiplos conjuntos de dados subsequentes. |
View | Avaliado sob demanda, não persistido. Utilize modos de exibição para transformações intermediárias e verificações que não precisam ser publicadas em um catálogo. |
Uma tabela de streaming é um tipo de tabela gerenciada pelo Unity Catalog que também funciona como um destino de streaming. Uma tabela de transmissão pode ter um ou mais fluxos de transmissão ( Append , AUTO CDC ) gravados nela. É possível definir fluxos de transmissão explicitamente e separadamente de sua tabela de transmissão de destino, ou implicitamente como parte de uma definição de tabela de transmissão.
Uma materialized view é também uma forma de tabela gerenciada do Unity Catalog e é um destino em lote. Uma visualização materializada pode ter um ou mais fluxos de visualização materializada escritos nela. Materialized views diferem das tabelas de transmissão porque os fluxos são sempre definidos implicitamente como parte da definição da materialized view.
Para detalhes, consulte Tabelas de transmissão e views materializadas.
Quando usar visualizações, visualizações materializadas e tabelas de transmissão em fluxo
Ao implementar consultas em pipeline, escolha o tipo de dataset que melhor se adapta ao seu caso de uso.
Considere usar uma view para:
- Dividir uma query grande ou complexa em queries mais fáceis de gerenciar.
- Validar resultados intermediários usando expectativas.
- Reduzir custos de armazenamento e compute para resultados que não precisam ser persistidos. Como as tabelas são materializadas, elas exigem recursos adicionais de computação e armazenamento.
Considere usar uma visualização materializada quando:
- Múltiplas queries downstream utilizam a tabela. Como as views são computadas sob demanda, uma view é recalculada toda vez que é consultada.
- Outros pipelines, jobs ou consultas consomem a tabela. Como as visualizações não são materializadas, elas só podem ser usadas dentro do mesmo pipeline.
- Para inspecionar os resultados de uma consulta durante o desenvolvimento. Como as tabelas são materializadas e podem ser consultadas fora do pipeline, o uso de tabelas durante o desenvolvimento pode ajudar a validar a correção dos cálculos. Após a validação, converter consultas que não exigem materialização em views.
Considere usar uma tabela de transmissão quando:
- Uma consulta é definida em uma fonte de dados que está crescendo contínua ou incrementalmente.
- Resultados de query devem ser computados de forma incremental.
- O pipeline precisa de alta taxa de transferência e baixa latência.
Tabelas de transmissão são sempre definidas contra fontes de transmissão. É possível usar fontes de transmissão com AUTO CDC ... INTO para aplicar atualizações de feeds CDC. Consulte As APIs AUTO de CDC: Simplifique a captura de dados de alterações (CDC) com pipelines.
Fluxos
Um fluxo é o conceito fundamental de processamento de dados na SDP que suporta as semânticas de transmissão e de lotes. Um fluxo lê dados de uma fonte, aplica a lógica de processamento definida pelo usuário e escreve o resultado em um destino. SDP compartilha o mesmo tipo de fluxo de transmissão ( Append , Update , Complete ) que a transmissão estructurada do Spark. (Atualmente, apenas os fluxos de *Acréscimo* e *Atualização* estão expostos.) Para mais detalhes, consulte modos de saída em transmissão estructurada.
O LakeFlow Spark Declarative Pipelines também oferece tipos de fluxo adicionais:
- O AUTO CDC é um fluxo de transmissão exclusivo no Lakeflow SDP que gerencia eventos CDC fora de sequência e suporta SCD Tipo 1 e SCD Tipo 2. O Auto CDC não está disponível nos Pipelines Declarativos do Apache Spark.
- A view materializada é um fluxo de lotes no SDP que processa apenas dados novos e alterações nas tabelas de origem sempre que possível.
Para obter detalhes, consulte Carregar e processar dados incrementalmente com fluxos de pipelines declarativos do Lakeflow Spark.
Pias
Um *destino* é um alvo de transmissão para um pipeline e oferece suporte a tabelas Delta, tópicos do Apache Kafka, tópicos do Azure EventHubs e fontes de dados Python personalizadas. Um coletor pode ter um ou mais fluxos de transmissão (Acréscimo, Atualização) gravadosnele.
Para obter detalhes, consulte Destinos nos pipelines Declarativos do LakeFlow Spark.
pipeline
Um *pipeline* é a unidade de desenvolvimento e execução em Lakeflow Spark Declarative Pipelines e é o contêiner para os fluxos, tabelas de streaming, visualizações materializadas e coletores que são definidos. Utiliza-se o SDP definindo esses objetos no código-fonte do seu pipeline e, em seguida, executando o pipeline. Enquanto seu pipeline executa, ele analisa as dependências de seus objetos definidos e orquestra a ordem de execução e a paralelização automaticamente.
Para obter detalhes, consulte O que são pipelines?.
Também é possível definir views materializadas e tabelas de transmissão independentes fora de um pipeline, onde o Databricks gerencia o pipeline. Para comparar as duas abordagens, consulte Pipelines independentes vs. pipelines declarativos do Lakeflow Spark.
ingestão de dados
Os pipelines suportam todas as fontes de dados disponíveis no Databricks. O Databricks recomenda o uso de tabelas de transmissão para a maioria dos casos de uso de ingestão. Para arquivos que chegam ao armazenamento de objetos na nuvem, o Auto Loader oferece carregamento incremental e idempotente. Para dados de transmissão, pipelines podem ingerir diretamente de barramentos de mensagens, como Apache Kafka, Azure Event Hubs, Amazon Kinesis e Google Pub/Sub. Consulte Carregar dados em pipelines.
Qualidade dos dados
Expectativas são cláusulas opcionais em datasets que validam dados à medida que fluem pelo pipeline. Você define uma expectativa como uma restrição Boolean SQL e especifica o que acontece quando um registro falha: avisar, descartar o registro ou falhar a atualização. Consulte Gerenciar a Qualidade dos Dados com Expectativas de Pipeline.
Integração do Delta
Todas as tabelas criadas e gerenciadas por pipelines são tabelas Delta. Eles possuem as mesmas garantias que o Delta Lake, incluindo transações ACID, viagem do tempo e imposição de esquema. Pipelines adicionam propriedades de tabela adicionais e realizam manutenção automática usando otimização preditiva, incluindo OPTIMIZE e VACUUM operações. Consulte O que é o Delta Lake no Databricks?.