クエリ パフォーマンスの最適化の概要
クエリの速度が想定よりも遅くなることがあります。一般的に、処理の少ないクエリほど優れたパフォーマンスを発揮します。実行時間が短く、より少ないリソースしか消費しないため、費用を削減でき、障害が減少します。このドキュメントでは、BigQuery でのクエリ パフォーマンスを向上できる最適化手法の概要を説明します。
クエリのパフォーマンス
BigQuery でのクエリのパフォーマンスの評価には、いくつかの要因が関わります。
- 入力データとデータソース(I/O): クエリで何バイト読み取るか。
- ノード間の通信(シャッフル): クエリから次の段階に何バイト転送するか。クエリは各スロットに何バイトずつ渡すか。
- コンピューティング: クエリにはどのくらいの CPU 作業が必要か。
- 出力(実体化): クエリは何バイト書き込むか。
- クエリのアンチパターン: クエリは SQL のベスト プラクティスに従っているか。
これらの質問の多くは、BigQuery でクエリを実行するたびに BigQuery が生成するクエリプランで回答されます。クエリプランには、読み取りバイト数や消費されたスロット時間など、実行統計が表示されます。また、実行のさまざまな段階を示し、クエリのパフォーマンスを診断して改善することもできます。クエリの診断の例などの詳細については、クエリプランとタイムラインをご覧ください。
他のシステムと同様に、パフォーマンスの最適化にもトレードオフが伴います。たとえば、高度な SQL 構文を使用すると、複雑さが増し、SQL の専門家ではないとクエリを理解できなくなる可能性もあります。また、重要ではないワークロードのマイクロ最適化に時間を費やすと、アプリケーションの新機能の構築や、より効果的な最適化を行うためのリソースが不足することになります。したがって、費用対効果を最大にするため、データ分析パイプラインで最も重要なワークロードの最適化に集中することをおすすめします。
スロットの競合が原因で、最適化されたクエリでも実行に時間がかかることがあります。たとえば、6 個のプロジェクトで使用できるスロットが 10,000 個ある場合、すべてのスロットで 2,000 個のスロットを使用できるわけではありません。これにより、クエリまたはジョブが遅くなる場合があります。クエリをさらに最適化できない場合は、予約の使用を検討してください。
特定のクエリに問題があるかどうかを評価するには、Cloud Monitoring を使用して、BigQuery ジョブによるリソースの消費状況をモニタリングします。低速またはリソースが集中しているクエリを特定したら、そのクエリにパフォーマンス最適化を集中できます。
容量と同時実行性
BigQuery は、SQL クエリの実行に必要な計算能力をスロットという単位に分解します。BigQuery は、クエリのサイズと複雑さに応じて、クエリに必要なスロット数を自動的に計算します。
BigQuery では、お客様の履歴、使用量、費用に基づいて、クエリを実行するスロットの割り当てを自動的に管理します。ほとんどのユーザーは、各プロジェクトのデフォルトのスロット容量で十分です。それ以上のスロットにアクセスしても、クエリごとのパフォーマンスが改善される保証はありません。ただし、スロットプールが大きければ、大規模で複雑なクエリのパフォーマンスが向上するとともに、同時実行数の多いワークロードのパフォーマンスも向上します。クエリのパフォーマンスをさらに向上させるには、データモデルとクエリの最適化を行うだけでなく、予約スロットの追加購入も検討する必要があります。
クエリに関して、BigQuery はオンデマンドと定額の 2 種類の料金モデルを提供します。オンデマンドの料金は、実行した各クエリで処理されたデータの量に基づいて計算されます。毎月の分析費用を一定にしたい場合は、定額料金が適しています。定額料金プランに加入する場合は、クエリ処理に使用する BigQuery スロットの割り当て数を購入します。処理データの費用はすべて月定額料金に含まれます。クエリが定額容量を超えた場合、定額リソースが使用可能になるまでクエリはキューに入れられます。
クエリプランとタイムライン
Google Cloud コンソールで BigQuery を使用すると、クエリのクエリプランとタイムラインを視覚的に確認できます。jobs.get
API メソッドを使用すると、クエリプランとタイムライン情報を取得できます。また、オープンソース ツールの BigQuery Visualiser で、BigQuery ジョブの実行ステージのフローを視覚的に表示することもできます。
BigQuery がクエリジョブを実行すると、宣言型の SQL ステートメントを実行グラフに変換し、一連のクエリステージに分割します。クエリステージは、より細かい実行ステップから構成されます。BigQuery は、高度に分散された並列アーキテクチャを利用して、これらのクエリを実行します。BigQuery ステージは、多くのワーカーを同時に実行できる作業単位をモデル化しています。ステージは、高速の分散シャッフル アーキテクチャを介して相互に通信を行います。
クエリプランに加えて、クエリジョブは実行のタイムラインを公開します。このタイムラインにより、クエリワーカー内で完了している作業単位、保留中の作業単位、アクティブな作業単位の数を確認できます。1 つのクエリで複数のステージが同時に処理される場合もあるため、タイムラインはクエリ全体の進行状況を把握する際に役立ちます。
クエリの計算コストは、クエリが 1 秒あたりに消費するスロット数の合計で判断します。1 秒間で消費されるスロット数が少ないほど、同じプロジェクトで同時に実行されている他のクエリがより多くのリソースを使用できることを意味します。
クエリプランとタイムラインの統計情報は、BigQuery でのクエリの実行状態や、特定のステージでのリソースの使用状況の把握に役立ちます。たとえば、JOIN
ステージで入力行よりも出力行が多い場合は、クエリの前にフィルタリングが必要かもしれません。ただし、サービスの管理特性のため、この情報をそのまま利用できるとは限りません。クエリの実行とパフォーマンスを改善するためのベスト プラクティスと手法については、[クエリ計算を最適化する] をご覧ください。
次のステップ
- BigQuery 監査ログを使用して、クエリの実行の問題のトラブルシューティング方法を学習する。
- BigQuery のその他の費用管理手法を学習する。
- BigQuery システム テーブル レポートを使用して、BigQuery の使用状況をモニタリングする方法を学習する。