Data Loading

Introdução

Carregamento de dados no conector

O carregamento de dados refere-se ao tempo necessário para carregar novos dados no Conector. Isso é determinado pelo número de colunas ao ler do banco de dados.

Alguns tipos de dados são mais rápidos de carregar do que outros. Em um sentido amplo, a ordem é a seguinte.

1. ODBC: também depende do driver e do banco de dados.
2. Arquivos simples: csv’s.
3. Excel: esses arquivos contêm sobrecarga para uso no Excel, o que os torna mais lentos para ler. Se possível, use arquivos de texto em vez de arquivos do Excel. Os arquivos de texto são muito mais rápidos.

O script de vários arquivos é bastante lento para analisar todos os diferentes arquivos simples juntos e deve ser evitado, se possível. Evite também APIs para carregar grandes quantidades de dados.

 

Carregamento de dados no aplicativo

Os dados podem ser carregados das seguintes maneiras:

• quando o aplicativo é iniciado (dados ativos);
• como resultado de uma execução de dados agendada (dados em cache);
• uma combinação de dados ao vivo e em cache (carga incremental).

Dados ao vivo

Em geral, os dados ao vivo são muito mais lentos, especialmente se houver muitos dados. Os dados ao vivo também precisam de acesso contínuo aos dados, o que pode ser um problema durante o horário de produção.

Como diretriz geral, é recomendável manter os dados ativos abaixo de 100.000 eventos. O desempenho real depende muito dos dados e das fontes de dados usadas.

É possível recuperar dados ativos com base no valor de um filtro. Se o filtro for alterado, os novos dados são solicitados. O desempenho deve ser seriamente considerado para esses tipos de casos de uso.

As tabelas ativas são carregadas quando o usuário efetua login e/ou altera um controle de filtro. Tabelas ao vivo geralmente levam a problemas de desempenho. É recomendável usar tabelas em cache sempre que possível.

Dados em cache

Para dados em cache, o tempo de inicialização do aplicativo é independente do número de colunas. Quando os dados são pré-calculados e armazenados em cache, eles podem ser carregados diretamente do cache quando solicitados. Extrair dados de sistemas de origem pode ser demorado. Recomenda-se agendar as atualizações do cache, por exemplo, fora do horário de produção.

Além da extração de dados, os dados também são transformados para o formato interno do UiPath Process Mining e todos os cálculos que não dependem da entrada do usuário são armazenados em cache.

Para cálculos que dependem da entrada do usuário, o estado inicial é armazenado em cache. Quando o usuário altera um controle ou filtro que altera o cálculo, o cálculo é executado novamente. Manter esses recálculos no mínimo é muito importante para um bom design de aplicativo.

Carga Incremental

Por padrão, o UiPath Process Mining não carrega dados de forma incremental. Como as mutações geralmente ocorrem nos itens dos sistemas ERP, o arquivamento dos dados geralmente não é uma abordagem desejada. Portanto, todos os dados são carregados do sistema para garantir que tenhamos as alterações mais recentes em nosso modelo de dados.

Carregamento de dados incremental teoricamente pode ser configurado por desenvolvedores de aplicativos. Isso requer informações suficientes no banco de dados para determinar quais dados são novos e quais precisam ser consultas. O desempenho precisa ser considerado com cuidado. Recomendamos apenas o uso de carregamento de dados incremental quando isso for absolutamente necessário.

Uma alternativa mais adequada é executar cargas incrementais do sistema de origem em um data lake/warehouse usando ferramentas especializadas e, em seguida, consultar o data lake/warehouse a partir do UiPath Process Mining. Isso garante um baixo impacto no sistema de origem e compartilha os ganhos de cargas incrementais com toda a organização, em vez de especialmente para UiPath Process Mining.

Scripts Externos

No UiPath Process Mining, você pode carregar dados por meio de scripts usando ou exemplo Python ou R. Esses scripts chamarão um programa externo para execução e essa saída poderá ser lida novamente. O UiPath Process Mining fornece o suporte na interface entre nossa plataforma e o script. O UiPath Process Mining não oferece suporte a problemas com o script real, o que pode causar um longo tempo de execução da ferramenta externa.

 

Soluções

Drivers

Certifique-se sempre de ter instalado as versões mais recentes dos drivers MSSQL ODBC para Windows Server 2016.

Módulo de depuração

Às vezes não é possível reduzir os dados a serem lidos, por exemplo. quando os dados de entrada ainda não podem ser filtrados. Com uma grande entrada em seu conector, os tempos de reação podem ser lentos. Para acelerar o desenvolvimento, você pode adicionar módulos ao seu aplicativo.

Você pode usar o código do módulo para garantir que apenas em um módulo os dados sejam realmente lidos, enquanto o outro módulo não carrega dados e pode ser usado para fazer alterações em seu modelo de dados. Dessa forma, as alterações são afetadas sem a necessidade de aguardar a inicialização dos dados.