Pular para o conteúdo principal
Última atualização em

Como usar os LakeFlow Pipelines

Esta página explica como usar os Lakeflow pipelines ao longo do ciclo de vida de um pipeline de dados, desde as primeiras decisões de projeto até a execução em escala, e as vantagens e desvantagens de cada etapa. Cada seção contém links para os artigos que mostram como fazer isso.

Este guia pressupõe familiaridade com os conceitos básicos de engenharia de dados. Se você é iniciante em pipelines, comece com o Apache Spark Declarative Pipelines para entender o produto e o modelo declarativo por trás dele, e depois siga o Tutorial: Criar um pipeline ETL usando captura de dados de alterações (CDC).

Visão geral do ciclo de vida do pipeline​

Um pipeline passa por seis etapas:

  1. Planejar e projetar: decida o que você está criando e escolha as ferramentas, o idioma e o compute adequados.
  2. Ingerir dados: traga dados de origem para o pipeline de forma confiável e incremental.
  3. Transforme e modele: limpe, valide, una e estruture os dados em tabelas nas quais os consumidores possam confiar.
  4. Operacionalize: coloque o pipeline sob controle de versão, teste-o, programe-o e promova-o entre ambientes.
  5. Executar em produção: monitore, alerta, depure, preencha, proteja e rastreie a linhagem à medida que o pipeline é executado sem supervisão.
  6. Amadurecimento e escala: Confirme a prontidão para produção e mantenha o pipeline saudável à medida que o volume e o tamanho da equipe aumentam.

Os estágios não são estritamente sequenciais, mas eles mapeiam a ordem na qual as perguntas surgem. Como os Lakeflow pipelines lidam com orquestração, pontos de verificação, novas tentativas e processamento incremental, seu trabalho em cada estágio é principalmente uma decisão de design em vez de implementação.

Planejar e projetar​

Suas primeiras decisões moldam tudo o que acontece depois. Para saber como o modelo declarativo se compara à escrita manual de etapas procedimentais, consulte Processamento de dados procedimental versus declarativo no Databricks.

Algumas escolhas definem sua configuração inicial:

  • Um dataset independente ou um pipeline. Uma única view materializada ou tabela de streaming pode ser definida em SQL como um dataset independente, e o Databricks gerencia o pipeline de refresh subjacente. Crie e opere um pipeline Lakeflow como uma unidade quando precisar de autoria em Python, sinks ou orquestração em vários estágios. Veja Pipelines independentes vs. Lakeflow pipelines.
  • SQL ou Python (ou ambos). O SQL é adequado para transformações que são principalmente filtros, junções e agregações. Python é adequado para lógica personalizada, bibliotecas externas ou para gerar muitas tabelas semelhantes programaticamente. A escolha é feita por arquivo, e não para todo o pipeline, então você pode misturar os dois e não precisa decidir isso antecipadamente.
  • Compute serverless ou classic. Serverless é o padrão recomendado e remove a configuração do cluster. Escolha classic quando precisar de tipos de instância específicos, políticas de cluster personalizadas ou um init script. Consulte Configurar um pipeline serverless e Configurar compute clássico para pipelines.
  • Execução acionada ou contínua. Começar Trigger, já que ele consome compute apenas enquanto está em execução. O modo contínuo mantém o compute em execução para processar novos dados com atraso mínimo, o que geralmente é o maior fator de custo; portanto, reserve-o para um requisito de latência comprovado. Consulte Modo de Trigger vs. pipeline contínuo.

Um pipeline infere seu gráfico de execução a partir dos datasets que seu código referencia, portanto, o trabalho de design consiste basicamente em nomear e sequenciar datasets. A decisão principal é qual deve ser o tipo de cada saída: tabelas de transmissão para dados incrementais com muitas adições, ou views materializadas para agregações e joins recomputados. Essa escolha impulsiona o custo e a precisão, porque o processamento incremental escala com a taxa de novos dados, enquanto uma recomputação completa escala com todo o seu histórico. Para saber qual tipo se adapta a qual job, consulte O que são pipelines?.

Como o código do pipeline é Python e SQL comuns, você pode escrevê-lo, analisá-lo e validá-lo em seu próprio editor antes de implantá-lo em um Workspace compartilhado.

Nesta etapa​

Questões para refletir nesta fase:

Ingerir dados​

A questão central do projeto é se uma fonte é somente para acréscimo ou se as alterações são feitas no local. Isso determina como você modela o alvo:

  • Fontes somente de acréscimo , como arquivos armazenados na cloud ou eventos em um barramento de mensagens, são ingeridas em uma tabela de streaming, que registra seu progresso para que uma reinicialização não reprocesse nem descarte os dados. O Auto Loader lida com arquivos, descobrindo novos e inferindo e evoluindo o esquema à medida que chegam. Barramentos de mensagens como Apache Kafka, Azure Event Hubs, Amazon Kinesis e Google Pub/Sub leem diretamente em uma tabela de transmissão. Faça a desduplicação downstream, já que um barramento pode entregar o mesmo evento mais de uma vez. Para obter informações específicas sobre o Azure Event Hubs, consulte Usar o Azure Event Hubs como uma fonte de dados de pipeline.
  • Fontes que atualizam e excluem linhas , como a maioria dos bancos de dados e muitos sistemas de software como serviço (SaaS), usam a captura de dados de alterações (CDC). Uma cópia completa em cada execução é um desperdício e torna-se mais lenta à medida que a fonte cresce, portanto, o CDC lê apenas as linhas que mudaram desde a última execução. A API AUTO CDC aplica essas alterações sem lógica de merge escrita manualmente; consulte As APIs AUTO CDC: simplifique a captura de dados de alterações com pipelines. Um fluxo aplica CDC em uma tabela de transmissão, e vários fluxos podem alimentar uma tabela, que é como você distribui várias fontes em um único destino.

O checkpointing e as novas tentativas são automáticos, portanto, um pipeline é retomado a partir do último offset processado, em vez de reprocessar tudo. Duas medidas de segurança são opcionais:

  • Uma coluna de dados resgatados captura registros que não correspondem ao esquema esperado.
  • As expectativas aplicam a ação de nível de linha que você definir.

Se um ponto de verificação de transmissão se tornar inválido, prefira a recuperação mais barata que preserve os dados da tabela.

Nesta etapa​

Questões para refletir nesta fase:

Transformar e modelar​

A transformação converte dados ingeridos em tabelas limpas nas quais pessoas e ferramentas podem confiar. É aqui que o padrão medallion (bronze para prata para ouro) assume uma forma concreta.

A limpeza e a validação vêm em primeiro lugar. As expectativas são um recurso integrado ao pipeline do Lakeflow: restrições de qualidade de dados que o pipeline avalia em cada linha de cada execução, relatando contagens de aprovação e reprovação, de modo que a qualidade seja contínua em vez de uma verificação única. Decida o que acontece quando uma linha falha (avisar e mantê-la, descartá-la ou falhar na atualização) e onde o portão deve ser posicionado. As comportas geralmente ficam no limite entre a camada de bronze e a de prata, então tudo rio abaixo pode ser considerado confiável sem necessidade de nova verificação.

A união e a agregação moldam a transição da prata para o ouro. Uma materialized view se adequa a um join ou agregação em lote sobre tabelas existentes, porque mantém os resultados consistentes com suas fontes: ela refreshes incrementalmente quando a query e as fontes permitem e, caso contrário, recalcula completamente, produzindo o mesmo resultado de qualquer maneira. Isso a torna a escolha certa quando a precisão importa mais do que a latência, já que recalcula as junções quando uma dimensão muda. Veja Como os pipelines refresh? A entrada em transmissões ao vivo gera um estado ilimitado, portanto, os joins de transmissão e as agregações de transmissão precisam de uma marca d'água para limitar por quanto tempo o pipeline espera por dados que chegam com atraso.

Duas ideias de correção percorrem esta etapa:

  • Idempotência significa que um pipeline produz o mesmo resultado, independentemente de quantas vezes ele seja executado sobre a mesma entrada. Os LakeFlow Pipelines são idempotentes para as partes que gerenciam, como leituras com checkpoint e upserts baseados em key AUTO CDC; você mantém sua própria lógica idempotente evitando funções não determinísticas em views recomputadas.
  • Processamento pelo menos uma vez versus exatamente uma vez. As tabelas Delta-to-Delta gerenciadas commit as entradas e saídas de cada micro-batch juntas, proporcionando exatamente uma vez por default. Isso para nas bordas, como um destino personalizado, um alvo que não seja Delta ou uma fonte personalizada não verificada, onde você trata a gravação como pelo menos uma vez e a torna idempotente, por exemplo, fazendo upsert em uma key.

Dimensões que mudam lentamente (SCD) também residem aqui: AUTO CDC implementa SCD Tipo 1 e Tipo 2 diretamente, portanto, você define um tipo em vez de escrever lógica de acompanhamento de história.

Nesta etapa​

Questões para refletir nesta fase:

Operacionalizar​

A operacionalização transforma um pipeline de algo que é executado para você em algo que a equipe pode construir, testar e entregar de forma repetível. Um pipeline é código-fonte mais configuração, portanto, aplicam-se as práticas comuns de engenharia de software.

Os testes abrangem duas coisas simultaneamente: a sua lógica de transformação e a qualidade contínua dos dados que a atravessam. As expectativas lidam continuamente com o lado dos dados. Para a lógica, decomponha as transformações em funções simples e teste-as unitariamente fora do ambiente de execução. Em seguida, valide o gráfico do pipeline com uma simulação antes de materializar qualquer coisa. Consulte Testes unitários para pipelines.

Mantenha o código do pipeline no Git e empacote-o para implantação para que possa ser revisado, revertido e implantado de forma consistente em vários ambientes. O pacote não é uma alternativa aos Lakeflow pipelines. É o projeto e o wrapper de CI/CD em torno do seu pipeline, e sua lógica de dados permanece declarativa. Parametrize valores específicos do ambiente, como nomes de catálogo e caminhos, para que o mesmo código seja executado sem modificações em cada ambiente. Consulte Usar parâmetros com pipelines.

Para executar um pipeline de acordo com um programar, envolva-o em um fluxo de trabalho. A Databricks recomenda o programar e a orquestração de pipelines com Job, que também permitem coordenar o pipeline com outras tarefas, como encadear um relatório subsequente ou vários pipelines. Dentro de uma execução, um pipeline ordena e paraleliza seus próprios conjuntos de dados, portanto, a orquestração apenas coordena tarefas fora do pipeline.

Nesta etapa​

Questões para refletir nesta fase:

Executar em produção​

Assim que um pipeline é executado sem supervisão com dados reais, o trabalho passa a ser saber se ele está íntegro e corrigi-lo quando não estiver.

O monitoramento funciona em três níveis de profundidade. A lista de Empregos e Pipelines oferece uma visão geral do status das execuções recentes. A interface de monitoramento do pipeline exibe cada tabela e fluxo com cores que indicam o status, além de contagens de linhas, métricas de qualidade de dados e métricas de backlog para tabelas de transmissão. O registro de eventos subjacente a ambos é a fonte de verdade para qualquer informação programática ou histórica. Configure notificações de falha para que você fique sabendo de uma execução interrompida antes que seus stakeholders a relatem. Para uma visão geral das superfícies de monitoramento, consulte Monitorar pipelines.

Para depurar, comece pela falha destacada no gráfico e siga até os detalhes completos do erro no log de eventos. Em seguida, execute novamente apenas o que falhou. O comportamento de repetição varia de acordo com o Trigger: atualizações acionadas manualmente desativam as repetições automáticas, permitindo que você veja os erros imediatamente, enquanto atualizações agendadas repetem falhas recuperáveis. Um alerta de produção pode, portanto, se resolver sozinho em uma nova tentativa, enquanto a mesma falha não ocorrerá durante o desenvolvimento interativo. Durante o desenvolvimento, o Genie Code pode ajudar a diagnosticar e corrigir erros no código à medida que você itera, embora atualmente seu foco seja a criação de pipelines em vez do diagnóstico de execuções em produção.

Modele um preenchimento como um fluxo explícito e único, alimentando o mesmo alvo que seu fluxo incremental regular. Manter registros separados de quando e como o histórico foi carregado mantém a lógica de estado estacionário simples.

Proteja um pipeline controlando quem pode operá-lo, executando-o como um Service Principal dedicado em vez de uma account pessoal e mantendo as credenciais em um Secret Scope em vez de no código-fonte. A linhagem é automática, capturada até o nível da coluna. Um pipeline grava em um sistema externo por meio de Sinks em LakeFlow Pipelines, a borda onde se aplica o conceito de "pelo menos uma vez" mencionado acima.

Nesta etapa​

Questões para refletir nesta fase:

Maduro e em escala​

Um pipeline maduro funciona sem supervisão e cresce sem ser reescrito. Confirmar a prontidão e planejar como expandir definem esta etapa.

A prontidão para produção é uma lista de verificação que abrange qualidade de dados, confiabilidade, observabilidade, implantação, custo e governança. Trate cada item não verificado como uma lacuna conhecida: cada dataset que pode receber dados incorretos tem uma expectativa? O pipeline está agendado em vez de iniciado manualmente? As notificações de falha estão configuradas? Ele é executado como um service principal? Ele é implantado a partir do controle de versão em pelo menos um destino de desenvolvimento e produção? Qualidade de dados e notificações são os itens mais baratos de adicionar e os mais propensos a detectar uma execução incorreta não identificada.

Dimensione em resposta a sinais concretos de que a integridade do pipeline está se degradando:

  • A duração da atualização está em tendência de alta.
  • Autoscale está atingindo seu limite máximo repetidamente.
  • Os custos estão crescendo mais rápido do que o negócio em si.
  • As materialized views estão recorrendo a recomputações completas.

Experimente primeiro alavancas de nível de compute, como migrar para serverless ou ajustar seu modo de desempenho às suas necessidades de latência. Além disso, a forma como você organiza conjuntos de dados entre pipelines é o que mais importa:

  • Um pipeline possui um limite de concorrência : ele atualiza apenas um número definido de conjuntos de dados simultaneamente. Quando um pipeline possui mais conjuntos de dados do que esse limite, as atualizações extras ficam em uma fila de espera, aumentando assim o tempo total de atualização do pipeline.
  • Agrupe conjuntos de dados relacionados e divida os não relacionados. Agrupe por domínio, cadência de refresh compartilhada e dependência; divida nos limites de propriedade, camada e latência. Separar a ingestão da transformação, por exemplo, evita que uma ingestão lenta atrase tudo o que está downstream e mantém cada pipeline pequeno o suficiente para permanecer abaixo do limite de simultaneidade.

Mesclar dois pipelines pequenos posteriormente é mais fácil do que dividir um pipeline grande que já está em produção. Para saber como agrupar e dividir conjuntos de dados, consulte Organizar conjuntos de dados em LakeFlow Pipelines.

Nesta etapa​

Questões para refletir nesta fase:

Outros recursos​

Nesta página