process-mining
2021.10
true
Wichtig :
Bitte beachten Sie, dass dieser Inhalt teilweise mithilfe von maschineller Übersetzung lokalisiert wurde.
UiPath logo, featuring letters U and I in white
Process Mining
Automation CloudAutomation Cloud Public SectorAutomation SuiteStandalone
Last updated 2. Sep. 2024

Verwenden Sie Sharding in Ihren Anwendungen

Einleitung

Sharding ist eine innovative Lösung zur Verbesserung der Leistung Ihrer Process Mining-Anwendungen. Kurz gesagt, Sharding unterteilt die Daten in Ihrem Ereignisprotokoll in kleinere Teile, die als „Shards“ bezeichnet werden. Je kleiner jeder Shard ist, desto schneller ist er.

Bei einem Shard berücksichtigen Endbenutzer nur den entsprechenden Teil der Daten, an dem sie interessiert sind. Wenn sich ein Benutzer bei der Anwendung anmeldet, wird nur der entsprechende Daten-Shard geladen.

Shard-Typen

Shards können in zwei verschiedene Typen unterteilt werden:

  • Reguläre Shards, die Teile Ihrer Daten auf Detailebene enthalten.
  • Benchmark-Shards, die eine aggregierte, allgemeine Ansicht aller Ihrer Daten enthalten.

Es gibt mehrere Techniken zum Erstellen von regulären Shards sowie für Benchmark-Shards. Regelmäßige Shards können erstellt werden, indem Sie Ihre Daten basierend auf Fallattributen aufteilen. Benchmark-Shards kombinieren die Daten aller Shards. In der Regel wird die Detailebene der Daten durch Voraggregation, Filterung oder Stichprobenziehung reduziert.

Reguläre Shards

Ein Beispielattribut für das Sharding könnte „Unternehmenscode“ sein, wobei jeder Shard alle Fälle enthält, die zu einem einzelnen Buchungskreis gehören. Wenn Sie 10 Buchungskreise in Ihrem Dataset haben, ist jeder Shard ungefähr 10-mal schneller als das Original (unter der Annahme gleicher Aufteilungen).

Siehe Abbildung unten.



Benchmark-Shards

Neben der Aufteilung Ihrer Daten in separate Shards ist es nützlich, einen Übersichts-Shard zu haben, der eine übergeordnete Ansicht aller Daten enthält, einen „Benchmark-Shard“.

Sie können dies auf verschiedene Arten einrichten:

  • Durch Voraggregieren von Werten oder Attributen: Dadurch können Sie keine detaillierte Analyse durchführen, können aber dennoch Unterschiede über Shards vergleichen.
  • Durch Verringern der Detailebene durch Herausfiltern feinkörniger Ereignisse: Dies ermöglicht es Ihnen, Prozesse auf einer groben Ebene zu vergleichen.
  • Durch Filtern: Sie können alle Ereignisdaten entfernen und nur Tags und die jeweiligen Fälle behalten. Auf diese Weise können Sie Tags über mehrere Shards hinweg vergleichen.
  • Durch Stichproben: Sie können Stichproben von Fällen in Ihrem Dataset erstellen, um nur einen Teil der Fälle zu behalten und eine repräsentative Stichprobe von Fällen als Benchmark-Dataset zu behalten.

Sie können auch mehrere Benchmark-Shards mit verschiedenen Methoden einrichten.

Einrichten Ihres Connectors

Regulärer Shard

Sie können einen einzelnen Connector für Ihre ETL verwenden, auch wenn Sie Sharding verwenden. Dazu richten Sie Anwendungsmodule ein und verwenden ein Modul pro Shard, das Sie erstellen möchten.

Fügen Sie in Ihrem Connector eine Systemtabelle hinzu, deren Tabellenbereich auf „aktueller Benutzer“ festgelegt ist, um den ActiveApplicationCode abzurufen, der das derzeit aktive Modul angibt. Sie können dieses Attribut aus der Systemtabelle verwenden, um Bedingungen für das Laden von Daten zu erstellen.

Beispiel

Wenn Sie Sharding mithilfe von Falltypen anwenden, richten Sie einen Ausdruck Case_Type_Shard basierend auf dem ActiveApplicationCode- Attribut ein, um zu bestimmen, welcher Falltyp zu welchem Anwendungscode gehört. Dann legen Sie in der Tabelle „ cases_base “ die Join-Bedingung fest auf:

Cases_preprocessing where Case_type_Shard = Case_type

Dadurch wird sichergestellt, dass nur die Fälle mit einem Falltyp, der zum aktuellen Shard gehört, in Ihrer endgültigen Ausgabe übergeben werden.

Sie müssen auch sicherstellen, dass nur Ereignisse, die zu Fällen im aktuellen Shard gehören, in der Ausgabe enthalten sind. Erstellen Sie daher in der Tabelle events_preprocessing einen Nachschlageausdruck für die Tabelle cases_base , der überprüft, ob sich Fälle im ausgewählten Shard befinden.

Siehe Abbildung unten.



Verwenden Sie dieses Ausdrucksattribut in der Join-Bedingung der Tabelle events_base mit dem Ausdruck:

Events_preprocessing where Case_in_shard.

Benchmark-Shard

Der Benchmark-Shard wird auch mit dem Attribut ActiveApplicationCode eingerichtet. Die Filterung hängt davon ab, welche Art von Benchmark-Shard Sie verwenden möchten, und ähnelt dem, was oben für die regulären Shards beschrieben wurde.

Einrichten Ihrer Anwendung

Um Ihre Anwendung für das Sharding einzurichten, benötigen Sie auch ein Modul pro Shard. Diese Module müssen dieselben Modulcodes wie die in Ihrem Connector haben.

Darüber hinaus kann sich die Datenstruktur für die regulären Shards und die Benchmark-Shards unterscheiden, je nachdem, welchen Benchmark-Shard Sie verwenden. In diesem Fall benötigen Sie eine separate Anwendung für den Benchmark-Shard.

Neuladen Ihrer Daten

Da Sie mehrere Module verwenden, müssen Sie die Daten mit einem Skript neu laden, um sicherzustellen, dass die Daten aller Connector-Module im selben Dataset landen. So weiß die Anwendung basierend auf dem geöffneten Modul, welcher Teil der Daten berücksichtigt werden soll. Das Skript zum Neuladen Ihrer Daten finden Sie unter Einrichten von automatisierten Datenaktualisierungen .

War diese Seite hilfreich?

Hilfe erhalten
RPA lernen – Automatisierungskurse
UiPath Community-Forum
Uipath Logo White
Vertrauen und Sicherheit
© 2005–2024 UiPath. Alle Rechte vorbehalten