PDT inkremental

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

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

Tabel besar dengan tiga baris bawah yang disorot 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 menjalankan kueri pada PDT inkremental, Looker akan mem-build seluruh PDT untuk mendapatkan data awal. Jika tabel berukuran besar, build awal mungkin akan memakan waktu yang cukup lama, seperti halnya membuat tabel besar. Setelah tabel awal dibuat, build berikutnya akan bersifat inkremental dan akan memakan 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 pada Contoh 1 di halaman ini, Looker menggunakan perintah INSERT atau merge untuk membuat kenaikan PDT inkremental. Tabel turunan tidak dapat ditentukan menggunakan pernyataan Data Definition Language (DDL) kustom karena Looker tidak akan dapat menentukan pernyataan DDL mana yang diperlukan untuk membuat kenaikan yang akurat.
  • Tabel sumber PDT inkremental harus dioptimalkan untuk kueri berbasis waktu. Secara khusus, kolom berbasis waktu yang digunakan untuk kunci penambahan harus memiliki strategi pengoptimalan, seperti partisi, sortkeys, indeks, atau strategi pengoptimalan apa pun yang didukung untuk dialek Anda. Pengoptimalan tabel sumber sangat disarankan karena setiap kali tabel inkremental diperbarui, Looker akan mengkueri 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 akan 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 kueri untuk 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 dibuat ulang untuk setiap build inkremental. Parameter increment_offset berguna dalam kasus data yang terlambat tiba, saat jangka waktu sebelumnya mungkin memiliki data baru yang tidak disertakan saat penambahan 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 utuh secara keseluruhan saat pertama kali kueri dijalankan. Setelah itu, PDT akan dibuat ulang dalam kelipatan satu hari (increment_key: departure_date), kembali ke tiga hari sebelumnya (increment_offset: 3).

Kunci penambahan didasarkan pada dimensi departure_date, yang sebenarnya merupakan rentang waktu date dari grup dimensi departure. (Lihat halaman dokumentasi parameter dimension_group untuk 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 strategi persistensi tabel dipicu, atau kecuali PDT dipicu secara manual dengan opsi Rebuild Derived Tables & Run dalam Jelajah.
  • Jika 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 itu, builder PDT akan memotong data ke awal penambahan waktu terbaru dalam tabel, lalu membuat kenaikan terbaru dari sana.
  • Jika PDT memiliki parameter increment_offset, builder PDT juga akan membangun ulang jumlah jangka waktu sebelumnya yang ditentukan dalam parameter increment_offset. Jangka waktu sebelumnya kembali dimulai dari awal penambahan waktu terbaru (jangka waktu yang ditentukan oleh parameter increment_key).

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

Contoh 1

Contoh ini menggunakan PDT dengan properti berikut:

  • Kunci penambahan: tanggal
  • Offset penambahan: 3
  • Strategi persistensi: dipicu sebulan sekali pada hari pertama setiap bulan

Berikut adalah cara tabel ini diperbarui:

  • Strategi persistensi bulanan berarti tabel dibuat secara otomatis sebulan sekali. Ini berarti bahwa 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 membangun kembali data untuk tanggal 1 Mei dan hingga hari ini, 1 Juni.
  • Selain itu, PDT ini memiliki offset pertambahan 3. Jadi builder PDT juga membangun kembali data dari tiga periode waktu (hari) sebelumnya sebelum 1 Mei. Hasilnya adalah data tersebut dibuat ulang untuk tanggal 28, 29, 30 April, dan hingga 1 Juni saat ini.

Dalam istilah SQL, berikut adalah perintah bahwa builder PDT akan berjalan pada tanggal 1 Juni untuk menentukan baris dari PDT yang ada yang harus dibangun 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)

Dan inilah perintah SQL yang akan dijalankan oleh PDT builder pada tanggal 1 Juni untuk membuat inkremental 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: bulan
  • Offset penambahan: 0

Berikut adalah cara tabel ini diperbarui 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 penambahan didasarkan pada bulan, pembuat PDT akan memotong dari 31 Mei kembali ke awal bulan dan membangun ulang data untuk semua bulan Mei dan hingga hari ini, termasuk 1 Juni.
  • Karena PDT ini tidak memiliki offset penambahan, tidak ada jangka waktu sebelumnya yang dibuat ulang.

Berikut adalah cara tabel ini diperbarui pada tanggal 2 Juni:

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

Contoh 3

Contoh ini menggunakan PDT dengan properti berikut:

  • Kunci penambahan: bulan
  • Offset penambahan: 3
  • Strategi persistensi: dipicu sekali sehari

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

Berikut adalah cara tabel ini diperbarui 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 penambahan didasarkan pada bulan, pembuat PDT akan memotong dari 31 Mei kembali ke awal bulan dan membangun ulang data untuk semua bulan Mei dan hingga hari ini, termasuk 1 Juni.
  • Selain itu, PDT ini memiliki offset pertambahan 3. Ini berarti bahwa pembuat PDT juga membangun kembali data dari tiga jangka waktu (bulan) sebelumnya sebelum bulan Mei. Hasilnya adalah data tersebut dibuat ulang dari bulan Februari, Maret, April, dan hingga hari ini, 1 Juni.

Berikut adalah cara tabel ini diperbarui pada tanggal 2 Juni:

  • Pada tanggal 2 Juni, baris terakhir dalam tabel akan ditambahkan pada tanggal 1 Juni.
  • Builder PDT akan memotong bulan kembali ke 1 Juni dan membangun ulang data untuk bulan Juni, termasuk 2 Juni.
  • Selain itu, karena kompensasi kenaikan, builder PDT akan membangun ulang data dari tiga bulan sebelumnya sebelum bulan Juni. Hasilnya adalah data tersebut dibuat ulang dari bulan Maret, April, Mei, dan hingga hari ini, yaitu 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 dibangun dan bertambah. 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 guna membuat Jelajah untuk tampilan PDT inkremental.
     include: "/views/e_faa_pdt.view"
 explore: e_faa_pdt {}

  2. Buka Jelajahi untuk PDT. Untuk melakukannya, pilih tombol See file actions, lalu pilih nama Explore.

  1. Di bagian Explore, pilih beberapa dimensi atau ukuran, lalu klik Run. Looker kemudian akan membangun seluruh PDT. Jika ini adalah kueri pertama yang Anda jalankan pada PDT inkremental, builder PDT akan membangun seluruh PDT untuk mendapatkan data awal. Jika tabel berukuran besar, build awal mungkin akan memakan waktu yang cukup lama, seperti halnya membuat tabel besar.

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

    • Jika memiliki izin see_logs, Anda dapat memverifikasi bahwa tabel dibuat dengan melihat di Log Peristiwa PDT. Jika Anda tidak melihat peristiwa pembuatan PDT di Log Peristiwa PDT, periksa informasi status di bagian atas Penjelajahan 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 di Explore. Tab SQL menampilkan kueri dan tindakan yang akan diambil saat Anda menjalankan kueri di Explore. Misalnya, jika komentar di tab SQL bertuliskan -- generate derived table e_incremental_pdt, itulah tindakan yang akan diambil saat Anda mengklik Run.

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

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

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

  5. Setelah memverifikasi bahwa PDT telah dibuat dan bertambah dengan benar, jika tidak ingin menyimpan Explore khusus untuk PDT, Anda dapat menghapus atau menjadikan 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 persisten dalam Mode Pengembangan di halaman dokumentasi Tabel turunan di Looker untuk mengetahui informasi selengkapnya.

Dialek database yang didukung untuk PDT inkremental

Agar Looker dapat mendukung PDT inkremental dalam project Looker, dialek database Anda harus mendukung perintah Data Definition Language (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 baru):

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 dan yang lebih baru
Tidak
Apache Hive 3.1.2+
Tidak
Apache Spark 3+
Tidak
ClickHouse
Tidak
Cloudera Impala 3.1+
Tidak
Cloudera Impala 3.1+ dengan Native Driver
Tidak
Cloudera Impala dengan Native Driver
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
PostgreSQL Google Cloud
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 9.5
Ya
PrestoDB
Tidak
PrestoSQL
Tidak
SAP HANA
Tidak
SAP HANA 2+
Tidak
SingleStore
Tidak
SingleStore 7+
Tidak
Snowflake
Ya
Teradata
Tidak
Trino
Tidak
Vector
Tidak
Vertica
Ya