Fixação de altos tempos de inicialização em pipelines

Os pipelines podem conter muitos conjuntos de dados com muitos fluxos para mantê-los atualizados. Os pipelines gerenciam automaticamente atualizações e clusters para atualização eficiente. No entanto, há alguma sobrecarga com o 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 sobrecarga de gerenciamento durante o processamento.

Se você estiver enfrentando atrasos aguardando a inicialização de pipelines acionados, como tempos de inicialização superiores a cinco minutos, considere dividir o processamento em vários pipelines, mesmo quando os conjuntos de dados usam os mesmos dados de origem.

Observação

Os pipelines acionados realizam as etapas de inicialização sempre que são acionados. Os pipelines contínuos só executam as etapas de inicialização quando são interrompidos 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 motivos de desempenho.

• As fases INITIALIZING e SETTING_UP_TABLES demoram mais tempo do que o desejado, afetando o tempo total do pipeline. Se isto durar mais de 5 minutos, geralmente é melhorado dividindo a sua pipeline.
• O driver que gerencia o cluster pode se tornar um gargalo ao executar muitas (mais de 30-40) tabelas de streaming dentro de um único pipeline. Se o driver não estiver respondendo, as durações das consultas de streaming aumentarão, afetando o tempo total da atualização.
• Um pipeline acionado com vários fluxos de tabelas de streaming poderá não conseguir executar em paralelo todas as atualizações de fluxo que são paralelizáveis.

Detalhes sobre problemas de desempenho

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

Gargalos nas fases de INICIALIZAÇÃO e CONFIGURAÇÃO_DE_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, são criados planos lógicos, incluindo planos para construir o gráfico de dependência e determinar a ordem das atualizações da tabela.

FASE_DE_CONFIGURAÇÃO_DE_TABELAS

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

• Validação e resolução do 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 conjunto de dados está ativo no pipeline ou se é novo desde qualquer atualização anterior.
• Crie tabelas de streaming na primeira atualização e, para exibições materializadas, crie exibições temporárias ou tabelas de backup necessárias durante cada atualização de pipeline.

Por que INICIALIZAR e CONFIGURAR_TABELAS podem levar mais tempo

Grandes pipelines com muitos fluxos para muitos conjuntos de dados podem 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 um gargalo de desempenho, devido às operações necessárias para materializar as tabelas com base nas transformações definidas.
• Existem também 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 que tenha 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 algumas das etapas de todas as 700 tabelas, obter os dataframes e selecionar os que serão executados.

Gargalos no motorista

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 lidar com cada fluxo. Ao executar várias (mais de 30-40) tabelas de streaming dentro de um único pipeline, o driver pode se tornar um gargalo para os recursos da CPU à medida que lida com o trabalho em todo o cluster.

O driver também pode ter problemas de memória. Isso pode acontecer com mais frequência quando o número de fluxos paralelos é de 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 streaming podem ser executados em paralelo, mas isso requer que o driver use memória e CPU para todos os fluxos simultaneamente. Em um pipeline acionado, o driver pode processar um subconjunto de fluxos em paralelo de cada vez, para evitar restrições de memória e CPU.

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

Concessões na divisão de pipelines

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

• Dependências Você pode ter um pipeline downstream que depende de vários pipelines upstream (em vez de um). Por exemplo, se tu tiveres três pipelines, pipeline_A, pipeline_B e pipeline_C, e pipeline_C depender de pipeline_A e de pipeline_B, pretendes que pipeline_C atualize somente depois de ambos pipeline_A e pipeline_B terem concluído as suas respetivas atualizações. Uma maneira de resolver isso é orquestrar as dependências tornando cada pipeline uma tarefa em um trabalho com as dependências devidamente modeladas, para que pipeline_C só sejam atualizadas depois de ambas pipeline_A e pipeline_B sejam concluídas.

• Simultaneidade Você pode ter fluxos diferentes dentro de uma linha de processamento que levam quantidades muito diferentes de tempo para serem concluídos, por exemplo, se flow_A as atualizações forem feitas em 15 segundos e flow_B levarem vários minutos. Pode ser útil examinar os tempos de consulta antes de dividir os pipelines e agrupar consultas mais curtas.

Planeie a divisão das suas pipelines

Você pode visualizar a divisão do 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.

Depois de dividir o gasoduto, existem dois gasodutos. Um processa a única fonte de dados raiz e 4 segmentos e exibições associadas. O segundo pipeline processa os outros 4 segmentos e suas visões associadas. O segundo pipeline depende do primeiro para atualizar a fonte de dados raiz.

Dividir o pipeline sem uma atualização completa

Depois de ter planeado a divisão do seu pipeline, crie quaisquer novos pipelines necessários e mova tabelas entre eles para equilibrar a carga do pipeline. Você pode mover tabelas sem causar uma atualização completa.

Consulte Mover tabelas entre pipelines para mais detalhes.

Existem algumas limitações com esta abordagem:

• Os pipelines devem estar no Unity Catalog.
• Os pipelines de origem e de destino devem estar dentro do mesmo espaço de trabalho. Não há suporte para movimentações entre espaços de trabalho.
• O pipeline de destino deve ser criado e executado uma vez (mesmo que falhe) antes da transferência.
• Não é possível mover uma tabela de um pipeline que usa o modo de publicação padrão para um que usa o modo de publicação herdado. Para obter mais detalhes, consulte Esquema LIVE (legado).