Tutorial kesadaran agregat

Untuk mengetahui detail tambahan, lihat halaman dokumentasi Kesadaran gabungan.

Pengantar

Halaman ini adalah panduan untuk menerapkan kesadaran agregat dalam skenario praktis, termasuk mengidentifikasi peluang penerapan, nilai yang didorong oleh kesadaran agregat, dan alur kerja sederhana untuk menerapkannya dalam model nyata. Halaman ini bukan penjelasan mendalam tentang semua fitur awareness gabungan atau kasus ekstrem, dan juga bukan katalog lengkap dari semua fiturnya.

Apa yang dimaksud dengan kesadaran agregat?

Di Looker, Anda sebagian besar membuat kueri terhadap tabel atau tampilan mentah di database Anda. Terkadang, tabel ini adalah tabel turunan persisten (PDT) Looker.

Anda mungkin sering menemukan set data atau tabel yang sangat besar yang, agar berperforma baik, memerlukan tabel agregasi atau ringkasan.

Biasanya, Anda dapat membuat tabel agregasi seperti tabel orders_daily yang berisi dimensi terbatas. Hal ini perlu ditangani dan dimodelkan secara terpisah di Eksplorasi, dan tidak sesuai dengan model. Batasan ini menyebabkan pengalaman pengguna yang buruk saat pengguna harus memilih antara beberapa Eksplorasi untuk data yang sama.

Sekarang, dengan kemampuan Looker untuk mengenali agregasi, Anda dapat membuat tabel agregasi terlebih dahulu dengan berbagai tingkat perincian, dimensi, dan agregasi; serta Anda dapat memberi tahu Looker cara menggunakannya dalam Eksplorasi yang ada. Kueri kemudian akan memanfaatkan tabel gabungan ini jika Looker menganggapnya sesuai, tanpa input pengguna. Hal ini akan mengurangi ukuran kueri, mengurangi waktu tunggu, dan meningkatkan pengalaman pengguna.

CATATAN: Tabel gabungan Looker adalah jenis tabel turunan persisten (PDT). Artinya, tabel gabungan memiliki persyaratan database dan koneksi yang sama dengan PDT.

Untuk melihat apakah dialek database dan koneksi Looker Anda dapat mendukung PDT, lihat persyaratan yang tercantum di halaman dokumentasi Tabel turunan di Looker.

Untuk mengetahui apakah dialek database Anda mendukung kesadaran agregat, lihat halaman dokumentasi Kesadaran agregat.

Manfaat kesadaran agregat

Ada sejumlah proposisi nilai signifikan yang ditawarkan agregasi kesadaran untuk mendorong nilai tambahan dari model Looker yang ada:

• Peningkatan performa: Menerapkan kesadaran gabungan akan membuat kueri pengguna lebih cepat. Looker akan menggunakan tabel yang lebih kecil jika berisi data yang diperlukan untuk menyelesaikan kueri pengguna.
• Penghematan biaya: Dialek tertentu mengenakan biaya berdasarkan ukuran kueri pada model konsumsi. Dengan membuat Looker membuat kueri tabel yang lebih kecil, Anda akan mengurangi biaya per kueri pengguna.
• Peningkatan pengalaman pengguna: Selain pengalaman yang lebih baik yang mengambil jawaban lebih cepat, konsolidasi menghilangkan pembuatan Eksplorasi yang berlebihan.
• Jejak LookML yang lebih kecil: Mengganti strategi keakraban agregat berbasis Liquid yang ada dengan implementasi native yang fleksibel akan meningkatkan ketahanan dan mengurangi error.
• Kemampuan untuk memanfaatkan LookML yang ada: Tabel gabungan menggunakan objek query, yang menggunakan kembali logika yang dimodelkan yang ada, bukan menduplikasi logika dengan SQL kustom eksplisit.

Contoh dasar

Berikut adalah penerapan yang sangat sederhana dalam model Looker untuk menunjukkan betapa ringannya kesadaran agregat. Mengingat tabel flights hipotetis dalam database dengan baris untuk setiap penerbangan yang dicatat melalui FAA, kita dapat memodelkan tabel ini di Looker dengan tampilan dan Eksplorasi sendiri. Berikut adalah LookML untuk tabel gabungan yang dapat kita tentukan untuk Eksplorasi:

  explore: flights {
    aggregate_table: flights_by_week_and_carrier {
      query: {
        dimensions: [carrier, depart_week]
        measures: [cancelled_count, count]
      }

      materialization: {
        sql_trigger_value: SELECT CURRENT-DATE;;
      }
    }
  }

Dengan tabel gabungan ini, pengguna dapat mengkueri flights Jelajah dan Looker akan otomatis memanfaatkan tabel gabungan yang ditentukan dalam LookML dan menggunakan tabel gabungan untuk menjawab kueri. Pengguna tidak perlu memberi tahu Looker tentang kondisi khusus: Jika tabel cocok untuk kolom yang dipilih pengguna, Looker akan menggunakan tabel tersebut.

Pengguna dengan izin see_sql dapat menggunakan komentar di tab SQL pada Eksplorasi untuk melihat tabel gabungan mana yang akan digunakan untuk kueri. Berikut adalah contoh tab SQL Looker untuk kueri yang menggunakan tabel agregat flights:flights_by_week_and_carrier in teach_scratch:

Lihat halaman dokumentasi Kesadaran agregat untuk mengetahui detail tentang cara menentukan apakah tabel agregat digunakan untuk kueri.

Mengidentifikasi peluang

Untuk memaksimalkan manfaat awareness gabungan, Anda harus mengidentifikasi tempat awareness gabungan dapat berperan dalam pengoptimalan atau dalam mendorong nilai awareness gabungan.

Mengidentifikasi dasbor dengan runtime tinggi

Salah satu peluang besar untuk meningkatkan kesadaran agregat adalah membuat tabel agregat untuk dasbor yang sering digunakan dengan runtime yang sangat tinggi. Anda mungkin mendengar dari pengguna tentang dasbor yang lambat, tetapi jika memiliki see_system_activity, Anda juga dapat menggunakan Jelajah Histori Aktivitas Sistem Looker untuk menemukan dasbor dengan waktu proses yang lebih lambat dari rata-rata. Sebagai pintasan, Anda dapat menggunakan URL berikut di browser, dengan mengganti HOSTNAME dengan nama instance Looker Anda (seperti example.cloud.looker.com).

https://HOSTNAME/explore/system__activity/history?fields=dashboard.title,dashboard.link,history.count,history.average_runtime,history.cache_result_query_count,history.database_result_query_count,query.count_of_explores&f[history.created_date]=30+days&f[dashboard.title]=-NULL%2C-Limejump+Dashboard&sorts=history.count+desc&limit=500&query_timezone=America%2FLos_Angeles&vis=%7B%22show_view_names%22%3Afalse%2C%22show_row_numbers%22%3Atrue%2C%22transpose%22%3Afalse%2C%22truncate_text%22%3Atrue%2C%22hide_totals%22%3Afalse%2C%22hide_row_totals%22%3Afalse%2C%22size_to_fit%22%3Atrue%2C%22table_theme%22%3A%22gray%22%2C%22limit_displayed_rows%22%3Afalse%2C%22enable_conditional_formatting%22%3Atrue%2C%22header_text_alignment%22%3A%22left%22%2C%22header_font_size%22%3A%2212%22%2C%22rows_font_size%22%3A%2212%22%2C%22conditional_formatting_include_totals%22%3Afalse%2C%22conditional_formatting_include_nulls%22%3Afalse%2C%22show_sql_query_menu_options%22%3Afalse%2C%22show_totals%22%3Atrue%2C%22show_row_totals%22%3Atrue%2C%22series_column_widths%22%3A%7B%22dashboard.link%22%3A80%2C%22history.average_runtime%22%3A94%2C%22history.count%22%3A96%7D%2C%22series_cell_visualizations%22%3A%7B%22history.count%22%3A%7B%22is_active%22%3Afalse%7D%7D%2C%22conditional_formatting%22%3A%5B%7B%22type%22%3A%22along+a+scale...%22%2C%22value%22%3Anull%2C%22background_color%22%3A%22%232196F3%22%2C%22font_color%22%3Anull%2C%22color_application%22%3A%7B%22collection_id%22%3A%22bdo%22%2C%22palette_id%22%3A%22bdo-diverging-0%22%2C%22options%22%3A%7B%22steps%22%3A5%2C%22constraints%22%3A%7B%22min%22%3A%7B%22type%22%3A%22minimum%22%7D%2C%22mid%22%3A%7B%22type%22%3A%22number%22%2C%22value%22%3A0%7D%2C%22max%22%3A%7B%22type%22%3A%22maximum%22%7D%7D%2C%22mirror%22%3Atrue%2C%22reverse%22%3Atrue%2C%22stepped%22%3Afalse%7D%7D%2C%22bold%22%3Afalse%2C%22italic%22%3Afalse%2C%22strikethrough%22%3Afalse%2C%22fields%22%3A%5B%22history.average_runtime%22%5D%7D%5D%2C%22type%22%3A%22looker_grid%22%2C%22series_types%22%3A%7B%7D%2C%22defaults_version%22%3A1%2C%22hidden_fields%22%3A%5B%22history.cache_result_query_count%22%2C%22history.database_result_query_count%22%2C%22dashboard.link%22%5D%7D&filter_config=%7B%22history.created_date%22%3A%5B%7B%22type%22%3A%22past%22%2C%22values%22%3A%5B%7B%22constant%22%3A%2230%22%2C%22unit%22%3A%22day%22%7D%2C%7B%7D%5D%2C%22id%22%3A0%2C%22error%22%3Afalse%7D%5D%2C%22dashboard.title%22%3A%5B%7B%22type%22%3A%22%21null%22%2C%22values%22%3A%5B%7B%22constant%22%3A%22%22%7D%2C%7B%7D%5D%2C%22id%22%3A2%2C%22error%22%3Afalse%7D%2C%7B%22type%22%3A%22%21%3D%22%2C%22values%22%3A%5B%7B%22constant%22%3A%22Limejump+Dashboard%22%7D%2C%7B%7D%5D%2C%22id%22%3A3%2C%22error%22%3Afalse%7D%5D%7D&dynamic_fields=%5B%7B%22table_calculation%22%3A%22ratio_from_cache_vs_database%22%2C%22label%22%3A%22Ratio+from+Cache+vs+Database%22%2C%22expression%22%3A%22%24%7Bhistory.cache_result_query_count%7D%2F%24%7Bhistory.database_result_query_count%7D%22%2C%22value_format%22%3Anull%2C%22value_format_name%22%3A%22decimal_2%22%2C%22_kind_hint%22%3A%22measure%22%2C%22_type_hint%22%3A%22number%22%7D%2C%7B%22table_calculation%22%3A%22is_performing_worse_than_mean%22%2C%22label%22%3A%22Is+Performing+Worse+Than+Mean%22%2C%22expression%22%3A%22%24%7Bhistory.average_runtime%7D%3Emean%28%24%7Bhistory.average_runtime%7D%29%22%2C%22value_format%22%3Anull%2C%22value_format_name%22%3Anull%2C%22_kind_hint%22%3A%22measure%22%2C%22_type_hint%22%3A%22yesno%22%7D%5D&origin=share-expanded"  rel="undefined">this System Activity History Explore link

Anda akan melihat visualisasi Eksplorasi dengan data tentang dasbor instance Anda, termasuk Judul, Histori, Jumlah Eksplorasi, Rasio dari Cache vs. Database, dan Performa Lebih Buruk dari Rata-Rata:

Dalam contoh ini, ada sejumlah dasbor dengan pemanfaatan tinggi yang berperforma lebih buruk daripada rata-rata, seperti dasbor Sample Visualizations. Dasbor Sample Visualizations menggunakan dua Jelajah, jadi strategi yang baik adalah membuat tabel gabungan untuk kedua Jelajah ini.

Mengidentifikasi Eksplorasi yang lambat dan banyak dikueri oleh pengguna

Peluang lain untuk meningkatkan kesadaran secara agregat adalah dengan Eksplorasi yang banyak dikueri oleh pengguna dan memiliki respons kueri yang lebih rendah dari rata-rata.

Anda dapat menggunakan Jelajah Histori Aktivitas Sistem sebagai titik awal untuk mengidentifikasi peluang pengoptimalan Jelajah. Sebagai pintasan, Anda dapat menggunakan URL berikut di browser, dengan mengganti HOSTNAME dengan nama instance Looker Anda (seperti example.cloud.looker.com).

https://HOSTNAME/explore/system__activity/history?fields=query.view,history.query_run_count,user.count,query.model,history.average_runtime&f[history.created_date]=30+days&f[history.source]=Explore&sorts=history.query_run_count+desc&limit=15&query_timezone=America%2FLos_Angeles&vis=%7B%22show_view_names%22%3Afalse%2C%22show_row_numbers%22%3Atrue%2C%22transpose%22%3Afalse%2C%22truncate_text%22%3Atrue%2C%22hide_totals%22%3Afalse%2C%22hide_row_totals%22%3Afalse%2C%22size_to_fit%22%3Atrue%2C%22table_theme%22%3A%22white%22%2C%22limit_displayed_rows%22%3Afalse%2C%22enable_conditional_formatting%22%3Atrue%2C%22header_text_alignment%22%3A%22left%22%2C%22header_font_size%22%3A%2212%22%2C%22rows_font_size%22%3A%2212%22%2C%22conditional_formatting_include_totals%22%3Afalse%2C%22conditional_formatting_include_nulls%22%3Afalse%2C%22show_sql_query_menu_options%22%3Afalse%2C%22show_totals%22%3Atrue%2C%22show_row_totals%22%3Atrue%2C%22series_labels%22%3A%7B%22user.count%22%3A%22User+Count%22%7D%2C%22series_column_widths%22%3A%7B%22query.model%22%3A179%2C%22query.view%22%3A128%7D%2C%22series_cell_visualizations%22%3A%7B%22history.query_run_count%22%3A%7B%22is_active%22%3Atrue%2C%22__FILE%22%3A%22system__activity%2Fcontent_activity.dashboard.lookml%22%2C%22__LINE_NUM%22%3A106%7D%2C%22user.count%22%3A%7B%22is_active%22%3Atrue%2C%22__FILE%22%3A%22system__activity%2Fcontent_activity.dashboard.lookml%22%2C%22__LINE_NUM%22%3A108%7D%7D%2C%22conditional_formatting%22%3A%5B%7B%22type%22%3A%22along+a+scale...%22%2C%22value%22%3Anull%2C%22background_color%22%3A%22%233EB0D5%22%2C%22font_color%22%3Anull%2C%22color_application%22%3A%7B%22collection_id%22%3A%22bdo%22%2C%22palette_id%22%3A%22bdo-diverging-0%22%2C%22options%22%3A%7B%22steps%22%3A5%2C%22reverse%22%3Atrue%7D%7D%2C%22bold%22%3Afalse%2C%22italic%22%3Afalse%2C%22strikethrough%22%3Afalse%2C%22fields%22%3A%5B%22history.average_runtime%22%5D%7D%5D%2C%22type%22%3A%22looker_grid%22%2C%22truncate_column_names%22%3Afalse%2C%22series_types%22%3A%7B%7D%2C%22defaults_version%22%3A1%7D&filter_config=%7B%22history.created_date%22%3A%5B%7B%22type%22%3A%22past%22%2C%22values%22%3A%5B%7B%22constant%22%3A%2230%22%2C%22unit%22%3A%22day%22%7D%2C%7B%7D%5D%2C%22id%22%3A0%2C%22error%22%3Afalse%7D%5D%2C%22history.source%22%3A%5B%7B%22type%22%3A%22%3D%22%2C%22values%22%3A%5B%7B%22constant%22%3A%22Explore%22%7D%2C%7B%7D%5D%2C%22id%22%3A1%2C%22error%22%3Afalse%7D%5D%7D&origin=share-expanded

Anda akan melihat visualisasi Eksplorasi dengan data tentang Eksplorasi instance Anda, termasuk Eksplorasi, Model, Jumlah Eksekusi Kueri, Jumlah Pengguna, dan Waktu Proses Rata-Rata dalam Detik:

Di Eksplorasi Histori, Anda dapat mengidentifikasi jenis Eksplorasi berikut di instance Anda:

• Eksplorasi yang dikueri oleh pengguna (berbeda dengan kueri dari API atau kueri dari pengiriman terjadwal)
• Eksplorasi yang sering dikueri
• Eksplorasi yang performanya buruk (dibandingkan dengan Eksplorasi lainnya)

Dalam contoh Eksplorasi Histori Aktivitas Sistem sebelumnya, Eksplorasi flights dan order_items adalah kandidat yang mungkin untuk penerapan kesadaran gabungan.

Mengidentifikasi kolom yang banyak digunakan dalam kueri

Terakhir, Anda dapat mengidentifikasi peluang lain di tingkat data dengan memahami kolom yang biasanya disertakan pengguna dalam kueri dan filter.

Sebagai pintasan, Anda dapat menggunakan URL berikut di browser, dengan mengganti HOSTNAME dengan nama instance Looker Anda (seperti example.cloud.looker.com).

https://HOSTNAME/explore/system__activity/field_usage?fields=field_usage.model,field_usage.explore,field_usage.field,field_usage.times_used&f[field_usage.model]=faa%2C%22advanced_data_analyst_bootcamp%22&f[field_usage.explore]=flights%2C%22order_items%22&sorts=field_usage.times_used+desc&limit=500&query_timezone=America%2FNew_York&vis=%7B%22x_axis_gridlines%22%3Afalse%2C%22y_axis_gridlines%22%3Atrue%2C%22show_view_names%22%3Afalse%2C%22show_y_axis_labels%22%3Atrue%2C%22show_y_axis_ticks%22%3Atrue%2C%22y_axis_tick_density%22%3A%22default%22%2C%22y_axis_tick_density_custom%22%3A5%2C%22show_x_axis_label%22%3Atrue%2C%22show_x_axis_ticks%22%3Atrue%2C%22y_axis_scale_mode%22%3A%22linear%22%2C%22x_axis_reversed%22%3Afalse%2C%22y_axis_reversed%22%3Afalse%2C%22plot_size_by_field%22%3Afalse%2C%22trellis%22%3A%22%22%2C%22stacking%22%3A%22%22%2C%22limit_displayed_rows%22%3Atrue%2C%22legend_position%22%3A%22center%22%2C%22point_style%22%3A%22none%22%2C%22show_value_labels%22%3Afalse%2C%22label_density%22%3A25%2C%22x_axis_scale%22%3A%22auto%22%2C%22y_axis_combined%22%3Atrue%2C%22ordering%22%3A%22none%22%2C%22show_null_labels%22%3Afalse%2C%22show_totals_labels%22%3Afalse%2C%22show_silhouette%22%3Afalse%2C%22totals_color%22%3A%22%23808080%22%2C%22limit_displayed_rows_values%22%3A%7B%22show_hide%22%3A%22show%22%2C%22first_last%22%3A%22first%22%2C%22num_rows%22%3A%2215%22%7D%2C%22series_types%22%3A%7B%7D%2C%22type%22%3A%22looker_bar%22%2C%22defaults_version%22%3A1%7D&filter_config=%7B%22field_usage.model%22%3A%5B%7B%22type%22%3A%22%3D%22%2C%22values%22%3A%5B%7B%22constant%22%3A%22faa%2Cadvanced_data_analyst_bootcamp%22%7D%2C%7B%7D%5D%2C%22id%22%3A0%2C%22error%22%3Afalse%7D%5D%2C%22field_usage.explore%22%3A%5B%7B%22type%22%3A%22%3D%22%2C%22values%22%3A%5B%7B%22constant%22%3A%22flights%2Corder_items%22%7D%2C%7B%7D%5D%2C%22id%22%3A1%2C%22error%22%3Afalse%7D%5D%7D&origin=share-expanded

Ganti filter yang sesuai. Anda akan melihat Eksplorasi dengan visualisasi diagram batang yang menunjukkan berapa kali kolom telah digunakan dalam kueri:

Dalam contoh Eksplorasi Aktivitas Sistem yang ditampilkan dalam gambar, Anda dapat melihat bahwa flights.count dan flights.depart_week adalah dua kolom yang paling sering dipilih untuk Eksplorasi. Oleh karena itu, kolom tersebut adalah kandidat yang baik untuk kolom yang akan disertakan dalam tabel gabungan.

Data konkret seperti ini berguna, tetapi ada elemen subjektif yang akan memandu kriteria pemilihan Anda. Misalnya, dengan melihat empat kolom sebelumnya, Anda dapat dengan aman mengasumsikan bahwa pengguna biasanya melihat jumlah penerbangan terjadwal dan jumlah penerbangan yang dibatalkan, serta mereka ingin mengelompokkan data tersebut menurut minggu dan maskapai. Berikut adalah contoh kombinasi kolom dan metrik yang jelas, logis, dan relevan dengan dunia nyata.

Ringkasan

Langkah-langkah di halaman dokumentasi ini akan berfungsi sebagai panduan untuk menemukan dasbor, Eksplorasi, dan kolom yang perlu dipertimbangkan untuk pengoptimalan. Anda juga perlu memahami bahwa ketiga hal tersebut mungkin saling eksklusif: dasbor yang bermasalah mungkin tidak didukung oleh Eksplorasi yang bermasalah, dan membuat tabel gabungan dengan kolom yang umum digunakan mungkin tidak membantu dasbor tersebut sama sekali. Kemungkinan ini adalah tiga penerapan awareness agregat yang terpisah.

Mendesain tabel gabungan

Setelah mengidentifikasi peluang untuk meningkatkan kesadaran agregat, Anda dapat mendesain tabel agregat yang paling sesuai untuk memanfaatkan peluang ini. Lihat halaman dokumentasi Kesadaran agregasi untuk mengetahui informasi tentang kolom, ukuran, dan jangka waktu yang didukung dalam tabel gabungan, serta panduan lain untuk mendesain tabel gabungan.

CATATAN: Tabel gabungan tidak harus sama persis dengan kueri Anda agar dapat digunakan. Jika kueri Anda berada pada perincian minggu dan Anda memiliki tabel gabungan harian, Looker akan menggunakan tabel gabungan, bukan tabel tingkat stempel waktu mentah. Demikian pula, jika Anda memiliki tabel gabungan yang di-roll up ke tingkat brand dan date dan pengguna membuat kueri hanya di tingkat brand, tabel tersebut tetap menjadi kandidat untuk digunakan oleh Looker untuk kesadaran agregat.

Kesadaran agregat didukung untuk metrik berikut:

• Ukuran standar: Ukuran jenis SUM, COUNT, AVERAGE, MIN, dan MAX
• Metrik komposit: Metrik jenis NUMBER, STRING, YESNO, dan DATE
• Ukuran jumlah unik perkiraan: Dialek yang dapat menggunakan fungsi HyperLogLog

Kesadaran gabungan tidak didukung untuk ukuran berikut:

• Ukuran berbeda: Karena perbedaan hanya dapat dihitung pada data atomik yang tidak diagregasi, ukuran *_DISTINCT tidak didukung di luar perkiraan yang menggunakan HyperLogLog ini.
• Ukuran berbasis kardinalitas: Seperti ukuran unik, median dan persentil tidak dapat diagregasi sebelumnya dan tidak didukung. 

CATATAN: Jika Anda mengetahui potensi kueri pengguna dengan jenis ukuran yang tidak didukung oleh pengenalan agregat, Anda dapat membuat tabel agregat yang cocok persis dengan kueri. Tabel gabungan yang cocok persis dengan kueri dapat digunakan untuk menjawab kueri dengan jenis ukuran yang jika tidak, tidak akan didukung untuk kesadaran agregat.

Perincian tabel gabungan

Sebelum membuat tabel untuk kombinasi dimensi dan ukuran, Anda harus menentukan pola penggunaan dan pemilihan kolom yang umum untuk membuat tabel gabungan yang akan digunakan sesering mungkin dengan dampak terbesar. Perhatikan bahwa semua kolom yang digunakan dalam kueri (baik yang dipilih maupun difilter) harus ada dalam tabel gabungan agar tabel tersebut dapat digunakan untuk kueri. Namun, seperti yang disebutkan sebelumnya, tabel agregat tidak harus cocok persis dengan kueri agar dapat digunakan untuk kueri tersebut. Anda dapat menjawab banyak potensi kueri pengguna dalam satu tabel gabungan dan tetap melihat peningkatan performa yang besar.

Dari contoh mengidentifikasi kolom yang banyak digunakan dalam kueri, ada dua dimensi (flights.depart_week dan flights.carrier) yang sangat sering dipilih, serta dua ukuran (flights.count dan flights.cancelled_count). Oleh karena itu, akan logis untuk membuat tabel gabungan yang menggunakan keempat kolom ini. Selain itu, membuat satu tabel gabungan untuk flights_by_week_and_carrier akan menghasilkan penggunaan tabel gabungan yang lebih sering daripada dua tabel gabungan yang berbeda untuk tabel flights_by_week dan flights_by_carrier.

Berikut adalah contoh tabel gabungan yang dapat kita buat untuk kueri pada kolom umum:

  explore: flights {
    aggregate_table: flights_by_week_and_carrier {
      query: {
        dimensions: [carrier, depart_week]
        measures: [cancelled_count, count]
      }

      materialization: {
        sql_trigger_value: SELECT CURRENT-DATE;;
      }
    }
  }

Pengguna bisnis Anda dan bukti anekdotal serta data dari Aktivitas Sistem Looker dapat membantu memandu proses pengambilan keputusan Anda.

Menyeimbangkan penerapan dan performa

Contoh berikut menunjukkan kueri Eksplorasi untuk kolom Flights Depart Week, Flights Details Carrier, Flights Count, dan Flights Detailed Cancelled Count dari tabel gabungan flights_by_week_and_carrier:

Menjalankan kueri ini dari tabel database asli memerlukan waktu 15,8 detik dan memindai 38 juta baris tanpa gabungan apa pun menggunakan Amazon Redshift. Memutar kueri, yang merupakan operasi pengguna normal, membutuhkan waktu 29,5 detik.

Setelah menerapkan tabel gabungan flights_by_week_and_carrier, kueri berikutnya memerlukan waktu 7,2 detik dan memindai 4.592 baris. Hal ini merupakan pengurangan ukuran tabel sebesar 99,98%. Memutar kueri memerlukan waktu 9,8 detik.

Dari Eksplorasi Penggunaan Kolom Aktivitas Sistem, kita dapat melihat seberapa sering pengguna menyertakan kolom ini dalam kueri. Dalam contoh ini, flights.count digunakan 47.848 kali, flights.depart_week digunakan 18.169 kali, flights.cancelled_count digunakan 16.570 kali, dan flights.carrier digunakan 13.517 kali.

Meskipun kami memperkirakan dengan sangat sederhana bahwa 25% kueri ini menggunakan keempat kolom dengan cara paling sederhana (pilihan sederhana, tanpa pivot), 3.379 x 8,6 detik = 8 jam, 4 menit waktu tunggu pengguna secara keseluruhan dihilangkan.

CATATAN: Model contoh yang digunakan di sini sangat mendasar. Hasil ini tidak boleh digunakan sebagai tolok ukur atau kerangka referensi untuk model Anda.

Setelah menerapkan alur yang sama persis ke model e-commerce order_items — Explore yang paling sering digunakan di instance ‐ hasilnya adalah sebagai berikut:

Sumber	Waktu Kueri	Baris yang Dipindai
Tabel Dasar	13,1 detik	285.000
Tabel Gabungan	5,1 detik	138.000
Delta	8 detik	147.000

Kolom yang digunakan dalam kueri dan tabel gabungan berikutnya adalah brand, created_date, orders_count, dan total_revenue, menggunakan dua gabungan. Kolom tersebut telah digunakan sebanyak 11.000 kali. Dengan memperkirakan penggunaan gabungan yang sama sebesar ~25%, penghematan gabungan untuk pengguna adalah 6 jam, 6 menit (8 dtk * 2750 = 22000 dtk). Tabel gabungan memerlukan waktu 17,9 detik untuk dibuat.

Dengan melihat hasil ini, ada baiknya kita meluangkan waktu untuk mundur sejenak dan menilai potensi keuntungan yang diperoleh dari:

• Mengoptimalkan model/Eksplorasi yang lebih besar dan lebih kompleks yang memiliki performa "dapat diterima" dan mungkin mengalami peningkatan performa dari praktik pemodelan yang lebih baik

versus

• Menggunakan awareness gabungan untuk mengoptimalkan model yang lebih sederhana yang lebih sering digunakan dan berperforma buruk

Anda akan melihat penurunan hasil dari upaya Anda saat mencoba mendapatkan performa terakhir dari Looker dan database Anda. Anda harus selalu menyadari ekspektasi performa dasar, terutama dari pengguna bisnis, dan batasan yang diberlakukan oleh database Anda (seperti serentak, nilai minimum kueri, biaya, dan sebagainya). Anda tidak boleh berharap kesadaran gabungan dapat mengatasi batasan ini.

Selain itu, saat mendesain tabel gabungan, ingatlah bahwa memiliki lebih banyak kolom akan menghasilkan tabel gabungan yang lebih besar dan lebih lambat. Tabel yang lebih besar dapat mengoptimalkan lebih banyak kueri dan oleh karena itu dapat digunakan dalam lebih banyak situasi, tetapi tabel besar tidak akan secepat tabel yang lebih kecil dan lebih sederhana.

Contoh:

  explore: flights {
    aggregate_table: flights_by_week_and_carrier {
      query: {
        dimensions: [carrier, depart_week,flights.distance, flights.arrival_week,flights.cancelled]
        measures: [cancelled_count, count, flights.average_distance, flights.total_distance]
      }

      materialization: {
        sql_trigger_value: SELECT CURRENT-DATE;;
      }
    }
  }

Hal ini akan menyebabkan tabel gabungan digunakan untuk kombinasi dimensi yang ditampilkan dan untuk ukuran yang disertakan, sehingga tabel ini dapat digunakan untuk menjawab banyak kueri pengguna yang berbeda. Namun, untuk menggunakan tabel ini untuk kueri SELECT sederhana dari carrier dan count, diperlukan pemindaian tabel 885.000 baris. Sebaliknya, kueri yang sama hanya akan memerlukan pemindaian 4.592 baris jika tabel didasarkan pada dua dimensi. Tabel 885 ribu baris masih merupakan pengurangan ukuran tabel sebesar 97% (dari 38 juta baris sebelumnya); tetapi menambahkan satu dimensi lagi akan meningkatkan ukuran tabel menjadi 20 juta baris. Oleh karena itu, ada penurunan hasil saat Anda menyertakan lebih banyak kolom dalam tabel gabungan untuk meningkatkan penerapannya pada lebih banyak kueri.

Membangun tabel gabungan

Mengambil contoh Flights Explore yang kami identifikasi sebagai peluang untuk dioptimalkan, strategi terbaiknya adalah membuat tiga tabel gabungan yang berbeda untuknya:

• flights_by_week_and_carrier
• flights_by_month_and_distance
• flights_by_year

Cara termudah untuk membuat tabel gabungan ini adalah dengan mendapatkan LookML tabel gabungan dari kueri Jelajah atau dari dasbor dan menambahkan LookML ke file project Looker Anda.

Setelah Anda menambahkan tabel gabungan ke project LookML dan men-deploy update ke produksi, Jelajah akan memanfaatkan tabel gabungan untuk kueri pengguna Anda.

Persistensi

Agar dapat diakses untuk pengenalan gabungan, tabel gabungan harus dipertahankan dalam database Anda. Sebaiknya selaraskan pembuatan ulang otomatis tabel gabungan ini dengan kebijakan penyimpanan dalam cache Anda dengan memanfaatkan grup data. Anda harus menggunakan grup data yang sama untuk tabel gabungan yang digunakan untuk Eksplorasi terkait. Jika Anda tidak dapat menggunakan grup data, opsi alternatifnya adalah menggunakan parameter sql_trigger_value. Berikut menunjukkan nilai berbasis tanggal generik untuk sql_trigger_value:

sql_trigger_value: SELECT CURRENT_DATE() ;;

Tindakan ini akan membuat tabel gabungan Anda secara otomatis setiap hari pada tengah malam.

Logika jangka waktu

Saat membuat tabel gabungan, Looker akan menyertakan data hingga saat tabel gabungan dibuat. Data apa pun yang kemudian ditambahkan ke tabel dasar dalam database biasanya akan dikecualikan dari hasil kueri menggunakan tabel gabungan tersebut.

Diagram ini menunjukkan linimasa saat pesanan diterima dan dicatat dalam database dibandingkan dengan titik waktu saat tabel gabungan Pesanan dibuat. Ada dua pesanan yang diterima hari ini yang tidak akan ada dalam tabel gabungan Pesanan, karena pesanan diterima setelah tabel gabungan dibuat:

Namun, Looker dapat menggabungkan data baru ke tabel gabungan saat pengguna membuat kueri untuk jangka waktu yang tumpang-tindih dengan tabel gabungan, seperti yang digambarkan dalam diagram linimasa yang sama:

Karena Looker dapat menggabungkan data baru ke tabel gabungan, jika pengguna memfilter jangka waktu yang tumpang-tindih dengan akhir tabel gabungan dan tabel dasar, pesanan yang diterima setelah tabel gabungan dibuat akan disertakan dalam hasil pengguna. Lihat halaman dokumentasi Kesadaran agregat untuk mengetahui detail dan kondisi yang harus dipenuhi untuk menggabungkan data baru ke kueri tabel gabungan.

Ringkasan

Sebagai rangkuman, untuk membuat penerapan kesadaran gabungan, ada tiga langkah mendasar:

1. Identifikasi peluang yang tepat dan berdampak untuk pengoptimalan menggunakan tabel gabungan.
2. Rancang tabel gabungan yang akan memberikan cakupan paling besar untuk kueri pengguna umum sekaligus tetap cukup kecil untuk mengurangi ukuran kueri tersebut secara memadai.
3. Buat tabel gabungan dalam model Looker, yang menyandingkan persistensi tabel dengan persistensi cache Eksplorasi.