はじめに
こんにちは、京セラコミュニケーションシステム 西田（@kccs_hiromi-nishida）です。
前編記事で、Dataformの概要とDataformを使うまでの準備について、中編では実際に簡単なデータパイプラインを作ってみました。
後編では、テストや定期実行に関して紹介します！
本記事は2023年9月ごろに作成しております。よって、引用している文章などはこの時点での最新となります。ご了承ください。
また、特別な記載のない限り画像はBigQuery（Dataform）の画面をキャプチャしたものとなります。
連載記事一覧
Dataformって何？便利そうだし調べてみた！（前編）
Dataformって何？便利そうだし調べてみた！（中編）
Dataformって何？便利そうだし調べてみた！（後編） ★本記事★
Dataformのテスト
Dataformではassertionsオプションを使ってデータのテストし、問題のあるデータを検知できます。
assertionsオプションは、中編記事でも紹介したSQLXファイルのconfigブロック内に定義するだけで、とても簡単に使うことができます。
代表的なassertionsオプションは以下の通りです！
nonNull
指定した列のすべての値がNULLでないことをチェックします。
config {
type: "table",
assertions: {
nonNull: ["user_id", "customer_id", "email"]
}
}
SELECT ...
uniqueKey
指定した項目の値がユニーク（重複していない）であることをチェックします。
config {
type: "table",
assertions: {
uniqueKey: ["user_id"]
}
}
SELECT ...
uniqueKeys
指定した複数項目のすべての値がユニーク（重複していない）であることをチェックします。
config {
type: "table",
assertions: {
uniqueKeys: [["user_id"], ["signup_date", "customer_id"]]
}
}
SELECT ...
rowConditions
指定した項目の値が、定義しているカスタムロジックにしたがっているかをチェックします。
正規表現も使えるので文字列に対する制約をかけるときに重宝しそうです。
config {
type: "incremental",
assertions: {
rowConditions: [
'signup_date is null or signup_date > "2022-08-01"',
'email like "%@%.%"'
]
}
}
SELECT ...
その他のassertions
上記4つのassertions以外にも
- 自作のアサーションを定義する
- アサーションを依存関係として追加する
というようなこともできます。
詳しくは公式のドキュメントをご確認ください！
assertion結果の確認方法
アサーション結果の確認方法は、2つあります。
1.実行ログから確認
BigQuery→Dataformと選択し、リポジトリを選択してWORKFLOW EXECUTION LOGSを選択すると、実行ログを確認できます。
エラーになっている開始時間のリンクを選択すると、詳細を確認できます。
2.テスト結果が保存されるテーブルを確認
テスト結果は自動的にBigQueryにデータセットが作成され、Viewとして保存されます。
Viewを確認することで、何が検知されたかわかります。
dataform_assertionsというデータセットの下にテーブルができているので、Viewに対してクエリを実行します。
結果を確認すると、customer_idはNOT NULLの条件が設定されているのに、値がnullになっていることからデータ違反として検知されたことがわかります。
Dataformの定期実行
Dataformのワークフローを定期実行させたい場合、Cloud SchedulerやCloud Composerを使うこともできますが、Dataformだけで完結するような簡単なデータパイプラインの場合はワークフロー構成で実行をスケジューリングする方法がシンプルで簡単だと思います。
Cloud SchedulerやCloud Composerを使用する方法に興味のある方は公式ドキュメントを参照してください。
リポジトリへ変更を反映（コミット）する
リリース構成の作成やワークフロー構成の作成は、リポジトリに変更がコミットされていることが前提となります。
前編で開発ワークスペースの作成を行い、中編ではその作成したワークスペースにSQLXファイルを作成しましたが、作成しただけだとリポジトリに変更がコミットされていないため、変更をコミットする必要があります。
ワークスペースに〇件の変更をCOMMITと表示されている場合、その件数のコミットがまだリポジトリに行えてないということになるので、コミットしておきましょう。
この場合だと、4件の変更をCOMMITという部分を選択します。
コミットメッセージを入力し、すべてのファイルをCOMMITを選択してください。
すると、PUSH TO DEFAULT BRANCHという表示に切り替わるので、選択します。
ワークスペースは最新の状態という表示になればOKです。
リリース構成を作成する
ワークフローの定期実行を行う設定をする前に、リリース構成を作成する必要があるので作成します。
Dataformのリポジトリを選択し、RELEASE CONFIGURATIONSを選択します。
新しいリリースの構成を選択します。
リリースIDを入力し、頻度はなしとします。
その他の項目は今回は入力・設定の必要はないので、このまま作成を選択します。
リリース設定が作成されました。
ワークフロー構成の作成
次に、ワークフロー構成の作成を行います。
Dataformのリポジトリを選択し、WORKFLOW CONFIGURATIONSを選択し、新しいワークフロー構成を選択します。
構成IDを入力し、リリース構成は先ほど作成したリリース構成を選択します。
サービスアカウントは今回はデフォルトのサービスアカウントを選択しました。
頻度は、Cron形式での指定となります。
この例だと、毎日午前12時の実行指定になります。他にもさまざまな指定方法があるので、公式ドキュメントを確認し、実行したい頻度の指定を行ってください。
最後に実行するアクションの指定を行います。
- ALL ACTIONS
すべてのアクションを実行 - SELECTION OF ACTIONS
実行するアクションを選択して実行 - SELECTION OF TAGS
実行するタグを選択して実行
※タグに関しては今回の連載記事では触れていませんが、SQLXファイルを作成する際にconfigブロック内にタグの指定をすることで、タグ単位でのアクション実行を行うことが可能です。
作成を選択すると、スケジュールが作成されます。
実行結果は、WORKFLOW EXECUTION LOGSで確認できます。
おわりに
前編・中編・後編とDataformに関して紹介しました。
いかがでしたか？
私も今回はじめてDataformを使ったのですが、SQLを書くことができれば、ほとんど苦労することなく使えるサービスだと感じました！
今回連載で紹介した内容以外にも、Dataformにはさまざまな機能があります。
興味がある方はぜひ公式ドキュメントも確認してみてくださいね。