Tabel turunan di Looker

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

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

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

Untuk kasus penggunaan tabel turunan yang populer, buka Cookbook 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 di bagian parameter tampilan. Di dalam parameter derived_table, Anda dapat menentukan kueri untuk tabel turunan dengan salah satu dari dua cara berikut:

• 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 ini menggambarkan cara membuat tabel turunan yang setara menggunakan LookML atau SQL untuk menentukan kueri 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 memasukkan 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 tersebut membuat tampilan bernama 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. Baik 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 database.

Tabel turunan native

Tabel turunan native didasarkan pada kueri yang Anda tentukan menggunakan istilah LookML. Untuk membuat tabel turunan native, Anda menggunakan parameter explore_source di dalam parameter derived_table dari 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 mengetahui detail tentang cara membuat tabel turunan native.

Tabel turunan berbasis SQL

Untuk membuat tabel turunan berbasis SQL, Anda menentukan kueri dalam istilah SQL, yang 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 tampilan.

Pintasan yang berguna 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 menggabungkan pernyataan Bahasa Definisi Data (DDL) CREATE TABLE dialek di sekitar kueri Anda untuk membuat PDT dari kueri SQL Anda. 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 contoh.
• 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 menentukan tabel turunan berbasis SQL, pastikan untuk memberi setiap kolom alias yang bersih menggunakan AS. Hal ini karena Anda harus mereferensikan nama kolom set hasil di dimensi, seperti ${TABLE}.first_order. Inilah sebabnya contoh sebelumnya menggunakan MIN(DATE(time)) AS first_order, bukan hanya MIN(DATE(time)).

Catatan: Agar dapat 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 bertahap.

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. Nilai 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 tersebut beserta kolom, join, dan nilai filter yang diminta. Jika kombinasi telah dijalankan sebelumnya dan hasilnya masih valid di cache, Looker akan menggunakan hasil yang di-cache. Lihat halaman dokumentasi Menyimpan kueri dalam 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. Oleh karena itu, Anda harus memastikan bahwa tabel turunan sementara Anda berperforma tinggi dan tidak akan membebani database Anda secara berlebihan. 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 mendukung tabel turunan dalam project Looker, dialek database Anda juga harus mendukungnya. Tabel berikut menunjukkan dialek 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+	Ya
Apache Hive 3.1.2+	Ya
Apache Spark 3+	Ya
ClickHouse	Ya
Cloudera Impala 3.1+	Ya
Cloudera Impala 3.1+ dengan Driver Native	Ya
Cloudera Impala dengan Driver Native	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
Google Cloud PostgreSQL	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 pra-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
Vektor	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) di project Looker, Anda memerlukan hal berikut:

• Dialek database yang mendukung PDT. Lihat bagian Dialek database yang didukung untuk PDT di halaman ini untuk mengetahui daftar dialek yang mendukung tabel turunan berbasis SQL persisten dan tabel turunan native persisten.

• Skema awal di 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.

  Peringatan: Jika Anda memiliki beberapa instance Looker, seperti instance produksi dan instance QA, pastikan untuk menetapkan skema awal yang berbeda untuk setiap instance guna menghindari konflik pengelolaan PDT.

• Koneksi Looker yang dikonfigurasi dengan tombol Enable PDTs diaktifkan. Hal 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 mendukung tabel turunan persisten (PDT) di project Looker, dialek database Anda juga harus mendukungnya.

Untuk mendukung jenis PDT apa pun (berbasis LookML atau berbasis SQL), dialek harus mendukung operasi tulis ke database, di antara persyaratan lainnya. Ada beberapa konfigurasi database hanya baca yang tidak mengizinkan persistensi berfungsi (paling umum database replika hot-swap Postgres). Dalam kasus ini, Anda dapat menggunakan tabel turunan sementara sebagai gantinya.

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+	Ya
Apache Hive 3.1.2+	Ya
Apache Spark 3+	Ya
ClickHouse	Tidak
Cloudera Impala 3.1+	Ya
Cloudera Impala 3.1+ dengan Driver Native	Ya
Cloudera Impala dengan Driver Native	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
Google Cloud PostgreSQL	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 pra-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
Vektor	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 Looker terbaru:

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+	Ya
Apache Hive 3.1.2+	Ya
Apache Spark 3+	Ya
ClickHouse	Tidak
Cloudera Impala 3.1+	Ya
Cloudera Impala 3.1+ dengan Driver Native	Ya
Cloudera Impala dengan Driver Native	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
Google Cloud PostgreSQL	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 pra-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
Vektor	Ya
Vertica	Ya

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

Membangun PDT secara inkremental

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

Jika dialek Anda mendukung PDT inkremental, dan PDT Anda 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 mengetahui informasi selengkapnya.

Dialek database yang didukung untuk PDT inkremental

Agar Looker 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+	Tidak
Apache Hive 3.1.2+	Tidak
Apache Spark 3+	Tidak
ClickHouse	Tidak
Cloudera Impala 3.1+	Tidak
Cloudera Impala 3.1+ dengan Driver Native	Tidak
Cloudera Impala dengan Driver Native	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
Google Cloud PostgreSQL	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 pra-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
Vektor	Tidak
Vertica	Ya

Membuat PDT

Untuk mengubah tabel turunan menjadi tabel turunan persisten (PDT), Anda harus 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 persisten, 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 di database hingga PDT dipicu untuk di-build ulang. Saat PDT dipicu, Looker akan mem-build ulang PDT untuk menggantikan versi sebelumnya. Artinya, dengan PDT berbasis pemicu, pengguna Anda tidak perlu menunggu PDT dibuat untuk mendapatkan jawaban atas kueri Jelajah dari PDT.

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

datagroup_trigger

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

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

Lihat bagian Pembuat ulang Looker untuk mengetahui informasi selengkapnya tentang cara pembuat ulang 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 akan dipertahankan di database. Artinya, dalam sebagian besar kasus, pengguna Anda tidak perlu menunggu PDT dibuat. Jika pengguna meminta data dari PDT saat sedang dibuat, dan hasil kueri tidak ada dalam cache, Looker akan menampilkan data dari PDT yang ada hingga PDT baru dibuat.

Lihat bagian Pembuat ulang Looker untuk mengetahui informasi selengkapnya tentang cara pembuat ulang 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 akan dibuat sebelumnya saat pengguna membuat kueri. Jika pengguna meminta data dari PDT saat sedang dibuat, dan hasil kueri 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 di dalamnya. Looker kemudian mempertahankan PDT di 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 di PDT.

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

PDT yang menggunakan persist_for tidak otomatis di-build ulang oleh regenerator Looker, kecuali dalam kasus cascade dependensi PDT. Jika tabel persist_for adalah bagian dari cascade dependensi dengan PDT berbasis pemicu (PDT yang menggunakan strategi persistensi datagroup_trigger, interval_trigger, atau sql_trigger_value), generator ulang akan memantau dan mem-build ulang tabel persist_for untuk mem-build ulang tabel lain dalam cascade. Lihat bagian Cara Looker membuat tabel turunan berurutan di halaman ini.

materialized_view: yes

Catatan: Fungsi tampilan terwujud adalah fitur lanjutan. Bergantung pada dialek Anda, tampilan yang diwujudkan dapat menggunakan resource yang besar, jadi Anda harus memahami penerapan tampilan yang diwujudkan oleh dialek Anda. Lihat dokumentasi dialek Anda untuk mengetahui informasi tentang perilaku dialek dan frekuensi dialek memuat ulang data untuk tampilan yang diwujudkan.

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

Serupa 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 diperbarui:

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

Oleh karena itu, fungsi tampilan terwujud memerlukan pengetahuan lanjutan tentang dialek 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 yang 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 di 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 menyetelnya untuk dibuat ulang saat grup data orders_datagroup dipicu, 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 untuk dialek Anda), Looker akan memperingatkan Anda 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.

Dalam beberapa kasus, data dapat dioptimalkan melalui 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 alat Explain from SQL Runner.

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

• Pengoptimalan pengujian
• Menggabungkan atau menggabungkan data

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 pengindeksan, distribusi, dan opsi pengoptimalan lainnya tanpa memerlukan banyak dukungan dari developer DBA atau ETL.

Pertimbangkan kasus saat 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]
  }
}

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

Jangan lupa untuk mengubah kode tampilan kembali untuk menghapus PDT.

Menggunakan PDT untuk menggabungkan atau menggabungkan data sebelumnya

Sebaiknya gabungkan atau agregasikan data sebelumnya untuk menyesuaikan pengoptimalan kueri untuk volume tinggi atau beberapa jenis data.

Misalnya, Anda ingin membuat kueri untuk pelanggan berdasarkan kelompok berdasarkan waktu mereka melakukan pesanan pertama. Kueri ini mungkin mahal untuk dijalankan beberapa kali setiap kali data diperlukan secara real time; namun, Anda dapat menghitung kueri hanya sekali, 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 berurutan

Anda dapat mereferensikan satu tabel turunan dalam definisi tabel turunan lainnya, sehingga membuat rantai tabel turunan berurutan, atau tabel turunan persisten berurutan (PDT), sesuai kasusnya. Contoh tabel turunan cascading adalah tabel, TABLE_D, yang bergantung pada tabel lain, TABLE_C, sedangkan TABLE_C bergantung pada TABLE_B, dan TABLE_B bergantung pada TABLE_A.

Catatan: Sebelum menyiapkan tabel turunan berurutan, penting untuk mengetahui cara tabel berurutan otomatis dibuat ulang oleh regenerator Looker dan cara tabel tersebut dapat dibuat ulang secara manual oleh pengguna. Ada juga pertimbangan penting lainnya untuk menerapkan tabel yang dipertahankan. Semua topik ini 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 sintaksis yang sama ini untuk merujuk ke tampilan LookML. Sekali lagi, dalam hal ini, SQL_TABLE_NAME adalah string literal.

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

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

PDT event_summary dan PDT clean_events adalah PDT cascading, 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 merujuk ke tabel turunan dengan cara ini, sebaiknya buat alias untuk tabel 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

Sebaiknya gunakan alias karena, di balik layar, PDT diberi nama dengan kode panjang di database Anda. Dalam beberapa kasus (terutama dengan klausa ON), Anda mungkin lupa bahwa Anda perlu menggunakan sintaksis ${derived_table_or_view_name.SQL_TABLE_NAME} untuk mengambil nama panjang ini. Alias dapat membantu mencegah jenis kesalahan ini.

Cara Looker membuat tabel turunan berurutan

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

Sekarang, mari kita lihat skenario tabel turunan sementara yang berurutan dengan 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 di TABLE_C dalam cache, Looker akan membuat semua tabel yang diperlukan untuk kueri. Jadi, Looker akan mem-build 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 mem-build ulang TABLE_D saat ini.)

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

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

Poin logis penting yang perlu dipahami adalah dalam kasus cascade PDT, PDT dependen pada dasarnya mengajukan kueri PDT yang menjadi dependensinya. Hal ini penting terutama untuk PDT yang menggunakan strategi persist_for. Biasanya, PDT persist_for dibuat saat pengguna membuat kueri, tetap berada di database hingga interval persist_for-nya habis, lalu tidak akan dibuat ulang hingga kueri berikutnya dibuat oleh pengguna. Namun, jika PDT persist_for adalah bagian dari kaskade 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 dependennya di-build ulang. Jadi, dalam hal ini, PDT persist_for akan di-build ulang sesuai jadwal PDT dependennya. Artinya, PDT persist_for dapat terpengaruh oleh strategi persistensi dependennya.

Membangun ulang tabel persisten secara manual untuk kueri

Pengguna dapat memilih opsi Rebuild Derived Tables & Run dari menu Jelajah untuk mengganti setelan persistensi dan mem-build ulang semua tabel turunan persisten (PDT) dan tabel agregat yang diperlukan untuk kueri saat ini di Jelajah:

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

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

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

Dalam kasus PDT berurutan, ini berarti membangun ulang semua tabel turunan dalam urutan, dimulai dari bagian atas. Perilaku ini sama seperti saat Anda membuat kueri tabel dalam cascade tabel turunan sementara:

Perhatikan hal-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 pada kueri pengguna lain saat tabel sedang dibuat ulang, pengguna tersebut tetap dapat terpengaruh oleh beban tambahan pada database Anda. Jika Anda berada dalam situasi saat memicu pembuatan ulang selama jam buka dapat menyebabkan beban 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 tersebut.

• Jika pengguna berada dalam Mode Pengembangan dan Eksplorasi didasarkan pada tabel pengembangan, operasi Buat Ulang Tabel Turunan & Jalankan akan membuat ulang tabel pengembangan, bukan tabel produksi, untuk Eksplorasi. Namun, jika Jelajahi dalam Mode Pengembangan menggunakan versi produksi tabel turunan, tabel produksi akan dibuat ulang. Lihat Tabel yang dipertahankan dalam Mode Pengembangan untuk mengetahui informasi tentang tabel pengembangan dan tabel produksi.

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

Tabel yang dipertahankan 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 agregat serta tabel turunan persisten (PDT).

Jika Anda membuat kueri tabel yang dipertahankan dalam Mode Pengembangan tanpa membuat perubahan pada definisinya, Looker akan membuat kueri 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 di Mode Pengembangan lagi. Dengan memiliki tabel pengembangan tersebut, Anda dapat menguji perubahan tanpa mengganggu pengguna akhir.

Yang meminta Looker membuat tabel pengembangan

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

• Jika tabel yang dipertahankan memiliki parameter yang mempersempit set datanya agar berfungsi lebih cepat dalam Mode Pengembangan
• Jika Anda telah membuat perubahan pada definisi tabel yang dipertahankan 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 yang dipertahankan yang tidak memiliki parameter untuk mempersempit set data dalam Mode Pengembangan, Looker menggunakan versi produksi tabel untuk menjawab kueri dalam Mode Pengembangan, kecuali jika Anda mengubah definisi tabel, lalu membuat kueri tabel dalam Mode Pengembangan. Hal ini berlaku untuk setiap perubahan pada tabel yang memengaruhi data dalam tabel atau cara tabel dikueri.

Berikut adalah beberapa contoh jenis perubahan yang akan meminta Looker 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 yang diperlukan (dalam kasus tabel turunan berurutan)
• 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 Looker mempertahankan tabel pengembangan

Terlepas dari strategi persistensi tabel yang sebenarnya, Looker memperlakukan tabel yang dipertahankan pengembangan seolah-olah memiliki strategi persistensi persist_for: "24 hours". Looker melakukan hal ini untuk memastikan bahwa tabel pengembangan tidak dipertahankan selama lebih dari satu hari, karena developer Looker dapat membuat kueri untuk banyak iterasi tabel selama pengembangan, dan setiap kali tabel pengembangan baru dibuat. Untuk mencegah tabel pengembangan memenuhi database, Looker menerapkan strategi persist_for: "24 hours" untuk memastikan tabel dihapus 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 dipertahankan di database saat Anda men-deploy perubahan ke 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 pada 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 di-build menggunakan Looker IDE atau menggunakan tab Development di halaman Persistent Derived Tables. Jika memiliki PDT yang belum di-build, Anda dapat membuat kueri di 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 mengomentari parameter dev_filters atau klausa WHERE bersyarat, lalu membuat kueri tabel dalam Mode Pengembangan. Looker kemudian akan membuat versi lengkap tabel yang dapat digunakan untuk produksi saat Anda men-deploy perubahan.

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

Memeriksa PDT yang belum di-build dalam Mode Pengembangan

Jika tabel pengembangan dipertahankan di database saat Anda men-deploy perubahan ke 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 Looker mempertahankan tabel pengembangan dan Yang mendorong Looker membuat tabel pengembangan di halaman ini untuk mengetahui detail selengkapnya.

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

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

Jika ada PDT yang tidak di-build, 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. Dari sana, Anda dapat melihat PDT pengembangan mana yang di-build dan tidak di-build serta mengakses informasi pemecahan masalah lainnya. Lihat halaman dokumentasi Setelan admin - Tabel Turunan Persisten untuk mengetahui informasi selengkapnya.

Setelah mengidentifikasi PDT yang belum di-build dalam project, Anda dapat mem-build versi pengembangannya dengan membuka Jelajahi yang membuat kueri tabel, lalu menggunakan opsi Build Ulang Tabel Turunan & Jalankan dari menu Jelajahi. Lihat bagian Mem-build ulang tabel persisten secara manual untuk kueri di halaman ini.

Catatan: Jika tabel yang dipertahankan 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 Durasi Looker mempertahankan tabel pengembangan 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 Yang mendorong Looker untuk membuat tabel pengembangan di halaman dokumentasi ini).

Pembersihan dan pembagian tabel

Dalam instance Looker tertentu, Looker akan membagikan tabel yang dipertahankan di antara pengguna jika tabel memiliki definisi yang sama dan setelan metode persistensi yang sama. Selain itu, jika definisi tabel tidak ada lagi, Looker akan menandai tabel tersebut sebagai habis masa berlakunya.

Hal ini memiliki beberapa manfaat:

• Jika Anda belum membuat perubahan pada tabel dalam Mode Pengembangan, kueri Anda akan menggunakan tabel produksi yang ada. Hal ini berlaku kecuali jika 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 kebetulan membuat perubahan yang sama pada tabel saat dalam Mode Pengembangan, mereka akan berbagi tabel pengembangan yang sama.
• Setelah Anda menerapkan perubahan dari Mode Pengembangan ke Mode Produksi, definisi produksi lama tidak ada lagi, sehingga tabel produksi lama ditandai sebagai habis masa berlakunya dan akan dihapus.
• Jika Anda memutuskan untuk menghapus perubahan Mode Pengembangan, definisi tabel tersebut tidak akan ada lagi, sehingga tabel pengembangan yang tidak diperlukan akan ditandai sebagai habis masa berlakunya dan akan dihapus.

Bekerja lebih cepat dalam Mode Pengembangan

Ada situasi saat tabel turunan persisten (PDT) yang Anda buat memerlukan waktu lama untuk dibuat, yang 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 Anda 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 menyertakan parameter dev_filters yang memfilter data ke 90 hari terakhir dan parameter filters yang memfilter data ke 2 tahun terakhir dan ke Bandara Yucca Valley.

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 akan diprioritaskan untuk versi pengembangan tabel. Dalam contoh ini, versi pengembangan tabel akan memfilter data ke 90 hari terakhir untuk Bandara Yucca Valley.

Untuk tabel turunan berbasis SQL, Looker mendukung klausa WHERE bersyarat dengan opsi yang 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 menyertakan 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 set 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 mengomentari parameter dev_filters atau klausa WHERE bersyarat, 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 Durasi Looker mempertahankan tabel pengembangan di halaman ini untuk mengetahui detail selengkapnya tentang penggunaan tabel pengembangan dalam produksi.

Cara Looker mem-build PDT

Setelah tabel turunan persisten (PDT) ditentukan dan dijalankan untuk pertama kalinya atau dipicu oleh regenerator untuk di-build ulang sesuai dengan strategi persistensinya, Looker akan melakukan 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. Buat pernyataan untuk membuat indeks saat tabel dibuat
3. Ganti nama tabel dari LC$.. ("Looker Create") menjadi LR$.. ("Looker Read"), untuk menunjukkan bahwa tabel siap digunakan
4. Hapus versi tabel yang lebih lama yang tidak boleh digunakan lagi

Ada beberapa implikasi penting:

• SQL yang membentuk tabel turunan harus valid di dalam pernyataan CTAS.
• Alias kolom pada set 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 tabel turunan, bukan nama kolom yang ditentukan dalam LookML.

Regenerator Looker

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

• Untuk tabel yang menggunakan sql_trigger_value, pemicu 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(), generator ulang Looker akan membuat ulang tabel saat berikutnya generator ulang 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 yang dipertahankan yang menggunakan parameter persist_for, tetapi hanya jika tabel persist_for adalah cascade dependensi dari tabel yang dipertahankan pemicu. Dalam hal ini, generator ulang Looker akan memulai pembuatan ulang untuk tabel persist_for, karena tabel tersebut diperlukan untuk membuat ulang tabel lain dalam kaskade. Jika tidak, generator ulang tidak akan memantau tabel yang dipertahankan yang menggunakan strategi persist_for.

Siklus regenerator Looker dimulai pada interval reguler yang dikonfigurasi oleh admin Looker di setelan Datagroup and PDT Maintenance Schedule pada koneksi database Anda (defaultnya 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 generator ulang Looker mungkin tidak berjalan sesering yang ditentukan dalam setelan Jadwal Pemeliharaan PDT dan Grup Data. Faktor lain dapat memengaruhi waktu yang diperlukan untuk mem-build ulang tabel, seperti yang dijelaskan di bagian Pertimbangan penting untuk menerapkan tabel yang dipertahankan di halaman ini.

Jika PDT gagal dibuat, regenerator dapat mencoba membuat ulang tabel dalam siklus regenerator berikutnya:

• Jika setelan Retry Failed PDT Builds diaktifkan pada koneksi database Anda, generator ulang Looker akan mencoba membuat ulang tabel selama siklus generator ulang berikutnya, meskipun kondisi pemicu tabel tidak terpenuhi.
• Jika setelan Retry Failed PDT Builds dinonaktifkan, generator ulang Looker tidak akan mencoba membuat ulang tabel hingga kondisi pemicu PDT terpenuhi.

Jika pengguna meminta data dari tabel yang dipertahankan saat sedang dibuat dan hasil kueri tidak ada dalam cache, Looker akan memeriksa apakah tabel yang ada masih valid. (Tabel sebelumnya mungkin tidak valid jika tidak kompatibel dengan versi baru tabel, 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. Jika tidak, jika tabel yang ada tidak valid, Looker akan memberikan hasil kueri setelah tabel baru dibuat ulang.

Pertimbangan penting untuk menerapkan tabel yang dipertahankan

Mengingat kegunaan tabel yang dipertahankan (PDT dan tabel agregat), Anda dapat dengan mudah mengumpulkan banyak tabel tersebut di instance Looker. Anda dapat membuat skenario saat regenerator Looker perlu membuat banyak tabel secara bersamaan. Khususnya dengan tabel berurutan, atau tabel yang berjalan lama, Anda dapat membuat skenario saat tabel mengalami penundaan yang lama sebelum di-build ulang, atau saat pengguna mengalami penundaan dalam mendapatkan hasil kueri dari tabel saat database bekerja keras untuk membuat tabel.

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

Beberapa faktor dapat memengaruhi waktu yang diperlukan untuk mem-build ulang tabel:

• Admin Looker Anda mungkin telah mengubah interval pemeriksaan pemicu regenerator menggunakan setelan Jadwal Pemeliharaan PDT dan Grup Data pada koneksi database Anda.
• Penghasil ulang Looker tidak memulai siklus baru hingga menyelesaikan semua pemeriksaan dan membangun ulang PDT dari siklus terakhir. Jadi, jika Anda memiliki build PDT yang berjalan lama, siklus regenerator Looker mungkin tidak sefrekuen setelan Jadwal Pemeliharaan Datagroup dan PDT.
• Secara default, regenerator dapat memulai pembuatan ulang satu PDT atau tabel gabungan satu per satu melalui koneksi. Admin Looker dapat menyesuaikan jumlah pembuatan ulang serentak yang diizinkan oleh regenerator menggunakan kolom Max number of PDT builder connections di setelan koneksi.
• Semua PDT dan tabel gabungan yang dipicu oleh datagroup yang sama akan dibuat ulang selama proses regenerasi yang sama. Hal ini dapat menjadi beban berat jika Anda memiliki banyak tabel yang menggunakan grup data, baik secara langsung maupun sebagai hasil dari dependensi cascading.

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

• Saat tabel turunan akan diperluas — Setiap ekstensi PDT akan membuat salinan baru tabel 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.
• Saat tabel turunan native dibuat dari Eksplorasi 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.
• Jika data pokok sering berubah dan dialek database Anda tidak mendukung PDT inkremental.
• Jika biaya dan waktu yang diperlukan untuk membuat PDT terlalu tinggi.

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

Mengelola PDT dalam skala besar melalui API

Memantau dan mengelola tabel turunan persisten (PDT) yang dimuat ulang pada jadwal yang bervariasi menjadi semakin rumit saat Anda membuat lebih banyak PDT di instance. Sebaiknya gunakan integrasi Apache Airflow Looker untuk mengelola jadwal PDT bersama dengan 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 Tabel Turunan Persisten Looker untuk melihat status PDT. Lihat halaman dokumentasi Setelan admin - Tabel Turunan Persisten untuk mengetahui informasinya.

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 di Looker, lalu mungkin memulai ulang Looker untuk memulihkan fungsi PDT normal.
• Tentukan apakah ada masalah dengan semua PDT, atau hanya satu. Jika ada masalah dengan salah satunya, masalah tersebut kemungkinan disebabkan oleh error LookML atau SQL.
• Tentukan apakah masalah pada PDT sesuai dengan waktu saat PDT dijadwalkan untuk di-build 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 melindungi dari kueri yang berjalan tanpa henti.) Untuk informasi selengkapnya tentang penggunaan SQL Runner untuk men-debug tabel turunan, lihat postingan Komunitas Menggunakan SQL Runner untuk menguji tabel turunan .
• Untuk PDT berbasis SQL, gunakan SQL Runner untuk memverifikasi bahwa SQL PDT dijalankan 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 mereferensikan DT tersebut dari DT pertama Anda menggunakan sintaksis ${derived_table_or_view_name.SQL_TABLE_NAME}.
• Pastikan tabel yang menjadi dependensi PDT masalah — baik tabel normal maupun PDT itu sendiri — ada dan dapat dikueri.
• Pastikan tabel yang menjadi dependensi PDT masalah tidak memiliki kunci bersama atau eksklusif. Agar berhasil mem-build PDT, Looker harus mendapatkan kunci eksklusif pada tabel yang akan diperbarui. Tindakan ini akan bertentangan dengan kunci bersama atau eksklusif lainnya yang saat ini ada di tabel. Looker tidak akan dapat memperbarui PDT hingga semua kunci lainnya telah dihapus. Hal yang sama berlaku untuk kunci eksklusif pada tabel tempat Looker membuat PDT; jika ada kunci eksklusif pada 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.
• Pantau komentar dalam kueri. Lihat bagian Komentar kueri untuk PDT di halaman ini.

Membuat kueri komentar 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 pembuatan 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 Pesan pada tab Info di pop-up Detail Kueri untuk setiap kueri di halaman admin Kueri.

Mem-build ulang PDT setelah kegagalan

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

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

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

• Kegagalan build untuk satu tabel akan mencegah build PDT di sepanjang rantai dependensi.
• PDT dependen pada dasarnya mengkueri PDT yang menjadi andalannya, sehingga strategi persistensi satu tabel dapat memicu pembuatan ulang PDT yang naik ke rantai.

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

Jika TABLE_B mengalami kegagalan, semua perilaku standar (non-cascade) akan berlaku untuk TABLE_B: Jika TABLE_B dikueri, Looker akan mencoba menggunakan cache terlebih dahulu untuk menampilkan hasil, lalu mencoba menggunakan versi tabel sebelumnya jika memungkinkan, lalu mencoba membuat ulang tabel, lalu akhirnya akan menampilkan error jika TABLE_B tidak dapat dibuat ulang. Looker akan mencoba lagi untuk mem-build ulang TABLE_B saat tabel dikueri berikutnya atau saat strategi persistensi tabel berikutnya memicu build 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 di 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 akan membuat kueri di TABLE_B.
• Looker kemudian akan mencoba mem-build ulang TABLE_B (yang akan gagal jika TABLE_B belum diperbaiki).
• Jika TABLE_B tidak dapat dibuat ulang, TABLE_C juga tidak dapat dibuat ulang, sehingga Looker akan menampilkan error untuk kueri di TABLE_C.
• Looker kemudian akan mencoba mem-build ulang TABLE_C sesuai dengan strategi persistensi biasanya, atau saat berikutnya PDT dikueri (yang mencakup saat berikutnya TABLE_D mencoba mem-build, karena TABLE_D bergantung pada TABLE_C).

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

Meningkatkan performa PDT

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

Anda dapat meningkatkan performa dengan memfilter data atau dengan mengontrol cara data di PDT diurutkan dan diindeks.

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 hanya membuat kueri untuk data terbaru, pertimbangkan untuk menambahkan filter ke klausa WHERE PDT yang membatasi tabel hingga 90 hari atau kurang. Dengan cara ini, hanya data yang relevan yang akan ditambahkan ke tabel setiap kali tabel 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 membuat kueri 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 kunci pengurutan dan distribusi (untuk Redshift) dapat membantu performa.

Sebaiknya tambahkan parameter indexes di kolom ID atau tanggal.

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

Setelan yang direkomendasikan untuk meningkatkan performa

Setelan berikut mengontrol cara data dalam tabel turunan persisten (PDT) diurutkan dan diindeks. 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. Saat dua tabel digabungkan oleh kolom yang ditentukan dalam parameter distribution, database dapat menemukan data join di node yang sama, sehingga I/O antar-node diminimalkan.
• Untuk Redshift, tetapkan parameter distribution_style ke all untuk menginstruksikan database agar menyimpan salinan lengkap data di setiap node. Hal ini sering digunakan untuk meminimalkan I/O antar-node saat tabel yang relatif kecil digabungkan. Tetapkan 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 tersebut menentukan kolom PDT mana yang digunakan untuk mengurutkan data di disk agar memudahkan penelusuran. Di Redshift, Anda dapat menggunakan sortkeys atau indexes, tetapi tidak keduanya.
• Di sebagian besar database, gunakan parameter indexes. Nilai menentukan kolom PDT mana yang diindeks. (Di Redshift, indeks digunakan untuk membuat kunci pengurutan yang diselingi.)