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

How to use 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.

This guide assumes familiarity with core data engineering concepts. If you are new to pipelines, start with Apache Spark Declarative Pipelines for what the product is and the declarative model behind it, then work through the Tutorial: Build an ETL pipeline using change data capture.

Visão geral do ciclo de vida do pipeline​

A pipeline moves through six stages:

  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. Transform and model: Clean, validate, join, and shape data into tables consumers can trust.
  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. Mature and scale: Confirm production readiness and keep the pipeline healthy as volume and team size grow.

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.

A few choices set your starting configuration:

  • A standalone dataset or a pipeline. A single materialized view or streaming table can be defined in SQL as a standalone dataset, and Databricks manages the refresh pipeline behind it. Author and operate a Lakeflow pipeline as a unit when you need Python authoring, sinks, or multi-stage orchestration. See Standalone pipelines 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.
  • Serverless or classic compute. Serverless is the recommended default and removes cluster configuration. Choose classic when you need specific instance types, custom cluster policies, or an init script. See Configure a serverless pipeline and Configure classic compute for 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?.

Because pipeline code is ordinary Python and SQL, you can write, lint, and validate it in your own editor before deploying to a shared workspace.

In this stage​

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:

  • Append-only sources , such as files landing in cloud storage or events on a message bus, ingest into a streaming table, which checkpoints its progress so a restart neither reprocesses nor drops data. Auto Loader handles files, discovering new ones and inferring and evolving schema as they arrive. Message buses such as Apache Kafka, Azure Event Hubs, Amazon Kinesis, and Google Pub/Sub read directly into a streaming table. Deduplicate downstream, since a bus can deliver the same event more than once. For Azure Event Hubs specifically, see Use Azure Event Hubs as a pipeline data source.
  • Sources that update and delete rows , such as most databases and many software as a service (SaaS) systems, use change data capture (CDC). A full copy on every run is wasteful and grows slower as the source grows, so CDC reads only the rows that changed since the last run. The AUTO CDC API applies those changes without hand-written merge logic; see The AUTO CDC APIs: Simplify change data capture with pipelines. A flow applies CDC into a streaming table, and several flows can feed one table, which is how you fan multiple sources into a single target.

Checkpointing and retries are automatic, so a pipeline resumes from the last processed offset rather than reprocessing everything. Two safeguards are opt-in:

  • A rescued-data column captures records that don't match the expected schema.
  • Expectations apply the row-level action you define.

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.

In this stage​

Questões para refletir nesta fase:

Transformar e modelar​

Transformation turns ingested data into clean tables that people and tools can trust. This is where the medallion pattern (bronze to silver to gold) takes concrete form.

Cleaning and validation come first. Expectations are a built-in Lakeflow pipeline feature: data quality constraints the pipeline evaluates on every row of every run, reporting pass and fail counts, so quality is continuous rather than a one-time gate. Decide what happens when a row fails (warn and keep it, drop it, or fail the update) and where the gate belongs. Gates usually sit at the bronze-to-silver boundary, so everything downstream can be trusted without re-checking.

Joining and aggregating shape the silver-to-gold step. A materialized view fits a batch-style join or aggregation over existing tables, because it keeps results consistent with its sources: it refreshes incrementally when the query and sources allow and otherwise recomputes in full, producing the same result either way. That makes it the right choice when correctness matters more than latency, since it recomputes joins when a dimension changes. See How do pipelines refresh?. Joining live streams raises unbounded state, so streaming joins and aggregations need a watermark to bound how long the pipeline waits for late-arriving data.

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.
  • At-least-once versus exactly-once processing. Managed Delta-to-Delta tables commit each micro-batch's inputs and outputs together, giving you exactly-once by default. That stops at the edges, such as a custom sink, a non-Delta target, or an unverified custom source, where you treat the write as at-least-once and make it idempotent, for example by upserting on a key.

Slowly changing dimensions (SCDs) also live here: AUTO CDC implements SCD Type 1 and Type 2 directly, so you set a type rather than write history-tracking logic.

In this stage​

Questões para refletir nesta fase:

Operationalize​

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.

Testing covers two things at once: your transformation logic and the ongoing quality of the data flowing through it. Expectations handle the data side continuously. For logic, factor transformations into plain functions and unit-test them outside the runtime, then validate the pipeline graph with a dry run before materializing anything. See Unit testing for pipelines.

Keep pipeline code in Git and package it for deployment so it can be reviewed, reverted, and deployed consistently across environments. The package is not an alternative to Lakeflow pipelines. It is the project and CI/CD wrapper around your pipeline, and your data logic stays declarative. Parameterize environment-specific values like catalog names and paths so the same code runs unmodified in each environment. See Use parameters with 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.

In this stage​

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.

Monitoring works at three levels of depth. The Jobs & Pipelines list gives an at-a-glance status for recent runs. The pipeline monitoring UI shows every table and flow color-coded by status, with row counts, data quality metrics, and backlog metrics for streaming tables. The event log underneath both is the source of truth for anything programmatic or historical. Configure failure notifications so you learn about a broken run before your stakeholders report it. For an overview of the monitoring surfaces, see Monitor pipelines.

Debug by working backward from the failure highlighted on the graph to the full error detail in the event log, then re-run only what failed. Retry behavior differs by trigger: manually triggered updates disable automatic retries so you see errors immediately, while scheduled updates retry recoverable failures. A production alert might therefore clear itself on retry where the same failure won't during interactive development. While developing, Genie Code can help diagnose and fix code-level errors as you iterate, though today it targets authoring pipelines rather than diagnosing production runs.

Model a backfill as its own explicit, one-time flow feeding the same target as your regular incremental flow. Keeping it separate records when and how history was loaded and keeps the steady-state logic simple.

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.

In this stage​

Questões para refletir nesta fase:

Mature and scale​

A mature pipeline runs unattended and grows without a rewrite. Confirming readiness and planning how to scale define this stage.

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.

Scale in response to concrete signals that pipeline health is degrading:

  • 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.

Try compute-level levers first, such as moving to serverless or matching its performance mode to your latency needs. Beyond that, how you organize datasets across pipelines matters most:

  • A pipeline has a concurrency limit : it updates only a set number of datasets at the same time. Once a pipeline has more datasets than that limit, the extra updates wait in a queue, so the pipeline's total update time grows.
  • 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.

In this stage​

Questões para refletir nesta fase:

Additional resources​

Nesta página