Process Mining

変換

フォルダー構造

プロセスアプリの変換は、1 つの dbt プロジェクトで成り立ちます。以下の表は、dbt プロジェクトフォルダーの内容の説明です。

フォルダー/ファイル	次の値を含む
`dbt_packages\`	`pm_utils` パッケージとそのマクロです。
`logs\`	dbt の実行時に作成されるログです。
`macros\`	カスタムマクロです。
`models\`	`.sql` 変換を定義するファイル
`models\schema\`	`.yml` データに対するテストを定義するファイル
`seed`	`.csv` 構成設定を含むファイル
`dbt_project.yml`	dbt プロジェクトの設定です。

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

dbt_project.yml

dbt_project.yml ファイルには、変換を定義する dbt プロジェクトの設定が含まれています。vars セクションには、変換で使用される変数が含まれます。

日付/時刻形式

各アプリテンプレートには、日付/時刻のデータを解析するためのデータ形式を決定する変数が含まれています。入力データの日付/時刻の形式が期待と異なる場合は、これらの変数を調整する必要があります。

データ変換

データ変換は、models\ ディレクトリ内の .sql ファイルで定義されます。データ変換は、サブディレクトリの標準セット内で整理されています。

1_input
2_entities
3_events
4_event_logs
5_business_logic です。

「変換の構造」をご覧ください。

.sql ファイルは Jinja SQL で記述されており、プレーンな SQL クエリに Jinja ステートメントを挿入できます。dbt ですべての .sql ファイルが実行されると、各 .sql ファイルによってデータベース内に新しいビューまたはテーブルが生成されます。

.sql ファイルは通常、次の構造を持ちます。

With ステートメント: 必要なサブテーブルを含む With ステートメントが 1 つ以上必要です。
- {{ ref(‘My_table) }} は、別の .sql ファイルで定義されたテーブルを参照します。
- {{ source(var("schema_sources"), 'My_table') }} は入力テーブルを参照します。
メインクエリ: 新しいテーブルを定義するクエリです。
最後のクエリ: 通常、Select * from table のようなクエリが最後に使用されます。これにより、デバッグ中に副選択を簡単に行うことができます。

変換の効果的な記述方法について詳しくは、「SQL を記述するためのヒント」をご覧ください。

ソーステーブルを追加する

dbt プロジェクトに新しいソーステーブルを追加するには、そのテーブルが models\schema\sources.yml のリストに含められている必要があります。こうすることで、他のモデルが {{ source(var("schema_sources"), 'My_table') }} を使用してテーブルを参照できます。以下の画像で例をご確認ください。

重要: 新しいソーステーブルは、それぞれ sources.yml のリストに加えられている必要があります。

クエリでソーステーブルを使用する方法について詳しくは、「変換の構造: 1. 入力」をご覧ください。詳しくは、ソースに関する dbt の公式ドキュメントをご覧ください。

データ出力

データ変換は、対応するアプリで必要となるデータモデルを出力する必要があります。つまり、期待されるそれぞれのテーブルとフィールドが存在する必要があります。

これは実際の場面では、models\5_business_logic 内のテーブルを削除すべきではないということを意味します。また、対応するクエリの出力フィールドは削除すべきではありません。

プロセスアプリに新しいフィールドを追加する場合は、これらのフィールドを変換に追加できます。

ヒント:

dbt docs コマンドを使用して dbt プロジェクトのドキュメントサイトを生成し、既定のブラウザーで開くことができます。このドキュメントサイトにはリネージグラフも含まれます。リネージグラフには、プロジェクト内の各データテーブル間の関係をグラフィカルに表したエンティティリレーションシップダイアグラムが表示されます。

詳しくは、dbt docs に関する dbt の公式ドキュメントをご覧ください。

マクロ

マクロを使用すると、一般的な SQL の構造を簡単に再利用できます。詳しくは、Jinja マクロの dbt 公式ドキュメントをご覧ください。

pm_utils

pm-utils パッケージには、Process Mining の変換で通常使用されるマクロが一式含まれています。pm_utils マクロについて詳しくは、「ProcessMining-pm-utils」をご覧ください。

以下に pm_utils.optional() マクロを呼び出す Jinja のコードの例を示します。

シード

シードとは、変換にデータテーブルを追加するために使用される csv ファイルです。詳しくは、Jinja のシードに関する dbt の公式ドキュメントをご覧ください。

Process Mining では、変換内のマッピングを簡単に設定できるよう、一般的にシードが使用されます。

シードファイルを編集しても、ファイルはデータベース内で即座に更新されません。シードファイルの新しい内容をデータベースに読み込むよう dbt に指示するには、以下のいずれかを実行します。

dbt seed - シードファイルのテーブルのみ更新します。
dbt build - すべてのモデルとテストも実行します。

注: 最初にシードファイルにデータレコードが含まれていない場合、データベース内のデータ型が正しく設定されていない可能性があります。これを修正するには、run dbt seed --full-refresh を呼び出します。これにより、データベース内の列のセットも更新されます。

アクティビティの設定

activity_configuration.csv ファイルは、アクティビティに関連する追加フィールドを設定するために使用されます。activity_order は、同じタイムスタンプで 2 つのイベントが発生する際のタイブレーカーとして使用されます。以下の画像で例をご確認ください。

テスト

models\schema\ フォルダーには、テストを定義する.yml ファイル一式が含まれます。これらのファイルは、期待されるデータの構造と内容を検証します。詳しくは、テストに関する dbt の公式ドキュメントをご覧ください。

変換を Process Mining で実行すると、各データ取り込みでは sources.yml 内のテストのみが実行されます。これは、入力データの書式が正しいかどうかを確認するために行われます。

注: 変換を編集する際は、テストを適宜更新してください。テストは必要に応じて削除できます。

dbt プロジェクト

データ変換は、入力データを Process Mining に適したデータに変換するために使用されます。Process Mining の変換は dbt プロジェクトとして書き込まれます。

このページでは、dbt について説明します。詳しくは、dbt の公式ドキュメントをご覧ください。

pm-utils パッケージ

Process Mining のアプリテンプレートには、pm_utils という dbt パッケージが付属しています。この pm-utils パッケージには、Process Mining の dbt プロジェクト用のユーティリティ関数とマクロが含まれています。pm_utils について詳しくは、「ProcessMining-pm-utils」をご覧ください。