Mengukur gateway data lokal
Artikel ini menargetkan administrator Power BI yang perlu menginstal dan mengelola gateway data lokal.
Gateway diperlukan setiap kali Power BI harus mengakses data yang tidak dapat diakses langsung lewat Internet. Ini dapat diinstal pada server lokal, atau infrastruktur yang dihosting VM sebagai layanan (IaaS).
Beban kerja gateway
Gateway data lokal mendukung dua beban kerja. Penting bagi Anda untuk terlebih dahulu memahami beban kerja ini sebelum kita membahas pengukuran dan rekomendasi gateway.
Beban kerja data yang di-cache
Beban kerja data singgahan mengambil dan mengubah data sumber untuk dimuat ke dalam model semantik Power BI. Hal tersebut dilakukan dalam tiga langkah:
- Koneksi: Gateway tersambung ke data sumber.
- Pengambilan dan transformasi data: Data diambil, dan bila perlu, diubah. Jika memungkinkan, mesin mashup Power Query mendorong langkah-langkah transformasi ke sumber data—yang dikenal sebagai lipatan kueri. Jika tidak memungkinkan, transformasi harus dilakukan oleh gateway. Dalam hal ini, gateway akan menggunakan lebih banyak sumber daya CPU dan memori.
- Transfer: Data ditransfer ke layanan Power BI—koneksi Internet yang andal dan cepat penting, terutama untuk volume data besar.
Beban kerja Koneksi Langsung dan DirectQuery
Beban kerja Koneksi Langsung dan DirectQuery sebagian besar berfungsi dalam mode pass-through. Layanan Power BI mengirim kueri, dan gateway merespons dengan hasil kueri. Umumnya, hasil kueri berukuran kecil.
- Untuk informasi selengkapnya tentang Koneksi Langsung, lihat Model semantik di layanan Power BI (Model yang dihosting secara eksternal).
- Untuk informasi selengkapnya tentang DirectQuery, lihat Mode model semantik di layanan Power BI (mode DirectQuery).
Beban kerja ini memerlukan sumber daya CPU untuk kueri perutean dan hasil kueri. Biasanya ada permintaan CPU yang jauh lebih sedikit daripada yang diperlukan oleh beban kerja data Cache—terutama ketika diperlukan untuk mengubah data untuk cache.
Konektivitas yang andal, cepat, dan konsisten penting untuk memastikan pengguna laporan memiliki pengalaman yang responsif.
Pertimbangan pengukuran
Menentukan ukuran yang benar untuk mesin gateway Anda dapat bergantung pada variabel berikut:
- Untuk beban kerja data Cache:
- Jumlah refresh model semantik bersamaan
- Jenis sumber data (database relasional, database analitik, umpan data, atau file)
- Volume data yang akan diambil dari sumber data
- Setiap transformasi yang perlu dilakukan oleh mesin mashup Power Query
- Volume data yang akan ditransfer ke layanan Power BI
- Untuk beban kerja Koneksi Langsung dan DirectQuery:
- Jumlah pengguna laporan bersamaan
- Jumlah visual pada halaman laporan (setiap visual mengirimkan setidaknya satu kueri)
- Frekuensi pembaruan cache kueri dasbor Power BI
- Jumlah laporan real-time menggunakan fitur Refresh halaman otomatis
- Apakah model semantik memberlakukan Keamanan Tingkat Baris (RLS)
Umumnya, beban kerja Koneksi Langsung dan DirectQuery memerlukan CPU yang memadai, sementara beban kerja data Cache memerlukan lebih banyak CPU dan memori. Kedua beban kerja bergantung pada konektivitas yang baik dengan layanan Power BI, dan sumber data.
Catatan
Kapasitas Power BI memberlakukan batasan pada paralelisme refresh model, dan throughput Koneksi Langsung dan DirectQuery. Tidak ada gunanya mengukur gateway Anda untuk memberikan lebih dari apa yang didukung layanan Power BI. Batas berbeda dengan SKU Premium (dan SKU A yang berukuran setara). Untuk informasi selengkapnya, lihat Lisensi kapasitas Microsoft Fabric dan Apa itu Power BI Premium? (Node kapasitas).
Penting
Terkadang artikel ini mengacu pada Power BI Premium atau langganan kapasitasnya (SKU P). Ketahuilah bahwa Microsoft saat ini mengonsolidasikan opsi pembelian dan menghentikan SKU Power BI Premium per kapasitas. Pelanggan baru dan yang sudah ada harus mempertimbangkan untuk membeli langganan kapasitas Fabric (F SKU) sebagai gantinya.
Untuk informasi selengkapnya, lihat Pembaruan penting yang masuk ke lisensi Power BI Premium dan Tanya Jawab Umum Power BI Premium.
Rekomendasi
Rekomendasi ukuran gateway bergantung pada banyak variabel. Di bagian ini, kami memberi Anda rekomendasi umum yang dapat Anda pertimbangkan.
Pengukuran awal
Mungkin sulit untuk memperkirakan ukuran yang tepat secara akurat. Kami menyarankan agar Anda memulai dengan mesin dengan setidaknya 8 inti CPU, RAM 8 GB, dan beberapa adaptor jaringan Gigabit. Anda kemudian dapat mengukur beban kerja gateway yang khas dengan mencatat penghitung CPU dan sistem memori. Untuk informasi selengkapnya, lihat Memantau dan mengoptimalkan performa gateway data lokal.
Konektivitas
Rencanakan konektivitas terbaik antara layanan Power BI dan gateway Anda, serta gateway dan sumber data Anda.
- Berusahalah untuk keandalan, kecepatan cepat, dan latensi yang rendah dan konsisten.
- Hilangkan—atau kurangi—lompatan mesin antara gateway dan sumber data Anda.
- Hapus pembatasan jaringan apa pun yang diberlakukan oleh lapisan proksi firewall Anda. Untuk informasi selengkapnya tentang titik akhir Power BI, lihat Menambahkan URL Power BI ke daftar izinkan Anda.
- Siapkan Azure ExpressRoute untuk membuat koneksi privat dan terkelola ke Power BI.
- Untuk sumber data di Azure VM, pastikan VM dikolokasikan dengan layanan Power BI.
- Untuk beban kerja Koneksi Langsung ke SQL Server Analysis Services (SSAS) yang melibatkan RLS dinamis, pastikan konektivitas yang baik antara mesin gateway dan Active Directory lokal.
Pengklusteran
Untuk penyebaran skala besar, Anda dapat membuat gateway dengan beberapa anggota kluster. Kluster menghindari satu titik kegagalan, dan dapat memuat lalu lintas keseimbangan di seluruh gateway. Anda dapat:
- Instal satu atau beberapa gateway dalam kluster.
- Mengisolasi beban kerja ke gateway mandiri, atau kluster server gateway.
Untuk informasi selengkapnya, lihat Mengelola kluster ketersediaan tinggi gateway data lokal dan penyeimbangan beban.
Desain dan pengaturan model semantik
Desain model semantik, dan pengaturannya, dapat berdampak pada beban kerja gateway. Untuk mengurangi beban kerja gateway, Anda dapat mempertimbangkan tindakan berikut.
Untuk Impor model semantik:
- Menyiapkan refresh data yang lebih jarang.
- Siapkan refresh bertahap untuk meminimalkan jumlah data yang akan ditransfer.
- Jika memungkinkan, pastikan pelipatan kueri terjadi.
- Terutama untuk volume data besar atau kebutuhan akan hasil latensi rendah, konversikan desain ke model DirectQuery atau Composite .
Untuk model semantik DirectQuery:
- Optimalkan sumber data, model, dan desain laporan—untuk informasi selengkapnya, lihat Panduan model DirectQuery di Power BI Desktop.
- Buat agregasi untuk menyimpan hasil tingkat yang lebih tinggi untuk mengurangi jumlah permintaan DirectQuery.
- Batasi interval refresh halaman Otomatis, dalam desain laporan dan pengaturan kapasitas.
- Terutama ketika RLS dinamis diberlakukan, batasi frekuensi pembaruan cache dasbor.
- Terutama untuk volume data yang lebih kecil atau untuk data non-volatil, konversikan desain ke model Impor atau Komposit .
Untuk model semantik Koneksi Langsung:
- Terutama ketika RLS dinamis diberlakukan, batasi frekuensi pembaruan cache dasbor.
Konten terkait
Untuk informasi selengkapnya tentang dokumen resmi ini, lihat sumber daya berikut:
- Perencanaan implementasi Power BI: Gateway data
- Panduan untuk menyebarkan gateway data untuk Power BI
- Konfigurasikan pengaturan proksi untuk gateway data lokal
- Memantau dan mengoptimalkan performa gateway data lokal
- Memecahkan masalah gateway - Power BI
- Pemecahan masalah gateway data Lokal
- Pentingnya pelipatan kueri
- Pertanyaan? Coba tanyakan kepada Komunitas Power BI
- Ada saran? Sumbang ide untuk meningkatkan Power BI