Process Mining

パフォーマンス特性

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

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

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

開発データと運用データ

Process Mining の各アプリには、開発ステージとパブリッシュ済みステージがあります。目的のアプリでサイズの大きいデータセットが必要な場合は、データ変換とダッシュボードの開発には、よりサイズの小さいデータセットを使用することをお勧めします。アプリが完成したら、よりサイズの大きいデータセットを使用して、エンドユーザーにパブリッシュできます。「[開発] タブ」をご覧ください。

一般的なシナリオとしては、タイムフレームが短いデータセットを開発に使用します。たとえば、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 つのテーブル間の距離
使用するフィールドのデータ型。数値フィールドはテキストフィールドよりも高速です。
メトリック自体の複雑さ。メトリックが複数のフィールドに基づいている可能性があります。