DirectQuery di Power BI

Di Power BI Desktop atau layanan Power BI, Anda bisa menyambungkan ke berbagai sumber data dengan cara yang berbeda. Anda bisa mengimpor data ke Power BI, yang merupakan cara paling umum untuk mendapatkan data. Anda juga dapat terhubung langsung ke beberapa data di repositori sumber aslinya, yang disebut DirectQuery. Artikel ini terutama membahas kemampuan DirectQuery.

Artikel ini menjelaskan:

• Opsi konektivitas data Power BI yang berbeda.
• Panduan tentang kapan menggunakan DirectQuery daripada mengimpor.
• Batasan dan implikasi penggunaan DirectQuery.
• Rekomendasi untuk berhasil menggunakan DirectQuery.
• Cara mendiagnosis masalah performa DirectQuery.

Artikel ini berfokus pada alur kerja DirectQuery saat Anda membuat laporan di Power BI Desktop, tetapi juga mencakup menyambungkan melalui DirectQuery di layanan Power BI.

Catatan

DirectQuery juga merupakan fitur SQL Server Analysis Services. Fitur tersebut berbagi banyak detail dengan Direct Query di Power BI, tetapi ada juga perbedaan penting. Artikel ini terutama membahas DirectQuery dengan Power BI, bukan SQL Server Analysis Services.

Untuk informasi selengkapnya tentang menggunakan DirectQuery dengan SQL Server Analysis Services, lihat Menggunakan DirectQuery untuk model semantik Power BI dan Analysis Services (pratinjau). Anda juga dapat mengunduh PDF DirectQuery di SQL Server 2016 Analysis Services.

Mode konektivitas data Power BI

Power BI tersambung ke sejumlah besar sumber data yang bervariasi, seperti:

• Layanan online seperti Salesforce dan Dynamics 365.
• Database seperti SQL Server, Access, dan Amazon Redshift.
• File sederhana dalam Excel, JSON, dan format lainnya.
• Sumber data lain seperti Spark, situs web, dan Microsoft Exchange.

Anda bisa mengimpor data dari sumber ini ke Power BI. Untuk beberapa sumber, Anda juga dapat terhubung menggunakan DirectQuery. Untuk ringkasan sumber yang mendukung DirectQuery, lihat Sumber data yang didukung oleh DirectQuery. Sumber yang diaktifkan DirectQuery terutama merupakan sumber yang dapat memberikan performa kueri interaktif yang baik.

Anda harus mengimpor data ke Power BI sedapat mungkin. Mengimpor memanfaatkan mesin kueri berkinerja tinggi Power BI, dan memberikan pengalaman dengan fitur penuh yang sangat interaktif.

Jika Anda tidak dapat memenuhi tujuan dengan mengimpor data, misalnya jika data sering berubah dan laporan harus mencerminkan data terbaru, pertimbangkan untuk menggunakan DirectQuery. DirectQuery hanya layak ketika sumber data yang mendasar dapat memberikan hasil kueri interaktif dalam waktu kurang dari lima detik untuk kueri agregat biasa, dan dapat menangani beban kueri yang dihasilkan. Pertimbangkan dengan cermat batasan dan implikasi penggunaan DirectQuery.

Kemampuan impor Power BI dan DirectQuery berevolusi dari waktu ke waktu. Perubahan yang memberikan lebih banyak fleksibilitas saat menggunakan data yang diimpor memungkinkan Anda mengimpor lebih sering, dan menghilangkan beberapa kelemahan menggunakan DirectQuery. Terlepas dari peningkatan, performa sumber data yang mendasar adalah pertimbangan utama saat menggunakan DirectQuery. Jika sumber data yang mendasar lambat, menggunakan DirectQuery untuk sumber tersebut tetap tidak layak.

Bagian berikut mencakup tiga opsi untuk menyambungkan ke data: impor, DirectQuery, dan koneksi langsung. Sisa artikel berfokus pada DirectQuery.

Mengimpor koneksi

Saat Anda menyambungkan ke sumber data seperti SQL Server dan mengimpor data di Power BI Desktop, hasil berikut ini terjadi:

• Saat Anda awalnya Mendapatkan Data, setiap kumpulan tabel yang Anda pilih menentukan kueri yang mengembalikan sekumpulan data. Anda dapat mengedit kueri tersebut sebelum memuat data, misalnya untuk menerapkan filter, mengagregasi data, atau menggabungkan tabel yang berbeda.

• Setelah dimuat, semua data yang ditentukan oleh kueri diimpor ke dalam cache Power BI.

• Membangun visual dalam Power BI Desktop mengkueri data yang di-cache. Penyimpanan Power BI memastikan kueri cepat, dan bahwa semua perubahan pada visual segera mencerminkan.

• Visual tidak mencerminkan perubahan pada data yang mendasar di penyimpanan data. Anda perlu menimpor ulang untuk merefresh data.

• Menerbitkan laporan ke layanan Power BI sebagai file .pbix membuat dan mengunggah model semantik yang menyertakan data yang diimpor. Anda kemudian dapat menjadwalkan refresh data, misalnya meniru ulang data setiap hari. Bergantung pada lokasi sumber data asli, mungkin perlu untuk mengonfigurasi gateway data lokal untuk refresh.

• Membuka laporan yang sudah ada atau menulis laporan baru di layanan Power BI meminta data yang diimpor lagi, memastikan interaktivitas.

• Anda dapat menyematkan visual atau seluruh halaman laporan sebagai petak dasbor di layanan Power BI. Petak peta secara otomatis di-refresh setiap kali model semantik yang mendasar disegarkan.

Koneksi DirectQuery

Saat Anda menggunakan DirectQuery untuk menyambungkan ke sumber data di Power BI Desktop, hasil berikut terjadi:

• Anda menggunakan Dapatkan Data untuk memilih sumber. Untuk sumber relasional, Anda masih bisa memilih sekumpulan tabel yang menentukan kueri yang secara logis mengembalikan sekumpulan data. Untuk sumber multidaya seperti SAP Business Warehouse (SAP BW), Anda hanya memilih sumbernya.

• Setelah dimuat, tidak ada data yang diimpor ke penyimpanan Power BI. Sebagai gantinya, saat Anda membuat visual, Power BI Desktop mengirimkan kueri ke sumber data yang mendasarinya untuk mengambil data yang diperlukan. Waktu yang diperlukan untuk menyegarkan visual bergantung pada performa sumber data yang mendasari.

• Setiap perubahan pada data yang mendasar tidak segera tercermin dalam visual yang ada. Ini masih perlu di-refresh. Power BI Desktop mengirim ulang kueri yang diperlukan untuk setiap visual, dan memperbarui visual seperlunya.

• Menerbitkan laporan ke layanan Power BI membuat dan mengunggah model semantik, sama seperti untuk impor. Namun, model semantik itu tidak menyertakan data.

• Membuka laporan yang sudah ada atau menulis laporan baru di layanan Power BI meminta sumber data yang mendasarinya untuk mengambil data yang diperlukan. Bergantung pada lokasi sumber data asli, mungkin perlu untuk mengonfigurasi gateway data lokal untuk mendapatkan data.

• Anda dapat menyematkan visual atau seluruh halaman laporan sebagai petak peta dasbor. Untuk memastikan bahwa membuka dasbor cepat, petak peta secara otomatis di-refresh sesuai jadwal, misalnya setiap jam. Anda dapat mengontrol frekuensi refresh tergantung pada seberapa sering data berubah dan pentingnya melihat data terbaru.

• Saat Anda membuka dasbor, petak peta mencerminkan data pada saat refresh terakhir, belum tentu perubahan terbaru yang dilakukan pada sumber yang mendasar. Anda dapat me-refresh dasbor terbuka untuk memastikan bahwa dasbor tersebut terkini.

Koneksi langsung

Saat menyambungkan ke SQL Server Analysis Services, Anda dapat memilih untuk mengimpor data atau menggunakan koneksi langsung ke model data yang dipilih. Menggunakan koneksi langsung mirip dengan DirectQuery. Tidak ada data yang diimpor, dan sumber data yang mendasar dikueri untuk me-refresh visual.

Misalnya, saat Anda menggunakan impor untuk menyambungkan ke SQL Server Analysis Services, Anda menentukan kueri terhadap sumber SQL Server Analysis Services eksternal, dan mengimpor data. Jika Anda menyambungkan langsung, Anda tidak menentukan kueri, dan seluruh model eksternal ditampilkan dalam daftar bidang.

Situasi ini juga berlaku saat Anda tersambung ke sumber berikut, kecuali tidak ada opsi untuk mengimpor data:

• Model semantik Power BI, misalnya menyambungkan ke model semantik Power BI yang sudah diterbitkan ke layanan, untuk menulis laporan baru di atasnya.

• Microsoft Dataverse.

Saat Anda menerbitkan laporan SQL Server Analysis Services yang menggunakan koneksi langsung, perilaku dalam layanan Power BI mirip dengan laporan DirectQuery dengan cara berikut:

• Membuka laporan yang sudah ada atau menulis laporan baru di layanan Power BI meminta sumber SQL Server Analysis Services yang mendasarinya, mungkin memerlukan gateway data lokal.

• Petak peta dasbor secara otomatis di-refresh sesuai jadwal, seperti setiap jam.

Koneksi langsung juga berbeda dari DirectQuery dalam beberapa cara. Misalnya, koneksi langsung selalu meneruskan identitas pengguna yang membuka laporan ke sumber SQL Server Analysis Services yang mendasar.

Kasus penggunaan DirectQuery

Koneksi dengan DirectQuery dapat berguna dalam skenario berikut. Dalam beberapa kasus ini, meninggalkan data di lokasi sumber aslinya diperlukan atau bermanfaat.

DirectQuery di Power BI menawarkan manfaat terbesar dalam skenario berikut:

• Data sering berubah, dan Anda memerlukan pelaporan hampir real-time.
• Anda perlu menangani data besar tanpa harus melakukan pra-agregat.
• Sumber yang mendasar menentukan dan menerapkan aturan keamanan.
• Pembatasan kedaulatan data berlaku.
• Sumbernya adalah sumber multidimensi yang berisi langkah-langkah, seperti SAP BW.

Data sering berubah, dan Anda memerlukan pelaporan hampir real-time

Anda dapat merefresh model dengan data yang diimpor paling banyak sekali per jam, lebih sering dengan langganan Power BI Pro atau Power BI Premium. Jika data terus berubah, dan perlu laporan untuk menampilkan data terbaru, menggunakan impor dengan refresh terjadwal mungkin tidak memenuhi kebutuhan Anda. Anda dapat mengalirkan data langsung ke Power BI, meskipun ada batasan pada volume data yang didukung untuk kasus ini.

Menggunakan DirectQuery berarti membuka atau me-refresh laporan atau dasbor selalu menampilkan data terbaru di sumbernya. Petak peta dasbor juga dapat diperbarui lebih sering, sesering setiap 15 menit.

Data sangat besar

Jika data sangat besar, tidak layak untuk mengimpor semuanya. DirectQuery tidak memerlukan transfer data yang besar, karena meminta data di tempat. Namun, data besar mungkin juga membuat performa kueri terhadap sumber yang mendasarinya terlalu lambat.

Anda tidak selalu harus mengimpor data terperinci lengkap. Editor Power Query memudahkan untuk melakukan pra-agregat data selama impor. Secara teknis, dimungkinkan untuk mengimpor data agregat yang Anda butuhkan untuk setiap visual. Meskipun DirectQuery adalah pendekatan paling sederhana untuk data besar, mengimpor data agregat mungkin menawarkan solusi jika sumber data yang mendasar terlalu lambat untuk DirectQuery.

Detail ini berkaitan dengan penggunaan Power BI saja. Untuk informasi selengkapnya tentang menggunakan model besar di Power BI, lihat model semantik besar di Power BI Premium. Tidak terdapat batasan seberapa sering data dapat direfresh.

Sumber yang mendasar menentukan aturan keamanan

Saat Anda mengimpor data, Power BI tersambung ke sumber data dengan menggunakan kredensial Power BI Desktop pengguna saat ini, atau kredensial yang dikonfigurasi untuk refresh terjadwal dari layanan Power BI. Dalam menerbitkan dan berbagi laporan yang telah mengimpor data, Anda harus berhati-hati untuk berbagi hanya dengan pengguna yang diizinkan untuk melihat data, atau Anda harus menentukan keamanan tingkat baris sebagai bagian dari model semantik.

DirectQuery memungkinkan kredensial penampil laporan melewati ke sumber yang mendasar, yang menerapkan aturan keamanan. DirectQuery mendukung akses menyeluruh (SSO) ke sumber data Azure SQL, dan melalui gateway data ke server SQL lokal. Untuk informasi selengkapnya, lihat Gambaran Umum akses menyeluruh (SSO) untuk gateway di Power BI.

Pembatasan kedaulatan data berlaku

Beberapa organisasi memiliki kebijakan seputar kedaulatan data, artinya data tidak dapat meninggalkan tempat organisasi. Data ini menyajikan masalah untuk solusi berdasarkan impor data. Dengan DirectQuery, data tetap berada di lokasi sumber yang mendasar. Namun, bahkan dengan DirectQuery, layanan Power BI menyimpan beberapa cache data di tingkat visual, karena refresh petak peta terjadwal.

Sumber data yang mendasar menggunakan langkah-langkah

Sumber data yang mendasar seperti SAP Hana atau SAP BW berisi langkah-langkah. Pengukuran berarti bahwa data yang diimpor sudah berada pada tingkat agregasi tertentu, seperti yang ditentukan oleh kueri. Visual yang meminta data pada agregat tingkat yang lebih tinggi, seperti TotalSales menurut Tahun, selanjutnya menggabungkan nilai agregat. Agregasi ini baik-baik saja untuk langkah-langkah aditif, seperti Jumlah dan Min, tetapi dapat menjadi masalah untuk langkah-langkah non-aditif, seperti Average dan DistinctCount.

Dengan mudah mendapatkan data agregat yang benar yang diperlukan untuk visual langsung dari sumber memerlukan pengiriman kueri per visual, seperti dalam DirectQuery. Ketika Anda terhubung ke SAP BW, memilih DirectQuery memungkinkan perawatan tindakan ini. Untuk informasi selengkapnya, lihat DirectQuery dan SAP BW.

Saat ini DirectQuery melalui SAP Hana memperlakukan data sama dengan sumber relasional, dan menghasilkan perilaku yang mirip dengan impor. Untuk informasi selengkapnya, lihat DirectQuery dan SAP Hana.

Batasan DirectQuery

Menggunakan DirectQuery memiliki beberapa implikasi yang berpotensi negatif. Beberapa batasan ini sedikit berbeda tergantung pada sumber yang tepat yang Anda gunakan. Bagian berikut mencantumkan implikasi umum penggunaan DirectQuery, dan batasan yang terkait dengan performa, keamanan, transformasi, pemodelan, dan pelaporan.

Implikasi umum

Beberapa implikasi umum dan batasan penggunaan DirectQuery mengikuti:

• Jika data berubah, Anda harus me-refresh untuk menampilkan data terbaru. Mengingat penggunaan cache, tidak ada jaminan bahwa visual selalu menampilkan data terbaru. Misalnya, visual mungkin menampilkan transaksi dalam sehari terakhir. Perubahan pemotong mungkin me-refresh visual untuk menampilkan transaksi selama dua hari terakhir, termasuk transaksi terbaru yang baru tiba. Tetapi mengembalikan pemotong ke nilai aslinya dapat mengakibatkannya lagi memperlihatkan nilai sebelumnya yang di-cache. Pilih Refresh untuk menghapus cache apa pun dan merefresh semua visual di halaman untuk memperlihatkan data terbaru.

• Jika data berubah, tidak ada jaminan konsistensi antar visual. Visual yang berbeda, baik pada halaman yang sama atau di halaman yang berbeda, mungkin disegarkan pada waktu yang berbeda. Jika data di sumber yang mendasar berubah, tidak ada jaminan bahwa setiap visual menampilkan data pada titik waktu yang sama.

  Mengingat bahwa lebih dari satu kueri mungkin diperlukan untuk satu visual, misalnya, untuk mendapatkan detail dan total, bahkan konsistensi dalam satu visual tidak dijamin. Untuk menjamin konsistensi ini akan memerlukan overhead untuk menyegarkan semua visual setiap kali visual di-refresh, bersama dengan menggunakan fitur mahal seperti isolasi rekam jepret di sumber data yang mendasar.

  Anda dapat mengurangi masalah ini ke tingkat besar dengan memilih Refresh untuk me-refresh semua visual di halaman. Bahkan untuk mode impor, ada masalah serupa dalam mempertahankan konsistensi saat Anda mengimpor data dari lebih dari satu tabel.

• Anda harus me-refresh di Power BI Desktop untuk mencerminkan perubahan skema. Setelah laporan diterbitkan, Refresh di layanan Power BI me-refresh visual dalam laporan. Tetapi jika skema sumber yang mendasar berubah, layanan Power BI tidak secara otomatis memperbarui daftar bidang yang tersedia. Jika tabel atau kolom dihapus dari sumber yang mendasar, tabel atau kolom tersebut mungkin mengakibatkan kegagalan kueri saat di-refresh. Untuk memperbarui bidang dalam model untuk mencerminkan perubahan, Anda harus membuka laporan di Power BI Desktop dan memilih Refresh.

• Batas 1 juta baris dapat kembali pada kueri apa pun. Ada batas tetap 1 juta baris yang dapat dikembalikan dalam kueri tunggal apa pun ke sumber yang mendasar. Batas ini umumnya tidak memiliki implikasi praktis, dan visual tidak akan menampilkan banyak poin tersebut. Namun, batas dapat terjadi dalam kasus di mana Power BI tidak sepenuhnya mengoptimalkan kueri yang dikirim, dan meminta beberapa hasil perantara yang melebihi batas.

  Batas juga dapat terjadi saat membangun visual, pada jalur ke status akhir yang lebih masuk akal. Misalnya, termasuk Pelanggan dan TotalSalesQuantity dapat mencapai batas ini jika ada lebih dari 1 juta pelanggan, sampai Anda menerapkan beberapa filter. Kesalahan yang mengembalikan adalah: Hasil kueri ke sumber data eksternal telah melebihi ukuran maksimum yang diizinkan dari baris '1000000'.

  Catatan

  Kapasitas premium memungkinkan Anda melebihi batas satu juta baris. Untuk informasi selengkapnya, lihat jumlah kumpulan baris perantara maksimum.

• Anda tidak dapat mengubah model dari mode impor ke DirectQuery. Anda dapat mengalihkan model dari mode DirectQuery ke mode impor jika Anda mengimpor semua data yang diperlukan. Tidak dimungkinkan untuk beralih kembali ke mode DirectQuery, terutama karena set fitur yang tidak didukung mode DirectQuery. Untuk sumber multidireksional seperti SAP BW, Anda tidak dapat beralih dari DirectQuery ke mode impor, karena berbagai perlakuan tindakan eksternal.

Implikasi performa dan beban

Saat Anda menggunakan DirectQuery, pengalaman keseluruhan bergantung pada performa sumber data yang mendasar. Jika me-refresh setiap visual, misalnya setelah mengubah nilai pemotong, membutuhkan waktu kurang dari lima detik, pengalamannya wajar, meskipun mungkin terasa lamban dibandingkan dengan respons langsung dengan data yang diimpor. Jika kelambatan sumber menyebabkan visual individu memakan waktu lebih dari puluhan detik untuk disegarkan, pengalaman menjadi sangat buruk. Kueri bahkan mungkin kehabisan waktu.

Seiring dengan performa sumber yang mendasar, beban yang ditempatkan pada sumber juga berdampak pada performa. Setiap pengguna yang membuka laporan bersama, dan setiap petak dasbor yang direfresh, mengirimkan setidaknya satu kueri per visual ke sumber yang mendasarinya. Sumber harus dapat menangani beban kueri seperti itu sambil mempertahankan performa yang wajar.

Implikasi keamanan

Kecuali sumber data yang mendasar menggunakan SSO, laporan DirectQuery selalu menggunakan kredensial tetap yang sama untuk menyambungkan ke sumber setelah diterbitkan ke layanan Power BI. Segera setelah menerbitkan laporan DirectQuery, Anda harus mengonfigurasi kredensial pengguna untuk digunakan. Hingga Anda mengonfigurasi kredensial, mencoba membuka laporan di layanan Power BI menghasilkan kesalahan.

Setelah Anda memberikan kredensial pengguna, Power BI menggunakan kredensial tersebut untuk siapa pun yang membuka laporan, sama seperti untuk data yang diimpor. Setiap pengguna melihat data yang sama, kecuali keamanan tingkat baris didefinisikan sebagai bagian dari laporan. Anda harus memberikan perhatian yang sama untuk berbagi laporan seperti untuk data yang diimpor, bahkan jika ada aturan keamanan yang ditentukan dalam sumber yang mendasar.

• Koneksi ke model semantik Power BI dan Analysis Services dalam mode DirectQuery selalu menggunakan SSO, sehingga keamanannya mirip dengan koneksi langsung ke Analysis Services.

• Kredensial alternatif tidak didukung saat membuat koneksi DirectQuery ke SQL Server dari Power BI Desktop. Anda dapat menggunakan informasi masuk Windows atau database Anda saat ini.

• Anda dapat menggunakan beberapa sumber data dalam model DirectQuery dengan menggunakan model komposit. Saat Anda menggunakan beberapa sumber data, penting untuk memahami implikasi keamanan tentang bagaimana data bergerak bolak-balik antara sumber data yang mendasar.

Batasan transformasi data

DirectQuery membatasi transformasi data yang dapat Anda terapkan dalam Editor Power Query. Dengan data yang diimpor, Anda dapat dengan mudah menerapkan serangkaian transformasi canggih untuk membersihkan dan membentuk ulang data sebelum menggunakannya untuk membuat visual. Misalnya, Anda dapat mengurai dokumen JSON, atau mempivot data dari kolom ke formulir baris. Transformasi ini lebih terbatas dalam DirectQuery.

Saat Anda terhubung ke sumber pemrosesan analitik online (OLAP) seperti SAP BW, Anda tidak dapat menentukan transformasi apa pun, dan seluruh model eksternal diambil dari sumbernya. Untuk sumber relasional seperti SQL Server, Anda masih dapat menentukan serangkaian transformasi per kueri, tetapi transformasi tersebut terbatas karena alasan performa.

Transformasi apa pun harus diterapkan pada setiap kueri ke sumber yang mendasar, bukan sekali pada refresh data. Transformasi harus dapat diterjemahkan secara wajar ke dalam satu kueri asli. Jika Anda menggunakan transformasi yang terlalu kompleks, Anda mendapatkan kesalahan bahwa transformasi tersebut harus dihapus atau model koneksi dialihkan untuk mengimpor.

Selain itu, dialog Dapatkan Data atau Editor Power Query menggunakan subpilih dalam kueri yang mereka buat dan kirim untuk mengambil data untuk visual. Kueri yang ditentukan dalam Editor Power Query harus valid dalam konteks ini. Secara khusus, tidak dimungkinkan untuk menggunakan kueri dengan ekspresi tabel umum, atau yang memanggil prosedur tersimpan.

Batasan pemodelan

Istilah pemodelan dalam konteks ini berarti tindakan menyempurnakan dan memperkaya data mentah sebagai bagian dari penulisan laporan menggunakan data. Contoh pemodelan meliputi:

• Menentukan hubungan antar tabel.
• Menambahkan perhitungan baru, seperti kolom dan pengukuran terhitung.
• Mengganti nama dan menyembunyikan kolom dan pengukuran.
• Menentukan hierarki.
• Menentukan pemformatan kolom, ringkasan default, dan urutan pengurutan.
• Mengelompokkan atau mengelompokkan nilai.

Anda masih dapat membuat banyak pengayaan model ini ketika Anda menggunakan DirectQuery, dan menggunakan prinsip memperkaya data mentah untuk meningkatkan konsumsi nanti. Namun, beberapa kemampuan pemodelan tidak tersedia atau dibatasi dengan DirectQuery. Batasan diterapkan untuk menghindari masalah performa.

Batasan berikut umum untuk semua sumber DirectQuery. Batasan lainnya mungkin berlaku untuk masing-masing sumber.

• Tidak ada hierarki tanggal bawaan: Dengan data yang diimpor, setiap kolom tanggal/tanggalwaktu juga memiliki hierarki tanggal bawaan yang tersedia secara default. Misalnya, jika Anda mengimpor tabel pesanan penjualan yang menyertakan kolom OrderDate, dan Anda menggunakan OrderDate dalam visual, Anda dapat memilih tingkat tanggal yang sesuai untuk digunakan, seperti tahun, bulan, atau hari. Hierarki tanggal bawaan ini tidak tersedia dengan DirectQuery. Jika ada tabel Tanggal yang tersedia di sumber yang mendasar, seperti umumnya di banyak gudang data, Anda dapat menggunakan fungsi kecerdasan waktu Data Analysis Expressions (DAX) seperti biasa.

• Dukungan tanggal/waktu hanya untuk tingkat detik: Untuk model semantik yang menggunakan kolom waktu, Power BI mengeluarkan kueri ke sumber DirectQuery yang mendasarinya hanya hingga tingkat detail detik, bukan milidetik. Hapus data milidetik dari kolom sumber Anda.

• Batasan dalam kolom terhitung: Kolom terhitung hanya dapat berupa intra-baris, yaitu kolom tersebut hanya dapat merujuk ke nilai kolom lain dari tabel yang sama, tanpa menggunakan fungsi agregat apa pun. Selain itu, fungsi skalar DAX yang diizinkan, seperti LEFT(), terbatas pada fungsi-fungsi yang dapat didorong ke sumber yang mendasarinya. Fungsi bervariasi tergantung pada kemampuan sumber yang tepat. Fungsi yang tidak didukung tidak tercantum dalam pelengkapan otomatis saat menulis kueri DAX untuk kolom terhitung, dan mengakibatkan kesalahan jika digunakan.

• Tidak ada dukungan untuk fungsi DAX induk-anak: Saat dalam mode DirectQuery, tidak dimungkinkan untuk menggunakan keluarga DAX PATH() fungsi yang biasanya menangani struktur induk-anak, seperti bagan akun atau hierarki karyawan.

• Tidak ada pengklusteran: Saat menggunakan DirectQuery, Anda tidak dapat menggunakan kemampuan pengklusteran untuk menemukan grup secara otomatis.

Batasan pelaporan

Hampir semua kemampuan pelaporan didukung untuk model DirectQuery. Selama sumber yang mendasar menawarkan tingkat performa yang sesuai, Anda dapat menggunakan serangkaian visualisasi yang sama seperti untuk data yang diimpor.

Salah satu batasan umum adalah bahwa panjang maksimum data dalam kolom teks untuk model semantik DirectQuery adalah 32.764 karakter. Pelaporan pada teks yang lebih panjang menghasilkan kesalahan.

Kemampuan pelaporan Power BI berikut ini dapat menyebabkan masalah performa dalam laporan berbasis DirectQuery:

• Mengukur filter: Visual yang menggunakan pengukuran atau agregat kolom dapat berisi filter dalam langkah-langkah tersebut. Misalnya, grafik berikut menunjukkan SalesAmount menurut Kategori, tetapi hanya untuk kategori dengan lebih dari 20M penjualan.

  

  Pendekatan ini menyebabkan dua kueri dikirim ke sumber yang mendasarinya:

  • Kueri pertama mengambil kategori yang memenuhi kondisi SalesAmount lebih besar dari 20 juta.
  • Kueri kedua mengambil data yang diperlukan untuk visual, yang mencakup kategori yang memenuhi WHERE kondisi.

  Pendekatan ini umumnya bekerja dengan baik jika ada ratusan atau ribuan kategori, seperti dalam contoh ini. Performa dapat menurun jika jumlah kategori jauh lebih besar. Kueri gagal jika ada lebih dari satu juta kategori.

• Filter TopN: Anda dapat menentukan filter tingkat lanjut untuk memfilter hanya pada nilai atas atau bawah N yang diberi peringkat berdasarkan beberapa ukuran. Misalnya, filter dapat menyertakan 10 kategori teratas. Pendekatan ini kembali mengirim dua kueri ke sumber yang mendasarinya. Namun, kueri pertama mengembalikan semua kategori dari sumber yang mendasar, lalu TopN ditentukan berdasarkan hasil yang dikembalikan. Bergantung pada kardinalitas kolom yang terlibat, pendekatan ini dapat menyebabkan masalah performa atau kegagalan kueri karena batas satu juta baris pada hasil kueri.

• Median: Agregasi apa pun, seperti Sum atau Count Distinct, didorong ke sumber yang mendasar. Namun, biasanya median agregat tidak didukung oleh sumber yang mendasar. Untuk median, data detail diambil dari sumber yang mendasar, dan median dihitung dari hasil yang dikembalikan. Pendekatan ini wajar untuk menghitung median melalui sejumlah kecil hasil.

  Masalah performa atau kegagalan kueri dapat muncul jika kardinalitas besar karena batas satu juta baris. Misalnya, mengkueri Populasi Negara/Wilayah Median mungkin wajar, tetapi Harga Penjualan Median mungkin tidak masuk akal.

• Filter teks tingkat lanjut seperti 'contains': Pemfilteran tingkat lanjut pada kolom teks memungkinkan filter seperti contains dan begins with. Filter ini dapat mengakibatkan penurunan performa untuk beberapa sumber data. Secara khusus, jangan gunakan filter default contains jika Anda memerlukan kecocokan yang tepat. Meskipun hasilnya mungkin sama tergantung pada data aktual, performanya mungkin berbeda secara drastis karena indeks.

• Pemotong multi-pilih: Secara default, pemotong hanya memungkinkan membuat satu pilihan. Mengizinkan multi-pilihan dalam filter dapat menyebabkan masalah performa. Misalnya, jika pengguna memilih 10 produk yang menarik, setiap pilihan baru menghasilkan kueri yang dikirim ke sumbernya. Meskipun pengguna dapat memilih item berikutnya sebelum kueri selesai, pendekatan ini menghasilkan beban tambahan pada sumber yang mendasarinya.

• Total pada visual tabel: Secara default, tabel dan matriks menampilkan total dan subtotal. Dalam banyak kasus, mendapatkan nilai untuk total tersebut memerlukan pengiriman kueri terpisah ke sumber yang mendasarinya. Persyaratan ini berlaku setiap kali Anda menggunakan DistinctCount agregasi, atau dalam semua kasus yang menggunakan DirectQuery melalui SAP BW atau SAP Hana. Anda dapat menonaktifkan total tersebut dengan menggunakan panel Format .

Rekomendasi DirectQuery

Bagian ini memberikan panduan tingkat tinggi tentang cara berhasil menggunakan DirectQuery, mengingat implikasinya.

Performa sumber data yang mendasar

Validasi bahwa refresh visual sederhana dalam waktu lima detik, untuk memberikan pengalaman interaktif yang wajar. Jika visual membutuhkan waktu lebih dari 30 detik untuk di-refresh, kemungkinan masalah lebih lanjut setelah publikasi laporan akan membuat solusi tidak dapat dikerjakan.

Jika kueri lambat, periksa kueri yang dikirim ke sumber yang mendasarinya, dan alasan performa lambat. Untuk informasi selengkapnya, lihat Diagnostik performa.

Artikel ini tidak mencakup berbagai rekomendasi pengoptimalan database di seluruh kumpulan lengkap sumber potensial yang mendasar. Praktik database standar berikut berlaku untuk sebagian besar situasi:

• Untuk performa yang lebih baik, hubungan dasar pada kolom bilangan bulat daripada menggabungkan kolom dari jenis data lainnya.

• Buat indeks yang sesuai. Pembuatan indeks umumnya berarti menggunakan indeks penyimpanan kolom di sumber yang mendukungnya, misalnya SQL Server.

• Perbarui statistik yang diperlukan di sumbernya.

Desain model

Saat Anda menentukan model, ikuti panduan ini:

• Hindari kueri kompleks dalam Editor Power Query. Editor Power Query menerjemahkan kueri kompleks menjadi kueri SQL tunggal. Kueri tunggal muncul di subpilih setiap kueri yang dikirim ke tabel tersebut. Jika kueri tersebut rumit, hal itu dapat mengakibatkan masalah performa pada setiap kueri yang dikirim. Anda bisa mendapatkan kueri SQL aktual untuk serangkaian langkah dengan mengklik kanan langkah terakhir di bawah Langkah yang diterapkan di Editor Power Query dan memilih Tampilkan Kueri Asli.

• Jaga agar langkah-langkah tetap sederhana. Setidaknya awalnya, batasi langkah-langkah untuk agregat sederhana. Jika langkah-langkah beroperasi dengan cara yang memuaskan, Anda dapat menentukan langkah-langkah yang lebih kompleks, tetapi memperhatikan performa.

• Hindari hubungan pada kolom terhitung. Dalam database tempat Anda perlu melakukan gabungan multi-kolom, Power BI tidak mengizinkan hubungan basing pada beberapa kolom sebagai kunci utama atau kunci asing. Solusi umumnya adalah menggabungkan kolom dengan menggunakan kolom terhitung, dan mendasarkan gabungan pada kolom tersebut.

  Solusi ini wajar untuk data yang diimpor, tetapi untuk DirectQuery, solusi ini menghasilkan gabungan pada ekspresi. Hasil itu biasanya mencegah penggunaan indeks apa pun, dan menyebabkan performa yang buruk. Satu-satunya solusi adalah benar-benar mewujudkan beberapa kolom ke dalam satu kolom di sumber data yang mendasar.

• Hindari hubungan pada kolom 'uniqueidentifier'. Power BI tidak secara asli mendukung uniqueidentifier jenis data. Menentukan hubungan antar uniqueidentifier kolom menghasilkan kueri dengan gabungan yang melibatkan pemeran. Sekali lagi, pendekatan ini biasanya mengarah pada performa yang buruk. Satu-satunya solusinya adalah mewujudkan kolom dari jenis alternatif di sumber data yang mendasar.

• Sembunyikan kolom 'ke' pada hubungan. Kolom to pada hubungan biasanya merupakan kunci utama pada to tabel. Kolom tersebut harus disembunyikan, tetapi jika disembunyikan, kolom tersebut tidak muncul di daftar bidang dan tidak dapat digunakan dalam visual. Seringkali kolom tempat hubungan didasarkan sebenarnya adalah kolom sistem, misalnya kunci pengganti di gudang data. Masih yang terbaik untuk menyembunyikan kolom tersebut.

  Jika kolom memiliki arti, perkenalkan kolom terhitung yang terlihat dan yang memiliki ekspresi sederhana sama dengan kunci utama, misalnya:

      ProductKey_PK   (Destination of a relationship, hidden)
      ProductKey (= [ProductKey_PK],   visible)
      ProductName
      ...
  

• Periksa semua kolom terhitung dan perubahan tipe data. Anda dapat menggunakan tabel terhitung saat menggunakan DirectQuery dengan model komposit. Kemampuan ini tidak selalu berbahaya, tetapi menghasilkan kueri yang berisi ekspresi daripada referensi sederhana ke kolom. Kueri tersebut mungkin mengakibatkan indeks tidak digunakan.

• Hindari pemfilteran silang dua arah pada hubungan. Menggunakan pemfilteran silang dua arah dapat menyebabkan pernyataan kueri yang tidak berkinerja baik. Untuk informasi selengkapnya tentang pemfilteran silang dua arah, lihat Mengaktifkan pemfilteran silang dua arah untuk DirectQuery di Power BI Desktop, atau mengunduh laporan resmi pemfilteran silang dua arah. Contoh dalam makalah adalah untuk SQL Server Analysis Services, tetapi poin mendasar juga berlaku untuk Power BI.

• Bereksperimenlah dengan mengatur Asumsikan integritas referensial. Pengaturan Asumsikan integritas referensial pada hubungan memungkinkan kueri untuk menggunakan INNER JOIN daripada OUTER JOIN pernyataan. Panduan ini umumnya meningkatkan performa kueri, meskipun bergantung pada spesifikasi sumber data.

• Jangan gunakan pemfilteran data relatif di Editor Power Query. Dimungkinkan untuk menentukan pemfilteran tanggal relatif di Editor Power Query. Misalnya, Anda dapat memfilter ke baris tempat tanggal dalam 14 hari terakhir.

  

  Namun, filter ini diterjemahkan ke dalam filter berdasarkan tanggal tetap, seperti waktu kueri ditulis, seperti yang dapat Anda lihat di kueri asli.

  

  Data ini mungkin bukan yang Anda inginkan. Untuk memastikan filter diterapkan berdasarkan tanggal pada saat laporan berjalan, terapkan filter tanggal dalam laporan. Anda dapat membuat kolom terhitung yang menghitung jumlah hari yang lalu dengan menggunakan DAX DATE() fungsi , dan menggunakan kolom terhitung tersebut dalam filter.

Desain laporan

Saat Anda membuat laporan yang menggunakan koneksi DirectQuery, ikuti panduan ini:

• Pertimbangkan untuk menggunakan opsi pengurangan kueri: Power BI menyediakan opsi laporan untuk mengirim lebih sedikit kueri, dan untuk menonaktifkan interaksi tertentu yang menyebabkan pengalaman buruk jika kueri yang dihasilkan membutuhkan waktu lama untuk dijalankan. Opsi ini berlaku saat Anda berinteraksi dengan laporan Anda di Power BI Desktop, dan juga berlaku saat pengguna menggunakan laporan di layanan Power BI.

  Untuk mengakses opsi ini di Power BI Desktop, buka File>Opsi dan pengaturan>Opsi dan pilih Pengurangan kueri.

  

  Pilihan pada layar Pengurangan kueri memungkinkan Anda memperlihatkan tombol Terapkan untuk pemotong atau pemfilteran pilihan. Tidak ada kueri yang dikirim hingga Anda memilih tombol Terapkan pada filter atau pemotong. Kueri kemudian menggunakan pilihan Anda untuk memfilter data. Tombol ini memungkinkan Anda membuat beberapa pemotong dan memfilter pilihan sebelum Menerapkannya.

• Terapkan filter terlebih dahulu: Selalu terapkan filter apa pun yang berlaku di awal pembuatan visual. Misalnya, daripada menyeret TotalSalesAmount dan ProductName, lalu filter ke tahun tertentu, terapkan filter pada Tahun di awal.

  Setiap langkah membangun visual mengirimkan kueri. Meskipun dimungkinkan untuk membuat perubahan lain sebelum kueri pertama selesai, pendekatan ini masih meninggalkan beban yang tidak perlu pada sumber yang mendasarinya. Menerapkan filter lebih awal umumnya membuat kueri perantara tersebut lebih murah. Gagal menerapkan filter lebih awal dapat mengakibatkan mencapai batas satu juta baris.

• Batasi jumlah visual pada halaman: Saat Anda membuka halaman atau mengubah pemotong atau filter tingkat halaman, semua visual pada refresh halaman. Ada batasan jumlah kueri paralel. Ketika jumlah visual meningkat, beberapa visual me-refresh secara serial, yang meningkatkan waktu yang diperlukan untuk me-refresh halaman. Oleh karena itu, yang terbaik adalah membatasi jumlah visual pada satu halaman, dan sebaliknya memiliki halaman yang lebih sederhana.

• Pertimbangkan untuk menonaktifkan interaksi antar visual: Secara default, visualisasi pada halaman laporan dapat digunakan untuk memfilter silang dan menyorot silang visualisasi lain pada halaman tersebut. Misalnya, jika Anda memilih 1999 pada bagan pai, bagan kolom disorot silang untuk memperlihatkan penjualan menurut kategori untuk 1999.

  

  Pemfilteran silang dan penyorotan silang di DirectQuery mengharuskan kueri dikirimkan ke sumber yang mendasarinya. Anda harus menonaktifkan interaksi ini jika waktu yang diperlukan untuk merespons pilihan pengguna tidak masuk akal panjang.

  Anda bisa menggunakan pengaturan Pengurangan kueri untuk menonaktifkan penyorotan silang di seluruh laporan Anda, atau berdasarkan kasus per kasus. Untuk informasi selengkapnya, lihat Bagaimana visual saling memfilter silang dalam laporan Power BI.

Jumlah maksimum koneksi

Anda dapat mengatur jumlah maksimum sambungan yang dibuka DirectQuery untuk setiap sumber data pokok, yang mengontrol jumlah kueri yang dikirim secara bersamaan ke setiap sumber data.

DirectQuery membuka jumlah maksimum default 10 sambungan bersamaan. Untuk mengubah jumlah maksimum file saat ini di Power BI Desktop, buka Opsi File>dan Pengaturan> Opsi, dan pilih DirectQuery di bagian File Saat Ini di panel kiri.

Pengaturan diaktifkan hanya ketika setidaknya ada satu sumber DirectQuery dalam laporan saat ini. Nilai berlaku untuk semua sumber DirectQuery, dan untuk sumber DirectQuery baru yang ditambahkan ke laporan tersebut.

Meningkatkan koneksi Maksimum per sumber data memungkinkan pengiriman lebih banyak kueri, hingga jumlah maksimum yang ditentukan, ke sumber data yang mendasarinya. Pendekatan ini berguna ketika banyak visual berada di satu halaman, atau banyak pengguna mengakses laporan secara bersamaan. Setelah jumlah maksimum koneksi tercapai, kueri lebih lanjut diantrekan hingga koneksi tersedia. Batas yang lebih tinggi menghasilkan lebih banyak beban pada sumber yang mendasar, sehingga pengaturan tidak dijamin untuk meningkatkan performa keseluruhan.

Setelah Anda menerbitkan laporan ke layanan Power BI, jumlah maksimum kueri bersamaan juga bergantung pada batas tetap yang ditetapkan pada lingkungan target tempat laporan diterbitkan. Power BI, Power BI Premium, dan Power BI Report Server memberlakukan batas yang berbeda. Tabel di bawah ini mencantumkan batas atas sambungan aktif per sumber data untuk setiap lingkungan Power BI. Batas ini berlaku untuk sumber data cloud dan sumber data lokal seperti SQL Server, Oracle, dan Teradata.

Lingkungan	Batas atas per sumber data
Power BI Pro	10 koneksi aktif
Power BI Premium	Tergantung pada batasan SKU model semantik
Power BI Report Server	10 koneksi aktif

Catatan

Jumlah maksimum pengaturan koneksi DirectQuery berlaku untuk semua sumber DirectQuery saat Anda mengaktifkan metadata yang ditingkatkan, yang merupakan pengaturan default untuk semua model yang dibuat di Power BI Desktop.

DirectQuery dalam layanan Power BI

Semua sumber data DirectQuery didukung dari Power BI Desktop, dan beberapa sumber juga tersedia langsung dari dalam layanan Power BI. Pengguna bisnis dapat menggunakan Power BI untuk menyambungkan ke data mereka di Salesforce, misalnya, dan segera mendapatkan dasbor, tanpa menggunakan Power BI Desktop.

Hanya dua sumber yang diaktifkan DirectQuery berikut yang tersedia langsung di layanan Power BI:

• Spark
• Azure Synapse Analytics (sebelumnya SQL Data Warehouse)

Bahkan untuk kedua sumber ini, masih yang terbaik untuk memulai penggunaan DirectQuery dalam Power BI Desktop. Meskipun awalnya mudah untuk membuat koneksi di layanan Power BI, ada batasan tentang meningkatkan laporan yang dihasilkan lebih lanjut. Misalnya, dalam layanan tidak dimungkinkan untuk membuat perhitungan apa pun, atau menggunakan banyak fitur analitik, atau merefresh metadata untuk mencerminkan perubahan pada skema yang mendasar.

Performa laporan DirectQuery di layanan Power BI tergantung pada tingkat beban yang ditempatkan pada sumber data yang mendasar. Beban tergantung pada:

• Jumlah pengguna yang berbagi laporan dan dasbor.
• Kompleksitas laporan.
• Apakah laporan menentukan keamanan tingkat baris.

Melaporkan perilaku dalam layanan Power BI

Saat Anda membuka laporan di layanan Power BI, semua visual pada refresh halaman yang saat ini terlihat. Setiap visual memerlukan setidaknya satu kueri ke sumber data yang mendasar. Beberapa visual mungkin memerlukan lebih dari satu kueri. Misalnya, visual mungkin menampilkan nilai agregat dari dua tabel fakta yang berbeda, atau berisi ukuran yang lebih kompleks, atau berisi total ukuran non-aditif seperti Count Distinct. Pindah ke halaman baru akan merefresh visual tersebut. Merefresh mengirimkan serangkaian kueri baru ke sumber yang mendasarinya.

Setiap interaksi pengguna pada laporan dapat menyebabkan visual direfresh. Misalnya, memilih nilai yang berbeda pada pemotong memerlukan pengiriman sekumpulan kueri baru untuk merefresh semua visual yang terpengaruh. Hal yang sama berlaku untuk memilih visual untuk menyoroti silang visual lain, atau mengubah filter. Demikian pula, membuat atau mengedit laporan mengharuskan kueri dikirim untuk setiap langkah di jalur untuk menghasilkan visual akhir.

Ada beberapa hasil penembolokan. Refresh visual seketika jika hasil yang sama persis baru-baru ini diperoleh. Jika keamanan tingkat baris ditentukan, cache ini tidak dibagikan di seluruh pengguna.

Menggunakan DirectQuery memberlakukan beberapa batasan penting dalam beberapa kemampuan yang ditawarkan layanan Power BI untuk laporan yang diterbitkan:

• Wawasan cepat tidak didukung: Wawasan cepat Power BI mencari subset yang berbeda dari model semantik Anda sambil menerapkan serangkaian algoritma canggih untuk menemukan wawasan yang berpotensi menarik. Karena wawasan cepat memerlukan kueri berkinerja tinggi, fitur ini tidak tersedia pada model semantik yang menggunakan DirectQuery.

• Menggunakan Jelajahi di Excel menghasilkan performa yang buruk: Anda bisa menjelajahi model semantik dengan menggunakan kemampuan Jelajahi di Excel , yang memungkinkan Anda membuat tabel pivot dan bagan pivot di Excel. Kemampuan ini didukung untuk model semantik yang menggunakan DirectQuery, tetapi performanya lebih lambat daripada membuat visual di Power BI. Jika menggunakan Excel penting untuk skenario Anda, perhitungkan masalah ini dalam memutuskan apakah akan menggunakan DirectQuery.

• Excel tidak memperlihatkan hierarki: Misalnya, saat Anda menggunakan Analisis di Excel, Excel tidak memperlihatkan hierarki apa pun yang ditentukan dalam model Azure Analysis Services atau model semantik Power BI yang menggunakan DirectQuery.

Refresh dasbor

Di layanan Power BI, Anda dapat menyematkan visual individual atau seluruh halaman ke dasbor sebagai petak peta. Petak peta yang didasarkan pada model semantik DirectQuery di-refresh secara otomatis dengan mengirim kueri ke sumber data yang mendasarinya sesuai jadwal. Secara default, model semantik di-refresh setiap jam, tetapi Anda dapat mengonfigurasi refresh antara mingguan dan setiap 15 menit sebagai bagian dari pengaturan model semantik.

Jika tidak ada keamanan tingkat baris yang ditentukan dalam model, setiap petak peta di-refresh sekali, dan hasilnya dibagikan di semua pengguna. Jika Anda menggunakan keamanan tingkat baris, setiap petak peta memerlukan kueri terpisah per pengguna untuk dikirim ke sumber yang mendasarinya.

Mungkin ada efek pengali besar. Dasbor dengan 10 petak peta, dibagikan dengan 100 pengguna, dibuat pada model semantik menggunakan DirectQuery dengan keamanan tingkat baris, menghasilkan setidaknya 1000 kueri yang dikirim ke sumber data yang mendasarinya untuk setiap refresh. Berikan pertimbangan yang cermat untuk penggunaan keamanan tingkat baris dan konfigurasi jadwal refresh.

Batas waktu kueri

Batas waktu empat menit berlaku untuk kueri individual dalam layanan Power BI. Kueri yang memakan waktu lebih dari empat menit gagal. Batas ini dimaksudkan untuk mencegah masalah yang disebabkan oleh waktu eksekusi yang terlalu lama. Anda harus menggunakan DirectQuery hanya untuk sumber yang dapat memberikan performa kueri interaktif.

Diagnostik kinerja

Bagian ini menjelaskan cara mendiagnosis masalah performa, atau cara mendapatkan informasi yang lebih rinci untuk mengoptimalkan laporan Anda.

Mulai diagnosis masalah performa di Power BI Desktop, bukan di layanan Power BI. Masalah performa sering kali didasarkan pada performa sumber yang mendasarinya. Anda dapat dengan lebih mudah mengidentifikasi dan mendiagnosis masalah di lingkungan Power BI Desktop yang lebih terisolasi.

Pendekatan ini awalnya menghilangkan komponen tertentu, seperti gateway Power BI. Jika masalah performa tidak terjadi di Power BI Desktop, Anda dapat menyelidiki spesifik laporan dalam layanan Power BI.

Penganalisis Performa Power BI Desktop adalah alat yang berguna untuk mengidentifikasi masalah. Cobalah untuk mengisolasi masalah apa pun ke satu visual, daripada banyak visual di halaman. Jika satu visual di halaman Power BI Desktop lamban, gunakan penganalisis Performa untuk menganalisis kueri yang dikirim Power BI Desktop ke sumber yang mendasarinya.

Anda juga dapat melihat jejak dan informasi diagnostik yang dikeluarkan beberapa sumber data yang mendasar. Bahkan jika tidak ada jejak dari sumbernya, file pelacakan mungkin berisi detail yang berguna tentang cara kueri berjalan dan bagaimana Anda dapat meningkatkannya. Anda bisa menggunakan proses berikut untuk menampilkan kueri yang dikirim Power BI dan waktu eksekusinya.

Menggunakan SQL Server Profiler untuk melihat kueri

Secara default, Power BI Desktop mencatat peristiwa selama sesi tertentu ke file pelacakan yang disebut FlightRecorderCurrent.trc. File pelacakan berada di folder Power BI Desktop untuk pengguna saat ini, dalam folder bernama AnalysisServicesWorkspaces.

Untuk beberapa sumber DirectQuery, file pelacakan ini mencakup semua kueri yang dikirim ke sumber data yang mendasarinya. Sumber data berikut mengirim kueri ke log:

• SQL Server
• Azure SQL Database
• Azure Synapse Analytics (sebelumnya SQL Data Warehouse)
• Oracle
• Teradata
• SAP HANA

Anda dapat membaca file pelacakan dengan menggunakan SQL Server Profiler, bagian dari unduhan gratis SQL Server Management Studio.

Untuk membuka file pelacakan untuk sesi saat ini:

1. Selama sesi Power BI Desktop, pilih Opsi File>dan opsi pengaturan>, lalu pilih Diagnostik.

2. Di bawah Koleksi Crash Dump, pilih Buka folder crash dump/traces.

   

   Folder Power BI Desktop\Traces terbuka.

3. Navigasi ke folder induk lalu ke folder AnalysisServicesWorkspaces , yang berisi satu folder ruang kerja untuk setiap instans Power BI Desktop yang terbuka. Folder ini diberi nama dengan akhiran bilangan bulat, seperti AnalysisServicesWorkspace2058279583. Folder ruang kerja dihapus saat sesi Power BI Desktop terkait berakhir.

   Di dalam folder ruang kerja untuk sesi Power BI saat ini, folder \Data berisi file pelacakan FlightRecorderCurrent.trc . Catat lokasinya.

4. Buka SQL Server Profiler, dan pilih File>Buka>File Pelacakan.

5. Navigasi ke atau masukkan jalur ke file pelacakan untuk sesi Power BI saat ini, dan buka FlightRecorderCurrent.trc.

SQL Server Profiler menampilkan semua peristiwa dari sesi saat ini. Cuplikan layar berikut menyoroti sekelompok peristiwa untuk kueri. Setiap grup kueri memiliki peristiwa berikut:

• Peristiwa Query Begin dan Query End , yang mewakili awal dan akhir kueri DAX yang dihasilkan dengan mengubah visual atau filter di UI Power BI, atau dari memfilter atau mengubah data di Editor Power Query.

• Satu atau beberapa pasangan dan DirectQuery End peristiwa, yang mewakili kueri yang dikirim ke sumber data yang mendasarinya DirectQuery Begin sebagai bagian dari mengevaluasi kueri DAX.

Beberapa kueri DAX dapat berjalan secara paralel, sehingga acara dari grup yang berbeda dapat digabungkan. Anda dapat menggunakan ActivityID nilai untuk menentukan peristiwa mana yang termasuk dalam grup yang sama.

Kolom berikut ini juga menarik:

• TextData: Detail tekstual dari peristiwa tersebut. Untuk Query Begin peristiwa dan Query End , detailnya adalah kueri DAX. Untuk DirectQuery Begin peristiwa dan DirectQuery End , detailnya adalah kueri SQL yang dikirim ke sumber yang mendasar. TextData untuk peristiwa yang saat ini dipilih juga muncul di panel di bagian bawah layar.
• EndTime: Waktu saat peristiwa selesai.
• Durasi: Durasi, dalam milidetik, yang diperlukan untuk menjalankan kueri DAX atau SQL.
• Kesalahan: Apakah terjadi kesalahan, dalam hal ini peristiwa juga ditampilkan dengan warna merah.

Untuk menangkap jejak guna membantu mendiagnosis potensi masalah performa:

1. Buka satu sesi Power BI Desktop, untuk menghindari kebingungan beberapa folder ruang kerja.

2. Lakukan serangkaian tindakan yang menarik di Power BI Desktop. Sertakan beberapa tindakan lagi, untuk memastikan bahwa peristiwa yang menarik dihapus ke dalam file pelacakan.

3. Buka SQL Server Profiler dan periksa jejaknya. Ingatlah bahwa menutup Power BI Desktop akan menghapus file pelacakan. Selain itu, tindakan lebih lanjut di Power BI Desktop tidak segera muncul. Anda harus menutup dan membuka kembali file jejak untuk melihat peristiwa baru.

Pertahankan sesi individu yang cukup kecil, mungkin 10 detik tindakan, bukan ratusan. Pendekatan ini memudahkan untuk menginterpretasikan file pelacakan. Ada juga batasan ukuran file pelacakan. Untuk sesi yang panjang, terdapat kemungkinan peristiwa awal dibatalkan.

Memahami format kueri

Format umum kueri Power BI Desktop menggunakan subpilih untuk setiap tabel yang mereka referensikan. Kueri Editor Power Query menentukan kueri subpilih. Misalnya, asumsikan Anda memiliki tabel TPC-DS berikut di SQL Server:

Menjalankan kueri berikut:

SalesAmount (SUMX(Web_Sales, [ws_sales_price]*[ws_quantity]))
by Item[i_category]
for Date_dim[d_year] = 2000

Hasil dalam visual berikut di Power BI:

Merefresh visual tersebut menghasilkan kueri SQL dalam gambar berikut. Ada tiga kueri subpilih untuk Web_Sales, , Itemdan Date_dim, yang masing-masing mengembalikan semua kolom pada tabel masing-masing, meskipun visual hanya mereferensikan empat kolom.

Editor Power Query menentukan kueri subpilih yang tepat. Penggunaan kueri subpilih ini belum ditampilkan untuk memengaruhi performa untuk sumber data yang didukung DirectQuery. Sumber data seperti SQL Server mengoptimalkan rujukan ke kolom lain.

Power BI menggunakan pola ini karena analis menyediakan kueri SQL secara langsung. Power BI menggunakan kueri sebagaimana disediakan, tanpa upaya untuk menulis ulang kueri tersebut.

Konten terkait

Untuk informasi selengkapnya tentang DirectQuery di Power BI, lihat:

• Menggunakan DataQuery di Power BI Desktop

Artikel ini menjelaskan aspek DirectQuery yang umum di semua sumber data. Lihat artikel berikut ini untuk detail tentang sumber tertentu:

• DirectQuery dan SAP Hana
• DirectQuery dan SAP BW
• Menggunakan DirectQuery untuk model semantik Power BI dan Analysis Services