第2章 アカウント管理とデータガバナンス(Account Mgmt & Governance, 20%)
🎯 この節の学習目標
Snowflakeの利用状況(クエリ履歴、ログイン履歴、クレジット消費など)を調べる方法は大きく2つあります。
SNOWFLAKE の中のスキーマで、アカウント全体のメタデータ・履歴ビューを提供します。既定ではACCOUNTADMINがアクセスでき、他ロールへは権限付与で開放できます同じ「QUERY_HISTORY」という名前でも、ACCOUNT_USAGEのビューとINFORMATION_SCHEMAのテーブル関数では性質が大きく異なります。この違いこそがこの節の核心です。
両者の違いは次の3軸で整理します。この表は確実に頭に入れてください。
| ACCOUNT_USAGE(SNOWFLAKEデータベース) | INFORMATION_SCHEMA(各データベース) | |
|---|---|---|
| データの遅延 | あり。ビューによって45分〜3時間程度(例:QUERY_HISTORYは45分程度、LOGIN_HISTORYは2時間程度) | なし。リアルタイムの情報が返る |
| 保持期間 | 365日(1年) | 短い。テーブル関数により7日〜6ヶ月(例:QUERY_HISTORY関数は7日) |
| ドロップ済みオブジェクト | 含まれる(DELETEDカラム等で判別できる) | 含まれない(現存するオブジェクトのみ) |
| 提供形態 | ビュー(アカウント全体が対象) | ビュー+テーブル関数(そのデータベース、または関数の引数で指定した範囲) |
📝 試験のポイント
「遅延・保持・ドロップ済み」の3点セットで対比して覚えます。ACCOUNT_USAGE=遅延あり・365日・ドロップ済みを含む、INFORMATION_SCHEMA=遅延なし・保持が短い・ドロップ済みを含まない。「たった今実行したクエリが見つからない」ならACCOUNT_USAGEの遅延が原因、「1ヶ月前のクエリを調べたいのに出てこない」ならINFORMATION_SCHEMAの保持期間切れが原因、という形でトラブルシューティングの文脈でも問われます。
目的別に代表的なものを整理します。名前と用途の対応付けができれば十分です。
| 名前 | 用途 | 備考 |
|---|---|---|
| QUERY_HISTORY | クエリの実行履歴(SQL文・実行時間・使用WH・実行ユーザーなど) | ACCOUNT_USAGEのビューと、INFORMATION_SCHEMAのテーブル関数の両方がある |
| LOGIN_HISTORY | ログインの成功・失敗の履歴(認証方式・接続元IPなど) | 不正アクセスの監査に使う。こちらもビューとテーブル関数の両方がある |
| COPY_HISTORY | COPY INTOやSnowpipeによるデータロードの履歴(ファイル名・行数・エラー) | ロードの成否確認・トラブルシューティングに使う |
| TASK_HISTORY | タスクの実行履歴(スケジュール実行の成否・実行時間) | パイプラインの監視に使う |
| WAREHOUSE_METERING_HISTORY | ウェアハウスごとのクレジット消費履歴 | コスト分析の基本(2-6参照) |
| ACCESS_HISTORY | 列レベルのアクセス監査・リネージ | ACCOUNT_USAGEのみに存在(2-4参照) |
💡 具体例:同じ「QUERY_HISTORY」の2つの書き方
-- (1) ACCOUNT_USAGEのビュー:過去365日・アカウント全体、ただし遅延あり
SELECT query_text, user_name, total_elapsed_time
FROM snowflake.account_usage.query_history
WHERE start_time >= DATEADD('day', -90, CURRENT_TIMESTAMP())
ORDER BY total_elapsed_time DESC;
-- (2) INFORMATION_SCHEMAのテーブル関数:遅延なし、ただし保持は7日
SELECT query_text, user_name, total_elapsed_time
FROM TABLE(my_db.information_schema.query_history(
end_time_range_start => DATEADD('hour', -1, CURRENT_TIMESTAMP()),
result_limit => 100
))
ORDER BY start_time DESC;テーブル関数は TABLE(...) で包んで呼び出し、引数で時間範囲や件数を指定します。「直近1時間のクエリを今すぐ調べたい」なら(2)、「四半期をまたいだ長期の傾向分析・監査」なら(1)が適切です。
SNOWFLAKEデータベースにはACCOUNT_USAGE以外にも関連スキーマがあります。存在と役割を知っておきましょう。
利用状況の監視と関連して、セキュリティ状態の監視にはSnowsightのTrust Centerが使えます。Trust Centerは、アカウントの設定をスキャナーパッケージに基づいて定期的にスキャンし、「MFAが未設定のユーザーがいる」「過剰な権限が付与されている」といったセキュリティリスクの検出と推奨事項の提示を行う機能です。利用状況(コスト・履歴)はACCOUNT_USAGE、セキュリティ態勢はTrust Center、という対応で覚えておきましょう。
要件からスキーマを選ぶ流れを図にまとめます。
図:スキーマ選択の判断フロー。「今すぐ・直近」ならINFORMATION_SCHEMA、「長期・監査・ドロップ済み」ならACCOUNT_USAGE
✅ この節のまとめ
問1. ACCOUNT_USAGEスキーマとINFORMATION_SCHEMAの違いとして正しいものはどれか。
正解:B
ACCOUNT_USAGEは「遅延あり(45分〜3時間)・保持365日・ドロップ済みを含む」が特徴です。Aは両者の遅延の特徴が逆です。Cは誤りで、遅延・保持・ドロップ済みの3軸で明確な違いがあります。DはACCOUNT_USAGEの特徴をINFORMATION_SCHEMAに付け替えており誤りです(INFORMATION_SCHEMAは保持が短く、ドロップ済みを含みません)。
問2. 数分前に実行したクエリの情報を今すぐ確認したい。最も適切な方法はどれか。
正解:B
直近のクエリをリアルタイムに調べるには、遅延のないINFORMATION_SCHEMAのQUERY_HISTORYテーブル関数が適切です。AのACCOUNT_USAGE版は45分程度の遅延があるため、数分前のクエリはまだ反映されていない可能性が高いです。CのACCESS_HISTORYはアクセス監査・リネージ用であり、しかもACCOUNT_USAGEなので遅延があります。DはBという即時の手段があるため誤りです(SnowsightのQuery Historyページでも確認できます)。
問3. INFORMATION_SCHEMAのQUERY_HISTORYテーブル関数で、10ヶ月前のクエリ履歴を取得しようとしたが返ってこない。原因として最も適切なものはどれか。
正解:A
INFORMATION_SCHEMAのQUERY_HISTORYテーブル関数の保持期間は7日で、それより古い履歴は取得できません。過去365日以内ならACCOUNT_USAGEのQUERY_HISTORYビューで確認できます(それでも10ヶ月前なら間に合います)。Bは誤りで、INFORMATION_SCHEMAは遅延なしが特徴です。Cは誤りで、実行に必要なのはACCOUNTADMINであることではなく適切な権限です。Dの「クエリがドロップ済み扱いになる」という概念は存在しません。
問4. 「組織内の複数アカウントのクレジット消費を横断的に確認したい」。使用すべきスキーマはどれか。
正解:B
組織内の全アカウントの利用状況・請求情報を横断的に見るにはORGANIZATION_USAGEスキーマを使います。AのINFORMATION_SCHEMAは各データベース(自アカウント内)のメタデータであり、他アカウントは対象外です。CのREADER_ACCOUNT_USAGEは自分が作成したリーダーアカウントの監視用で、組織内の通常アカウントの横断監視ではありません。DのPUBLICスキーマはデータベース作成時に既定で作られる普通のスキーマで、利用状況の監視とは無関係です。