Praktik terbaik untuk mengelola sumber daya komputasi - Hologres

Topik ini menjelaskan praktik terbaik untuk mengelola sumber daya komputasi Hologres, membantu Anda menangani permintaan baca dan tulis yang kompleks dan beragam secara efisien, cerdas, serta hemat biaya.

Latar Belakang

Di perusahaan e-commerce, data dikelola oleh tim data dan digunakan oleh analis serta tim rekomendasi. Tim data bertanggung jawab atas pemrosesan data dan menyediakan data kepada berbagai konsumen di seluruh perusahaan. Tabel berikut menggambarkan tugas bisnis dan karakteristik setiap tim.

Tim	Tanggung Jawab	Tugas	Karakteristik
Tim Data	Bertanggung jawab atas penulisan dan pemrosesan data untuk semua tim bisnis, termasuk data ETL real-time, hampir real-time, dan batch.	ETL Real-time dan Hampir Real-time: Mengambil data ke Lapisan Operational Data Store (ODS) secara real-time dengan Flink atau DataWorks Data Integration. Memproses data secara real-time pada lapisan Data Warehouse Detail (DWD) dan Data Warehouse Service (DWS) dengan Flink. Memproses data secara hampir real-time pada lapisan DWD dan DWS dengan Hologres Dynamic Table. ETL Batch: Mereplikasi data ke lapisan ODS setiap hari dengan MaxCompute. Memproses data pada lapisan DWD dan DWS setiap hari dengan Hologres.	ETL Real-time atau Hampir Real-time: Beban kerja puncak terjadi pada malam hari. ETL Batch: Dijadwalkan berjalan pada waktu tetap di pagi hari setiap hari. Ini melibatkan transformasi tabel besar dan kecil.
Analis Data	Analisis data penjualan untuk berbagai peran, seperti staf operasional, staf outlet, dan staf penjualan.	Mengembangkan dan menggunakan dasbor data BI, di mana peran berbeda meminta dasbor dengan tingkat akses data yang bervariasi. Mengaktifkan analitik swalayan untuk staf operasional.	Trafik kueri pada dasbor BI biasanya mencapai puncaknya selama jam kerja tetapi dapat melonjak secara tak terduga di malam hari. Permintaan analitik swalayan dapat menciptakan overhead tinggi. Overhead dari kueri dasbor data berbeda-beda. Peran berbeda memiliki persyaratan performa yang berbeda saat meminta data dasbor.
Tim Rekomendasi	Rekomendasi produk personalisasi	Rekomendasi Real-time: Mengambil fitur pengguna berdasarkan kunci utama dan menyesuaikan rekomendasi untuk pengguna menggunakan algoritma rekomendasi.	Trafik dari pengguna di platform e-commerce puncak setiap malam.

Prinsip Optimasi

Untuk beban kerja yang stabil, cukup memesan sumber daya komputasi khusus. Namun, dalam kasus penggunaan dunia nyata, beban kerja bisa sangat konkuren, memiliki jam puncak, atau sangat tinggi. Hal ini dapat menghabiskan sumber daya komputasi dan memengaruhi stabilitas instans. Dalam hal ini, gunakan pohon keputusan berikut untuk memilih solusi optimasi sumber daya.

Gunakan Komputasi Tanpa Server untuk beban kerja yang sangat besar, seperti pengisian ulang data masif, pemindaian tabel penuh tanpa filter, operasi join kompleks dengan lebih dari 10 tabel, dan beberapa subkueri bersarang. Hal ini menghindari gangguan terhadap kueri lain yang berjalan pada instans. Untuk tugas-tugas tersebut, kami merekomendasikan mengaktifkan komputasi tanpa server adaptif.
Permintaan yang dioptimalkan oleh Fixed Plan tidak mendukung eksekusi menggunakan Komputasi Tanpa Server atau Antrian Kueri. Oleh karena itu, Anda harus menangani beban kerja puncak permintaan ini dengan memperbesar gudang virtual, tetapi perhatikan bahwa lonjakan penulisan tidak dapat ditangani oleh elastisitas otomatis gudang virtual.
Untuk permintaan lain, pilih solusi berdasarkan kebutuhan performa, jam puncak, dan jenis permintaan.
Saat menggunakan Komputasi Tanpa Server, lihat Tantangan dan Solusi Manajemen Sumber Daya untuk memilih solusi yang sesuai.

Tantangan dan solusi manajemen sumber daya

Bagian ini merekomendasikan solusi optimal untuk titik-titik sakit bisnis berikut.

Tantangan 1: Persaingan sumber daya dan interferensi timbal balik antara tim yang berbeda

Deskripsi: Tugas ETL data dan kueri dapat bersaing untuk sumber daya komputasi dan saling mengganggu.

Solusi: Gunakan instans Hologres dengan beberapa gudang virtual untuk menerapkan isolasi beban kerja di antara tim yang berbeda. Lihat Arsitektur Instans Gudang Virtual. Contoh:

Gudang virtual utama (init_warehouse): Digunakan oleh tim data untuk penulisan data dan ETL.
Gudang virtual read-only 1: Digunakan oleh tim analitik.
Gudang virtual read-only 2: Digunakan oleh tim rekomendasi.

Tantangan 2: Jam puncak tetap

Gunakan penjadwalan penskalaan (beta) untuk meningkatkan atau menurunkan skala gudang virtual pada waktu yang dijadwalkan. Jika Anda memerlukan ekspansi sumber daya kurang dari 16 jam per hari, penjadwalan penskalaan menghemat biaya dibandingkan hanya menggunakan sumber daya khusus (cadangan). Contoh:

ETL Real-time:
- Karena tugas-tugas ini dioptimalkan melalui Fixed Plan, Anda hanya dapat menangani jam puncak dengan meningkatkan skala gudang virtual.
- Aktifkan penjadwalan penskalaan untuk gudang virtual utama untuk menangani jam puncak.
Analitik Data: Konfigurasikan penjadwalan penskalaan untuk gudang virtual read-only berdasarkan karakteristik puncak trafik (jam kerja siang hari).
Rekomendasi Real-time:
- Tugas-tugas ini adalah kueri poin yang dioptimalkan oleh Fixed Plan. Oleh karena itu, Anda hanya dapat menaikkan skala gudang virtual untuk menangani lonjakan beban kerja.
- Karena puncak trafik terjadi pada malam hari, konfigurasikan penjadwalan penskalaan untuk gudang virtual read-only untuk meningkatkan sumber daya komputasi di malam hari.

Tantangan 3: Tugas besar sering menyebabkan kesalahan OOM dan menempati sumber daya untuk waktu lama, mempengaruhi tugas lain

Skenario berikut mungkin melibatkan tugas besar:

ETL Batch: Tugas tunggal biasanya membutuhkan sejumlah besar sumber daya. Tugas itu sendiri rentan terhadap kesalahan OOM dan dapat menempati sumber daya komputasi untuk waktu yang lama, memblokir tugas lain.
- Solusi 1 (memprioritaskan stabilitas): Jalankan semua tugas ETL batch menggunakan sumber daya komputasi tanpa server. Anda dapat mengonfigurasi ini pada level SQL atau pengguna. Lihat Gunakan Sumber Daya Komputasi Tanpa Server untuk Mengeksekusi Tugas Baca dan Tulis.
- Solusi 2 (menyeimbangkan stabilitas dan biaya): Jika tugas ETL batch berukuran bervariasi, jalankan tugas kecil menggunakan gudang virtual utama dan tugas besar menggunakan Komputasi Tanpa Server.
ETL Hampir Real-time dengan Tabel Dinamis: Tugas pembaruan bertahap dieksekusi untuk setiap tabel setiap menit. Jumlah komputasi yang diperlukan untuk suatu tugas terkait dengan jumlah data inkremental, yang bisa tidak stabil.
- Solusi 1 (memprioritaskan stabilitas): Jalankan semua tugas ETL ini menggunakan sumber daya komputasi tanpa server. Lihat CREATE DYNAMIC TABLE.
- Solusi 2 (menyeimbangkan stabilitas dan biaya): Eksekusi tugas pembaruan untuk tabel besar atau tabel dengan fluktuasi volume data signifikan menggunakan Komputasi Tanpa Server. Jalankan tugas lain menggunakan gudang virtual utama.
Dasbor BI untuk analitik data: Ada banyak dasbor data, dan ukuran tugas bervariasi. Tugas besar dapat menempati sumber daya komputasi untuk waktu yang lama, memblokir tugas kecil.
- Solusi 1 (menyeimbangkan stabilitas, biaya, dan upaya pengembangan): Aktifkan Komputasi Tanpa Server Adaptif pada level database atau pengguna. Ini secara otomatis mengarahkan tugas besar untuk menggunakan sumber daya komputasi tanpa server, sementara tugas kecil tetap ada di gudang virtual read-only.
- Solusi 2 (menyeimbangkan stabilitas dan biaya): Ekstrak sidik jari SQL dari tugas besar dari dasbor data, buat antrian kueri, dan konfigurasikan semua permintaan dalam antrian kueri ini untuk berjalan pada sumber daya komputasi tanpa server. Untuk mengimplementasikan solusi ini, lakukan hal berikut:
  1. Uji dasbor data untuk memastikan bahwa Hologres mengeksekusi semua permintaan dari dasbor.
  2. Dalam log kueri lambat Hologres, filter tugas besar menggunakan bidang cpu_time_ms dan ekstrak bidang digest, yaitu sidik jari SQL. Untuk informasi lebih lanjut, lihat Kueri dan Analisis Log Kueri Lambat.
  3. Buat antrian kueri untuk tugas besar menggunakan sidik jari SQL mereka. Untuk informasi lebih lanjut, lihat Konfigurasikan Aturan Pencocokan Klasifikasi.
  4. Konfigurasikan semua permintaan dalam antrian kueri ini untuk berjalan pada sumber daya komputasi tanpa server. Untuk informasi lebih lanjut, lihat Gunakan Sumber Daya Komputasi Tanpa Server untuk Mengeksekusi Kueri dalam Antrian Kueri.
- Solusi 3 (memprioritaskan penghematan biaya): Prioritaskan menjalankan semua kueri di gudang virtual. Pada saat yang sama, aktifkan auto-rerun kueri besar untuk antrian kueri. Ini menggunakan sumber daya komputasi tanpa server untuk menjalankan ulang kueri yang habis waktu dan OOM. Pengguna tidak menyadari timeout atau kesalahan OOM. Untuk informasi lebih lanjut, lihat Kontrol Kueri Besar.

Tantangan 4: Tugas besar tiba-tiba sepenuhnya menempati kolam sumber daya, mempengaruhi stabilitas sistem

Tugas analitik sporadis dapat menciptakan overhead tiba-tiba dan tinggi, mempengaruhi stabilitas instans.

Solusi 1 (memprioritaskan stabilitas): Konfigurasikan semua permintaan analitik ad-hoc untuk berjalan pada Komputasi Tanpa Server di level pengguna. Untuk informasi lebih lanjut, lihat Konfigurasikan di Level Pengguna.
Solusi 2 (menyeimbangkan stabilitas dan biaya): Aktifkan Komputasi Tanpa Server Adaptif di level pengguna. Ini secara otomatis mengarahkan tugas besar yang dimulai oleh pengguna ke sumber daya tanpa server, sementara tugas kecil terus berjalan di gudang virtual.
Solusi 3 (memprioritaskan penghematan biaya): Prioritaskan menjalankan semua permintaan di gudang virtual. Pada saat yang sama, aktifkan rerun otomatis untuk kueri besar untuk antrian kueri. Ini menggunakan sumber daya komputasi tanpa server untuk menjalankan ulang kueri yang habis waktu dan OOM. Pengguna tidak menyadari timeout atau kesalahan OOM. Untuk informasi lebih lanjut, lihat Kontrol Kueri Besar.

Tantangan 5: Persyaratan kesegaran data dan stabilitas yang berbeda

Dasbor BI diminta oleh berbagai peran di seluruh perusahaan, seperti pengembang data, staf operasional, staf penjualan, dan manajemen senior. Tujuan akses mereka juga bervariasi, termasuk demonstrasi pelanggan atau tampilan internal.

Kebutuhan performa tinggi:
- Solusi 1 (memrioritaskan stabilitas): Jika beban kerja stabil, buat gudang virtual terpisah untuk menangani permintaan.
- Solusi 2 (menyeimbangkan stabilitas dan biaya): Jalankan semua permintaan menggunakan Komputasi Tanpa Server, atau gunakan fitur Komputasi Tanpa Server Adaptif.
Latensi dapat ditoleransi:
- Jika jenis permintaan untuk dasbor data tetap (misalnya, sebuah peran secara konsisten mengakses dasbor tertentu), konfigurasikan pembatasan kecepatan secara manual. Pertama, lakukan uji stres untuk menentukan kapasitas baca gudang virtual. Kemudian, konfigurasikan batas konkurensi tetap untuk antrian kueri. Untuk informasi lebih lanjut, lihat Buat Antrian Kueri.
- Jika jenis permintaan tidak tetap (misalnya, beberapa dasbor diakses oleh peran berbeda), aktifkan pembatasan kecepatan otomatis. Hologres secara otomatis menyesuaikan batas konkurensi antrian kueri berdasarkan beban kerja. Untuk informasi lebih lanjut, lihat Pembatasan Kecepatan Otomatis (Beta).

Tantangan 6: Lonjakan permintaan tak terduga memengaruhi stabilitas instans

Lonjakan kueri tak terduga di malam hari menjadi tantangan. Komputasi tanpa server tidak dapat menanganinya karena pengguna, tabel, dan pernyataan SQL-nya tidak diketahui. Penjadwalan penskalaan tidak efektif terhadap lonjakan yang tidak dapat diprediksi.

Solusi: Aktifkan penyesuaian skala otomatis. Fitur ini memungkinkan gudang virtual secara otomatis memperluas kapasitas saat beban puncak dan memperkecil kapasitas saat permintaan menurun. Untuk detailnya, lihat Multi-kuster dan Penyesuaian Skala Otomatis (Beta).

Pengaturan Lanjutan

Konfigurasikan prioritas tugas untuk Komputasi Tanpa Server

Jika beberapa layanan menggunakan Komputasi Tanpa Server, konfigurasikan prioritas untuk permintaan mereka di level pengguna. Untuk informasi lebih lanjut, lihat Atur Prioritas untuk Tugas Komputasi Tanpa Server. Contoh:

Permintaan kueri dari peran dengan kebutuhan performa tinggi: Atur prioritas ke 5. Permintaan ini dieksekusi pertama kali ketika sumber daya tanpa server langka.
Tugas ETL batch: Atur prioritas ke 1. Tugas ini menunggu dalam antrian ketika sumber daya tanpa server langka.
Tugas lain: Gunakan prioritas default 3.

Konfigurasikan kuota harian untuk Komputasi Tanpa Server

Jika beberapa layanan dapat menggunakan Komputasi Tanpa Server, biayanya mungkin tidak terduga tinggi. Dalam hal ini, konfigurasikan kuota harian sumber daya komputasi tanpa server untuk instans. Anda juga dapat mengonfigurasi kuota sumber daya untuk pengguna yang berbeda. Ini membantu Anda menggunakan sumber daya komputasi tanpa server secara fleksibel dan hemat biaya. Lihat Batas Penggunaan Kumulatif Harian.

Aktifkan ketersediaan tinggi untuk gudang virtual read-only

Untuk gudang virtual read-only, terutama yang menangani layanan rekomendasi online, konfigurasikan beberapa replika tingkat shard. Ini memastikan kueri tanpa kehilangan data ketika node kueri gagal. Untuk informasi lebih lanjut, lihat Replikasi Tingkat Shard untuk Instans Hologres.