Tabel turunan di Looker

Di Looker, tabel turunan adalah kueri yang hasilnya digunakan seolah-olah merupakan tabel yang sebenarnya dalam database.

Misalnya, Anda mungkin memiliki tabel database bernama orders yang memiliki banyak kolom. Anda ingin menghitung beberapa metrik gabungan tingkat pelanggan, seperti berapa banyak pesanan yang dilakukan setiap pelanggan atau kapan setiap pelanggan melakukan pemesanan pertama mereka. Dengan menggunakan tabel turunan native atau tabel turunan berbasis SQL, Anda dapat membuat tabel database baru bernama customer_order_summary yang menyertakan metrik ini.

Anda kemudian dapat menggunakan tabel turunan customer_order_summary seolah-olah tabel tersebut adalah tabel lain dalam database.

Untuk kasus penggunaan tabel turunan populer, buka Buku masak Looker: Mendapatkan hasil maksimal dari tabel turunan di Looker.

Tabel turunan native dan tabel turunan berbasis SQL

Untuk membuat tabel turunan di project Looker, gunakan parameter derived_table pada parameter view. Di dalam parameter derived_table, Anda dapat menentukan kueri untuk tabel turunan dengan salah satu dari dua cara:

• Untuk tabel turunan native, Anda menentukan tabel turunan dengan kueri berbasis LookML.
• Untuk tabel turunan berbasis SQL, Anda menentukan tabel turunan dengan kueri SQL.

Misalnya, file tampilan berikut menunjukkan cara menggunakan LookML untuk membuat tampilan dari tabel turunan customer_order_summary. Dua versi LookML menggambarkan bagaimana Anda dapat membuat tabel turunan yang setara menggunakan LookML atau SQL untuk menentukan kueri bagi tabel turunan:

• Tabel turunan native menentukan kueri dengan LookML dalam parameter explore_source. Dalam contoh ini, kueri didasarkan pada tampilan orders yang ada, yang ditentukan dalam file terpisah yang tidak ditampilkan dalam contoh ini. Kueri explore_source dalam tabel turunan native menghadirkan kolom customer_id, first_order, dan total_amount dari file tampilan orders.
• Tabel turunan berbasis SQL menentukan kueri menggunakan SQL dalam parameter sql. Dalam contoh ini, kueri SQL adalah kueri langsung dari tabel orders dalam database.

Versi tabel turunan native

view: customer_order_summary {
  derived_table: {
    explore_source: orders {
      column: customer_id {
        field: orders.customer_id
      }
      column: first_order {
        field: orders.first_order
      }
      column: total_amount {
        field: orders.total_amount
      }
    }
  }
  dimension: customer_id {
    type: number
    primary_key: yes
    sql: ${TABLE}.customer_id ;;
  }
  dimension_group: first_order {
    type: time
    timeframes: [date, week, month]
    sql: ${TABLE}.first_order ;;
  }
  dimension: total_amount {
    type: number
    value_format: "0.00"
    sql: ${TABLE}.total_amount ;;
  }
}

Versi tabel turunan berbasis SQL

view: customer_order_summary {
  derived_table: {
    sql:
      SELECT
        customer_id,
        MIN(DATE(time)) AS first_order,
        SUM(amount) AS total_amount
      FROM
        orders
      GROUP BY
        customer_id ;;
  }
  dimension: customer_id {
    type: number
    primary_key: yes
    sql: ${TABLE}.customer_id ;;
  }
  dimension_group: first_order {
    type: time
    timeframes: [date, week, month]
    sql: ${TABLE}.first_order ;;
  }
  dimension: total_amount {
    type: number
    value_format: "0.00"
    sql: ${TABLE}.total_amount ;;
  }
}

Kedua versi membuat tampilan yang disebut customer_order_summary yang didasarkan pada tabel orders, dengan kolom customer_id, first_order,, dan total_amount.

Selain parameter derived_table dan subparameternya, tampilan customer_order_summary ini berfungsi seperti file tampilan lainnya. Apakah Anda menentukan kueri tabel turunan dengan LookML atau dengan SQL, Anda dapat membuat ukuran dan dimensi LookML yang didasarkan pada kolom tabel turunan.

Setelah menentukan tabel turunan, Anda dapat menggunakannya seperti tabel lainnya dalam {i>database<i} Anda.

Tabel turunan native

Tabel turunan native didasarkan pada kueri yang Anda tentukan menggunakan istilah LookML. Untuk membuat tabel turunan native, gunakan parameter explore_source di dalam parameter derived_table parameter tampilan. Anda membuat kolom tabel turunan native dengan merujuk ke dimensi atau ukuran LookML dalam model Anda. Lihat file tampilan tabel turunan native di contoh sebelumnya.

Dibandingkan dengan tabel turunan berbasis SQL, tabel turunan native jauh lebih mudah dibaca dan dipahami saat Anda membuat model data.

Lihat halaman dokumentasi Membuat tabel turunan native untuk detail tentang cara membuat tabel turunan native.

tabel turunan berbasis SQL

Untuk membuat tabel turunan berbasis SQL, Anda menentukan kueri dalam istilah SQL, membuat kolom dalam tabel menggunakan kueri SQL. Anda tidak dapat merujuk ke dimensi dan ukuran LookML dalam tabel turunan berbasis SQL. Lihat file tampilan tabel turunan berbasis SQL di contoh sebelumnya.

Biasanya, Anda menentukan kueri SQL menggunakan parameter sql di dalam parameter derived_table dari parameter view.

Pintasan yang bermanfaat untuk membuat kueri berbasis SQL di Looker adalah menggunakan SQL Runner untuk membuat kueri SQL dan mengubahnya menjadi definisi tabel turunan.

Kasus ekstrem tertentu tidak akan mengizinkan penggunaan parameter sql. Dalam kasus tersebut, Looker mendukung parameter berikut untuk menentukan kueri SQL untuk tabel turunan persisten (PDT):

• create_process: Saat Anda menggunakan parameter sql untuk PDT, di latar belakang, Looker akan menggabungkan CREATE TABLE pernyataan Data Definition Language (DDL) dialek di sekitar kueri Anda untuk membuat PDT dari kueri SQL. Beberapa dialek tidak mendukung pernyataan CREATE TABLE SQL dalam satu langkah. Untuk dialek ini, Anda tidak dapat membuat PDT dengan parameter sql. Sebagai gantinya, Anda dapat menggunakan parameter create_process untuk membuat PDT dalam beberapa langkah. Lihat halaman dokumentasi parameter create_process untuk mengetahui informasi dan contohnya.
• sql_create: Jika kasus penggunaan Anda memerlukan perintah DDL kustom dan dialek Anda mendukung DDL (misalnya, BigQuery ML prediktif Google), Anda dapat menggunakan parameter sql_create untuk membuat PDT, bukan menggunakan parameter sql. Lihat halaman dokumentasi sql_create untuk mengetahui informasi dan contoh.

Baik Anda menggunakan parameter sql, create_process, atau sql_create, dalam semua kasus ini, Anda menentukan tabel turunan dengan kueri SQL, sehingga semuanya dianggap sebagai tabel turunan berbasis SQL.

Saat Anda menentukan tabel turunan berbasis SQL, pastikan untuk memberi setiap kolom alias yang bersih menggunakan AS. Hal ini karena Anda harus mereferensikan nama kolom hasil yang ditetapkan dalam dimensi Anda, seperti ${TABLE}.first_order. Itulah sebabnya contoh sebelumnya menggunakan MIN(DATE(time)) AS first_order, bukan MIN(DATE(time)).

Catatan: Untuk digunakan sebagai PDT inkremental, tabel turunan berbasis SQL harus ditentukan menggunakan parameter sql. Tabel turunan berbasis SQL yang ditentukan dengan parameter sql_create atau parameter create_process tidak dapat dibuat secara inkremental.

Tabel turunan sementara dan persisten

Selain perbedaan antara tabel turunan native dan tabel turunan berbasis SQL, ada juga perbedaan antara tabel turunan sementara — yang tidak ditulis ke database — dan tabel turunan persisten (PDT) — yang ditulis ke skema di database Anda.

Tabel turunan native dan tabel turunan berbasis SQL dapat bersifat sementara atau persisten.

Tabel turunan sementara

Tabel turunan yang ditampilkan sebelumnya adalah contoh tabel turunan sementara. Hal ini bersifat sementara karena tidak ada strategi persistensi yang ditentukan dalam parameter derived_table.

Tabel turunan sementara tidak ditulis ke database. Saat pengguna menjalankan kueri Jelajah yang melibatkan satu atau beberapa tabel turunan, Looker akan membuat kueri SQL menggunakan kombinasi SQL khusus dialek untuk tabel turunan ditambah kolom yang diminta, gabungan, dan nilai filter. Jika kombinasi telah dijalankan sebelumnya dan hasilnya masih valid dalam cache, Looker akan menggunakan hasil yang di-cache. Lihat halaman dokumentasi Kueri cache untuk mengetahui informasi selengkapnya tentang penyimpanan kueri dalam cache di Looker.

Jika tidak, jika Looker tidak dapat menggunakan hasil yang di-cache, Looker harus menjalankan kueri baru di database Anda setiap kali pengguna meminta data dari tabel turunan sementara. Karena itu, Anda harus yakin bahwa tabel turunan sementara memiliki performa dan tidak akan memberikan beban berlebihan pada database Anda. Jika kueri memerlukan waktu beberapa saat untuk dijalankan, PDT sering kali merupakan opsi yang lebih baik.

Dialek database yang didukung untuk tabel turunan sementara

Agar Looker dapat mendukung tabel turunan dalam project Looker, dialek database Anda juga harus mendukung tabel turunan tersebut. Tabel berikut menunjukkan dialek mana yang mendukung tabel turunan dalam rilis Looker terbaru:

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

Tabel turunan persisten

Tabel turunan persisten (PDT) adalah tabel turunan yang ditulis ke dalam skema awal di database Anda dan dibuat ulang sesuai jadwal yang Anda tentukan dengan strategi persistensi.

PDT dapat berupa tabel turunan native atau tabel turunan berbasis SQL.

Persyaratan untuk PDT

Untuk menggunakan tabel turunan persisten (PDT) dalam project Looker, Anda memerlukan hal berikut:

• Dialek {i>database<i} yang mendukung PDT. Lihat bagian Dialek database yang didukung untuk PDT nanti di halaman ini guna mengetahui daftar dialek yang mendukung tabel turunan berbasis SQL persisten dan tabel turunan native persisten.
• Skema awal pada database Anda. Skema ini dapat berupa skema apa pun di database Anda, tetapi sebaiknya buat skema baru yang hanya akan digunakan untuk tujuan ini. Administrator database Anda harus mengonfigurasi skema dengan izin tulis untuk pengguna database Looker.
• Koneksi Looker yang dikonfigurasi dengan tombol Enable PDTs diaktifkan. Opsi ini biasanya disiapkan saat Anda pertama kali mengonfigurasi koneksi Looker (lihat halaman dokumentasi Dialek Looker untuk mengetahui petunjuk dialek database), tetapi Anda juga dapat mengaktifkan PDT untuk koneksi setelah penyiapan awal.

Dialek database yang didukung untuk PDT

Agar Looker dapat mendukung tabel turunan persisten (PDT) dalam project Looker Anda, dialek database Anda juga harus mendukung tabel turunan tersebut.

Untuk mendukung semua jenis PDT (baik yang berbasis LookML atau berbasis SQL), dialek harus mendukung penulisan ke database, di antara persyaratan lainnya. Ada beberapa konfigurasi database hanya baca yang tidak mengizinkan persistensi berfungsi (umumnya database replika hot-swap Postgres). Dalam kasus ini, Anda dapat menggunakan tabel turunan sementara.

Tabel berikut menunjukkan dialek yang mendukung tabel turunan berbasis SQL persisten dalam rilis terbaru Looker:

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

Untuk mendukung tabel turunan native persisten (yang memiliki kueri berbasis LookML), dialek juga harus mendukung fungsi DDL CREATE TABLE. Berikut adalah daftar dialek yang mendukung tabel turunan native (berbasis LookML) persisten dalam rilis terbaru Looker:

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

Catatan: PDT tidak didukung untuk koneksi Snowflake yang menggunakan OAuth.

Membangun PDT secara bertahap

PDT inkremental adalah tabel turunan persisten (PDT) yang dibuat Looker dengan menambahkan data baru ke tabel, bukan mem-build ulang tabel secara keseluruhan.

Jika dialek Anda mendukung PDT inkremental, dan PDT menggunakan strategi persistensi berbasis pemicu (datagroup_trigger, sql_trigger_value, atau interval_trigger), Anda dapat menentukan PDT sebagai PDT inkremental.

Catatan: PDT inkremental tidak didukung untuk PDT yang menggunakan strategi persistensi persist_for.

Lihat halaman dokumentasi PDT Inkremental untuk informasi selengkapnya.

Dialek database yang didukung untuk PDT inkremental

Agar Looker dapat mendukung PDT inkremental dalam project Looker, dialek database Anda juga harus mendukungnya. Tabel berikut menunjukkan dialek yang mendukung PDT inkremental dalam rilis Looker terbaru:

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

Membuat PDT

Untuk membuat tabel turunan menjadi tabel turunan persisten (PDT), Anda menentukan strategi persistensi untuk tabel tersebut. Untuk mengoptimalkan performa, Anda juga harus menambahkan strategi pengoptimalan.

Strategi persistensi

Persistensi tabel turunan dapat dikelola oleh Looker atau, untuk dialek yang mendukung tampilan terwujud, oleh database Anda menggunakan tampilan terwujud.

Untuk membuat tabel turunan tetap, tambahkan salah satu parameter berikut ke definisi derived_table:

• Parameter persistensi yang dikelola Looker:
  • datagroup_trigger
  • sql_trigger_value
  • interval_trigger
  • persist_for
• Parameter persistensi yang dikelola database:
  • materialized_view: yes

Dengan strategi persistensi berbasis pemicu (datagroup_trigger, sql_trigger_value, dan interval_trigger), Looker mempertahankan PDT dalam database hingga PDT dipicu untuk pembuatan ulang. Saat PDT dipicu, Looker akan membangun ulang PDT untuk menggantikan versi sebelumnya. Artinya, dengan PDT berbasis pemicu, pengguna tidak perlu menunggu PDT dibuat untuk mendapatkan jawaban atas kueri Jelajahi dari PDT.

Catatan: Pengguna tertentu dapat mengganti setelan persistensi PDT. Pengguna dengan izin develop dapat menggunakan opsi Rebuild Derived Tables & Run dari menu Jelajah untuk mengganti setelan persistensi dan mem-build ulang semua PDT yang diperlukan untuk kueri saat ini di Jelajah. Lihat bagian Membuat ulang PDT secara manual untuk kueri di halaman ini untuk mengetahui detailnya.

datagroup_trigger

Datagroups adalah metode paling fleksibel untuk membuat persistensi. Jika telah menentukan grup data dengan sql_trigger atau interval_trigger, Anda dapat menggunakan parameter datagroup_trigger untuk memulai pembuatan ulang tabel turunan persisten (PDT).

Looker mempertahankan PDT dalam database hingga grup datanya dipicu. Saat grup data dipicu, Looker akan membangun ulang PDT untuk menggantikan versi sebelumnya. Artinya, dalam banyak kasus, pengguna Anda tidak perlu menunggu PDT dibangun. Jika pengguna meminta data dari PDT saat sedang di-build dan hasil kueri tidak ada dalam cache, Looker akan menampilkan data dari PDT yang ada hingga PDT baru dibuat. Lihat Membuat cache kueri untuk mengetahui ringkasan grup data.

Lihat bagian Regenerator Looker untuk mengetahui informasi selengkapnya tentang cara regenerator membuat PDT.

sql_trigger_value

Parameter sql_trigger_value memicu pembuatan ulang tabel turunan persisten (PDT) berdasarkan pernyataan SQL yang Anda berikan. Jika hasil pernyataan SQL berbeda dari nilai sebelumnya, PDT akan dibuat ulang. Jika tidak, PDT yang ada dipertahankan di database. Artinya, dalam banyak kasus, pengguna Anda tidak perlu menunggu PDT dibangun. Jika pengguna meminta data dari PDT saat sedang di-build dan hasil kuerinya tidak ada dalam cache, Looker akan menampilkan data dari PDT yang ada hingga PDT baru dibuat.

Lihat bagian Regenerator Looker untuk mengetahui informasi selengkapnya tentang cara regenerator membuat PDT.

interval_trigger

Parameter interval_trigger memicu pembuatan ulang tabel turunan persisten (PDT) berdasarkan interval waktu yang Anda berikan, seperti "24 hours" atau "60 minutes". Serupa dengan parameter sql_trigger, ini berarti biasanya PDT sudah di-build sebelumnya saat pengguna Anda membuat kuerinya. Jika pengguna meminta data dari PDT saat sedang di-build dan hasil kuerinya tidak ada dalam cache, Looker akan menampilkan data dari PDT yang ada hingga PDT baru dibuat.

persist_for

Opsi lainnya adalah menggunakan parameter persist_for untuk menetapkan durasi penyimpanan tabel turunan sebelum ditandai sebagai habis masa berlakunya, sehingga tidak lagi digunakan untuk kueri dan akan dihapus dari database.

Tabel turunan persisten (PDT) persist_for dibuat saat pengguna pertama kali menjalankan kueri pada tabel tersebut. Looker kemudian menyimpan PDT dalam database selama jangka waktu yang ditentukan dalam parameter persist_for PDT. Jika pengguna membuat kueri PDT dalam waktu persist_for, Looker akan menggunakan hasil yang di-cache jika memungkinkan atau menjalankan kueri pada PDT.

Setelah waktu persist_for, Looker akan menghapus PDT dari database Anda, dan PDT akan dibuat ulang saat pengguna membuat kuerinya lagi, yang berarti kueri tersebut harus menunggu dibuat ulang.

PDT yang menggunakan persist_for tidak otomatis dibuat ulang oleh regenerator Looker, kecuali jika terjadi jenjang dependensi PDT. Jika tabel persist_for adalah bagian dari jenjang dependensi dengan PDT berbasis pemicu (PDT yang menggunakan strategi persistensi datagroup_trigger, interval_trigger, atau sql_trigger_value), regenerator akan memantau dan membuat ulang tabel persist_for untuk membuat ulang tabel lain dalam jenjang tersebut. Lihat bagian Cara Looker membuat tabel turunan bertingkat di halaman ini.

materialized_view: yes

Catatan: Fungsi tampilan terwujud adalah fitur lanjutan. Bergantung pada dialek Anda, tampilan terwujud dapat menghabiskan sumber daya yang besar, jadi penting bagi Anda untuk memahami implementasi tampilan terwujud dialek Anda. Lihat dokumentasi dialek Anda untuk mendapatkan informasi tentang perilaku dialek Anda dan frekuensi dialek memperbarui data untuk tampilan terwujud.

Tampilan terwujud memungkinkan Anda memanfaatkan fungsi database untuk mempertahankan tabel turunan dalam project Looker. Jika dialek database Anda mendukung tampilan terwujud dan koneksi Looker Anda dikonfigurasi dengan tombol Aktifkan PDT yang diaktifkan, Anda dapat membuat tampilan terwujud dengan menentukan materialized_view: yes untuk tabel turunan. Tampilan terwujud didukung untuk tabel turunan native dan tabel turunan berbasis SQL.

Mirip dengan tabel turunan persisten (PDT), tampilan terwujud adalah hasil kueri yang disimpan sebagai tabel dalam skema awal database Anda. Perbedaan utama antara PDT dan tampilan terwujud adalah cara tabel disegarkan:

• Untuk PDT, strategi persistensi ditentukan di Looker, dan persistensi dikelola oleh Looker.
• Untuk tampilan terwujud, database bertanggung jawab untuk memelihara dan memuat ulang data dalam tabel.

Karena alasan ini, fungsi tampilan terwujud memerlukan pengetahuan tingkat lanjut tentang dialek Anda dan fiturnya. Pada umumnya, database Anda akan memuat ulang tampilan terwujud setiap kali database mendeteksi data baru dalam tabel yang dikueri oleh tampilan terwujud. Tampilan terwujud optimal untuk skenario yang memerlukan data real-time.

Lihat halaman dokumentasi parameter materialized_view untuk mengetahui informasi tentang dukungan dialek, persyaratan, dan pertimbangan penting.

Strategi pengoptimalan

Karena tabel turunan persisten (PDT) disimpan dalam database, Anda harus mengoptimalkan PDT menggunakan strategi berikut, seperti yang didukung oleh dialek Anda:

• cluster_keys
• distribution
• distribution_style
• indexes
• partition_keys
• sortkeys

Misalnya, untuk menambahkan persistensi ke contoh tabel turunan, Anda dapat menetapkannya untuk mem-build ulang saat orders_datagroup grup data terpicu, dan menambahkan indeks di customer_id dan first_order, seperti ini:

view: customer_order_summary {
  derived_table: {
    explore_source: orders {
      ...
    }
    datagroup_trigger: orders_datagroup
    indexes: ["customer_id", "first_order"]
  }
}

Jika Anda tidak menambahkan indeks (atau yang setara dengan dialek Anda), Looker akan memperingatkan bahwa Anda harus melakukannya untuk meningkatkan performa kueri.

Kasus penggunaan untuk PDT

Tabel turunan persisten (PDT) berguna karena dapat meningkatkan performa kueri dengan mempertahankan hasil kueri dalam tabel.

Sebagai praktik terbaik umum, developer harus mencoba membuat model data tanpa menggunakan PDT hingga benar-benar diperlukan.

Terkadang, data dapat dioptimalkan dengan cara lain. Misalnya, menambahkan indeks atau mengubah jenis data kolom dapat menyelesaikan masalah tanpa perlu membuat PDT. Pastikan untuk menganalisis rencana eksekusi kueri lambat menggunakan Explain dari alat SQL Runner.

Selain mengurangi waktu kueri dan beban database pada kueri yang sering dijalankan, ada beberapa kasus penggunaan lain untuk PDT yang meliputi:

• Menguji pengoptimalan
• Penggabungan data terlebih dahulu

Anda juga dapat menggunakan PDT untuk menentukan kunci utama jika tidak ada cara yang wajar untuk mengidentifikasi baris unik dalam tabel sebagai kunci utama.

Menggunakan PDT untuk menguji pengoptimalan

Anda dapat menggunakan PDT untuk menguji berbagai opsi pengindeksan, distribusi, dan pengoptimalan lainnya tanpa memerlukan banyak dukungan dari developer DBA atau ETL.

Pertimbangkan kasus di mana Anda memiliki tabel tetapi ingin menguji indeks yang berbeda. LookML awal Anda untuk tampilan mungkin terlihat seperti berikut:

view: customer {
  sql_table_name: warehouse.customer ;;
}

Untuk menguji strategi pengoptimalan, Anda dapat menggunakan parameter indexes untuk menambahkan indeks ke LookML seperti ini:

view: customer {
  # sql_table_name: warehouse.customer
  derived_table: {
    sql: SELECT * FROM warehouse.customer ;;
    persist_for: "8 hours"
    indexes: [customer_id, customer_name, salesperson_id]
  }
}

Mengkueri tampilan sekali untuk menghasilkan PDT. Kemudian, jalankan kueri pengujian dan bandingkan hasilnya. Jika hasilnya positif, Anda dapat meminta tim DBA atau ETL Anda untuk menambahkan indeks ke tabel asli.

Jangan lupa mengubah kode tampilan Anda kembali untuk menghapus PDT.

Menggunakan PDT untuk menggabungkan data terlebih dahulu atau

Hal ini berguna untuk menggabungkan data terlebih dahulu atau mengagregasi sebelumnya guna menyesuaikan pengoptimalan kueri untuk volume tinggi atau beberapa jenis data.

Misalnya, Anda ingin melaporkan pelanggan menurut kelompok berdasarkan waktu mereka melakukan pemesanan pertama. Kueri ini mungkin mahal untuk dijalankan beberapa kali setiap kali data diperlukan secara real time; namun, Anda hanya dapat menghitung kueri satu kali, lalu menggunakan kembali hasilnya dengan PDT:

view: customer_order_facts {
  derived_table: {
    sql: SELECT
    c.customer_id,
    MIN(o.order_date) OVER (PARTITION BY c.customer_id) AS first_order_date,
    MAX(o.order_date) OVER (PARTITION BY c.customer_id) AS most_recent_order_date,
    COUNT(o.order_id) OVER (PARTITION BY c.customer_id) AS lifetime_orders,
    SUM(o.order_value) OVER (PARTITION BY c.customer_id) AS lifetime_value,
    RANK() OVER (PARTITION BY c.customer_id ORDER BY o.order_date ASC) AS order_sequence,
    o.order_id
    FROM warehouse.customer c LEFT JOIN warehouse.order o ON c.customer_id = o.customer_id
    ;;
    sql_trigger_value: SELECT CURRENT_DATE ;;
    indexes: [customer_id&, order_id, order_sequence, first_order_date]
  }
}

Tabel turunan bertingkat

Satu tabel turunan dapat dijadikan referensi dalam definisi tabel turunan lainnya, membuat rantai tabel turunan bertingkat, atau tabel turunan persisten (PDT), seperti yang mungkin terjadi. Contoh tabel turunan bertingkat adalah tabel, TABLE_D, yang bergantung pada tabel lain, TABLE_C, sementara TABLE_C bergantung pada TABLE_B, dan TABLE_B bergantung pada TABLE_A.

Catatan: Sebelum menyiapkan tabel turunan bertingkat, penting untuk mengetahui cara tabel bertingkat secara otomatis dibuat ulang oleh regenerator Looker dan bagaimana tabel ini dapat dibuat ulang secara manual oleh pengguna. Ada juga pertimbangan penting lainnya untuk menerapkan tabel persisten. Semua topik tersebut akan dibahas nanti di halaman ini.

Sintaksis untuk mereferensikan tabel turunan

Untuk mereferensikan tabel turunan dalam tabel turunan lain, gunakan sintaksis ini:

`${derived_table_or_view_name.SQL_TABLE_NAME}`

Dalam format ini, SQL_TABLE_NAME adalah string literal. Misalnya, Anda dapat mereferensikan tabel turunan clean_events dengan sintaksis ini:

`${clean_events.SQL_TABLE_NAME}`

Anda dapat menggunakan {i>syntax<i} yang sama untuk merujuk ke tampilan LookML. Sekali lagi, dalam kasus ini, SQL_TABLE_NAME adalah string literal.

Catatan: Sintaksis ${derived_table_or_view_name.SQL_TABLE_NAME} tidak didukung dalam parameter sql_trigger grup data, sehingga Anda tidak dapat menggunakan tabel turunan untuk memicu grup data. Namun, Anda dapat menggunakan sintaksis ${derived_table_or_view_name.SQL_TABLE_NAME} di parameter sql_trigger_value untuk memicu build ulang PDT.

Pada contoh berikutnya, PDT clean_events dibuat dari tabel events dalam database. PDT clean_events tidak menyertakan baris yang tidak diinginkan dari tabel database events. Kemudian PDT kedua akan ditampilkan; PDT event_summary adalah ringkasan dari clean_events PDT. Tabel event_summary dibuat ulang setiap kali baris baru ditambahkan ke clean_events.

PDT event_summary dan PDT clean_events merupakan PDT bertingkat, dengan event_summary bergantung pada clean_events (karena event_summary ditentukan menggunakan PDT clean_events). Contoh khusus ini dapat dilakukan secara lebih efisien dalam satu PDT, tetapi berguna untuk menunjukkan referensi tabel turunan.

view: clean_events {
  derived_table: {
    sql:
      SELECT *
      FROM events
      WHERE type NOT IN ('test', 'staff') ;;
    datagroup_trigger: events_datagroup
  }
}

view: events_summary {
  derived_table: {
    sql:
      SELECT
        type,
        date,
        COUNT(*) AS num_events
      FROM
        ${clean_events.SQL_TABLE_NAME} AS clean_events
      GROUP BY
        type,
        date ;;
    datagroup_trigger: events_datagroup
  }
}

Meskipun tidak selalu diperlukan, saat Anda mengacu pada tabel turunan dengan cara ini, sering kali berguna membuat alias untuk tabel dengan menggunakan format ini:

${derived_table_or_view_name.SQL_TABLE_NAME} AS derived_table_or_view_name

Contoh sebelumnya melakukan hal ini:

${clean_events.SQL_TABLE_NAME} AS clean_events

Penggunaan alias di balik layar akan sangat membantu karena PDT diberi nama dengan kode panjang dalam database Anda. Dalam beberapa kasus (terutama dengan klausa ON), Anda sering lupa bahwa Anda harus menggunakan sintaksis ${derived_table_or_view_name.SQL_TABLE_NAME} untuk mengambil nama yang panjang ini. Alias dapat membantu mencegah kesalahan semacam ini.

Cara Looker membuat tabel turunan bertingkat

Dalam kasus tabel turunan sementara yang menurun, jika hasil kueri pengguna tidak ada dalam cache, Looker akan membuat semua tabel turunan yang diperlukan untuk kueri tersebut. Jika Anda memiliki TABLE_D yang definisinya berisi referensi ke TABLE_C, TABLE_D bergantung pada TABLE_C. Artinya, jika Anda membuat kueri TABLE_D dan kueri tersebut tidak ada dalam cache Looker, Looker akan membuat ulang TABLE_D. Namun, TABLE_C harus di-build ulang terlebih dahulu.

Sekarang, mari kita ambil skenario tabel turunan sementara yang menurun saat TABLE_D bergantung pada TABLE_C, yang bergantung pada TABLE_B, yang bergantung pada TABLE_A. Jika Looker tidak memiliki hasil yang valid untuk kueri TABLE_C di cache, Looker akan membuat semua tabel yang diperlukan untuk kueri tersebut. Jadi, Looker akan membangun TABLE_A, lalu TABLE_B, lalu TABLE_C:

Dalam skenario ini, TABLE_A harus selesai dibuat sebelum Looker dapat mulai membuat TABLE_B, dan seterusnya, hingga TABLE_C selesai dan Looker dapat memberikan hasil kueri. (Karena TABLE_D tidak diperlukan untuk menjawab kueri ini, Looker tidak akan membuat ulang TABLE_D saat ini.)

Lihat halaman dokumentasi parameter datagroup untuk mengetahui contoh skenario PDT bertingkat yang menggunakan grup data yang sama.

Logika dasar yang sama berlaku untuk PDT: Looker akan membuat tabel apa pun yang diperlukan untuk menjawab kueri, hingga ke rantai dependensi. Namun, dengan PDT, sering kali tabel sudah ada dan tidak perlu dibuat ulang. Dengan kueri pengguna standar pada PDT yang menurun, Looker akan membangun ulang PDT secara menurun hanya jika tidak ada versi PDT yang valid dalam database. Jika ingin memaksa pembuatan ulang untuk semua PDT dalam proses bertingkat, Anda dapat membuat ulang tabel secara manual untuk kueri melalui Jelajah.

Poin logis penting yang perlu dipahami adalah bahwa dalam kasus kaskade PDT, PDT dependen pada dasarnya melakukan kueri PDT yang menjadi dependensinya. Hal ini signifikan terutama bagi PDT yang menggunakan strategi persist_for. Biasanya, PDT persist_for di-build saat pengguna membuat kuerinya, tetap berada di database hingga interval persist_for-nya habis, lalu tidak dibuat ulang hingga selanjutnya dikueri oleh pengguna. Namun, jika PDT persist_for adalah bagian dari jenjang dengan PDT berbasis pemicu (PDT yang menggunakan strategi persistensi datagroup_trigger, interval_trigger, atau sql_trigger_value), PDT persist_for pada dasarnya akan dikueri setiap kali PDT yang dependen dibuat ulang. Jadi, dalam hal ini, PDT persist_for akan dibuat ulang sesuai jadwal PDT dependennya. Artinya, persist_for PDT dapat dipengaruhi oleh strategi persistensi turunannya.

Membuat ulang tabel persisten secara manual untuk sebuah kueri

Pengguna dapat memilih opsi Rebuild Derived Tables & Run dari menu Eksplorasi untuk mengganti setelan persistensi dan membuat ulang semua tabel turunan persisten (PDT) dan tabel gabungan yang diperlukan untuk kueri saat ini di Eksplorasi:

Opsi ini hanya dapat dilihat oleh pengguna dengan izin develop, dan hanya setelah kueri Jelajah dimuat.

Opsi Rebuild Derived Tables & Run membuat ulang semua tabel persisten (semua PDT dan tabel gabungan) yang diperlukan untuk menjawab kueri, terlepas dari strategi persistensinya. Hal ini mencakup tabel dan PDT gabungan dalam kueri saat ini, serta tabel gabungan dan PDT yang dirujuk oleh tabel gabungan dan PDT dalam kueri saat ini.

Dalam kasus PDT inkremental, opsi Rebuild Derived Tables & Run akan memicu build inkremental yang baru. Dengan PDT inkremental, penambahan akan mencakup jangka waktu yang ditentukan dalam parameter increment_key, serta jumlah jangka waktu sebelumnya yang ditentukan dalam parameter increment_offset, jika ada. Lihat halaman dokumentasi PDT inkremental untuk mengetahui beberapa contoh skenario yang menunjukkan cara build PDT inkremental, bergantung pada konfigurasinya.

Dalam kasus cascading PDT, artinya membuat ulang semua tabel turunan dalam bertingkat, mulai dari atas. Perilaku ini sama seperti ketika Anda membuat kueri tabel dalam jenjang tabel turunan sementara:

Perhatikan hal berikut tentang cara mem-build ulang tabel turunan secara manual:

• Untuk pengguna yang memulai operasi Rebuild Derived Tables & Run, kueri akan menunggu tabel dibuat ulang sebelum memuat hasil. Kueri pengguna lain akan tetap menggunakan tabel yang ada. Setelah tabel persisten dibuat ulang, semua pengguna akan menggunakan tabel yang dibuat ulang. Meskipun proses ini dirancang untuk menghindari gangguan kueri pengguna lain saat tabel dibuat ulang, pengguna tersebut masih dapat terpengaruh oleh beban tambahan pada database Anda. Jika Anda berada dalam situasi di mana memicu build ulang selama jam kerja dapat memberikan tekanan yang tidak dapat diterima pada database, Anda mungkin perlu memberi tahu pengguna bahwa mereka tidak boleh membuat ulang PDT atau tabel gabungan tertentu selama jam-jam tersebut.

• Jika pengguna berada dalam Mode Pengembangan dan Jelajah didasarkan pada tabel pengembangan, operasi Rebuild Derived Tables & Run akan mem-build ulang tabel pengembangan, bukan tabel produksi, untuk Jelajah. Namun, jika Explore dalam Mode Pengembangan menggunakan versi produksi dari tabel turunan, tabel produksi akan dibuat ulang. Lihat Tabel persisten dalam Mode Pengembangan untuk mengetahui informasi tentang tabel pengembangan dan tabel produksi.

• Untuk instance yang dihosting di Looker, jika tabel turunan memerlukan waktu lebih dari satu jam untuk dibuat ulang, tabel tersebut tidak akan berhasil dibuat ulang dan sesi browser akan habis waktunya. Lihat bagian Waktu tunggu kueri dan antrean di halaman dokumentasi Setelan admin - Kueri untuk mengetahui informasi selengkapnya tentang waktu tunggu yang dapat memengaruhi proses Looker.

Tabel persisten dalam Mode Pengembangan

Looker memiliki beberapa perilaku khusus untuk mengelola tabel yang dipertahankan dalam Mode Pengembangan.

Catatan: Perilaku ini berlaku untuk semua jenis tabel persisten, yang mencakup tabel gabungan serta tabel turunan persisten (PDT).

Jika Anda membuat kueri tabel persisten dalam Mode Pengembangan tanpa mengubah definisinya, Looker akan mengkueri versi produksi tabel tersebut. Jika Anda melakukan perubahan pada definisi tabel yang memengaruhi data dalam tabel atau cara tabel dikueri, versi pengembangan baru tabel akan dibuat saat Anda membuat kueri tabel dalam Mode Pengembangan lagi. Memiliki tabel pengembangan seperti itu memungkinkan Anda menguji perubahan tanpa mengganggu pengguna akhir.

Yang meminta Looker untuk membuat tabel pengembangan

Jika memungkinkan, Looker akan menggunakan tabel produksi yang ada untuk menjawab kueri, terlepas dari apakah Anda berada dalam Mode Pengembangan atau tidak. Namun, ada kasus tertentu saat Looker tidak dapat menggunakan tabel produksi untuk kueri dalam Mode Pengembangan:

• Jika tabel persisten memiliki parameter yang mempersempit set datanya agar bekerja lebih cepat dalam Mode Pengembangan
• Jika Anda telah membuat perubahan pada definisi tabel persisten yang memengaruhi data dalam tabel

Looker akan membuat tabel pengembangan jika Anda berada dalam Mode Pengembangan dan membuat kueri tabel turunan berbasis SQL yang ditentukan menggunakan klausa WHERE bersyarat dengan pernyataan if prod dan if dev.

Catatan: Hal ini tidak berlaku untuk tabel turunan native dengan parameter dev_filters. Untuk tabel turunan native dengan dev_filters, Looker memiliki logika untuk menggunakan tabel produksi guna menjawab kueri dalam Mode Pengembangan, kecuali jika Anda mengubah definisi tabel, lalu membuat kueri tabel dalam Mode Pengembangan.

Untuk tabel persisten yang tidak memiliki parameter untuk mempersempit set data dalam Mode Pengembangan, Looker akan menggunakan versi produksi tabel untuk menjawab kueri dalam Mode Pengembangan, kecuali jika Anda mengubah definisi tabel lalu kemudian membuat kueri tabel dalam Mode Pengembangan. Ini berlaku untuk setiap perubahan pada tabel yang memengaruhi data dalam tabel atau cara tabel dikueri.

Berikut beberapa contoh jenis perubahan yang akan meminta Looker untuk membuat versi pengembangan tabel persisten (Looker hanya akan membuat tabel jika Anda kemudian membuat kueri tabel setelah melakukan perubahan ini):

• Mengubah kueri yang menjadi dasar tabel persisten, seperti mengubah parameter explore_source, sql, query, sql_create, atau create_process di tabel persisten itu sendiri, atau di tabel apa pun yang diperlukan (untuk tabel turunan bertingkat)
• Mengubah strategi persistensi tabel, seperti mengubah parameter datagroup_trigger, sql_trigger_value, interval_trigger, atau persist_for tabel
• Mengubah nama view tabel turunan
• Mengubah increment_key atau increment_offset dari PDT inkremental
• Mengubah connection yang digunakan oleh model terkait

Untuk perubahan yang tidak mengubah data tabel atau memengaruhi cara Looker membuat kueri tabel, Looker tidak akan membuat tabel pengembangan. Parameter publish_as_db_view adalah contoh yang baik: Dalam Mode Pengembangan, jika Anda hanya mengubah setelan publish_as_db_view untuk tabel turunan, Looker tidak perlu membuat ulang tabel turunan sehingga tidak akan membuat tabel pengembangan.

Durasi tabel pengembangan Looker dipertahankan

Terlepas dari strategi persistensi tabel yang sebenarnya, Looker memperlakukan tabel persisten pengembangan seolah-olah memiliki strategi persistensi persist_for: "24 hours". Looker melakukan hal ini untuk memastikan tabel pengembangan tidak dipertahankan selama lebih dari satu hari, karena developer Looker dapat mengkueri banyak iterasi tabel selama pengembangan, dan setiap kali tabel pengembangan baru dibuat. Agar tabel pengembangan tidak mengacaukan database, Looker menerapkan strategi persist_for: "24 hours" untuk memastikan tabel dibersihkan dari database secara rutin.

Jika tidak, Looker akan membuat tabel turunan persisten (PDT) dan tabel gabungan dalam Mode Pengembangan dengan cara yang sama seperti membuat tabel persisten dalam Mode Produksi.

Jika tabel pengembangan disimpan di database saat Anda men-deploy perubahan pada PDT atau tabel gabungan, Looker sering kali dapat menggunakan tabel pengembangan sebagai tabel produksi sehingga pengguna tidak perlu menunggu tabel dibuat saat mereka membuat kueri tabel.

Perhatikan bahwa saat Anda men-deploy perubahan, tabel mungkin masih perlu dibuat ulang agar dapat dikueri dalam produksi, bergantung pada situasinya:

• Jika sudah lebih dari 24 jam sejak Anda membuat kueri tabel dalam Mode Pengembangan, versi pengembangan tabel akan diberi tag sebagai sudah tidak berlaku dan tidak akan digunakan untuk kueri. Anda dapat memeriksa PDT yang belum dibangun menggunakan Looker IDE atau menggunakan tab Development di halaman Persistent Derived Tables. Jika memiliki PDT yang belum dibangun, Anda bisa mengkuerinya dalam Mode Pengembangan tepat sebelum membuat perubahan, sehingga tabel pengembangan tersedia untuk digunakan dalam produksi.
• Jika tabel yang dipertahankan memiliki parameter dev_filters (untuk tabel turunan native) atau klausa WHERE bersyarat yang menggunakan pernyataan if prod dan if dev (untuk tabel turunan berbasis SQL), tabel pengembangan tidak dapat digunakan sebagai versi produksi, karena versi pengembangan memiliki set data yang disingkat. Jika demikian, setelah selesai mengembangkan tabel dan sebelum men-deploy perubahan, Anda dapat menjadikan parameter dev_filters atau klausa WHERE kondisional, lalu membuat kueri tabel dalam Mode Pengembangan. Looker kemudian akan membuat versi lengkap tabel yang dapat digunakan untuk produksi saat Anda men-deploy perubahan.

Sebaliknya, jika Anda men-deploy perubahan saat tidak ada tabel pengembangan valid yang dapat digunakan sebagai tabel produksi, Looker akan membuat ulang tabel saat tabel dikueri dalam Mode Produksi (untuk tabel persisten yang menggunakan strategi persist_for), atau saat berikutnya regenerator berjalan (untuk tabel persisten yang menggunakan datagroup_trigger, interval_trigger, atau sql_trigger_value).

Memeriksa PDT yang tidak dibangun dalam Mode Pengembangan

Jika tabel pengembangan dipertahankan di database saat Anda men-deploy perubahan pada tabel turunan persisten (PDT) atau tabel gabungan, Looker sering kali dapat menggunakan tabel pengembangan sebagai tabel produksi sehingga pengguna tidak perlu menunggu tabel dibuat saat mereka membuat kueri tabel. Lihat bagian Durasi tabel pengembangan Looker dan Hal yang meminta Looker membuat tabel pengembangan di halaman ini untuk mengetahui detail selengkapnya.

Oleh karena itu, sebaiknya semua PDT di-build saat Anda men-deploy ke produksi sehingga tabel dapat langsung digunakan sebagai versi produksi.

Anda dapat memeriksa project Anda untuk menemukan PDT yang belum dibangun di panel Project Health. Klik ikon Project Health di Looker IDE untuk membuka panel Project Health. Kemudian, klik tombol Validasi Status PDT.

Jika ada PDT yang tidak dibangun, panel Project Health akan mencantumkannya:

Jika memiliki izin see_pdts, Anda dapat mengklik tombol Buka Pengelolaan PDT. Looker akan membuka tab Development di halaman Persistent Derived Tables dan memfilter hasilnya ke project LookML tertentu Anda. Dari sana, Anda dapat melihat PDT pengembangan mana yang dibangun dan tidak dibangun serta mengakses informasi pemecahan masalah lainnya. Lihat halaman dokumentasi Setelan admin - Tabel Turunan Persisten untuk informasi selengkapnya.

Setelah mengidentifikasi PDT yang belum dibangun dalam project, Anda dapat mem-build versi pengembangannya dengan membuka Explore yang membuat kueri tabel, lalu menggunakan opsi Rebuild Derived Tables & Run dari menu Explore. Lihat bagian Membuat ulang tabel persisten secara manual untuk kueri di halaman ini.

Catatan: Jika tabel persisten adalah tabel turunan berbasis SQL yang ditentukan menggunakan klausa WHERE bersyarat dengan pernyataan if prod dan if dev, Anda tidak akan dapat menggunakan versi pengembangan tabel untuk produksi, karena versi pengembangan tabel memiliki set data yang disingkat. Lihat bagian Berapa lama tabel pengembangan Looker dipertahankan di halaman ini untuk mengetahui informasi selengkapnya. Untuk tabel turunan native dengan parameter dev_filters, Looker menggunakan tabel produksi untuk menjawab kueri dalam Mode Pengembangan, kecuali jika Anda mengubah definisi tabel, lalu membuat kueri tabel dalam Mode Pengembangan (lihat bagian Hal yang meminta Looker untuk membuat tabel pengembangan di halaman dokumentasi ini).

Berbagi dan pembersihan meja

Dalam instance Looker tertentu, Looker akan membagikan tabel persisten kepada pengguna jika tabel tersebut memiliki definisi dan setelan metode persistensi yang sama. Selain itu, jika definisi tabel tidak ada lagi, Looker akan menandai tabel tersebut sebagai sudah tidak berlaku.

Hal ini memiliki beberapa manfaat:

• Jika Anda belum melakukan perubahan pada tabel dalam Mode Pengembangan, kueri Anda akan menggunakan tabel produksi yang ada. Hal ini berlaku kecuali tabel Anda adalah tabel turunan berbasis SQL yang ditentukan menggunakan klausa WHERE bersyarat dengan pernyataan if prod dan if dev. Jika tabel ditentukan dengan klausa WHERE bersyarat, Looker akan membuat tabel pengembangan jika Anda membuat kueri tabel dalam Mode Pengembangan. (Untuk tabel turunan native dengan parameter dev_filters, Looker memiliki logika untuk menggunakan tabel produksi guna menjawab kueri dalam Mode Pengembangan, kecuali jika Anda mengubah definisi tabel, lalu membuat kueri tabel dalam Mode Pengembangan.)
• Jika dua developer membuat perubahan yang sama pada tabel saat berada dalam Mode Pengembangan, mereka akan menggunakan tabel pengembangan yang sama.
• Setelah Anda mendorong perubahan dari Mode Pengembangan ke Mode Produksi, definisi produksi lama tidak ada lagi, sehingga tabel produksi lama ditandai sebagai kedaluwarsa dan akan dihapus.
• Jika Anda memutuskan untuk membuang perubahan Mode Pengembangan, definisi tabel tersebut tidak akan ada lagi, sehingga tabel pengembangan yang tidak diperlukan ditandai sebagai kedaluwarsa dan akan dihapus.

Bekerja lebih cepat dalam Mode Pengembangan

Ada situasi saat tabel turunan persisten (PDT) yang Anda buat memerlukan waktu lama untuk dihasilkan, sehingga dapat memakan waktu jika Anda menguji banyak perubahan dalam Mode Pengembangan. Untuk kasus ini, Anda dapat meminta Looker untuk membuat versi tabel turunan yang lebih kecil saat berada dalam Mode Pengembangan.

Untuk tabel turunan native, Anda dapat menggunakan subparameter dev_filters dari explore_source untuk menentukan filter yang hanya diterapkan ke versi pengembangan tabel turunan:

view: e_faa_pdt {
  derived_table: {
  ...
    datagroup_trigger: e_faa_shared_datagroup
    explore_source: flights {
      dev_filters: [flights.event_date: "90 days"]
      filters: [flights.event_date: "2 years", flights.airport_name: "Yucca Valley Airport"]
      column: id {}
      column: airport_name {}
      column: event_date {}
    }
  }
...
}

Contoh ini mencakup parameter dev_filters yang memfilter data ke 90 hari terakhir dan parameter filters yang memfilter data dari 2 tahun terakhir dan ke Yucca Valley Airport.

Parameter dev_filters berfungsi bersama dengan parameter filters sehingga semua filter diterapkan ke versi pengembangan tabel. Jika dev_filters dan filters menentukan filter untuk kolom yang sama, dev_filters lebih diprioritaskan untuk versi pengembangan tabel. Dalam contoh ini, versi pengembangan tabel akan memfilter data hingga 90 hari terakhir untuk Bandara Yucca Valley.

Untuk tabel turunan berbasis SQL, Looker mendukung klausa WHERE bersyarat dengan opsi berbeda untuk versi produksi (if prod) dan pengembangan (if dev) tabel:

view: my_view {
  derived_table: {
    sql:
      SELECT
        columns
      FROM
        my_table
      WHERE
        -- if prod -- date > '2000-01-01'
        -- if dev -- date > '2020-01-01'
      ;;
  }
}

Dalam contoh ini, kueri akan mencakup semua data dari tahun 2000 dan seterusnya saat dalam Mode Produksi, tetapi hanya data dari tahun 2020 dan seterusnya saat dalam Mode Pengembangan. Menggunakan fitur ini secara strategis untuk membatasi kumpulan hasil, dan meningkatkan kecepatan kueri, dapat membuat perubahan Mode Pengembangan jauh lebih mudah divalidasi.

Catatan: Jika tabel yang dipertahankan memiliki parameter dev_filters atau klausa WHERE bersyarat, tabel pengembangan tidak dapat digunakan sebagai versi produksi, karena versi pengembangan memiliki set data yang disingkat. Jika demikian, setelah selesai mengembangkan tabel dan sebelum men-deploy perubahan, Anda dapat menjadikan parameter dev_filters atau klausa WHERE kondisional, lalu membuat kueri tabel dalam Mode Pengembangan. Looker kemudian akan membuat versi lengkap tabel yang dapat digunakan untuk produksi saat Anda men-deploy perubahan. Lihat bagian Berapa lama tabel pengembangan Looker dipertahankan di halaman ini untuk mengetahui detail selengkapnya tentang cara menggunakan tabel pengembangan dalam produksi.

Cara Looker membangun PDT

Setelah tabel turunan persisten (PDT) ditentukan dan dijalankan untuk pertama kalinya atau dipicu oleh regenerator untuk dibuat ulang sesuai dengan strategi persistensinya, Looker akan melalui langkah-langkah berikut:

1. Gunakan SQL tabel turunan untuk membuat pernyataan CREATE TABLE AS SELECT (atau CTAS) dan jalankan. Misalnya, untuk mem-build ulang PDT yang disebut customer_orders_facts: CREATE TABLE tmp.customer_orders_facts AS SELECT ... FROM ... WHERE ...
2. Berikan pernyataan untuk membuat indeks saat tabel di-build
3. Ganti nama tabel dari LC$.. ("Looker Create") menjadi LR$.. ("Looker Read"), untuk menunjukkan bahwa tabel siap digunakan
4. Hapus versi lama tabel yang seharusnya tidak lagi digunakan

Ada beberapa implikasi penting:

• SQL yang membentuk tabel turunan harus valid di dalam pernyataan CTAS.
• Alias kolom pada kumpulan hasil pernyataan SELECT harus berupa nama kolom yang valid.
• Nama yang digunakan saat menentukan distribusi, kunci pengurutan, dan indeks harus berupa nama kolom yang tercantum dalam definisi SQL dari tabel turunan, bukan nama kolom yang didefinisikan dalam LookML.

Regenerator Looker

Regenerator Looker memeriksa status dan memulai pembuatan ulang untuk tabel dengan pemicu persistensi. Tabel dengan pemicu persistensi adalah tabel turunan persisten (PDT) atau tabel gabungan yang menggunakan pemicu sebagai strategi persistensi:

• Untuk tabel yang menggunakan sql_trigger_value, pemicunya adalah kueri yang ditentukan dalam parameter sql_trigger_value tabel. Regenerator Looker memicu pembuatan ulang tabel saat hasil pemeriksaan kueri pemicu terbaru berbeda dengan hasil pemeriksaan kueri pemicu sebelumnya. Misalnya, jika tabel turunan Anda dipertahankan dengan kueri SQL SELECT CURDATE(), regenerator Looker akan membuat ulang tabel saat berikutnya regenerator memeriksa pemicu setelah tanggal berubah.
• Untuk tabel yang menggunakan interval_trigger, pemicunya adalah durasi waktu yang ditentukan dalam parameter interval_trigger tabel. Regenerator Looker memicu pembuatan ulang tabel saat waktu yang ditentukan telah berlalu.
• Untuk tabel yang menggunakan datagroup_trigger, pemicu dapat berupa kueri yang ditentukan dalam parameter sql_trigger grup data terkait, atau pemicu dapat berupa durasi waktu yang ditentukan dalam parameter interval_trigger grup data.

Regenerator Looker juga memulai pembuatan ulang untuk tabel persisten yang menggunakan parameter persist_for, tetapi hanya jika tabel persist_for merupakan jenjang dependensi dari tabel dengan pemicu persistensi. Dalam hal ini, regenerator Looker akan memulai pembuatan ulang untuk tabel persist_for karena tabel tersebut diperlukan untuk mem-build ulang tabel lainnya dalam jenjang ini. Jika tidak, regenerator tidak akan memantau tabel persisten yang menggunakan strategi persist_for.

Siklus regenerator Looker dimulai pada interval reguler yang dikonfigurasi oleh admin Looker Anda di setelan Jadwal Pemeliharaan Grup Data dan PDT pada koneksi database Anda (default-nya adalah interval lima menit). Namun, regenerator Looker tidak memulai siklus baru hingga menyelesaikan semua pemeriksaan dan membangun ulang PDT dari siklus terakhir. Artinya, jika Anda memiliki build PDT yang berjalan lama, siklus regenerator Looker mungkin tidak berjalan sesering yang ditentukan dalam setelan Jadwal Pemeliharaan PDT dan Grup Data. Faktor lain dapat memengaruhi waktu yang diperlukan untuk membuat ulang tabel, seperti yang dijelaskan di bagian Pertimbangan penting untuk menerapkan tabel persisten di halaman ini.

Jika PDT gagal terbentuk, regenerator dapat mencoba membuat ulang tabel pada siklus regenerator berikutnya:

• Jika setelan Coba lagi Build PDT Gagal diaktifkan pada koneksi database Anda, regenerator Looker akan mencoba membuat ulang tabel selama siklus regenerator berikutnya, meskipun kondisi pemicu tabel tidak terpenuhi.
• Jika setelan Coba lagi Build PDT Gagal dinonaktifkan, regenerator Looker tidak akan mencoba membuat ulang tabel hingga kondisi pemicu PDT terpenuhi.

Jika pengguna meminta data dari tabel persisten saat sedang dibuat dan hasil kueri tidak ada dalam cache, Looker akan memeriksa untuk melihat apakah tabel yang ada masih valid. (Tabel sebelumnya mungkin tidak valid jika tidak kompatibel dengan versi tabel yang baru, yang dapat terjadi jika tabel baru memiliki definisi yang berbeda, tabel baru menggunakan koneksi database yang berbeda, atau tabel baru dibuat dengan versi Looker yang berbeda.) Jika tabel yang ada masih valid, Looker akan menampilkan data dari tabel yang ada hingga tabel baru dibuat. Atau, jika tabel yang ada tidak valid, Looker akan memberikan hasil kueri setelah tabel baru dibuat ulang.

Pertimbangan penting untuk menerapkan tabel yang disimpan

Dengan mempertimbangkan kegunaan tabel persisten (PDT dan tabel gabungan), tabel gabungan menjadi mudah untuk dikumpulkan di instance Looker Anda. Anda dapat membuat skenario yang mengharuskan regenerator Looker untuk membuat banyak tabel sekaligus. Khususnya untuk tabel beruntun, atau tabel yang berjalan lama, Anda dapat membuat skenario di mana tabel mengalami penundaan yang lama sebelum dibuat ulang, atau saat pengguna mengalami penundaan dalam mendapatkan hasil kueri dari tabel saat database bekerja keras untuk membuat tabel.

Regenerator Looker memeriksa pemicu PDT untuk melihat apakah pemicu harus membuat ulang tabel dengan pemicu persistensi. Siklus regenerator disetel pada interval reguler yang dikonfigurasi oleh admin Looker Anda di setelan Jadwal Pemeliharaan Grup Data dan PDT pada koneksi database Anda (defaultnya adalah interval lima menit).

Beberapa faktor dapat memengaruhi waktu yang diperlukan untuk membangun ulang tabel Anda:

• Admin Looker Anda mungkin telah mengubah interval pemeriksaan pemicu regenerator dengan menggunakan setelan Jadwal Pemeliharaan PDT dan Grup Data pada koneksi database Anda.
• Regenerator Looker tidak memulai siklus baru hingga menyelesaikan semua pemeriksaan dan mem-build ulang PDT dari siklus terakhir. Jadi, jika Anda memiliki build PDT yang berjalan lama, siklus regenerator Looker mungkin tidak akan sesering setelan Jadwal Pemeliharaan PDT dan Grup Data.
• Secara default, regenerator dapat memulai pembuatan ulang satu PDT atau tabel gabungan dalam satu waktu melalui koneksi. Admin Looker dapat menyesuaikan jumlah pembuatan ulang serentak yang diizinkan oleh regenerator menggunakan kolom Jumlah maksimum koneksi builder PDT di setelan koneksi.
• Semua PDT dan tabel gabungan yang dipicu oleh datagroup yang sama akan dibuat ulang selama proses pembuatan ulang yang sama. Hal ini dapat menjadi beban berat jika Anda memiliki banyak tabel yang menggunakan datagroup, baik secara langsung maupun akibat dependensi menurun.

Selain pertimbangan sebelumnya, ada juga beberapa situasi yang mengharuskan Anda menghindari penambahan persistensi ke tabel turunan:

• Kapan tabel turunan akan extended — Setiap ekstensi PDT akan membuat salinan tabel baru di database Anda.
• Jika tabel turunan menggunakan filter template atau parameter Liquid — Persistensi tidak didukung untuk tabel turunan yang menggunakan filter template atau parameter Liquid.
• Jika tabel turunan native dibuat dari Jelajah yang menggunakan atribut pengguna dengan access_filters, atau dengan sql_always_where — Salinan tabel akan dibuat di database Anda untuk setiap kemungkinan nilai atribut pengguna yang ditentukan.
• Saat data yang mendasari sering berubah dan dialek database Anda tidak mendukung PDT inkremental.
• Saat biaya dan waktu yang diperlukan dalam pembuatan PDT terlalu tinggi.

Bergantung pada jumlah dan kompleksitas tabel persisten pada koneksi Looker Anda, antrean mungkin berisi banyak tabel persisten yang perlu diperiksa dan dibuat ulang pada setiap siklus. Jadi, penting untuk mengingat faktor-faktor ini saat menerapkan tabel turunan pada instance Looker Anda.

Mengelola PDT dalam skala besar melalui API

Memantau dan mengelola tabel turunan persisten (PDT) yang dimuat ulang pada berbagai jadwal akan menjadi semakin kompleks saat Anda membuat lebih banyak PDT pada instance. Pertimbangkan untuk menggunakan integrasi Apache Airflow pada Looker untuk mengelola jadwal PDT bersama proses ETL dan ELT lainnya.

Memantau dan memecahkan masalah PDT

Jika Anda menggunakan tabel turunan persisten (PDT), dan terutama PDT bertingkat, sebaiknya lihat status PDT Anda. Anda dapat menggunakan halaman admin Persistent Derived Tables Looker untuk melihat status PDT Anda. Lihat halaman dokumentasi Setelan admin - Persistent Derived Tables untuk mendapatkan informasi.

Saat mencoba memecahkan masalah PDT:

• Perhatikan dengan cermat perbedaan antara tabel pengembangan dan tabel produksi saat menyelidiki Log Peristiwa PDT.
• Pastikan tidak ada perubahan yang dilakukan pada skema awal tempat Looker menyimpan tabel turunan persisten. Jika perubahan telah dilakukan, Anda mungkin perlu memperbarui setelan Koneksi di bagian Admin pada Looker, lalu mungkin memulai ulang Looker untuk memulihkan fungsi PDT normal.
• Tentukan apakah ada masalah pada semua PDT, atau hanya satu. Jika ada masalah dengan satu, maka masalah tersebut kemungkinan disebabkan oleh error LookML atau SQL.
• Menentukan apakah masalah pada PDT sesuai dengan waktu yang dijadwalkan untuk dibangun ulang.
• Pastikan semua kueri sql_trigger_value berhasil dievaluasi dan hanya menampilkan satu baris dan kolom. Untuk PDT berbasis SQL, Anda dapat melakukannya dengan menjalankannya di SQL Runner. (Menerapkan LIMIT akan melindungi dari kueri yang tidak terkendali.) Untuk mengetahui informasi selengkapnya tentang penggunaan SQL Runner untuk men-debug tabel turunan, lihat Postingan komunitas Menggunakan runner sql untuk menguji tabel turunan .
• Untuk PDT berbasis SQL, gunakan SQL Runner untuk memverifikasi bahwa SQL PDT dieksekusi tanpa error. (Pastikan untuk menerapkan LIMIT di SQL Runner agar waktu kueri tetap wajar.)
• Untuk tabel turunan berbasis SQL, hindari penggunaan ekspresi tabel umum (CTE). Penggunaan CTE dengan DT akan membuat pernyataan WITH bertingkat yang dapat menyebabkan PDT gagal tanpa peringatan. Sebagai gantinya, gunakan SQL untuk CTE Anda guna membuat DT sekunder dan referensikan DT tersebut dari DT pertama Anda menggunakan sintaksis ${derived_table_or_view_name.SQL_TABLE_NAME}.
• Periksa bahwa setiap tabel yang menjadi tempat PDT masalah bergantung — baik tabel normal atau PDT itu sendiri — ada dan dapat dikueri.
• Pastikan setiap tabel yang menjadi tempat PDT masalah bergantung tidak memiliki kunci bersama atau eksklusif. Agar berhasil membangun PDT, Looker perlu memperoleh kunci eksklusif di tabel agar dapat diperbarui. Hal ini akan bertentangan dengan kunci bersama atau eksklusif lainnya yang saat ini terdapat di tabel. Looker tidak akan dapat memperbarui PDT hingga semua kunci lainnya dihapus. Hal yang sama berlaku untuk setiap kunci eksklusif di tabel yang digunakan Looker untuk membangun PDT; jika ada kunci eksklusif di tabel, Looker tidak akan dapat memperoleh kunci bersama untuk menjalankan kueri hingga kunci eksklusif dihapus.
• Gunakan tombol Show Processes di SQL Runner. Jika ada banyak proses yang aktif, hal ini dapat memperlambat waktu kueri.
• Memantau komentar dalam kueri. Lihat bagian Komentar kueri untuk PDT di halaman ini.

Komentar kueri untuk PDT

Administrator database dapat dengan mudah membedakan kueri normal dari kueri yang menghasilkan tabel turunan persisten (PDT). Looker menambahkan komentar ke pernyataan CREATE TABLE ... AS SELECT ... yang menyertakan model dan tampilan LookML PDT, serta ID unik (slug) untuk instance Looker. Jika PDT dibuat atas nama pengguna dalam Mode Pengembangan, komentar akan menunjukkan ID pengguna. Komentar yang dibuat di PDT mengikuti pola ini:

-- Building `<view_name>` in dev mode for user `<user_id>` on instance `<instance_slug>`
CREATE TABLE `<table_name>` SELECT ...
-- finished `<view_name>` => `<table_name>`

Komentar pembuatan PDT akan muncul di tab SQL Jelajah jika Looker harus membuat PDT untuk kueri Jelajah. Komentar akan muncul di bagian atas pernyataan SQL.

Terakhir, komentar pembuatan PDT akan muncul di kolom Message di tab Info pada pop-up Query Details untuk setiap kueri di halaman admin Query.

Membangun kembali PDT setelah kegagalan

Jika tabel turunan persisten (PDT) mengalami kegagalan, berikut yang terjadi saat PDT dikueri:

• Looker akan menggunakan hasil dalam cache jika kueri yang sama sebelumnya dijalankan. (Lihat halaman dokumentasi Kueri cache untuk mendapatkan penjelasan tentang cara kerjanya.)
• Jika hasilnya tidak ada dalam cache, Looker akan mengambil hasil dari PDT dalam database, jika ada versi PDT yang valid.
• Jika tidak ada PDT yang valid dalam database, Looker akan mencoba membangun ulang PDT.
• Jika PDT tidak dapat dibuat ulang, Looker akan menampilkan error untuk kueri. Regenerator Looker akan mencoba membangun ulang PDT saat PDT dikueri lagi atau saat strategi persistensi PDT memicu build ulang lagi.

Dengan PDT bertingkat, logika yang sama berlaku, kecuali dengan PDT bertingkat:

• Kegagalan dalam mem-build untuk satu tabel akan mencegah pembuatan PDT dalam rantai dependensi.
• PDT dependen pada dasarnya membuat kueri PDT yang menjadi dependensinya, sehingga strategi persistensi satu tabel dapat memicu pembuatan ulang PDT yang menaik ke dalam rantai.

Melihat kembali contoh tabel bertingkat sebelumnya, dengan TABLE_D bergantung pada TABLE_C, yang bergantung pada TABLE_B, yang bergantung pada TABLE_A:

Jika TABLE_B gagal, semua perilaku standar (non-jenjang) berlaku untuk TABLE_B: Jika TABLE_B dikueri, Looker akan mencoba menggunakan cache terlebih dahulu untuk menampilkan hasil, lalu mencoba menggunakan tabel versi sebelumnya jika memungkinkan, lalu mencoba membuat ulang tabel, lalu menampilkan error jika TABLE_B tidak dapat dibuat ulang. Looker akan mencoba lagi untuk membuat ulang TABLE_B saat tabel selanjutnya dikueri atau saat strategi persistensi tabel selanjutnya memicu pembuatan ulang.

Hal yang sama juga berlaku untuk dependen TABLE_B. Jadi, jika TABLE_B tidak dapat dibuat, dan ada kueri di TABLE_C:

• Looker akan mencoba menggunakan cache untuk kueri pada TABLE_C.
• Jika hasilnya tidak ada dalam cache, Looker akan mencoba mengambil hasil dari TABLE_C dalam database.
• Jika tidak ada versi TABLE_C yang valid, Looker akan mencoba mem-build ulang TABLE_C, yang membuat kueri di TABLE_B.
• Selanjutnya, Looker akan mencoba membangun ulang TABLE_B (yang akan gagal jika TABLE_B belum diperbaiki).
• Jika TABLE_B tidak dapat dibuat ulang, TABLE_C tidak dapat dibuat ulang, sehingga Looker akan menampilkan error untuk kueri di TABLE_C.
• Looker kemudian akan mencoba membuat ulang TABLE_C sesuai dengan strategi persistensinya yang biasa, atau saat PDT dikueri lagi (yang mencakup saat TABLE_D mencoba membuat build lagi, karena TABLE_D bergantung pada TABLE_C).

Setelah Anda menyelesaikan masalah dengan TABLE_B, TABLE_B dan setiap tabel dependen akan mencoba mem-build ulang sesuai dengan strategi persistensinya, atau saat berikutnya kueri tersebut dibuat kuerinya (yang mencakup saat PDT dependen mencoba membuat ulang lagi). Atau, jika versi pengembangan PDT dalam cascade dibangun dalam Mode Pengembangan, versi pengembangan tersebut dapat digunakan sebagai PDT produksi baru. (Lihat bagian Tabel persisten dalam Mode Pengembangan di halaman ini untuk mengetahui cara kerjanya.) Atau, Anda dapat menggunakan Explore untuk menjalankan kueri di TABLE_D, lalu membuat ulang PDT untuk kueri secara manual, yang akan memaksa pembuatan ulang semua PDT yang menaiki penurunan dependensi.

Meningkatkan performa PDT

Saat Anda membuat tabel turunan persisten (PDT), performa dapat menjadi masalah. Terutama jika tabelnya berukuran sangat besar, proses kueri tabel mungkin akan menjadi lambat, seperti halnya untuk tabel besar dalam database Anda.

Anda dapat meningkatkan performa dengan memfilter data atau dengan mengontrol cara pengurutan dan pengindeksan data dalam PDT.

Menambahkan filter untuk membatasi set data

Dengan set data yang sangat besar, memiliki banyak baris akan memperlambat kueri terhadap tabel turunan persisten (PDT). Jika Anda biasanya membuat kueri data terbaru saja, pertimbangkan untuk menambahkan filter ke klausa WHERE dari PDT yang membatasi tabel hingga 90 hari atau kurang. Dengan cara ini, hanya data yang relevan yang akan ditambahkan ke tabel setiap kali tabel tersebut dibuat ulang sehingga kueri yang berjalan akan jauh lebih cepat. Kemudian, Anda dapat membuat PDT terpisah yang lebih besar untuk analisis historis guna memungkinkan kueri cepat untuk data terbaru dan kemampuan untuk mengkueri data lama.

Menggunakan indexes atau sortkeys dan distribution

Saat Anda membuat tabel turunan persisten (PDT) yang besar, mengindeks tabel (untuk dialek seperti MySQL atau Postgres) atau menambahkan sortkey dan distribusi (untuk Redshift) dapat membantu meningkatkan performa.

Sebaiknya tambahkan parameter indexes pada kolom ID atau tanggal.

Untuk Redshift, sebaiknya tambahkan parameter sortkeys pada kolom ID atau tanggal dan parameter distribution di kolom yang digunakan untuk bergabung.

Setelan yang direkomendasikan untuk meningkatkan performa

Setelan berikut mengontrol cara pengurutan dan pengindeksan data dalam tabel turunan persisten (PDT). Setelan ini bersifat opsional, tetapi sangat direkomendasikan:

• Untuk Redshift dan Aster, gunakan parameter distribution untuk menentukan nama kolom yang nilainya digunakan untuk menyebarkan data di sekitar cluster. Jika dua tabel digabungkan dengan kolom yang ditentukan dalam parameter distribution, database dapat menemukan data gabungan pada node yang sama, sehingga I/O antarnode diminimalkan.
• Untuk Redshift, setel parameter distribution_style ke all untuk menginstruksikan database agar menyimpan salinan data lengkap di setiap node. Ini sering digunakan untuk meminimalkan I/O antar-node ketika tabel-tabel kecil yang relatif bergabung. Setel nilai ini ke even untuk menginstruksikan database agar menyebarkan data secara merata melalui cluster tanpa menggunakan kolom distribusi. Nilai ini hanya dapat ditentukan jika distribution tidak ditentukan.
• Untuk Redshift, gunakan parameter sortkeys. Nilai-nilainya menentukan kolom PDT mana yang digunakan untuk mengurutkan data pada {i>disk<i} untuk membuat pencarian lebih mudah. Pada Redshift, Anda dapat menggunakan sortkeys atau indexes, tetapi tidak keduanya.
• Pada sebagian besar database, gunakan parameter indexes. Nilainya menentukan kolom PDT mana yang diindeks. (Pada Redshift, indeks digunakan untuk menghasilkan kunci pengurutan yang disisipkan.)