AnalyticDB:Pengembangan SQL XIHE BSP

Prasyarat

• Kelompok sumber daya pekerjaan telah dibuat untuk kluster Enterprise Edition, Basic Edition, atau Data Lakehouse Edition AnalyticDB for MySQL.

• Akun database telah dibuat untuk kluster Enterprise Edition, Basic Edition, atau Data Lakehouse Edition AnalyticDB for MySQL.

Skenario

Pekerjaan SQL XIHE BSP dieksekusi oleh mesin XIHE BSP dan cocok untuk skenario extract, transform, and load (ETL), kueri besar, serta lonjakan kueri prioritas rendah. Untuk informasi lebih lanjut mengenai mesin XIHE BSP, lihat Compute engines.

Skenario ETL

Alur ETL khas ditunjukkan pada gambar berikut.

Operasi seperti pembersihan dan transformasi data dari sumber data ke lapisan Application Data Service (ADS) biasanya memakan waktu lama dan melibatkan volume data yang besar. Dalam skenario ini, waktu respons kueri bukanlah faktor utama. Namun, keandalan sangat penting, dan sistem harus mendukung fitur seperti retry otomatis. Anda dapat mengeksekusi kueri ini dalam mode XIHE BSP untuk memanfaatkan throughput tinggi, keandalan yang ditingkatkan, serta biaya lebih rendah dari mesin XIHE BSP.

Untuk kueri pada lapisan ADS, waktu respons kueri merupakan faktor yang lebih kritis dan sering kali diharapkan berada pada tingkat detik bahkan milidetik. Anda dapat mengeksekusi kueri ini dalam mode XIHE Massively Parallel Processing (MPP) untuk memanfaatkan kecepatan tinggi mesin XIHE MPP.

Kueri besar yang tidak dapat dieksekusi dalam mode XIHE MPP

Karena keterbatasan mode eksekusi XIHE MPP, beberapa kueri yang melibatkan volume data besar dapat menyebabkan error memori atau exception kueri lainnya. Untuk menjalankan kueri ini dalam mode XIHE MPP, Anda harus melakukan operasi seperti scale-out untuk menambahkan lebih banyak resource, yang tidak efisien dari segi biaya. Dalam skenario ini, Anda dapat menjalankan kueri dalam mode XIHE BSP. Kueri dieksekusi dalam kelompok sumber daya pekerjaan tertentu dan data ditulis ke disk. Metode ini lebih sesuai untuk kueri besar. Selain itu, sumber daya untuk kelompok sumber daya pekerjaan diminta dan dibayar sesuai kebutuhan, sehingga pendekatan ini lebih hemat biaya.

Burst kueri prioritas rendah

Waktu respons biasanya bukan faktor kritis untuk kueri prioritas rendah. Namun, sifat lonjakannya dapat menyebabkan kekurangan sumber daya sistem, yang berpotensi memengaruhi eksekusi kueri lain. Dalam skenario ini, Anda dapat menempatkan kueri prioritas rendah tersebut dalam kelompok sumber daya pekerjaan untuk dijalankan dalam mode XIHE BSP. Pendekatan ini mengurangi tekanan pada sumber daya sistem dan mencegah gangguan antar kueri.

Batasan

• Anda tidak dapat menulis ke tabel Hudi dalam mode XIHE BSP.

• Anda tidak dapat membaca dari atau menulis ke tabel Delta dalam mode XIHE BSP.

Mengembangkan pekerjaan XIHE BSP

Anda dapat mengembangkan pekerjaan XIHE BSP dengan salah satu cara berikut.

/*+ resource_group=<resource_group_name>*/ <SQL Statement>;

/*+ resource_group=bsptest*/SELECT count(*) from test_db.ods_hudi;

/*+ resource_group=<resource_group_name>, query_submission_type=async*/ <SQL Statement>;

/*+ resource_group=bsptest, query_submission_type=async*/SELECT count(*) from test_db.ods_hudi;

Konfigurasi pekerjaan XIHE BSP

Anda dapat mengatur sumber daya, periode timeout default, dan prioritas untuk pekerjaan XIHE BSP.

Metode konfigurasi

Konfigurasi pekerjaan BSP dapat diterapkan untuk satu pekerjaan saja, semua pekerjaan dalam kelompok sumber daya pekerjaan, atau semua pekerjaan dalam kluster.

/*+ resource_group=bsptest,elastic_job_max_acu=20*/SELECT count(*) from test_db.ods_hudi;

SET adb_config bsptest.elastic_job_max_acu=20;

SET adb_config elastic_job_max_acu=20;

Item konfigurasi

Tabel berikut menjelaskan item konfigurasi yang didukung oleh pekerjaan XIHE BSP.

FAQ

Bagaimana cara memeriksa status pekerjaan BSP?

• Jika pekerjaan BSP dikirim dari editor pekerjaan, Anda dapat melihat statusnya pada tab Execution Records di bagian bawah halaman Job Editor > SQL Development.

• Jika pekerjaan BSP dikirim menggunakan metode lain, Anda dapat menanyakan tabel information_schema.kepler_meta_elastic_job_list. Contohnya:

  SELECT status FROM information_schema.kepler_meta_elastic_job_list WHERE process_id='<job_id>';

  Catatan

  Tabel information_schema.kepler_meta_elastic_job_list menyimpan informasi tentang 1.000 tugas BSP terakhir yang dikirim dalam 30 hari terakhir. Anda dapat melakukan analisis statistik lebih lanjut, seperti agregasi, pada tabel ini. Contoh berikut menunjukkan cara menghitung jumlah pekerjaan BSP dalam setiap status.

  SELECT status,count(*) FROM information_schema.kepler_meta_elastic_job_list GROUP BY status;

Bagaimana memilih antara pengiriman sinkron dan asinkron untuk pekerjaan BSP?

Tidak ada perbedaan fungsional antara pengiriman sinkron dan asinkron. Satu-satunya perbedaan adalah apakah klien perlu menunggu hingga kueri selesai.

Pengiriman asinkron direkomendasikan untuk kueri yang memakan waktu lama dan intensif komputasi tetapi menghasilkan set hasil kecil, seperti INSERT INTO SELECT, INSERT OVERWRITE SELECT, dan CREATE TABLE AS SELECT.