- リリース ノート
- はじめる前に
- 基本情報
- アクセス権を管理する
- プロセス アプリを使用する
- プロセス アプリを作成する
- データを読み込む
- プロセス アプリをカスタマイズする
- データ変換
- TemplateOne アプリ テンプレート
- Purchase-to-Pay アプリ テンプレート
- Order-to-Cash アプリ テンプレート
- 基本的なトラブルシューティング ガイド
変換を編集する
データ変換は、入力データを Process Mining に適したデータに変換するために使用されます。Process Mining の変換は dbt プロジェクトとして書き込まれます。
このページでは、dbt について説明します。詳しくは、dbt の公式ドキュメントをご覧ください。
pm_utils
という dbt パッケージが付属しています。この pm-utils
パッケージには、Process Mining の dbt プロジェクト用のユーティリティ関数とマクロが含まれています。pm_utils
について詳しくは、「ProcessMining-pm-utils」をご覧ください。
pm-utils
パッケージに対して継続的な改善を行っています。
pm-utils
パッケージがリリースされたら、変換で使用されているバージョンを更新して、必ず pm-utils
パッケージの最新の関数とマクロを利用できるようにすることをお勧めします。
pm-utils
パッケージのバージョン番号は、ProcessMining-pm-utils の [リリース] パネルで確認できます。
pm-utils
のバージョンを更新するには、以下の手順に従います。
-
pm-utils
のリリースからソース コード (zip) をダウンロードします。 -
zip
ファイルを抽出し、フォルダーの名前を pm_utils に変更します。 -
インラインのデータ変換エディターから変換をエクスポートし、ファイルを抽出します。
-
エクスポートした変換の pm_utils フォルダーを、新しい pm_utils フォルダーに置き換えます。
-
変換の内容を再度 zip で圧縮し、データ変換エディターにインポートします。
プロセス アプリの変換は、1 つの dbt プロジェクトで成り立ちます。以下の表は、dbt プロジェクト フォルダーの内容の説明です。
フォルダー/ファイル |
次の値を含む |
---|---|
|
pm_utils パッケージとそのマクロです。
|
|
dbt の実行時に作成されるログです。 |
|
カスタム マクロです。 |
|
変換を定義する
.sql ファイル
|
|
データに対するテストを定義する
.yml ファイルです。
|
|
構成設定を含む
.csv ファイル
|
|
dbt プロジェクトの設定です。 |
以下の画像でご確認ください。
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 を記述するためのヒント」をご覧ください。
models\schema\sources.yml
のリストに含められている必要があります。こうすることで、他のモデルが {{ source(var("schema_sources"), 'My_table_raw') }}
を使用してテーブルを参照できます。以下の画像で例をご確認ください。
sources.yml
のリストに加えられている必要があります。
データの読み込み時に、ソース テーブルのテーブル名にサフィックス _raw が追加されます。たとえば、my_table というテーブルは my_table_raw として参照されます。
詳しくは、ソースに関する dbt の公式ドキュメントをご覧ください。
データ変換は、対応するアプリで必要となるデータ モデルを出力する必要があります。つまり、期待されるそれぞれのテーブルとフィールドが存在する必要があります。
models\5_business_logic
内のテーブルを削除すべきではないということを意味します。また、対応するクエリの出力フィールドは削除すべきではありません。
プロセス アプリに新しいフィールドを追加する場合は、プロセス アプリで利用可能なカスタム フィールドを使用できます。変換のフィールドをカスタム フィールドにマッピングして、出力で利用できるようにします。出力内のカスタム フィールドの名前は、プロセス アプリのデータ モデルで記述された名前と一致させてください。
dbt docs
コマンドを使用して dbt プロジェクトのドキュメント サイトを生成し、既定のブラウザーで開くことができます。このドキュメント サイトにはリネージ グラフも含まれます。リネージ グラフには、プロジェクト内の各データ テーブル間の関係をグラフィカルに表したエンティティ リレーションシップ ダイアグラムが表示されます。
dbt docs
に関する dbt の公式ドキュメントをご覧ください。
マクロを使用すると、一般的な SQL の構造を簡単に再利用できます。詳しくは、Jinja マクロの dbt 公式ドキュメントをご覧ください。
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
を呼び出します。これにより、データベース内の列のセットも更新されます。
models\schema\
フォルダーには、テストを定義する.yml
ファイル一式が含まれます。これらのファイルは、期待されるデータの構造と内容を検証します。詳しくは、テストに関する dbt の公式ドキュメントをご覧ください。
sources.yml
内のテストのみが実行されます。これは、入力データの書式が正しいかどうかを確認するために行われます。