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:
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
, atauinterval_trigger
). PDT inkremental tidak didukung untuk PDT yang menggunakan strategi persistensipersist_for
. - Untuk PDT berbasis SQL, kueri tabel harus ditentukan menggunakan parameter
sql
agar dapat digunakan sebagai PDT inkremental. PDT berbasis SQL yang ditentukan dengan parametersql_create
atau parametercreate_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 dokumentasiincrement_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. Parameterincrement_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 parameterincrement_offset
. Jangka waktu sebelumnya kembali dimulai dari awal penambahan waktu terbaru (jangka waktu yang ditentukan oleh parameterincrement_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:
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 {}
- Dalam file model terkait, gunakan parameter
Buka Jelajahi untuk PDT. Untuk melakukannya, pilih tombol See file actions, lalu pilih nama Explore.
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.
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
itulah tindakan yang akan diambil saat Anda mengklik Run.-- generate derived table e_incremental_pdt
,
- Jika memiliki izin
Setelah membuat build awal PDT, minta build inkremental PDT menggunakan opsi Rebuild Derived Tables & Run dari Explore.
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 peristiwacreate 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
- Jika memiliki izin
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
daninclude
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 |