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

Preparação para produção de LakeFlow Pipelines

A prontidão para produção é o ponto em que um pipeline pode ser executado sem supervisão com dados reais de negócios, e esta página fornece uma lista de verificação para confirmar se você atingiu esse estágio antes de confiar nele.

Visão geral​

Um pipeline pronto para produção é executado de forma programada, com dados reais de negócios, com falhas detectadas automaticamente em vez de relatadas por um consumidor downstream. A prontidão é uma lista de verificação que abrange qualidade dos dados, confiabilidade, observabilidade, implementação, custo e governança.

LakeFlow Pipelines oferecem diversas primitivas integradas que se mapeiam diretamente nessas dimensões. Em vez de tentar intuir se você está pronto, percorra a lista de verificação abaixo e trate qualquer caixa não marcada como uma lacuna conhecida. Se a maioria das caixas estiver marcada, o pipeline está pronto para execução em produção. Se várias estiverem sem marcar, trate-as como sua lista de tarefas prioritárias. Comece pela qualidade dos dados e pelas notificações, já que são as funcionalidades mais baratas de implementar e as que têm maior probabilidade de detectar uma execução ruim não identificada.

Lista de verificação​

Analise a seguinte lista de verificação em cada dimensão da prontidão para produção e considere qualquer item não marcado como uma lacuna conhecida a ser preenchida antes de confiar no pipeline.

Qualidade dos dados​

  • Todo dataset que pode receber dados ruins tem pelo menos uma expectativa (expect, expect_or_drop, ou expect_or_fail) definida, não apenas um comentário de docstring dizendo "assume entrada limpa".
  • Você escolheu deliberadamente warn versus drop versus fail por restrição: fail para condições que devem interromper o processamento (como uma chave primária quebrada), drop para registros que você pode descartar com segurança (com uma tabela de quarentena capturando o que foi descartado) e warn apenas onde você monitora ativamente a tendência.
  • Você verificou a tab Qualidade dos dados na interface do usuário do pipeline, ou consultou o log de eventos pelo menos uma vez, e conhece sua taxa atual de aprovação de expectativas, não apenas que as expectativas existem. Consulte Gerenciar a qualidade dos dados com expectativas de pipeline.

Confiabilidade​

  • Você escolheu conscientemente entre o modo de pipeline acionado e contínuo . O modo acionado é o default correto para a grande maioria dos pipelines. Reserve o modo contínuo para necessidades reais de latência inferior a um minuto, pois ele requer um cluster sempre ativo. Consulte Modo de Trigger vs. pipeline contínuo.
  • O pipeline é agendado por meio do programador de jobs ou de um LakeFlow Job, em vez de alguém precisar se lembrar de selecionar Começar . Consulte Executar pipelines em um fluxo de trabalho.
  • As notificações de falha são configuradas para email, um webhook ou um event hook para que você saiba sobre uma execução interrompida antes que seus stakeholders.
  • Para fontes de transmissão, você testou o que acontece em uma falha de ponto de verificação e conhece o procedimento de recuperação, em vez de descobri-lo durante um incidente. Consulte Recuperar um pipeline de uma falha de ponto de verificação de transmissão.
  • O pipeline é executado como um Service Principal , e não como uma identidade de usuário pessoal, tornando as execuções mais seguras e estáveis para automação não supervisionada.

Observabilidade​

  • Você sabe onde o log de eventos reside e executou pelo menos uma query nele para linhagem, métricas de qualidade de dados ou uso de recursos. O log de eventos é a primitiva de observabilidade primária para pipelines, e a UI do pipeline é uma view sobre ele. Consulte Monitorar pipelines.
  • Você verificou system.lakeflow.pipelines e tabelas de sistema relacionadas, ou criou um pequeno dashboard, para que a integridade do pipeline possa ser consultada, e não apenas observada visualmente na IU.
  • Você sabe a duração atual das suas atualizações e consegue perceber se ela está aumentando ou se mantendo estável a cada atualização.

Implantação e gestão de mudanças​

  • O pipeline é definido e implantado por meio de um pacote, e não criado manualmente na interface do usuário, permitindo assim a revisão de código e o controle de versão. Consulte Criar um pipeline com controle de versão.
  • Você tem pelo menos um alvo dev e um alvo prod (idealmente dev, staging e prod) para que as alterações sejam validadas em algum lugar antes de atingirem os dados reais.
  • Valores específicos do ambiente (nomes de catálogo, programações, caminhos de origem) são parametrizados por meio da configuração do pipeline em vez de codificados, para que o mesmo código seja promovido de forma limpa entre os destinos.

compute e custo​

  • Você fez uma escolha explícita entre computação Serverless e computação clássica (a computação Serverless é a recomendação default para novos pipelines) e documentou o motivo, caso tenha escolhido a computação clássica. Consulte Configurar um Serverless pipeline.
  • Se estiver no compute clássico, o autoscale aprimorado é habilitado em vez de um tamanho de cluster fixo, para que o pipeline não fique silenciosamente sem workers sob carga.
  • Você já olhou para system.billing.usage pelo menos uma vez para o consumo de unidades Databricks (DBU) deste pipeline e não é um número surpreendente.

Governança​

  • As tabelas de destino residem no Unity Catalog com uma disposição intencional de catálogo e esquema (por exemplo, catálogos ou esquemas separados por ambiente), não no Hive metastore legado.
  • O acesso aos objetos de origem e destino segue o princípio do menor privilégio: a Service Principal do pipeline pode ler e gravar apenas o necessário. Consulte Gerenciar identidades, permissões e privilégios para pipelines.

Outros recursos​

Nesta página