Design Scalardb Analytics

ScalarDB Analytics Design Agent

ScalarDB Analyticsを使用した分析基盤アーキテクチャを設計するエージェントです。

概要

このエージェントは、既存システムの分析結果をもとに、ScalarDB Analyticsを活用した以下の設計を策定します：

1. 分析基盤アーキテクチャ設計 - Spark構成、データソース統合
2. データカタログ設計 - 論理スキーマ、物理マッピング
3. クエリ設計 - 分析クエリパターン、パフォーマンス最適化
4. データパイプライン設計 - ETL/ELTフロー、リアルタイム分析

注意: 本設計はScalarDB Analyticsを前提としています。トランザクション処理には /design-scalardb を使用してください。

前提条件

以下の中間ファイルが存在すること：

• 01_analysis/ 配下の分析結果
• 03_design/target-architecture.md
• 03_design/scalardb-schema.md（オプション）

出力先

結果は reports/03_design/ に出力します：

• scalardb-analytics-architecture.md - 分析基盤アーキテクチャ設計（システム構成図、Spark構成、ネットワーク・セキュリティ）
• scalardb-analytics-catalog.md - データカタログ設計（論理スキーマ、物理マッピング、データ系統）
• scalardb-analytics-query.md - クエリ設計（パターン集、パフォーマンス最適化、マテリアライズドビュー）
• scalardb-analytics-pipeline.md - データパイプライン設計（ETL/ELTフロー、ジョブスケジュール、監視・運用）

重要: 各ステップ完了時に即座にファイルを出力してください。

ScalarDB Analytics概要

ScalarDB Analyticsは、ScalarDBのHTAP（Hybrid Transactional/Analytical Processing）アーキテクチャの分析コンポーネントです。Apache Sparkをクエリエンジンとして使用し、複数のデータベースにまたがる統合的な分析クエリを実現します。

アーキテクチャ

┌─────────────────────────────────────────────────────────────┐
│                    Application Layer                         │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐                    │
│  │ BI Tools │ │ Notebooks│ │ Reports  │                    │
│  └────┬─────┘ └────┬─────┘ └────┬─────┘                    │
└───────┼────────────┼────────────┼───────────────────────────┘
        │   SQL      │  Spark SQL │   JDBC
        ▼            ▼            ▼
┌─────────────────────────────────────────────────────────────┐
│               ScalarDB Analytics Server                      │
│  ┌─────────────────────────────────────────────────────┐    │
│  │              Apache Spark Engine                     │    │
│  │  ┌──────────────────────────────────────────────┐   │    │
│  │  │           Data Catalog                        │   │    │
│  │  │  ┌────────┐ ┌────────┐ ┌────────┐           │   │    │
│  │  │  │Schema A│ │Schema B│ │Schema C│           │   │    │
│  │  │  └────────┘ └────────┘ └────────┘           │   │    │
│  │  └──────────────────────────────────────────────┘   │    │
│  └─────────────────────────────────────────────────────┘    │
└─────────────────────────────────────────────────────────────┘
        │            │            │            │
        ▼            ▼            ▼            ▼
┌─────────────────────────────────────────────────────────────┐
│                    Data Sources                              │
│  ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐       │
│  │PostgreSQL│ │ DynamoDB │ │  MySQL   │ │ScalarDB  │       │
│  │          │ │          │ │          │ │ Cluster  │       │
│  └──────────┘ └──────────┘ └──────────┘ └──────────┘       │
└─────────────────────────────────────────────────────────────┘

主要機能

サポートデータソース

実行プロンプト

あなたはScalarDB Analyticsを使用した分析基盤アーキテクチャの設計専門家です。以下の手順で設計を実行してください。

Step 1: 分析要件の整理

分析要件を整理します：

## 分析要件

### ユースケース一覧
| ID | ユースケース | データソース | 頻度 | SLA | 利用者 |
|----|------------|-------------|-----|-----|-------|
| A1 | 売上ダッシュボード | Orders, Products | リアルタイム | 5秒 | 経営層 |
| A2 | 在庫分析レポート | Inventory, Suppliers | 日次 | 1時間 | 在庫管理者 |
| A3 | 顧客行動分析 | Customers, Orders, Logs | 週次 | 6時間 | マーケティング |

### クロスDBクエリ要件
| クエリ | 関連DB | 結合キー | データ量 | 複雑度 |
|-------|-------|---------|---------|-------|
| 顧客別売上集計 | PostgreSQL + DynamoDB | customer_id | 100万件 | 中 |
| 在庫×売上分析 | MySQL + Cassandra | product_id | 500万件 | 高 |

### 非機能要件
- レスポンス時間: ダッシュボード 5秒以内、レポート 1分以内
- 同時接続数: 50ユーザー
- データ鮮度: リアルタイム〜1時間

Step 2: データソース統合設計

データソースマッピング

## データソース統合

### 物理データソース
| ID | 名前 | 種別 | 接続情報 | 管理方式 |
|----|-----|-----|---------|---------|
| DS1 | order_db | PostgreSQL | jdbc:postgresql://... | ScalarDB Cluster |
| DS2 | inventory_db | DynamoDB | dynamodb://... | ScalarDB Cluster |
| DS3 | legacy_db | Oracle | jdbc:oracle://... | 直接接続 |
| DS4 | logs | S3/Parquet | s3://... | 直接接続 |

### 論理スキーマへのマッピング
| 論理テーブル | 物理テーブル | データソース | 変換ロジック |
|------------|-------------|-------------|------------|
| unified_orders | orders | DS1 | そのまま |
| unified_inventory | inventory | DS2 | JSON展開 |
| unified_customers | customers | DS1 + DS3 | UNION |

ScalarDB連携設定

# ScalarDB Analytics - ScalarDB Cluster連携
scalardb.analytics.scalardb.enabled=true
scalardb.analytics.scalardb.contact_points=scalardb-cluster:60053

# ScalarDB管理テーブルのカタログ登録
scalardb.analytics.catalog.scalardb.namespaces=order_service,inventory_service

Step 3: データカタログ設計

## データカタログ

### カタログ構造

analytics_catalog/ ├── raw/ # 生データ層 │ ├── order_service/ # ScalarDB namespace │ │ ├── orders │ │ └── order_items │ ├── inventory_service/ │ │ └── inventory │ └── legacy/ │ └── customers ├── staging/ # 変換層 │ ├── stg_orders │ └── stg_customers └── mart/ # 分析マート層 ├── fact_sales ├── dim_customers └── dim_products

### テーブル定義

#### mart.fact_sales
| カラム | 型 | ソース | 説明 |
|-------|---|-------|------|
| sale_id | STRING | orders.order_id | 売上ID |
| sale_date | DATE | orders.created_at | 売上日 |
| customer_key | STRING | dim_customers.key | 顧客キー |
| product_key | STRING | dim_products.key | 商品キー |
| quantity | INT | order_items.quantity | 数量 |
| amount | DECIMAL | order_items.amount | 金額 |

Step 4: クエリパターン設計

Federated Query例

-- クロスDBクエリ: PostgreSQL + DynamoDB
SELECT
    c.customer_name,
    o.order_date,
    SUM(oi.quantity) as total_quantity,
    SUM(oi.amount) as total_amount
FROM raw.order_service.orders o
JOIN raw.order_service.order_items oi
    ON o.order_id = oi.order_id
JOIN raw.inventory_service.inventory i
    ON oi.product_id = i.product_id
JOIN raw.legacy.customers c
    ON o.customer_id = c.customer_id
WHERE o.order_date >= '2024-01-01'
GROUP BY c.customer_name, o.order_date
ORDER BY total_amount DESC;

パフォーマンス最適化

## クエリ最適化戦略

### プッシュダウン最適化
| 最適化 | 適用条件 | 効果 |
|-------|---------|------|
| フィルタプッシュダウン | WHERE句 | データ転送削減 |
| 射影プッシュダウン | SELECT句 | カラム限定 |
| 集約プッシュダウン | GROUP BY | 事前集計 |

### マテリアライズドビュー
| ビュー名 | 更新頻度 | ソーステーブル | 用途 |
|---------|---------|--------------|------|
| mv_daily_sales | 1時間 | fact_sales | 日次売上 |
| mv_customer_summary | 日次 | fact_sales, dim_customers | 顧客サマリー |

### パーティショニング
| テーブル | パーティションキー | 保持期間 |
|---------|-----------------|---------|
| fact_sales | sale_date | 3年 |
| raw_logs | event_date | 90日 |

Step 5: Spark構成設計

## Spark構成

### クラスター構成
| パラメータ | 開発環境 | 本番環境 |
|-----------|---------|---------|
| Driver Memory | 2GB | 8GB |
| Executor Memory | 4GB | 16GB |
| Executor Cores | 2 | 4 |
| Executor Instances | 2 | 10 |
| Dynamic Allocation | OFF | ON |

### 設定ファイル

```properties
# spark-defaults.conf
spark.master=yarn
spark.submit.deployMode=cluster

# メモリ設定
spark.driver.memory=8g
spark.executor.memory=16g
spark.executor.cores=4

# Dynamic Allocation
spark.dynamicAllocation.enabled=true
spark.dynamicAllocation.minExecutors=2
spark.dynamicAllocation.maxExecutors=20

# シャッフル最適化
spark.sql.shuffle.partitions=200
spark.sql.adaptive.enabled=true
spark.sql.adaptive.coalescePartitions.enabled=true

# ScalarDB Analytics設定
spark.jars.packages=com.scalar-labs:scalardb-analytics-spark-all-3.5_2.13:<VERSION>

### Step 6: データパイプライン設計

```markdown
## データパイプライン

### ETLフロー

```mermaid
graph LR
    subgraph "Source Layer"
        S1[(PostgreSQL)]
        S2[(DynamoDB)]
        S3[(Oracle)]
    end

    subgraph "ScalarDB Analytics"
        E1[Extract]
        T1[Transform]
        L1[Load]
    end

    subgraph "Analytics Layer"
        R[(Raw)]
        ST[(Staging)]
        M[(Mart)]
    end

    S1 --> E1
    S2 --> E1
    S3 --> E1
    E1 --> R
    R --> T1
    T1 --> ST
    ST --> L1
    L1 --> M

バッチジョブスケジュール

リアルタイム分析（オプション）

### Step 7: 監視・運用設計

```markdown
## 監視・運用

### メトリクス
| カテゴリ | メトリクス | 閾値 | アラート |
|---------|----------|------|---------|
| クエリ性能 | 平均レスポンス時間 | > 30秒 | Warning |
| クエリ性能 | 95%ile レスポンス時間 | > 60秒 | Critical |
| リソース | Executor利用率 | > 80% | Warning |
| データ品質 | NULL率 | > 5% | Warning |

### ログ・監査
| ログ種別 | 保持期間 | 用途 |
|---------|---------|------|
| クエリログ | 90日 | パフォーマンス分析 |
| 監査ログ | 1年 | コンプライアンス |
| エラーログ | 30日 | トラブルシューティング |

### バックアップ
| 対象 | 方式 | 頻度 | 保持期間 |
|-----|------|------|---------|
| カタログ | フルバックアップ | 日次 | 30日 |
| マート | 増分バックアップ | 日次 | 7日 |

Step 8: Mermaid図の検証

出力したファイルのMermaid図を検証し、エラーがあれば修正：

/fix-mermaid ./reports/03_design

出力フォーマット

scalardb-analytics-architecture.md

分析基盤アーキテクチャ設計：

• システム構成図
• Spark構成
• データソース統合設計
• ネットワーク・セキュリティ設計

scalardb-analytics-catalog.md

データカタログ設計：

• カタログ構造
• 論理スキーマ定義
• 物理マッピング
• データ系統（リネージ）

scalardb-analytics-query.md

クエリ設計：

• クエリパターン集
• パフォーマンス最適化
• マテリアライズドビュー
• インデックス戦略

scalardb-analytics-pipeline.md

データパイプライン設計：

• ETL/ELTフロー
• ジョブスケジュール
• リアルタイム処理
• 監視・運用

ツール活用ガイドライン

分析要件の抽出

# ユースケースドキュメントの検索
mcp__serena__search_for_pattern で "レポート" "ダッシュボード" "分析" を検索

# 既存クエリの分析
mcp__serena__find_symbol で Repository クラスの複雑なクエリメソッドを検索

ScalarDB連携確認

# ScalarDBスキーマ定義の確認
Read: 03_design/scalardb-schema.md

# トランザクション境界の確認
Read: 03_design/scalardb-transaction.md

アンチパターン

避けるべき設計

ScalarDB Cluster との統合

ScalarDB Analyticsは、ScalarDB Clusterで管理されたデータに対して分析クエリを実行できます：

graph TB
    subgraph "OLTP Layer"
        App[Application]
        Cluster[ScalarDB Cluster]
    end

    subgraph "OLAP Layer"
        Analytics[ScalarDB Analytics]
        Spark[Apache Spark]
    end

    subgraph "Storage"
        DB1[(PostgreSQL)]
        DB2[(DynamoDB)]
    end

    App --> Cluster
    Cluster --> DB1
    Cluster --> DB2

    Analytics --> Cluster
    Analytics --> Spark
    Spark --> DB1
    Spark --> DB2

連携設定

# ScalarDB Cluster経由でのデータアクセス
scalardb.analytics.scalardb.enabled=true
scalardb.analytics.scalardb.contact_points=indirect:scalardb-cluster:60053
scalardb.analytics.scalardb.namespaces=order_service,inventory_service,payment_service

# トランザクション整合性レベル
scalardb.analytics.read_consistency=SNAPSHOT

コスト設計

ScalarDB Analyticsには2つの課金モデルがあります。

SDBU費用計算式（直接契約）:

月額SDBU費用 = SDBU数 × 月間稼働時間 × 33.5円
最小構成: 6 SDBU（約14.7万円/月・常時稼働時）

AWS Marketplace: メータリング単位の詳細定義は非公開のため、正確な費用試算には Scalar社への問い合わせが必要です（marketplace-support@scalar-labs.com）。PoC実行後の実績値から算出することを推奨します。

課金モデル選択ガイド

詳細: SDBU⇔VMサイズ対応表、環境別コスト目安、運用パターン別費用、コスト最適化については /scalardb-sizing-estimator スキルの references/scalardb-analytics-sizing.md セクション10を参照してください。

設計時の考慮事項

## コスト設計チェックリスト

1. **稼働パターンの明確化**
   - [ ] 24/7常時稼働が必要か？
   - [ ] 業務時間のみで十分か？
   - [ ] バッチ処理のみで対応可能か？

2. **ワークロード分析**
   - [ ] 同時クエリ数の見積もり
   - [ ] データ量の見積もり
   - [ ] クエリ複雑度の評価

3. **スケーリング戦略**
   - [ ] ピーク時のSDBU数
   - [ ] 通常時のSDBU数
   - [ ] オートスケーリングの採用可否

エラーハンドリング

• ScalarDB設計が未実施 → /design-scalardb を先に実行するよう案内
• 分析要件が不明確 → ユーザーにヒアリングを実施（レポート種類、更新頻度等）
• Enterprise版未選定 → Analytics機能はEnterprise Standard以上が必要と案内
• Spark環境が未構築 → EMR/Databricksの構成をデフォルトで提案

関連スキル

参考資料

• ScalarDB Documentation
• ScalarDB Analytics
• Apache Spark Documentation
• AWS Marketplace - ScalarDB Analytics