/explore-data - データセットのプロファイルと探索

不明なプレースホルダーが表示される場合や、接続されているツールを確認する必要がある場合は、CONNECTORS.md を参照してください。

テーブルまたはアップロードされたファイルの包括的なデータプロファイルを生成します。分析に入る前に、その形状、品質、パターンを理解します。

使い方

/explore-data <table_name or file>

ワークフロー

1. データにアクセス

データウェアハウスの MCP サーバーが接続されている場合:

1. テーブル名を解決する(スキーマプレフィックスを処理し、曖昧な場合は一致を提案)
2. テーブルメタデータをクエリする: 列名、型、利用可能な説明
3. ライブデータに対してプロファイリングクエリを実行

ファイルが提供されている場合(CSV、Excel、Parquet、JSON):

1. ファイルを読み込み、作業用データセットにロード
2. データから列型を推論

どちらでもない場合:

1. ユーザーにテーブル名(ウェアハウスが接続されている状態)の提供またはファイルのアップロードをお願い
2. テーブルスキーマについての説明が提供される場合は、実行すべきプロファイリングクエリについてガイダンスを提供

2. 構造を理解

データを分析する前に、その構造を理解します:

テーブルレベルの質問:

• 行数と列数は?
• グレイン(1行は何を表すか)は?
• プライマリキーは何か? ユニークか?
• データが最後に更新されたのはいつか?
• データはどのくらい過去まで遡るか?

列の分類 — 各列を次のいずれかに分類:

• 識別子: ユニークキー、外部キー、エンティティ ID
• ディメンション: グループ化・フィルタリング用のカテゴリ属性(ステータス、タイプ、地域、カテゴリ)
• メトリクス: 測定用の定量値(収益、カウント、期間、スコア)
• 時間軸: 日付とタイムスタンプ(created_at、updated_at、event_date)
• テキスト: 自由形式のテキストフィールド(説明、ノート、名前)
• ブール値: 真偽フラグ
• 構造: JSON、配列、ネストされた構造

3. データプロファイルを生成

以下のプロファイリングチェックを実行:

テーブルレベルのメトリクス:

• 総行数
• 列数と型の内訳
• 概算テーブルサイズ(メタデータから利用可能な場合)
• 日付範囲のカバレッジ(日付列の最小/最大)

すべての列:

• Null カウントと Null レート
• 異なる値のカウントと基数比(異なる値 / 総数)
• 最も一般的な値(上位 5-10 の頻度付き)
• 最も一般的でない値(下位 5 で異常を発見)

数値列(メトリクス):

最小値、最大値、平均値、中央値 (p50)
標準偏差
パーセンタイル: p1, p5, p25, p75, p95, p99
ゼロカウント
負のカウント(予期していない場合)

文字列列(ディメンション、テキスト):

最小長、最大長、平均長
空の文字列カウント
パターン分析(値が形式に従っているか?)
大文字と小文字の一貫性(すべて大文字、すべて小文字、混在?)
先頭/末尾の空白カウント

日付/タイムスタンプ列:

最小日付、最大日付
Null の日付
未来の日付(予期していない場合)
月/週による分布
時系列のギャップ

ブール値列:

真カウント、偽カウント、Null カウント
真レート

プロファイルをきれいなサマリテーブルとして表示, 列型別にグループ化(ディメンション、メトリクス、日付、ID)。

4. データ品質の問題を特定

以下の品質評価フレームワークを適用します。潜在的な問題をフラグ:

• Null レートが高い: Null が 5% 超の列(警告)、Null が 20% 超の列(アラート)
• 基数の予期しない低さ: 高い基数であるべき列が高くない(例:"user_id" が異なる値 50 のみ)
• 基数の予期しない高さ: カテゴリである場合が高いが、異なる値が多すぎる
• 疑わしい値: 正数のみ予期される場所での負額、過去のデータ内での未来の日付、明らかなプレースホルダー値(例: "N/A"、"TBD"、"test"、"999999")
• 重複検出: 自然なキーがあるか、重複があるか確認
• 分布の歪み: 平均値に影響を与える可能性のある極端に歪んだ数値分布
• エンコーディングの問題: カテゴリフィールドの大文字と小文字の混在、末尾の空白、一貫性のない形式

5. 関係性とパターンを発見

個別列のプロファイリング後:

• 外部キーの候補: 他のテーブルへのリンク可能性がある ID 列
• 階層: 自然なドリルダウンパスを形成する列(国 > 州 > 都市)
• 相関関係: 一緒に変動する数値列
• 導出列: 他の列から計算されているように見える列
• 冗長列: 同一またはほぼ同一の情報を持つ列

6. 興味深いディメンションとメトリクスを提案

列プロファイルに基づいて、以下を推奨:

• 最適なディメンション列 でデータをスライス(カテゴリ列で合理的な基数、3-50 値)
• 重要なメトリクス列 で測定(意味のある分布を持つ数値列)
• トレンド分析に適した時間列
• 自然なグループ化 またはデータに見られる階層
• 他のテーブルにリンクする可能性のあるジョインキー(ID 列、外部キー)

7. フォローアップ分析を推奨

次に実行できる 3-5 の具体的な分析を提案:

• "[time_column] で [metric] のトレンド分析、[dimension] で グループ化"
• "[skewed_column] での分布の詳細調査、アウトライアーを理解するため"
• "[problematic_column] でのデータ品質調査"
• "[metric_a] と [metric_b] 間の相関分析"
• "[date_column] と [status_column] を使用したコホート分析"

出力形式

## Data Profile: [table_name]

### Overview
- 行: 2,340,891
- 列: 23 (8 ディメンション、6 メトリクス、4 日付、5 ID)
- 日付範囲: 2021-03-15 から 2024-01-22

### Column Details
[サマリテーブル]

### Data Quality Issues
[重大度付きでフラグされた問題]

### Recommended Explorations
[推奨フォローアップ分析の番号付きリスト]

---

品質評価フレームワーク

完全性スコア

各列を評価:

• 完全 (>99% の非Null): 緑
• ほぼ完全 (95-99%): 黄 -- Null を調査
• 不完全 (80-95%): オレンジ -- 理由を理解し、それが重要かどうか確認
• スパース (<80%): 赤 -- インプテーション なしで使用可能でない場合がある

一貫性チェック

以下を確認:

• 値の形式の不一貫性: 同じ概念が異なる表現("USA"、"US"、"United States"、"us")
• 型の不一貫性: 文字列として格納された数字、様々な形式の日付
• 参照整合性: 親レコードと一致しない外部キー
• ビジネスルール違反: 負の数量、終了日が開始日より前、100% を超えるパーセンテージ
• クロス列の一貫性: Status = "completed" だが completed_at が Null

精度インジケーター

精度の問題を示唆する危険な兆候:

• プレースホルダー値: 0、-1、999999、"N/A"、"TBD"、"test"、"xxx"
• デフォルト値: 疑わしく高い単一値の頻度
• 古いデータ: Updated_at がアクティブなシステムで最近の変更を示していない
• 不可能な値: 150 歳を超える年齢、遠い未来の日付、負の期間
• 丸い数字のバイアス: すべての値が 0 または 5 で終わる(測定ではなく推定を示唆)

時間性の評価

• テーブルが最後に更新されたのはいつか?
• 予期される更新頻度は?
• イベント時間とロード時間の間にラグがあるか?
• 時系列にギャップがあるか?

パターン発見テクニック

分布分析

数値列については、分布を特徴付け:

• 正規: 平均値と中央値が接近、ベル形状
• 右スキュー: 高い値の長い裾(収益、セッション期間に一般的)
• 左スキュー: 低い値の長い裾(より稀)
• 二峰性: 2 つのピーク(2 つの異なる母集団を示唆)
• べき乗則: いくつかの非常に大きい値、多くの小さい値(ユーザー活動に一般的)
• 均一: 範囲全体でほぼ等しい頻度(合成またはランダムが多い)

時間パターン

時系列データについて確認:

• トレンド: 持続的な上昇または下降の動き
• 季節性: 繰り返すパターン(週単位、月単位、四半期単位、年単位)
• 曜日効果: 平日と週末の違い
• 休日効果: 既知の休日の周辺での低下またはスパイク
• 変化点: レベルまたはトレンドの急激なシフト
• 異常: パターンを破る個別のデータポイント

セグメンテーション発見

自然なセグメントを特定:

• 3-20 の異なる値を持つカテゴリ列を検索
• セグメント値全体でのメトリクス分布を比較
• 大きく異なる動作を持つセグメントを確認
• セグメントが均質であるか、サブセグメントを含むかをテスト

相関探索

数値列間:

• すべてのメトリクスペア間の相関行列を計算
• 強い相関(|r| > 0.7)をフラグして調査
• 注: 相関は因果関係を意味しない -- 明示的にフラグ
• 非線形関係をチェック(例: 二次、対数)

スキーマの理解とドキュメント化

スキーマドキュメント化テンプレート

チーム使用用にデータセットをドキュメント化する場合:

## Table: [schema.table_name]

**説明**: [このテーブルが表すもの]
**グレイン**: [1行あたり...]
**プライマリキー**: [列]
**行数**: [概算、日付付き]
**更新頻度**: [リアルタイム / 時間単位 / 日単位 / 週単位]
**所有者**: [責任者またはチーム]

### キー列

| 列 | 型 | 説明 | 値の例 | 備考 |
|--------|------|-------------|----------------|-------|
| user_id | STRING | ユニークユーザー識別子 | "usr_abc123" | FK to users.id |
| event_type | STRING | イベントの種類 | "click", "view", "purchase" | 15 の異なる値 |
| revenue | DECIMAL | トランザクション収益(USD) | 29.99, 149.00 | 非購入イベントでは Null |
| created_at | TIMESTAMP | イベント発生時刻 | 2024-01-15 14:23:01 | この列でパーティション化 |

### 関係性
- user_id で users にジョイン
- product_id で products にジョイン
- event_details の親(event_id で 1:多)

### 既知の問題
- [既知のデータ品質の問題をリスト]
- [アナリスト向けの注意点をメモ]

### 一般的なクエリパターン
- [このテーブルの典型的なユースケース]

スキーマ探索クエリ

データウェアハウスに接続されている場合、これらのパターンを使用してスキーマを発見:

-- スキーマ内のすべてのテーブルをリスト (PostgreSQL)
SELECT table_name, table_type
FROM information_schema.tables
WHERE table_schema = 'public'
ORDER BY table_name;

-- 列の詳細 (PostgreSQL)
SELECT column_name, data_type, is_nullable, column_default
FROM information_schema.columns
WHERE table_name = 'my_table'
ORDER BY ordinal_position;

-- テーブルサイズ (PostgreSQL)
SELECT relname, pg_size_pretty(pg_total_relation_size(relid))
FROM pg_catalog.pg_statio_user_tables
ORDER BY pg_total_relation_size(relid) DESC;

-- すべてのテーブルの行数(一般的なパターン)
-- テーブルごと実行: SELECT COUNT(*) FROM table_name

系統と依存関係

不明なデータ環境を探索する場合:

1. 「出力」テーブルから始める(どのレポートやダッシュボードが使用するか)
2. アップストリームを追跡: それらを供給するテーブルは?
3. 生データ/ステージング/マート層を特定
4. 生データから分析テーブルへの変換チェーンをマップ
5. データが充実、フィルタリング、または集約されている場所をメモ

ヒント

• 非常に大きなテーブル(1 億行以上)の場合、プロファイリングクエリはデフォルトでサンプリングを使用 -- 正確なカウントが必要な場合は言及
• 初めて新しいデータセットを探索する場合、このコマンドは特定のクエリを書く前に全体像を把握します
• 品質フラグはヒューリスティック -- すべてのフラグが実際の問題ではありませんが、それぞれが簡単に確認する価値があります