Para um sistema de relatórios ETL, é normal que o tempo total de execução de um pull de 15 minutos sem dados seja semelhante a um pull de 24 horas com dados?
Eu esperava que o tempo total para ETL quando não há dados fosse menor, mas essa não é a situação entre um pull de 15 minutos e 24 horas. Mas devo confessar que não sei nada sobre as partes internas das fases T e L dentro de um servidor de relatório.
Alguém pode esclarecer se as fases T e L são tipicamente fixas em duração (até certo ponto)?
Não há nada especificamente quantificável sobre os conceitos abstratos de Transform e Load , apenas suas implementações concretas são mensuráveis. Para poder comentar sobre seu caso, precisaríamos saber especificamente o que seus processos de Transformação e Carregamento estão realmente fazendo. Obviamente, algumas Transformações podem levar muito mais tempo do que outras.
Mas, de um modo geral, a quantidade de dados processados definitivamente deve afetar o tempo de execução geral de um processo ETL . Se houver uma diferença significativa na quantidade de dados entre um período de 24 horas e um período de 15 minutos, mas seu processo de ETL estiver sendo executado aproximadamente no mesmo tempo de execução médio para ambos os casos, algo é definitivamente suspeito, e isso não é normal.
Mesmo que uma verificação de índice esteja ocorrendo em ambos os casos, se houver uma diferença significativa na quantidade de dados, o tempo de execução total certamente deve refletir isso. O tempo de execução de uma varredura de índice é linear (em termos gerais) com base no número de linhas no índice.
Eu também adicionaria algumas coisas sobre o Power BI.
Muitas vezes, em modelos do Power BI, você usará o modo "importar dados". Nesse caso, quando você atualiza apenas algumas linhas em seus dados de origem, o mecanismo de armazenamento do Power BI criará uma nova cópia completa de todos os dados de origem (ou se o processo for otimizado apenas partições específicas). O Power BI usa o mesmo mecanismo que as colunas não atualizáveis armazenam índices, portanto, toda a partição de índice precisa ser recompilada após cada alteração.
Você pode ler mais sobre a atualização do Power BI aqui: https://learn.microsoft.com/en-us/power-bi/connect-data/refresh-data .
Normalmente, você não usará partições menores que um dia, portanto, espera-se que a atualização de 15 minutos ou 24h cause a reconstrução das mesmas partições e essa fase do ETL levará um tempo semelhante.
Claro que é apenas uma das fases do processo ETL, mas muitas vezes a mais longa.
As respostas de JD e Piotr são úteis e contêm dados valiosos, mas infelizmente não são a resposta real para esse problema. Isso não é culpa deles.
Quando comecei a investigar isso, descobri que isso é simplesmente um problema de extração de pacotes SSIS. Na época, eu não tinha conhecimento suficiente para explorar o painel do relatório de integração do SSIS para entender o que estava vendo.
A etapa final que eu precisava dar era abrir o projeto no visual studio e ver o designer da caixa de ferramentas do SSIS mostrando as várias etapas. Aprendendo como funciona o processo. Muito interessante e poderoso!
Finalmente cheguei a uma tabela que estava sendo puxada (extraída) em sua totalidade porque falta uma coluna timestamp. Essa tabela contém 4 milhões de linhas de 3 colunas pequenas e a lógica do SSIS usa uma ação de 'pesquisa' para decidir se o banco de dados do relatório precisa ser atualizado ou inserido.
Esta ação de pesquisa da caixa de ferramentas do SSIS tinha a opção de cache de memória desabilitada ! Caramba!
Levava 40 minutos para processar essa tabela todas as vezes, independentemente de quantos minutos a extração original foi definida.
O Power BI não tem nada a ver com isso. Minhas desculpas pela confusão.