Tabel turunan di Looker

Dalam Looker, tabel turunan adalah kueri yang hasilnya digunakan seolah-olah kueri tersebut adalah tabel sebenarnya dalam basis data.

Misalnya, Anda mungkin memiliki tabel basis data bernama orders yang memiliki banyak kolom. Anda ingin menghitung beberapa metrik agregat tingkat pelanggan, seperti berapa banyak pesanan yang telah dilakukan setiap pelanggan atau kapan setiap pelanggan melakukan pesanan pertama mereka. Dengan menggunakan tabel turunan asli atau tabel turunan berbasis SQL, Anda dapat membuat tabel basis data baru bernama customer_order_summary yang menyertakan metrik-metrik ini.

Anda kemudian dapat bekerja dengan tabel turunan customer_order_summary seolah-olah itu adalah tabel lain di dalam basis data.

Untuk contoh penggunaan tabel turunan yang populer, kunjungi Looker cookbooks: Memanfaatkan tabel turunan secara maksimal di Looker.

Tabel turunan asli dan tabel turunan berbasis SQL

Untuk membuat tabel turunan di proyek Looker Anda, gunakanderived_table parameter di bawah sebuahmelihat parameter. Di dalam parameter derived_table, Anda dapat menentukan kueri untuk tabel turunan dengan salah satu dari dua cara:

• Untuk tabel turunan asli, Anda mendefinisikan tabel turunan dengan kueri berbasis LookML.
• Untuk sebuahTabel turunan berbasis SQL Anda mendefinisikan tabel turunan dengan kueri SQL.

Misalnya, berkas tampilan berikut menunjukkan bagaimana Anda dapat menggunakan LookML untuk membuat tampilan dari tabel turunan customer_order_summary. Kedua versi LookML tersebut mengilustrasikan bagaimana Anda dapat membuat tabel turunan yang setara menggunakan LookML atau SQL untuk mendefinisikan kueri untuk tabel turunan tersebut:

• Tabel turunan asli mendefinisikan kueri dengan LookML pada parameter explore_source. Dalam contoh ini, kueri didasarkan pada tampilan orders yang sudah ada, yang didefinisikan dalam file terpisah yang tidak ditampilkan dalam contoh ini. Kueri explore_source dalam tabel turunan asli mengambil field customer_id, first_order, dan total_amount dari file tampilan orders.
• Tabel turunan berbasis SQL mendefinisikan kueri menggunakan SQL pada parameter sql. Dalam contoh ini, kueri SQL adalah kueri langsung ke tabel orders di dalam basis data.

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 ;;
  }
}

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 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. 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 view. Anda membuat kolom tabel turunan native dengan merujuk ke dimensi atau ukuran LookML dalam model. Lihat file tampilan tabel turunan native dalam contoh sebelumnya.

Dibandingkan dengan tabel turunan berbasis SQL, tabel turunan native jauh lebih mudah dibaca dan dipahami saat Anda memodelkan 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, 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 dalam contoh sebelumnya.

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

Cara pintas yang berguna untuk membuat kueri berbasis SQL di Looker adalah dengan 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 bagi tabel turunan persisten (PDT):

• create_process: Saat Anda menggunakan parameter sql untuk PDT, di latar belakang, Looker akan membungkus pernyataan Bahasa Definisi Data (DDL) CREATE TABLE dialek di sekitar kueri Anda untuk membuat PDT dari kueri SQL Anda. Beberapa dialek tidak mendukung pernyataan SQL CREATE TABLE 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_createJika kasus penggunaan Anda memerlukan kustomisasiDDL perintah dan dialek Anda mendukung DDL (misalnya, prediksi Google)BigQuery ML ), Anda dapat menggunakansql_create parameter untuk membuat PDT alih-alih menggunakansql parameter. Lihatsql_create Halaman dokumentasi untuk informasi dan contoh.

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

Saat Anda mendefinisikan tabel turunan berbasis SQL, pastikan untuk memberi setiap kolom alias yang jelas dengan menggunakan AS. Hal ini karena Anda perlu merujuk nama kolom dari kumpulan hasil Anda dalam dimensi Anda, seperti ${TABLE}.first_order. Inilah mengapa contoh sebelumnya menggunakan MIN(DATE(time)) AS first_order dan bukan hanya MIN(DATE(time)).

Tabel turunan sementara dan permanen

Selain perbedaan antara tabel turunan asli dan tabel turunan berbasis SQL, ada juga perbedaan antara tabel turunan sementara (temporary derived table) — yang tidak ditulis ke basis data — dan tabel turunan tetap (persistent derived table (PDT) — yang ditulis ke skema pada basis data Anda.

Tabel turunan asli dan tabel turunan berbasis SQL dapat bersifat sementara atau permanen.

Tabel turunan sementara

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

Tabel turunan sementara tidak ditulis ke dalam basis data. Saat pengguna menjalankan kueri Jelajahi yang melibatkan satu atau lebih tabel turunan, Looker membuat kueri SQL dengan menggunakan kombinasi spesifik dialek dari SQL untuk tabel turunan ditambah bidang, gabungan, dan nilai filter yang diminta. Jika kombinasi tersebut telah dijalankan sebelumnya dan hasilnya masih valid di dalam cache, Looker akan menggunakan hasil yang tersimpan dalam cache. Lihat halaman dokumentasi Caching queries untuk informasi lebih lanjut tentang caching kueri di Looker.

Jika tidak, jika Looker tidak dapat menggunakan hasil yang di-cache, Looker harus menjalankan kueri baru pada basis data Anda setiap kali pengguna meminta data dari tabel turunan sementara. Oleh karena itu, Anda harus memastikan bahwa tabel turunan sementara Anda berkinerja baik dan tidak akan memberikan beban berlebihan pada basis data Anda. Dalam kasus di mana kueri akan membutuhkan waktu untuk dijalankan, PDT seringkali merupakan pilihan yang lebih baik.

Dialek basis data yang didukung untuk tabel turunan sementara

Agar Looker dapat mendukung tabel turunan dalam proyek Looker Anda, dialek basis data Anda juga harus mendukungnya. Tabel berikut menunjukkan dialek mana yang mendukung tabel turunan dalam rilis terbaru Looker:

Tabel turunan persisten

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

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

Persyaratan untuk PDT

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

• Dialek basis data yang mendukung PDT. Lihat bagian Dialek basis data yang didukung untuk PDT di halaman ini untuk daftar dialek yang mendukung tabel turunan berbasis SQL persisten dan tabel turunan asli persisten.

• Skema sementara pada basis data Anda. Ini bisa berupa skema apa pun di basis data Anda, tetapi kami sarankan untuk membuat skema baru yang hanya akan digunakan untuk tujuan ini. Administrator basis data Anda harus mengkonfigurasi skema dengan izin tulis untuk pengguna basis data Looker.

• Koneksi Looker yang dikonfigurasi dengan sakelar Aktifkan PDT diaktifkan. Pengaturan Aktifkan PDT ini biasanya dikonfigurasi saat Anda pertama kali menyiapkan koneksi Looker Anda (lihat halaman dokumentasi Dialek Looker untuk petunjuk dialek basis data Anda), tetapi Anda juga dapat mengaktifkan PDT untuk koneksi Anda setelah pengaturan awal.

Dialek basis data yang didukung untuk PDT

Agar Looker dapat mendukung PDT dalam proyek Looker Anda, dialek basis data Anda juga harus mendukungnya.

Untuk mendukung semua jenis PDT (baik berbasis LookML maupun berbasis SQL), dialek harus mendukung penulisan ke basis data, di antara persyaratan lainnya. Terdapat beberapa konfigurasi basis data hanya baca yang tidak memungkinkan persistensi berfungsi (paling umum adalah basis data replika hot-swap Postgres). Dalam kasus ini, Anda dapat menggunakan tabel turunan sementara sebagai gantinya.

Tabel berikut menunjukkan dialek-dialek yang mendukung persistensi.Tabel turunan berbasis SQL dalam rilis terbaru Looker:

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

Membangun PDT secara bertahap

Sebuah PDT inkremental adalah sebuah tabel turunan persisten yang dibangun oleh Looker dengan menambahkan data baru ke dalam tabel, bukan membangunnya kembali secara keseluruhan.

Jika AndaDialek mendukung PDT bertahap., dan PDT Anda menggunakan strategi persistensi berbasis pemicu (datagroup_trigger, sql_trigger_value, atauinterval_trigger ), Anda bisamendefinisikan PDT sebagai PDT inkremental .

Lihat halaman dokumentasi PDT Inkremental untuk informasi selengkapnya.

Dialek basis data yang didukung untuk PDT inkremental

Agar Looker dapat mendukung PDT inkremental dalam proyek Looker Anda, dialek basis data Anda juga harus mendukungnya. Tabel berikut menunjukkan dialek mana yang mendukung PDT inkremental pada rilis terbaru Looker:

Membuat PDT

Untuk menjadikan tabel turunan menjadi tabel turunan persisten (PDT), Anda menentukan strategi persistensi untuk tabel tersebut. Untuk mengoptimalkan kinerja, Anda juga harus menambahkan strategi optimasi.

Strategi persistensi

Keberlangsungan tabel turunan dapat dikelola oleh Looker atau, untuk dialek yang mendukung materialisasi tampilan, oleh basis data Anda menggunakan materialisasi tampilan.

Untuk membuat tabel turunan menjadi 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 basis data:
  • materialized_view: yes

Dengan strategi persistensi berbasis pemicu (datagroup_trigger, sql_trigger_value, dan interval_trigger), Looker mempertahankan PDT di dalam basis data hingga PDT dipicu untuk dibangun kembali. Saat PDT dipicu, Looker membangun ulang PDT untuk menggantikan versi sebelumnya. Artinya, dengan PDT berbasis pemicu, pengguna Anda tidak perlu menunggu PDT dibangun untuk mendapatkan jawaban atas kueri Jelajahi dari PDT.

datagroup_trigger

Datagroups adalah metode yang paling fleksibel untuk membuat persistensi. Jika Anda telah mendefinisikan sebuahkelompok data dengansql_trigger atauinterval_trigger Anda dapat menggunakandatagroup_trigger parameter untuk memulai pembangunan ulang tabel turunan persisten (PDT) Anda.

Looker menyimpan PDT di dalam basis data hingga grup datanya dipicu. Saat grup data dipicu, Looker membangun ulang PDT untuk menggantikan versi sebelumnya. Ini berarti bahwa, dalam sebagian besar kasus, pengguna Anda tidak perlu menunggu PDT (Pattern Day Test) selesai dibuat. Jika pengguna meminta data dari PDT saat PDT tersebut sedang dibangun dan hasil kueri belum ada di dalam cache, Looker akan mengembalikan data dari PDT yang ada hingga PDT baru selesai dibangun. Lihat Caching queries untuk gambaran umum tentang grup data.

Lihat bagian tentang Regenerator Looker untuk informasi lebih lanjut tentang bagaimana regenerator membangun PDT.

sql_trigger_value

Itusql_trigger_value Parameter ini memicu pembuatan ulang tabel turunan persisten (PDT) yang didasarkan pada pernyataan SQL yang Anda berikan. Jika hasil pernyataan SQL berbeda dari nilai sebelumnya, PDT akan dibuat ulang. Jika tidak, PDT yang ada akan tetap tersimpan dalam basis data. Ini berarti bahwa, dalam sebagian besar kasus, pengguna Anda tidak perlu menunggu PDT (Pattern Day Test) selesai 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 tentang Regenerator Looker untuk informasi lebih lanjut tentang bagaimana regenerator membangun 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". Mirip dengan parameter sql_trigger, hal ini berarti PDT biasanya akan dibuat sebelumnya saat pengguna Anda 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 jangka waktu tabel turunan harus disimpan sebelum ditandai sebagai habis masa berlaku, 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. Kemudian, Looker mempertahankan PDT dalam database selama jangka waktu yang ditentukan dalam parameter persist_for PDT. Jika pengguna menjalankan 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 dibangun ulang saat pengguna berikutnya membuat kueri, yang berarti kueri harus menunggu pembangunan ulang.

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

materialized_view: yes

Tampilan terwujud memungkinkan Anda menggunakan fungsi database untuk mempertahankan tabel turunan di project Looker. Jika dialek database Anda mendukung tampilan yang di-materialisasi dan koneksi Looker Anda dikonfigurasi dengan tombol Aktifkan PDT diaktifkan, Anda dapat membuat tampilan yang di-materialisasi 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 di skema sementara database Anda. Perbedaan utama antara PDT dan tampilan yang di-materialisasi 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 materialisasi memerlukan pengetahuan tingkat lanjut tentang dialek Anda dan fitur-fiturnya. Dalam kebanyakan kasus, basis data Anda akan memperbarui tampilan materialisasi setiap kali basis data mendeteksi data baru dalam tabel yang dikueri oleh tampilan materialisasi tersebut. Materialized view paling optimal untuk skenario yang membutuhkan data real-time.

Lihatmaterialized_view Halaman dokumentasi parameter untuk informasi tentang dukungan dialek, persyaratan, dan pertimbangan penting.

Strategi optimasi

Karena tabel turunan persisten (PDT) disimpan dalam basis data Anda, Anda harus mengoptimalkan PDT Anda menggunakan strategi berikut, sesuai dengan dialek yang Anda gunakan:

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

Misalnya, untuk menambahkan persistensi ke tabel turunan example, Anda dapat mengaturnya untuk dibangun ulang ketika grup data orders_datagroup dipicu, dan menambahkan indeks pada 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 kinerja kueri.

Kasus penggunaan PDT

Tabel turunan persisten (PDT) berguna karena dapat meningkatkan kinerja kueri dengan menyimpan hasil kueri dalam sebuah tabel.

Sebagai praktik terbaik secara umum, pengembang sebaiknya mencoba memodelkan data tanpa menggunakan PDT (Planned Data Techniques) kecuali benar-benar diperlukan.

Dalam beberapa kasus, data dapat dioptimalkan melalui cara lain. Sebagai contoh, menambahkan indeks atau mengubah tipe data kolom dapat menyelesaikan masalah tanpa perlu membuat PDT. Pastikan untuk menganalisis rencana eksekusi kueri yang lambat menggunakan alat Explain dari SQL Runner.

Selain mengurangi waktu eksekusi kueri dan beban basis data pada kueri yang sering dijalankan, terdapat beberapa kegunaan lain untuk PDT, termasuk:

• Optimasi pengujian
• Penggabungan atau penggabungan data sebelumnya

Anda juga dapat menggunakan PDT untuk mendefinisikan kunci utama dalam kasus di mana tidak ada cara yang masuk akal untuk mengidentifikasi baris unik dalam tabel sebagai kunci utama.

Menggunakan PDT untuk menguji optimasi

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

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

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

Untuk menguji strategi optimasi, Anda dapat menggunakanindexes parameter 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]
  }
}

Lakukan query pada view sekali untuk menghasilkan PDT. Kemudian jalankan kueri pengujian Anda dan bandingkan hasilnya. Jika hasilnya memuaskan, Anda dapat meminta tim DBA atau ETL Anda untuk menambahkan indeks ke tabel asli.

Ingat untuk mengubah kembali kode tampilan Anda untuk menghapus PDT.

Menggunakan PDT untuk menggabungkan atau mengagregasi data terlebih dahulu.

Menggabungkan atau mengagregasi data terlebih dahulu dapat bermanfaat untuk menyesuaikan optimasi kueri untuk volume data yang tinggi atau berbagai jenis data.

Sebagai contoh, anggaplah Anda ingin membuat kueri untuk pelanggan berdasarkan kelompok waktu (cohort) yang mereka gunakan untuk melakukan pemesanan pertama. Kueri ini mungkin mahal jika dijalankan berulang kali setiap kali data dibutuhkan secara real-time; namun, Anda dapat menghitung kueri hanya sekali dan kemudian 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

Dimungkinkan untuk merujuk satu tabel turunan dalam definisi tabel turunan lainnya, sehingga menciptakan rantai. tabel turunan bertingkat, atau tabel turunan persisten (PDT) bertingkat, tergantung situasinya. Contoh tabel turunan bertingkat 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.

Sintaks untuk merujuk ke tabel turunan

Untuk merujuk tabel turunan di dalam tabel turunan lain, gunakan sintaks berikut:

`${derived_table_or_view_name.SQL_TABLE_NAME}`

Dalam format ini, SQL_TABLE_NAME adalah string literal. Misalnya, Anda dapat merujuk ke tabel turunan clean_events dengan sintaks ini:

`${clean_events.SQL_TABLE_NAME}`

Anda dapat menggunakan sintaks yang sama untuk merujuk ke tampilan LookML. Sekali lagi, dalam kasus ini, SQL_TABLE_NAME adalah string literal.

Pada contoh berikutnya, PDT clean_events dibuat dari tabel events di dalam basis data. PDT clean_events menghilangkan baris yang tidak diinginkan dari tabel basis data events. Kemudian PDT kedua 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 bertingkat, di mana event_summary bergantung pada clean_events (karena event_summary didefinisikan menggunakan PDT clean_events). Contoh khusus ini sebenarnya bisa dilakukan lebih efisien dalam satu PDT (Planned Data Type), tetapi berguna untuk mendemonstrasikan 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, seringkali berguna untuk membuat alias untuk tabel tersebut dengan menggunakan format ini:

${derived_table_or_view_name.SQL_TABLE_NAME} AS derived_table_or_view_name

Contoh sebelumnya melakukan hal berikut:

${clean_events.SQL_TABLE_NAME} AS clean_events

Sebaiknya gunakan alias karena, di balik layar, PDT diberi nama dengan kode panjang di dalam basis data Anda. Dalam beberapa kasus (terutama dengan klausa ON), ada kemungkinan Anda lupa bahwa Anda perlu menggunakan sintaks ${derived_table_or_view_name.SQL_TABLE_NAME} untuk mengambil nama yang panjang ini. Penggunaan alias dapat membantu mencegah kesalahan jenis ini.

Bagaimana Looker membangun tabel turunan bertingkat

Dalam kasus tabel turunan temporary yang bertingkat, jika hasil kueri pengguna tidak ada dalam cache, Looker akan membangun semua tabel turunan yang dibutuhkan untuk kueri tersebut. Jika Anda memiliki TABLE_D yang definisinya berisi referensi ke TABLE_C, maka TABLE_D adalah bergantung pada TABLE_C. Ini berarti bahwa jika Anda melakukan kueri TABLE_D dan kueri tersebut tidak ada dalam cache Looker, Looker akan membangun ulang TABLE_D. Namun pertama-tama, ia harus membangun kembali TABLE_C.

Pertimbangkan skenario dengan tabel turunan sementara yang berjenjang, di mana 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 pada TABLE_C di dalam cache, Looker akan membuat semua tabel yang dibutuhkan untuk kueri tersebut. Jadi Looker akan membangun TABLE_A, lalu TABLE_B, lalu TABLE_C:

Dalam skenario ini, TABLE_A harus selesai dihasilkan sebelum Looker dapat mulai menghasilkan TABLE_B, dan TABLE_B harus selesai dihasilkan sebelum Looker dapat mulai menghasilkan TABLE_C. Setelah TABLE_C selesai, Looker akan memberikan hasil kueri. (Karena TABLE_D tidak diperlukan untuk menjawab kueri ini, Looker tidak akan membangun ulang TABLE_D saat ini.)

Lihatdatagroup Halaman dokumentasi parameter untuk contoh skenario PDT bertingkat yang menggunakan grup data yang sama.

Logika dasar yang sama berlaku untuk PDT: Looker akan membangun tabel apa pun yang diperlukan untuk menjawab kueri, hingga ke puncak rantai dependensi. Namun dengan PDT, seringkali tabel sudah ada dan tidak perlu dibangun ulang. Dengan kueri pengguna standar pada PDT bertingkat, Looker hanya membangun kembali PDT dalam rangkaian bertingkat tersebut jika tidak ada versi PDT yang valid dalam basis data. Jika Anda ingin memaksa pembangunan ulang untuk semua PDT dalam kaskade, Anda dapat membangun ulang tabel secara manual untuk sebuah kueri melalui Explore.

Poin logis penting yang perlu dipahami adalah bahwa dalam kasus kaskade PDT, PDT yang bergantung pada dasarnya mengkueri PDT yang menjadi acuannya. Hal ini sangat penting terutama bagi PDT yang menggunakanpersist_for strategi. Biasanya, persist_for PDT dibangun ketika pengguna memintanya, tetap berada di dalam basis data hingga interval persist_for-nya habis, dan kemudian tidak dibangun ulang hingga diminta lagi oleh pengguna. Namun, jikapersist_for PDT merupakan bagian dari rangkaian terapi dengan PDT berbasis pemicu (PDT yang menggunakandatagroup_trigger, interval_trigger, atausql_trigger_value strategi persistensi), persist_for PDT pada dasarnya diakses setiap kali PDT yang bergantung padanya dibangun kembali. Jadi, dalam kasus ini, PDT persist_for akan dibangun kembali pada jadwal PDT yang bergantung padanya. Ini berarti bahwa persist_for PDT dapat dipengaruhi oleh strategi persistensi dari dependensinya.

Saat Anda mengkonfigurasi persistensi untuk struktur PDT yang sangat bertingkat (rantai PDT yang saling terkait dengan beberapa tingkat ketergantungan), pastikan periode retensi cache dan interval grup data Anda memberikan waktu yang cukup bagi seluruh kaskade untuk terbentuk. Periode penyimpanan cache yang singkat dapat menyebabkan kondisi persaingan (race condition) yang mengakibatkan kesalahan 409 Conflict selama penyegaran. Untuk informasi lebih lanjut dan praktik terbaik yang direkomendasikan, lihat bagian Penyelesaian Masalah kesalahan Konflik 409 pada PDT bersarang dalam di halaman ini.

Membangun ulang tabel persisten secara manual untuk sebuah kueri.

Pengguna dapat memilih opsi Bangun Ulang Tabel Turunan & Jalankan dari menu Jelajahi untuk mengganti pengaturan persistensi dan membangun ulang semua tabel turunan persisten (PDT) dan tabel agregat yang diperlukan untuk kueri saat ini di Jelajahi:

Opsi ini hanya terlihat oleh pengguna dengandevelop izin, dan hanya setelah kueri Jelajahi dimuat.

Opsi Bangun Ulang Tabel Turunan & Jalankan membangun ulang semua tabel persisten (semua PDT dan tabel agregat) yang diperlukan untuk menjawab kueri, terlepas dari strategi persistensinya. Ini mencakup semua tabel agregat dan PDT dalam kueri saat ini, dan juga mencakup semua tabel agregat dan PDT yang dirujuk oleh tabel agregat dan PDT dalam kueri saat ini.

Dalam kasus PDT inkremental, opsi Bangun Ulang Tabel Turunan & Jalankan memicu pembuatan inkremental baru. Dengan PDT inkremental, satu inkremen mencakup periode waktu yang ditentukan dalamincrement_key parameter, dan juga jumlah periode waktu sebelumnya yang ditentukan dalamincrement_offset parameter, jika ada. Lihat halaman dokumentasi PDT Inkremental untuk beberapa contoh skenario yang menunjukkan bagaimana PDT inkremental dibangun, tergantung pada konfigurasinya.

Dalam kasus PDT bertingkat, ini berarti membangun kembali semua tabel turunan dalam kaskade, dimulai dari atas. Perilaku ini sama seperti saat Anda melakukan kueri pada tabel dalam rangkaian tabel turunan sementara:

Perhatikan hal-hal berikut mengenai pembangunan ulang tabel turunan secara manual:

• Bagi pengguna yang memulai operasi Bangun Ulang Tabel Turunan & Jalankan, kueri akan menunggu tabel dibangun ulang sebelum memuat hasil. Permintaan dari pengguna lain akan tetap menggunakan tabel yang sudah ada. Setelah tabel persisten dibangun kembali, maka semua pengguna akan menggunakan tabel yang telah dibangun kembali tersebut. Meskipun proses ini dirancang untuk menghindari gangguan terhadap kueri pengguna lain saat tabel sedang dibangun ulang, pengguna tersebut tetap dapat terpengaruh oleh beban tambahan pada basis data Anda. Jika Anda berada dalam situasi di mana memicu pembangunan ulang selama jam kerja dapat memberikan beban yang tidak dapat diterima pada basis data Anda, Anda mungkin perlu mengkomunikasikan kepada pengguna Anda bahwa mereka tidak boleh membangun ulang PDT atau tabel agregat tertentu selama jam-jam tersebut.

• Jika pengguna berada dalam Mode Pengembangan dan Explore didasarkan pada tabel pengembangan, operasi Bangun Ulang Tabel Turunan & Jalankan akan membangun ulang tabel pengembangan, bukan tabel produksi, untuk Explore. Namun, jika Explore dalam Mode Pengembangan menggunakan versi produksi dari tabel turunan, tabel produksi akan dibangun ulang. Lihat Tabel yang disimpan dalam Mode Pengembangan untuk informasi tentang tabel pengembangan dan tabel produksi.

• Untuk instance yang dihosting oleh Looker, jika tabel turunan membutuhkan waktu lebih dari satu jam untuk dibangun kembali, tabel tidak akan berhasil dibangun kembali dan sesi browser akan habis waktu. Lihat bagian Batas waktu dan antrean kueri pada halaman dokumentasi Pengaturan admin - Kueri untuk informasi lebih lanjut tentang batas waktu yang dapat memengaruhi proses Looker.

Tabel yang dipertahankan dalam Mode Pengembangan

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

Jika Anda melakukan kueri pada tabel yang disimpan dalam Mode Pengembangan tanpa membuat perubahan apa pun pada definisinya, Looker akan melakukan kueri pada versi produksi tabel tersebut. Jika AndaMengerjakan Jika Anda melakukan perubahan pada definisi tabel yang memengaruhi data dalam tabel atau cara tabel tersebut diakses, versi pengembangan baru dari tabel akan dibuat saat Anda mengakses tabel tersebut dalam Mode Pengembangan. Dengan adanya tabel pengembangan seperti ini, Anda dapat menguji perubahan tanpa mengganggu pengguna.

Apa yang mendorong Looker untuk membuat tabel pengembangan?

Jika memungkinkan, Looker menggunakan tabel produksi yang ada untuk menjawab kueri, terlepas dari apakah Anda sedang dalam Mode Pengembangan atau tidak. Namun, ada beberapa kasus di mana Looker tidak dapat menggunakan tabel produksi untuk kueri dalam Mode Pengembangan:

• Jika tabel yang Anda simpan memiliki parameter yang mempersempit kumpulan datanya menjadi bekerja lebih cepat dalam Mode Pengembangan
• Jika Anda telah melakukan perubahan pada definisi tabel yang disimpan yang memengaruhi data dalam tabel tersebut

Looker akan membuat tabel pengembangan jika Anda berada dalam Mode Pengembangan dan Anda melakukan kueri.Tabel turunan berbasis SQL yang didefinisikan menggunakan sebuahbersyaratWHERE klausa denganif prod Danif dev pernyataan .

Untuk tabel yang disimpan secara permanen dan tidak memiliki parameter untuk mempersempit kumpulan data dalam Mode Pengembangan, Looker menggunakan versi produksi tabel untuk menjawab kueri dalam Mode Pengembangan, kecuali jika Anda mengubah definisi tabel dan lalu melakukan kueri tabel dalam Mode Pengembangan. Hal ini berlaku untuk setiap perubahan pada tabel yang memengaruhi data dalam tabel atau cara tabel tersebut diakses.

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

• Mengubah kueri yang menjadi dasar tabel persisten, seperti memodifikasiexplore_source, sql, query, sql_create, ataucreate_process parameter dalam tabel persisten itu sendiri, atau dalam tabel yang dibutuhkan (dalam hal initabel turunan bertingkat )
• Mengubah strategi persistensi tabel, seperti memodifikasi tabel.datagroup_trigger, sql_trigger_value, interval_trigger, ataupersist_for parameter
• Mengubah nama tabel turunanview
• Mengubahincrement_key atauincrement_offset dari sebuahPDT bertahap
• Mengubahconnection yang digunakan oleh model terkait

Untuk perubahan yang tidak memodifikasi data tabel atau memengaruhi cara Looker melakukan query pada tabel, Looker tidak akan membuat tabel pengembangan. Itupublish_as_db_view Parameter ini adalah contoh yang baik: Dalam Mode Pengembangan, jika Anda hanya mengubahpublish_as_db_view Dengan pengaturan untuk tabel turunan, Looker tidak perlu membangun ulang tabel turunan sehingga tidak akan membuat tabel pengembangan.

Berapa lama Looker bertahan dalam tabel pengembangan?

Terlepas dari strategi persistensi tabel yang sebenarnya, Looker memperlakukan tabel yang disimpan dalam pengembangan seolah-olah tabel tersebut memiliki strategi persistensi sebesar persist_for: "24 hours". Looker melakukan ini untuk memastikan bahwa tabel pengembangan tidak disimpan lebih dari satu hari, karena seorang pengembang Looker mungkin melakukan query pada banyak iterasi tabel selama pengembangan, dan setiap kali tabel pengembangan baru dibuat. Untuk mencegah tabel pengembangan memenuhi basis data, Looker menerapkan strategi persist_for: "24 hours" untuk memastikan bahwa tabel-tabel tersebut sering dibersihkan dari basis data.

Selain itu, Looker membangun tabel turunan persisten (PDT) dan tabel agregat dalam Mode Pengembangan dengan cara yang sama seperti membangun tabel persisten dalam Mode Produksi.

Jika tabel pengembangan disimpan secara permanen di basis data Anda saat Anda menerapkan perubahan ke PDT atau tabel agregat, Looker sering kali dapat menggunakan tabel pengembangan sebagai tabel produksi sehingga pengguna Anda tidak perlu menunggu tabel tersebut dibuat saat mereka melakukan kueri pada tabel tersebut.

Perlu diingat bahwa saat Anda menerapkan perubahan, tabel mungkin masih perlu dibangun ulang agar dapat diakses di lingkungan produksi, tergantung pada situasinya:

• Jika sudah lebih dari 24 jam sejak Anda melakukan kueri pada tabel dalam Mode Pengembangan, versi pengembangan tabel tersebut ditandai sebagai kedaluwarsa dan tidak akan digunakan untuk kueri. Anda dapat memeriksa PDT yang belum dibuat dengan menggunakan Looker IDE atau dengan menggunakan tab Pengembangan pada halaman Tabel Turunan Persisten. Jika Anda memiliki PDT yang belum dibuat, Anda dapat menanyakan tabel tersebut dalam Mode Pengembangan tepat sebelum Anda melakukan perubahan sehingga tabel pengembangan tersedia untuk digunakan dalam produksi.
• Jika tabel yang dipertahankan memilikidev_filters parameter (untuktabel turunan asli ) ataubersyaratWHERE klausa yang menggunakanif prod Danif dev pernyataan (untukTabel turunan berbasis SQL ), tabel pengembangan tidak dapat digunakan sebagai versi produksi, karena versi pengembangan memiliki kumpulan data yang disingkat. Jika demikian, setelah Anda selesai mengembangkan tabel dan sebelum Anda menerapkan perubahan, Anda dapat mengomentari parameter dev_filters atau klausa kondisional WHERE dan kemudian melakukan kueri tabel dalam Mode Pengembangan. Looker kemudian akan membuat versi lengkap tabel yang dapat digunakan untuk produksi saat Anda menerapkan perubahan Anda.

Sebaliknya, jika Anda menerapkan perubahan Anda ketika tidak ada tabel pengembangan yang valid yang dapat digunakan sebagai tabel produksi, Looker akan membangun kembali tabel tersebut pada saat tabel tersebut diakses kembali dalam Mode Produksi (untuk tabel yang disimpan yang menggunakanpersist_for strategi), atau lain kaliregenerator menjalankan (untuk tabel yang dipertahankan yang menggunakandatagroup_trigger, interval_trigger, atausql_trigger_value ).

Memeriksa PDT yang belum dibuat dalam Mode Pengembangan

Jika tabel pengembangan disimpan secara permanen di basis data Anda saat Anda menerapkan perubahan ke tabel turunan permanen (PDT) atau tabel agregat, Looker sering kali dapat menggunakan tabel pengembangan sebagai tabel produksi sehingga pengguna Anda tidak perlu menunggu tabel tersebut dibuat saat mereka melakukan kueri pada tabel tersebut. Lihat bagian Berapa lama Looker menyimpan tabel pengembangan dan Apa yang mendorong Looker untuk membuat tabel pengembangan pada halaman ini untuk detail selengkapnya.

Oleh karena itu, akan lebih optimal jika semua PDT Anda dibuat saat Anda melakukan deployment ke lingkungan produksi sehingga tabel dapat langsung digunakan sebagai versi produksi.

Anda dapat memeriksa proyek Anda untuk PDT yang belum dibuat di panel Kesehatan Proyek. Klik ikon Kesehatan Proyek di Looker IDE untuk membuka panel Kesehatan Proyek. Kemudian klik tombol Validasi Status PDT.

Jika terdapat PDT yang belum dibangun, panel Kesehatan Proyek akan menampilkannya:

kalau sudahsee_pdts izin, Anda dapat mengklikBuka Manajemen PDT tombol. Looker akan membuka tab Pengembangan pada halaman Tabel Turunan Persisten dan memfilter hasilnya sesuai dengan proyek LookML spesifik Anda. Dari situ, Anda dapat melihat PDT pengembangan mana yang sudah dibangun dan belum dibangun, serta mengakses informasi pemecahan masalah lainnya. Lihat halaman dokumentasi Pengaturan admin - Tabel Turunan Persisten untuk informasi selengkapnya.

Setelah Anda mengidentifikasi PDT yang belum dibuat dalam proyek Anda, Anda dapat membuat versi pengembangannya dengan membuka Explore yang menanyakan tabel tersebut, lalu menggunakan opsi Rebuild Derived Tables & Run dari menu Explore. Lihat bagian Membangun ulang tabel persisten secara manual untuk sebuah kueri di halaman ini.

Berbagi meja dan membersihkan

Dalam setiap instance Looker, Looker akan berbagi tabel yang disimpan secara permanen di antara pengguna jika tabel tersebut memiliki definisi yang sama dan pengaturan metode penyimpanan yang sama. Selain itu, jika definisi suatu tabel tidak lagi ada, Looker akan menandai tabel tersebut sebagai kedaluwarsa.

Hal ini memiliki beberapa manfaat:

• Jika Anda belum melakukan perubahan apa pun pada tabel dalam Mode Pengembangan, kueri Anda akan menggunakan tabel produksi yang sudah ada. Hal ini berlaku kecuali jika tabel Anda adalah tabel turunan berbasis SQL yang didefinisikan menggunakan klausa kondisional WHERE dengan pernyataan if prod dan if dev. Jika tabel didefinisikan dengan klausa kondisional WHERE, Looker akan membuat tabel pengembangan jika Anda melakukan kueri tabel dalam Mode Pengembangan. (Untuktabel turunan asli dengandev_filters (Jika parameter ini digunakan, Looker memiliki logika untuk menggunakan tabel produksi untuk menjawab kueri dalam Mode Pengembangan, kecuali jika Anda mengubah definisi tabel dan kemudian melakukan kueri pada tabel tersebut dalam Mode Pengembangan.)
• Jika dua pengembang secara kebetulan melakukan perubahan yang sama pada sebuah tabel saat berada dalam Mode Pengembangan, mereka akan berbagi tabel pengembangan yang sama.
• Setelah Anda mengirimkan 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 Anda, definisi tabel tersebut tidak ada lagi, sehingga tabel pengembangan yang tidak dibutuhkan akan ditandai sebagai kedaluwarsa dan akan dihapus.

Bekerja lebih cepat dalam Mode Pengembangan

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

Untuktabel turunan asli Anda dapat menggunakandev_filters subparameter dariexplore_source untuk menentukan filter yang hanya diterapkan pada versi pengembangan dari 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 menyaring data ke 90 hari terakhir dan parameter filters yang menyaring data ke 2 tahun terakhir dan ke Bandara Yucca Valley.

Parameter dev_filters bekerja bersamaan dengan parameter filters sehingga semua filter diterapkan pada versi pengembangan tabel. Jika dev_filters dan filters sama-sama menentukan filter untuk kolom yang sama, dev_filters akan diutamakan untuk versi pengembangan tabel. Dalam contoh ini, versi pengembangan tabel akan memfilter data ke 90 hari terakhir untuk Bandara Yucca Valley.

UntukTabel turunan berbasis SQL Looker mendukung kondisi bersyaratWHERE klausul dengan berbagai pilihan untuk produksi (if prod ) dan pembangunan (if dev ) versi 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. Dengan menggunakan fitur ini secara strategis untuk membatasi kumpulan hasil Anda, dan meningkatkan kecepatan kueri, perubahan dalam Mode Pengembangan dapat jauh lebih mudah divalidasi.

Bagaimana Looker membangun PDT

Setelah tabel turunan persisten (PDT) didefinisikan dan dijalankan untuk pertama kalinya atau dipicu oleh regenerator untuk membangun kembali 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 membangun kembali PDT yang disebut customer_orders_facts: CREATE TABLE tmp.customer_orders_facts AS SELECT ... FROM ... WHERE ...
2. Keluarkan pernyataan untuk membuat indeks saat tabel dibuat.
3. Ubah nama tabel dari LC$.. ("Looker Create") menjadi LR$.. ("Looker Read"), untuk menunjukkan bahwa tabel siap digunakan.
4. Hapus semua versi tabel yang lebih lama yang seharusnya tidak lagi digunakan.

Ada beberapa implikasi penting:

• SQL yang membentuk tabel turunan harus valid di dalam pernyataan CTAS.
• Alias ​​kolom pada 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 field yang didefinisikan dalam LookML.

Regenerator Looker

Regenerator Looker memeriksa status dan memulai pembangunan ulang untuk tabel yang disimpan oleh pemicu. Tabel yang dipertahankan pemicunya adalah tabel turunan persisten (PDT) atau sebuahtabel agregat yang menggunakan pemicu sebagai strategi persistensi:

• Untuk tabel yang menggunakansql_trigger_value, pemicunya adalah kueri yang ditentukan dalam tabel tersebutsql_trigger_value parameter. Regenerator Looker memicu pembangunan ulang tabel ketika hasil pemeriksaan kueri pemicu terbaru berbeda dari hasil pemeriksaan kueri pemicu sebelumnya. Misalnya, jika tabel turunan Anda disimpan dengan kueri SQL SELECT CURDATE(), regenerator Looker akan membangun kembali tabel tersebut pada saat regenerator memeriksa pemicu setelah tanggal berubah.
• Untuk tabel yang menggunakaninterval_trigger Pemicunya adalah durasi waktu yang ditentukan dalam tabel.interval_trigger parameter. Regenerator Looker memicu pembangunan ulang tabel ketika waktu yang ditentukan telah berlalu.
• Untuk tabel yang menggunakandatagroup_trigger Pemicunya dapat berupa kueri yang ditentukan dalam grup data terkait.sql_trigger parameter, atau pemicunya dapat berupa durasi waktu yang ditentukan dalam grup data.interval_trigger parameter.

Regenerator Looker juga memulai pembangunan ulang untuk tabel yang disimpan yang menggunakanpersist_for parameter, tetapi hanya ketikapersist_for tabel adalah sebuah ketergantunganriam dari tabel yang dipertahankan oleh pemicu. Dalam hal ini, regenerator Looker akan memulai pembangunan ulang untuk tabel persist_for, karena tabel tersebut diperlukan untuk membangun ulang tabel lain dalam kaskade. Jika tidak, regenerator tidak memantau tabel yang disimpan yang menggunakan strategi persist_for.

Selain itu, regenerator Looker menciptakanmodel analitik di dalam basis data Anda, jika Anda mendefinisikan model analitik dengan menggunakanderived_analytic_model parameter. Regenerator Looker memproses model analitik turunan serupa dengan PDT yang merupakan tampilan materialisasi. Baik materialized view maupun derived analytic model hanya dibuat sekali dan tidak mendukung trigger, seperti datagroup triggers, SQL triggers, atau interval triggers. Regenerator Looker hanya akan membuat ulang model analitik di database Anda jika definisi LookML-nya berubah atau jika ada tampilan LookML yang bergantung padanya berubah.

Siklus regenerator Looker dimulai pada interval reguler yang dikonfigurasi oleh admin Looker Anda di pengaturan Jadwal Pemeliharaan pada koneksi basis data Anda (standarnya adalah interval lima menit). Namun, regenerator Looker tidak memulai siklus baru sampai menyelesaikan semua pemeriksaan dan pembangunan ulang PDT dari siklus terakhir. Ini berarti jika Anda memiliki proses build PDT yang berjalan lama, siklus regenerator Looker mungkin tidak berjalan sesering yang ditentukan dalam pengaturan Jadwal Pemeliharaan. Faktor lain dapat memengaruhi waktu yang dibutuhkan untuk membangun kembali tabel Anda, seperti yang dijelaskan dalam bagian Pertimbangan penting untuk mengimplementasikan tabel yang disimpan secara permanen pada halaman ini.

Dalam kasus di mana PDT gagal dibangun, regenerator dapat mencoba membangun kembali tabel tersebut pada siklus regenerator berikutnya:

• Jika pengaturan Coba Lagi Pembuatan PDT yang Gagal diaktifkan pada koneksi basis data Anda, regenerator Looker akan mencoba membangun kembali tabel selama siklus regenerator berikutnya, meskipun kondisi pemicu tabel tidak terpenuhi.
• Jika pengaturan Coba Lagi Pembuatan PDT yang Gagal dinonaktifkan, regenerator Looker tidak akan mencoba membangun kembali tabel sampai 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 tabel yang baru, yang dapat terjadi jika tabel baru memiliki definisi yang berbeda, tabel baru menggunakan koneksi basis data yang berbeda, atau tabel baru dibuat dengan versi Looker yang berbeda.) Jika tabel yang ada masih valid, Looker akan mengembalikan data dari tabel yang ada hingga tabel baru dibuat. Sebaliknya, jika tabel yang ada tidak valid, Looker akan memberikan hasil kueri setelah tabel baru dibangun kembali.

Pertimbangan penting untuk mengimplementasikan tabel yang disimpan secara permanen.

Mengingat kegunaan tabel yang dipertahankan (PDT dantabel agregat ), dimungkinkan untuk mengumpulkan banyak di antaranya pada instance Looker Anda. Dimungkinkan untuk membuat skenario di mana Looker regenerator perlu membangun banyak tabel secara bersamaan. Khususnya dengan tabel bertingkat, atau tabel yang berjalan lama, Anda dapat membuat skenario di mana tabel mengalami penundaan yang lama sebelum dibangun kembali, atau di mana pengguna mengalami penundaan dalam mendapatkan hasil kueri dari sebuah tabel sementara basis data bekerja keras untuk menghasilkan tabel tersebut.

Regenerator Looker memeriksa pemicu PDT untuk melihat apakah tabel yang dipertahankan pemicu harus dibangun ulang. Siklus regenerator diatur pada interval reguler yang dikonfigurasi oleh admin Looker Anda di pengaturan Jadwal Pemeliharaan pada koneksi basis data Anda (standarnya adalah interval lima menit).

Beberapa faktor dapat memengaruhi waktu yang dibutuhkan untuk membangun kembali tabel Anda:

• Admin Looker Anda mungkin telah mengubah interval pemeriksaan pemicu regenerator dengan menggunakan pengaturan Jadwal Pemeliharaan pada koneksi basis data Anda.
• Regenerator Looker tidak memulai siklus baru sampai menyelesaikan semua pemeriksaan dan pembangunan ulang PDT dari siklus terakhir. Jadi jika Anda memiliki build PDT yang berjalan lama, siklus regenerator Looker mungkin tidak sesering pengaturan Jadwal Pemeliharaan.
• Secara default, regenerator dapat memulai pembangunan kembali satu PDT atau tabel agregat pada satu waktu melalui sebuah koneksi. Seorang admin Looker dapat menyesuaikan jumlah pembangunan ulang simultan yang diizinkan oleh regenerator dengan menggunakan bidang Jumlah maksimum koneksi pembangun PDT di pengaturan koneksi.
• Semua PDT dan tabel agregat dipicu oleh hal yang sama.datagroup akan dibangun kembali selama proses regenerasi yang sama. Ini bisa menjadi beban berat jika Anda memiliki banyak tabel yang menggunakan datagroup, baik secara langsung maupun sebagai akibat dariketergantungan berjenjang.

Selain pertimbangan sebelumnya, ada juga beberapa situasi di mana Anda harus menghindari penambahan persistensi ke tabel turunan:

• Kapan tabel turunan akan diperluas — Setiap perluasan PDT akan membuat salinan baru tabel di basis data Anda.
• Saat tabel turunan digunakanfilter templat atau parameter cairan — Persistensi tidak didukung untuk tabel turunan yang menggunakan filter berbasis templat atau parameter Liquid.
• Kapantabel turunan asli dibangun dari Explore yang menggunakanatribut pengguna denganaccess_filters, atau dengansql_always_where — Salinan tabel akan dibuat di basis data Anda untuk setiap nilai atribut pengguna yang mungkin ditentukan.
• Ketika data yang mendasarinya sering berubah dan dialek basis data Anda tidak mendukung PDT inkremental.
• Ketika biaya dan waktu yang dibutuhkan untuk membuat PDT terlalu tinggi.

Tergantung pada jumlah dan kompleksitas tabel yang disimpan pada koneksi Looker Anda, antrean mungkin berisi banyak tabel yang perlu diperiksa dan dibangun kembali pada setiap siklus, jadi penting untuk mengingat faktor-faktor ini saat mengimplementasikan tabel turunan pada instance Looker Anda.

Mengelola PDT dalam skala besar menggunakan API

Memantau dan mengelola tabel turunan persisten (PDT) yang diperbarui dengan jadwal yang berbeda-beda menjadi semakin kompleks seiring bertambahnya jumlah PDT yang Anda buat pada instance Anda. Pertimbangkan untuk menggunakan integrasi Looker Apache Airflow untuk mengelola jadwal PDT Anda bersamaan dengan proses ETL dan ELT lainnya.

Memantau dan memecahkan masalah PDT

Jika Anda menggunakan tabel turunan persisten (PDT), dan khususnya PDT cascading, akan sangat membantu untuk melihat status PDT Anda. Anda dapat menggunakan halaman admin Looker Persistent Derived Tables untuk melihat status PDT Anda. Anda juga dapat memeriksa Pohon pemecahan masalah PDT untuk debugging langkah demi langkah.

Saat mencoba memecahkan masalah PDT:

• Perhatikan secara khusus perbedaan antaratabel pengembangan dan tabel produksi saat menyelidikiCatatan Peristiwa PDT.
• Pastikan setelan Temp Database di koneksi Looker Anda cocok dengan skema atau database sementara yang sebenarnya. Jika setelan Database Sementara pada koneksi tidak cocok dengan skema sementara di database Anda, perbarui setelan Database Sementara agar Looker dapat menyimpan tabel turunan persisten di database Anda.
• Tentukan apakah ada masalah dengan semua PDT atau hanya satu PDT. Jika ada masalah dengan salah satunya, maka masalah tersebut kemungkinan disebabkan oleh kesalahan LookML atau SQL.
• Tentukan apakah masalah pada PDT sesuai dengan waktu saat PDT 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 melakukan ini dengan menjalankannya di SQL Runner. (Menerapkan LIMIT melindungi dari kueri yang tidak terkendali.) Untuk informasi lebih lanjut 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 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 membuat pernyataan WITH bertingkat yang dapat menyebabkan PDT gagal tanpa peringatan. Sebaliknya, gunakan SQL untuk CTE Anda untuk membuat DT sekunder dan merujuk DT tersebut dari DT pertama Anda menggunakan${derived_table_or_view_name.SQL_TABLE_NAME} sintaksis.
• Pastikan semua tabel yang menjadi dasar PDT masalah — baik tabel normal maupun PDT itu sendiri — ada dan dapat dikueri.
• Pastikan bahwa tabel apa pun yang menjadi ketergantungan PDT masalah tersebut tidak memiliki kunci bersama atau eksklusif. Agar Looker berhasil membuat PDT, Looker harus mendapatkan kunci eksklusif pada tabel yang perlu diperbarui. Hal ini akan bertentangan dengan kunci eksklusif atau bersama lainnya yang ada di tabel. Looker tidak akan dapat memperbarui PDT sampai semua kunci lainnya telah dilepas. Hal yang sama berlaku untuk setiap kunci eksklusif pada tabel yang digunakan Looker untuk membangun PDT; jika ada kunci eksklusif pada suatu tabel, Looker tidak akan dapat memperoleh kunci bersama untuk menjalankan kueri sampai kunci eksklusif tersebut dicabut.
• Gunakan tombol Tampilkan Proses di SQL Runner. Jika terdapat banyak proses yang aktif, hal ini dapat memperlambat waktu eksekusi kueri.
• Pantau komentar dalam kueri. Lihat bagian Komentar kueri untuk PDT di halaman ini.

• Ketika fungsi tanggal khusus basis data (seperti current_date()) digunakan dalam kueri SQL dari tabel turunan, ada risiko ketidakcocokan zona waktu antara sesi Looker pengguna dan basis data yang mendasarinya. Karena fungsi basis data dieksekusi langsung di dalam basis data dan tidak melalui konversi zona waktu kueri Looker, perbedaan ini dapat menyebabkan hasil filter tanggal yang tidak terduga (misalnya, filter tanggal untuk "Kemarin" dapat menghasilkan tanggal dua hari yang lalu mendekati tengah malam).

  Untuk mengatasi masalah ini, pastikan keselarasan zona waktu yang benar antara basis data Anda dan instance Looker, yang mungkin memerlukan koordinasi dengan tim Rekayasa Data Anda.

• Jika Anda menemukan kesalahan 409 Conflict selama pembaruan PDT dalam struktur PDT yang sangat bersarang (rantai PDT bertingkat dengan beberapa tingkat ketergantungan), lihat bagian Penyelesaian Masalah 409 Kesalahan Konflik dalam PDT yang sangat bersarang pada halaman ini.

Komentar kueri untuk PDT

Administrator basis data dapat membedakan kueri normal dari kueri yang menghasilkan tabel turunan persisten (PDT). Looker menambahkan komentar ke pernyataan CREATE TABLE ... AS SELECT ... yang mencakup model dan tampilan LookML PDT, ditambah pengidentifikasi unik (slug) untuk instance Looker. Jika PDT dibuat atas nama pengguna dalam Mode Pengembangan, komentar akan menunjukkan ID pengguna. Komentar generasi 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 Explore jika Looker harus membuat PDT untuk kueri Explore tersebut. Komentar akan muncul di bagian atas pernyataan SQL.

Terakhir, komentar pembuatan PDT muncul di kolom Pesan pada tab Info dari pop-up Detail Kueri untuk setiap kueri pada halaman admin Kueri.

Membangun kembali PDT setelah kegagalan

Ketika tabel turunan persisten (PDT) mengalami kegagalan, berikut yang terjadi saat PDT tersebut diakses:

• Looker akan menggunakan hasil yang ada di cache jika kueri yang sama telah dijalankan sebelumnya. (Lihat halaman dokumentasi Caching queries untuk penjelasan tentang cara kerjanya.)
• Jika hasilnya tidak ada di dalam cache, Looker akan mengambil hasil dari PDT di dalam basis data, jika versi PDT yang valid tersedia.
• Jika tidak ada PDT yang valid dalam basis data, Looker akan mencoba membangun kembali PDT tersebut.
• Jika PDT tidak dapat dibangun kembali, Looker akan mengembalikan kesalahan untuk sebuah kueri. Looker regenerator akan mencoba membangun kembali PDT pada saat PDT dikueri berikutnya atau pada saat strategi persistensi PDT memicu pembangunan kembali.

Dengan PDT cascading, logika yang sama berlaku, kecuali bahwa dengan PDT cascading:

• Kegagalan dalam membangun satu tabel akan mencegah pembangunan PDT di sepanjang rantai ketergantungan.
• PDT dependen pada dasarnya melakukan kueri pada PDT yang diandalkannya, sehingga strategi persistensi suatu tabel dapat memicu pembangunan ulang PDT yang berada di atas rantai tersebut.

Mari kita tinjau kembali contoh sebelumnya tentang tabel bertingkat , di mana 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) berlaku untuk TABLE_B:

1. Jika TABLE_B ditanyakan, Looker pertama-tama mencoba menggunakan cache untuk mengembalikan hasil.
2. Jika upaya ini gagal, Looker selanjutnya akan mencoba menggunakan versi tabel sebelumnya, jika memungkinkan.
3. Jika upaya ini juga gagal, Looker kemudian mencoba membangun kembali tabel tersebut.
4. Terakhir, jika TABLE_B tidak dapat dibangun kembali, Looker akan mengembalikan kesalahan.

Looker akan mencoba lagi untuk membangun kembali TABLE_B ketika tabel tersebut dikueri berikutnya atau ketika strategi persistensi tabel memicu pembangunan kembali berikutnya.

Hal yang sama juga berlaku untuk tanggungan dari TABLE_B. Jadi jika TABLE_B tidak dapat dibangun, dan ada permintaan pada TABLE_C, maka urutan berikut akan terjadi:

1. Looker akan mencoba menggunakan cache untuk kueri pada TABLE_C.
2. Jika hasilnya tidak ada di cache, Looker akan mencoba mengambil hasil dari TABLE_C di dalam basis data.
3. Jika tidak ada versi TABLE_C yang valid, Looker akan mencoba membangun kembali TABLE_C, yang akan membuat kueri pada TABLE_B.
4. Looker kemudian akan mencoba membangun kembali TABLE_B (yang akan gagal jika TABLE_B belum diperbaiki).
5. Jika TABLE_B tidak dapat dibangun kembali, maka TABLE_C tidak dapat dibangun kembali, sehingga Looker akan mengembalikan kesalahan untuk kueri pada TABLE_C.
6. Looker kemudian akan mencoba membangun kembali TABLE_C sesuai dengan strategi persistensi biasanya, atau pada saat PDT dikueri berikutnya (yang mencakup saat TABLE_D mencoba membangun kembali, karena TABLE_D bergantung pada TABLE_C).

Setelah Anda menyelesaikan masalah dengan TABLE_B, maka TABLE_B dan setiap tabel yang bergantung akan mencoba membangun kembali sesuai dengan strategi persistensi mereka, atau pada saat kueri berikutnya (yang mencakup saat PDT yang bergantung mencoba membangun kembali). Atau, jika versi pengembangan PDT dalam kaskade dibangun dalam Mode Pengembangan, versi pengembangan tersebut dapat digunakan sebagai PDT produksi yang baru. (Lihat bagian Tabel yang Disimpan dalam Mode Pengembangan pada halaman ini untuk mengetahui cara kerjanya.) Atau Anda dapat menggunakan Explore untuk menjalankan kueri pada TABLE_D dan kemudian membangun ulang PDT secara manual untuk kueri, yang akan memaksa pembangunan ulang semua PDT yang naik ke kaskade dependensi.

Penyelesaian masalah kesalahan konflik 409 pada PDT yang bersarang dalam

Saat Anda bekerja dengan struktur PDT yang sangat bertingkat (rantai PDT yang saling terkait dengan beberapa tingkat ketergantungan), mengkonfigurasi periode retensi cache yang singkat (misalnya, 15 menit) dapat menyebabkan kondisi persaingan yang mengakibatkan kesalahan 409 Conflict selama penyegaran.

Kondisi race ini terjadi karena cache untuk PDT bersarang tingkat bawah mungkin kedaluwarsa sementara PDT tingkat atas masih dalam proses pembuatan. Ketika situasi ini terjadi, Looker memicu permintaan build duplikat baru untuk PDT tingkat bawah sementara pekerjaan awal masih diproses di gudang data, yang mengakibatkan konflik.

Untuk mengatasi atau mencegah kesalahan ini, gunakan praktik terbaik berikut:

• Tingkatkan periode penyimpanan cache: Tetapkan periode retensi cache (max_cache_age ataupersist_for ) agar PDT setidaknya dua hingga tiga kali lebih lama dari waktu maksimum yang dibutuhkan untuk menyelesaikan pembangunan penuh semua PDT bersarang.
• Tingkatkan interval penyegaran grup data: Berikan waktu yang cukup bagi proses build PDT yang sangat bertingkat untuk selesai, yang mengurangi risiko tumpang tindih proses build.

Meningkatkan kinerja PDT

Saat Anda membuat tabel turunan persisten (PDT), performa bisa menjadi perhatian. Terutama jika tabelnya sangat besar, melakukan kueri pada tabel tersebut mungkin akan lambat, sama seperti halnya pada tabel besar lainnya di basis data Anda.

Anda dapat meningkatkan kinerja dengan memfilter data atau dengan mengontrol bagaimana data dalam PDT diurutkan dan diindeks.

Menambahkan filter untuk membatasi kumpulan data.

Pada kumpulan data yang sangat besar, banyaknya baris akan memperlambat kueri terhadap tabel turunan persisten (PDT). Jika Anda biasanya hanya menanyakan data terbaru, pertimbangkan untuk menambahkan filter ke klausa WHERE pada PDT Anda yang membatasi tabel hanya untuk data 90 hari atau kurang. Dengan cara ini, hanya data yang relevan yang akan ditambahkan ke tabel setiap kali tabel tersebut dibangun ulang sehingga menjalankan kueri 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) berukuran besar, pengindeksan tabel (untuk dialek seperti MySQL atau Postgres) atau menambahkan kunci pengurutan dan distribusi (untuk Redshift) dapat membantu meningkatkan kinerja.

Biasanya yang terbaik adalah menambahkanindexes parameter pada kolom ID atau tanggal.

Untuk Redshift, biasanya yang terbaik adalah menambahkansortkeys parameter pada kolom ID atau tanggal dandistribution parameter pada kolom yang digunakan untuk penggabungan.

Pengaturan yang direkomendasikan untuk meningkatkan kinerja.

Pengaturan berikut mengontrol bagaimana data dalam tabel turunan persisten (PDT) diurutkan dan diindeks. Pengaturan ini bersifat opsional, tetapi sangat disarankan:

• Untuk Redshift dan Aster, gunakandistribution parameter untuk menentukan nama kolom yang nilainya digunakan untuk menyebarkan data di sekitar klaster. Ketika dua tabel digabungkan berdasarkan kolom yang ditentukan dalam parameter distribution, basis data dapat menemukan data gabungan pada node yang sama, sehingga I/O antar node diminimalkan.
• Untuk Redshift, aturdistribution_style parameter untukall untuk menginstruksikan basis data agar menyimpan salinan lengkap data pada setiap node. Hal ini sering digunakan untuk meminimalkan I/O antar-node ketika tabel yang relatif kecil digabungkan. Atur nilai ini ke even untuk menginstruksikan basis data agar menyebarkan data secara merata ke seluruh klaster tanpa menggunakan kolom distribusi. Nilai ini hanya dapat ditentukan ketika distribution tidak ditentukan.
• Untuk Redshift, gunakansortkeys parameter. Nilai-nilai tersebut menentukan kolom mana dari PDT yang digunakan untuk mengurutkan data pada disk agar pencarian lebih mudah. Di Redshift, Anda dapat menggunakan sortkeys atau indexes, tetapi tidak keduanya.
• Pada sebagian besar basis data, gunakanindexes parameter. Nilai-nilai tersebut menentukan kolom mana dari PDT yang diindeks. (Pada Redshift, indeks digunakan untuk menghasilkan kunci pengurutan yang saling terkait.)