この記事はSnowflakeAdventCalenderの20日目です。

もうすぐクリスマスですね
こんなときは私たちが提供するデータも安定していてほしいものです

ということで、今回はデータ品質を可視化したり定量値で収集するデータ品質の監視手法（直訳はデータ可観測性(DataObservability)）をいろいろ調べてみました。

データ可観測性（DataObservability）とは？

2019年頃にDataObservabilityツールを提供しているMONTE CARLOにて定義されたカテゴリーです。
組織がシステム内のデータの信頼性を可視化したり定量値を収集して、把握できていることを指します。
データの状況を可視化することで改善のサイクルをまわし、データのダウンタイムを削減していきたいという考えです。
具体的には以下のMONTE CARLOの記事が参考になります。

本記事で、MONTE CARLOはデータ可観測性の観点を5つの柱としてまとめています。
これらの観点は多少違いはあれど概ねデータ品質を監視する際に様々なツールでもよく使われている観点かと思います。

鮮度（freshness)　：分析に利用するデータがいつ時点のデータか？
品質（Quality）　：NULLの割合や一意の割合などをみて許容範囲内のデータであるか？データパイプラインが正常に動いていても、データの中身は壊れていることも往々にしてあり得ます
ボリューム（Volume）：データの大幅な欠損などデータの完全性として問題ないか？
スキーマ（Schema）：データの項目の追加変更や、配置先のスキーマ移動などが発生していないか？変更があった場合参照時にアプリケーション修正が必要になります
1.リネージュ（lineage）：汚染が発生しているデータはどこから来たデータか？下流では誰が使っているか？誰が生成しているか？

個人的にデータ可観測性は、まず第一歩はこれらの5つにあるような観点でデータの状態を可視化していくことだと考えています。
次の段階として、収集したデータを機械学習で異常検知させたりしてより指標の精度をあげていくことだと考えています。（一気にここまでできればよいですが）

さらに、MONTE CARLOの創業メンバーの方がデータ可観測性を実現した61個のユースケースをまとめた記事を出されていて面白かったので、興味ある方はぜひ。

データ可観測性（DataObservability）の手段

今回は可観測性の目的を語るというよりは、世の中どんな手段があるのかを調べたのでまとめてみます。他にも色々なライブラリやツールがあるかと思いますが目立って見つかったものを挙げさせていただきます。

[CloudService]AWS Deequ
こちらの記事が参考になりました。

[CloudService]Snowflake DataMetrics Function
PrPr機能ですが、後述します
[Observability Tool]MONTE CARLO
FreeTrialはすぐに使えずただ、異常検知等は過去実績から学習して自動検知してくれるので、とても便利そう

[Free tools]dbt elementary
dbt coreでも使えるので嬉しいです。以下が分かりやすかったです。

[Observability Tool]SODA

SnowflakeDataMetricsFunciton（※PrPr）お試し

今回はせっかくなので2023年6月のSnowflakeSummitの個別セッションを見てから気になっていたSnowflakeのDataMetricsFunction機能を試させていただきました。
とはいえ、残念ながら現段階ではPrPr機能でまだ公開できない情報でしたので、少しぼかしながらお話させていただきます

まず大きく以下のいずれかで関数設定ができ、SQLベースでデータチェックを実行できるようになっています。※UDFなイメージ

Snowflakeデフォルト提供の関数
カスタム関数

デフォルトで提供される関数は、概ねDataObservabilityとは？で前述の可観測性の5つの柱に近い観点かと思います。
例：鮮度、完全性（NULLチェック）、分布（一意性チェック）、データボリューム（ROW_COUNT）

データチェックの流れはざっくりと以下です。

対象TABLE/VIEWの項目にデフォルト提供の関数を設定 ※手動も可能だが、今回はスケジュール実行
関数の実行ログはSnowflakeのEVENT TABLEをアカウントと紐づければEVENT TABLEに出力
EVENT TABLEの値がJSON形式なので、見やすいようにVIEWで加工
出力結果をBIツール（今回はSigma）に連携して、閾値アラート　※streamlit等でも可

１~3の実行実績はPuPrになったら更新；；

たとえば、
・データ鮮度の場合は、スケジュール実行時⇔対象のTIMESTAMP項目の差分を取得します。差分の値が設計値や今までの実績からずれた場合に通知をとばします。
・データの完全性については、対象項目のNULLの数を取得します。このNULLの数を定期的に取得していつもよりNULLが多いなど、連携データの欠損などの異常を検知できます。
・データ容量については、スケジュール実行時点のテーブルレコード数を監視します。通常よりもレコード数が大幅に少ない場合などの検知することができます。

今回は一旦正常時で静的なテーブルですが、関数の適用と出力結果だけ確認しました。
適用関数などは今回記載しないため、あくまで参考イメージ程度になりますが・・

出力結果（Snowsight側）

出力結果（BIツール Sigma利用）

※実際の想定ケースは日次

所感

用途
自分のプロジェクトでは
・データ鮮度チェック：データ取得時
・データ重複チェック：レコード更新時
に実施しており上流から不正データが送られてきたときは不正検知できるようになっています。
ただ、これは上流連携データの不正チェックであり、その後パイプライン加工時におかしなデータが作成されていると気づける契機が少ないです。
パイプラインの検知のなかですり抜けるデータ汚染を公開データを監視することによって早急に検知してデータのダウンタイムを短くするためには、今回のSnowflakeの機能はまさに公開データへ適用できるチェッククエリでした。
機能面
関数設定自体はとても簡易で、対象テーブルや対象項目さえ整理できていれば10分程度で設定できます。
関数実行時のWHコストが少し気になりますが、24時間以内でスケジューリングすればキャッシュで動かせるかもしれないです。
他の手法との違い
Pythonでもできますが、SQLでそのままTABLEに実行結果を出力してSnowflake内で完結できるのはツール接続などせずに済むので楽なのではと思います。

結論としては手段はどれでもよく、安くて簡単につくれるのが一番な気がします。
ただ、DataObservability製品ともなると、閾値も実績値から学習して自動で判定アラートだしてくれるので、とても便利でリッチだなと思いました。