Corrigindo altos tempos de inicialização no pipeline declarativo LakeFlow

O pipeline pode conter muitos conjuntos de dados com muitos fluxos para mantê-los atualizados. pipeline gerencia automaticamente atualizações e clusters para atualizar com eficiência. No entanto, há alguma sobrecarga no gerenciamento de grandes números de fluxos e, às vezes, isso pode levar a uma inicialização maior do que o esperado ou até mesmo a uma sobrecarga de gerenciamento durante o processamento.

Se você estiver enfrentando atrasos na espera pela inicialização do pipeline acionado, como tempos de inicialização superiores a cinco minutos, considere dividir o processamento em vários pipelines, mesmo quando o conjunto de dados usar os mesmos dados de origem.

nota

O pipeline disparado executa a inicialização dos passos cada vez que eles são disparados. O pipeline contínuo só realiza a inicialização dos passos quando eles são parados e reiniciados. Esta seção é mais útil para otimizar a inicialização do pipeline acionado.

Quando considerar a divisão de um pipeline

Há vários casos em que dividir um pipeline pode ser vantajoso por razões de desempenho.

• As fases INITIALIZING e SETTING_UP_TABLES demoram mais do que você gostaria, impactando o tempo geral do seu pipeline. Se esse tempo for superior a 5 minutos, geralmente é possível melhorar dividindo o pipeline.
• O driver que gerencia o cluster pode se tornar um gargalo ao executar muitas (mais de 30-40) tabelas de transmissão dentro de um único pipeline. Se o seu driver não responder, a duração das consultas de transmissão aumentará, impactando o tempo total da sua atualização.
• Um pipeline acionado com vários fluxos de tabela de transmissão pode não ser capaz de executar todas as atualizações de transmissão paralelizáveis em paralelo.

Detalhes sobre problemas de desempenho

Esta seção descreve alguns dos problemas de desempenho que podem surgir ao ter muitas tabelas e fluxos em um único pipeline.

Gargalos nas fases de INICIALIZAÇÃO e CONFIGURAÇÃO_DAS_TABELAS

As fases iniciais da execução podem ser um gargalo de desempenho, dependendo da complexidade do pipeline.

Fase de INICIALIZAÇÃO

Durante esta fase, planos lógicos são criados, incluindo planos para construir o gráfico de dependência e determinar a ordem das atualizações da tabela.

Fase de CONFIGURAÇÃO_DAS_MESAS

Durante esta fase, os seguintes processos são realizados, com base nos planos criados na fase anterior:

• Validação e resolução de esquema para todas as tabelas definidas no pipeline.
• Crie o gráfico de dependência e determine a ordem de execução da tabela.
• Verifique se cada dataset está ativo no pipeline ou é novo desde alguma atualização anterior.
• Crie tabelas de transmissão na primeira atualização e, para a visualização materializada, crie tabelas de visualização temporária ou de backup necessárias durante cada atualização pipeline .

Por que INICIALIZAR e CONFIGURAR TABELAS pode levar mais tempo

Um pipeline grande com muitos fluxos para muitos conjuntos de dados pode levar mais tempo por vários motivos:

• Para pipelines com muitos fluxos e dependências complexas, essas fases podem levar mais tempo devido ao volume de trabalho a ser feito.
• Transformações complexas, incluindo Auto CDC transformações, podem causar gargalo de desempenho, devido às operações necessárias para materializar as tabelas com base nas transformações definidas.
• Também há cenários em que um número significativo de fluxos pode causar lentidão, mesmo que esses fluxos não façam parte de uma atualização. Como exemplo, considere um pipeline com mais de 700 fluxos, dos quais menos de 50 são atualizados para cada gatilho, com base em uma configuração. Neste exemplo, cada execução deve passar por alguns dos passos de todas as 700 tabelas, obter os dataframes e então selecionar aqueles a serem executados.

Gargalos no driver

O driver gerencia as atualizações dentro da execução. Ele deve executar alguma lógica para cada tabela, para decidir quais instâncias em um cluster devem manipular cada fluxo. Ao executar várias tabelas de transmissão (mais de 30-40) dentro de um único pipeline, o driver pode se tornar um gargalo para o recurso da CPU, pois ele lida com o trabalho no cluster.

O driver também pode ser executado em problemas de memória. Isso pode acontecer com mais frequência quando o número de fluxos paralelos é 30 ou mais. Não há um número específico de fluxos ou conjuntos de dados que podem causar problemas de memória do driver, mas depende da complexidade das tarefas que estão sendo executadas em paralelo.

Os fluxos de transmissão podem ser executados em paralelo, mas isso requer que o driver use memória e CPU para todas as transmissões simultaneamente. Em um pipeline acionado, o driver pode processar um subconjunto de transmissões em paralelo por vez, para evitar restrições de memória e CPU.

Em todos esses casos, dividir o pipeline para que haja um conjunto ideal de fluxos em cada um pode acelerar o tempo de inicialização e processamento.

Compensações com a divisão do pipeline

Quando todos os seus fluxos estão dentro do mesmo pipeline, o pipeline declarativo LakeFlow gerencia dependências para você. Quando há vários pipelines, você deve gerenciar as dependências entre eles.

• Dependências Você pode ter um pipeline downstream que depende de vários pipelines upstream (em vez de um). Por exemplo, se você tiver três pipelines, pipeline_A, pipeline_B e pipeline_C, e pipeline_C depender de pipeline_A e pipeline_B, você desejará que pipeline_C atualize somente depois que pipeline_A e pipeline_B tiverem concluído suas respectivas atualizações. Uma maneira de resolver isso é orquestrar as dependências tornando cada pipeline uma tarefa em um Job com as dependências modeladas corretamente, de modo que pipeline_C seja atualizado somente depois que pipeline_A e pipeline_B forem concluídos.

• Simultaneidade Você pode ter fluxos diferentes dentro de um pipeline que levam períodos de tempo muito diferentes para serem concluídos, por exemplo, se flow_A atualiza em 15 segundos e flow_B leva vários minutos. Pode ser útil analisar os tempos de consulta antes de dividir seu pipeline e agrupar consultas mais curtas.

Planeje a divisão do seu pipeline

Você pode visualizar a divisão do seu pipeline antes de começar. Aqui está um gráfico de um pipeline de origem que processa 25 tabelas. Uma única fonte de dados raiz é dividida em 8 segmentos, cada um com 2 visualizações.

Após dividir o pipeline, há dois pipelines. Um processa a única fonte de dados raiz e 4 segmentos e a visualização associada. O segundo pipeline processa os outros 4 segmentos e suas visualizações associadas. O segundo pipeline depende do primeiro para atualizar a fonte de dados raiz.

Dividir o pipeline sem uma refreshcompleta

Depois de planejar a divisão do pipeline , crie qualquer novo pipeline necessário e mova as tabelas entre os pipelines para balancear a carga do pipeline. Você pode mover tabelas sem causar uma refresh completa.

Para obter detalhes, consulte Mover tabelas entre o pipeline declarativo LakeFlow.

Há algumas limitações com esta abordagem:

• O pipeline deve estar no Unity Catalog.
• O pipeline de origem e destino deve estar no mesmo workspace. Não há suporte para movimentações entreworkspace .
• O pipeline de destino deve ser criado e executado uma vez (mesmo que falhe) antes da movimentação.
• Não é possível mover uma tabela de um pipeline que usa o modo de publicação default para um que usa o modo de publicação legado. Para mais detalhes, consulte Esquema LIVE (legado).