Performance do Process Mining: benchmarks e dicas

O que influencia a performance do Process Mining

A performance do Process Mining depende de três fatores: quanto de dados você envia, como os estrutura e como o sistema os processa. Este guia aborda os três pontos com benchmarks reais e formas práticas de melhorar os resultados.

Publicamos todos os nossos números. Compare-os com qualquer ferramenta de Process Mining do mercado.

O pipeline de dados: onde o tempo é gasto

Quando você envia dados para o ProcessMind, três coisas acontecem. Veja exatamente onde o tempo é gasto:

1. Upload (domina o tempo total). Seu arquivo percorre a internet até nossa infraestrutura em nuvem. Esse é o gargalo para arquivos grandes. A física prevalece: um CSV com 50 milhões de eventos (11 GB) leva 2 minutos em uma conexão de 1 Gbps, 18 minutos a 100 Mbps ou mais de 3 horas a 10 Mbps. Os mesmos dados em Parquet ocupam apenas 1,7 GB, reduzindo esses tempos para 19 segundos, 3 minutos e 28 minutos. Esse é o principal motivo para usar formatos colunares, como Parquet ou ORC, ou conjuntos de dados menores.

2. Pré-processamento (custo único, de ~30 s a 2,5 min). Depois do upload, transformamos seus dados em armazenamento colunar otimizado: eventos indexados, transições de atividades pré-calculadas, variantes de processo identificadas e estatísticas resumidas calculadas. Isso leva 30 segundos para conjuntos de dados pequenos e até 2,5 minutos para 100 milhões de eventos. Você paga esse custo uma vez por upload e se beneficia dele depois.

3. Alterações no modelo (recálculo parcial, 6–52 s). Quando você modifica o modelo do processo adicionando ou removendo atividades ou alterando mapeamentos, apenas os cálculos dependentes do modelo são atualizados. Isso leva 6 segundos para conjuntos de dados pequenos e até 52 segundos para 100 milhões de eventos, muito mais rápido que o pré-processamento completo. Alterações nos filtros são instantâneas.

Entendendo a performance das consultas

Depois que seus dados são carregados, várias características determinam a velocidade das consultas. Entendê-las ajuda você a criar exportações melhores e definir expectativas realistas.

A quantidade de atividades importa. Modelos de processo com 10–20 atividades distintas são ideais. Acima de 50 atividades, o fluxo do processo demora mais para ser calculado e fica mais difícil de entender. Nós e conexões em excesso criam ruído visual. Se sua exportação contiver muitas atividades, considere agrupar etapas relacionadas.

A diversidade de variantes afeta o cálculo. Um processo em que 80% dos casos seguem 5 variantes é mais rápido de analisar do que outro em que cada caso percorre um caminho único. Uma variação elevada não é necessariamente ruim e muitas vezes indica problemas reais, mas espere tempos de consulta um pouco maiores.

Mais colunas significam mais dados para examinar. Cada atributo incluído é indexado e consultado. As colunas principais, CaseId, Activity e Timestamp, são sempre necessárias. Colunas adicionais ajudam na filtragem e na categorização, mas cada uma acrescenta sobrecarga.

Casos longos demoram mais. Um caso com 50 eventos exige mais processamento do que um com 5. Se seu processo tiver casos com centenas de eventos, as consultas serão proporcionalmente mais lentas. Isso é inerente ao Process Mining, não específico de uma ferramenta.

Dados de benchmark do mundo real (março de 2026)

Entender o que esperar ajuda você a se planejar. Esses benchmarks foram executados em uma infraestrutura AWS de produção, com latência de rede real, e calculados como médias de várias execuções de teste. Testamos mais de 50 tipos de consulta por tamanho de conjunto de dados.

Tempos de upload e pré-processamento

A tabela abaixo mostra expectativas realistas para cada tamanho de conjunto de dados. O tempo de upload predomina nos arquivos maiores, especialmente em conexões mais lentas. Ele é o maior fator individual no seu tempo total de espera.

Os tamanhos dos arquivos consideram um CSV não compactado com um esquema típico de Event Log (CaseId, Activity, Timestamp e mais 5–8 atributos de negócio). Seus arquivos podem ser maiores ou menores, dependendo da quantidade e do conteúdo das colunas.

Os tempos de upload a 1 Gbps foram medidos com throughput efetivo de 88 MB/s até a AWS eu-central-1. As demais velocidades foram extrapoladas usando throughputs práticos: 50 Mbps → ~5 MB/s, 100 Mbps → ~10 MB/s, 10 Mbps → ~1 MB/s. O throughput real depende da sua rede, da distância até o data center e da carga atual.

O principal insight: o tempo de pré-processamento se mantém entre 1 e 2,5 minutos, independentemente da escala. O tempo de upload cresce linearmente com o tamanho do arquivo. Reduzir o tamanho do arquivo é a otimização de maior impacto que você pode fazer.

Escolha o formato de arquivo certo

O formato do arquivo que você envia tem grande impacto na velocidade do upload e no tempo de pré-processamento. O ProcessMind oferece suporte a CSV, Parquet, ORC, Excel e XES. Para conjuntos de dados grandes, Parquet e ORC superam o CSV com ampla vantagem tanto no tamanho do arquivo quanto na velocidade de processamento.

Comparação de tamanhos de arquivo

Os arquivos Parquet são 85% menores que os CSV. Os arquivos ORC são 82% menores. Ambos são formatos colunares com compactação integrada, então nenhuma etapa extra é necessária. Sua ferramenta de ETL ou plataforma de dados, como Spark, Databricks, dbt ou BigQuery, provavelmente já oferece suporte à exportação para Parquet ou ORC.

Pré-processamento por formato

O tamanho do arquivo é apenas metade da história. Depois do upload, seus dados passam por ingestão e processamento analítico dependentes do formato, incluindo indexação de eventos e cálculos de transições e variantes. A etapa analítica predomina e é igual para todos os formatos. CSV.GZ é o único formato que acrescenta um tempo significativo, porque arquivos gzip não podem ser divididos para descompactação em paralelo.

O tempo de pré-processamento é praticamente idêntico para Parquet, ORC e CSV porque o processamento analítico predomina independentemente do formato de entrada. Já o pré-processamento de CSV.GZ piora significativamente em escala, passando de cerca de um minuto para 1 milhão de eventos a mais de 4 minutos para 100 milhões. Arquivos compactados com gzip não podem ser divididos e processados em paralelo, então a descompactação acrescenta uma etapa cada vez maior antes do início da análise.

O panorama completo

Considere o tempo de upload e o pré-processamento, e a escolha do formato ficará clara:

Em escala, Parquet e ORC são os vencedores claros porque seus arquivos são muito menores. O tempo de upload é o principal gargalo. O pré-processamento leva praticamente o mesmo tempo em todos os formatos, exceto no CSV.GZ, que sofre uma penalidade de descompactação cada vez maior.

Carregamento incremental: adicione dados sem fazer um novo upload

Depois que você carrega um conjunto de dados de referência, não precisa fazer um novo upload de tudo quando chegam dados novos. O ProcessMind oferece suporte ao carregamento incremental, ou uploads incrementais, para que você possa acrescentar novos eventos a um conjunto de dados existente.

Como funciona:

1. Faça o upload do conjunto de dados inicial, como os pedidos de compra do 1º trimestre de 2026, com 2,3 milhões de eventos
2. Quando os dados do 2º trimestre chegarem, envie apenas os eventos novos em um arquivo incremental, como 800 mil novos eventos
3. O ProcessMind mescla os arquivos automaticamente e faz o processamento novamente

O impacto na performance é significativo. Em vez de fazer um novo upload do conjunto de dados completo a cada atualização, você envia apenas o que é novo:

Depois de um upload incremental, o pré-processamento é executado novamente no conjunto de dados combinado, com o mesmo custo de 1–2,5 minutos. Mas você economiza todo o tempo de upload dos dados que já havia enviado.

O carregamento incremental é ideal para:

• Atualizações semanais ou mensais de dados: acrescente novas transações à medida que elas ficam disponíveis
• Monitoramento contínuo do processo: mantenha os Dashboards atualizados sem fazer uploads grandes
• Event Logs em crescimento: adicione novos eventos do ERP, CRM ou de outros sistemas de origem

Os arquivos incrementais devem usar o mesmo formato e a mesma estrutura de colunas do upload original. Consulte o guia de carregamento incremental de dados para saber mais.

Usando a API para uploads grandes ou automatizados

Para conjuntos de dados maiores que alguns gigabytes ou para uploads recorrentes, scripts e ferramentas de linha de comando são mais confiáveis do que uploads pelo navegador. Os navegadores podem atingir o tempo limite, consumir memória em excesso ou perder o progresso quando a rede é interrompida.

Por que a API funciona melhor para arquivos grandes:

• Transferências confiáveis. Se sua conexão cair, você poderá tentar novamente sem começar do zero.
• Sem limites de memória do navegador. Os navegadores têm dificuldade com arquivos de vários gigabytes. As ferramentas de linha de comando lidam com eles facilmente.
• Automação. Agende uploads noturnos, integre-os aos pipelines de ETL ou dispare uploads a partir de CI/CD.
• Monitoramento do progresso. Ferramentas como curl mostram o progresso da transferência em tempo real.
• Uploads incrementais. Acrescente novos dados de forma programática, seguindo um cronograma.

Exemplo usando curl:

# Upload a Parquet file directly using a presigned URL
curl -X PUT "$PRESIGNED_URL" --upload-file data.parquet

O ProcessMind fornece URLs pré-assinadas que autorizam uploads diretos para o armazenamento em nuvem. Nenhuma credencial além da sua chave de API é necessária. Você também pode copiar a URL de upload pré-assinada diretamente no menu de configurações do conjunto de dados na interface do ProcessMind.

Consulte a documentação da API para ver exemplos completos em Bash, JavaScript e Python, incluindo como obter URLs pré-assinadas, carregar arquivos delta e lidar programaticamente com conjuntos de dados grandes.

Velocidade de iteração do modelo

Quando você aprimora seu modelo de processo renomeando atividades, alterando mapeamentos ou adicionando agrupamentos, apenas os cálculos dependentes do modelo precisam ser atualizados. Os dados-base permanecem no lugar:

As alterações no modelo são rápidas porque a etapa inicial de carregamento dos dados, que cresce com o tamanho do conjunto, já foi concluída. Apenas a etapa de agregação dependente do modelo, incluindo mapeamentos de atividades, transições e variantes, é executada novamente. Para conjuntos de até 20 milhões de eventos, as alterações no modelo terminam em menos de 25 segundos. Mesmo com 100 milhões de eventos, elas levam menos de um minuto, muito mais rápido que o pré-processamento completo.

Tempos de resposta do Dashboard

Depois que seus dados são carregados, estes são os tempos de resposta que você experimenta durante a análise. Os tempos abaixo são medianas de várias execuções de benchmark. Cada componente do Dashboard faz consultas de forma independente e é carregado em paralelo:

Padrões para observar:

• Estatísticas, incluindo contagens e durações resumidas, permanecem em ~0,6 s independentemente do tamanho. Essas consultas são altamente otimizadas.
• Fluxo do processo, o diagrama do processo, aumenta conforme o tamanho do conjunto porque calcula as transições entre todas as atividades.
• Variantes e Categorias aumentam moderadamente. Os dados pré-agregados mantêm essas consultas rápidas.
• Navegador de dados continua rápido graças à paginação. Com filtros aplicados, o tempo cai para menos de 1 s.
• Animação varia conforme a quantidade de casos ativos visualizados.

A conclusão: nos tamanhos recomendados de 1–10 milhões de eventos, todos os componentes do Dashboard respondem em menos de 3,5 segundos. Mesmo com 50 milhões, a maioria das consultas retorna em 2–4 segundos com filtros aplicados. Apenas os fluxos de processo e as visualizações de categorias sem filtros, em conjuntos com mais de 50 milhões de eventos, chegam a 5–6 segundos.

Comece pequeno, cresça com segurança

Este é o conselho mais importante deste guia: não comece com seu maior conjunto de dados.

Os números falam por si:

A maioria das organizações considera que 1–5 milhões de eventos são mais do que suficientes para gerar insights acionáveis. O comportamento do processo se estabiliza bem antes de 10 milhões de eventos. Depois disso, você está principalmente adicionando duplicatas de padrões que já viu.

Se o seu arquivo Parquet com 1 milhão de eventos, de 34 MB, é carregado em 3 segundos e oferece o mesmo mapa de processo que 50 milhões de eventos, por que esperar 18 minutos?

Estratégia de dados: encontre o tamanho certo

Os números acima contam uma história clara: com 1–5 milhões de eventos, os uploads levam segundos, o pré-processamento leva menos de 2 minutos e os Dashboards respondem em 1–2,5 segundos. Com 50 milhões, você espera 20 minutos por um upload a 100 Mbps, e os Dashboards ficam mais lentos, respondendo em 3–6 segundos. A experiência é muito diferente.

Então, a pergunta real não é “qual é a velocidade da ferramenta?”. É “de quantos dados eu realmente preciso?”. A resposta quase sempre é: menos do que você imagina.

Segmente primeiro, agregue depois

Analise primeiro um país, um departamento ou uma linha de produtos.

Isso não é uma limitação. É uma questão de clareza. A análise segmentada produz insights mais precisos do que médias globais.

Por que a segmentação funciona:

• Os processos variam por região. As operações alemãs seguem cadeias de aprovação diferentes das operações dos Estados Unidos. As leis trabalhistas francesas criam Workflows de RH diferentes. Analisá-las em conjunto gera ruído.
• Stakeholders diferentes, prioridades diferentes. O VP da região EMEA se importa com a EMEA. Mostre a ele os dados da EMEA. A visão global pode vir depois.
• Iteração mais rápida. Os dados de um único país podem ter 500 mil eventos em vez de 10 milhões. Você itera em minutos, não em horas.
• Benchmark integrado. Depois de analisar a Alemanha, faça o mesmo com a França. Agora você pode comparar.

Exemplo: uma empresa europeia de logística com 42 milhões de eventos de remessas em 8 países:

• Analisar tudo: 42 milhões de eventos, 9,3 GB, 16 min de upload (100 Mbps), 2 min de pré-processamento
• Analisar apenas a Alemanha: 8,5 milhões de eventos, 1,9 GB, 3 min de upload, 1,5 min de pré-processamento
• Analisar apenas a Holanda: 3,1 milhões de eventos, 690 MB, 1 min de upload, 1 min de pré-processamento
• Usar o carregamento incremental: fazer o upload da Alemanha primeiro e acrescentar a Holanda quando estiver pronta

Exclua o caminho feliz

Exclua o caminho feliz antes de fazer o upload. Essa técnica pode reduzir os conjuntos de dados em 90–95%.

A maioria dos processos de negócio segue a regra 80/20. A grande maioria dos casos percorre o caminho padrão e bem-sucedido. Se você está procurando exceções, violações de conformidade ou desvios de processo, não precisa desses dados.

Exemplo: um processo de compras a pagamentos com 1,2 milhão de pedidos de compra (8,4 milhões de eventos):

• 1,1 milhão de pedidos (92%) seguem o caminho ideal: Criar PO → Aprovar → Recebimento de mercadorias → Fatura → Pagamento
• 96.000 pedidos (8%) têm exceções: rejeições, devoluções, faturas duplicadas e aprovações ausentes

Se você está analisando problemas de conformidade, exporte apenas os casos de exceção. Isso representa uma redução de 92%, de 8,4 milhões de eventos (1,9 GB) para 670 mil eventos (150 MB). O tempo de upload cai de 3 minutos para 15 segundos a 100 Mbps. Exporte em Parquet (15 MB) e você poderá fazer o upload em menos de 2 segundos.

Seleção de colunas: menos é mais

Cada coluna exportada consome largura de banda, armazenamento e tempo de processamento. Escolher as colunas com cuidado é uma das otimizações de maior impacto que você pode fazer.

O que deixar de fora:

• Campos de texto longos. Descrições de pedidos, comentários, observações e campos de texto livre. Um campo de descrição com 500 caracteres em 5 milhões de eventos acrescenta 2,5 GB ao arquivo.
• PII (informações de identificação pessoal). Nomes, endereços de e-mail e números de telefone. Remover PII reduz o tamanho do arquivo, elimina riscos de privacidade e simplifica a conformidade.
• Identificadores redundantes. Se você tem OrderId, não precisa de OrderGUID, OrderReference ou LegacyOrderNumber.
• Colunas de auditoria. CreatedBy, ModifiedBy, CreatedDate e ModifiedDate. A menos que você esteja analisando esses campos especificamente, deixe-os de fora.
• Colunas do sistema. Sinalizadores internos, chaves de partição e metadados técnicos.

Exemplo: uma exportação do SAP com 1,8 milhão de eventos de pedidos de compra e 45 colunas foi reduzida a 12 colunas essenciais:

• Tamanho do arquivo: 2,1 GB → 380 MB (redução de 82%)
• Como Parquet: 380 MB → 58 MB (mais 85% de redução)
• Tempo de upload (100 Mbps): 3,5 min → 6 segundos
• Mesmo valor analítico

As colunas que importam: CaseId, Activity, Timestamp e alguns atributos de negócio, como status, valor, categoria e região. Todo o restante provavelmente é ruído.

Quando a escala importa

Algumas perguntas analíticas realmente exigem conjuntos de dados grandes. Entender quando isso acontece ajuda você a tomar a decisão certa:

• Detecção de eventos raros. Encontrar casos extremos que ocorrem 1 vez a cada 100.000 exige uma população grande o suficiente para conter amostras relevantes. Se você precisa analisar 50 ocorrências de uma exceção rara e ela ocorre em 0,01% dos casos, precisa de 500 mil casos.
• Medição de caminhos pouco frequentes. Variantes de processo que ocorrem em 0,1% dos casos podem ficar invisíveis em uma amostra de 1 milhão de eventos, mas ser significativas em uma população de 50 milhões.
• Conformidade e auditoria. Algumas regulamentações exigem cobertura completa da população. A amostragem não é aceitável.
• Análise de tendências de vários anos. Comparar o 1º trimestre de 2024 com o 1º trimestre de 2025 e o 1º trimestre de 2026 exige dados que cubram os três períodos. Use o carregamento incremental para criar esse histórico aos poucos.

Se você precisa de mais de 50 milhões de eventos, planeje-se: use o formato Parquet, que reduz um CSV de 11 GB para 1,7 GB e acelera o pré-processamento; use a API para transferências confiáveis; e use uma conexão de rede rápida, se disponível. Depois desse primeiro carregamento, os Dashboards continuam rápidos.

Mantendo o modelo e a interface rápidos

As seções acima tratam do volume de dados. A outra metade da capacidade de resposta vem da forma como o modelo e os Dashboards são construídos:

• Simplifique o modelo. Divida processos grandes em subprocessos modulares; uma tela com mil elementos visíveis demora para renderizar e é impossível de ler. Execute o layout automático depois de mudanças estruturais.
• Seja seletivo com os Dashboards. Cada gráfico e bloco precisa ser calculado. Mantenha os gráficos que geram alguma ação e mova o restante para um Dashboard próprio, em vez de empilhar tudo em uma única visualização.
• Combine o gráfico com o conjunto de dados. Em conjuntos de dados grandes, evite visualizações que exigem mais processamento, como gráficos de pizza detalhados e divisões com muitas categorias, priorizando gráficos que resumem as informações.
• Aplique filtros com moderação. Filtros são baratos individualmente e caros em conjunto. Mantenha o conjunto que responde à sua pergunta e remova-o depois.
• Observe a animação. O custo da animação aumenta com o número de casos ativos. Reduza a velocidade ou desative rastros e efeitos quando você precisar apenas do fluxo. Consulte Animação do processo.
• Arquive e revisite. Retire conjuntos de dados e processos antigos do espaço de trabalho ativo e use a simulação com as métricas de tempo para encontrar os gargalos que vale a pena corrigir, em vez de otimizar tudo de uma vez.

Próximos passos

A melhor maneira de entender a performance do Process Mining é vivenciá-la com seus próprios dados.

1. Comece com uma amostra. Exporte 1 milhão de eventos de um período recente no formato Parquet. Faça o upload. Crie seu primeiro modelo. Veja como você consegue iterar rapidamente.

2. Aplique as técnicas deste guia. Use formatos colunares. Filtre as exceções. Segmente por região. Remova colunas desnecessárias. Cada otimização aproveita a anterior.

3. Escale de forma planejada. Depois de entender seu processo com 1 milhão de eventos, decida se precisa de mais dados. Na maioria dos casos, não precisa. Quando precisar, use o delta loading para adicionar dados em vez de fazer o upload novamente.

Comece um teste grátis e veja esses benchmarks em ação. Para obter ajuda dimensionando seu conjunto de dados ou otimizando suas exportações, fale conosco. Já ajudamos centenas de organizações a encontrar o equilíbrio certo entre volume de dados e velocidade de análise.