You are viewing documentation for Looker 25.20. Click this link to see the most recent documentation.

increment_key

用途

view: my_view {
  derived_table: {
    increment_key: "created_date"
    ...
  }
}

階層

ファイルを表示

view

derived_table

increment_key

または

モデルファイル

explore

aggregate_table

materialization

increment_key

デフォルト値

なし

許可

時間ベースの LookML ディメンションの名前

特別なルール

increment_key は、永続テーブルでのみサポートされ、特定の言語でのみサポートされます。

定義

言語がサポートしている場合は、プロジェクトで増分 PDT を作成できます。増分 PDT は、テーブル全体を再構築するのではなく、Looker が新しいデータをテーブルに追加して構築する永続的な派生テーブル（PDT）です。詳しくは、増分 PDT のドキュメントページをご覧ください。

increment_key は、新しいデータをクエリして PDT に追加する時間増分を指定することで、PDT を増分 PDT にするパラメータです。increment_key に加えて、必要に応じて increment_offset を指定して、遅れて到着したデータを考慮して再構築する、以前の期間（インクリメントキーの粒度）の数を指定できます。

PDT の increment_key は、PDT の永続トリガーとは独立しています。increment_key、increment_offset、永続性戦略の関係を示すシナリオの例については、増分 PDT のドキュメントページをご覧ください。

increment_key パラメータは、サポートされている言語でのみ機能し、PDT や集約テーブル（PDT の一種）などの永続性戦略を持つテーブルでのみ機能します。

increment_key では、時間ベースの LookML ディメンションを指定する必要があります。

LookML ベースの PDT の場合、increment_key は、PDT の explore_source が基になっているビューで定義されている LookML ディメンションに基づく必要があります。例については、このページの LookML ベースの増分 PDT を作成するセクションをご覧ください。
集約テーブルの場合、increment_key は、集約テーブルの Explore のベースとなるビューで定義されている LookML ディメンションに基づいている必要があります。例については、このページの増分集約テーブルを作成するをご覧ください。
SQL ベースの PDT の場合、increment_key は PDT のビューファイル内で定義された LookML ディメンションに基づく必要があります。例については、このページの増分 SQL ベースの PDT を作成するをご覧ください。

また、increment_key は次の条件を満たす必要があります。

日、月、年、会計四半期などの切り捨てられた絶対時間。曜日などの期間はサポートされていません。
注文作成日など、新しいデータで予測どおりに増加するタイムスタンプ。つまり、テーブルに追加された最新のデータにも最新のタイムスタンプがある場合にのみ、タイムスタンプを増分キーとして使用する必要があります。ユーザーの誕生日などのタイムスタンプは、増分キーとして機能しません。誕生日のタイムスタンプは、テーブルに追加された新しいユーザーとともに確実に増加しないためです。

LookML ベースの増分 PDT の作成

LookML ベース（ネイティブ）の PDT を増分 PDT にするには、increment_key パラメータを使用して、時間ベースの LookML ディメンションの名前を指定します。ディメンションは、PDT の explore_source の基になるビューで定義する必要があります。

たとえば、次のビューファイルは、explore_source LookML パラメータを使用して、LookML に基づく PDT のビューファイルです。PDT は flights Explore から作成されます。この例では、flights ビューに基づいています。

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 ビューで定義されます。flights ビューファイルで departure ディメンショングループを定義する方法は次のとおりです。

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

増分 SQL ベースの PDT を作成する

Looker では、SQL ベースの派生テーブルを使用するのではなく、LookML ベース（ネイティブ）の派生テーブルを増分 PDT のベースとして使用することをおすすめします。ネイティブ派生テーブルは、増分 PDT に必要な複雑なロジックを本質的に処理します。SQL ベースの PDT は手動で作成されたロジックに依存するため、複雑な機能で使用するとエラーが発生しやすくなります。

増分 SQL ベースの PDT を定義するには、LookML ベースの PDT と同様に increment_key と（必要に応じて）increment_offset を使用します。ただし、SQL ベースの PDT は LookML ビューファイルに基づいていないため、SQL ベースの PDT を増分 PDT にするには、次の追加要件があります。

増分キーは、PDT のビューファイルで定義する時間ベースの LookML ディメンションに基づいて作成する必要があります。
増分キーの基準となっているデータベース時間列に増分キーを接続するには、PDT で {% incrementcondition %} Liquid フィルタを指定する必要があります。{% incrementcondition %} フィルタでは、SQL エイリアスや列に基づくディメンションの名前ではなく、データベース内の列の名前を指定する必要があります（次の例を参照）。

Liquid フィルタの基本的な形式は次のとおりです。

   WHERE {% incrementcondition %} database_table_name.database_time_column {% endincrementcondition %}

たとえば、1 日単位（increment_key: "dep_date"）で再構築される SQL ベースの PDT のビューファイルは次のようになります。この場合、再構築時に過去 3 日間のデータがテーブルに追加されます（increment_offset: 3）。

view: sql_based_incremental_date_pdt {
  derived_table: {
    datagroup_trigger: flights_default_datagroup
    increment_key: "dep_date"
    increment_offset: 3
    distribution_style: all
    sql: SELECT
        flights.id2  AS "id",
        flights.origin  AS "origin",
        DATE(flights.leaving_time )  AS "departure"
      FROM public.flights  AS flights
      WHERE {% incrementcondition %} flights.leaving_time {%  endincrementcondition %}
          ;;
  }

  dimension_group: dep {
    type: time
    timeframes: [date, week, month, year]
    datatype: date
    sql:  ${TABLE}.departure
    ;;
  }
  dimension: id {
      type: number
    }
    dimension: origin {
      type: string
  }
}

この例については、次の点に注意してください。

派生テーブルは SQL ステートメントに基づいています。この SQL ステートメントは、データベースの flights.leaving_time 列に基づいて派生テーブルに列を作成します。列にはエイリアス departure が指定されます。
PDT のビューファイルで、dep というディメンショングループが定義されています。
- ディメンショングループの sql パラメータは、ディメンショングループが派生テーブルの departure 列に基づいていることを示します。
- ディメンショングループの timeframes パラメータには、タイムフレームとして date が含まれます。
派生テーブルの increment_key は、dep ディメンショングループの date 期間に基づくディメンションである dep_date ディメンションを使用します。（ディメンショングループの仕組みの概要については、dimension_group パラメータのドキュメントページをご覧ください）。
{% incrementcondition %} Liquid フィルタは、増分キーをデータベースの flights.leaving_time 列に接続するために使用されます。
- {% incrementcondition %} では、データベース内の TIMESTAMP 列の名前を指定する必要があります（または、データベース内の TIMESTAMP 列に評価される必要があります）。
- {% incrementcondition %} は、PDT を定義する FROM 句で使用可能なもの（FROM 句で指定されたテーブルの列など）に対して評価する必要があります。{% incrementcondition %} は、SELECT ステートメントの結果（SQL ステートメントの列に付けられたエイリアスや、列に基づくディメンションの名前など）を参照できません。この例では、{% incrementcondition %} は flights.leaving_time です。FROM 句で flights テーブルが指定されているため、{% incrementcondition %} は flights テーブルの列を参照できます。
- {% incrementcondition %} は、増分キーに使用されるデータベース列と同じ列を指している必要があります。この例では、増分キーは dep_date です。これは、PDT の departure 列で定義されたディメンションです。この列は、データベースの flights.leaving_time 列のエイリアスです。したがって、フィルタは flights.leaving_time を指します。

WHERE {% incrementcondition %} flights.leaving_time {%  endincrementcondition %}

WHERE 句に追加して、他のフィルタを作成できます。たとえば、データベーステーブルが何年も前のデータまで遡る場合、PDT の初期ビルドで特定の日付以降のデータのみが使用されるようにフィルタを作成できます。次の WHERE は、2020 年 1 月 1 日以降のデータを含む PDT を作成します。

WHERE {% incrementcondition %} flights.leaving_time {%  endincrementcondition %}
  AND flights.leaving_time > '2020-01-01'

WHERE 句を使用して、SQL のデータをタイムスタンプに解析し、エイリアスを付けることもできます。たとえば、次の増分 PDT では、text_column に基づく 15 分の増分を使用します。text_column は、タイムスタンプデータに解析された文字列データです。

view: sql_based_incremental_15min_pdt {
  derived_table: {
    datagroup_trigger: flights_default_datagroup
    increment_key: "event_minute15"
    increment_offset: 1
    sql: SELECT PARSE_TIMESTAMP("%c", flights.text_column) as parsed_timestamp_column,
        flights.id2  AS "id",
        flights.origin  AS "origin",
      FROM public.flights  AS flights
      WHERE {% incrementcondition %} PARSE_TIMESTAMP("%c", flights.text_column)
          {% endincrementcondition %} ;;
  }

  dimension_group: event {
    type: time
    timeframes: [raw, minute15, hour, date, week, month, year]
    datatype: timestamp
    sql:  ${TABLE}.parsed_timestamp_column ;;
  }
  dimension: id {
    type: number
  }
  dimension: origin {
    type: string
  }
}

ディメンショングループの sql 定義で SQL のエイリアスを使用できますが、WHERE 句では SQL 式を使用する必要があります。また、minute15 は event ディメンショングループで期間として設定されているため、event_minute15 を増分キーとして使用して、PDT の 15 分の増分を取得できます。

増分集計テーブルを作成する

増分集計テーブルを作成するには、aggregate_table パラメータの materialization パラメータに increment_key と（必要に応じて）increment_offset を追加します。increment_key パラメータを使用して、時間ベースの LookML ディメンションの名前を指定します。ディメンションは、集約テーブルの Explore のベースとなるビューで定義する必要があります。

たとえば、この集約テーブルは accidents Explore に基づいています。この場合、accidents Explore は accidents ビューに基づいています。集計テーブルは、2 週間（increment_offset: 2）遡って 1 週間（increment_key: event_week）ずつ再構築されます。

explore: accidents {
  . . .
  aggregate_table: accidents_daily {
    query: {
      dimensions: [event_date, id, weather_condition]
      measures: [count]
    }
    materialization: {
      datagroup_trigger: flights_default_datagroup
      increment_key: "event_week"
      increment_offset: 2
    }
  }
}

増分キーは、event ディメンショングループの week タイムフレームに基づく event_week ディメンションを使用します。（ディメンショングループの仕組みの概要については、dimension_group パラメータのドキュメントページをご覧ください）。ディメンショングループと期間はどちらも、accidents ビューで定義されます。

. . .
view: accidents {
  . . .
  dimension_group: event {
      type: time
      timeframes: [
        raw,
        date,
        week,
        year
      ]
      sql: ${TABLE}.event_date ;;
  }
  . . .
}

注意点

時間ベースのクエリ用にソーステーブルを最適化する

増分 PDT のソーステーブルが時間ベースのクエリのために最適化されていることを確認します。具体的には、増分キーに使用される時間ベースの列には、パーティショニング、並べ替えキー、インデックスなどの最適化戦略、または言語でサポートされているなんらかの最適化戦略が含まれている必要があります。ソーステーブル最適化は強く推奨されます。というのは、増分テーブルが更新されるたびに、Looker はソーステーブルに対してクエリを実行し、増分キーとして使用される時間ベースの列の最新値を調べるからです。それらのクエリ用にソーステーブルが最適化されていない場合、Looker が最新値をクエリする処理は遅くなってコストがかかる可能性があります。

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

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

Looker の最新リリースで増分 PDT に対応する言語を次の表に示します。

方言	サポート対象
Actian Avalanche
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Amazon Redshift 2.1+
Amazon Redshift Serverless 2.1+
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+ with Native Driver
Cloudera Impala with Native Driver
DataVirtuality
Databricks
Denodo 7
Denodo 8 & 9
Dremio
Dremio 11+
Exasol
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 pre-9.5
PrestoDB
PrestoSQL
SAP HANA
SAP HANA 2+
SingleStore
SingleStore 7+
Snowflake
Teradata
Trino
Vector
Vertica

increment_key コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

用途

定義