Como utilizar os oleodutos Lakeflow

Esta página explica como utilizar pipelines Lakeflow ao longo do ciclo de vida de um pipeline de dados, desde as primeiras decisões de conceção até à execução à escala, e as vantagens e desvantagens de cada fase. Cada secção liga aos artigos que mostram como.

Este guia assume familiaridade com conceitos fundamentais de engenharia de dados. Se és novo em pipelines, começa pelos Apache Spark Declarative Pipelines para ver o que é o produto e o modelo declarativo por trás dele, depois segue o Tutorial: Constrói um pipeline ETL usando a captura de dados de alteração.

Visão geral do ciclo de vida do oleoduto

Um oleoduto avança por seis etapas:

  1. Planeia e desenha: Decide o que estás a construir e escolhe as ferramentas, a linguagem e os cálculos que se encaixam.
  2. Ingestão de dados: Integrar dados de origem no pipeline de forma fiável e incremental.
  3. Transformar e modelar: Limpar, validar, juntar e moldar dados em tabelas em que os consumidores possam confiar.
  4. Operacionalizar: Colocar o pipeline sob controlo de versões, testá-lo, agendar e promovê-lo entre ambientes.
  5. Executar em produção: Monitorizar, alertar, depurar, preencher, proteger e acompanhar a linhagem enquanto o pipeline corre sem vigilância.
  6. Amadurecer e escalar: Confirmar a prontidão para entrar em produção e manter o pipeline em bom estado à medida que o volume e a dimensão da equipa crescem.

As fases não são estritamente sequenciais, mas correspondem à ordem em que surgem as perguntas. Como os pipelines do Lakeflow tratam da orquestração, da criação de pontos de controlo, das novas tentativas e do processamento incremental, o seu trabalho em cada etapa consiste sobretudo numa decisão de conceção, mais do que de implementação.

Planejar e projetar

As tuas primeiras decisões moldam tudo daqui para a frente. Para saber como o modelo declarativo se compara com a escrita de passos procedurais por si próprio, veja Procedural vs. declarative data processing in Azure Databricks.

Algumas escolhas definem a sua configuração inicial:

  • Um conjunto de dados autónomo ou um pipeline. Uma única vista materializada ou tabela de streaming pode ser definida em SQL como um conjunto de dados autónomo, e o Azure Databricks gere o processo de atualização subjacente. Crie e opere um pipeline do Lakeflow como uma unidade quando precisar de criação em Python, destinos ou orquestração em várias etapas. Veja Oleodutos independentes vs. oleodutos de fluxo de lago.
  • SQL ou Python (ou ambos). SQL adequa-se a transformações que são maioritariamente filtros, joins e agregações. Python adequa-se para lógica personalizada, bibliotecas externas ou para gerar muitas tabelas semelhantes de forma programática. A escolha é feita por ficheiro, e não ao nível de todo o pipeline, pelo que pode misturar ambas as opções e não tem de decidir isso à partida.
  • Serverless ou computação clássica. 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 personalizadas de cluster ou um script de init. Veja Configurar um pipeline sem servidor e Configurar computação clássica para pipelines.
  • Execução desencadeada ou contínua. Início acionado, já que só consome recursos de computação enquanto estiver em execução. O modo contínuo mantém o cálculo a correr para processar novos dados com um atraso mínimo, que normalmente é o maior fator de custo, por isso reserve-o para um requisito comprovado de latência. Consulte Modo de fluxo de trabalho acionado versus contínuo.

Um pipeline infere o seu grafo de execução a partir dos conjuntos de dados referenciados pelo seu código, por isso o trabalho de design consiste sobretudo em nomear e sequenciar conjuntos de dados. A principal decisão é que tipo cada saída deve ter: Streaming tables para dados incrementais com muitas adições, ou Materialized views para agregações e junções recalculadas. Essa escolha condiciona o custo e a exatidão, porque o processamento incremental varia em função do ritmo de chegada de novos dados, enquanto uma recomputação completa varia em função da totalidade do histórico. Para saber que tipo se adequa a cada função, veja O que são pipelines?

Como o código de pipeline é Python e SQL comuns, pode escrevê-lo, lint e validá-lo no seu próprio editor antes de o implementar num espaço de trabalho partilhado.

Nesta fase

Perguntas a considerar nesta fase:

Ingerir dados

A questão central do design é se uma fonte é apenas acrescentada ou se faz alterações no local. Isso determina como modela o alvo:

  • Fontes apenas anexadas, como ficheiros que caem em armazenamento na cloud ou eventos num barramento de mensagens, ingerem numa tabela de streaming, que verifica o seu progresso, de modo que um reinício não reprocessa nem deixa cair dados. O Auto Loader trata de ficheiros, descobrindo novos e inferindo e evoluindo esquemas à medida que chegam. Barramentos de mensagens como Apache Kafka, Hubs de Eventos do Azure, Amazon Kinesis e Google Pub/Sub são lidos diretamente para uma tabela de streaming. Desduplicar a jusante, já que um bus pode entregar o mesmo evento mais do que uma vez. Especificamente para o Hubs de Eventos do Azure, veja Utilizar o Hubs de Eventos do Azure como origem de dados do pipeline.
  • Fontes que atualizam e eliminam linhas, como a maioria das bases de dados e muitos sistemas de software como serviço (SaaS), utilizam captura de dados de alteração (CDC). Uma cópia completa em cada execução é um desperdício e torna-se mais lenta à medida que a origem cresce, por isso o CDC lê apenas os registos que foram alterados desde a última execução. A API AUTO CDC aplica essas mudanças sem lógica de fusão escrita manualmente; veja As APIs AUTO CDC: simplificam a captura de dados de alteração através de pipelines. Um fluxo aplica CDC a uma tabela de streaming, e vários fluxos podem alimentar uma tabela, que é assim que várias fontes convergem num único destino.

A criação de pontos de verificação e as novas tentativas são automáticas, pelo que um pipeline retoma a execução a partir do último offset processado, em vez de voltar a processar tudo. Duas salvaguardas são de adesão voluntária:

  • Uma coluna de dados resgatados captura registos que não correspondem ao esquema esperado.
  • As expectativas aplicam a ação ao nível da linha que defines.

Se um checkpoint de streaming se tornar inválido, prefira a recuperação menos dispendiosa que preserve os dados da tabela.

Nesta fase

Perguntas a considerar nesta fase:

Transformar e modelar

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

A limpeza e a validação vêm em primeiro lugar. As expectativas são uma funcionalidade incorporada do pipeline Lakeflow: restrições de qualidade dos dados que o pipeline avalia em todas as linhas de cada execução, reportando contagens de passagens e falhas, pelo que a qualidade é contínua em vez de uma porta única. Decide o que acontece quando uma linha falha (avisa e mantém-na, retira-a ou falha a atualização) e onde o portal pertence. Os pontos de controlo situam-se normalmente na transição entre bronze e prata, pelo que tudo o que está a jusante pode ser considerado fiável sem necessidade de nova verificação.

A união e a agregação dão forma ao passo prata para ouro. Uma visualização materializada ajusta-se a uma junção ou agregação em lote sobre tabelas existentes, porque mantém os resultados consistentes com as suas fontes: atualiza-se incrementalmente quando a consulta e as fontes permitem e, de resto, recalcula na totalidade, produzindo o mesmo resultado de qualquer forma. Isso torna-a a escolha certa quando a correção importa mais do que a latência, pois recalcula as junções quando uma dimensão muda. Veja Como é que os pipelines atualizam?. Fazer junções em fluxos de dados em tempo real gera um estado não limitado, pelo que as junções e agregações em fluxo precisam de uma watermark para delimitar durante quanto tempo o pipeline espera por dados que chegam com atraso.

Duas ideias de correção passam por esta fase:

  • Idempotência significa que um pipeline produz sempre o mesmo resultado, independentemente do número de vezes que é executado com a mesma entrada. Os pipelines do Lakeflow são idempotentes nas partes que gerem, como leituras com checkpoint e upserts baseados em chaves AUTO CDC; mantém a sua própria lógica idempotente, evitando funções não determinísticas nas vistas recalculadas.
  • Processamento pelo menos uma vez versus processamento exatamente uma vez. As tabelas geridas de Delta para Delta registam em conjunto as entradas e saídas de cada microlote, garantindo por predefinição o processamento exatamente uma vez. Isso termina nas extremidades, como um sink personalizado, um alvo não-Delta ou uma fonte personalizada não verificada, onde tratas a escrita como pelo menos uma vez e tornas-a idempotente, por exemplo ao fazer upserting numa chave.

Dimensões que mudam lentamente (SCDs) também existem aqui: AUTO CDC implementam diretamente o SCD Tipo 1 e Tipo 2, por isso defines um tipo em vez de escrever lógica de rastreamento de histórico.

Nesta fase

Perguntas a considerar nesta fase:

Operacionalizar

A operacionalização transforma um pipeline de algo que funciona apenas para uma pessoa em algo que a equipa consegue construir, testar e disponibilizar de forma repetível. Um pipeline é código-fonte mais configuração, pelo que as práticas normais de engenharia de software aplicam-se.

Os testes abrangem duas coisas ao mesmo tempo: a lógica de transformação e a qualidade contínua dos dados que nela fluem. As expectativas tratam da vertente dos dados de forma contínua. Quanto à lógica, decomponha as transformações em funções simples e submeta-as a testes unitários fora do ambiente de execução; depois, valide o grafo do pipeline com uma simulação antes de materializar o que quer que seja. Veja Testes unitários para pipelines.

Mantém o código do pipeline no Git e empacote-o para implementação, para que possa ser revisto, revertido e implementado de forma consistente em vários ambientes. O pacote não é uma alternativa aos oleodutos Lakeflow. Trata-se do projeto e da camada envolvente de CI/CD em torno do teu pipeline, e a tua lógica de dados mantém-se declarativa. Parametrize valores específicos do ambiente, como nomes de catálogo e caminhos, para que o mesmo código corra sem alterações em cada ambiente. Consulte Usar parâmetros com pipelines.

Para executar um pipeline de forma agendada, inclua-o num Executar pipelines num fluxo de trabalho: a Databricks recomenda agendar e orquestrar pipelines com tarefas, o que também permite coordenar o pipeline com outro trabalho, como encadear um relatório subsequente ou vários pipelines. Numa execução, um pipeline ordena e paraleliza os seus próprios conjuntos de dados, pelo que a orquestração só coordena tarefas fora do pipeline.

Nesta fase

Perguntas a considerar nesta fase:

Executar em produção

Uma vez que um pipeline corre sem vigilância em relação a dados reais, o trabalho passa a ser saber se está saudável e corrigi-lo quando não está.

A monitorização funciona a três níveis de profundidade. A lista Jobs & Pipelines apresenta uma visão geral do estado das execuções recentes. A interface de monitorização do pipeline mostra todas as tabelas e fluxos identificados por cores consoante o estado, com número de linhas, métricas de qualidade dos dados e métricas de backlog para tabelas de streaming. O registo de eventos por baixo de ambos é a fonte de verdade para tudo o que seja programático ou histórico. Configure as notificações de falha para ser informado de uma execução com falha antes de as partes interessadas reportarem o problema. Para uma visão geral das superfícies de monitorização, consulte Monitorizar pipelines.

Depure retrocedendo a partir da falha destacada no gráfico até ao detalhe completo do erro no registo de eventos e, em seguida, execute novamente apenas o que falhou. O comportamento das retentativas varia consoante o gatilho: as atualizações acionadas manualmente desativam as tentativas automáticas para que veja erros imediatamente, enquanto as atualizações agendadas retentam falhas recuperáveis. Um alerta de produção pode, portanto, desaparecer numa nova tentativa, ao passo que a mesma falha não desaparece durante o desenvolvimento interativo. Durante o desenvolvimento, o Genie Code pode ajudar a diagnosticar e corrigir erros ao nível do código à medida que se itera, embora hoje em dia tenha como objetivo criar pipelines em vez de diagnosticar execuções em produção.

Modele um preenchimento retroativo como um fluxo explícito e pontual que alimenta o mesmo destino que o seu fluxo incremental habitual. Mantê-lo separado permite registar quando e como o histórico foi carregado e mantém simples a lógica em regime estacionário.

Proteja um pipeline controlando quem pode operá-lo, executando-o como um principal de serviço dedicado em vez de uma conta pessoal, e mantendo as credenciais num âmbito secreto em vez de no código-fonte. A linhagem é automática, capturada até ao nível da coluna. Um pipeline escreve para um sistema externo através de pipelines Sinks in Lakeflow, a borda onde se aplica o pensamento acima pelo menos uma vez.

Nesta fase

Perguntas a considerar nesta fase:

Amadurecer e escalar

Uma canalização madura funciona sem supervisão e cresce sem ter de ser reescrita. Confirmar a prontidão e planear como escalar definem esta fase.

A prontidão para produção é uma lista de verificação que abrange qualidade dos dados, fiabilidade, observabilidade, implementação, custo e governação. Trate cada item não verificado como uma lacuna conhecida: cada conjunto de dados que pode receber dados errados tem uma expectativa, o pipeline está agendado em vez de iniciado manualmente, as notificações de falhas estão configuradas, corre como um principal de serviço, é implementado a partir do controlo de versões pelo menos num alvo de desenvolvimento e produção? A qualidade dos dados e as notificações são as medidas mais fáceis e baratas de implementar e as mais suscetíveis de detetar uma execução com falhas que, de outro modo, passaria despercebida.

Escala em resposta a sinais concretos de que a saúde do oleoduto está a degradar-se:

  • A duração da atualização está a aumentar.
  • O dimensionamento automático está constantemente a atingir o limite máximo.
  • O custo está a crescer mais rapidamente do que o negócio subjacente.
  • As visualizações materializadas estão a regressar a recomputações completas.

Experimente primeiro alavancas ao nível de computação, como passar para serverless ou ajustar o modo de desempenho às suas necessidades de latência. Para além disso, a forma como organizas conjuntos de dados entre pipelines é o que mais importa:

  • Um pipeline tem um limite de concorrência: atualiza apenas um número definido de conjuntos de dados ao mesmo tempo. Quando um pipeline tem mais conjuntos de dados do que esse limite, as atualizações extra aguardam numa fila, pelo que o tempo total de atualização do pipeline aumenta.
  • Agrupar conjuntos de dados relacionados e dividir os não relacionados. Agrupe por domínio, cadência de atualização partilhada e dependência; divida nos limites de responsabilidade, de camada e de latência. Separar a ingestão da transformação, por exemplo, evita que uma ingestão lenta atrase tudo a jusante e mantém cada pipeline suficientemente pequeno para se manter abaixo do limite de concorrência.

Fundir dois pequenos pipelines mais tarde é mais fácil do que dividir um grande pipeline já em produção. Para saber como agrupar e dividir conjuntos de dados, veja Organizar conjuntos de dados através dos pipelines Lakeflow.

Nesta fase

Perguntas a considerar nesta fase:

Recursos adicionais

  • Last updated on