Perilaku penentuan ukuran, penskalaan, dan antrean gudang SQL
Artikel ini menjelaskan perilaku ukuran, antrean, dan penskalaan otomatis kluster gudang SQL.
Mengukur gudang SQL tanpa server
Selalu mulai dengan ukuran kaos yang lebih besar untuk gudang SQL tanpa server Anda daripada yang Anda pikir Akan Anda butuhkan dan turunkan ukurannya saat Anda menguji. Jangan mulai dengan ukuran t-shirt kecil untuk gudang SQL tanpa server Anda dan naik. Secara umum, mulailah dengan satu gudang SQL tanpa server dan andalkan Azure Databricks untuk ukuran yang tepat dengan kluster tanpa server, memprioritaskan beban kerja, dan bacaan data cepat. Lihat Penskalakan otomatis tanpa server dan antrean kueri.
- Untuk mengurangi latensi kueri untuk gudang SQL tanpa server tertentu:
- Jika kueri meluap ke disk, tingkatkan ukuran kaos.
- Jika kueri sangat paralel, tingkatkan ukuran kaos.
- Jika Anda menjalankan beberapa kueri sekaligus, tambahkan lebih banyak kluster untuk penskalaan otomatis.
- Untuk mengurangi biaya, cobalah untuk turun dalam ukuran t-shirt tanpa menumpahkan ke disk atau meningkatkan latensi secara signifikan.
- Untuk membantu menyesuaikan ukuran gudang SQL tanpa server Anda, gunakan alat berikut:
- Halaman pemantauan: lihat jumlah kueri puncak. Jika puncak antrean umumnya di atas satu, tambahkan kluster. Jumlah maksimum kueri dalam antrean untuk semua jenis gudang SQL adalah 1000. Lihat Memantau gudang SQL.
- Riwayat kueri. Lihat Riwayat kueri.
- Profil kueri (cari Byte yang ditumpahkan ke disk di atas 1). Lihat Profil Kueri.
Catatan
Untuk gudang SQL tanpa server, ukuran kluster mungkin dalam beberapa kasus menggunakan jenis instans yang berbeda dari yang tercantum dalam dokumentasi untuk gudang SQL pro dan klasik untuk ukuran kluster yang setara. Secara umum, rasio harga/performa ukuran kluster untuk gudang SQL tanpa server mirip dengan yang untuk gudang SQL pro dan klasik.
Penskalakan otomatis tanpa server dan antrean kueri
Intelligent Workload Management (IWM) adalah serangkaian fitur yang meningkatkan kemampuan gudang SQL tanpa server untuk memproses sejumlah besar kueri dengan cepat dan hemat biaya. Menggunakan kemampuan prediksi yang didukung AI untuk menganalisis kueri masuk dan menentukan IO tercepat dan lebih efisien (Prediktif IO), IWM berfungsi untuk memastikan bahwa beban kerja memiliki jumlah sumber daya yang tepat dengan cepat. Perbedaan utama terletak pada kemampuan AI di Databricks SQL untuk merespons tuntutan beban kerja secara dinamis daripada menggunakan ambang statis.
Respons ini memastikan:
- Peningkatan skala yang cepat untuk memperoleh lebih banyak komputasi ketika diperlukan untuk mempertahankan latensi rendah.
- Pengakuan kueri lebih dekat dengan batasan perangkat keras.
- Penurunan skala cepat untuk meminimalkan biaya ketika permintaan rendah, memberikan performa yang konsisten dengan biaya dan sumber daya yang dioptimalkan.
Ketika kueri tiba di gudang, IWM memprediksi biaya kueri. Pada saat yang sama, IWM secara real time memantau kapasitas komputasi gudang yang tersedia. Selanjutnya, menggunakan model pembelajaran mesin, IWM memprediksi apakah kueri masuk memiliki komputasi yang diperlukan yang tersedia pada komputasi yang ada. Jika tidak memiliki komputasi yang diperlukan, maka kueri ditambahkan ke antrean. Jika memang memiliki komputasi yang diperlukan, kueri akan segera mulai dijalankan.
IWM memantau antrean dipantau sekitar setiap 10 detik. Jika antrean tidak menurun cukup cepat, penskalaan otomatis dimulai untuk mendapatkan lebih banyak komputasi dengan cepat. Setelah kapasitas baru ditambahkan, kueri yang diantrekan dimasukkan ke kluster baru. Dengan gudang SQL tanpa server, kluster baru dapat ditambahkan dengan cepat, dan lebih dari satu kluster sekaligus dapat dibuat. Jumlah maksimum kueri dalam antrean untuk semua jenis gudang SQL adalah 1000.
Ukuran kluster untuk gudang SQL pro dan klasik
Tabel pada bagian ini akan memetakan SQL ukuran kluster gudang ke ukuran driver kluster Azure Databricks serta jumlah pekerja. Ukuran driver hanya berlaku untuk gudang SQL pro dan klasik.
| Ukuran kluster | Jenis instans untuk driver (hanya berlaku untuk gudang SQL pro dan klasik) | Jumlah pekerja |
|---|---|---|
| 2X-Kecil | Standard_E8ds_v4 | 1 x Standard_E8ds_v4 |
| X-Kecil | Standard_E8ds_v4 | 2 x Standard_E8ds_v4 |
| Bentuk dan | Standard_E16ds_v4 | 4 x Standard_E8ds_v4 |
| Medium | Standard_E32ds_v4 | 8 x Standard_E8ds_v4 |
| Bentuk dan | Standard_E32ds_v4 | 16 x Standard_E8ds_v4 |
| X-Besar | Standard_E64ds_v4 | 32 x Standard_E8ds_v4 |
| 2X-Besar | Standard_E64ds_v4 | 64 x Standard_E8ds_v4 |
| 3X-Besar | Standard_E64ds_v4 | 128 x Standard_E8ds_v4 |
| 4X-Besar | Standard_E64ds_v4 | 256 x Standard_E8ds_v4 |
Ukuran instans semua pekerja Standard_E8ds_v4.
Setiap driver dan pekerja memiliki delapan disk terkelola LRS Standar 128 GB yang terpasang. Disk terlampir diisi setiap jam.
Kuota Azure vCPU yang diperlukan untuk gudang SQL klasik dan pro
Untuk memulai gudang SQL klasik atau pro, Anda harus memiliki kuota Azure vCPU yang memadai untuk instans Standard_E8ds_v4 di akun Azure Anda. Gunakan panduan berikut untuk menentukan kuota vCPU yang diperlukan:
- Jika Anda hanya memiliki satu atau dua gudang SQL, pastikan Anda telah memiliki 8 Azure vCPU yang tersedia untuk setiap inti di kluster. Hal ini akan memastikan bahwa Anda memiliki Azure vCPU yang memadai untuk memperhitungkan penyediaan ulang gudang Anda, yang terjadi kira-kira setiap 24 jam. Jika gudang SQL Anda menggunakan penskalaan otomatis atau penyeimbangan beban multi-kluster, Anda mungkin harus meningkatkan pengali.
- Ketika jumlah gudang SQL meningkat, harap izinkan antara 4 dan 8 Azure vCPU untuk setiap inti dalam kluster. Databricks merekomendasikan untuk memulai dengan jumlah yang lebih besar dan pemantauan untuk stabilitas.
- Azure vCPU yang digunakan oleh gudang SQL adalah selain Azure vCPU yang digunakan oleh kluster yang digunakan oleh Ilmu Data & Teknik atau oleh beban kerja non-Databricks.
Untuk meminta tambahan kuota Azure vCPU, lihat Kuota standar: Meningkatkan batas menurut seri mesin virtual di dokumentasi Azure.
Catatan
Informasi dalam tabel ini dapat bervariasi berdasarkan ketersediaan produk atau wilayah dan jenis ruang kerja.
Antrean dan penskalaan otomatis untuk gudang SQL pro dan klasik
Azure Databricks akan membatasi jumlah kueri pada kluster yang ditetapkan ke gudang SQL berdasarkan biaya untuk menghitung hasilnya. Peningkatan kluster per gudang akan didasarkan pada throughput kueri, laju kueri yang masuk, dan ukuran antrean. Azure Databricks merekomendasikan kluster untuk setiap 10 kueri bersamaan. Jumlah maksimum kueri dalam antrean untuk semua jenis gudang SQL adalah 1000.
Azure Databricks menambahkan kluster berdasarkan waktu yang diperlukan untuk memproses semua kueri yang sedang berjalan, semua kueri yang diantrekan, dan kueri masuk yang diharapkan dalam dua menit ke depan.
- Jika kurang dari 2 menit, jangan melakukan upscale.
- Jika 2 hingga 6 menit, tambahkan 1 kluster.
- Jika 6 hingga 12 menit, tambahkan 2 kluster.
- Jika 12 hingga 22 menit, tambahkan 3 kluster.
Jika tidak, Azure Databricks menambahkan 3 kluster ditambah 1 kluster untuk setiap tambahan 15 menit beban kueri yang diharapkan.
Selain itu, gudang selalu ditingkatkan skalanya jika kueri menunggu selama 5 menit dalam antrean.
Jika beban bernilai rendah selama 15 menit, Azure Databricks akan menurunkan skala gudang SQL. Itu membuat cukup kluster untuk menangani beban puncak selama 15 menit terakhir. Misalnya, jika beban puncak adalah 25 kueri bersamaan, Azure Databricks menyimpan 3 kluster.
Antrean kueri untuk gudang SQL pro dan klasik
Azure Databricks akan mengantrekan kueri saat semua kluster yang ditetapkan ke gudang menjalankan kueri dengan kapasitas penuh atau saat gudang berada dalam status STARTING. Jumlah maksimum kueri dalam antrean untuk semua jenis gudang SQL adalah 1000.
Kueri metadata (misalnya, DESCRIBE <table>) serta kueri pengubahan status (misalnya SET) tidak pernah diantrekan, kecuali gudang berada dalam status STARTING.