表示されているのは Looker のドキュメントです。Looker Studio のドキュメントについては、https://support.google.com/looker-studio をご覧ください。

増分PDT

Looker では、データベースのスクラッチスキーマに永続的な派生テーブル（PDT）が書き込まれます。Looker は永続性戦略に基づいて PDT の永続化と再構築を行います。PDTの再構築がトリガーされると、Lookerはデフォルトでテーブル全体を再構築します。

増分 PDT は、テーブル全体を再構築するのではなく、Looker が新しいデータをテーブルに追加して構築する PDT です。

下部に少数の行が追加されることを強調するための3つの行を持つ大きなテーブル

言語が増分 PDT をサポートしている場合は、次のタイプの PDT を増分 PDT にできます。

増分PDTに対するクエリを初めて実行すると、Lookerは、初期データを取得するためにPDT全体を構築します。テーブルのサイズが大きい場合、初期構築には大規模なテーブル構築のためにかなり時間がかかる場合があります。初期テーブルが構築されると、戦略的に増分PDTが設定されているなら、それ以降の構築は増分になり必要な時間は短くなります。

増分 PDT については、次の点に注意してください。

増分 PDT は、トリガーベースの永続化戦略を使用する PDT にのみサポートされています（datagroup_trigger、sql_trigger_value、interval_trigger）。増分 PDT は、persist_for 永続性戦略を使用する PDT ではサポートされていません。
SQL ベースの PDT の場合、テーブルクエリは増分 PDT として使用するため sql パラメータを使用して定義する必要があります。sql_create パラメータ、または create_process パラメータで定義された SQL ベースの PDT は、段階的に構築することはできません。このページの例 1 に示されているように、Looker は INSERT または MERGE コマンドを使用して、増分 PDT の増分を作成します。派生テーブルを、カスタムデータ定義言語（DDL）ステートメントを使用して定義することはできません。というのは、Looker は、正確な増分作成のためにどの DDL ステートメントが必要になるかを判別できないからです。
増分 PDT のソーステーブルは、時間ベースのクエリ用に最適化する必要があります。具体的には、増分キーに使用される時間ベースの列には、パーティショニング、並べ替えキー、インデックスなどの最適化戦略、または言語でサポートされているなんらかの最適化戦略が含まれている必要があります。ソーステーブル最適化は強く推奨されます。というのは、増分テーブルが更新されるたびに、Looker はソーステーブルに対してクエリを実行し、増分キーとして使用される時間ベースの列の最新値を調べるからです。それらのクエリ用にソーステーブルが最適化されていない場合、Looker が最新値をクエリする処理は遅くなってコストがかかる可能性があります。

増分PDTを定義する

次のパラメータを使用して、PDTを増分PDTにすることができます。

increment_key（PDT を増分 PDT にする場合に必須）: 新しいレコードを照会する期間を定義します。
{% incrementcondition %}Liquid フィルタ（SQL ベースの PDT を、LookML ベースの PDT には非適用の増分 PDT とする場合に必須）: 増分キーが基になっているデータベース時間列に接続します。詳しくは、increment_key のドキュメントページをご覧ください。
increment_offset (任意): 増分構築ごとに再構築する、以前の期間（increment key の粒度で指定される）の数を定義する整数。increment_offset パラメータは、遅れて到着したデータに便利です。この場合、対応する増分が最初に構築され、PDT に追加されたときに、以前の期間に含まれていない新しいデータが含まれていることがあります。

永続的なネイティブ派生テーブル、永続的な SQL ベースの派生テーブル、サマリー表から増分 PDT を作成する方法の例については、increment_key パラメータのドキュメントページをご覧ください。

LookMLベースの増分PDTを定義するビューファイルの簡単な例を以下に示します。

view: flights_lookml_incremental_pdt {
  derived_table: {
    indexes: ["id"]
    increment_key: "departure_date"
    increment_offset: 3
    datagroup_trigger: flights_default_datagroup
    distribution_style: all
    explore_source: flights {
      column: id {}
      column: carrier {}
      column: departure_date {}
    }
  }

  dimension: id {
    type: number
  }
  dimension: carrier {
    type: string
  }
   dimension: departure_date {
    type: date
  }
}

このテーブルは、クエリの初回実行時に全体が構築されます。その後、PDT は 1 日分（increment_key: departure_date）単位で再構築され、3 日分（increment_offset: 3）に戻ります。

増分キーは departure_date ディメンション、実際には departure ディメンショングループの date 期間が基準となります。（ディメンショングループの仕組みの概要については、dimension_group パラメータのドキュメントページをご覧ください）。ディメンショングループと期間はどちらも、この PDT の explore_source である flights ビューで定義されます。departure ディメンショングループが flights ビューファイルでどのように定義されるかを以下に示します。

...
  dimension_group: departure {
    type: time
    timeframes: [
      raw,
      date,
      week,
      month,
      year
    ]
    sql: ${TABLE}.dep_time ;;
  }
...

増分パラメータと永続性戦略の関係

PDT の increment_key 設定と increment_offset 設定は、PDT の永続性戦略とは無関係です。

増分 PDT の永続性戦略で決まるのは、PDT の増分のタイミングのみです。PDT ビルダーは、テーブルの永続性戦略がトリガーされる場合や、Explore の [Rebuild Dtables & Run] オプションで PDT を手動でトリガーしない限り、増分 PDT を変更しません。
PDT が増分すると、PDT ビルダーは、直近の時間増分（increment_key パラメータによって定義される期間）に基づいて、最後に最新のデータがテーブルに追加されたタイミングを決定します。それに基づき、PDTビルダーは、テーブルの中の最新の時間増分の開始時間までデータを切り捨てた後、そこから最新の増分を構築します。
PDT に increment_offset パラメータがある場合、PDT ビルダーは increment_offset パラメータで指定された過去の期間の数も再構築します。以前の期間は、直近の時間増分（increment_key パラメータによって定義される期間）の開始時間からさかのぼります。

次のシナリオのサンプルは、increment_key、increment_offset、永続性戦略の関係を示し、増分 PDT がどのように更新されるかを示すものです。

例 1

この例で使用されるPDTのプロパティは次のとおりです:

増分キー: 日付
増分オフセット: 3
永続性戦略: 毎月 1 日にトリガーされます。

このテーブルがどう更新されるかを以下に示します:

永続性戦略が毎月であることは、テーブルが月に一度自動構築されることを意味します。つまり、例えば6月1日の時点で、テーブルに追加されていた最後の行は5月1日になります。
このPDTの増分キーは日単位であるため、PDTビルダーは、5月1日をその日の初めまで切り捨て、5月1日と当日6月1日までのデータを再構築します。
さらに、この PDT には 3 の増分オフセットがあります。そのためPDTビルダーは、5月1日より前の3つの期間（日）のデータも再構築します。その結果、4月28、29、30日、および当日6月1日までのデータが再構築されます。

SQLで言えば、既存PDTのうち再構築する必要のある行を判別するためにPDTビルダーが6月1日に実行するコマンドは次のとおりです:

## Example SQL for BigQuery:
SELECT FORMAT_TIMESTAMP('%F %T',TIMESTAMP_ADD(MAX(pdt_name),INTERVAL -3 DAY))

## Example SQL for other dialects:
SELECT CAST(DATE_ADD(MAX(pdt_name),INTERVAL -3 DAY) AS CHAR)

また、最新の増分を構築するためにPDTビルダーが6月1日に実行するSQLコマンドは次のとおりです:

## Example SQL for BigQuery:

MERGE INTO [pdt_name] USING (SELECT [columns]
   WHERE created_at >= TIMESTAMP('4/28/21 12:00:00 AM'))
   AS tmp_name ON FALSE
WHEN NOT MATCHED BY SOURCE AND created_date >= TIMESTAMP('4/28/21 12:00:00 AM')
   THEN DELETE
WHEN NOT MATCHED THEN INSERT [columns]

## Example SQL for other dialects:

START TRANSACTION;
DELETE FROM [pdt_name]
   WHERE created_date >= TIMESTAMP('4/28/21 12:00:00 AM');
INSERT INTO [pdt_name]
   SELECT [columns]
   FROM [source_table]
   WHERE created_at >= TIMESTAMP('4/28/21 12:00:00 AM');
COMMIT;

例 2

この例で使用されるPDTのプロパティは次のとおりです:

永続性戦略: 1 日に 1 回トリガーされます。
増分キー: 月
増分オフセット: 0

このテーブルが6月1日にどう更新されるかを以下に示します:

永続性戦略が毎日であることは、テーブルが1日に一度自動構築されることを意味します。6月1日の時点で、テーブルに追加されていたの最後の行は5月31日になります。
増分キーは月単位であるため、PDTビルダーは、5月31日からその月の初めまで切り捨て、5月のすべておよび6月1日を含む当日までのデータを再構築します。
このPDTには増分オフセットがないため、再構築される以前の期間はありません。

このテーブルが6月2日にどう更新されるかを以下に示します:

6月2日の時点で、テーブルに追加されていた最後の行は6月1日になります。
PDTビルダーは6月の月初めまでさかのぼって切り捨て、6月1日以降当日までのデータを再構築するため、再構築されるデータは6月1日と6月2日だけです。
このPDTには増分オフセットがないため、再構築される以前の期間はありません。

例 3

この例で使用されるPDTのプロパティは次のとおりです:

増分キー: 月
増分オフセット: 3
永続性戦略: 1 日に 1 回トリガーされます。

このシナリオは、増分 PDT のまずい設定例です。3か月オフセットで毎日トリガーされる PDT となっています。つまり、最低でも3か月分のデータが毎日再構築されるため、増分PDTが非常に非効率な方法で使用されることになります。しかし、これは増分PDTの動作について理解を深める上で興味深いシナリオです。

このテーブルが6月1日にどう更新されるかを以下に示します:

永続性戦略が毎日であることは、テーブルが1日に一度自動構築されることを意味します。例えば6月1日の時点で、テーブルに追加されていた最後の行は5月31日になります。
増分キーは月単位であるため、PDTビルダーは、5月31日からその月の初めまで切り捨て、5月のすべておよび6月1日を含む当日までのデータを再構築します。
さらに、この PDT には 3 の増分オフセットがあります。つまり、PDT ビルダーは 5 月より前の 3 つの期間（月）のデータも再構築します。2 月、3 月、4 月から6月1日を含む当日までのデータが再構築されます。

このテーブルが6月2日にどう更新されるかを以下に示します:

6月2日の時点で、テーブルに追加されていた最後の行は6月1日になります。
PDTビルダーは、6月1日までさかのぼって月を切り捨て、6月2日を含む6月のデータを再構築します。
さらに、増分オフセットがあるため、PDTビルダーは、6月より前の3か月分のデータを再構築することになります。その結果、3月、4月、5月、および当日6月2までのデータが再構築されます。

増分PDTを開発モードでテストする

新しい増分PDTを本番環境にデプロイする前に、PDTをテストして、その構築と増分を確認することができます。増分PDTを開発モードでテストするには:

PDT用のExploreを作成します:
- 関連するモデルファイルで include パラメータを使用して、モデルファイルに PDT のビューファイルを含めます。
- 同じモデルファイルで、explore パラメータを使用して、増分 PDT のビュー用の Explore を作成します。
```
 include: "/views/e_faa_pdt.view"
 explore: e_faa_pdt {}
```
PDT用のExploreを開きます。これを行うには、[See file actions] ボタンを選択して Explore の名前を選択します。

Explore の中で、ディメンションまたはメジャーを選択し、[Run] をクリックします。LookerによりPDT全体が構築されます。これが増分PDTに対して実行した最初のクエリである場合、PDTビルダーはPDT全体を構築し初期データを取得します。テーブルのサイズが大きい場合、初期構築には大規模なテーブル構築のためにかなり時間がかかる場合があります。
初期PDTが構築されたことは、次の方法で確認できます:
- see_logs 権限がある場合は、PDT イベントログでテーブルが構築されていることを確認できます。PDT イベントログの中に PDT の作成イベントが見当たらない場合、PDT イベントログ Explore の先頭のステータス情報を確認してください。[キャッシュから] と表示されている場合は、[キャッシュをクリアして更新] を選択すると、最新の情報を取得できます。
- それ以外の場合は、Explore の [データ] バーの [SQL] タブでコメントを確認できます。[SQL] タブには、クエリと、Explore でクエリを実行したときに実行されるアクションが表示されます。たとえば、[SQL] タブのコメントが「-- generate derived table e_incremental_pdt」となっている場合、これは [実行] をクリックすると実行されるアクションです。
PDT の最初の構築を作成したら、「Explore」の [Rebuild Derived Tables & Run] オプションを使用して、PDT の増分構築のプロンプトを表示します。
前と同じ方法を使用することによりPDTの増分構築を確認できます。
- see_logs 権限を付与されている場合は、PDT イベントログを使用して、増分 PDT の create increment complete イベントを確認できます。このイベントが PDT イベントログに表示されず、クエリのステータスが「キャッシュから」と表示されている場合は、[キャッシュをクリアして更新] を選択して、最新の情報を取得します。
- Explore の [データ] バーの [SQL] タブでコメントを確認します。この場合、コメントにはPDTが増分されたことが示されています。例: -- increment persistent derived table e_incremental_pdt to generation 2
PDT が構築されていて増分が適切であることを確認した後、PDT の専用 Explore をそのまま保持することが望ましくない場合は、PDT の explore パラメータと include パラメータをモデルファイルから削除するかコメントアウトします。

開発モードで PDT を構築した後、変更内容をデプロイしたら、テーブルの定義にそれ以上変更を加えるのでなければ、同じテーブルが本番用に使用されます。詳しくは、Looker の派生テーブル ドキュメントの Development Mode の永続テーブルをご覧ください。

増分PDT対応のデータベース言語

Looker プロジェクトで増分 PDT に対応するためには、データベース言語が、行の削除と挿入を有効にするデータ定義言語（DDL）のコマンドに対応している必要があります。

次の表では、Looker の最新リリースで増分 PDT をサポートする言語を示します（Databricks の場合、増分 PDT は Databricks バージョン 12.1 以降でのみサポートされます）。

言語	サポート対象
Actian Avalanche	いいえ
Amazon Athena	いいえ
Amazon Aurora MySQL	いいえ
Amazon Redshift	はい
Apache Druid	いいえ
Apache Druid 0.13+	いいえ
Apache Druid 0.18+	いいえ
Apache Hive 2.3+	いいえ
Apache Hive 3.1.2+	いいえ
Apache Spark 3 以降	いいえ
ClickHouse	いいえ
Cloudera Impala 3.1+	いいえ
ネイティブドライバを使用した Cloudera Impala 3.1+	いいえ
ネイティブドライバを使用した Cloudera Impala	いいえ
DataVirtuality	いいえ
Databricks	はい
Denodo 7	いいえ
Denodo 8	いいえ
Dremio	いいえ
Dremio 11+	いいえ
Exasol	いいえ
Firebolt	いいえ
Google BigQuery Legacy SQL	いいえ
Google BigQuery Standard SQL	はい
Google Cloud PostgreSQL	はい
Google Cloud SQL	×
Google Spanner	×
Greenplum	はい
HyperSQL	いいえ
IBM Netezza	いいえ
MariaDB	いいえ
Microsoft Azure PostgreSQL	はい
Microsoft Azure SQL Database	いいえ
Microsoft Azure Synapse Analytics	はい
Microsoft SQL Server 2008+	いいえ
Microsoft SQL Server 2012+	いいえ
Microsoft SQL Server 2016	いいえ
Microsoft SQL Server 2017+	いいえ
MongoBI	いいえ
MySQL	はい
MySQL 8.0.12+	はい
Oracle	いいえ
Oracle ADWC	いいえ
PostgreSQL 9.5+	はい
PostgreSQL 9.5 より前	はい
PrestoDB	いいえ
Presto SQL	いいえ
SAP HANA 2+	いいえ
SingleStore	いいえ
SingleStore 7+	いいえ
Snowflake	はい
Teradata	いいえ
Trino	いいえ
Vector	いいえ
Vertica	はい