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 give you several built-in primitives that map directly onto these dimensions. Rather than trying to intuit whether you're ready, walk through the checklist below and treat any unchecked box as a known gap. If most boxes are checked, the pipeline is ready to run in production. If several are unchecked, treat those as your prioritized to-do list. Start with data quality and notifications, since those are the cheapest to add and the most likely to catch an undetected bad run.

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​

  • Every dataset that can receive bad data has at least one expectation (expect, expect_or_drop, or expect_or_fail) defined, not just a docstring comment saying "assume clean input."
  • 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.
  • You've looked at the Data quality tab in the pipeline UI, or queried the event log at least once, and know your current expectation pass rate, not just that expectations exist. See Manage data quality with pipeline expectations.

Reliability​

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

  • You know where the event log lives and have run at least one query against it for lineage, data-quality metrics, or resource usage. The event log is the primary observability primitive for pipelines, and the pipeline UI is a view over it. See Monitor 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.
  • You know your current update duration and can tell whether it's trending up or holding steady update over update.

Deployment and change management​

  • The pipeline is defined and deployed through a bundle, not hand-clicked into existence in the UI, so it can be code-reviewed and version-controlled. See Create a source-controlled pipeline.
  • 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.
  • If on classic compute, enhanced autoscaling is enabled rather than a fixed cluster size, so the pipeline doesn't silently starve for workers under load.
  • You've looked at system.billing.usage at least once for this pipeline's Databricks unit (DBU) consumption and it isn't a surprise number.

Governança​

  • Target tables live in Unity Catalog with an intentional catalog and schema layout (for example, separate catalogs or schemas per environment), not the legacy Hive metastore.
  • 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.

Additional resources​

Nesta página