Google menggunakan teknologi AI untuk menerjemahkan konten ke dalam bahasa pilihan Anda. Terjemahan AI mungkin mengandung kesalahan.

PDT inkremental

Di Looker, tabel turunan persisten (PDT) ditulis ke skema sementara basis data Anda. Looker mempertahankan dan membangun ulang PDT berdasarkan strategi persistennya. Saat PDT dipicu untuk dibangun ulang, secara default Looker akan membangun ulang seluruh tabel.

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

Tabel besar dengan tiga baris bawah yang disoroti 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 membuat seluruh PDT untuk mendapatkan data awal. Jika tabelnya besar, build awal mungkin memerlukan waktu yang cukup lama, seperti halnya membangun tabel besar lainnya. Setelah tabel awal dibuat, build berikutnya akan bersifat inkremental dan akan membutuhkan 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 (trigger-based persistence strategy). datagroup_trigger, sql_trigger_value, atauinterval_trigger PDT inkremental tidak didukung untuk PDT yang menggunakanpersist_for strategi persistensi.
Untuk PDT berbasis SQL, kueri tabel harus didefinisikan menggunakansql parameter yang akan digunakan sebagai PDT inkremental. PDT berbasis SQL yang ditentukan dengan parameter sql_create atau parameter create_process tidak dapat dibuat secara inkremental. Seperti yang Anda lihat pada Contoh 1 di halaman ini, Looker menggunakan perintah INSERT atau MERGE untuk membuat penambahan untuk PDT inkremental. Tabel turunan tidak dapat ditentukan menggunakan pernyataan Bahasa Definisi Data (DDL) kustom, karena Looker tidak akan dapat menentukan pernyataan DDL mana yang diperlukan untuk membuat inkrement 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, kunci pengurutan, indeks, atau strategi pengoptimalan apa pun yang didukung untuk dialek Anda. Pengoptimalan tabel sumber sangat disarankan karena setiap kali tabel inkremental diperbarui, Looker akan melakukan kueri ke tabel sumber untuk menentukan nilai terbaru dari 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 agar PDT menjadi PDT inkremental): Menentukan periode waktu di mana catatan baru harus dicari.
{% incrementcondition %} Filter Liquid (diperlukan untuk membuat PDT berbasis SQL menjadi 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 mengetahui informasi selengkapnya.
increment_offset (opsional): Bilangan bulat yang menentukan jumlah periode waktu sebelumnya (pada perincian kunci inkremental) yang dibangun ulang untuk setiap build inkremental. Parameter increment_offset berguna dalam kasus data yang terlambat tiba, yang mana periode 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 inkremental berbasis LookML:

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 pada saat pertama kali kueri dijalankan padanya. Setelah itu, PDT akan dibangun ulang dengan inkrementasi satu hari (increment_key: departure_date), kembali ke tiga hari (increment_offset: 3).

Kunci penambahan didasarkan pada dimensi departure_date, yang sebenarnya adalah date timeframe 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 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 diinkrementalkan. Pembuat PDT tidak mengubah PDT inkremental kecuali jika strategi persistensi tabel dipicu, atau PDT dipicu secara manual dengan opsi Bangun Ulang Tabel Turunan & Jalankan di Eksplorasi.
Ketika PDT bertambah, pembuat PDT akan menentukan kapan data terbaru sebelumnya ditambahkan ke tabel, dalam hal penambahan waktu terkini (periode waktu yang ditentukan oleh parameter increment_key). Berdasarkan hal tersebut, pembuat PDT akan memotong data ke awal interval waktu terbaru dalam tabel, lalu membangun interval terbaru dari sana.
Jika PDT memiliki parameter increment_offset, pembuat PDT juga akan membangun ulang jumlah periode waktu sebelumnya yang ditentukan dalam parameter increment_offset. Periode waktu sebelumnya dimulai dari awal kenaikan waktu yang paling baru (periode 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
Offset inkremental: 3
Strategi persisten: dipicu sebulan sekali pada hari pertama setiap bulan

Berikut cara tabel ini akan diperbarui:

Strategi persistensi bulanan berarti tabel dibuat secara 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, pembuat PDT akan memangkas 1 Mei kembali ke awal hari dan membangun kembali data untuk 1 Mei hingga hari ini, 1 Juni.
Selain itu, PDT ini memiliki offset inkremental 3. Jadi, PDT builder juga membangun ulang data dari tiga periode waktu (hari) sebelumnya sebelum 1 Mei. Hasilnya, data dibangun kembali untuk tanggal 28, 29, 30 April, dan hingga hari ini, 1 Juni.

Dalam istilah SQL, berikut adalah perintah yang akan dijalankan oleh builder PDT pada 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 berikut adalah perintah SQL yang akan dijalankan oleh pembuat PDT pada tanggal 1 Juni untuk membuat 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: bulan
Offset inkremental: 0

Berikut cara tabel ini akan 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 inkremental didasarkan pada bulan, PDT builder akan memangkas dari 31 Mei kembali ke awal bulan dan membangun kembali data untuk seluruh bulan Mei dan hingga hari ini, termasuk 1 Juni.
Karena PDT ini tidak memiliki offset inkremental, tidak ada periode waktu sebelumnya yang dibangun ulang.

Berikut cara tabel ini akan diperbarui pada 2 Juni:

Pada 2 Juni, baris terakhir di tabel akan ditambahkan pada 1 Juni.
Karena pembuat PDT akan memotong data hingga awal bulan Juni, lalu membangun kembali data mulai dari tanggal 1 Juni hingga hari ini, data yang dibangun kembali hanya untuk tanggal 1 Juni dan 2 Juni.
Karena PDT ini tidak memiliki offset inkremental, tidak ada periode waktu sebelumnya yang dibangun ulang.

Contoh 3

Contoh ini menggunakan PDT dengan properti berikut:

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

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

Berikut cara tabel ini akan diperbarui pada 1 Juni:

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

Berikut cara tabel ini akan diperbarui pada 2 Juni:

Pada 2 Juni, baris terakhir dalam tabel akan ditambahkan pada 1 Juni.
Pembuat PDT akan memangkas bulan kembali ke 1 Juni dan membangun kembali data untuk bulan Juni, termasuk 2 Juni.
Selain itu, karena offset inkremental, builder PDT akan membangun ulang data dari tiga bulan sebelumnya sebelum bulan Juni. Hasilnya, data disusun ulang mulai dari bulan Maret, April, Mei, hingga hari ini, 2 Juni.

Menguji PDT inkremental dalam Mode Pengembangan

Sebelum menerapkan PDT inkremental baru ke lingkungan produksi Anda, Anda dapat menguji PDT tersebut untuk memastikan bahwa PDT tersebut berhasil dibuat dan bertambah. Untuk menguji PDT inkremental dalam Mode Pengembangan:

Buat Eksplorasi 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 Eksplorasi untuk tampilan PDT inkremental.
```
 include: "/views/e_faa_pdt.view"
 explore: e_faa_pdt {}
```
Buka Eksplorasi untuk PDT. Untuk melakukannya, pilih tombol Lihat tindakan file, lalu pilih nama Eksplorasi.

Di Eksplorasi, pilih beberapa dimensi atau ukuran, lalu klik Jalankan. Kemudian, Looker akan membangun seluruh PDT. Jika ini adalah kueri pertama yang Anda jalankan di PDT inkremental, builder PDT akan membuat seluruh PDT untuk mendapatkan data awal. Jika tabelnya besar, build awal mungkin memerlukan waktu yang cukup lama, seperti halnya membangun tabel besar lainnya.
Anda dapat memverifikasi bahwa PDT awal telah dibangun dengan cara-cara berikut:
- Jika Anda memilikisee_logs Dengan izin tersebut, Anda dapat memverifikasi bahwa tabel telah dibuat dengan melihat diCatatan 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.
- Atau, Anda dapat melihat komentar di tab SQL pada panel Data Eksplorasi. Tab SQL menampilkan kueri dan tindakan yang akan dilakukan saat Anda menjalankan kueri di Eksplorasi. Misalnya, jika komentar di tab SQL bertuliskan -- generate derived table e_incremental_pdt, tindakan tersebut akan dilakukan saat Anda mengklik Jalankan.
Setelah membuat build awal PDT, picu build inkremental PDT menggunakan opsi Bangun Ulang Tabel Turunan & Jalankan dari Jelajah.
Anda dapat menggunakan metode yang sama seperti sebelumnya untuk memverifikasi bahwa PDT dibangun secara inkremental:
- Jika memiliki izin see_logs, Anda dapat menggunakan PDT Event Log untuk melihat peristiwa create increment complete untuk PDT inkremental. Jika Anda tidak melihat kejadian ini di Log Kejadian PDT dan status kueri menunjukkan "dari cache," pilih Bersihkan Cache & Segarkan untuk mendapatkan informasi yang lebih baru.
- Lihat komentar di tab SQL pada panel Data di Explore. Dalam hal ini, komentar akan menunjukkan bahwa PDT telah ditingkatkan. Contoh: -- increment persistent derived table e_incremental_pdt to generation 2
Setelah Anda memverifikasi bahwa PDT dibuat dan di-increment dengan benar, jika tidak ingin menyimpan Eksplorasi 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 persisten dalam Mode Pengembangan di halaman dokumentasi Tabel turunan di Looker untuk mengetahui informasi selengkapnya.

Penyelesaian masalah PDT inkremental

Bagian ini menjelaskan beberapa masalah umum yang mungkin Anda alami saat menggunakan PDT inkremental, serta langkah-langkah untuk memecahkan masalah dan menyelesaikannya.

PDT inkremental gagal dibuat setelah perubahan skema

Jika PDT inkremental Anda adalah tabel turunan berbasis SQL, dan parameter sql menyertakan karakter wildcard seperti SELECT *, maka perubahan pada skema basis data yang mendasarinya (seperti penambahan kolom, penghapusan kolom, atau perubahan tipe data kolom) dapat menyebabkan PDT gagal dengan kesalahan berikut:

SQL Error in incremental PDT: Query execution failed

Untuk mengatasi masalah ini, ubah pernyataan SELECT pada parameter sql agar memilih kolom individual. Misalnya, jika klausa select Anda adalah SELECT *, ubahlah menjadi SELECT column1, column2, ....

Jika skema Anda berubah dan Anda ingin membangun ulang PDT inkremental Anda dari awal, gunakan panggilan API.start_pdt_build, dan mencakupfull_force_incremental parameter.

Dialek basis data yang didukung untuk PDT inkremental

Agar Looker dapat mendukung PDT inkremental dalam project Looker Anda, dialek database Anda harus mendukung perintah bahasa definisi data (DDL) yang memungkinkan penghapusan dan penyisipan baris.

Tabel berikut menunjukkan dialek mana 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
Amazon Athena
Amazon Aurora MySQL
Amazon Redshift
Amazon Redshift 2.1+
Amazon Redshift Serverless 2.1+
Apache Druid
Apache Druid 0.13.x - 0.17.x
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 AlloyDB for PostgreSQL
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
MongoSQL
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

PDT inkremental Tetap teratur dengan koleksi Simpan dan kategorikan konten berdasarkan preferensi Anda.

Menentukan PDT inkremental

Interaksi parameter inkremental dan strategi persistensi

Contoh 1

Contoh 2

Contoh 3

Menguji PDT inkremental dalam Mode Pengembangan

Penyelesaian masalah PDT inkremental

PDT inkremental gagal dibuat setelah perubahan skema

Dialek basis data yang didukung untuk PDT inkremental

PDT inkremental