Refresh bertahap dan data real time

Refresh bertahap memperluas operasi refresh terjadwal dengan menyediakan pembuatan dan manajemen partisi otomatis untuk tabel himpunan data yang sering memuat data baru dan yang diperbarui. Untuk sebagian besar himpunan data, ini adalah satu atau beberapa tabel yang berisi data transaksi yang sering berubah dan dapat tumbuh secara eksponensial, seperti tabel fakta dalam skema database relasional atau bintang. Kebijakan refresh bertahap untuk mempartisi tabel, me-refresh hanya partisi impor terbaru, dan secara opsional memanfaatkan partisi DirectQuery tambahan untuk data real-time dapat secara signifikan mengurangi jumlah data yang harus di-refresh sementara pada saat yang sama memastikan bahwa bahkan perubahan terbaru pada sumber data disertakan dalam hasil kueri.

Dengan refresh bertahap dan data real time:

• Lebih sedikit siklus refresh untuk data yang berubah cepat – Mode DirectQuery mendapatkan pembaruan data terbaru saat kueri diproses tanpa memerlukan irama refresh yang tinggi.
• Refresh lebih cepat - Hanya data terbaru yang telah berubah yang perlu di-refresh.
• Refresh lebih dapat diandalkan - Koneksi jangka panjang ke sumber data volatil tidak diperlukan. Kueri untuk sumber data berjalan lebih cepat, mengurangi potensi masalah jaringan untuk mengganggu.
• Konsumsi sumber daya berkurang - Less data untuk di-refresh mengurangi konsumsi memori secara keseluruhan dan sumber daya lainnya dalam sistem Power BI dan sumber data.
• Memungkinkan himpunan data besar - Himpunan data dengan kemungkinan miliaran baris dapat tumbuh tanpa perlu sepenuhnya menyegarkan seluruh himpunan data dengan setiap operasi refresh.
• Penyiapan yang mudah - Kebijakan refresh bertahap didefinisikan dalam Power BI Desktop hanya dengan beberapa tugas. Saat diterbitkan, layanan secara otomatis menerapkan kebijakan tersebut dengan setiap refresh.

Saat Anda menerbitkan model Power BI Desktop ke layanan, setiap tabel dalam himpunan data baru memiliki satu partisi. Partisi tunggal tersebut berisi semua baris untuk tabel tersebut. Jika tabelnya besar, katakanlah dengan puluhan juta baris atau bahkan lebih, refresh untuk tabel tersebut dapat memakan waktu lama dan mengonsumsi sumber daya yang berlebihan.

Dengan refresh bertahap, layanan secara dinamis mempartisi dan memisahkan data yang perlu sering di-refresh dari data yang dapat di-refresh lebih jarang. Data tabel difilter dengan menggunakan parameter tanggal/waktu Power Query dengan nama RangeStart dan RangeEnd yang dicadangkan dan peka huruf besar/kecil. Saat awalnya mengonfigurasi refresh bertahap di Power BI Desktop, parameter digunakan untuk memfilter hanya periode kecil data yang akan dimuat ke dalam model. Saat diterbitkan ke layanan, dengan operasi refresh pertama, layanan membuat refresh bertahap dan partisi historis dan secara opsional partisi DirectQuery real time berdasarkan pengaturan kebijakan refresh bertahap, lalu mengambil alih nilai parameter untuk memfilter dan mengkueri data untuk setiap partisi berdasarkan nilai tanggal/waktu untuk setiap baris.

Dengan setiap refresh berikutnya, filter kueri hanya mengembalikan baris tersebut dalam periode refresh yang ditentukan secara dinamis oleh parameter. Baris dengan tanggal/waktu dalam periode refresh di-refresh. Baris dengan tanggal/waktu tidak lagi dalam periode refresh kemudian menjadi bagian dari periode historis, yang tidak di-refresh. Jika partisi DirectQuery real time disertakan dalam kebijakan refresh bertahap, filternya juga diperbarui sehingga mengambil perubahan apa pun yang terjadi setelah periode refresh. Baik periode refresh maupun historis digulirkan ke depan. Saat partisi refresh bertahap baru dibuat, partisi refresh tidak lagi dalam periode refresh menjadi partisi historis. Seiring waktu, partisi historis menjadi kurang terperinci saat digabungkan bersama- sama. Ketika partisi historis tidak lagi dalam periode historis yang ditentukan oleh kebijakan, partisi tersebut dihapus dari himpunan data sepenuhnya. Ini dikenal sebagai pola jendela bergulir.

Keindahan refresh bertahap adalah layanan menangani semua ini untuk Anda berdasarkan kebijakan refresh bertahap yang Anda tentukan. Bahkan, proses dan partisi yang dibuat darinya bahkan tidak terlihat dalam layanan. Dalam kebanyakan kasus, kebijakan refresh bertahap yang terdefinisi dengan baik adalah semua yang diperlukan untuk secara signifikan meningkatkan performa refresh himpunan data. Namun, partisi DirectQuery real time hanya didukung untuk himpunan data dalam kapasitas Premium, Power BI Premium juga memungkinkan partisi yang lebih canggih dan skenario refresh melalui titik akhir XMLA.

Persyaratan

Paket yang didukung

Refresh bertahap didukung untuk himpunan data Power BI Premium, Premium per pengguna, Power BI Pro, dan Power BI Embedded.

Mendapatkan data terbaru secara real time dengan DirectQuery hanya didukung untuk himpunan data Power BI Premium, Premium per pengguna, dan Power BI Embedded.

Sumber data yang didukung

Refresh bertahao dan data real-time berfungsi paling baik untuk sumber data relasional terstruktur, seperti SQL Database dan Azure Synapse, tetapi juga dapat berfungsi untuk sumber data lainnya. Bagaimanapun, sumber data Anda harus mendukung hal berikut:

Kolom tanggal - Tabel harus berisi kolom tanggal jenis data tanggal/waktu atau bilangan bulat. Parameter RangeStart dan RangeEnd (yang harus berupa jenis data tanggal/waktu) memfilter data tabel berdasarkan kolom tanggal. Untuk kolom tanggal kunci pengganti bilangan bulat dalam bentuk yyyymmdd, Anda dapat membuat fungsi yang mengonversi nilai tanggal/waktu dalam parameter RangeStart dan RangeEnd agar sesuai dengan kunci pengganti bilangan bulat kolom tanggal. Untuk mempelajari selengkapnya, lihat Mengonfigurasi refresh bertahap - Mengonversi DateTime menjadi bilangan bulat.

Lipatan kueri - Refresh bertahap dirancang untuk sumber data yang mendukung pelipatan kueri, yang merupakan kemampuan Power Query untuk menghasilkan ekspresi kueri tunggal untuk mengambil dan mengubah data sumber, terutama jika mendapatkan data terbaru secara real time dengan DirectQuery. Sebagian besar sumber data yang mendukung kueri SQL mendukung pelipatan kueri. Sumber data seperti file datar, blob, dan beberapa umpan web sering kali tidak.

Saat refresh bertahap dikonfigurasi, ekspresi Power Query yang menyertakan filter tanggal/waktu berdasarkan parameter RangeStart dan RangeEnd dijalankan terhadap sumber data. Filter ini berlaku untuk transformasi yang disertakan dalam kueri yang menentukan klausa WHERE berdasarkan parameter. Dalam kasus di mana filter tidak didukung oleh sumber data, filter tidak dapat disertakan dalam ekspresi kueri. Jika kebijakan refresh bertahap mencakup mendapatkan data real-time dengan DirectQuery, transformasi non-lipat tidak dapat digunakan. Jika ini adalah kebijakan mode impor murni tanpa data real-time, mesin mashup kueri mungkin mengkompensasi dan menerapkan filter secara lokal, yang mengharuskan mengambil semua baris untuk tabel dari sumber data. Ini dapat menyebabkan refresh bertahap menjadi lambat, dan prosesnya dapat kehabisan sumber daya baik di layanan Power BI atau di Gateway Data Lokal - secara efektif mengalahkan tujuan refresh bertahap.

Karena dukungan untuk pelipatan kueri berbeda untuk berbagai jenis sumber data, verifikasi harus dilakukan untuk memastikan logika filter disertakan dalam kueri yang dijalankan terhadap sumber data. Dalam kebanyakan kasus, Power BI Desktop mencoba melakukan verifikasi ini untuk Anda saat menentukan kebijakan refresh bertahap. Untuk sumber data berbasis SQL seperti SQL Database, Azure Synapse, Oracle, dan Teradata, verifikasi ini dapat diandalkan. Namun, sumber data lain mungkin tidak dapat memverifikasi tanpa melacak kueri. Jika Power BI Desktop tidak dapat mengonfirmasi, peringatan ditampilkan dalam dialog Konfigurasi kebijakan refresh bertahp.

Jika Anda melihat peringatan ini dan ingin memverifikasi bahwa lipatan kueri yang diperlukan terjadi, gunakan fitur Diagnostik Power Query atau lacak kueri dengan menggunakan alat yang didukung oleh sumber data, seperti SQL Profiler. Jika pelipatan kueri tidak terjadi, verifikasi logika filter disertakan dalam kueri yang diteruskan ke sumber data. Jika tidak, kemungkinan kueri menyertakan transformasi yang mencegah pelipatan.

Sebelum mengonfigurasi solusi refresh bertambah Anda, pastikan untuk membaca dan memahami panduan pelipatan Kueri secara menyeluruh di Power BI Desktop dan Power Query lipatan kueri. Artikel ini dapat membantu Anda menentukan apakah sumber data dan kueri Anda mendukung pelipatan kueri.

Sumber data tunggal

Saat mengonfigurasi refresh bertahap dan data real-time dengan menggunakan Power BI Desktop, atau mengonfigurasi solusi tingkat lanjut dengan menggunakan Tabular Model Scripting Language (TMSL) atau Tabular Object Model (TOM) melalui titik akhir XMLA, semua partisi baik impor atau DirectQuery harus meminta data dari satu sumber.

Jenis sumber data lainnya

Dengan menggunakan fungsi kueri kustom tambahan dan logika kueri, refresh bertahap dapat digunakan dengan jenis sumber data lain yang disediakan filter berdasarkan RangeStart dan RangeEnd dapat diteruskan dalam satu kueri. Misalnya, Excel file buku kerja yang disimpan dalam folder, file di SharePoint, atau umpan RSS. Perlu diingat, ini adalah skenario lanjutan yang memerlukan penyesuaian dan pengujian tambahan di luar apa yang dijelaskan di sini. Pastikan untuk memeriksa bagian Komunitas nanti di artikel ini untuk saran tentang bagaimana Anda dapat menemukan info selengkapnya tentang menggunakan refresh bertahap untuk skenario unik seperti ini.

Batas waktu

Terlepas dari refresh bertahap, himpunan data Power BI Pro memiliki batas waktu refresh dua jam dan tidak mendukung mendapatkan data real-time dengan DirectQuery. Untuk himpunan data dalam kapasitas Premium, batas waktunya adalah lima jam. Operasi refresh bersifat proses dan memori intensif. Operasi refresh penuh dapat menggunakan sebanyak dua kali lipat jumlah memori yang diperlukan oleh himpunan data saja karena layanan mempertahankan rekam jepret himpunan data dalam memori hingga operasi refresh selesai. Operasi refresh juga dapat diproses secara intensif, mengkonsumsi sejumlah besar sumber daya CPU yang tersedia. Operasi refresh juga harus mengandalkan koneksi yang volatil ke sumber data, dan kemampuan sistem sumber data tersebut untuk mengembalikan output kueri dengan cepat. Batas waktu adalah perlindungan untuk membatasi konsumsi sumber daya Anda yang tersedia secara berlebihan.

Catatan

Dengan kapasitas Premium, operasi refresh yang dilakukan melalui titik akhir XMLA tidak memiliki batas waktu. Untuk mempelajari selengkapnya, lihat Refresh bertahap tingkat lanjut dengan titik akhir XMLA.

Karena refresh bertahap mengoptimalkan operasi refresh pada tingkat partisi dalam himpunan data, konsumsi sumber daya dapat dikurangi secara signifikan. Pada saat yang sama, bahkan dengan refresh bertahap, kecuali melalui titik akhir XMLA, operasi refresh terikat oleh batas dua dan lima jam yang sama. Kebijakan refresh bertahap yang efektif tidak hanya mengurangi jumlah data yang diproses dengan operasi refresh, tetapi juga mengurangi jumlah data historis yang tidak perlu yang disimpan dalam himpunan data Anda.

Kueri juga dapat dibatasi oleh batas waktu default untuk sumber data. Sebagian besar sumber data relasional memungkinkan penggantian batas waktu dalam ekspresi Power Query M. Misalnya, ekspresi di bawah ini menggunakan fungsi akses data SQL Server untuk mengatur CommandTimeout menjadi 2 jam. Setiap periode yang ditentukan oleh rentang kebijakan mengirimkan kueri yang mengamati pengaturan batas waktu perintah.

let
    Source = Sql.Database("myserver.database.windows.net", "AdventureWorks", [CommandTimeout=#duration(0, 2, 0, 0)]),
    dbo_Fact = Source{[Schema="dbo",Item="FactInternetSales"]}[Data],
    #"Filtered Rows" = Table.SelectRows(dbo_Fact, each [OrderDate] >= RangeStart and [OrderDate] < RangeEnd)
in
    #"Filtered Rows"

Untuk himpunan data yang sangat besar dalam kapasitas Premium yang kemungkinan akan berisi miliaran baris, operasi refresh awal dapat di-bootstrap. Bootstrapping memungkinkan layanan untuk membuat objek tabel dan partisi untuk himpunan data, tetapi tidak memuat dan memproses data ke salah satu partisi. Dengan menggunakan SQL Server Management Studio, partisi kemudian dapat diproses secara individual, berurutan, atau secara paralel yang dapat mengurangi jumlah data yang dikembalikan dalam satu kueri, tetapi juga melewati batas waktu lima jam. Untuk mempelajari selengkapnya, lihat Refresh bertahap tingkat lanjut - Mencegah batas waktu pada refresh penuh awal.

Tanggal dan waktu saat ini

Tanggal dan waktu saat ini didasarkan pada tanggal sistem pada saat refresh. Jika refresh terjadwal diaktifkan untuk himpunan data dalam layanan, zona waktu yang ditentukan akan dipertimbangkan saat menentukan tanggal dan waktu saat ini. Baik refresh individual mapun terjadwal melalui layanan pengawasan zona waktu jika tersedia. Misalnya, refresh yang terjadi pada pukul 20.00 Waktu Pasifik (AS dan Kanada) dengan zona waktu yang ditentukan akan menentukan tanggal dan waktu saat ini berdasarkan Waktu Pasifik, bukan GMT (yang seharusnya menjadi hari berikutnya). Operasi refresh yang tidak dipanggil melalui layanan, seperti perintah refresh TMSL, tidak akan mempertimbangkan zona waktu refresh terjadwal.

Mengonfigurasi refresh bertahap dan data real time

Kita akan membahas konsep penting untuk mengonfigurasi refresh bertahap dan data real-time di sini. Saat Anda siap untuk instruksi langkah demi langkah yang lebih rinci, pastikan untuk memeriksa Mengonfigurasi refresh bertahap dan data real-time untuk himpunan data.

Mengonfigurasi refresh bertahap dilakukan di Power BI Desktop. Untuk sebagian besar model, hanya beberapa tugas yang diperlukan. Namun, ingatlah hal-hal berikut:

• Saat diterbitkan ke layanan, Anda tidak dapat menerbitkan model yang sama lagi dari Power BI Desktop. Penerbitan ulang akan menghapus partisi dan data yang ada yang sudah ada di himpunan data. Jika Anda menerbitkan ke kapasitas Premium, perubahan skema metadata berikutnya dapat dilakukan dengan alat seperti Toolkit ALM sumber terbuka atau dengan menggunakan Tabular Model Scripting Language (TMSL). Untuk mempelajari selengkapnya, lihat Refresh bertahap tingkat lanjut - Penyebaran khusus metadata.
• Saat dipublikasikan ke layanan, Anda tidak dapat mengunduh himpunan data kembali sebagai PBIX untuk Power BI Desktop. Karena himpunan data dalam layanan dapat tumbuh begitu besar, tidak praktis untuk mengunduh kembali dan membuka di komputer desktop biasa.
• Saat mendapatkan data real-time dengan DirectQuery, Anda tidak dapat menerbitkan himpunan data ke ruang kerja yang tidak Premium. Refresh bertahap dengan data real-time hanya didukung dengan Power BI Premium.

Membuat parameter

Saat mengonfigurasi refresh bertahap di Power BI Desktop, Anda terlebih dahulu membuat dua parameter tanggal/waktu Power Query dengan nama RangeStart dan RangeEnd yang dipesan dan peka terhadap huruf besar/kecil. Parameter ini, yang ditentukan dalam dialog Kelola Parameter di Editor Power Query awalnya digunakan untuk memfilter data yang dimuat ke dalam tabel model Power BI Desktop untuk menyertakan hanya baris tersebut dengan tanggal/waktu dalam periode tersebut. Setelah model diterbitkan ke layanan, RangeStart dan RangeEnd diganti secara otomatis oleh layanan untuk mengkueri data yang ditentukan oleh periode refresh yang ditentukan dalam pengaturan kebijakan refresh bertahap.

Misalnya, tabel sumber data FactInternetSales kami rata-rata 10k baris baru per hari. Untuk membatasi jumlah baris yang awalnya dimuat ke dalam model dalam Power BI Desktop, kami menentukan periode dua hari antara RangeStart dan RangeEnd.

Memfilter data

Dengan parameter RangeStart dan RangeEnd yang ditentukan, Anda kemudian menerapkan filter Tanggal kustom pada kolom tanggal tabel Anda. Filter yang Anda terapkan pilih subset data yang akan dimuat ke dalam model saat Anda mengklik Terapkan.

Menggunakan contoh FactInternetSales kami, setelah membuat filter berdasarkan parameter dan menerapkan langkah-langkah, data dua hari, kira-kira 20k baris dimuat ke dalam model kami.

Tentukan kebijakan

Setelah filter diterapkan dan subset data telah dimuat ke dalam model, Anda kemudian menentukan kebijakan refresh bertahap untuk tabel. Setelah model diterbitkan ke layanan, kebijakan digunakan oleh layanan untuk membuat dan mengelola partisi tabel dan melakukan operasi refresh. Untuk menentukan kebijakan, Anda akan menggunakan kotak dialog Refresh bertahap dan data real time untuk menentukan pengaturan yang diperlukan dan pengaturan opsional.

Tabel

Kotak daftar Pilih tabel default ke tabel yang Anda pilih dalam Tampilan data. Aktifkan refresh bertahap untuk tabel dengan penggeser. Jika ekspresi Power Query untuk tabel tidak menyertakan filter berdasarkan parameter RangeStart dan RangeEnd, pengalih dinonaktifkan.

Pengaturan yang Diperlukan

Data arsip yang dimulai sebelum pengaturan tanggal refresh menentukan periode historis di mana baris dengan tanggal/waktu dalam periode tersebut disertakan dalam kumpulan data, ditambah baris untuk periode historis yang belum selesai saat ini, ditambah baris dalam periode refresh hingga tanggal saat ini dan waktu.

Misalnya, jika kita menentukan 5 tahun, tabel kita akan menyimpan lima tahun terakhir seluruh tahun data historis dalam partisi tahun, ditambah baris untuk tahun ini dalam partisi kuartal, bulan, atau hari, hingga dan termasuk periode refresh.

Untuk himpunan data dalam kapasitas Premium, partisi historis yang didukung dapat di-refresh secara selektif pada granularitas yang ditentukan oleh pengaturan ini. Untuk mempelajari selengkapnya, lihat Refresh bertambah tingkat lanjut - Partisi.

refresh bertahap dimulai sebelum tanggal refresh menentukan periode refresh bertahap di mana semua baris dengan tanggal/waktu dalam periode tersebut disertakan dalam partisi refresh dan disegarkan dengan setiap operasi refresh.

Misalnya, jika kita menentukan periode refresh 3 hari, dengan setiap operasi refresh, layanan menggantikan parameter RangeStart dan RangeEnd untuk membuat kueri untuk baris dengan tanggal/waktu dalam periode tiga hari, dimulai dan berakhir tergantung pada tanggal dan waktu saat ini. Baris dengan tanggal/waktu dalam 3 hari terakhir hingga waktu operasi refresh saat ini di-refresh. Dengan jenis kebijakan ini, kita dapat mengharapkan tabel himpunan data FactInternetSales dalam layanan, yang rata-rata 10k baris baru per hari, untuk me-refresh sekitar 30k baris dengan setiap operasi refresh.

Pastikan untuk menentukan periode yang hanya menyertakan jumlah baris minimum yang diperlukan untuk memastikan pelaporan yang akurat. Jika menentukan kebijakan untuk lebih dari satu tabel, parameter RangeStart dan RangeEnd yang sama harus digunakan meskipun periode penyimpanan dan refresh yang berbeda ditentukan untuk setiap tabel.

Pengaturan opsional

Pengaturan Dapatkan data terbaru secara real time dengan DirectQuery (hanya Premium) memungkinkan pengambilan perubahan terbaru dari tabel yang dipilih di sumber data di luar periode refresh bertahap dengan menggunakan DirectQuery. Semua baris dengan tanggal/waktu yang lebih lambat dari periode refresh bertahap disertakan dalam partisi DirectQuery dan diambil dari sumber data dengan setiap kueri himpunan data.

Misalnya, jika kita menentukan periode refresh 3 hari, dengan setiap operasi refresh, layanan menggantikan parameter RangeStart dan RangeEnd untuk membuat kueri untuk baris dengan tanggal/waktu dalam periode tiga hari, dimulai dan berakhir tergantung pada tanggal dan waktu saat ini. Baris dengan tanggal/waktu setelah waktu operasi refresh saat ini disertakan. Dengan jenis kebijakan ini, kita dapat mengharapkan tabel himpunan data FactInternetSales dalam layanan untuk menyertakan bahkan pembaruan data terbaru.

Satu-satunya hari refresh yang lengkap memastikan semua baris sepanjang hari disertakan dalam operasi refresh. Pengaturan ini bersifat opsional kecuali Anda mengaktifkan pengaturan Dapatkan data terbaru secara real time dengan DirectQuery (hanya Premium). Katakanlah refresh Anda dijadwalkan untuk berjalan pada pukul 04.00 setiap pagi. Jika baris data baru muncul di tabel sumber data selama empat jam tersebut antara tengah malam dan 04.00, Anda tidak ingin memperhitungkannya. Beberapa metrik bisnis seperti barel per hari di industri minyak dan gas tidak masuk akal dengan hari-hari parsial. Contoh lain adalah me-refresh data dari sistem keuangan di mana data untuk bulan sebelumnya disetujui pada hari kalender ke-12 dalam sebulan. Anda dapat mengatur periode refresh menjadi 1 bulan dan menjadwalkan refresh untuk berjalan pada hari ke-12 dalam sebulan. Dengan opsi ini dipilih, misalnya, refresh data Januari pada 12 Februari.

Perlu diingat, kecuali refresh terjadwal dikonfigurasi untuk zona waktu non-UTC, operasi refresh dalam layanan berjalan di bawah waktu UTC, yang dapat menentukan tanggal efektif dan periode selesai efek.

Pengaturan Deteksi perubahan data memungkinkan refresh yang lebih selektif. Anda dapat memilih kolom tanggal/waktu yang digunakan untuk mengidentifikasi dan me-refresh hanya hari-hari di mana data telah berubah. Ini mengasumsikan kolom seperti itu ada di sumber data, yang biasanya untuk tujuan audit. Kolom ini seharusnya tidak sama dengan yang digunakan untuk mempartisi data dengan parameter RangeStart dan RangeEnd. Nilai maksimum kolom ini dievaluasi untuk setiap periode dalam rentang bertahap. Jika belum berubah sejak refresh terakhir, Anda tidak perlu me-refresh periode. Dalam contoh ini, ini berpotensi mengurangi hari-hari yang di-refresh secara bertahap dari 3 menjadi 1.

Desain saat ini mengharuskan kolom untuk mendeteksi perubahan data tetap ada dan di-cache ke dalam memori. Teknik berikut dapat digunakan untuk mengurangi kardinalitas dan konsumsi memori:

• Pertahankan hanya nilai maksimum kolom pada saat refresh, mungkin dengan menggunakan fungsi Power Query.
• Kurangi presisi ke tingkat yang dapat diterima, mengingat persyaratan frekuensi refresh Anda.
• Tentukan kueri kustom untuk mendeteksi perubahan data dengan menggunakan titik akhir XMLA dan hindari mempertahankan nilai kolom sama sekali.

Dalam beberapa kasus, mengaktifkan opsi Deteksi perubahan data dapat ditingkatkan lebih lanjut. Misalnya, Anda mungkin ingin menghindari mempertahankan kolom pembaruan terakhir di cache dalam memori, atau mengaktifkan skenario di mana tabel konfigurasi/instruksi disiapkan oleh proses ETL untuk menandai hanya partisi yang perlu di-refresh. Dalam kasus seperti ini, untuk kapasitas Premium, gunakan Tabular Model Scripting Language (TMSL) dan/atau Tabular Object Model (TOM) untuk mengambil alih perilaku deteksi perubahan data. Untuk mempelajari selengkapnya, lihat Refresh bertahap tingkat lanjut - Kueri kustom untuk mendeteksi perubahan data.

Terbitkan

Setelah mengonfigurasi kebijakan refresh bertahap, Anda menerbitkan model ke layanan. Saat penerbitan selesai, Anda dapat melakukan operasi refresh awal pada himpunan data.

Catatan

Himpunan data dengan kebijakan refresh bertahap untuk mendapatkan data terbaru secara real time dengan DirectQuery hanya dapat diterbitkan ke ruang kerja Premium.

Untuk himpunan data yang diterbitkan ke ruang kerja yang ditetapkan ke kapasitas Premium, jika Menurut Anda himpunan data akan tumbuh melebihi 1 GB atau lebih, Anda dapat meningkatkan performa operasi refresh dan memastikan himpunan data tidak memaksimalkan batas ukuran dengan mengaktifkan Format penyimpanan himpunan data besar sebelum melakukan operasi refresh pertama dalam layanan. Untuk mempelajari selengkapnya, lihat Himpunan data besar di Power BI Premium.

Penting

Setelah diterbitkan ke layanan, Anda tidak dapat mengunduh kembali PBIX.

Refresh

Setelah menerbitkan ke layanan, Anda melakukan operasi refresh awal pada himpunan data. Ini harus berupa refresh individu (manual) sehingga Anda dapat memantau kemajuan. Operasi refresh awal dapat memakan waktu cukup lama untuk diselesaikan. Partisi harus dibuat, data historis yang dimuat, objek seperti hubungan dan hierarki dibangun atau dibangun kembali, dan objek terhitung dihitung ulang.

Operasi refresh berikutnya, baik individu atau terjadwal jauh lebih cepat karena hanya partisi refresh bertahap yang di-refresh. Operasi pemrosesan lain masih harus terjadi, seperti menggabungkan partisi dan penghitungan ulang, tetapi biasanya hanya membutuhkan sebagian kecil waktu dibandingkan dengan refresh awal.

Refresh laporan otomatis

Untuk laporan yang menggunakan himpunan data dengan kebijakan refresh bertahap untuk mendapatkan data terbaru secara real time dengan DirectQuery, ada baiknya mengaktifkan refresh halaman otomatis pada interval tetap atau berdasarkan deteksi perubahan sehingga laporan menyertakan data terbaru tanpa penundaan. Untuk mempelajari selengkapnya, lihat Refresh halaman otomatis di Power BI.

Refresh bertahap tingkat lanjut

Jika himpunan data Anda berada pada kapasitas Premium dengan titik akhir XMLA diaktifkan, refresh bertahap dapat diperluas lebih lanjut untuk skenario tingkat lanjut. Misalnya, Anda dapat menggunakan SQL Server Management Studio untuk melihat dan mengelola partisi, bootstrap operasi refresh awal, atau merefresh partisi historis yang didukung. Untuk mempelajari selengkapnya, lihat Refresh bertahap tingkat lanjut dengan titik akhir XMLA.

Komunitas

Power BI memiliki komunitas yang dinamis di mana MVP, pro BI, dan rekan sejawat berbagi keahlian dalam grup diskusi, video, blog, dan lainnya. Saat mempelajari tentang refresh bertahap, pastikan untuk memeriksa sumber daya tambahan ini:

• Komunitas Power BI
• Cari "refresh bertahap Power BI" di Bing
• Cari "Refresh bertahap untuk file" di Bing
• Cari "Pertahankan data yang ada menggunakan refresh bertahap" di Bing

Langkah berikutnya

Refresh bertahap untuk himpunan data
Refresh bertahap tingkat lanjut dengan titik akhir XMLA
Memecahkan masalah refresh bertahap
Refresh bertahap untuk himpunan data