メインコンテンツへスキップ
DataStoreプロファイラを使うと、実行時間を測定し、パフォーマンスのボトルネックを特定できます。

クイックスタート

プロファイリングの有効化


Profiler API

Profilerの取得

report()

パフォーマンスレポートを表示します。
パラメータ:
パラメータデフォルト説明
min_duration_msfloat0.1この時間以上のステップのみを表示
出力例:
レポートには次が表示されます。
  • 各ステップの所要時間 (ミリ秒)
  • 親/合計時間に占める割合
  • 操作の階層構造
  • 各ステップのメタデータ (例: ops_countops)

step()

コードブロックの実行時間を手動で計測します。

clear()

すべてのプロファイリングデータをクリアします。

summary()

ステップ名と所要時間 (ms) の対応を表す辞書を取得します。
出力例:

レポートを理解する

ステップ名

ステップ名説明
Total Execution全体の実行時間
Query Planningクエリのプランニングにかかった時間
SQL Segment NSQL セグメント N の実行
SQL Execution実際の SQL クエリの実行
Result to DataFrame結果を pandas の DataFrame に変換
Cache Checkクエリキャッシュの確認
Cache Write結果を cache に書き込み

実行時間

  • 計画ステップ (Query Planning): 通常は高速
  • 実行ステップ (SQL Execution): 実際の処理が行われる部分
  • 転送ステップ (Result to DataFrame): データを pandas に変換する部分

ボトルネックの特定


プロファイリングパターン

単一のクエリをプロファイリングする

複数クエリのプロファイリング

アプローチの比較


最適化のヒント

1. SQL実行時間を確認する

SQL execution がボトルネックになっている場合:
  • フィルターを追加してデータ量を減らす
  • CSV ではなく Parquet を使用する
  • 適切な索引が設定されているか確認する (データベースソースの場合)

2. I/O時間を確認する

read_csv または read_parquet がボトルネックになっている場合:
  • Parquet を使用する (列指向かつ圧縮可能)
  • 必要なカラムだけを読み取る
  • 可能であればソース側でフィルタする

3. データ転送を確認する

to_df が遅い場合:
  • 結果セットが大きすぎる可能性があります
  • フィルターを追加するか、件数を制限します
  • プレビューには head() を使用します

4. エンジンを比較する


ベストプラクティス

1. 最適化する前にプロファイリングを行う

2. テストごとにクリアする

3. Focus には min_duration_ms を使用する

4. 代表的なデータをプロファイリングする

5. 本番環境では無効化する


例: 完全なプロファイリングセッション

最終更新日 2026年7月2日