Pengaturan gudang SQL untuk beban kerja BI

Beban kerja kecerdasan bisnis memiliki karakteristik berbeda yang memerlukan pertimbangan konfigurasi gudang SQL tertentu. Halaman ini memberikan panduan tentang menganalisis persyaratan beban kerja BI Anda dan mengonfigurasi gudang SQL untuk memberikan performa, efisiensi biaya, dan keandalan yang optimal.

Analisis beban kerja dan persyaratan SLA

Setiap beban kerja BI unik dan memerlukan analisis yang cermat sebelum konfigurasi. Pertimbangkan pertanyaan berikut saat mengevaluasi kebutuhan Anda:

  • Migrasi atau implementasi baru: Apakah beban kerja ini dimigrasikan dari platform yang berbeda, atau apakah ini implementasi baru? Beban kerja yang dimigrasikan mungkin telah menetapkan SLA dan garis besar performa.
  • Perjanjian tingkat layanan (SLA): Apa persyaratan latensi, throughput, dan ketersediaan Anda? Dokumentasikan SLA teknis dan bisnis.
  • Pola akses: Bagaimana pengguna berinteraksi dengan data? Memahami pola kueri umum membantu mengukur konfigurasi gudang Anda dengan tepat dan mengoptimalkan lapisan data untuk beban kerja tertentu.

Pola akses BI umum

Beban kerja BI biasanya termasuk dalam dua kategori pola akses yang berbeda, masing-masing membutuhkan konfigurasi gudang SQL yang berbeda.

Pola DirectQuery / LiveQuery

Pola DirectQuery mengkueri data secara real time, membutuhkan respons latensi rendah untuk analitik interaktif:

Karakteristik:

  • Jumlah kueri yang tinggi
  • Kueri biasanya mengembalikan kumpulan hasil kecil (kurang dari 1.000 rekaman)
  • Biasanya dijalankan selama jam kerja
  • Persyaratan SLA yang ketat dengan ekspektasi latensi rendah
  • Pola kueri yang tidak dapat diprediksi (dasbor, laporan)
  • Data yang diakses per kueri biasanya kurang dari 5GB
  • Membutuhkan komputasi yang sangat dapat diskalakan untuk mengakomodasi pola lonjakan

Ekspektasi performa:

  • Waktu respons kueri: detik (biasanya kurang dari 5 detik untuk dasbor interaktif)
  • Kesegaran data: Terbaru, mencerminkan data terbaru

Profil beban kerja:

  • Lonjakan yang sering terjadi selama jam kerja
  • Variasi beban yang tidak dapat diprediksi (berbasis pengguna)
  • Dapat meluas hingga 24x7 untuk organisasi global

Pola Impor dan Ekstrak

Pola pemuatan mengekstrak data untuk sistem hilir, memprioritaskan throughput daripada latensi.

Karakteristik:

  • Jumlah kueri rendah (penyegaran terjadwal)
  • Biasanya kumpulan hasil yang besar (lebih dari 1.000.000 rekaman)
  • Biasanya dijadwalkan selama jam sepi
  • Pola kueri yang dapat diprediksi (sering didorong proses penelusuran lebih dalam)
  • Data yang diakses per kueri: hingga puluhan GB

Ekspektasi performa:

  • Waktu respons kueri: menit hingga jam (berorientasi batch)
  • Kesegaran data: Rekam jepret hari atau hari sebelumnya

Profil beban kerja:

  • Jendela eksekusi terjadwal dan dapat diprediksi
  • Karakteristik beban kerja dan persyaratan sumber daya yang diketahui
  • Pemrosesan berorientasi batch

Campuran kueri dalam beban kerja DirectQuery

Saat menggunakan pola DirectQuery dengan model data skema bintang, harapkan distribusi kueri berikut:

  • Kueri dimensi: Banyak kueri kecil memindai tabel dimensi (pelanggan, produk, waktu)
  • Kueri fakta: Banyak kueri besar yang memindai tabel fakta dengan gabungan dan agregasi
  • Ekstrak kueri: Beberapa kueri yang sederhana namun memakan waktu lama untuk ekstrak data besar

Campuran kueri yang bervariasi ini memerlukan gudang SQL yang dapat menangani kueri kecil dan sering secara efisien dan kueri analitik besar secara bersamaan.

Strategi multi-gudang untuk isolasi beban kerja

Databricks merekomendasikan penyediaan beberapa gudang SQL untuk mencapai:

Ukuran yang tepat dan biaya optimal

  • Mengukur setiap gudang dengan tepat untuk pola beban kerja spesifiknya
  • Hindari over-provisioning dengan memisahkan beban kerja dengan persyaratan sumber daya yang berbeda
  • Gunakan gudang yang lebih kecil untuk pengembangan dan pengujian, lebih besar untuk produksi
  • Gunakan skalabilitas gudang untuk menemukan keseimbangan ideal antara performa dan biaya

Performa keseluruhan yang lebih baik

  • Mencegah pertikaian sumber daya antara pola DirectQuery dan Impor/Ekstrak
  • Mengisolasi dasbor interaktif dari operasi refresh batch
  • Mengaktifkan penskalakan independen berdasarkan tuntutan beban kerja

Pengisian silang dan alokasi biaya

  • Melacak penggunaan dan biaya berdasarkan unit bisnis, proyek, atau tim
  • Mengaktifkan model penagihan balik yang akurat
  • Meningkatkan visibilitas dan akuntabilitas biaya

Administrasi dan manajemen yang lebih efisien

  • Menetapkan kepemilikan dan tanggung jawab manajemen oleh tim atau proyek
  • Menerapkan kebijakan berhenti otomatis yang berbeda berdasarkan pola penggunaan
  • Mengonfigurasi kontrol dan pemantauan akses terpisah

Untuk beban kerja DirectQuery / LiveQuery

  • Menggunakan gudang SQL tanpa server untuk manajemen sumber daya otomatis
  • Mengonfigurasi penghentian otomatis agresif (15-30 menit) untuk pengoptimalan biaya
  • Atur ukuran kluster berdasarkan kompleksitas kueri dan volume data (mulailah dengan Sedang, tingkatkan skala jika diperlukan)
  • Atur jumlah kluster min dan maks berdasarkan beban kerja yang diantisipasi
  • Pantau parameter Kueri Antrean Puncak dan sesuaikan maksimum kluster yang sepadan

Untuk Mengimpor/Mengekstrak beban kerja

  • Gunakan gudang SQL Pro atau Klasik untuk pekerjaan terjadwal yang dapat diprediksi
  • Mengonfigurasi waktu berhenti otomatis yang lebih lama (1-2 jam) jika beberapa pekerjaan berjalan secara berurutan
  • Gunakan ukuran kluster yang lebih besar (Besar, Ekstra Besar) untuk agregasi kompleks
  • Pertimbangkan penjadwalan tetap untuk diselaraskan dengan jendela batch
  • Memantau durasi kueri dan menyesuaikan ukuran berdasarkan persyaratan SLA

Untuk informasi selengkapnya tentang perilaku penskalaan dan ukuran gudang SQL, lihat perilaku ukuran, penskalaan, dan antrean gudang SQL.

Untuk referensi cepat praktik terbaik penyajian BI, lihat lembar contekan BI.

  • Last updated on