パフォーマンス特性

Process Mining アプリの応答時間は、さまざまな要因によって決まりますが、一般的には次の原則が成り立ちます。

• データが少ないほど実行速度が速い

Process Mining には、異なるパフォーマンス特性を持つ 2 つの領域があります。データを読み込むためのデータ実行と、データを表示するためのダッシュボードです。

開発データと運用データ

Process Mining では、プロセス アプリごとに開発ステージとパブリッシュ済みステージがあります。目的のアプリで大規模なデータセットが必要な場合は、データ変換とダッシュボードの開発に、小規模なデータセット (レコード件数が 1,000 万未満) を使用することをお勧めします。

開発データセットは、データ変換のテストに使用されます。パブリッシュ済みのプロセス アプリのダッシュボードに表示されるデータには影響しません。 ビジネス ユーザーがアプリを使用する準備が整ったら、アプリをパブリッシュして、パブリッシュ済みのプロセス アプリで使用する新しいデータを取り込むことができます。

一般的なシナリオは、開発に短い時間枠のデータセットを使用することです (たとえば、2 週間の時間枠で 100,000 個のイベントのみ)。パブリッシュ時には、より大きなデータセット (12 か月分など) を使用できます。

データ実行のパフォーマンス

Process Mining のデータ実行は、以下のユース ケースでトリガーされます。

• アプリの作成

• データをアップロードする

• データ変換エディターで [ダッシュボードに適用]、[すべてのテストを実行]、または [ファイルを実行] をトリガーする

• データ変換に変更があるアプリをパブリッシュする

データ実行は通常、以下の手順から成り、各手順にはそれぞれ異なるパフォーマンス特性があります。

1. データをアップロードする

データをアップロードする場合、ディスクにアップロードされたデータの全体的なサイズが速度にとって最も重要な要因です。詳しくは、「データを読み込む」をご覧ください。パフォーマンスに影響する要因は次のとおりです。

• テーブルの数

• テーブル内のレコードの数

• テーブル内の列数

• テーブル内のデータ。たとえば、複数行の説明が格納されている列は、単純な Boolean 列よりも低速です。

2. データを変換する

データ変換により、入力データを、ダッシュボードに必要なデータ モデルに変更します。詳しくは、「データ変換」をご覧ください。

変換内の各 .sql ファイルは、追加の SQL クエリを実行します。データ変換の速度に影響する要因は次のとおりです。

• .sql ファイルの数

• 各テーブルのレコードの数

• 各テーブルの列数

• SQL クエリの複雑さ: 結合条件、共通テーブル式 (Common Table Expressions、CTE) の数、SQL クエリの式

3. データモデル

データ モデルによって、ダッシュボードに公開されるテーブルのセットが決まります。データ実行中にテストが実行され、データ モデル内のこれらのテーブルの構造が検証されます。ただし、最も時間のかかる部分は、後でダッシュボードの表示を高速化するために行われる事前計算です。

この手順の全体的な速度は、次の要素によって決まります。

• データ モデル内のテーブルの数

• 出力テーブル間の関係

• 出力テーブルの列数

• 出力テーブルのレコード数

4. プロセス モデル

データ実行の最後の部分では、プロセス グラフを高速化するための事前計算を実行します。

• バリアントの数

• イベントの数

[BPMN モデルをインポート] を使用してプロセスを表示する場合は、BPMN モデルの複雑さもパフォーマンスに影響します。アクティビティとエッジが多いほど、計算は遅くなります。

データ実行のパフォーマンスを向上させる方法

データの量を減らす

データのアップロード速度を向上させるには、データのサイズを必要最小限に抑えます。このアドバイスは、データのすべてのステージに適用されます。

• 必要な入力データのみを抽出する

• 必要なデータのみを変換する

• データ モデルにテーブルを追加するのは、データ分析に必要な場合だけにする

このための最も簡単な方法は、通常、データ抽出に使用する期間を短くすることです。これにより、入力から変換、出力までの過程で、ほとんどのデータ テーブルのレコード数が減ります。

早い段階でデータのサイズを縮小できるほど、効率が向上します。

• sql ファイルをフィルター処理する。データ変換のできるだけ早い段階か、可能であればデータ抽出時に行います。

• 開発には通常、よりサイズの小さいデータセットを使用する。クエリのテストを高速化するには、「開発データと運用データ」をご覧ください。

データ テーブルと列の数を減らす

さらに、実際に使用する列のみを読み込むように注意します。プロセスの早い段階で列を除外するほど、効率が向上します。

• 抽出する一連のデータ列を減らし、必要なものだけにする

• 出力データ モデルに必要のない .sql ファイルを削除する

• クエリ内の不要なデータ列を削除する

• 一連のイベントから不要なアクティビティを削除する

複雑さを軽減する

データ変換の計算とデータ モデルが複雑になるほど、データ実行は遅くなります。複雑さを軽減することは困難な場合がありますが、データ実行の時間に大きな影響を及ぼすことができます。

• 可能であれば SQL ステートメントの複雑さを軽減する。「SQL を記述するためのヒント」を参照してください。

• データ モデル内のデータを減らし、データ分析に必要なデータだけにする。データ分析に必要のないテーブルや列はすべて削除することをお勧めします。

• [BPMN モデルをインポート] を使用してプロセスを表示する場合は、アクティビティとエッジの数を少なくする。これにより、パフォーマンスが向上します。

ダッシュボードのパフォーマンス

一般に、ダッシュボードの読み込み時間は、グラフで使用されるデータの量と、計算されるメトリックの影響を受けます。

ダッシュボードが Process Mining に読み込まれるたびに、各グラフが並列に計算されます。グラフの読み込み速度に影響する要因は次のとおりです。

• グラフに表示するメトリックの数。

• 各メトリックでは、メトリックを計算するために必要な結合サイズが重要です。結合サイズを判断するには、グラフをグループ化するために使用するテーブルに、メトリックのテーブルを組み合わせます。

  • 2 つのテーブル間のリレーションの複雑さ

  • データ モデル内での 2 つのテーブル間の距離

• 使用するフィールドのデータ型。数値フィールドはテキスト フィールドよりも高速です。

• メトリック自体の複雑さ。メトリックが複数のフィールドに基づいている可能性があります。

ダッシュボードのパフォーマンスを向上させる方法

グラフに必要のないメトリックを削除すると、読み込み時間が短縮されます。

• 上部バーに表示する KPI を検討する。

• グラフに表示するメトリックを検討する。グラフに複数のメトリックを表示する場合は、メトリックごとに追加の計算時間が加わります。

メトリックの定義を簡素化することでも、グラフの読み込み時間を短縮できます。

• メトリックの定義を簡素化できるかどうかを検討する。

• データ変換時にメトリックの一部を事前計算することを検討する。以前にすでに行われた静的計算は、実行時に実行する必要はありません。