PDT inkremental

Di Looker, tabel turunan persisten (PDT) ditulis ke skema sementara database 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 tabel, bukan membangun ulang tabel secara keseluruhan:

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

• Tabel gabungan
• PDT berbasis LookML (asli)
• PDT berbasis SQL

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 (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 inkremental. Seperti yang dapat Anda lihat di Contoh 1 di halaman ini, Looker menggunakan perintah INSERT atau MERGE untuk membuat inkremen 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 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 (wajib untuk menjadikan PDT sebagai PDT inkremental): Menentukan jangka waktu untuk kueri data baru.
• {% 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, di 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 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 sepenuhnya saat kueri dijalankan untuk pertama kalinya. Setelah itu, PDT akan dibangun ulang secara bertahap setiap hari (increment_key: departure_date), kembali ke tiga hari sebelumnya (increment_offset: 3).

Kunci inkremental didasarkan pada dimensi departure_date, yang sebenarnya merupakan 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 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.
• Saat PDT bertambah, builder PDT akan menentukan kapan data terbaru sebelumnya ditambahkan ke tabel, dalam hal kenaikan waktu terbaru (periode waktu yang ditentukan oleh parameter increment_key). Berdasarkan hal tersebut, builder PDT akan memangkas data ke awal kenaikan waktu terbaru dalam tabel, lalu membuat kenaikan terbaru dari sana.
• Jika PDT memiliki parameter increment_offset, builder PDT juga akan membangun ulang jumlah periode waktu sebelumnya yang ditentukan dalam parameter increment_offset. Periode waktu sebelumnya dimulai dari awal kenaikan waktu terbaru (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, pembuat PDT juga membangun kembali data dari tiga periode waktu (hari) sebelumnya sebelum 1 Mei. Hasilnya adalah data dibangun ulang untuk 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)

Berikut adalah perintah SQL yang akan dijalankan oleh builder PDT pada 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 persisten: 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 memangkas kembali ke awal bulan Juni, lalu membangun kembali data mulai 1 Juni hingga hari ini, data hanya dibangun kembali untuk 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 persisten: 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, ini adalah skenario 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. Misalnya, 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.
• 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 bulan Februari, Maret, April, dan 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 inkremen, pembuat PDT akan membangun ulang data dari tiga bulan sebelumnya sebelum bulan Juni. Hasilnya adalah data dibangun ulang dari bulan 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 dibuat dan diinkrementalkan. 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 Eksplorasi 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 Eksplorasi.

1. Di Eksplorasi, pilih beberapa dimensi atau ukuran, lalu klik Jalankan. Kemudian, Looker akan membangun seluruh PDT. Jika ini adalah kueri pertama yang Anda jalankan pada 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.

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

   • Jika memiliki izin see_logs, Anda dapat memverifikasi bahwa tabel dibuat dengan melihat Log Peristiwa PDT. Jika Anda tidak melihat peristiwa pembuatan PDT di Log Peristiwa PDT, periksa informasi status di bagian atas Eksplorasi 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 kolom Data di 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, maka itulah tindakan yang akan dilakukan saat Anda mengklik Jalankan.

3. Setelah membuat build awal PDT, minta build inkremental PDT menggunakan opsi Bangun Ulang Tabel Turunan & Jalankan dari Jelajah.

4. 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 peristiwa ini di Log Peristiwa 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 Eksplorasi. Dalam hal ini, komentar akan menunjukkan bahwa PDT telah di-increment. Contoh: -- increment persistent derived table e_incremental_pdt to generation 2

5. 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.

Memecahkan 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 pengganti seperti SELECT *, perubahan pada skema database pokok Anda (seperti penambahan kolom, penghapusan kolom, atau perubahan jenis data kolom) dapat menyebabkan PDT gagal dengan error berikut:

SQL Error in incremental PDT: Query execution failed

Untuk mengatasi masalah ini, edit pernyataan SELECT dalam parameter sql untuk memilih masing-masing kolom. Misalnya, jika klausa select Anda adalah SELECT *, ubah menjadi SELECT column1, column2, ....

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

Dialek database yang didukung untuk PDT inkremental

Agar Looker mendukung PDT inkremental di 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):