データ品質を壊しながらSnowflakeのAIに分析させてみた

Transcript

1. データ品質を壊しながら Snowflake の AI に分析させてみた データ事業本部ビジネスソリューション部 川中⼦凌平
2. ⾃⼰紹介 2 名前：川中⼦凌平 (かわなごりょうへい) 所属：データ事業本部 ビジネスソリューション部 業務：データ分析基盤の構築（データエンジニア） 趣味：⽝と遊ぶこと https://dev.classmethod.jp/author/kawanago-ryohei/
3. 今⽇お話しすること • • 今回はデータ分析基盤で管理するデータの品質ついてお話しします ◦ データ品質がAIによる分析に与える影響 ◦ データ品質を守るためのSnowflakeの機能 データ品質などの運⽤⾯については6⽉のウェビナーでお話しています 3
4. データ分析はAIが担う時代に • AIの活⽤によりビジネスユーザーが⾃然⾔語でデータ分析できる時代に • Snowflakeはデータの蓄積‧管理からAIによる分析まで⼀つのプラット フォームで完結するため⾮常に⼈気がある https://www.snowflake.com/ja/blog/ai-data-agents-snowflake-cortex/ 4
5. AI活⽤におけるデータ品質の課題 • PwC Japanの調査では、⽣成AIの効果が期待を下回った理由で「データ品質」が1位 • 実態としては、そもそもデータ品質の課題に気付いていないケースも考えられる https://www.pwc.com/jp/ja/knowledge/thoughtleadership/2025/assets/pdf/generative-ai-survey2025.pdf 5
6. データ品質がAIの分析結果に与える影響 6
7. 検証構成イメージ • 内部ステージ：ソースシステムから⽣データのCSVを連携 • Bronze層：COPY INTOで⽣データをロード • Silver層：正規化‧型変換 • Gold層：BI‧AI向けに公開 + Semantic Viewを定義 • AI活⽤層：Cortex Analyst + Agentで分析 7
8. Semantic Viewの定義 • Gold層には以下のような定義でSemantic Viewを作成した CREATE SEMANTIC VIEW EC_SALES_ANALYSIS TABLES ( orders AS ORDERS PRIMARY KEY (ORDER_ID) COMMENT = '注⽂トランザクション', customers AS CUSTOMERS PRIMARY KEY (CUSTOMER_ID) COMMENT = '顧客マスタ', products AS PRODUCTS PRIMARY KEY (PRODUCT_ID) COMMENT = '商品マスタ' ) RELATIONSHIPS ( orders (CUSTOMER_ID) REFERENCES customers (CUSTOMER_ID), ... ) DIMENSIONS ( orders.order_id AS ORDER_ID COMMENT = '注⽂ID', ... ) METRICS ( orders.total_order_amount AS SUM(ORDER_AMOUNT) COMMENT = '注⽂⾦額合計', ... ) 8
9. 分析対象データ 9
10. 正常な状態での分析 • 投げた質問に対して正しい情報が返ってくることを確認 • 正常なテーブルでの売上集計は915,900円だった 10
11. データ品質劣化の想定ケース 11 • 現実のデータ基盤運⽤では、様々な原因でデータ品質が劣化する • 今回は以下のケースを想定してデータ品質を壊してみました 原因 例 連携処理の不備 同⼀データが別名ファイルとして再連携されてデータが重複 ソース側の仕様変更 ソース側の障害 返品データが負の⾦額として混⼊ ⽇次エクスポートが停⽌してしまい鮮度が劣化
12. ケース1 — 重複データの混⼊ 想定シナリオ：同⼀データが別名ファイルとして再ロードされた • 8⽉のレコードが全て2⾏ずつに重複してしまっている状態 12
13. ケース1 — 重複データの混⼊ • 実⾏した集計処理は正しいが、実際の売上よりも2倍⾼い⾦額が出てしまう 13
14. ケース2 — マイナス⾦額の混⼊ 想定シナリオ：ソース側の仕様変更で、負の⾦額が売上テーブルに混⼊した • ORDER_AMOUNT列に負の値が⼊ってしまっている状態 14
15. ケース2 — マイナス⾦額の混⼊ • 負の値もまとめて集計されてしまい、実際の⾦額よりも低く出てしまう 15
16. ケース3 — データの鮮度劣化 想定シナリオ：ソース側の⽇次連携が停⽌し、直近7⽇分のデータが⽋落 • 8⽉25⽇以降のデータがテーブルに連携されていない状態 16
17. ケース3 — データの鮮度劣化 • 8⽉24⽇までのデータしか集計されず、実際の売上より低く出てしまう 17
18. AIはデータ品質の異常を⾒落とすことがある • 3つのエラーケースの結果は以下の通りだった ケース • 重複データの混⼊ ⾦額が実際の2倍になる マイナス⾦額の混⼊ ⾦額が⼤幅に少なくなる データの鮮度劣化 ⽋落分だけ⾦額が少なくなる いずれのケースでもAIによる分析では異常を指摘しなかった ◦ • 分析結果への影響 内容によっては、異常に気付いて教えてくれるケースもあった ユーザーに誤った⽰唆を与えてしまうリスクが⽣じる 18
19. なぜAIはデータ品質の異常に気付けないのか • Semantic Viewではデータの構造や意味を説明している 定義するもの 例 テーブルの説明 「注⽂トランザクション」 主キー テーブル間の関係性 カラムの意味 集計指標 ORDER_ID ORDERS.PRODUCT_ID → PRODUCTS.PRODUCT_ID 「注⽂⾦額（⽇本円）」 SUM(ORDER_AMOUNT) → 注⽂⾦額合計 • Cortex Analystはこの情報をもとにSQLを⽣成する • しかしカラムの有効値や値の形式のようなデータ品質の制約は持てない • データ品質を守り、異常を検知するには別の仕組みが必要 19
20. データ品質を守るために 20
21. データ品質を守る2つのポイント 21 • ⼀度⼊ってしまったエラーデータをクレンジングするのは⾮常に⼤変 • データが⼊ってくる⼊⼝と、活⽤の窓⼝の両⽅を監視することが重要 基盤の⼊⼝で守る データを定点観測する どこで：基盤への⽣データの取り込み どこで：公開するテーブル / カラム なにを：型 / ⽋損 / 形式 / 許可値 なにを：品質⽬標値との乖離 どうする：問題を検知したら拒否 / 退避 どうする：品質低下を検知したら通知
22. データ取り込み時のエラー処理 • • 22 COPY INTOやSnowpipeでは基本的なスキーマレベルのエラーを検知する ◦ データ型不整合 / カラム数の不一致 / NOT NULL制約違反 など ◦ 値の重複 や許可値、値閾などの品質検証はできない エラー発⽣時の挙動はON_ERRORオプションで細かく制御が可能 値 動作 ABORT_STATEMENT 最初のエラーで全体を中断 CONTINUE エラー⾏をスキップして続⾏ SKIP_FILE エラーのあるファイルを丸ごとスキップ SKIP_FILE_n n件以上のエラー⾏があるファイルをスキップ SKIP_FILE_n% n%を超える⾏がエラーのファイルをスキップ
23. エラー内容の確認 23 • スキップされたファイル‧⾏のエラーはSnowflake内に記録される • エラーの詳細はVIEW、またはテーブル関数で確認することができる 確認⽅法 粒度 ACCOUNT_USAGE.COPY_HISTORY ファイル単位 status、⾏数、最初のエラーメッセージ ⾏単位 どの⾏のどのカラムがなぜ失敗したか VALIDATE関数 主な情報
24. DMF（Data Metric Functions） 24 • テーブルやビューに紐づけて、対象のデータの品質をチェックする機能 • 基盤⼊⼝になるBRONZE層や、ユーザーに公開するGOLD層に使⽤する • データ変更時やスケジュールで⾃動実⾏できる • Snowflake上で完結し、Horizon Catalogで品質状態を可視化できる • 基本的な品質検証はデフォルトで準備されている 種類 特徴 システムDMF ビルトインで約50種あり、すぐに利⽤可能 カスタムDMF 独⾃ロジックが必要な場合にSQLで定義
25. システムDMFの例 • 25 システムDMFには以下のようなものがある カテゴリ • 関数例 正確性 NULL_COUNT, NULL_PERCENT, BLANK_COUNT ⼀意性 DUPLICATE_COUNT, UNIQUE_COUNT 鮮度 FRESHNESS ボリューム ROW_COUNT テーブルへの適⽤例 ALTER TABLE ORDERS ADD DATA METRIC FUNCTION SNOWFLAKE.CORE.DUPLICATE_COUNT ON (ORDER_ID);
26. カスタムDMFの例 — 鮮度チェック • 独⾃ロジックが必要な場合はカスタムDMFを作成する • 以下は最新データからの経過⽇数を返す鮮度検証の関数の例 CREATE OR REPLACE DATA METRIC FUNCTION DM_FRESHNESS_DAYS( ARG_T TABLE(ORDER_DATE DATE) ) RETURNS NUMBER AS $$ SELECT DATEDIFF( DAY, MAX(ORDER_DATE), SNOWFLAKE.CORE.DATA_METRIC_SCHEDULED_TIME() ) FROM ARG_T $$; 26
27. Expectation — 品質の合否判定 • DMFの結果に閾値を設定し、PASS / FAILで合否判定する仕組み • 結果はHorizon Catalogに連携されるため、品質状態が⼀⽬で分かる ALTER TABLE ORDERS ADD DATA METRIC FUNCTION SNOWFLAKE.CORE.DUPLICATE_COUNT ON (ORDER_ID) EXPECTATION dup_check (VALUE = 0); ALTER TABLE ORDERS ADD DATA METRIC FUNCTION SNOWFLAKE.CORE.NEGATIVE_COUNT ON (ORDER_AMOUNT) EXPECTATION neg_check (VALUE = 0); ALTER TABLE ORDERS ADD DATA METRIC FUNCTION SNOWFLAKE.CORE.FRESHNESS ON (ORDER_DATE) EXPECTATION freshness_check (VALUE <= 604800); 27
28. Horizon Catalogで品質を確認 • テーブル > Data Quality タブでDMFとExpectationの結果を確認できる 28
29. Notification Integration • Notification Integrationを使⽤して品質エラー時の通知を設定可能 • Expectation違反や異常を検知した際に、⾃動的に通知が⾶ぶ CREATE NOTIFICATION INTEGRATION dq_notify TYPE = EMAIL ENABLED = TRUE ALLOWED_RECIPIENTS = ('user@example.com'); ALTER DATABASE DEVIO_2026_DEMO SET DATA_QUALITY_MONITORING_SETTINGS = $$ notification: enabled: TRUE integrations: [DQ_NOTIFY] $$; 29
30. Alertによる柔軟な通知 • Notification Integrationより柔軟な条件で通知したい場合はAlertを使う • DMFの結果テーブルを直接SQLでクエリするため、複雑な条件も書ける CREATE OR REPLACE ALERT dq_duplicate_alert WAREHOUSE = DEVIO_2026_WH SCHEDULE = 'USING CRON 0 */6 * * * Asia/Tokyo' IF (EXISTS ( SELECT * FROM SNOWFLAKE.LOCAL.DATA_QUALITY_MONITORING_RESULTS WHERE METRIC_NAME ILIKE '%DUPLICATE_COUNT%' AND VALUE > 0 )) THEN CALL SYSTEM$SEND_EMAIL( ... ); 30
31. 異常検出（Anomaly Detection） ※プレビュー • DMFの実⾏結果の履歴をもとに、Snowflakeが⾃動で異常を検出する • 閾値を⼿動で設定する必要がなく、予測範囲から外れた値を⾃動判定 • 結果はDATA_QUALITY_MONITORING_ANOMALY_DETECTION_STATUSに管理される 対応するシステムDMF 検出できる異常 ROW_COUNT データ量の急増‧急減 FRESHNESS 更新頻度の異常（更新停⽌など） 31
32. 異常検出（Anomaly Detection） ※プレビュー • ROW_COUNTを新たに設定し、異常検知の感度を設定する • 検知の感度はLOW / MEDIUM(デフォルト) / HIGHから選択する • 偽陽性を防ぎたい場合はLOW、偽陰性を減らしたい場合はHIGHにする ALTER TABLE ORDERS ADD DATA METRIC FUNCTION SNOWFLAKE.CORE.ROW_COUNT ON () ANOMALY_DETECTION = TRUE; ALTER TABLE ORDERS MODIFY DATA METRIC FUNCTION SNOWFLAKE.CORE.ROW_COUNT ON () SET SENSITIVITY = 'HIGH'; 32
33. 異常検出（Anomaly Detection） ※プレビュー • 検知した異常もカタログ上のデータ品質タブで確認できる 33
34. Cortex Data Quality ※プレビュー • テーブルのメタデータを分析し、AIが適切な品質チェック項⽬を推奨 • どんなデータ品質チェックを⼊れるべきか迷うときなどに便利 34
35. Cortex Data Quality ※プレビュー 35
36. dbtとの使い分け 36 • よくSnowflakeと併せて利⽤されるdbtもテスト機能は充実している • ただdbtでテストするのは主に、変換パイプラインを実⾏したとき • dbtで変換時の検知、DMFでGOLD層の品質可視化などの使い分けもできる Snowflake dbt • 変換前のBRONZE層にDMFを定義 • データ変換時の品質を検証 • 結果をHorizon Catalogで可視化 • 不合格時にパイプラインを⽌められる • 異常検知などの品質管理機能も強化中 • テストがコードとして管理される
37. まとめ 37
38. まとめ AIが分析する環境になってもデータ品質は最重要 • AIによる分析ができても、その結果はデータ⾃体の品質に左右される • Cortex Analystで正しいSQLを⽣成できても、データの正しさは保証しない Snowflakeにもデータ品質に向けた機能が揃ってきている • 測定‧判定‧通知‧可視化をSnowflake内で⼀貫して実装できる • 今後は異常検出機能、Cortex Data Qualityによる品質検査の提案も まずはデータ品質の問題を検知できる仕組みづくりから • SnowflakeのDMFなら外部ツールを使わずにすぐに実装ができる • データの⼊⼝、ユーザー公開しているテーブルから品質検査を始めよう 38
39. ご清聴ありがとうございました