PDT inkremental

Di Looker, tabel turunan persisten (PDT) ditulis ke skema awal database Anda. Looker mempertahankan dan mem-build ulang PDT berdasarkan strategi persistensi-nya. Saat PDT dipicu untuk di-build ulang, Looker akan mem-build ulang seluruh tabel secara default.

PDT inkremental adalah PDT yang dibuat Looker dengan menambahkan data baru ke tabel, bukan membuat ulang tabel secara keseluruhan:

Tabel besar dengan tiga baris bawah ditandai untuk menunjukkan sejumlah kecil baris baru yang ditambahkan ke tabel.

Jika dialek Anda mendukung PDT inkremental, Anda dapat mengubah jenis PDT berikut menjadi PDT inkremental:

Saat pertama kali Anda menjalankan kueri pada PDT inkremental, Looker akan mem-build seluruh PDT untuk mendapatkan data awal. Jika tabel berukuran besar, build awal mungkin memerlukan waktu yang cukup lama, seperti halnya membuat tabel besar. Setelah tabel awal dibuat, build berikutnya akan bersifat inkremental dan akan memerlukan waktu lebih sedikit, jika PDT inkremental disiapkan secara strategis.

Perhatikan hal berikut untuk PDT inkremental:

  • PDT inkremental hanya didukung untuk PDT yang menggunakan strategi persistensi berbasis pemicu (datagroup_trigger, sql_trigger_value, atau interval_trigger). PDT inkremental tidak didukung untuk PDT yang menggunakan strategi persistensi persist_for.
  • Untuk PDT berbasis SQL, kueri tabel harus ditentukan menggunakan parameter sql agar dapat digunakan sebagai PDT inkremental. PDT berbasis SQL yang ditentukan dengan parameter sql_create atau parameter create_process tidak dapat dibuat secara bertahap. Seperti yang dapat Anda lihat di Contoh 1 di halaman ini, Looker menggunakan perintah INSERT atau MERGE untuk membuat inkremen PDT inkremental. Tabel turunan tidak dapat ditentukan menggunakan pernyataan Data Definition Language (DDL) kustom, karena Looker tidak dapat menentukan pernyataan DDL mana yang diperlukan untuk membuat inkremen yang akurat.
  • Tabel sumber PDT inkremental harus dioptimalkan untuk kueri berbasis waktu. Secara khusus, kolom berbasis waktu yang digunakan untuk kunci inkremental harus memiliki strategi pengoptimalan, seperti partisi, sortkeys, indeks, atau strategi pengoptimalan apa pun yang didukung untuk dialek Anda. Pengoptimalan tabel sumber sangat direkomendasikan karena setiap kali tabel inkremental diperbarui, Looker akan membuat kueri tabel sumber untuk menentukan nilai terbaru kolom berbasis waktu yang digunakan untuk kunci inkremental. Jika tabel sumber tidak dioptimalkan untuk kueri ini, kueri Looker untuk nilai terbaru mungkin lambat dan mahal.

Menentukan PDT inkremental

Anda dapat menggunakan parameter berikut untuk mengubah PDT menjadi PDT inkremental:

  • increment_key (diperlukan untuk menjadikan PDT sebagai PDT inkremental): Menentukan jangka waktu untuk membuat kueri data baru.
  • {% incrementcondition %} Filter liquid (diperlukan untuk menjadikan PDT berbasis SQL sebagai PDT inkremental; tidak berlaku untuk PDT berbasis LookML): Menghubungkan kunci inkremental ke kolom waktu database yang menjadi dasar kunci inkremental. Lihat halaman dokumentasi increment_key untuk informasi selengkapnya.
  • increment_offset (opsional): Bilangan bulat yang menentukan jumlah jangka waktu sebelumnya (pada tingkat perincian kunci inkremental) yang di-build ulang untuk setiap build inkremental. Parameter increment_offset berguna dalam kasus data yang terlambat diterima, dengan jangka waktu sebelumnya mungkin memiliki data baru yang tidak disertakan saat inkremen yang sesuai awalnya dibuat dan ditambahkan ke PDT.

Lihat halaman dokumentasi parameter increment_key untuk mengetahui contoh yang menunjukkan cara membuat PDT inkremental dari tabel turunan native persisten, tabel turunan berbasis SQL persisten, dan tabel gabungan.

Berikut adalah contoh sederhana file tampilan yang menentukan PDT berbasis LookML inkremental:

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
  }
}

Tabel ini akan dibuat secara keseluruhan saat pertama kali kueri dijalankan di dalamnya. Setelah itu, PDT akan dibuat ulang dengan penambahan satu hari (increment_key: departure_date), mundur tiga hari (increment_offset: 3).

Kunci inkremental didasarkan pada dimensi departure_date, yang sebenarnya adalah jangka waktu date dari grup dimensi departure. (Lihat halaman dokumentasi parameter dimension_group untuk mengetahui ringkasan cara kerja grup dimensi.) Grup dimensi dan jangka waktu ditentukan dalam tampilan flights, yang merupakan explore_source untuk PDT ini. Berikut adalah cara grup dimensi departure ditentukan dalam file tampilan flights:

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

Interaksi parameter inkremental dan strategi persistensi

Setelan increment_key dan increment_offset PDT tidak bergantung pada strategi persistensi PDT:

  • Strategi persistensi PDT inkremental hanya menentukan kapan PDT bertambah. Builder PDT tidak mengubah PDT inkremental kecuali jika strategi persistensi tabel dipicu, atau kecuali jika PDT dipicu secara manual dengan opsi Rebuild Derived Tables & Run di Jelajahi.
  • Saat PDT bertambah, builder PDT akan menentukan kapan data terbaru sebelumnya ditambahkan ke tabel, dalam hal penambahan waktu terbaru (jangka waktu yang ditentukan oleh parameter increment_key). Berdasarkan hal tersebut, builder PDT akan memotong data ke awal penambahan waktu terbaru dalam tabel, lalu membuat penambahan terbaru dari sana.
  • Jika PDT memiliki parameter increment_offset, builder PDT juga akan mem-build ulang jumlah jangka waktu sebelumnya yang ditentukan dalam parameter increment_offset. Jangka waktu sebelumnya kembali mulai dari awal penambahan waktu terbaru (jangka waktu yang ditentukan oleh parameter increment_key).

Contoh skenario berikut menggambarkan cara PDT inkremental diperbarui, dengan menunjukkan interaksi increment_key, increment_offset, dan strategi persistensi.

Contoh 1

Contoh ini menggunakan PDT dengan properti berikut:

  • Kunci penambahan: tanggal
  • Increment offset: 3
  • Strategi persistensi: dipicu sebulan sekali pada hari pertama bulan

Berikut cara tabel ini akan diperbarui:

  • Strategi persistensi bulanan berarti tabel dibuat otomatis sebulan sekali. Artinya, pada 1 Juni, misalnya, baris terakhir dalam tabel akan ditambahkan pada 1 Mei.
  • Karena PDT ini memiliki kunci inkremental berdasarkan tanggal, builder PDT akan memotong 1 Mei kembali ke awal hari dan membuat ulang data untuk 1 Mei dan hingga hari ini, 1 Juni.
  • Selain itu, PDT ini memiliki offset penambahan 3. Jadi, builder PDT juga membuat ulang data dari tiga jangka waktu (hari) sebelumnya sebelum 1 Mei. Akibatnya, data akan dibuat ulang untuk tanggal 28, 29, 30 April, dan hingga hari ini, 1 Juni.

Dalam istilah SQL, berikut adalah perintah yang akan dijalankan builder PDT pada 1 Juni untuk menentukan baris dari PDT yang ada yang harus dibuat ulang:

## 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)

Berikut adalah perintah SQL yang akan dijalankan builder PDT pada 1 Juni untuk mem-build inkremen terbaru:

## 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;

Contoh 2

Contoh ini menggunakan PDT dengan properti berikut:

  • Strategi persistensi: dipicu sekali sehari
  • Kunci penambahan: month
  • Increment offset: 0

Berikut adalah cara pembaruan tabel ini pada 1 Juni:

  • Strategi persistensi harian berarti tabel dibuat secara otomatis sekali sehari. Pada 1 Juni, baris terakhir dalam tabel akan ditambahkan pada 31 Mei.
  • Karena kunci inkremental didasarkan pada bulan, builder PDT akan memotong dari 31 Mei kembali ke awal bulan dan membuat ulang data untuk seluruh bulan Mei dan hingga hari ini, termasuk 1 Juni.
  • Karena PDT ini tidak memiliki offset inkremental, tidak ada jangka waktu sebelumnya yang akan dibuat ulang.

Berikut adalah cara tabel ini akan diperbarui pada 2 Juni:

  • Pada 2 Juni, baris terakhir di tabel akan ditambahkan pada 1 Juni.
  • Karena builder PDT akan memotong kembali ke awal bulan Juni, lalu membuat ulang data mulai 1 Juni hingga hari ini, data hanya dibuat ulang untuk 1 Juni dan 2 Juni.
  • Karena PDT ini tidak memiliki offset inkremental, tidak ada jangka waktu sebelumnya yang akan dibuat ulang.

Contoh 3

Contoh ini menggunakan PDT dengan properti berikut:

  • Kunci penambahan: month
  • Increment offset: 3
  • Strategi persistensi: dipicu sekali sehari

Skenario ini mengilustrasikan penyiapan yang buruk untuk PDT inkremental, karena merupakan PDT pemicu harian dengan offset tiga bulan. Artinya, setidaknya data tiga bulan akan dibuat ulang setiap hari, yang akan menjadi penggunaan PDT inkremental yang sangat tidak efisien. Namun, ini adalah skenario yang menarik untuk diperiksa sebagai cara memahami cara kerja PDT inkremental.

Berikut adalah cara pembaruan tabel ini pada 1 Juni:

  • Strategi persistensi harian berarti tabel dibuat secara otomatis sekali sehari. Misalnya, pada 1 Juni, baris terakhir dalam tabel akan ditambahkan pada 31 Mei.
  • Karena kunci inkremental didasarkan pada bulan, builder PDT akan memotong dari 31 Mei kembali ke awal bulan dan membuat ulang data untuk seluruh bulan Mei dan hingga hari ini, termasuk 1 Juni.
  • Selain itu, PDT ini memiliki offset penambahan 3. Artinya, builder PDT juga membuat ulang data dari tiga jangka waktu (bulan) sebelumnya sebelum Mei. Hasilnya, data dibuat ulang dari Februari, Maret, April, dan hingga hari ini, 1 Juni.

Berikut adalah cara tabel ini akan diperbarui pada 2 Juni:

  • Pada 2 Juni, baris terakhir dalam tabel akan ditambahkan pada 1 Juni.
  • Builder PDT akan memotong bulan kembali ke 1 Juni dan membuat ulang data untuk bulan Juni, termasuk 2 Juni.
  • Selain itu, karena offset inkremental, builder PDT akan membuat ulang data dari tiga bulan sebelumnya sebelum Juni. Hasilnya adalah data akan dibuat ulang dari Maret, April, Mei, dan hingga hari ini, 2 Juni.

Menguji PDT inkremental dalam Mode Pengembangan

Sebelum men-deploy PDT inkremental baru ke lingkungan produksi, Anda dapat menguji PDT untuk memastikan PDT tersebut di-build dan ditambahkan. Untuk menguji PDT inkremental dalam Mode Pengembangan:

  1. Buat Jelajah untuk PDT:

    • Dalam file model terkait, gunakan parameter include untuk menyertakan file tampilan PDT dalam file model.
    • Dalam file model yang sama, gunakan parameter explore untuk membuat Jelajahi untuk tampilan PDT inkremental.
     include: "/views/e_faa_pdt.view"
 explore: e_faa_pdt {}

  2. Buka Eksplorasi untuk PDT. Untuk melakukannya, pilih tombol Lihat tindakan file, lalu pilih nama Jelajah.

  1. Di bagian Jelajahi, pilih beberapa dimensi atau ukuran, lalu klik Jalankan. Looker kemudian akan mem-build seluruh PDT. Jika ini adalah kueri pertama yang Anda jalankan di PDT inkremental, builder PDT akan mem-build seluruh PDT untuk mendapatkan data awal. Jika tabel berukuran besar, build awal mungkin memerlukan waktu yang cukup lama, seperti halnya membuat tabel besar.

  2. Anda dapat memverifikasi bahwa PDT awal telah dibuat dengan cara berikut:

    • Jika memiliki izin see_logs, Anda dapat memverifikasi bahwa tabel telah dibuat dengan melihat di Log Peristiwa PDT. Jika Anda tidak melihat peristiwa pembuatan PDT di Log Peristiwa PDT, periksa informasi status di bagian atas Jelajahi Log Peristiwa PDT. Jika tertulis "dari cache", Anda dapat memilih Hapus Cache & Muat Ulang untuk mendapatkan informasi terbaru.
    • Jika tidak, Anda dapat melihat komentar di tab SQL pada panel Data Jelajahi. Tab SQL menampilkan kueri dan tindakan yang akan dilakukan saat Anda menjalankan kueri di Jelajahi. Misalnya, jika komentar di tab SQL bertuliskan -- generate derived table e_incremental_pdt, itulah tindakan yang akan dilakukan saat Anda mengklik Run.

  3. Setelah Anda membuat build awal PDT, minta build inkremental PDT menggunakan opsi Rebuild Derived Tables & Run dari Jelajahi.

  4. Anda dapat menggunakan metode yang sama seperti sebelumnya untuk memverifikasi bahwa PDT di-build secara bertahap:

    • Jika memiliki izin see_logs, Anda dapat menggunakan Log Peristiwa PDT untuk melihat peristiwa create increment complete untuk PDT inkremental. Jika Anda tidak melihat peristiwa ini di Log Peristiwa PDT dan status kueri bertuliskan "dari cache", pilih Hapus Cache & Muat Ulang untuk mendapatkan informasi terbaru.
    • Lihat komentar di tab SQL pada panel Data Jelajahi. Dalam hal ini, komentar akan menunjukkan bahwa PDT bertambah. Misalnya: -- increment persistent derived table e_incremental_pdt to generation 2

  5. Setelah memverifikasi bahwa PDT dibuat dan bertambah dengan benar, jika tidak ingin menyimpan Jelajah khusus untuk PDT, Anda dapat menghapus atau mengomentari parameter explore dan include PDT dari file model.

Setelah PDT dibuat dalam Mode Pengembangan, tabel yang sama akan digunakan untuk produksi setelah Anda men-deploy perubahan, kecuali jika Anda membuat perubahan lebih lanjut pada definisi tabel. Lihat bagian Tabel yang dipertahankan dalam Mode Pengembangan di halaman dokumentasi Tabel turunan di Looker untuk mengetahui informasi selengkapnya.

Dialek database yang didukung untuk PDT inkremental

Agar Looker mendukung PDT inkremental dalam project Looker, dialek database Anda harus mendukung perintah Bahasa Definisi Data (DDL) yang memungkinkan penghapusan dan penyisipan baris.

Tabel berikut menunjukkan dialek yang mendukung PDT inkremental dalam rilis Looker terbaru (untuk Databricks, PDT Inkremental hanya didukung di Databricks versi 12.1 dan yang lebih tinggi):

Dialek Didukung?
Actian Avalanche
Tidak
Amazon Athena
Tidak
Amazon Aurora MySQL
Tidak
Amazon Redshift
Ya
Apache Druid
Tidak
Apache Druid 0.13+
Tidak
Apache Druid 0.18+
Tidak
Apache Hive 2.3+
Tidak
Apache Hive 3.1.2+
Tidak
Apache Spark 3+
Tidak
ClickHouse
Tidak
Cloudera Impala 3.1+
Tidak
Cloudera Impala 3.1+ dengan Driver Native
Tidak
Cloudera Impala dengan Driver Native
Tidak
DataVirtuality
Tidak
Databricks
Ya
Denodo 7
Tidak
Denodo 8
Tidak
Dremio
Tidak
Dremio 11+
Tidak
Exasol
Tidak
Firebolt
Tidak
Legacy SQL Google BigQuery
Tidak
SQL Standar Google BigQuery
Ya
Google Cloud PostgreSQL
Ya
Google Cloud SQL
Tidak
Google Spanner
Tidak
Greenplum
Ya
HyperSQL
Tidak
IBM Netezza
Tidak
MariaDB
Tidak
Microsoft Azure PostgreSQL
Ya
Microsoft Azure SQL Database
Tidak
Microsoft Azure Synapse Analytics
Ya
Microsoft SQL Server 2008+
Tidak
Microsoft SQL Server 2012+
Tidak
Microsoft SQL Server 2016
Tidak
Microsoft SQL Server 2017+
Tidak
MongoBI
Tidak
MySQL
Ya
MySQL 8.0.12+
Ya
Oracle
Tidak
Oracle ADWC
Tidak
PostgreSQL 9.5+
Ya
PostgreSQL versi pra-9.5
Ya
PrestoDB
Tidak
PrestoSQL
Tidak
SAP HANA 2+
Tidak
SingleStore
Tidak
SingleStore 7+
Tidak
Snowflake
Ya
Teradata
Tidak
Trino
Tidak
Vektor
Tidak
Vertica
Ya