home ユーザーガイド 基本情報 ヘルプセンター ドキュメンテーション コミュニティ トレーニング 認証
menu
close
settings
Looker keyboard_arrow_down
language keyboard_arrow_down
English
Français
Deutsch
日本語
search
print
Looker documentation will be moving to cloud.google.com on August 22, 2022!
All the information you rely on will be migrated and all docs.looker.com URLs will be redirected to the appropriate page.
Lookerの派生テーブル

Lookerでは、派生テーブルとは、クエリ結果をデータベース内の実際のテーブルのように使用できるクエリを指します。

例えば、多数の列のあるordersという名前のデータベーステーブルがあるとします。それぞれのお客様が行った注文の数や、それぞれのお客様が最初の注文を行った時刻など、お客様レベルの集計メトリクスを計算する必要があります。ネイティブ派生テーブルSQLベースの派生テーブルのいずれかを使用して、これらのメトリクスを含むcustomer_order_summaryという名前の新しいデータベーステーブルを作成できます。

その後、customer_order_summary派生テーブルをデータベース内の他のテーブルと同様に扱えるようになります。

ネイティブ派生テーブルとSQLベースの派生テーブル

Lookerプロジェクトに派生テーブルを作成する場合、viewパラメーターの下でderived_tableパラメーターを使用します。derived_tableパラメーター内には、派生テーブルのクエリを次の2つの方法のいずれかで定義できます。

例えば、以下のビューファイルは、LookMLを使用してcustomer_order_summary派生ファイルからビューを作成する方法を示しています。2つのバージョンのLookMLは、LookMLとSQLのどちらを使用して派生テーブルのクエリを定義しても、同等の派生テーブルを作成できることを示しています。

ネイティブ派生テーブルバージョン
view: customer_order_summary { derived_table: { explore_source: orders { column: customer_id { field: orders.customer_id } column: first_order { field: orders.first_order } column: total_amount { field: orders.total_amount } } } dimension: customer_id { type: number primary_key: yes sql: ${TABLE}.customer_id ;; } dimension_group: first_order { type: time timeframes: [date, week, month] sql: ${TABLE}.first_order ;; } dimension: total_amount { type: number value_format: "0.00" sql: ${TABLE}.total_amount ;; } }
SQLベースの派生テーブルバージョン
view: customer_order_summary { derived_table: { sql: SELECT customer_id, MIN(DATE(time)) AS first_order, SUM(amount) AS total_amount FROM orders GROUP BY customer_id ;; } dimension: customer_id { type: number primary_key: yes sql: ${TABLE}.customer_id ;; } dimension_group: first_order { type: time timeframes: [date, week, month] sql: ${TABLE}.first_order ;; } dimension: total_amount { type: number value_format: "0.00" sql: ${TABLE}.total_amount ;; } }

どちらのバージョンも、列customer_idfirst_order,、およびtotal_amountを含むordersテーブルに基づくcustomer_order_summaryと呼ばれるビューを作成します。

derived_tableパラメーターとそのサブパラメーターを除けば、このcustomer_order_summaryビューは他のビューファイルと同様に動作します。派生テーブルのクエリをLookMLまたはSQLのどちらで定義しても、派生テーブルの列に基づくLookMLのMeasureやDimensionを作成できます。

派生テーブルの定義が完了したら、データベース内の他のテーブルと同様に使用することができます。

ネイティブ派生テーブル

ネイティブ派生テーブルは、LookMLの用語を使用して定義するクエリに基づいています。ネイティブ派生テーブルを作成する場合、viewパラメーターのderived_tableパラメーター内部でexplore_sourceパラメーターを使用します。ネイティブ派生テーブルの列は、モデル内のLookML DimensionまたはMeasureを参照して作成します。ネイティブ派生テーブルのビューファイルについては、前の例を参照してください。

SQLベースの派生テーブルと比較すると、ネイティブ派生テーブルでは、データをモデル化するときの読みやすさと理解しやすさが向上します。

ネイティブ派生テーブルの作成の詳細については、ネイティブ派生テーブルの作成のドキュメンテーションページを参照してください。

SQLベースの派生テーブル

SQLベースの派生テーブルを作成するには、SQL用語でクエリを定義し、SQLクエリを使用してテーブルに列を作成します。SQLベースの派生テーブルでLookMLのDimensionとMeasureを参照先とすることはできません。SQLベースの派生テーブルのビューファイルについては、前の例を参照してください。

一般に、SQLクエリはviewパラメーターのderived_tableパラメーター内部でsqlパラメーターを使用して定義します。

LookerでのSQLベースのクエリ作成に役立つショートカットは、SQL Runnerを使用してSQLクエリを作成し、派生テーブルの定義に変えることができます。

特定のエッジケースでは、sqlパラメーターの使用が許可されない場合があります。そのような場合、Lookerでは永続的な派生テーブル(PDT)のSQLクエリの定義のために以下のパラメーターをサポートしています。

sqlcreate_processsql_createのどのパラメーターを使用している場合であっても、派生テーブルの定義にはSQLクエリが使用されるため、これらはすべてSQLベースの派生テーブルと見なされます。

SQLベースの派生テーブルを定義する場合は、ASを使用して、各列に明確な別名を付ける必要があります。これは、Dimensionで結果セットの列名(${TABLE}.first_orderなど)の参照が必要になるためです。前の例で単純なMIN(DATE(time))ではなく、MIN(DATE(time)) AS first_orderを使用しているのはそのためです。

増分PDTとして使用する場合、SQLベースの派生テーブルはsqlパラメーターを使用して定義しなければなりません。sql_createパラメーターまたはcreate_processパラメーターを指定して定義されているSQLベースの派生テーブルについては、増分構築できません。

一時的な派生テーブルと永続的な派生テーブル

ネイティブ派生テーブルとSQLベースの派生テーブルの対比だけではなく、一時的な派生テーブル(データベースに書き込まれない)と永続的な派生テーブル(データベースのスクラッチスキーマに書き込まれる)の違いもあります。

ネイティブ派生テーブルとSQLベースの派生テーブルは、一時的、または永続的のどちらにもできます。

一時的な派生テーブル

前述の派生テーブルは、一時的な派生テーブルの例です。これは、永続性戦略derived_tableパラメーターに定義されていないため一時的なものです。

一時的な派生テーブルは、データベースに書き込まれません。1つまたは複数の派生テーブルに関与するExploreクエリをユーザーが実行すると、Lookerは、それらの派生テーブルの、ダイアレクト固有のSQLの組み合わせと、リクエストされたフィールド、結合、フィルタ値を使用してSQLクエリを構築します。その組み合わせが以前に実行されたものであり、キャッシュ内の結果がまだ有効な場合には、Lookerはキャッシュされた結果を使用します。Lookerでのクエリのキャッシュの詳細については、データグループによるクエリのキャッシングとPDTの再構築のドキュメンテーションページを参照してください。

一方、キャッシュされた結果を使用できない場合、Lookerはユーザーによる一時的な派生テーブルのデータのリクエストごとに、ユーザーのデータベースで新しいクエリを実行することが必要になります。このため、一時的な派生テーブルが高性能であり、データベース上で負荷を増大させるものではないことを確認する必要があります。クエリの実行に時間を要する場合には、一般に永続的な派生テーブルが適しています。

一時的な派生テーブルに対応するデータベースダイアレクト

Lookerプロジェクトで派生テーブルに対応するためには、データベースダイアレクトでも派生テーブルに対応している必要があります。次の表は、Looker22.14の派生テーブルに対応しているダイアレクトを示しています。

永続的な派生テーブル(PDT)

永続的な派生テーブル(PDT)は、データベースのスクラッチスキーマに書き込まれ、永続性戦略で指定したスケジュールで再生成された派生テーブルです。

PDTはネイティブ派生テーブルまたはSQLベースの派生テーブルのどちらでもかまいません。

PDTは、ユーザーがテーブルからのデータをリクエストする際にはテーブルがすでに作成されているので、クエリ時間とデータベースへの負荷の低減に役立ちます。

LookerプロジェクトでPDTを使用するには、以下のものが必要です。

PDTに対応するデータベースダイアレクト

LookerプロジェクトでPDTに対応するためには、データベースダイアレクトでもPDTに対応している必要があります。

永続的な派生テーブルの種類(LookMLベースまたはSQLベース)にかかわらず、ダイアレクトは他の要件に加えて、データベースへの書き込みに対応している必要があります。読み取り専用データベース構成の中には、永続性の動作を許可しないものもあります(Postgresホットスワップレプリカデータベースによく見られます)。このような場合には、代わりに一時的な派生テーブルを使用できます。

次の表は、Looker22.14の永続的なSQLベースの派生テーブルに対応しているダイアレクトを示しています。

永続的なネイティブ派生テーブル(LookMLベースのクエリを含む)に対応するには、ダイアレクトがCREATE TABLE DDL関数にも対応している必要があります。ここでは、Looker22.14の永続的なネイティブ(LookMLベースの)派生テーブルに対応しているダイアレクトのリストを示します。

OAuthを使用するSnowflakeまたはGoogle BigQuery接続ではPDTはサポートされません。

PDTの増分構築

ご使用のダイアレクトでサポートされているなら、プロジェクトに増分PDTを作成できます。増分PDTとは、テーブル全体を再構築するのではなく、新しいデータをテーブルに追加してビルドする、永続的な派生テーブル(PDT)です。詳細については、増分PDTのドキュメンテーションページを参照してください。

増分PDT対応のデータベースダイアレクト

Lookerプロジェクトで増分PDTに対応するためには、データベースダイアレクトでも増分PDTに対応している必要があります。次の表は、Looker 22.14において増分PDTに対応しているダイアレクトを示しています。

永続的な派生テーブルの作成

派生テーブルを永続的な派生テーブルにするには、そのテーブルに永続性戦略を定義します。パフォーマンスを最適化するには、最適化戦略も追加する必要があります。

永続性戦略

派生テーブルの永続性は、Lookerで管理できます。マテリアル化ビューをサポートするダイアレクトの場合は、マテリアル化ビューを使用してデータベースで管理できます。

派生テーブルを永続的なものにするには、以下のいずれかのパラメーターをderived_table定義に追加します。

トリガーベースの永続性戦略(datagroup_triggersql_trigger、およびinterval_trigger)では、PDTの再構築がトリガーされるまで、LookerはそのPDTをデータベースに保持します。PDTがトリガーされると、LookerはPDTを再構築し、前のバージョンと置き換えます。つまり、トリガーベースのPDTでは、ユーザーがPDTからのExploreクエリの回答を得るために、PDTの構築を待つ必要はありません。

特定のユーザーは、PDTの永続性設定を上書きすることができます。develop権限を持つユーザーは、Exploreのメニューから[Rebuild Derived Tables & Run]オプションを使用して永続性設定を上書きし、Exploreの現在のクエリに必要なすべてのPDTを再構築することができます。詳細については、このページの手動によるクエリ用のPDTの再構築に関するセクションを参照してください。

datagroup_trigger

データグループは、最も柔軟性の高い永続性作成メソッドです。キャッシュポリシーについてdatagroupを定義している場合には、datagroup_triggerパラメーターを使用してキャッシュポリシーと同じスケジュールでPDTの再構築を開始することができます。

Lookerでは、PDTのデータグループがトリガーされるまで、そのPDTをデータベースに保持します。データグループがトリガーされると、LookerはPDTを再構築し、前のバージョンと置き換えます。ほとんどの場合、これにより、ユーザーがPDTの構築を待つ必要がなくなります。PDTが構築中であり、クエリ結果がキャッシュされていない場合にユーザーがPDTからデータをリクエストすると、Lookerは新しいPDTがビルドされるまで、既存のPDTからデータを返します。データグループの概要については、データグループによるクエリのキャッシングとPDTの再構築のドキュメンテーションページを参照してください。

リジェネレーターのPDTの構築方法については、Lookerリジェネレーターのセクションを参照してください。

sql_trigger_value

sql_trigger_valueパラメーターは、指定したSQL文に基づいてPDTの再生成をトリガーします。SQL文の結果が前の値と異なる場合、PDTが再生成されます。それ以外の場合は、既存のPDTがデータベースに保持されます。ほとんどの場合、これにより、ユーザーがPDTの構築を待つ必要がなくなります。PDTの構築中で、クエリ結果がキャッシュされていない場合にユーザーがPDTのデータをリクエストすると、Lookerは新しいPDTが構築されるまで既存のPDTからのデータを返します。

リジェネレーターのPDTの構築方法については、Lookerリジェネレーターのセクションを参照してください。

interval_trigger

interval_triggerパラメーターは、"24 hours""60 minutes"など、指定された時間間隔に基づいてPDTの再生成をトリガーします。sql_triggerパラメーターと同様、ユーザーがクエリを実行するときには、通常PDTが事前構築されています。PDTの構築中にユーザーがPDTからデータをリクエストしたために、クエリ結果がキャッシュされない場合、Lookerは新しいPDTが構築されるまで既存のPDTからのデータを返します。

persist_for

別のオプションとしては、persist_forパラメーターを使用して、派生テーブルが期限切れとマークされ、クエリに使用されなくなりデータベースから削除されるまでの保存期間を設定するというものがありますです。

persist_for PDTは、ユーザーがPDTのクエリを最初に実行したときにビルドされます。その後、Lookerは、PDTのpersist_forパラメーターで指定した期間まで、このPDTをデータベースに保持します。ユーザーがpersist_for期間中にPDTのクエリを実行すると、Lookerは可能であればキャッシュされている結果を使用し、それ以外の場合はそのPDTでクエリを実行します。

persist_for期間を超過すると、LookerはデータベースからPDTを消去し、そのPDTは次回、ユーザーがクエリしたときに再構築されます。したがって、そのクエリでは再構築を待つ必要があります。

persist_forを使用するPDTは、PDTの依存カスケード依存である場合を除き、Lookerのリジェネレータで自動的に再構築されません。persist_forテーブルがトリガーベースのPDT(datagroup_triggerinterval_trigger、またはsql_trigger_value永続性戦略を使用するPDT)を使用する依存カスケードの一部である場合、リジェネレータは、persist_forテーブルを監視し、再構築して、カスケード内の他のテーブルを再構築します。このページのLookerによるカスケード派生テーブルのビルド方法のセクションを参照してください。

materialized_view: yes

マテリアル化ビューは高度な機能です。ダイアレクトによっては、マテリアル化ビューが膨大なリソースを消費することがあるため、ダイアレクトへのマテリアル化ビューの導入がどういったものか十分理解しておくことが重要です。ダイアレクトの動作や、マテリアル化ビューでのダイアレクトのデータ更新頻度の情報については、ダイアレクトのドキュメンテーションを参照してください。

マテリアル化ビューでは、データベースの機能を利用して、Lookerプロジェクトで派生テーブルを永続化させることができます。データベースダイアレクトがマテリアル化ビューをサポートし、Looker接続設定の永続的な派生テーブルオプションが有効になっている場合、派生テーブルにmaterialized_view: yesを指定するとマテリアル化ビューを作成できます。マテリアル化ビューは、ネイティブ派生テーブルSQLベースの派生テーブルの両方でサポートされています。

永続的な派生テーブル(PDT)と同様、マテリアル化ビューは、データベースのスクラッチスキーマでテーブルとして保存されるクエリの結果です。PDTとマテリアル化ビューの主な違いは、テーブルの更新方法です。

このため、マテリアル化ビューの機能を使用するには、ダイアレクトとその機能に関する高度な知識が必要になります。ほとんどの場合、データベースでは、マテリアル化ビューでクエリされるテーブル内に新規データが検出されるたびに、マテリアル化ビューが更新されます。マテリアル化ビューは、リアルタイムデータが必要なシナリオに最適です。

ダイアレクトのサポート、要件、重要な考慮事項については、materialized_viewパラメーターのドキュメンテーションページを参照してください。

最適化戦略

PDTはデータベースに保存されるため、ダイアレクトでサポートされているとおり、以下の戦略を使用してPDTを最適化する必要があります。

例えば、派生テーブルの例に永続性を追加するには、order_datagroupデータグループがトリガーした際にテーブルが再構築されるよう設定し、customer_idfirst_orderの両方に次のようにインデックスを追加します。

view: customer_order_summary { derived_table: { explore_source: orders { … } datagroup_trigger: orders_datagroup indexes: ["customer_id", "first_order"] } }

インデックス(またはご使用のダイアレクトでそれに相当するもの)を追加しない場合、クエリのパフォーマンス改善のため追加するようLookerから警告が表示されます。

カスケード派生テーブル

場合によっては、ある派生テーブルを別の定義で参照して、連鎖するカスケード派生テーブルまたはカスケードPDTを作成することができます。カスケード派生テーブルの例は、テーブルTABLE_Dです。このテーブルは別のテーブルTABLE_Cに依存し、TABLE_CTABLE_Bに依存し、TABLE_BTABLE_Aに依存します。

カスケード派生テーブルを設定する前に、カスケードテーブルがLookerのリジェネレーターによってどのように自動的に再構築されるか、およびユーザーによってどのように手動で再構築されるかを理解していることが重要です。また、他にも永続テーブルの導入に関する重要な考慮事項があります。これらのトピックはすべて、このページの後半で扱います。

派生テーブル参照の構文

他の派生テーブル内の派生テーブルを参照するには、次の構文を使用します。

${derived_table_or_view_name.SQL_TABLE_NAME}

この書式設定では、SQL_TABLE_NAMEはリテラル文字列です。例えば、次の構文でclean_events派生テーブルを参照できます。

${clean_events.SQL_TABLE_NAME}

この同じ構文を使用してLookMLビューを参照することもできます。この場合も、SQL_TABLE_NAMEはリテラル文字列です。

${derived_table_or_view_name.SQL_TABLE_NAME}構文はデータグループsql_triggerパラメーターではサポートされていないため、派生テーブルを使用してデータグループをトリガーすることはできません。ただし、sql_trigger_valueパラメーターで${derived_table_or_view_name.SQL_TABLE_NAME}構文を使用し、PDTの再構築をトリガーすることができます。

次の例では、clean_events PDTがデータベースのeventsテーブルから作成されます。clean_events PDTはeventsデータベーステーブルから不要な行を除外します。その後、clean_events PDTをまとめた2番目のPDTである、event_summary PDTが表示されます。event_summaryテーブルは、新しい行がclean_eventsに追加されるたびに再生成されます。

event_summary PDTおよびclean_events PDTはカスケードPDTであり、(event_summaryclean_events PDTを使用して定義されているため)event_summaryclean_eventsに依存します。(この特定の例は、1つのPDTでより効率的に行うことができますが、派生テーブルの参照を示すのに役立ちます。)

view: clean_events { derived_table: { sql: SELECT * FROM events WHERE type NOT IN ('test', 'staff') ;; datagroup_trigger: events_datagroup } }   view: events_summary { derived_table: { sql: SELECT type, date, COUNT(*) AS num_events FROM ${clean_events.SQL_TABLE_NAME} AS clean_events GROUP BY type, date ;; datagroup_trigger: events_datagroup } }

必ず必要なわけではありませんが、この方法で派生テーブルを参照する場合は、一般に次の形式でテーブルのエイリアスを作成すると有用です。

${derived_table_or_view_name.SQL_TABLE_NAME} AS derived_table_or_view_name

前の例では次のように行います:

${clean_events.SQL_TABLE_NAME} AS clean_events

ここでは、PDTにはデータベース内で長いコードの名前が付けられているため、エイリアスの使用が役立ちます。場合によっては(特にON句を使用する場合)、この長い名前を取得するために${derived_table_or_view_name.SQL_TABLE_NAME}構文を使用する必要があることを忘れがちになります。エイリアスを付与することで、こうした誤りを避けることができます。

Lookerによるカスケード派生テーブルのビルド方法

一時的な派生テーブルをカスケードする場合にユーザーのクエリ結果がキャッシュになければ、Lookerはそのクエリに必要なすべての派生テーブルをビルドします。TABLE_Dがあり、TABLE_Cへの参照がその定義に含まれている場合、TABLE_DTABLE_C依存しています。つまり、TABLE_Dをクエリし、そのクエリがLookerのキャッシュにない場合、LookerはTABLE_Dを再構築します。しかし、最初はTABLE_Cを再構築する必要があります。

一時的な派生テーブルのカスケードのシナリオを見ていきましょう。このテーブルでは、TABLE_Aに依存するTABLE_Bに依存するTABLE_Cに、TABLE_Dが依存しています。LookerのキャッシュにTABLE_Cに対する有効なクエリ結果がない場合、Lookerはそのクエリに必要なすべてのテーブルをビルドします。そのため、LookerはTABLE_ATABLE_BTABLE_Cの順番で構築することになります。

このシナリオでは、TABLE_Aの生成は、LookerがTABLE_Bの生成を開始するまでに完了する、という順番でTABLE_Cまでテーブルの生成を完了させると、Lookerからクエリ結果が返されます。(TABLE_Dはこのクエリに応える必要がないため、Lookerはこの時点ではTABLE_Dを再構築しません。)

PDTにも同じ基本のロジックが当てはまります。Lookerは、依存関係チェーンを遡って、クエリの回答に必要なすべてのテーブルをビルドします。ただし、PDTでは、テーブルがすでに存在し、再構築する必要がない場合もあります。カスケードPDTに関する標準のユーザークエリでは、Lookerはデータベース内にそのPDTの有効なバージョンがない場合のみ、カスケード内のPDTを再構築します。カスケード内のすべてのPDTを強制的に再構築する場合は、Exploreから手動によりクエリ用テーブルを再構築することができます。

重要な論理ポイントは、PDTカスケードの場合、基本的に依存PDTがその依存先であるPDTをクエリしていることです。これは特に、persist_for戦略を使用しているPDTには重要です。通常、persist_for PDTはユーザーがクエリを実行したときに構築され、persist_for期間が終了するまでデータベースに残され、その後はユーザーが次にクエリするまで再構築されません。ただし、persist_for PDTがトリガーベースのPDT(datagroup_triggerinterval_trigger、またはsql_trigger_valueを使用するPDT)を使用するカスケードの一部である場合、基本的にpersist_for PDTは、依存PDTが再構築されるごとにクエリされます。そのため、この場合、persist_for PDTはその依存PDTのスケジュールに従って再構築されます。つまり、persist_for PDTは、それに依存する永続性戦略の影響を受けるのです。

手動によるクエリ用の永続的なテーブルの再構築

Exploreのメニューから[派生テーブルを再作成して実行する]オプションを選択すると、永続性設定を上書きし、Exploreの現在のクエリに必要なすべてのPDTと集計テーブルを再構築することができます。

Clicking the Explore Actions button opens the Explore menu, from which you can select Rebuild Derived Tables & Run.

このオプションは、ユーザーにdevelop権限があり、Exploreクエリが読み込まれた場合のみ表示されます。

[Rebuild Derived Tables & Run]オプションにより、永続性戦略に関係なく、クエリに回答するために必要なすべての永続的なテーブル(すべてのPDTおよび集計テーブル)が再構築されます。これには現在のクエリのすべての集計テーブルとPDT、および現在のクエリの集計テーブルとPDTによって参照されるすべての集計テーブルとPDTも含まれます。

増分PDTの場合、[Rebuild Derived Tables & Run]オプションは新しい増分のビルドをトリガーします。増分PDTでは、increment_keyパラメーターで指定した期間、およびincrement_offsetパラメーターで指定した数の以前の期間(もしあれば)が増分に含まれます。設定に応じた増分PDTのビルド方法のシナリオ例については、増分PDTのドキュメンテーションページを参照してください。

カスケードPDTの場合は、カスケードの中のすべての派生テーブルが上から順に再ビルドされることを意味します。これは、一時的な派生テーブルのカスケードでテーブルをクエリする場合と同じ動作です。

If table_c depends on table_b, and table_b depends on table_a, then rebuilding table_c first rebuilds table_a, then table_b, and finally table_c.

ユーザーが[派生テーブルを再作成して実行する]操作を開始した場合、テーブルが再構築されてからクエリの結果が読み込まれます。他のユーザーのクエリには、引き続き既存のテーブルが使用されます。永続的なテーブルが再構築された後、すべてのユーザーは再構築されたテーブルを使用します。

このプロセスは、テーブルの再構築中に他のユーザーのクエリを中断しないように設計されていますが、データベースへの負荷増大という形で他のユーザーに影響が及ぶ可能性はあります。業務時間内に再構築をトリガーするとデータベースに許容できない負荷が生じうる状況においては、その時間に特定のPDTや集計テーブルを再構築しないようユーザーへの周知が必要となる場合もあります。

開発モードの永続テーブル

Lookerには、開発モードで永続テーブルを管理するための特殊な動作があります。

このような動作は、集計テーブルとPDTを含むあらゆる永続テーブルに該当します。

開発モードで永続テーブルの定義に変更を加えることなくテーブルに対してクエリを実行すると、Lookerはそのテーブルのプロダクションバージョンに対してクエリを実行します。ただし、テーブルのデータまたはテーブルのクエリ方法に影響を及ぼすような変更をテーブルの定義に加えると、次に開発モードでテーブルをクエリしたときにそのテーブルの新しい開発バージョンが作成されます。このような開発テーブルがあれば、エンドユーザーに影響を及ぼすことなく変更内容をテストできます。

Lookerで開発テーブルが作成されるきっかけ

可能な場合、Lookerは、開発モードかどうかに関係なく、既存のプロダクションテーブルを使用してクエリに答えます。ただし、Lookerは開発モードでクエリにプロダクションテーブルを使用できない次のような場合もあります:

開発モードで、if prodステートメントとif devステートメントで条件付きWHEREを使用して定義されたSQLベースの派生テーブルをクエリすると、Lookerは開発テーブルを構築します(これは、dev_filtersパラメーターを含むネイティブ派生テーブルのケースではありません。dev_filtersを含むネイティブ派生テーブルの場合は、テーブルの定義を変更してから、開発モードでテーブルをクエリしない限り、Lookerはプロダクションテーブルを使用して開発モードでクエリに答えます)。

開発モードでデータセットを絞り込むパラメーターが含まれていない永続テーブルの場合は、テーブルの定義を変更してから、開発モードでテーブルをクエリしない限り、Lookerは、開発モードでテーブルのプロダクションバージョンを使用してクエリに答えます。これによって、テーブル内のデータやテーブルのクエリ方法に影響を及ぼす変更がテーブルに加えられる場合があります。

Lookerで永続テーブルの開発バージョンが作成されるきっかけとなる変更タイプの例を次に示します(Lookerは、これらの変更を加えた後に続けてテーブルがクエリされた場合にのみ、テーブルを作成します)。

テーブルのデータを変更しないあるいはLookerがテーブルをクエリする方法に影響しない変更については、開発テーブルは作成されません。この例として、publish_as_db_viewパラメーターがあります。開発モードでは、派生テーブルのpublish_as_db_view設定のみを変更しても、Lookerでは派生テーブルを再構築する必要がないため開発テーブルは作成されません。

Lookerが開発テーブルを永続化する期間

テーブルの実際の永続性戦略とは関係なく、Lookerでは開発の永続テーブルを、persist_for: "24 hours"永続性戦略があるものとして扱います。Lookerでは、これによって開発テーブルを1日以上永続させないようにしています。これはLooker開発者が開発中、非常に多くのテーブルを反復クエリし、毎回新しい開発テーブルがビルドされることがあるためです。データベースが開発テーブルでいっぱいにならないようにするため、Lookerではpersist_for: "24 hours"戦略を適用し、データベースからテーブルが頻繁に削除されるようにしています。

そうしない場合、Lookerはプロダクションモードで永続テーブルをビルドする場合と同じ方法で、開発モードでPDTと集計テーブルをビルドします。

PDTまたは集計テーブルに変更をデプロイしたとき、データベース上で開発テーブルが永続化されている場合、Lookerはユーザーがテーブルをクエリするときにテーブルが作成されるのを待つ必要がないようにするために、その開発テーブルをプロダクションテーブルとして扱うことがよくあります。

変更をデプロイする場合、状況によっては、そのテーブルをプロダクションでクエリ対象として引き続き再構築しなければならない場合があります。

一方、プロダクションテーブルとして使用可能である有効な開発テーブルがないときに変更をデプロイすると、Lookerは次回テーブルがプロダクションモードでクエリされたとき(persist_for戦略を使用する永続テーブルの場合)、または次回リジェネレータを実行したとき(datagroup_triggerinterval_trigger、またはsql_trigger_valueを使用する永続テーブルの場合)にそのテーブルを再構築します。

開発モードでの未作成のPDTの有無の確認

PDTまたは集計テーブルに変更をデプロイしたとき、データベース上で開発テーブルが永続化されている場合、Lookerはユーザーがテーブルをクエリするときにテーブルが作成されるのを待つ必要がないようにするために、その開発テーブルをプロダクションテーブルとして扱うことがよくあります。詳細は、このページのLookerが開発テーブルを永続化する期間およびLookerで開発テーブルが作成されるきっかけを参照してください。

したがって、プロダクションにデプロイする時点ですべてのPDTが作成済みであり、それらのテーブルをプロダクションバージョンとして直ちに使用できるのが最善です。

プロジェクト内で未構築のPDTがないか[プロジェクトの健全性]パネルで確認できます。Looker IDEの[プロジェクトの健全性]アイコンをクリックして、[プロジェクトの健全性]パネルを開きます。その後、[PDTステータスの検証]ボタンをクリックします。

未構築のPDTが検出されると、[プロジェクトの健全性]パネルにリストされます。

The Project Health panel shows both a list of unbuilt PDTs for the project and a Go to PDT Management button.

see_pdts権限がある場合は、[PDT管理に移動]ボタンをクリックできます。[永続的な派生テーブル]ページの[開発]タブが開き、結果が特定のLookMLプロジェクトでフィルタリングされます。同じ場所で、どの開発PDTが作成済みで、どの開発PDTが未作成かを確認でき、その他のトラブルシューティング情報にアクセスできます。詳細については、管理者設定 - 永続的な派生テーブルドキュメンテーションページを参照してください。

プロジェクト内の未作成のPDTが特定できたら、そのPDTをクエリするExploreを開き、[Explore]メニューから[Rebuild Derived Tables & Run]オプションを使用して、そのPDTの開発バージョンを構築します。詳細については、このページの手動によるクエリ用の永続的なテーブルの再構築セクションを参照してください。

永続テーブルが、if prodステートメントとif devステートメントで条件付きWHEREを使用して定義されたSQLベースの派生テーブルである場合は、そのテーブルの開発バージョンには省略データセットが含まれているため、プロダクションに使用することはできません。詳細は、このページのLookerが開発テーブルを永続化する期間セクションを参照してください。dev_filtersパラメーターを含むネイティブ派生テーブルの場合は、テーブルの定義を変更してから、開発モードでテーブルをクエリしない限り、Lookerは開発モードのクエリにはプロダクションテーブルを使用して答えます(このドキュメンテーションページのLookerで開発テーブルが作成されるきっかけセクションを参照してください)。

テーブルの共有とクリーンアップ

任意のLookerインスタンス内で永続テーブルの定義と永続性メソッド設定が同一である場合、ユーザー間でそのテーブルを共有します。さらに、テーブルの定義が存在しなくなった場合には、Lookerはそのテーブルを期限切れとしてマークします。

これにはいくつかの利点があります。

開発モードでの作業の効率化

PDTの作成に長時間かかる場合もあります。例えば、開発モードで多数の変更内容をテストしている場合は時間がかかります。このような場合、開発モードを使用していれば、Lookerでよりサイズの小さい派生テーブルが作成されるように指定できます。

ネイティブ派生テーブルの場合は、explore_sourcedev_filtersサブパラメーターを使用して開発バージョンの派生テーブルにのみ適用されるフィルターを指定することができます。

view: e_faa_pdt { derived_table: { … datagroup_trigger: e_faa_shared_datagroup explore_source: flights { dev_filters: [flights.event_date: "90 days"] filters: [flights.event_date: "2 years", flights.airport_name: "Yucca Valley Airport"] column: id {} column: airport_name {} column: event_date {} } } … }

上の例には、過去90日間のデータをフィルタリングして表示するdev_filtersパラメーターと、過去2年間かつYucca Valley Airportのデータをフィルタリングして表示するfiltersパラメーターが含まれています。

dev_filtersパラメーターはfiltersパラメーターと併用できるので、開発バージョンのテーブルにすべてのフィルタが適用されます。dev_filtersfiltersの両方が同じ列のフィルタを指定している場合、開発バージョンのテーブルにはdev_filtersが優先的に適用されます。この例では、開発バージョンのテーブルは過去90日間のYucca Valley Airportのデータをフィルタリングして表示します。

SQLベースの派生テーブルの場合は、Lookerでプロダクション(if prod)バージョンのテーブルと開発(if dev)バージョンのテーブルに異なるオプションを指定する条件付きWHERE句がサポートされています。

view: my_view { derived_table: { sql: SELECT columns FROM my_table WHERE -- if prod -- date > '2000-01-01' -- if dev -- date > '2020-01-01' ;; } }

この例では、プロダクションモードのクエリでは2000年以降のすべてのデータが含まれますが、開発モードのクエリでは2020年以降のデータのみが含まれます。この機能を戦略的に使用して結果セットを制限し、クエリ速度を向上させることで、開発モードの変更の検証が大幅にしやすくなります。

永続テーブルにdev_filtersパラメーターや条件付きWHERE句が含まれている場合、開発バージョンには省略データセットが含まれるため、開発テーブルをプロダクションバージョンとして使用することはできません。この場合、テーブルの開発が終わって変更をデプロイする前に、dev_filtersパラメーターまたは条件付きWHERE句をコメント化してから開発モードでテーブルをクエリすることができます。こうすることで、Lookerは変更をデプロイした後もプロダクションで使用可能なフルバージョンのテーブルを構築します。プロダクションでの開発テーブルの使用についての詳細は、このページのLookerが開発テーブルを永続化する期間セクションを参照してください。

Lookerリジェネレータ

Lookerリジェネレーターは、トリガー永続テーブルのステータスをチェックし、再構築を開始します。トリガー永続テーブルとは、トリガーを永続性戦略として使用しているPDTのことです。

Lookerリジェネレータはpersist_forパラメーターを使用する永続テーブルの再構築も開始しますが、これは、persist_forテーブルがトリガー永続テーブルの依存カスケードである場合のみです。この場合、Lookerリジェネレーターはpersist_forテーブルの再ビルドを開始します。カスケード内の他のテーブルを再ビルドするためにこのテーブルが必要になるからです。カスケードの一部でない場合、リジェネレータはpersist_for戦略を使用する永続テーブルを監視しません。

PDTの構築に失敗した場合、リジェネレータは次のリジェネレータサイクルでテーブルの再構築を試みます。

ユーザーがビルド中の永続テーブルからのデータをリクエストし、そのクエリ結果がキャッシュされていない場合、Lookerは既存のテーブルがまだ有効であるかどうかをチェックします。(新バージョンのテーブルと互換性がない旧テーブルは無効になる場合があります。これは、新テーブルに異なる定義がある、新テーブルで別のデータベース接続を使用している、または新テーブルがLookerの別のバージョンで作成されている場合に発生する可能性があります)。既存のテーブルがまだ有効な場合、Lookerは新しいテーブルがビルドされるまで既存のテーブルからデータを返します。一方、既存のテーブルが有効でない場合、Lookerは新しいテーブルが再ビルドされてからクエリ結果を返します。

永続テーブルの導入に関する重要な考慮事項

永続テーブル(PDTおよび集計テーブル)の有用性については、Lookerインスタンスでさまざまな考慮事項を簡単に集約できます。Lookerリジェネレーターが同時に多数のテーブルをビルトするために必要なシナリオを作成することができます。特にカスケードテーブルや実行時間の長いテーブルでは、テーブルの再構築までに時間がかかるシナリオや、データベースがテーブルを生成しょうとしている最中にそのテーブルからクエリ結果を得ようとすると遅延が発生するシナリオを作成することができます。

デフォルトでは、LookerのリジェネレータはPDTトリガーを5分おきにチェックして、トリガー永続テーブル(datagroup_triggerinterval_trigger、またはsql_trigger_value永続性戦略を使用するPDTと集計テーブル)を再構築する必要があるか見極めます。

ただし、テーブルの再構築にかかる時間には他の要素が影響することがあります。

また、前述の考慮事項に加え、以下のように派生テーブルへ永続性を追加すべきでない状況もあります。

Looker接続での永続テーブルの数と複雑さによっては、サイクルごとにチェックし、再構築する必要のある永続テーブルがキューに多数含まれることになります。このため、Lookerインスタンスに派生テーブルを導入するには、これらの要素を念頭に置くことが重要です。

APIを使用した大規模なPDTの管理

インスタンスで多くのPDTを作成すると、さまざまなスケジュールで更新されるPDTの監視と管理がますます複雑になります。LookerのApache Airflow統合を使用して、PDTスケジュールを他のETLおよびELTプロセスと一緒に管理することを検討してください。

PTDの監視とトラブルシューティング

PDT、特にカスケードPDTを使用する場合は、PDTのステータス確認が役立ちます。Lookerの[Persistent Derived Tables]管理ページを使用すると、PTDのステータスを確認できます。詳細については、管理者設定 - 永続的な派生テーブルドキュメンテーションページを参照してください。

永続的な派生テーブルのトラブルシューティングの際の留意点は次のとおりです。

PDTのクエリコメント

データベース管理者は、通常のクエリとPDTを生成するクエリを簡単に見分けることができます。Lookerは、対象のPDTのLookMLモデルおよびビュー、さらにLookerインスタンスの一意の識別子(スラッグ)を含むCREATE TABLE ... AS SELECT ...ステートメントにコメントを追加します。対象のPDTがユーザーに代わり開発モードで生成されている場合には、コメントにはそのユーザーのIDが表示されます。PDT生成コメントは、次のパターンに従います。

-- Building <view_name> in dev mode for user <user_id> on instance <instance_slug> CREATE TABLE <table_name> SELECT … -- finished <view_name> => <table_name>

Exploreのクエリに代わりLookerがPDTを生成した場合には、PDT生成コメントがExploreのSQLタブに表示されます。コメントはSQLステートメントの上部に表示されます。

最後に、PDT生成コメントは、クエリ管理ページの各クエリのクエリ詳細ポップアップ[情報]タブの[メッセージ]フィールドに表示されます。

障害の後のPDTの再構築

PDTに障害がある場合、そのPDTのクエリ時に次のことが発生します。

カスケードPDTにも同じロジックが適用されますが、カスケードPDTに関しては次の点が例外となります。

前述の、TABLE_Aに依存するTABLE_Bに依存するTABLE_Cに、TABLE_Dが依存しているカスケードテーブルの例を振り返りましょう。

TABLE_Bに障害が発生した場合、標準の(カスケードではない)動作がすべてTABLE_Bに適用されます。TABLE_Bがクエリされると、Lookerは最初にキャッシュを使用して結果を返そうとし、次に可能であればテーブルの前のバージョンの使用を試み、次にテーブルを再構築しようとし、TABLE_Bを再構築できなければ最終的にエラーを返します。Lookerは、テーブルが次回クエリされたとき、またはテーブルの永続性戦略が次回再構築をトリガーしたときに、TABLE_Bをもう一度再構築しようとします。

TABLE_Bに依存するものにも同様のことが当てはまります。そのため、TABLE_Bをビルドできず、TABLE_Cへのクエリがある場合は、次のようになります。

TABLE_Bの問題が解決したら、TABLE_Bとそれに依存する各テーブルが、永続性戦略に従って、または次回クエリされたとき(これには次回、依存PDTが再構築を試みた場合も含む)に、再構築を試みます。あるいは、カスケード内のPDTの開発バージョンが開発モードでビルドされている場合は、開発バージョンが新しいプロダクションPDTとして使用される場合があります。(この仕組みについては、このページの開発モードにおける永続テーブルのセクションを参照してください。)または、Exploreを使用してTABLE_Dに対するクエリを実行し、次に手動によりクエリ用のPDTを再構築すると、依存関係カスケードの上方のPDTすべてが強制的に再構築されます。

Top