Amazon Redshift tidak akan lagi mendukung pembuatan Python UDFs baru mulai Patch 198. Python yang ada UDFs akan terus berfungsi hingga 30 Juni 2026. Untuk informasi lebih lanjut, lihat [posting blog](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/).
Terjemahan disediakan oleh mesin penerjemah. Jika konten terjemahan yang diberikan bertentangan dengan versi bahasa Inggris aslinya, utamakan versi bahasa Inggris.
# Prioritas kueri
Dengan Amazon Redshift, Anda dapat mengelola prioritas kueri dan alokasi sumber daya di seluruh kueri dan beban kerja bersamaan menggunakan Manajemen Beban Kerja (WM). Bagian berikut merinci cara mengonfigurasi antrian kueri WM, menentukan properti antrian seperti alokasi memori dan penskalaan konkurensi, dan menerapkan aturan prioritas yang disesuaikan dengan persyaratan beban kerja Anda.
Tidak semua kueri sama pentingnya, dan seringkali kinerja satu beban kerja atau kumpulan pengguna mungkin lebih penting. Jika Anda telah mengaktifkan [WLM otomatis](automatic-wlm.md), Anda dapat menentukan kepentingan relatif kueri dalam beban kerja dengan menetapkan nilai prioritas. Prioritas ditentukan untuk antrian dan diwarisi oleh semua kueri yang terkait dengan antrian. Anda mengaitkan kueri ke antrian dengan memetakan grup pengguna dan grup kueri ke antrian. Anda dapat mengatur prioritas berikut (terdaftar dari prioritas tertinggi ke terendah):
1. `HIGHEST`
1. `HIGH`
1. `NORMAL`
1. `LOW`
1. `LOWEST`
Administrator menggunakan prioritas ini untuk menunjukkan kepentingan relatif beban kerja mereka ketika ada kueri dengan prioritas berbeda yang bersaing untuk sumber daya yang sama. Amazon Redshift menggunakan prioritas saat membiarkan kueri masuk ke sistem, dan untuk menentukan jumlah sumber daya yang dialokasikan ke kueri. Secara default, kueri dijalankan dengan prioritasnya disetel ke`NORMAL`.
Prioritas tambahan,`CRITICAL`, yang merupakan prioritas lebih tinggi daripada`HIGHEST`, tersedia untuk pengguna super. Untuk menetapkan prioritas ini, Anda dapat menggunakan fungsi[CHANGE\$1QUERY\$1PRIORITY](r_CHANGE_QUERY_PRIORITY.md),[CHANGE\$1SESSION\$1PRIORITY](r_CHANGE_SESSION_PRIORITY.md). dan[CHANGE\$1USER\$1PRIORITY](r_CHANGE_USER_PRIORITY.md). Untuk memberikan izin pengguna database untuk menggunakan fungsi ini, Anda dapat membuat prosedur tersimpan dan memberikan izin kepada pengguna. Sebagai contoh, lihat [CHANGE\$1SESSION\$1PRIORITY](r_CHANGE_SESSION_PRIORITY.md).
**catatan**
Hanya satu `CRITICAL` kueri yang dapat dijalankan pada satu waktu.
Rollback selalu berjalan sebagai prioritas KRITIS.
Mari kita ambil contoh di mana prioritas beban kerja ekstrak, transformasi, beban (ETL) lebih tinggi daripada prioritas beban kerja analitik. Beban kerja ETL berjalan setiap enam jam, dan beban kerja analitik berjalan sepanjang hari. Ketika hanya beban kerja analitik yang berjalan di cluster, itu membuat seluruh sistem menjadi dirinya sendiri, menghasilkan throughput tinggi dengan pemanfaatan sistem yang optimal. Namun, ketika beban kerja ETL dimulai, ia mendapat hak karena memiliki prioritas yang lebih tinggi. Kueri yang berjalan sebagai bagian dari beban kerja ETL mendapatkan hak selama penerimaan dan juga alokasi sumber daya preferensial setelah diterima. Akibatnya, beban kerja ETL dapat diprediksi terlepas dari apa lagi yang mungkin berjalan pada sistem. Dengan demikian, ini memberikan kinerja yang dapat diprediksi dan kemampuan bagi administrator untuk memberikan perjanjian tingkat layanan (SLAs) untuk pengguna bisnis mereka.
Dalam klaster tertentu, kinerja yang dapat diprediksi untuk beban kerja prioritas tinggi datang dengan mengorbankan beban kerja prioritas lain yang lebih rendah. Beban kerja prioritas yang lebih rendah mungkin berjalan lebih lama karena kueri mereka menunggu di belakang kueri yang lebih penting untuk diselesaikan. Atau mereka mungkin berjalan lebih lama karena mereka mendapatkan sebagian kecil sumber daya ketika mereka berjalan bersamaan dengan kueri prioritas yang lebih tinggi. Kueri prioritas yang lebih rendah tidak menderita kelaparan, melainkan terus membuat kemajuan dengan kecepatan yang lebih lambat.
Pada contoh sebelumnya, administrator dapat mengaktifkan [penskalaan konkurensi untuk beban kerja analitik](concurrency-scaling.md). Melakukan hal ini memungkinkan beban kerja untuk mempertahankan throughputnya, meskipun beban kerja ETL berjalan pada prioritas tinggi.
## Mengkonfigurasi prioritas antrian
Jika Anda telah mengaktifkan WLM otomatis, setiap antrian memiliki nilai prioritas. Kueri diarahkan ke antrian berdasarkan grup pengguna dan grup kueri. Mulailah dengan prioritas antrian yang disetel ke`NORMAL`. Tetapkan prioritas yang lebih tinggi atau lebih rendah berdasarkan beban kerja yang terkait dengan grup pengguna dan grup kueri antrian.
Anda dapat mengubah prioritas antrian di konsol Amazon Redshift. **Di konsol Amazon Redshift, halaman **Manajemen Beban Kerja** menampilkan antrian dan memungkinkan pengeditan properti antrian seperti Prioritas.** Untuk menetapkan prioritas menggunakan operasi CLI atau API, gunakan parameter. `wlm_json_configuration` Untuk informasi selengkapnya, lihat [Mengonfigurasi Manajemen Beban Kerja di Panduan Manajemen](https://docs.aws.amazon.com/redshift/latest/mgmt/workload-mgmt-config.html) *Amazon Redshift*.
`wlm_json_configuration`Contoh berikut mendefinisikan tiga kelompok pengguna (`ingest`,`reporting`, dan`analytics`). Kueri yang dikirimkan dari pengguna dari salah satu grup ini berjalan dengan prioritas`highest`,`normal`, dan`low`, masing-masing.
```
[
{
"user_group": [
"ingest"
],
"priority": "highest",
"queue_type": "auto"
},
{
"user_group": [
"reporting"
],
"priority": "normal",
"queue_type": "auto"
},
{
"user_group": [
"analytics"
],
"priority": "low",
"queue_type": "auto",
"auto_wlm": true
}
]
```
## Mengubah prioritas kueri dengan aturan pemantauan kueri
Aturan pemantauan kueri (QMR) memungkinkan Anda mengubah prioritas kueri berdasarkan perilakunya saat sedang berjalan. Anda melakukan ini dengan menentukan atribut prioritas dalam predikat QMR selain tindakan. Untuk informasi selengkapnya, lihat [Aturan pemantauan kueri WLM](cm-c-wlm-query-monitoring-rules.md).
Misalnya, Anda dapat menentukan aturan untuk membatalkan kueri apa pun yang diklasifikasikan sebagai `high` prioritas yang berjalan selama lebih dari 10 menit.
```
"rules" :[
{
"rule_name":"rule_abort",
"predicate":[
{
"metric_name":"query_cpu_time",
"operator":">",
"value":600
},
{
"metric_name":"query_priority",
"operator":"=",
"value":"high"
}
],
"action":"abort"
}
]
```
Contoh lain adalah mendefinisikan aturan untuk mengubah prioritas kueri untuk kueri apa pun dengan prioritas saat ini `normal` yang menumpahkan lebih dari 1 TB ke disk. `lowest`
```
"rules":[
{
"rule_name":"rule_change_priority",
"predicate":[
{
"metric_name":"query_temp_blocks_to_disk",
"operator":">",
"value":1000000
},
{
"metric_name":"query_priority",
"operator":"=",
"value":"normal"
}
],
"action":"change_query_priority",
"value":"lowest"
}
]
```
## Memantau prioritas kueri
Untuk menampilkan prioritas untuk menunggu dan menjalankan kueri, lihat `query_priority` kolom dalam tabel sistem stv\$1wlm\$1query\$1state.
```
query | service_cl | wlm_start_time | state | queue_time | query_priority
---------+------------+----------------------------+------------------+------------+----------------
2673299 | 102 | 2019-06-24 17:35:38.866356 | QueuedWaiting | 265116 | Highest
2673236 | 101 | 2019-06-24 17:35:33.313854 | Running | 0 | Highest
2673265 | 102 | 2019-06-24 17:35:33.523332 | Running | 0 | High
2673284 | 102 | 2019-06-24 17:35:38.477366 | Running | 0 | Highest
2673288 | 102 | 2019-06-24 17:35:38.621819 | Running | 0 | Highest
2673310 | 103 | 2019-06-24 17:35:39.068513 | QueuedWaiting | 62970 | High
2673303 | 102 | 2019-06-24 17:35:38.968921 | QueuedWaiting | 162560 | Normal
2673306 | 104 | 2019-06-24 17:35:39.002733 | QueuedWaiting | 128691 | Lowest
```
Untuk mencantumkan prioritas kueri untuk kueri yang diselesaikan, lihat `query_priority` kolom di tabel sistem stl\$1wlm\$1query.
```
select query, service_class as svclass, service_class_start_time as starttime, query_priority
from stl_wlm_query order by 3 desc limit 10;
```
```
query | svclass | starttime | query_priority
---------+---------+----------------------------+----------------------
2723254 | 100 | 2019-06-24 18:14:50.780094 | Normal
2723251 | 102 | 2019-06-24 18:14:50.749961 | Highest
2723246 | 102 | 2019-06-24 18:14:50.725275 | Highest
2723244 | 103 | 2019-06-24 18:14:50.719241 | High
2723243 | 101 | 2019-06-24 18:14:50.699325 | Low
2723242 | 102 | 2019-06-24 18:14:50.692573 | Highest
2723239 | 101 | 2019-06-24 18:14:50.668535 | Low
2723237 | 102 | 2019-06-24 18:14:50.661918 | Highest
2723236 | 102 | 2019-06-24 18:14:50.643636 | Highest
```
Untuk mengoptimalkan throughput beban kerja Anda, Amazon Redshift dapat mengubah prioritas kueri yang dikirimkan pengguna. Amazon Redshift menggunakan algoritme pembelajaran mesin canggih untuk menentukan kapan pengoptimalan ini menguntungkan beban kerja Anda dan menerapkannya secara otomatis ketika semua kondisi berikut terpenuhi.
+ WLM otomatis diaktifkan.
+ Hanya satu antrian WLM yang ditentukan.
+ Anda belum menentukan aturan pemantauan kueri (QMRs) yang menetapkan prioritas kueri. Aturan tersebut termasuk metrik QMR `query_priority` atau tindakan QMR. `change_query_priority` Untuk informasi selengkapnya, lihat [Aturan pemantauan kueri WLM](cm-c-wlm-query-monitoring-rules.md).