Linimasa dan paket kueri

Tersemat dalam tugas kueri, BigQuery menyertakan informasi paket kueri dan waktu diagnostik. Hal ini mirip dengan informasi yang diberikan oleh pernyataan seperti EXPLAIN dalam sistem analisis dan database lain. Informasi ini dapat diambil dari respons API metode seperti jobs.get.

Untuk kueri yang berjalan lama, BigQuery akan memperbarui statistik ini secara berkala. Update ini terjadi secara mandiri pada tingkat polling status tugas, tetapi biasanya tidak akan terjadi lebih sering dari setiap 30 detik. Selain itu, tugas kueri yang tidak menggunakan resource eksekusi, seperti permintaan uji coba atau hasil yang dapat disajikan dari hasil yang di-cache, tidak akan menyertakan informasi diagnostik tambahan, meskipun mungkin ada statistik lain.

Latar belakang

Saat menjalankan tugas kueri, BigQuery mengonversi pernyataan SQL deklaratif menjadi grafik eksekusi, yang dipecah menjadi serangkaian tahap kueri, yang terdiri dari kumpulan yang lebih terperinci langkah-langkah eksekusi. BigQuery memanfaatkan arsitektur paralel yang sangat terdistribusi untuk menjalankan kueri ini. Tahapan membuat model unit tugas yang dapat dijalankan oleh banyak worker potensial secara paralel. Tahapan berkomunikasi satu sama lain menggunakan arsitektur shuffle terdistribusi yang cepat.

Dalam paket kueri, istilah unit tugas dan worker digunakan untuk menyampaikan informasi secara khusus tentang paralelisme. Di bagian lain dalam BigQuery, Anda mungkin menemukan istilah slot, yaitu representasi abstrak dari beberapa faset eksekusi kueri, termasuk komputasi, memori, dan resource I/O. Statistik tugas tingkat teratas memberikan perkiraan biaya kueri tertentu menggunakan estimasi totalSlotMs kueri menggunakan penghitungan terpisah ini.

Properti penting lainnya dari arsitektur eksekusi kueri adalah bersifat dinamis. Artinya, paket kueri dapat diubah saat kueri sedang berjalan. Stage yang diperkenalkan saat kueri berjalan sering digunakan untuk meningkatkan distribusi data di seluruh worker kueri. Dalam paket kueri di mana proses tersebut berlangsung, stage ini biasanya dilabeli sebagai Stage partisi ulang.

Selain paket kueri, tugas kueri juga mengekspos linimasa eksekusi, yang menyediakan akuntansi unit tugas yang telah selesai, tertunda, dan aktif dalam pekerja kueri. Kueri dapat memiliki beberapa tahap dengan pekerja aktif secara bersamaan, dan linimasa dimaksudkan untuk menampilkan progres kueri secara keseluruhan.

Melihat informasi dengan Google Cloud console

Di konsolGoogle Cloud , Anda dapat melihat detail paket kueri untuk kueri yang telah selesai dengan mengklik tombol Execution Details (di dekat tombol Results).

Informasi paket kueri

Dalam respons API, paket kueri direpresentasikan sebagai daftar stage kueri. Setiap item dalam daftar menunjukkan statistik ringkasan per stage, informasi langkah yang mendetail, dan klasifikasi pengaturan waktu stage. Tidak semua detail dirender dalam konsol Google Cloud , tetapi semuanya dapat tersedia dalam respons API.

Ringkasan stage

Kolom ringkasan untuk setiap stage dapat mencakup hal berikut:

Klasifikasi pengaturan waktu per stage

Stage kueri menyediakan klasifikasi pengaturan waktu stage, baik dalam bentuk relatif maupun absolut. Karena setiap stage eksekusi merepresentasikan tugas yang dilakukan oleh satu atau beberapa worker independen, informasi diberikan dalam waktu rata-rata dan kasus terburuk. Waktu ini menunjukkan performa rata-rata untuk semua worker dalam satu stage serta performa worker paling lambat longtail untuk klasifikasi tertentu. Waktu rata-rata dan waktu maksimum selanjutnya dibagi menjadi representasi absolut dan relatif. Untuk statistik berbasis rasio, data diberikan sebagai hasil bagi dari waktu terlama yang dihabiskan oleh worker mana pun di segmen mana pun.

Konsol Google Cloud menampilkan pengaturan waktu stage menggunakan representasi pengaturan waktu relatif.

Informasi pengaturan waktu stage dilaporkan sebagai berikut:

Ringkasan langkah

Langkah-langkah berisi operasi yang dijalankan oleh setiap worker dalam satu stage, yang ditampilkan sebagai daftar operasi yang diurutkan. Setiap operasi langkah memiliki kategori, dengan beberapa operasi memberikan informasi yang lebih mendetail. Kategori operasi yang ada dalam paket kueri mencakup hal berikut:

Memahami detail langkah

BigQuery menyediakan Detail langkah yang menjelaskan apa yang dilakukan setiap langkah dalam suatu tahap. Memahami langkah-langkah dalam tahap diperlukan untuk mengidentifikasi sumber masalah performa kueri.

Untuk menemukan detail langkah untuk suatu tahap, ikuti langkah-langkah berikut:

1. Di panel Hasil kueri, klik Grafik eksekusi.

   

2. Klik tahap yang Anda minati untuk membuka panel dengan informasi tahap.

3. Di panel yang berisi informasi tahap, buka bagian Detail langkah.

   

Setiap langkah terdiri dari sub-langkah yang menjelaskan tindakan yang dilakukan dalam langkah tersebut. Sublangkah menggunakan variabel untuk menjelaskan hubungan antar-langkah. Variabel dimulai dengan tanda dolar, diikuti dengan angka unik.

Berikut adalah contoh detail langkah dari tahap dengan variabel yang dibagikan di antara langkah-langkah:

READ
$30:l_orderkey, $31:l_quantity
FROM lineitem

AGGREGATE
GROUP BY $100 := $30
$70 := SUM($31)

WRITE
$100, $70
TO __stage00_output
BY HASH($100)

Detail langkah contoh melakukan hal berikut:

1. Tahap ini membaca kolom l_orderkey dan l_quantity dari tabel lineitem menggunakan variabel $30 dan $31.

2. Tahap ini diagregasi pada variabel $30 dan $31, yang menyimpan agregasi ke dalam variabel $100 dan $70.

3. Tahap ini menulis hasil variabel $100 dan $70 untuk diacak. Tahap ini menggunakan $100 untuk mengurutkan hasil tahap dalam pengacakan.

BigQuery mungkin memangkas detail langkah jika grafik eksekusi kueri cukup kompleks sehingga memberikan detail langkah tahap yang lengkap akan menyebabkan masalah ukuran payload saat mengambil informasi kueri.

Memahami langkah-langkah dengan Teks kueri

Untuk mendapatkan dukungan selama pratinjau, kirim email ke bq-query-inspector-feedback@google.com.

Memahami hubungan antara langkah-langkah tahap dengan kueri bisa jadi sulit. Bagian Teks kueri menunjukkan bagaimana beberapa langkah terkait dengan teks kueri asli.

Bagian Teks kueri menandai berbagai bagian teks kueri asli dan menampilkan langkah-langkah yang dipetakan kembali ke teks kueri yang langsung mendahului teks kueri asli yang ditandai. Hanya langkah-langkah tepat di atas bagian yang ditandai dari teks kueri asli yang berlaku untuk teks kueri yang ditandai.

Contoh screenshot menunjukkan pemetaan berikut:

• Langkah AGGREGATE: GROUP BY $100 := $30 dipetakan kembali ke teks kueri select l_orderkey.

• Langkah READ: FROM lineitem dipetakan kembali ke teks kueri select ... from lineitem.

• Langkah AGGREGATE: $70 := SUM($31) dipetakan kembali ke teks kueri sum(l_quantity).

Tidak semua langkah dapat dipetakan kembali ke teks kueri.

Jika kueri menggunakan tampilan, dan jika langkah-langkah tahap memiliki pemetaan ke teks kueri tampilan, bagian Teks kueri menampilkan nama tampilan dan teks kueri tampilan dengan pemetaannya. Namun, jika tampilan dihapus, atau jika Anda kehilangan bigquery.tables.get izin IAM ke tampilan, bagian Teks kueri tidak akan menampilkan pemetaan langkah-langkah tahap untuk tampilan.

Menafsirkan dan mengoptimalkan langkah-langkah

Bagian berikut menjelaskan cara menafsirkan langkah-langkah dalam rencana kueri dan memberikan cara untuk mengoptimalkan kueri Anda.

READ langkah

Langkah READ berarti bahwa suatu tahap mengakses data untuk diproses. Data dapat dibaca langsung dari tabel yang dirujuk dalam kueri, atau dari memori pengacakan. Saat data dari tahap sebelumnya dibaca, BigQuery membaca data dari memori pengacakan. Jumlah data yang dipindai memengaruhi biaya saat menggunakan slot on-demand dan memengaruhi performa saat menggunakan reservasi.

Potensi masalah performa

• Pemindaian besar tabel yang tidak berpartisi: jika kueri hanya memerlukan sebagian kecil data, hal ini mungkin menunjukkan bahwa pemindaian tabel tidak efisien. Partisi dapat menjadi strategi pengoptimalan yang baik.
• Pemindaian tabel besar dengan rasio filter kecil: hal ini menunjukkan bahwa filter tidak secara efektif mengurangi data yang dipindai. Pertimbangkan untuk merevisi kondisi filter.
• Byte pengacakan yang meluap ke disk: hal ini menunjukkan bahwa data tidak disimpan secara efektif menggunakan teknik pengoptimalan seperti pengelompokan, yang dapat mempertahankan data serupa dalam cluster.

Optimalkan

• Pemfilteran yang ditargetkan: gunakan klausa WHERE secara strategis untuk memfilter data yang tidak relevan sedini mungkin dalam kueri. Tindakan ini mengurangi jumlah data yang perlu diproses oleh kueri.
• Partisi dan pengelompokan: BigQuery menggunakan partisi dan pengelompokan tabel untuk menemukan segmen data tertentu secara efisien. Pastikan tabel Anda dipartisi dan dikelompokkan berdasarkan pola kueri umum Anda untuk meminimalkan data yang dipindai selama langkah-langkah READ.
• Pilih kolom yang relevan: hindari penggunaan pernyataan SELECT *. Sebagai gantinya, pilih kolom tertentu atau gunakan SELECT * EXCEPT untuk menghindari pembacaan data yang tidak perlu.
• Tampilan terwujud: tampilan terwujud dapat melakukan pra-penghitungan dan menyimpan agregasi yang sering digunakan, sehingga berpotensi mengurangi kebutuhan untuk membaca tabel dasar selama langkah READ untuk kueri yang menggunakan tampilan tersebut.

COMPUTE langkah

Pada langkah COMPUTE, BigQuery melakukan tindakan berikut pada data Anda:

• Mengevaluasi ekspresi dalam SELECT, WHERE, HAVING, dan klausa lainnya dalam kueri, termasuk kalkulasi, perbandingan, dan operasi logis.
• Mengeksekusi fungsi SQL bawaan dan fungsi yang ditentukan pengguna.
• Memfilter baris data berdasarkan kondisi dalam kueri.

Optimalkan

Paket kueri dapat mengungkapkan hambatan dalam langkah COMPUTE. Cari tahap dengan komputasi yang ekstensif atau jumlah baris yang diproses dalam jumlah besar.

• Korelasikan langkah COMPUTE dengan volume data: jika suatu tahap menunjukkan komputasi yang signifikan dan memproses volume data yang besar, maka tahap tersebut mungkin merupakan kandidat yang baik untuk dioptimalkan.
• Data miring: untuk tahap saat maksimum komputasi jauh lebih tinggi daripada rata-rata komputasi, hal ini menunjukkan bahwa tahap tersebut menghabiskan waktu yang tidak proporsional untuk memproses beberapa slice data. Pertimbangkan untuk melihat distribusi data untuk mengetahui apakah ada skew data.
• Pertimbangkan jenis data: gunakan jenis data yang sesuai untuk kolom Anda. Misalnya, menggunakan bilangan bulat, tanggal dan waktu, serta stempel waktu, bukan string, dapat meningkatkan performa.

WRITE langkah

WRITE terjadi untuk data perantara dan output akhir.

• Menulis ke memori pengacakan: dalam kueri multi-tahap, langkah WRITE sering kali melibatkan pengiriman data yang diproses ke tahap lain untuk diproses lebih lanjut. Hal ini umum terjadi pada memori pengacakan, yang menggabungkan atau mengagregasikan data dari beberapa sumber. Data yang ditulis selama tahap ini biasanya merupakan hasil sementara, bukan output akhir.
• Output akhir: hasil kueri ditulis ke tujuan atau tabel sementara.

Partisi Hash

Saat tahap dalam rencana kueri menulis data ke output yang dipartisi hash, BigQuery menulis kolom yang disertakan dalam output dan kolom yang dipilih sebagai kunci partisi.

Optimalkan

Meskipun langkah WRITE itu sendiri mungkin tidak dioptimalkan secara langsung, memahami perannya dapat membantu Anda mengidentifikasi potensi hambatan pada tahap sebelumnya:

• Minimalkan data yang ditulis: berfokus pada pengoptimalan tahap sebelumnya dengan pemfilteran dan agregasi untuk mengurangi jumlah data yang ditulis selama langkah ini.

• Partisi: penulisan sangat diuntungkan dari partisi tabel. Jika data yang Anda tulis terbatas pada partisi tertentu, BigQuery dapat melakukan penulisan yang lebih cepat.

  Jika pernyataan DML memiliki klausa WHERE dengan kondisi statis terhadap kolom partisi tabel, BigQuery hanya akan mengubah partisi tabel yang relevan.

• Trade-off denormalisasi: denormalisasi terkadang dapat menghasilkan set hasil yang lebih kecil pada langkah WRITE menengah. Namun, ada kekurangan seperti peningkatan penggunaan penyimpanan dan tantangan konsistensi data.

JOIN langkah

Pada langkah JOIN, BigQuery menggabungkan data dari dua sumber data. Gabungan dapat mencakup kondisi gabungan. Penggabungan memerlukan banyak resource. Saat menggabungkan data berukuran besar di BigQuery, kunci gabungan diacak secara terpisah agar sejajar di slot yang sama, sehingga gabungan dilakukan secara lokal di setiap slot.

Paket kueri untuk langkah JOIN biasanya mengungkapkan detail berikut:

• Pola gabungan: menunjukkan jenis gabungan yang digunakan. Setiap jenis menentukan jumlah baris dari tabel gabungan yang disertakan dalam set hasil.
• Gabungkan kolom: ini adalah kolom yang digunakan untuk mencocokkan baris di antara sumber data. Pilihan kolom sangat penting untuk performa gabungan.

Pola gabungan

• Penggabungan siaran: saat satu tabel, biasanya yang lebih kecil, dapat dimuat dalam memori di satu node atau slot pekerja, BigQuery dapat menyiarkannya ke semua node lain untuk melakukan penggabungan secara efisien. Cari JOIN EACH WITH ALL di detail langkah.
• Hash join: saat tabel berukuran besar atau gabungan siaran tidak sesuai, gabungan hash dapat digunakan. BigQuery menggunakan operasi hash dan shuffle untuk mengacak tabel kiri dan kanan sehingga kunci yang cocok berada di slot yang sama untuk melakukan penggabungan lokal. Penggabungan hash adalah operasi yang mahal karena data perlu dipindahkan, tetapi memungkinkan pencocokan baris yang efisien di seluruh hash. Cari JOIN EACH WITH EACH di detail langkah.
• Self-join: antipola SQL yang menggabungkan tabel dengan tabel itu sendiri.
• Cross join: antipola SQL yang dapat menyebabkan masalah performa yang signifikan karena menghasilkan data output yang lebih besar daripada input.
• Gabungan miring: distribusi data di seluruh kunci gabungan dalam satu tabel sangat miring dan dapat menyebabkan masalah performa. Cari kasus saat waktu komputasi maksimum jauh lebih besar daripada waktu komputasi rata-rata dalam rencana kueri. Untuk mengetahui informasi selengkapnya, lihat Gabungan kardinalitas tinggi dan Ketidakseimbangan partisi.

Proses Debug

• Volume data besar: jika paket kueri menunjukkan sejumlah besar data yang diproses selama langkah JOIN, selidiki kondisi gabungan dan kunci gabungan. Pertimbangkan untuk memfilter atau menggunakan kunci gabungan yang lebih selektif.
• Distribusi data miring: menganalisis distribusi data kunci gabungan. Jika satu tabel sangat miring, pelajari strategi seperti memisahkan kueri atau melakukan prapenyaringan.
• Join kardinalitas tinggi: join yang menghasilkan baris yang jauh lebih banyak daripada jumlah baris input kiri dan kanan dapat mengurangi performa kueri secara drastis. Hindari gabungan yang menghasilkan sejumlah besar baris.
• Urutan tabel yang salah: Pastikan Anda telah memilih jenis penggabungan yang sesuai, seperti INNER atau LEFT, dan mengurutkan tabel dari yang terbesar hingga yang terkecil berdasarkan persyaratan kueri Anda.

Optimalkan

• Kunci gabungan selektif: untuk kunci gabungan, gunakan INT64, bukan STRING, jika memungkinkan. Perbandingan STRING lebih lambat daripada perbandingan INT64 karena membandingkan setiap karakter dalam string. Bilangan bulat hanya memerlukan satu perbandingan.
• Memfilter sebelum menggabungkan: menerapkan filter klausa WHERE pada setiap tabel sebelum penggabungan. Hal ini mengurangi jumlah data yang terlibat dalam operasi penggabungan.
• Hindari fungsi pada kolom gabungan: hindari pemanggilan fungsi pada kolom gabungan. Sebagai gantinya, standarisasi data tabel Anda selama proses penyerapan atau pasca-penyerapan menggunakan pipeline SQL ELT. Pendekatan ini menghilangkan kebutuhan untuk mengubah kolom gabungan secara dinamis, yang memungkinkan penggabungan yang lebih efisien tanpa mengorbankan integritas data.
• Menghindari self-join: self-join biasanya digunakan untuk menghitung hubungan yang bergantung pada baris. Namun, self-join berpotensi melipatgandakan jumlah baris output, sehingga menyebabkan masalah performa. Daripada mengandalkan self-join, pertimbangkan untuk menggunakan fungsi jendela (analitik).
• Tabel besar terlebih dahulu: meskipun pengoptimal kueri SQL dapat menentukan tabel mana yang harus berada di sisi gabungan mana, urutkan tabel gabungan Anda dengan tepat. Praktik terbaiknya adalah menempatkan tabel terbesar terlebih dahulu, diikuti dengan tabel terkecil, lalu berdasarkan ukuran yang menurun.
• Denormalisasi: dalam beberapa kasus, denormalisasi tabel secara strategis (menambahkan data berlebihan) dapat menghilangkan penggabungan sepenuhnya. Namun, pendekatan ini memiliki kekurangan dalam hal penyimpanan dan konsistensi data.
• Partisi dan pengelompokan: Mempartisi tabel berdasarkan kunci gabungan dan mengelompokkan data yang ditempatkan bersama dapat mempercepat gabungan secara signifikan dengan memungkinkan BigQuery menargetkan partisi data yang relevan.
• Mengoptimalkan penggabungan condong: untuk menghindari masalah performa yang terkait dengan penggabungan condong, pra-filter data dari tabel sedini mungkin atau bagi kueri menjadi dua kueri atau lebih.

AGGREGATE langkah

Pada langkah AGGREGATE, BigQuery menggabungkan dan mengelompokkan data.

Proses Debug

• Detail tahap: periksa jumlah baris input dan baris output dari agregasi, dan ukuran pengacakan untuk menentukan seberapa besar pengurangan data yang dicapai langkah agregasi dan apakah pengacakan data terlibat.
• Ukuran pengacakan: ukuran pengacakan yang besar dapat menunjukkan bahwa sejumlah besar data dipindahkan di seluruh node pekerja selama agregasi.
• Periksa distribusi data: pastikan data didistribusikan secara merata di seluruh partisi. Distribusi data yang miring dapat menyebabkan workload yang tidak seimbang dalam langkah agregasi.
• Tinjau agregasi: analisis klausa agregasi untuk mengonfirmasi bahwa klausa tersebut diperlukan dan efisien.

Optimalkan

• Pengelompokan: kelompokkan tabel Anda pada kolom yang sering digunakan dalam GROUP BY, COUNT, atau klausa agregasi lainnya.
• Partisi: pilih strategi partisi yang sesuai dengan pola kueri Anda. Sebaiknya gunakan tabel berpartisi berdasarkan waktu penyerapan untuk mengurangi jumlah data yang dipindai selama agregasi.
• Agregasi lebih awal: jika memungkinkan, lakukan agregasi lebih awal di pipeline kueri. Hal ini dapat mengurangi jumlah data yang perlu diproses selama agregasi.
• Pengoptimalan pengacakan: jika pengacakan menjadi hambatan, pelajari cara meminimalkannya. Misalnya, denormalisasi tabel atau gunakan pengelompokan untuk menempatkan data yang relevan.

Kasus ekstrem

• Agregat DISTINCT: kueri dengan agregat DISTINCT dapat memerlukan banyak komputasi, terutama pada set data besar. Pertimbangkan alternatif seperti APPROX_COUNT_DISTINCT untuk mendapatkan perkiraan hasil.
• Jumlah grup yang besar: jika kueri menghasilkan sejumlah besar grup, kueri tersebut dapat menggunakan sejumlah besar memori. Dalam kasus tersebut, pertimbangkan untuk membatasi jumlah grup atau menggunakan strategi agregasi yang berbeda.

REPARTITION langkah

REPARTITION dan COALESCE adalah teknik pengoptimalan yang diterapkan BigQuery secara langsung ke data yang diacak dalam kueri.

• REPARTITION: operasi ini bertujuan untuk menyeimbangkan kembali distribusi data di seluruh node pekerja. Misalkan setelah pengacakan, satu worker node memiliki data dalam jumlah yang sangat besar. Langkah REPARTITION mendistribusikan ulang data secara lebih merata, sehingga mencegah satu pekerja menjadi hambatan. Hal ini sangat penting untuk operasi yang intensif secara komputasi seperti penggabungan.
• COALESCE: langkah ini terjadi saat Anda memiliki banyak bucket kecil data setelah pengacakan. Langkah COALESCE menggabungkan bucket ini menjadi bucket yang lebih besar, sehingga mengurangi overhead yang terkait dengan pengelolaan banyak potongan data kecil. Hal ini dapat sangat bermanfaat saat menangani set hasil perantara yang sangat kecil.

Jika Anda melihat langkah-langkah REPARTITION atau COALESCE dalam rencana kueri, bukan berarti ada masalah dengan kueri Anda. Hal ini sering kali menandakan bahwa BigQuery secara proaktif mengoptimalkan distribusi data untuk performa yang lebih baik. Namun, jika Anda melihat operasi ini berulang kali, hal ini mungkin menunjukkan bahwa data Anda pada dasarnya miring atau kueri Anda menyebabkan pengacakan data yang berlebihan.

Optimalkan

Untuk mengurangi jumlah langkah REPARTITION, coba lakukan hal berikut:

• Distribusi data: pastikan tabel Anda dipartisi dan dikelompokkan secara efektif. Data yang terdistribusi dengan baik mengurangi kemungkinan ketidakseimbangan yang signifikan setelah pengacakan.
• Struktur kueri: menganalisis kueri untuk mengetahui potensi sumber kemiringan data. Misalnya, apakah ada filter atau gabungan yang sangat selektif yang menyebabkan subset kecil data diproses pada satu pekerja?
• Strategi penggabungan: lakukan eksperimen dengan berbagai strategi penggabungan untuk melihat apakah strategi tersebut menghasilkan distribusi data yang lebih seimbang.

Untuk mengurangi jumlah langkah COALESCE, coba lakukan hal berikut:

• Strategi agregasi: pertimbangkan untuk melakukan agregasi lebih awal di pipeline kueri. Hal ini dapat membantu mengurangi jumlah set hasil perantara kecil yang dapat menyebabkan langkah-langkah COALESCE.
• Volume data: jika Anda menangani set data yang sangat kecil, COALESCE mungkin tidak menjadi masalah yang signifikan.

Jangan terlalu mengoptimalkan. Pengoptimalan prematur dapat membuat kueri Anda menjadi lebih rumit tanpa memberikan manfaat yang signifikan.

Penjelasan untuk kueri gabungan

Kueri gabungan memungkinkan Anda mengirim pernyataan kueri ke sumber data eksternal menggunakan fungsi EXTERNAL_QUERY. Kueri gabungan tunduk pada teknik pengoptimalan yang dikenal sebagai pushdown SQL dan rencana kueri menunjukkan operasi yang di-pushdown ke sumber data eksternal, jika ada. Misalnya, jika Anda menjalankan kueri berikut:

SELECT id, name
FROM EXTERNAL_QUERY("<connection>", "SELECT * FROM company")
WHERE country_code IN ('ee', 'hu') AND name like '%TV%'

Rencana kueri akan menampilkan langkah-langkah tahap berikut:

$1:id, $2:name, $3:country_code
FROM table_for_external_query_$_0(
  SELECT id, name, country_code
  FROM (
    /*native_query*/
    SELECT * FROM company
  )
  WHERE in(country_code, 'ee', 'hu')
)
WHERE and(in($3, 'ee', 'hu'), like($2, '%TV%'))
$1, $2
TO __stage00_output

Dalam rencana ini, table_for_external_query_$_0(...) mewakili fungsi EXTERNAL_QUERY. Dalam tanda kurung, Anda dapat melihat kueri yang dijalankan sumber data eksternal. Berdasarkan hal itu, Anda dapat melihat bahwa:

• Sumber data eksternal hanya menampilkan 3 kolom yang dipilih.
• Sumber data eksternal hanya menampilkan baris yang country_code-nya adalah 'ee' atau 'hu'.
• Operator LIKE tidak didorong ke bawah dan dievaluasi oleh BigQuery.

Sebagai perbandingan, jika tidak ada pushdown, paket kueri akan menampilkan langkah-langkah tahap berikut:

$1:id, $2:name, $3:country_code
FROM table_for_external_query_$_0(
  SELECT id, name, description, country_code, primary_address, secondary address
  FROM (
    /*native_query*/
    SELECT * FROM company
  )
)
WHERE and(in($3, 'ee', 'hu'), like($2, '%TV%'))
$1, $2
TO __stage00_output

Kali ini, sumber data eksternal menampilkan semua kolom dan semua baris dari tabel company, dan BigQuery melakukan pemfilteran.

Metadata linimasa

Linimasa kueri melaporkan progres pada waktu tertentu, yang menyediakan tampilan snapshot progres kueri secara keseluruhan. Linimasa direpresentasikan sebagai serangkaian contoh yang melaporkan detail berikut:

Contoh kueri

Kueri berikut menghitung jumlah baris dalam set data publik Shakespeare dan memiliki jumlah bersyarat kedua yang membatasi hasil pada baris yang merujuk ke 'hamlet':

SELECT
  COUNT(1) as rowcount,
  COUNTIF(corpus = 'hamlet') as rowcount_hamlet
FROM `publicdata.samples.shakespeare`

Klik Execution details untuk melihat paket kueri:

Indikator warna menunjukkan pengaturan waktu relatif untuk semua langkah di seluruh stage.

Untuk mempelajari lebih lanjut langkah-langkah stage eksekusi, klik arrow_drop_down untuk meluaskan detail stage tersebut:

Dalam contoh ini, waktu terlama di segmen mana pun adalah waktu yang dihabiskan oleh satu worker di Stage 01 untuk menunggu Stage 00 selesai. Hal ini karena Stage 01 bergantung pada input Stage 00, dan tidak dapat dimulai hingga stage pertama menulis output-nya dalam mode shuffle menengah.

Pelaporan error

Tugas kueri mungkin saja gagal di tengah eksekusi. Karena informasi paket diperbarui secara berkala, Anda dapat mengamati di bagian mana kegagalan terjadi dalam grafik eksekusi. Dalam konsol Google Cloud , tahap yang berhasil atau gagal diberi label dengan tanda centang atau tanda seru di samping nama tahap.

Untuk mengetahui informasi lebih lanjut tentang cara menafsirkan dan mengatasi error, lihat panduan pemecahan masalah.

Representasi contoh API

Informasi paket kueri disematkan dalam informasi respons tugas, dan Anda dapat mengambilnya dengan memanggil jobs.get. Misalnya, kutipan respons JSON berikut untuk tugas yang menampilkan contoh kueri hamlet menunjukkan paket kueri dan informasi linimasa.

"statistics": {
  "creationTime": "1576544129234",
  "startTime": "1576544129348",
  "endTime": "1576544129681",
  "totalBytesProcessed": "2464625",
  "query": {
    "queryPlan": [
      {
        "name": "S00: Input",
        "id": "0",
        "startMs": "1576544129436",
        "endMs": "1576544129465",
        "waitRatioAvg": 0.04,
        "waitMsAvg": "1",
        "waitRatioMax": 0.04,
        "waitMsMax": "1",
        "readRatioAvg": 0.32,
        "readMsAvg": "8",
        "readRatioMax": 0.32,
        "readMsMax": "8",
        "computeRatioAvg": 1,
        "computeMsAvg": "25",
        "computeRatioMax": 1,
        "computeMsMax": "25",
        "writeRatioAvg": 0.08,
        "writeMsAvg": "2",
        "writeRatioMax": 0.08,
        "writeMsMax": "2",
        "shuffleOutputBytes": "18",
        "shuffleOutputBytesSpilled": "0",
        "recordsRead": "164656",
        "recordsWritten": "1",
        "parallelInputs": "1",
        "completedParallelInputs": "1",
        "status": "COMPLETE",
        "steps": [
          {
            "kind": "READ",
            "substeps": [
              "$1:corpus",
              "FROM publicdata.samples.shakespeare"
            ]
          },
          {
            "kind": "AGGREGATE",
            "substeps": [
              "$20 := COUNT($30)",
              "$21 := COUNTIF($31)"
            ]
          },
          {
            "kind": "COMPUTE",
            "substeps": [
              "$30 := 1",
              "$31 := equal($1, 'hamlet')"
            ]
          },
          {
            "kind": "WRITE",
            "substeps": [
              "$20, $21",
              "TO __stage00_output"
            ]
          }
        ]
      },
      {
        "name": "S01: Output",
        "id": "1",
        "startMs": "1576544129465",
        "endMs": "1576544129480",
        "inputStages": [
          "0"
        ],
        "waitRatioAvg": 0.44,
        "waitMsAvg": "11",
        "waitRatioMax": 0.44,
        "waitMsMax": "11",
        "readRatioAvg": 0,
        "readMsAvg": "0",
        "readRatioMax": 0,
        "readMsMax": "0",
        "computeRatioAvg": 0.2,
        "computeMsAvg": "5",
        "computeRatioMax": 0.2,
        "computeMsMax": "5",
        "writeRatioAvg": 0.16,
        "writeMsAvg": "4",
        "writeRatioMax": 0.16,
        "writeMsMax": "4",
        "shuffleOutputBytes": "17",
        "shuffleOutputBytesSpilled": "0",
        "recordsRead": "1",
        "recordsWritten": "1",
        "parallelInputs": "1",
        "completedParallelInputs": "1",
        "status": "COMPLETE",
        "steps": [
          {
            "kind": "READ",
            "substeps": [
              "$20, $21",
              "FROM __stage00_output"
            ]
          },
          {
            "kind": "AGGREGATE",
            "substeps": [
              "$10 := SUM_OF_COUNTS($20)",
              "$11 := SUM_OF_COUNTS($21)"
            ]
          },
          {
            "kind": "WRITE",
            "substeps": [
              "$10, $11",
              "TO __stage01_output"
            ]
          }
        ]
      }
    ],
    "estimatedBytesProcessed": "2464625",
    "timeline": [
      {
        "elapsedMs": "304",
        "totalSlotMs": "50",
        "pendingUnits": "0",
        "completedUnits": "2"
      }
    ],
    "totalPartitionsProcessed": "0",
    "totalBytesProcessed": "2464625",
    "totalBytesBilled": "10485760",
    "billingTier": 1,
    "totalSlotMs": "50",
    "cacheHit": false,
    "referencedTables": [
      {
        "projectId": "publicdata",
        "datasetId": "samples",
        "tableId": "shakespeare"
      }
    ],
    "statementType": "SELECT"
  },
  "totalSlotMs": "50"
},

Menggunakan informasi eksekusi

Paket kueri BigQuery memberikan informasi tentang cara layanan mengeksekusi kueri, tetapi sifat layanan yang terkelola membatasi bisa tidaknya beberapa detail ditindaklanjuti secara langsung. Banyak pengoptimalan terjadi secara otomatis dengan menggunakan layanan ini, yang dapat berbeda dengan lingkungan lain karena penyesuaian, penyediaan, dan pemantauan dapat memerlukan staf khusus yang berpengetahuan luas.

Untuk mengetahui teknik tertentu yang dapat meningkatkan eksekusi dan performa kueri, lihat dokumentasi praktik terbaik. Statistik linimasa dan paket kueri dapat membantu Anda memahami apakah tahap tertentu mendominasi penggunaan resource. Misalnya, stage JOIN yang menghasilkan baris output yang jauh lebih banyak daripada baris input dapat mengindikasikan peluang untuk memfilter lebih awal dalam kueri.

Selain itu, informasi linimasa dapat membantu mengidentifikasi apakah kueri tertentu lambat secara terpisah atau karena efek dari kueri lain yang menangani resource yang sama. Jika Anda mengamati bahwa jumlah unit aktif tetap terbatas selama masa aktif kueri, tetapi jumlah unit tugas yang diantrekan tetap tinggi, hal ini dapat mewakili kasus ketika pengurangan jumlah kueri serentak dapat secara signifikan meningkatkan waktu eksekusi secara keseluruhan untuk kueri tertentu.