Amazon Redshift tidak akan lagi mendukung penggunaan Python UDF setelah 30 Juni 2026. Kami akan mulai menegakkannya secara bertahap. Untuk informasi lebih lanjut tentang detail opsi akhir masa pakai dan migrasi Python, lihat posting blog yang diterbitkan pada 30 Juni 2025.

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, 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 (tercantum dari prioritas tertinggi ke terendah):

Administrator menggunakan prioritas ini untuk menunjukkan pentingnya 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 untuk kueri. Secara default, kueri berjalan dengan prioritasnya ditetapkan keNORMAL.

Prioritas tambahanCRITICAL,, yang merupakan prioritas lebih tinggi daripadaHIGHEST, tersedia untuk pengguna super. Untuk mengatur prioritas ini, Anda dapat menggunakan fungsiUBAH_KUERI_PRIORITAS,UBAH_PRIORITAS_SESI. danUBAH_PRIORITAS_PENGGUNA. Untuk memberikan izin pengguna database untuk menggunakan fungsi-fungsi ini, Anda dapat membuat prosedur tersimpan dan memberikan izin kepada pengguna. Sebagai contoh, lihat UBAH_PRIORITAS_SESI.

Mari kita ambil contoh di mana prioritas beban kerja ekstrak, transformasi, muat (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 mendapatkan seluruh sistem untuk dirinya sendiri, menghasilkan throughput tinggi dengan pemanfaatan sistem yang optimal. Namun, ketika beban kerja ETL dimulai, itu menjadi benar 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 bekerja secara dapat diprediksi terlepas dari apa lagi yang mungkin berjalan di sistem. Dengan demikian, ini memberikan kinerja yang dapat diprediksi dan kemampuan bagi administrator untuk memberikan perjanjian tingkat layanan (SLA) untuk pengguna bisnis mereka.

Dalam cluster tertentu, kinerja yang dapat diprediksi untuk beban kerja prioritas tinggi datang dengan mengorbankan beban kerja lain dengan prioritas lebih rendah. Beban kerja prioritas 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 fraksi sumber daya yang lebih kecil ketika mereka berjalan bersamaan dengan kueri prioritas yang lebih tinggi. Kueri prioritas rendah tidak menderita kelaparan, melainkan terus membuat kemajuan dengan kecepatan yang lebih lambat.

Dalam contoh sebelumnya, administrator dapat mengaktifkan penskalaan konkurensi untuk beban kerja analitik. Melakukan hal ini memungkinkan beban kerja tersebut mempertahankan throughput, meskipun beban kerja ETL berjalan dengan prioritas tinggi.

Mengkonfigurasi prioritas antrian

Jika Anda telah mengaktifkan WLM otomatis, setiap antrian memiliki nilai prioritas. Kueri dialihkan ke antrian berdasarkan grup pengguna dan grup kueri. Mulailah dengan prioritas antrian yang disetel keNORMAL. Tetapkan prioritas lebih tinggi atau lebih rendah berdasarkan beban kerja yang terkait dengan grup pengguna antrian dan grup kueri.

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 mengatur prioritas menggunakan operasi CLI atau API, gunakan wlm_json_configuration parameter. Untuk informasi selengkapnya, lihat Meng onfigurasi Manajemen B eban Kerja di Panduan Manajemen Amazon Redshift.

wlm_json_configurationContoh berikut mendefinisikan tiga grup pengguna (ingest,reporting, dananalytics). Kueri yang dikirimkan dari pengguna dari salah satu grup ini dijalankan dengan prioritas highestnormal,, danlow, 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

Dengan aturan pemantauan kueri (QMR), Anda dapat 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.

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 menentukan aturan untuk mengubah prioritas kueri lowest untuk setiap kueri dengan prioritas saat ini normal yang menumpahkan lebih dari 1 TB ke disk.

"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"
  }
]

Prioritas kueri pemantauan

Untuk menampilkan prioritas untuk menunggu dan menjalankan kueri, lihat query_priority kolom di tabel sistem stv_wlm_query_state.

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_wlm_query.

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 algoritma pembelajaran mesin tingkat lanjut untuk menentukan kapan pengoptimalan ini menguntungkan beban kerja Anda dan menerapkannya secara otomatis ketika semua kondisi berikut terpenuhi.