data-exploration

データ探索スキル

データセットのプロファイリング、データ品質の評価、パターンの発見、スキーマの把握を体系的に行うための方法論です。

データプロファイリングの方法論

フェーズ 1：構造の把握

データを分析する前に、その構造を把握します。

テーブルレベルの質問：

• 行と列はいくつありますか？
• 粒度はどのようになっていますか（1 行は何を表しますか）？
• 主キーは何ですか？一意ですか？
• データが最後に更新されたのはいつですか？
• データはどの時点までさかのぼりますか？

列の分類： 各列を以下のいずれかに分類します。

• 識別子：一意キー、外部キー、エンティティ ID
• ディメンション：グループ化やフィルタリングに使用するカテゴリ属性（ステータス、タイプ、地域、カテゴリ）
• メトリクス：測定対象となる定量値（売上、件数、期間、スコア）
• 時間：日付とタイムスタンプ（created_at、updated_at、event_date）
• テキスト：自由形式のテキストフィールド（description、notes、name）
• ブール値：真偽値フラグ
• 構造：JSON、配列、ネストされた構造

フェーズ 2：列レベルのプロファイリング

各列について、以下を計算します。

すべての列：

• NULL の件数と NULL 率
• 個別値の件数とカーディナリティ比（個別値の数 / 合計数）
• 最頻値（頻度付きで上位 5～10 件）
• 最少頻値（異常値を見つけるため、下位 5 件）

数値列（メトリクス）：

min, max, mean, median (p50)
standard deviation
percentiles: p1, p5, p25, p75, p95, p99
zero count
negative count (if unexpected)

文字列列（ディメンション、テキスト）：

min length, max length, avg length
empty string count
pattern analysis (do values follow a format?)
case consistency (all upper, all lower, mixed?)
leading/trailing whitespace count

日付／タイムスタンプ列：

min date, max date
null dates
future dates (if unexpected)
distribution by month/week
gaps in time series

ブール値列：

true count, false count, null count
true rate

フェーズ 3：関係性の発見

個々の列のプロファイリング後に、以下を確認します。

• 外部キー候補：ほかのテーブルとの関連付けに使える ID 列
• 階層：自然なドリルダウン経路を形成する列（国 > 州 > 都市）
• 相関：連動して変化する数値列
• 派生列：ほかの列から計算されていると思われる列
• 冗長な列：情報が同一またはほぼ同一の列

品質評価フレームワーク

完全性スコア

各列を評価します。

• 完全（NULL 以外が 99% 超）：緑
• おおむね完全（95～99%）：黄 — NULL 値を調査します
• 不完全（80～95%）：オレンジ — 理由と影響の有無を確認します
• 疎（80% 未満）：赤 — 補完しないと使用できない可能性があります

一貫性チェック

以下を確認します。

• 値の形式の不一致：同じ概念が異なる形式で表されている（「USA」、「US」、「United States」、「us」）
• 型の不一致：文字列として保存された数値、さまざまな形式の日付
• 参照整合性：どの親レコードとも一致しない外部キー
• ビジネスルール違反：負の数量、開始日より前の終了日、100 を超える割合
• 列間の一貫性：ステータスが「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]

**Description**: [What this table represents]
**Grain**: [One row per...]
**Primary Key**: [column(s)]
**Row Count**: [approximate, with date]
**Update Frequency**: [real-time / hourly / daily / weekly]
**Owner**: [team or person responsible]

### Key Columns

| Column | Type | Description | Example Values | Notes |
|--------|------|-------------|----------------|-------|
| user_id | STRING | Unique user identifier | "usr_abc123" | FK to users.id |
| event_type | STRING | Type of event | "click", "view", "purchase" | 15 distinct values |
| revenue | DECIMAL | Transaction revenue in USD | 29.99, 149.00 | Null for non-purchase events |
| created_at | TIMESTAMP | When the event occurred | 2024-01-15 14:23:01 | Partitioned on this column |

### Relationships
- Joins to `users` on `user_id`
- Joins to `products` on `product_id`
- Parent of `event_details` (1:many on event_id)

### Known Issues
- [List any known data quality issues]
- [Note any gotchas for analysts]

### Common Query Patterns
- [Typical use cases for this table]

スキーマ調査クエリ

データウェアハウスに接続している場合は、次のパターンを使ってスキーマを把握します。

-- List all tables in a schema (PostgreSQL)
SELECT table_name, table_type
FROM information_schema.tables
WHERE table_schema = 'public'
ORDER BY table_name;

-- Column details (PostgreSQL)
SELECT column_name, data_type, is_nullable, column_default
FROM information_schema.columns
WHERE table_name = 'my_table'
ORDER BY ordinal_position;

-- Table sizes (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;

-- Row counts for all tables (general pattern)
-- Run per-table: SELECT COUNT(*) FROM table_name

データリネージと依存関係

不慣れなデータ環境を調査する場合：

1. 「出力」テーブル（レポートやダッシュボードが利用するテーブル）から始めます
2. 上流をたどり、どのテーブルがデータを供給しているかを確認します
3. raw／staging／mart の各レイヤーを特定します
4. 生データから分析用テーブルまでの変換チェーンをマッピングします
5. データがエンリッチ化、フィルタリング、集計される箇所を記録します