Process Mining
2021.10
False
Image de fond de la bannière
Process Mining
Dernière mise à jour 2 avr. 2024

Utilisez la partitionnement dans vos applications

Introduction

Sharding est une solution innovante pour améliorer les performances de vos applications de Process Mining. En bref, le sharding divise les données de votre journal des événements en parties plus petites appelées « fragments ». Plus chaque partition est petite, plus elle sera rapide.

Avec une partition, les utilisateurs finaux ne prennent en compte que la partie applicable des données qui les intéressent. Lorsqu'un utilisateur se connecte à l'application, seule la partition de données applicable est chargée.

Types de partitions

Les fragments peuvent être divisés en deux types différents :

  • Partitions standard, qui contiennent des parties de vos données au niveau détaillé.
  • Partitions de référence (Benchmark shards) , qui contiennent une vue agrégée de haut niveau de toutes vos données.

Il existe plusieurs techniques pour créer des partitions normales ainsi que des partitions de référence. Des partitions standard peuvent être créées en divisant vos données en fonction des attributs de cas. Les partitions de référence combinent les données de toutes les partitions. En règle générale, le niveau de détail des données est réduit à l'aide de la pré-agrégation, du filtrage ou de l'échantillonnage.

Partitions normales

Un exemple d'attribut de partitionnement pourrait être Code de l'entreprise, où chaque partition contient tous les cas appartenant à un seul code d'entreprise. Si vous deviez avoir 10 sociétés dans votre ensemble de données, chaque partition sera alors environ 10 fois plus rapide que l'originale (en supposant des fractionnements égaux).

Voir illustration ci-dessous.



Partitions de référence

En plus de diviser vos données en partitions distinctes, il est utile d'avoir une partition de vue d'ensemble contenant une vue de niveau supérieur de toutes les données, une « partition de référence ».

Vous pouvez configurer cela de plusieurs manières :

  • En pré-agrégeant des valeurs ou des attributs : cela vous empêche de faire une analyse détaillée, mais vous permet toujours de comparer les différences entre les partitions.
  • En abaissant le niveau de détail en filtrant les événements à granularité fine : cela vous permet de comparer les processus à un niveau grossier.
  • Par filtrage : vous pouvez supprimer toutes les données d'événement et ne conserver que les balises et les cas respectifs. Vous pouvez ainsi comparer les balises sur plusieurs partitions.
  • Par échantillonnage : vous pouvez échantillonner des observations dans votre ensemble de données pour n'en conserver qu'une partie, en conservant un échantillon représentatif d'observations comme ensemble de données de référence.

Vous pouvez également configurer plusieurs partitions de référence à l'aide de différentes méthodes.

Configurer votre connecteur

Partition normale

Vous pouvez utiliser un seul connecteur pour votre ETL, même lorsque vous utilisez le sharding. Pour ce faire, configurez des modules d'application, en utilisant un module par partition que vous souhaitez créer.

Dans votre connecteur, ajoutez une table système avec une étendue de table définie sur « current user » pour obtenir ActiveApplicationCode, qui indique le module actuellement actif. Vous pouvez utiliser cet attribut de la table système pour créer des conditions pour le chargement de vos données.

Exemple

Lors de l'application de la partitionnement à l'aide de types de cas, configurez une expression Type_Case_Shard en fonction de l'attribut ActiveApplicationCode , pour déterminer quel type de cas appartient à quel code d'application. Ensuite, dans la table case_base , vous définissez la condition de jointure sur :

Cases_preprocessing where Case_type_Shard = Case_type

Cela garantit que seuls les cas qui ont un type de cas appartenant à la partition actuelle sont transmis dans votre sortie finale.

Vous devez également vous assurer que seuls les événements appartenant aux incidents de la partition actuelle se trouvent dans la sortie. Par conséquent, dans la table events_preprocessing , créez une expression de recherche vers la table cases_base qui vérifie si les incidents se trouvent dans la partition sélectionnée.

Voir illustration ci-dessous.



Utilisez cet attribut d'expression dans la condition de jointure de la table events_base avec l'expression :

Events_preprocessing where Case_in_shard.

Partition de référence

La partition de référence est également configurée à l'aide de l'attribut ActiveApplicationCode . Le filtrage dépend du type de partition de référence que vous souhaitez utiliser et est similaire à ce qui est décrit ci-dessus pour les partitions standard.

Configuration de votre application

Pour configurer votre application pour le sharding, vous avez également besoin d'un module par partition. Ces modules doivent avoir les mêmes codes de module que ceux de votre connecteur.

En outre, selon le type de partition de référence que vous utilisez, la structure des données peut être différente pour les partitions standard et la partition de référence. Si tel est le cas, vous avez besoin d'une application distincte pour la partition de référence.

Rechargement de vos données

Étant donné que vous utilisez plusieurs modules, vous devez recharger les données à l'aide d'un script pour vous assurer que les données de tous les modules de connecteur se retrouvent dans le même ensemble de données. De cette façon, l'application sait, en fonction du module ouvert, quelle partie des données doit être prise en compte. Voir Configurer l'actualisation automatisée des données pour le script de rechargement de vos données.

Cette page vous a-t-elle été utile ?

Obtenez l'aide dont vous avez besoin
Formation RPA - Cours d'automatisation
Forum de la communauté UiPath
Logo Uipath blanc
Confiance et sécurité
© 2005-2024 UiPath. All rights reserved.