Explore クエリ トラッカーと Explore の [パフォーマンス] パネルには、Explore クエリのパフォーマンス データがステップごとに表示されます。このデータは、クエリのパフォーマンスの問題のトラブルシューティングと解決のための重要なエントリ ポイントを特定し、改善のための推奨事項を提供するのに役立ちます。
クエリ トラッカーを調べる
Explore クエリ トラッカーには、クエリの実行中に クエリの 3 つのフェーズを通過する Explore クエリの進行状況が表示されます。
クエリの実行に時間がかかる場合、クエリ トラッカーは、クエリのどのフェーズでパフォーマンスの問題が発生しているかを示すことができます。これは、パフォーマンスの問題が発生する可能性のある場所や、最適化の取り組みが最も効果的な場所を特定するのに役立ちます。
Explore の [可視化] パネルまたは Explore の [データ] パネルのいずれかが開いている場合、Explore の実行中にクエリ トラッカーが表示されます。
[パフォーマンス] パネルを確認する
[パフォーマンス] Explore パネルを表示するには、実行された Explore クエリで使用可能な [パフォーマンスの詳細を表示] リンクをクリックします。
[パフォーマンス] パネルには、クエリが 3 つのクエリフェーズのそれぞれで費やした時間が表示されます。また、パフォーマンスに関するドキュメントと クエリ履歴システム アクティビティ ダッシュボードへのリンクも含まれています。このダッシュボードには、クエリとクエリの作成に使用された Explore の現在と過去のパフォーマンス データが表示されます。
クエリフェーズ
Looker の Explore がデータベース クエリを実行すると、クエリは次の 3 つのフェーズで実行されます。
クエリの初期化フェーズ
クエリの初期化フェーズでは、クエリがデータベースに送信される前に必要なすべてのタスクを Looker が行います。[クエリの初期化] フェーズには、次のタスクが含まれます。
- LookML モデルをコンパイルする
- 永続的な派生テーブル（PDT）を作成する必要があるかどうかの確認
- クエリ SQL の生成
- データベース接続を取得する
ドキュメント ページ クエリのパフォーマンス指標を把握するでは、システム アクティビティのクエリ パフォーマンス指標 Explore を使用して、クエリの詳細な内訳を確認する方法について説明しています。クエリ トラッカーのクエリの初期化フェーズには、クエリ パフォーマンス指標 Explore の非同期ワーカー フェーズ、初期化フェーズ、接続処理フェーズで説明されているイベントが含まれます。
クエリ実行フェーズ
クエリの実行フェーズは、Looker がデータベースに接続してクエリを実行し、クエリの結果を返すフェーズです。このフェーズでパフォーマンスの問題が発生した場合は、外部データベースに問題がある可能性があります。たとえば、再構築に時間がかかる PDT がある場合は、最適化が必要になることがあります。また、外部データベース テーブルの最適化が必要になることもあります。[Running Query] フェーズには、次のタスクが含まれます。
- Explore クエリに必要なデータベース内の PDT をビルドする
- データベースでリクエストされたクエリを実行する
ドキュメント ページ クエリのパフォーマンス指標を把握するでは、システム アクティビティのクエリ パフォーマンス指標 Explore を使用して、クエリの詳細な内訳を確認する方法について説明しています。クエリ トラッカーのクエリの実行フェーズには、クエリ パフォーマンス指標 Explore のメインクエリのフェーズで説明されているイベントが含まれます。
このフェーズでパフォーマンスの問題が発生した場合は、次の手順をお試しください。
- 可能な限り、
many_to_one結合を使用して Explore を作成します。ビューを最も粒度の細かいレベルから最も詳細なレベル（many_to_one）まで結合すると、通常、クエリ パフォーマンスが最も高くなります。 - 可能な限りキャッシュを最大化して ETL ポリシーと同期し、データベースのクエリ トラフィックを削減します。デフォルトでは、Looker でクエリがキャッシュされるのは 1 時間です。
persist_withパラメータを使用して Explore 内でデータグループを適用することで、キャッシュ保存ポリシーを制御し、Looker のデータ更新を ETL プロセスと同期できます。キャッシュ保存を最大化することで、Looker とバックエンド データ パイプラインの統合を強化できるので、古いデータを分析するリスクを伴わずにキャッシュ使用量を最大化できます。名前付きキャッシュ保存ポリシーは、モデル全体に適用することも、個々の Explore と永続的な派生テーブル（PDT）に適用することもできます。 - Looker の集約テーブルの自動認識機能を使用して、Looker がロールアップまたはサマリー テーブルを作成できます。Looker は可能な限り、特に大規模なデータベースの一般的なクエリの場合にこのテーブルを使用できます。また、集約テーブルの自動認識を使用して、ダッシュボード全体のパフォーマンスを大幅に向上させることもできます。詳細については、集約テーブルの自動認識のチュートリアルをご覧ください。
- PDT を使用してクエリを高速化します。多くの複雑な結合やパフォーマンスの低い結合を持つ Explore や、サブクエリやサブセレクトを持つディメンションを PDT に変換すると、ビューが事前結合され、ランタイム前に使用可能な状態になります。
- データベース言語が増分 PDT をサポートしている場合は、増分 PDT を構成して、Looker が PDT テーブルの再構築にかかる時間を短縮します。
- Looker で定義された連結済みの主キーでビューを Explore に結合しないようにします。ビューに含まれる、連結済みの主キーを構成する基本フィールドで結合します。または、ビューの LookML ではなく、テーブルの SQL 定義で事前定義された連結済みの主キーを使用して、ビューを PDT として再作成します。
- ベンチマークには、SQL Runner ツールの Explain を利用します。
EXPLAINは、特定の SQL クエリに対するデータベースのクエリ実行プランの概要を生成し、最適化可能なクエリ コンポーネントを検出できるようにします。詳細については、コミュニティ投稿のEXPLAINを使用して SQL を最適化する方法をご覧ください。 - インデックスを宣言します。各テーブルのインデックスは、Looker で SQL Runner から直接確認できます。テーブルの歯車アイコンをクリックし、[Show Indexes] を選択します。
よく使われる列のうち、インデックスのメリットを得られる列は、重要な日付と外部キーです。これらの列にインデックスを追加すると、ほぼすべてのクエリでパフォーマンスが向上します。これは PDT にも適用されます。
indexes、sort keys、distributionなどの LookML パラメータが適切に適用できます。
結果の処理フェーズ
「結果を処理中」フェーズでは、Looker がクエリの結果を処理してレンダリングします。結果の処理フェーズには、次のタスクが含まれます。
- クエリ結果をキャッシュにストリーミングする
- 表計算の解決
- Liquid テンプレート言語の結果をフォーマットする
- クエリを結合する
- 合計と小計の計算
ドキュメント ページ クエリのパフォーマンス指標を把握するでは、システム アクティビティのクエリ パフォーマンス指標 Explore を使用して、クエリの詳細な内訳を確認する方法について説明しています。クエリ トラッカーの結果の処理フェーズには、クエリ パフォーマンス指標 Explore のクエリ後のフェーズで説明されているイベントが含まれます。
このフェーズでパフォーマンスの問題が発生した場合は、次の手順を試してください。
- 結果の統合、カスタム フィールド、表計算などの機能の使用は控えめにします。これらの機能は、モデルの設計に役立つ概念実証として使用することを目的としています。使用頻度の高い計算や関数は LookML にハードコードすることをおすすめします。これにより、データベースで処理される SQL を生成します。過剰な計算は Looker インスタンスの Java メモリと競合する可能性があるため、Looker インスタンスのレスポンスが遅くなります。
- ビューファイルの数が多い場合は、モデル内に含めるビューの数を制限します。1 つのモデルにすべてのビューを含めると、パフォーマンスが低下する場合があります。プロジェクト内に多数のビューが存在する場合は、各モデルに必要なビューファイルのみを含めることを検討してください。モデルにビューグループを簡単に含められるように、ビューファイルの名前に戦略的な命名規則を採用することを検討してください。例については、
includesパラメータのドキュメントをご覧ください。 - ダッシュボードのタイルと Look 内に、大量のデータポイントをデフォルトで返すのを避けます。数千のデータポイントを返すクエリは、より多くのメモリを消費します。フロントエンドの
フィルタをダッシュボード、Look、Explore に適用し、LookML レベルで
required filters、conditionally_filter、sql_always_whereパラメータを使用して、可能な限りデータを制限できるようにします。 - クエリのサイズが非常に大きくなり、処理する際に Looker サーバーに負荷がかかる可能性があるため、[すべての結果] オプションを使用してのクエリのダウンロードや配信は控えめにします。