分析パフォーマンスを最適化する

Last reviewed 2023-08-04 UTC

Google Cloud アーキテクチャ フレームワークのこのドキュメントでは、Google Cloud の分析ワークロードのパフォーマンスを最適化するための推奨事項について説明します。

BigQuery

このセクションでは、BigQuery でクエリのパフォーマンスを最適化するための推奨事項について説明します。

クエリデザインを最適化する

クエリのパフォーマンスは、クエリで読み書きされるバイト数や、スロット間で渡されるデータ量などの要因によって異なります。BigQuery でクエリのパフォーマンスを最適化するには、次のドキュメントをご覧ください。

マテリアライズド ビューを効率的に定義して使用する

一般的なクエリや繰り返しクエリを使用するワークロードのパフォーマンスを向上させるには、マテリアライズド ビューを使用します。作成できるマテリアライズド ビューの数には上限があります。クエリを置換するたびに、マテリアライズド ビューを個別に作成しないでください。代わりに、クエリの複数のパターンに使用できるマテリアライズド ビューを定義します。

JOIN のパフォーマンスを改善する

マテリアライズド ビューを使用すると、JOIN 上で集計を行うクエリのコストとレイテンシを低減できます。大きなファクト テーブルをいくつかの小さなディメンション テーブルと結合してから、それを基に集計を行う場合を考えてみます。次のようにクエリを書き換えると実用的になる可能性があります。まず外部キーをグループ化キーとして使用して、ファクト テーブル上で集計を行います。次に、その結果をディメンション テーブルと結合します。最後に事後集計を行います。

Dataflow

このセクションでは、Dataflow パイプラインのクエリ パフォーマンスを最適化するための推奨事項について説明します。

パイプラインを作成してデプロイするときに、Dataflow ワーカー VM に使用する Compute Engine マシンタイプなどの実行パラメータを構成できます。詳細については、パイプライン オプションをご覧ください。

パイプラインをデプロイすると、ジョブの実行に必要な Compute Engine リソースと Cloud Storage リソースを Dataflow が管理します。また、Dataflow の次の機能は、パイプラインのパフォーマンスの最適化に役立ちます。

  • 並列化: Dataflow は、データを自動的に分割し、並列処理のためにワーカーコードを Compute Engine インスタンスに分散します。詳細については、並列化と分散をご覧ください。
  • 最適化: Dataflow はパイプライン コードを使用して、PCollection オブジェクトとパイプライン内の変換を表す実行グラフを作成します。次に、最も効率的なパフォーマンスとリソース使用率を実現するためにグラフを最適化します。Dataflow は、データ集計など、コストがかかる可能性のある操作も自動的に最適化します。詳細については、融合の最適化結合の最適化をご覧ください。
  • 自動調整: Dataflow は、水平自動スケーリング垂直自動スケーリング動的作業再調整の実行時に動的にジョブを最適化します。

ウェブベースのモニタリング インターフェースまたは Dataflow gcloud CLI を使用して、Dataflow パイプラインのパフォーマンスをモニタリングできます。

Dataproc

このセクションでは、Dataproc クラスタのパフォーマンスを最適化するためのベスト プラクティスについて説明します。

クラスタの自動スケール

Dataproc クラスタで安定したパフォーマンスを提供するには、自動スケーリングを有効にします。Dataproc は、Hadoop YARN メモリ指標と、クラスタ内のワーカー VM の数を自動的に調整するために定義した自動スケーリング ポリシーを使用します。自動スケーリングの使用方法と構成方法については、クラスタの自動スケーリングをご覧ください。

適切なストレージをプロビジョニングする

パフォーマンスとコストの要件に基づいて、Dataproc クラスタに適したストレージ オプションを選択します。

  • 最小限の変更で、Hadoop と Spark のジョブで読み取り/書き込みを行える低コストの Hadoop 互換ファイル システム(HCFS)が必要な場合は、Cloud Storage を使用します。Cloud Storage に格納されたデータは永続的であり、他の Dataproc クラスタや他のプロダクト(BigQuery など)からアクセスできます。
  • Dataproc クラスタに低レイテンシの Hadoop 分散ファイル システム(HDFS)が必要な場合は、ワーカーノードにアタッチされた Compute Engine 永続ディスクを使用します。HDFS ストレージに格納されるデータは一時的なものであり、Cloud Storage のオプションよりもストレージ コストが高くなります。
  • Compute Engine 永続ディスクのパフォーマンス上のメリットと、Cloud Storage がもたらすコストと耐久性のメリットを得るために、両方のストレージ オプションを組み合わせることができます。たとえば、ソース データセットと最終データセットを Cloud Storage に保存し、中間データセットに対して制限付きの HDFS 容量をプロビジョニングできます。HDFS ストレージのディスクのサイズとタイプを決定する場合は、永続ディスクとローカル SSD セクションの推奨事項を検討してください。

Cloud Storage 使用時のレイテンシを短縮する

Cloud Storage に保存されているデータにアクセスする際のレイテンシを短縮するには、次のことをおすすめします。

  • Dataproc クラスタと同じリージョンに Cloud Storage バケットを作成します。
  • Cloud Storage に保存されている Apache Hive 管理のテーブルに対して、auto.purge を無効にします。
  • Spark SQL を使用する場合は、利用可能な最新バージョンのイメージを使用して Dataproc クラスタを作成することを検討してください。最新バージョンを使用することで、Spark 2.x の INSERT OVERWRITE のパフォーマンスが低いなど、古いバージョンに残っている可能性のあるパフォーマンスの問題を回避できます。
  • さまざまなサイズまたは小さなサイズの多数のファイルを Cloud Storage に書き込む可能性を最小限に抑えるには、Spark SQL パラメータspark.sql.shuffle.partitionsspark.default.parallelism または Hadoop パラメータ mapreduce.job.reduces を構成します。

ストレージの負荷と容量をモニタリングして調整する

Dataproc クラスタのワーカーノードにアタッチされている永続ディスクは、シャッフル データを保持しています。最適なパフォーマンスを得るには、ワーカーノードに十分なディスク容量が必要です。ノードに十分なディスク容量がない場合、YARN NodeManager ログでノードに UNHEALTHY とマークされます。この問題が発生した場合は、影響を受けるノードのディスクサイズを増やすか、同時に実行するジョブを減らします。

EFM を有効にする

ダウンスケーリングやプリエンプションなどにより、実行中の Dataproc クラスタからワーカーノードが削除されると、シャッフル データが失われる可能性があります。このような場合でのジョブの遅延を最小限に抑えるには、プリエンプティブル VM を使用するクラスタ、またはセカンダリ ワーカー グループのみを自動スケールするクラスタで、高度な柔軟性モード(EFM)を有効にすることをおすすめします。

次のステップ

コンピューティング リソース、ストレージ リソース、ネットワーキング リソース、データベース リソースのパフォーマンスを最適化するためのベスト プラクティスを確認します。