Explore クエリ トラッカーと [Explore] の [パフォーマンス] パネルには、Explore クエリのパフォーマンスに関する詳細なデータが表示されます。このデータは、クエリのパフォーマンスの問題のトラブルシューティングと解決のための主要なエントリ ポイントを特定し、改善のための推奨事項を提供するために役立ちます。
Explore クエリ トラッカー
Explore クエリ トラッカーには、クエリの実行中にクエリの 3 つのフェーズにおける Explore クエリの進行状況が表示されます。
クエリの実行に時間がかかる場合は、クエリ トラッカーで、パフォーマンスの問題の原因となっているクエリのフェーズを特定できます。これは、パフォーマンスの問題が発生する可能性のある場所や、最適化の取り組みが最も効果的である場所を特定するのに役立ちます。
クエリ トラッカーは、Explore の [ビジュアリゼーション] パネルまたは [データ] パネルが開いている限り、Explore の実行中に表示されます。
[パフォーマンス] パネルを調べる
Explore の [パフォーマンス] パネルを表示するには、[パフォーマンスの詳細を表示] リンクをクリックします。このリンクは、実行された Explore クエリで利用できます。
[パフォーマンス] パネルには、3 つのクエリフェーズのそれぞれでクエリが費やした時間が示されます。また、パフォーマンスのドキュメントと、クエリ履歴システム アクティビティ ダッシュボードへのリンクも含まれています。このダッシュボードには、クエリと、クエリの作成に使用された Explore の現在のパフォーマンス データと過去のパフォーマンス データが表示されます。
クエリフェーズ
Looker の Explore がデータベース クエリを実行すると、クエリは次の 3 つのフェーズで実行されます。
クエリの初期化フェーズ
クエリの初期化フェーズでは、クエリがデータベースに送信される前に必要なすべてのタスクを Looker が行います。クエリの初期化フェーズには、次のタスクが含まれます。
- LookML モデルのコンパイル
- 永続的な派生テーブル（PDT）を作成する必要があるかどうかの確認
- クエリ SQL の生成
- データベース接続の取得
ドキュメント ページ クエリのパフォーマンス指標を把握するでは、システム アクティビティの [クエリ パフォーマンス指標] Explore を使用して、クエリの詳細な内訳を確認する方法について説明しています。クエリ トラッカーのクエリの初期化フェーズには、クエリ パフォーマンス指標 Explore の非同期ワーカー フェーズ、初期化フェーズ、接続処理フェーズで説明されているイベントが含まれます。
クエリ実行フェーズ
クエリの実行フェーズは、Looker がデータベースに接続してクエリを実行し、クエリの結果を返すフェーズです。このフェーズでパフォーマンスの問題が発生した場合は、外部データベースに問題がある可能性があります。たとえば、再ビルドに時間がかかり、最適化が必要な PDT や、最適化が必要な外部データベース テーブルなどです。[クエリの実行] フェーズには、次のタスクが含まれます。
- 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 サーバーに負荷がかかる可能性があるため、[すべての結果] オプションを使用してのクエリのダウンロードや配信は控えめにします。