Share via

Klasifikasi beban kerja untuk kumpulan SQL khusus di Azure Synapse Analytics

  • Artikel

Artikel ini menjelaskan proses klasifikasi beban kerja untuk menetapkan grup beban kerja dan tingkat kepentingan, untuk permintaan masuk dengan kumpulan SQL khusus di Azure Synapse.

Klasifikasi

Klasifikasi manajemen beban kerja memungkinkan penerapan kebijakan beban kerja pada permintaan melalui penetapan kelas sumber daya dan tingkat kepentingan.

Meskipun ada banyak cara untuk mengklasifikasikan beban kerja pergudangan data, klasifikasi paling sederhana dan paling umum adalah beban dan kueri. Anda memuat data dengan menyisipkan, memperbarui, dan menghapus pernyataan. Anda mengkueri data menggunakan pilihan. Solusi pergudangan data sering kali membuat kebijakan beban kerja untuk aktivitas muatan, seperti menetapkan kelas sumber daya yang lebih tinggi dengan lebih banyak sumber daya. Kebijakan beban kerja yang berbeda dapat berlaku untuk kueri, seperti kepentingan yang lebih rendah dibandingkan dengan aktivitas muatan.

Anda juga dapat membuat subklasifikasi muatan dan kueri beban kerja Anda. Subklasifikasi memberi Anda lebih banyak kontrol atas beban kerja Anda. Misalnya, beban kerja kueri dapat terdiri dari refresh kubus, kueri dasbor, atau kueri ad-hoc. Anda dapat mengklasifikasikan setiap beban kerja kueri ini dengan pengaturan kelas atau kepentingan sumber daya yang berbeda. Beban juga dapat memperoleh keuntungan dari subklasifikasi. Transformasi besar dapat ditetapkan ke kelas sumber daya yang lebih besar. Kepentingan yang lebih tinggi dapat digunakan untuk memastikan data penjualan utama adalah pemuat sebelum data cuaca atau umpan data sosial.

Tidak semua pernyataan diklasifikasikan karena mereka tidak memerlukan sumber daya atau memerlukan kepentingan untuk mempengaruhi eksekusi. Perintah DBCC, pernyataan BEGIN, COMMIT, dan ROLLBACK TRANSACTION tidak diklasifikasikan.

Proses klasifikasi

Klasifikasi untuk kumpulan SQL khusus dicapai hari ini dengan menugaskan pengguna ke peran yang memiliki kelas sumber daya terkait yang ditetapkan ke pengguna menggunakan sp_addrolemember. Kemampuan untuk mengkarakterisasi permintaan di luar rincian masuk ke kelas sumber daya dibatasi dengan kemampuan ini. Sebuah metode yang lebih kaya untuk klasifikasi sekarang tersedia dengan sintaksis CREATE WORKLOAD CLASSIFIER. Dengan sintaksis ini, pengguna kumpulan SQL khusus dapat menetapkan kepentingan dan jumlah sumber daya sistem yang ditetapkan untuk permintaan melalui parameter workload_group.

Klasifikasi pembobotan

Sebagai bagian dari proses klasifikasi, pembobotan diberlakukan untuk menentukan grup beban kerja mana yang ditetapkan. Pembobotan berjalan sebagai berikut:

Parameter Penggolong Berat
MEMBERNAME:USER 64
MEMBERNAME:ROLE 32
WLM_LABEL 16
WLM_CONTEXT 8
START_TIME/END_TIME 4

Parameter membername bersifat wajib. Namun, jika nama anggota yang ditentukan adalah pengguna database alih-alih peran database, pembobotan untuk pengguna lebih tinggi dan dengan demikian penggolong dipilih.

Jika pengguna adalah anggota dari beberapa peran dengan kelas sumber daya yang berbeda yang ditetapkan atau dicocokkan di beberapa penggolong, pengguna akan diberikan tugas kelas sumber daya tertinggi. Perilaku ini konsisten dengan perilaku penugasan kelas sumber daya yang ada.

Catatan

Mengklasifikasikan perilaku identitas terkelola (MI) berbeda antara kumpulan SQL khusus di ruang kerja Azure Synapse dan kumpulan SQL khusus mandiri (sebelumnya SQL DW). Sementara MI kumpulan SQL khusus mandiri mempertahankan identitas yang ditetapkan, untuk ruang kerja Azure Synapse tempat MI dijalankan sebagai dbo. Tindakan ini tidak dapat diubah. Peran dbo, secara default, diklasifikasikan ke smallrc. Membuat pengklasifikasi untuk peran dbo memungkinkan untuk menetapkan permintaan ke grup beban kerja selain smallrc. Jika dbo saja terlalu umum untuk klasifikasi dan memiliki dampak yang lebih luas, pertimbangkan untuk menggunakan label, sesi, atau klasifikasi berbasis waktu dalam hubungannya dengan klasifikasi peran dbo.

Penggolong sistem

Klasifikasi beban kerja memiliki penggolong beban kerja sistem. Penggolong sistem memetakan keanggotaan peran kelas sumber daya yang ada ke alokasi sumber daya kelas sumber daya dengan tingkat kepentingan normal. Penggolong sistem tidak bisa dihilangkan. Untuk melihat penggolong sistem, Anda dapat menjalankan kueri di bawah ini:

SELECT * FROM sys.workload_management_workload_classifiers where classifier_id <= 12

Mencampur penugasan kelas sumber daya dengan penggolong

Penggolong sistem yang dibuat atas nama Anda, menyediakan jalur mudah untuk bermigrasi ke klasifikasi beban kerja. Menggunakan pemetaan peran kelas sumber daya dengan prioritas klasifikasi, dapat menyebabkan kesalahan klasifikasi saat Anda mulai membuat penggolong baru dengan tingkat kepentingan.

Pertimbangkan skenario berikut:

  • Gudang data yang ada memiliki pengguna database DBAUser yang ditetapkan ke peran kelas sumber daya yang lebih besar. Penugasan kelas sumber daya dilakukan dengan sp_addrolemember.
  • Gudang data sekarang diperbarui dengan manajemen beban kerja.
  • Untuk menguji sintaksis klasifikasi baru, peran database DBARole (di mana DBAUser adalah anggota), memiliki penggolong yang dibuat untuk memetakan mereka ke mediumrc dan sangat penting.
  • Saat DBAUser masuk dan menjalankan kueri, kueri akan ditetapkan ke largerc. Karena pengguna lebih diutamakan daripada keanggotaan peran.

Untuk menyederhanakan pemecahan masalah kesalahan klasifikasi, sebaiknya Hapus pemetaan peran kelas sumber daya saat Anda membuat penggolong beban kerja. Kode di bawah ini mengembalikan keanggotaan peran kelas sumber daya yang ada. Jalankan sp_droprolemember untuk setiap nama anggota yang dikembalikan dari kelas sumber daya yang sesuai.

SELECT  r.name AS [Resource Class]
,       m.name AS membername
FROM    sys.database_role_members rm
JOIN    sys.database_principals AS r ON rm.role_principal_id = r.principal_id
JOIN    sys.database_principals AS m ON rm.member_principal_id = m.principal_id
WHERE   r.name IN ('mediumrc','largerc','xlargerc','staticrc10','staticrc20','staticrc30','staticrc40','staticrc50','staticrc60','staticrc70','staticrc80');

--for each row returned run in the previous query
EXEC sp_droprolemember '[Resource Class]', membername;

Langkah berikutnya