データのボリューム

はじめに

データの量は、常にパフォーマンスと直接のトレードオフになります。 プロセス マイニングは、プロセス グラフを構築するための詳細に元々こだわりがあります。

ただし、これらの一意のタイムスタンプがすべて設定されている場合は、パフォーマンスに影響します。 一般に、すべてのプロセス マイニング ツールとすべてのインメモリ ツールアプローチの理論上の制限があります。

ユーザーの種類

アプリケーションとコネクタに使用されるデータのパフォーマンスは明確に区別されます。同じプラットフォームを利用しますが、ユーザーにとって許容できるもの (開発者とエンド ユーザー) と、実行されるアクションの種類など、いくつかの違いがあります。

大量のデータは コネクタ と アプリケーションの両方に影響を与える可能性がありますが、 すべてコネクタで解決できます。

データのボリューム

パフォーマンスのエンドユーザーが経験するパフォーマンスは、データ ボリュームに直接関連します。 データ ボリュームは、最大のテーブルの行数によって決定されます。 一般に、パフォーマンスのエンドユーザー のユーザー エクスペリエンスを決めるのは、行の数のみです。 列の数は、データベースからデータを読み込むときにのみ増加します。

プロセスあたりのイベント数は約 5,000,000 件 (500 万件)、最大で約 50,000,000 件 (5000 万件) のイベントが理想的です。 ケースやイベントの数が増えると、データの解析やビジュアリゼーションの表示に時間がかかるようになります。

UiPath Process Mining プラットフォームは引き続き機能しますが、大量のデータの挿入時に応答速度が低下する可能性があります。事前にデータ量を確認することをお勧めします。上記の数を超える場合は、データセットの最適化または制限を検討することをお勧めします。

詳細レベル

詳細度が上がるほど応答時間が伸び、パフォーマンスが影響を受けます。

データ量、詳細レベル、待機時間の正確なトレードオフをエンドユーザーと話し合う必要があります。 履歴データが非常に重要なこともありますが、多くの場合、最後の数年間しか必要ない場合があります。

もう一つの要因は、列にある一意の値です。UiPath Process Mining は、独自の方法を使用して *.mvn ファイルのサイズを最小限に抑えます。これは、類似する値に対して適切に機能します。属性に一意の値が多数あると、パフォーマンスにも影響します。予定の詳細。

Solutions (ソリューション)

データ量が大きい場合は、主に以下の 2 つの方法で対処する必要があります。

• 最適化;
• データの最小化

最適化では、Superadmin による調整を行うことで、ダッシュボードの表示を高速化できます。その実現には、アプリケーションの設定を特定のデータセットに合わせて調整します (詳細については、「アプリケーションの設計」をご覧ください)。

このセクションでは、データの最小化について説明します。データを最小化する場合は、エンド ユーザーに表示されるデータを、特定の業務の質問に合わせて調整して減らすことができます。

ここで説明する手法は互いに並んで存在することも、複数の技術のメリットを活用するために組み合わせることもできます。 さらに、最小化されたアプリケーションとともに、データを最小化せずにアプリケーションを維持することもできます。より遅いパフォーマンスを許容できる特定の分析では詳細レベルが必要になる場合があるからです。

データ のスコーピング

ツアー データセットに表示されるレコードの数を制限すると、アプリケーションのパフォーマンスが向上するだけでなく、プロセスの理解度も向上し、ビジネスでの承認性も向上します。

データのスコープは コネクタで実行できます。

制限のオプションの 1 つとして、日付や期間をフィルター処理して表示する期間を制限します。 たとえば、10 年間から 1 年間の期間を制限できます。 または 1 年から 1 か月。 以下の画像に例を示します。

特にプロセス マイニングへの取り組みの開始時には、限られた量のアクティビティをお勧めします。 そのため、専門知識の強化にさらに着手できます。

以下に、アクティビティの範囲に関するガイドラインを示します。

範囲 (アクティビティの値)	説明
5-20	Process Mining の使用を開始する場合に推奨される範囲です。洞察情報を提供するためのシンプルなプロセス。
20-50	エキスパートレンジ クリアバリアントで展開する。
50-100	明確なバリアントがある場合に最も便利です。 これは、やや関連するプロセスを意味しますが、主に独自のプロセスです。
100+	サブプロセスに分割することをお勧めします。

注:

アクティビティをフィルターで除外すると、プロセスが簡素化され、より分かりやすくなります。また、情報や詳細が失われる可能性があることに注意してください。

以下に、データのフィルター処理に関する提案をいくつか示します。

• 関係のないアクティビティ: プロセスに直接影響を与えないアクティビティは、除外される可能性があります。
• 第 2 のアクティビティ: いくつかのアクティビティ、つまり変更アクティビティは、プロセスのどこでも実行できます。 これらは大幅に多数のバリアントに吹き飛ばしました。
• 最小限に発生するイベント: データセット内で数回発生するイベントは、フィルター処理されて除外される可能性があります。
• 小規模なプロセス: サブプロセスのみを分析します。
• グループ化アクティビティ: データセット内の一部のアクティビティは、ビジネスにより理にかなっているアクティビティを表す、小さなタスクのようになることがあります。 グループ化するには、コネクタ内にロジックが必要であり、重複するアクティビティが生じる可能性があります。
• 可能であれば、 コネクタのパフォーマンスの範囲内で、 コネクタ を使用してアクティビティをフィルター処理します。これにより、変更を簡単に元に戻したり、アクティビティを再度追加したりできます。データ抽出やデータの読み込み時にアクティビティをフィルター処理して除外することは避けてください。

外れ値を削除する

多数のイベント (外れ値) を持つケースが 1 つある場合は、イベント レベルで集計を計算する一部の式に影響します。[始点/終点] ダッシュボードの項目フィルターもこの影響を受け、これらの外れ値があるかどうかを計算するのに時間がかかる可能性があります。コネクタでこれらのケースをフィルター処理して除外し、データセットから除外することをお勧めします。

注:

これはメトリックに影響します。外れ値は、ビジネス ユーザーに応じてのみ削除してください。

外れ値への焦点

他のインスタンスでは、外れ値がフォーカスする主要な領域である可能性があります。 プロセスが順調に進んでいる場合、または Six Sigma の方法論を採用している場合は、問題に集中したいと考えています。 すべてのケースが正しく表示されるのではなく、問題が起こっているケースのみが表示されます。

以下の画像でご確認ください。

データセットのサイズを小さくする

コネクタでは、多くの詳細を含む属性を削除できます。たとえば、 Event Detail 属性の長い文字列です。

開発が完了すると、未使用の属性が大量にデータセットに含まれる可能性があります。コネクタの出力データセットで使用される属性の利用可否をパブリックに設定することをお勧めします。他の属性の使用可否を private に設定します。

事前集約

事前集約は、多くの BI ツールで使用され、大量のデータに関する洞察を得るために使用される手法です。 データセット内のレコード数を減らすために、特定の属性に対するデータを集約する必要があります。 BIでは、これは通常、各サプライヤーの値を合計するものなので、各サプライヤーに 1 つのレコードしかありません。

以下の画像でご確認ください。

プロセス マイニングではより多くの設定が必要ですが、最初に必要なのはプロセス バリアントの集約のみです。 各バリアントには、1 つのケース レコードと、関連する数のイベントがあります。 これにより、データ量を大幅に減らすことができます。

正しい結果を表示するには、各バリアントが表すレコードの数も表示する必要があります。イベント終了の場合は、各イベントの中央値の期間を使用できます。 バリアントのみを使用して一結び付けるのは高すぎる可能性があるため、最も一般的なフィルター (バリアント、ケースの種類、ケース終了の月の組み合わせなど) を確認する必要があります (経時的な傾向を示す場合)。

ただし、属性を追加するとレコードの数に対して的な影響があるため、パフォーマンスとユース ケースが慎重にバランスする必要があります。

事前集約は、プロセスの概要とs 一般的なトレンドに最も適用されます。

サンプリング

サンプリングとは、特定の期間内に発生しているケースとそのイベントの割合を取る手法です。 たとえば、すべてのケースとそのイベントの 10% のみが表示されるように設定できます。 この方法では、各ケースがデータセットに表示される可能性が同様に高いため、例外や外れ値が引き続き発生します。

以下の画像でご確認ください。

カスケードサンプリング

カスケードサンプリングとは、サンプリング率が一定の割合で経時的に低下する手法です。 たとえば、過去 1 週間のデータの 100% の場合、2 週間前の 90%、3 週間前の 80% などを示します。

データのシャーディング

データ のシャーディングは、データをスコーピングするソリューションの手法です。組織は、単に 1 つの部分をスライスするのではなく、データを複数のデータセットに分割できます。 アプリケーションをモジュールを使用して分割し、複数の小さなデータセットをコネクタからエクスポートする必要があるため、この設定には追加の設定が必要です。

データのシャーディングでは、元のデータセットは複数のシャードに分けられます。 各シャードが小さいほど、速度は上がります。 ユーザーがアプリケーションにログインすると、該当するデータ シャードだけが読み込まれます。

シャーディングの一般的な単位は 、「会社コード」 または 「部門」です。たとえば、50 個の会社コードの場合、各シャードには 1 つの会社コードが含まれ、基本的に元のデータセットの約 50 倍の速度になります。

シャーディングの概要は、以下の画像でご確認ください。