ごあいさつ
こんにちは。日鉄ソリューションズ株式会社のhayashitaniです。
私が所属している組織では製造業のお客様向けに、データ基盤構築、データガバナンスコンサルなどを支援させていただいております。
今回は、OSSのデータカタログツール「OpenMetadata」を使って、データカタログにSnowflakeの実データプロファイリング情報（統計情報）を登録してみたいと思います。
本記事はOpenMetadataの実機操作記事の、３回目の投稿となります。
これまでの投稿については以下のリンクで投稿しています。
| no | 概要 |
|---|---|
| # | データカタログ概要 |
| 1 | Snowflakeのテクニカルメタデータをデータカタログに取得する |
| 補足 | Snowflakeの日本語table・view・columnをクローリングしてみる |
| 2 | Snowflakeの実データをサンプルとしてデータカタログに登録する |
| 3 | Snowflakeのプロファイリング情報をデータカタログに登録する ★本記事 |
| # | ビジネスメタデータをデータカタログに登録する |
| # | データカタログの検索機能を触ってみる |
| # | リネージをデータカタログに登録する |
| # | Snowflakeの利用情報をデータカタログに登録する |
| # | 用語をデータカタログに登録する |
| # | プロファイリング情報をデータカタログに登録する |
| # | データカタログで品質テストを行う |
本投稿の内容は私個人の意見であり、組織の見解を代表するものではありません。
メタデータの概要については以下に投稿を行っています。
前提
- OpenMetadataがインストール済み（本記事では、１．６．１バージョンを利用）
- Snowflakeアカウントを利用可能
- Snowflakeの対象テーブルに1レコード以上データが登録されている
- ブラウザを利用可能（本記事では、Chromeを利用）
- OpenMetadata上にSnowflakeの対象テーブルのテクニカルメタデータを取得済み
テクニカルメタデータの取得によって、データカタログ上にオブジェクトが作成され、そのオブジェクトに対して実データのプロファイリング情報を登録します。
そのため、サンプルデータの登録には、テクニカルメタデータが既にデータカタログ上に存在することが大前提となります。
こちらはOpenMetadataに限らず、ほとんどのデータカタログで同様の仕様です。
準備
- ブラウザからOpenMetadataにログイン
対象のテーブルにプロファイリング情報が登録されていないことを確認するため、対象のテーブルのページを開き、「Data Observability」タブ ＞ 「テーブルプロファイリング」タブを表示します
「Data Observability」タブ ＞ 「カラムプロファイリング」タブを表示します
未登録なので、黄色の枠内に「Data Profiler is an optional configuration in Ingestion. Please enable the data profiler by following the documentation」と表示されました
プロファイリング情報取得ジョブ作成
「設定」＞「サービス」＞「データベース」＞ 対象のデータベースサービス をクリックして、サービスオブジェクトのページを開き、インジェスチョンタブを参照します
インジェスチョンは、情報を取得するためのジョブの名称です。
OpenMetadataでは、用途毎にインジェスチョンの種類が分かれています。
「インジェスチョンを追加」＞「プロファイラインジェスチョン」をクリックします
取込設定、スケジュール設定を行い、デプロイします
（省略）
以下重要な設定項目です
- 「Compute Metrics」はオンにします
- Viewのプロファイリングを取得する場合は「Include Views」をオンにします
- テーブルのプロファイリングを取得する場合は「Compute Table Metrics」をオンにします
- カラムのプロファイリングを取得する場合は「Compute Column Metrics」をオンにします
「Profile Sample Type」、「Profile Sample」については後日追記します。
OpenMetadataのインジェスチョンはテーブル単位で複数作成することができます。
そのため、重くなりがちなプロファイリング情報の取得を、各テーブルに必要な頻度で設定することができます。
今回は１度ジョブを実行できれば良いので、スケジュール設定は手動実行で指定します
取込ジョブ実行
サービス画面のインジェスチョンタブを開き、対象のジョブを実行します
ステータスが「SUCCESS」になったら完了ですが、「FAIL」となりました。
ログボタンをクリックして、エラーとなった理由を確認します。
権限不足でSNOWFLAKE.ACOUNT_USAGE.QUERY_HISTORYビューへのにアクセスに失敗し、エラーとなっていました。（エラーはテーブル毎に出ています。）
取得しようとしているのは、テーブルへのINSERT/UPDATE/DELETE/MERGEのクエリ履歴なので、おそらく以下の画像「Table Updates」、「Volume Changes」グラフの情報を取得しようとして失敗したのではないかと推察します。
エラーの内容から、他の情報は取得できているのではないかと思います。
（画像の引用元：https://docs.open-metadata.org/latest/how-to-guides/data-quality-observability/profiler/workflow）
結果
※インジェスチョンがエラーとなった際の結果です。
テーブルのプロファイル
対象のテーブルのページを開き、「Data Observability」タブ＞「テーブルプロファイル」タブを表示します
レコード数、カラムCount、サイズ、作成日などが取得されていました！
Table Updates、Volume Change以外の結果が取得されていませんでした。 この２つは、SNOWFLAKE.ACCOUNT_USAGE.QUERY_HISTORYの情報から取得しているようです。
カラムのプロファイル
対象のテーブルのページを開き、「Data Observability」タブ＞「カラムプロファイル」タブを表示します
こちらも取得できていました！
カラム名、データ型の横に、NULLの割合、ユニークの割合、DISTINCTの割合、値の数が一覧で表示されてます
さらに、カラム名をクリックすると、各カラムの詳細を確認できます。
(省略)
各カラムのプロファイリング情報がグラフやヒストグラムで可視化されます。
補足
サンプルデータの取得でも記載しましたが、オブジェクトのページはヘッダーが共通で、タブ毎に表示される情報が変わるようになっています。
テーブルのページでは「スキーマ」タブを選べばテーブル定義、「Data Observability」タブを選べばプロファイリングデータが表示されるので、タブを切り替えるだけで、以下の図のように簡単にテーブル定義とプロファイリングデータを交互に参照することができるようになりました。
そのため、利活用データの探索において、テーブル定義書（Excelファイル）を見て良さそうであれば、Snowflakeにログインして実データの品質を確認する、という一連の流れが全てデータカタログ上で実施できるようになりました。
このような使い方をすれば、苦労して入手したデータがNULLばかりで使えない、といったことを回避できるのではないでしょうか。
追加調査
1. エラーの原因を確認する
エラーの内容から、QUERY_HISTORYビューへの権限不足が原因だと思われるので、権限付与を行い、動作確認をします。
まずは、Snowflake上でQUERY_HISTORYビューにアクセスできないことを確認します
Snowflake上で、対象のロールに権限を付与します
権限については以下のサイトを参考にQUERY_HISTORYビューの参照に必要な権限を付与しました。
ORGADMINが有効になっている場合のACCOUNT_USAGEへの権限付与の注意点
https://docs.snowflake.com/ja/sql-reference/account-usage#enabling-the-snowflake-database-usage-for-other-roles
Snowflake上でQUERY_HISTORYビューにアクセスできることを確認します
再度インジェスチョンを実行します
処理に成功しました！
エラーの原因はQuery Historyビューへの権限不足だとわかりました
2. Table Updates、Volume Changesを取得する条件を考察する
「1. エラーの原因を確認する」にて、処理自体は成功するようになりましたが、対象のテーブルのページ＞「Data Observability」タブ＞「テーブルプロファイル」タブを参照すると以下の画像の通り、Table Updates、Volume Changesのデータは更新されていませんでした
エラーログから、QUERY_HISTORYに対して実行しているSQL文を参照します。
SQLの内容からQUERY_HISTORY情報の取得には、少なくとも以下の条件がありそうです。
- QUERY_HISTORYテーブルに記録されている
- QUERY_HISTORYテーブルのクエリタイプがINSERT、DELETE、UPDATE、MERGEのどれか
- QUERY_HISTORYのクエリのステータスが成功になっている
- インジェスチョンの実行日時から24時間以内に実行されている
SNOWFLAKEにて、対象テーブルに、INSERT、DELETE、UPDATE操作を実施します
以下の操作を実施しました
- INSERT：5レコード
- UPDATE：4レコード
- DELETE：10レコード
再びプロファイラインジェスチョンを実行します
処理は成功しました
対象のテーブルのページ＞「Data Observability」タブ＞「テーブルプロファイル」タブを参照します
Table Updates、Volume Changesが登録されました！
以下の通り、操作したレコード数とも一致しています
- INSERT：5レコード
- UPDATE：4レコード（SQL文が２つに分かれていたので、グラフも分かれています）
- DELETE：10レコード
今回引っかかったTable Updates、Volume Changes登録の条件は「インジェスチョンの実行日時から24時間以内に実行されている」であったことがわかりました。
最後に
一部の機能についてはSnowflake上で追加の権限の付与が必要でしたが、テクニカルメタデータを取得済みであったので、プロファイリングデータも簡単に取得することができました。
今回取得したデータプロファイリング情報は、データ利活用の中でも、特にデータ選択やデータクレンジングのプロセスにおいて役立つと考えています。理由は次の通りです。
データ選択
データ集める際に以下のような事象に直面したことはないでしょうか？？
- 利用したいカラムの値がすべてNULLだった
- 利用したいカラムの値がすべて同じで、有用性がなかった
- 利用したいカラムの値がコード化されており、単体では活用できなかった
こういった場合は、データを取得しても活用することはできません。
しかし、これらの情報はDBにアクセスしSQLを実行しないとわからないことが多いです。
そのため、データ取得と確認を繰り返すことで適切なデータを選定するプロセスに時間がかかることが課題となっています。
データカタログではデータに対する権限が無い場合であっても、データカタログを通じてデータプロファイリング情報としてデータの状態を参照できるので、効率的に最適なデータを選択することができると考えています。
データクレンジング
データクレンジングは、データの状態に応じて適切な処理が必要です。
そのため、プロファイリング情報に関しては、データを活用する方々が、すでにデータクレンジングに必要な作業やその所要時間を見積もるために個別に収集・活用しているのではないでしょうか。
また、データクレンジングはデータ利活用において必須のプロセスであり、多くの時間を要することが一般的です。したがって、これらの作業を一元化し、自動化することで、データクレンジングの手間を少しでも減らし、本来の業務にかける時間を増やすことができるのではないかと考えています。
以下についてはデータサンプリングと同様なので、本記事では割愛いたします。
- インジェスチョンをテーブル単位で指定できるので、柔軟に情報取得が可能です
- スキーマ情報とプロファイリング情報の切り替えが簡単にできます
【OpenMetadata】Snowflakeの実データをサンプルとしてデータカタログに登録する
本記事についてご不明点、ご質問事項等があれば、コメントをお願いいたします。
また、本分野に関してご興味を持っていただけた方がいらっしゃれば、お気軽にお問い合わせください。