Refresh bertahap dan data real-time untuk model semantik

Artikel
11/10/2023

Refresh bertahap memperluas operasi refresh terjadwal dengan menyediakan pembuatan dan manajemen partisi otomatis untuk tabel model semantik yang sering memuat data baru dan yang diperbarui. Untuk sebagian besar model, satu atau beberapa tabel 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, hanya menyegarkan partisi impor terbaru, dan secara opsional menggunakan partisi DirectQuery lain untuk data real-time dapat secara signifikan mengurangi jumlah data yang harus disegarkan. Pada saat yang sama, kebijakan ini memastikan bahwa perubahan terbaru pada sumber data disertakan dalam hasil kueri.

Dengan refresh bertahap dan data real time:

Diperlukan 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. Lebih sedikit data untuk di-refresh mengurangi konsumsi memori secara keseluruhan dan sumber daya lainnya di Power BI dan sistem sumber data.
Model semantik besar diaktifkan. Model semantik dengan potensi miliaran baris dapat tumbuh tanpa perlu sepenuhnya merefresh seluruh model dengan setiap operasi refresh.
Penyiapan itu mudah. Kebijakan refresh inkremental ditentukan di Power BI Desktop hanya dengan beberapa tugas. Saat Power BI Desktop menerbitkan laporan, layanan secara otomatis menerapkan kebijakan tersebut dengan setiap refresh.

Saat Anda menerbitkan model Power BI Desktop ke layanan, setiap tabel dalam model baru memiliki satu partisi. Partisi tunggal tersebut berisi semua baris untuk tabel tersebut. Jika tabel besar, katakanlah dengan puluhan juta baris atau lebih, refresh untuk tabel tersebut dapat memakan waktu lama dan menggunakan jumlah 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 yang dipesan RangeStart dan peka huruf besar/kecil, dan RangeEnd. Saat Anda mengonfigurasi refresh inkremental di Power BI Desktop, parameter ini digunakan untuk memfilter hanya periode kecil data yang dimuat ke dalam model. Saat Power BI Desktop menerbitkan laporan ke layanan Power BI, dengan operasi refresh pertama, layanan membuat refresh bertahap dan partisi historis, dan secara opsional partisi DirectQuery real time berdasarkan pengaturan kebijakan refresh bertahap. Layanan kemudian 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 lalu 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 model sepenuhnya. Perilaku ini dikenal sebagai pola jendela bergulir.

Graphic representing a rolling window pattern.

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

Persyaratan

Bagian berikutnya menjelaskan paket dan sumber data yang didukung.

Paket yang didukung

Refresh inkremental didukung untuk model Power BI Premium, Premium per pengguna, Power BI Pro, dan Power BI Embedded.

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

Sumber data yang didukung

Refresh inkremental 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:

Pemfilteran tanggal - Sumber data harus mendukung beberapa mekanisme untuk memfilter data menurut tanggal. Untuk sumber relasional, biasanya ini adalah kolom tanggal/waktu atau tipe data bilangan bulat pada tabel target. 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 inkremental - Mengonversi DateTime menjadi bilangan bulat.

Untuk sumber data lainnya, parameter RangeStart dan RangeEnd harus diteruskan ke sumber data dengan beberapa cara yang memungkinkan pemfilteran. Untuk sumber data berbasis file tempat file dan folder diatur menurut tanggal, parameter RangeStart dan RangeEnd dapat digunakan untuk memfilter file dan folder untuk memilih file mana yang akan dimuat. Untuk sumber data berbasis web, parameter RangeStart dan RangeEnd dapat diintegrasikan ke dalam permintaan HTTP. Misalnya, kueri berikut dapat digunakan untuk refresh inkremental jejak dari instans AppInsights:

let 
    strRangeStart = DateTime.ToText(RangeStart,[Format="yyyy-MM-dd'T'HH:mm:ss'Z'", Culture="en-US"]),
    strRangeEnd = DateTime.ToText(RangeEnd,[Format="yyyy-MM-dd'T'HH:mm:ss'Z'", Culture="en-US"]),
    Source = Json.Document(Web.Contents("https://api.applicationinsights.io/v1/apps/<app-guid>/query", 
    [Query=[#"query"="traces 
    | where timestamp >= datetime(" & strRangeStart &") 
    | where timestamp < datetime("& strRangeEnd &")
    ",#"x-ms-app"="AAPBI",#"prefer"="ai.response-thinning=true"],Timeout=#duration(0,0,4,0)])),
    TypeMap = #table(
    { "AnalyticsTypes", "Type" }, 
    { 
    { "string",   Text.Type },
    { "int",      Int32.Type },
    { "long",     Int64.Type },
    { "real",     Double.Type },
    { "timespan", Duration.Type },
    { "datetime", DateTimeZone.Type },
    { "bool",     Logical.Type },
    { "guid",     Text.Type },
    { "dynamic",  Text.Type }
    }),
    DataTable = Source[tables]{0},
    Columns = Table.FromRecords(DataTable[columns]),
    ColumnsWithType = Table.Join(Columns, {"type"}, TypeMap , {"AnalyticsTypes"}),
    Rows = Table.FromRows(DataTable[rows], Columns[name]), 
    Table = Table.TransformColumnTypes(Rows, Table.ToList(ColumnsWithType, (c) => { c{0}, c{3}}))
in
Table

Saat refresh bertahap dikonfigurasi, ekspresi Power Query yang menyertakan filter tanggal/waktu berdasarkan parameter RangeStart dan RangeEnd dijalankan terhadap sumber data. Jika filter ditentukan dalam langkah kueri setelah kueri sumber awal, penting bahwa pelipatan kueri menggabungkan langkah kueri awal dengan langkah-langkah mereferensikan parameter RangeStart dan RangeEnd. Misalnya, dalam ekspresi kueri berikut, Table.SelectRows akan terlipat karena segera mengikuti Sql.Database langkah, dan SQL Server mendukung pelipatan:

let
  Source = Sql.Database("dwdev02","AdventureWorksDW2017"),
  Data  = Source{[Schema="dbo",Item="FactInternetSales"]}[Data],
  #"Filtered Rows" = Table.SelectRows(Data, each [OrderDateKey] >= Int32.From(DateTime.ToText(RangeStart,[Format="yyyyMMdd"]))),
  #"Filtered Rows1" = Table.SelectRows(#"Filtered Rows", each [OrderDateKey] < Int32.From(DateTime.ToText(RangeEnd,[Format="yyyyMMdd"])))
  
in
  #"Filtered Rows1"

Tidak ada persyaratan lipatan dukungan kueri akhir. Misalnya dalam ekspresi berikut, kami menggunakan NativeQuery non-lipat tetapi mengintegrasikan parameter RangeStart dan RangeEnd langsung ke SQL:

let
  Query = "select * from dbo.FactInternetSales where OrderDateKey >= '"& Text.From(Int32.From( DateTime.ToText(RangeStart,"yyyyMMdd") )) &"' and OrderDateKey < '"& Text.From(Int32.From( DateTime.ToText(RangeEnd,"yyyyMMdd") )) &"' ",
  Source = Sql.Database("dwdev02","AdventureWorksDW2017"),
  Data = Value.NativeQuery(Source, Query, null, [EnableFolding=false])
in
  Data

Namun, jika kebijakan refresh bertambah bertahap termasuk 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 kueri, peringatan diperlihatkan dalam dialog Konfigurasi kebijakan refresh bertahas.

Screenshot of the query folding warning

Jika Anda melihat peringatan ini dan ingin memverifikasi bahwa pelipatan 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 Anda mengonfigurasi refresh bertambah bertahap dan data real time dengan menggunakan Power BI Desktop, atau mengonfigurasi solusi tingkat lanjut dengan menggunakan Bahasa Pembuatan Skrip Model Tabular (TMSL) atau Model Objek Tabular (TOM) melalui titik akhir XMLA, semua partisi, baik impor atau DirectQuery, harus meminta data dari satu sumber.

Jenis sumber data lainnya

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

Batas waktu

Terlepas dari refresh bertahap, model Power BI Pro memiliki batas waktu refresh dua jam dan tidak mendukung mendapatkan data real-time dengan DirectQuery. Untuk model 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 model saja, karena layanan mempertahankan rekam jepret model dalam memori sampai 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 inkremental mengoptimalkan operasi refresh pada tingkat partisi dalam model, konsumsi sumber daya dapat dikurangi secara signifikan. Pada saat yang sama, bahkan dengan refresh bertahap, kecuali jika mereka melalui titik akhir XMLA, operasi refresh terikat oleh batas dua jam dan lima jam yang sama. Kebijakan refresh inkremental yang efektif tidak hanya mengurangi jumlah data yang diproses dengan operasi refresh, tetapi juga mengurangi jumlah data historis yang tidak perlu yang disimpan dalam model 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 model yang sangat besar dalam kapasitas Premium yang kemungkinan berisi miliaran baris, operasi refresh awal dapat di-bootstrap. Bootstrapping memungkinkan layanan membuat objek tabel dan partisi untuk model, tetapi tidak memuat dan memproses data ke salah satu partisi. Dengan menggunakan SQL Server Management Studio, Anda dapat mengatur partisi yang akan diproses secara individual, berurutan, atau paralel, untuk mengurangi jumlah data yang dikembalikan dalam satu kueri, dan juga melewati batas waktu lima jam. Untuk mempelajari selengkapnya, lihat Refresh inkremental 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 model dalam layanan, zona waktu yang ditentukan diperhitungkan 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 menentukan tanggal dan waktu saat ini berdasarkan Waktu Pasifik, bukan Waktu Universal Terkoordinasi (UTC), yang akan mengembalikan hari berikutnya. Operasi refresh tidak dipanggil melalui layanan Power BI, seperti perintah refresh TMSL, tidak mempertimbangkan zona waktu refresh terjadwal.

Screenshot of Scheduled refresh dialog showing the Time zone input field

Mengonfigurasi refresh bertahap dan data real-time

Bagian ini menjelaskan konsep penting untuk mengonfigurasi refresh inkremental dan data real time. Saat Anda siap untuk instruksi langkah demi langkah yang lebih terperinci, lihat Mengonfigurasi refresh bertambah bertahap dan data real time untuk model semantik.

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

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

Membuat parameter

Untuk mengonfigurasi refresh inkremental di Power BI Desktop, Anda terlebih dahulu membuat dua parameter tanggal/waktu Power Query dengan nama peka huruf besar/kecil yang dipesan RangeStart dan RangeEnd. 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 hanya menyertakan baris tersebut dengan tanggal/waktu dalam periode tersebut. RangeStart mewakili tanggal/waktu terlama, atau paling awal, dan RangeEnd mewakili tanggal/waktu terbaru, atau terbaru. Setelah model diterbitkan ke layanan, RangeStart dan RangeEnd ditimpa secara otomatis oleh layanan untuk mengkueri data yang ditentukan oleh periode refresh yang ditentukan dalam pengaturan kebijakan refresh bertahap.

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

Screenshot of the Manage Parameters dialog showing the RangeStart and RangeEnd parameters.

Filter data

RangeStart Dengan parameter dan RangeEnd yang ditentukan, Anda menerapkan filter tanggal kustom pada kolom tanggal tabel Anda. Filter yang Anda terapkan memilih subkumpulan data yang dimuat ke dalam model saat Anda memilih Terapkan.

Screenshot of column context menu with Custom Filter selected

Dengan contoh FactInternetSales kami, setelah membuat filter berdasarkan parameter dan menerapkan langkah-langkah, dua hari data (sekitar 20.000 baris) dimuat ke dalam model.

Tentukan kebijakan

Setelah filter diterapkan dan subset data telah dimuat ke dalam model, Anda 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 menggunakan kotak dialog Refresh inkremental dan data real time untuk menentukan pengaturan yang diperlukan dan opsional.

Screenshot of the Incremental refresh and real-time data dialog showing the Incrementally refresh this table option on.

Table

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 RangeStart parameter dan RangeEnd , tombol tidak tersedia.

Pengaturan yang Diperlukan

Pengaturan Tanggal arsip data yang dimulai sebelum refresh menentukan periode historis di mana baris dengan tanggal/waktu dalam periode tersebut disertakan dalam model, ditambah baris untuk periode historis yang tidak lengkap saat ini, ditambah baris dalam periode refresh hingga tanggal dan waktu saat ini.

Misalnya, jika Anda menentukan lima tahun, tabel menyimpan lima tahun terakhir data historis dalam partisi tahun. Tabel juga akan menyertakan baris untuk partisi kuartal, bulan, atau hari saat ini, hingga dan termasuk periode refresh.

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

Pengaturan Tanggal refresh bertahap yang 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 Anda menentukan periode refresh tiga hari, dengan setiap operasi refresh, layanan akan mengambil alih RangeStart parameter dan RangeEnd untuk membuat kueri untuk baris dengan tanggal/waktu dalam periode tiga hari, dengan awal dan akhir tergantung pada tanggal dan waktu saat ini. Baris dengan tanggal/waktu dalam tiga hari terakhir hingga waktu operasi refresh saat ini disegarkan. Dengan jenis kebijakan ini, Anda dapat mengharapkan tabel model FactInternetSales kami dalam layanan, yang rata-rata 10.000 baris baru per hari, untuk menyegarkan sekitar 30.000 baris dengan setiap operasi refresh.

Tentukan periode yang hanya menyertakan jumlah minimum baris yang diperlukan untuk memastikan pelaporan yang akurat. Saat Anda menentukan kebijakan untuk lebih dari satu tabel, parameter dan RangeEnd yang sama RangeStart harus digunakan bahkan jika 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 model.

Misalnya, jika pengaturan ini diaktifkan, dengan setiap operasi refresh, layanan masih mengambil alih RangeStart parameter dan RangeEnd untuk membuat kueri untuk baris dengan tanggal/waktu setelah periode refresh, dengan awal tergantung pada tanggal dan waktu saat ini. Baris dengan tanggal/waktu setelah waktu operasi refresh saat ini juga disertakan. Dengan jenis kebijakan ini, tabel model FactInternetSales dalam layanan menyertakan pembaruan data terbaru.

Pengaturan Hanya refresh hari selesai memastikan semua baris untuk sepanjang hari disertakan dalam operasi refresh. Pengaturan ini bersifat opsional kecuali Anda mengaktifkan pengaturan Dapatkan data terbaru secara real time dengan DirectQuery (khusus Premium). Misalnya, 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 merefresh data dari sistem keuangan di mana data untuk bulan sebelumnya disetujui pada hari kalender ke-12 dalam sebulan. Anda dapat mengatur periode refresh menjadi satu bulan dan menjadwalkan refresh untuk dijalankan pada hari kedua belas 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.

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. Pengaturan ini mengasumsikan kolom seperti itu ada di sumber data, yang biasanya untuk tujuan audit. Kolom ini seharusnya bukan kolom yang sama yang digunakan untuk mempartisi data dengan RangeStart parameter dan RangeEnd . Nilai maksimum kolom ini dievaluasi untuk setiap periode dalam rentang bertahap. Jika belum berubah sejak refresh terakhir, tidak perlu menyegarkan periode, yang berpotensi mengurangi hari-hari yang disegarkan secara bertahap dari tiga menjadi satu.

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 bertahannya kolom pembaruan terakhir di cache dalam memori, atau mengaktifkan skenario di mana tabel konfigurasi/instruksi disiapkan dengan proses extract-transform-load (ETL) untuk menandai hanya partisi yang perlu disegarkan. Dalam kasus seperti ini, untuk kapasitas Premium, gunakan TMSL dan/atau TOM untuk mengambil alih perilaku mendeteksi 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 model.

Catatan

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

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

Penting

Setelah Power BI Desktop menerbitkan model ke layanan, Anda tidak dapat mengunduh kembali .pbix tersebut .

Segarkan

Setelah menerbitkan ke layanan, Anda melakukan operasi refresh awal pada model. Refresh 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 dimuat, objek seperti hubungan dan hierarki yang dibangun atau dibangun kembali, dan objek terhitung dihitung ulang.

Operasi refresh berikutnya, baik individu atau terjadwal, jauh lebih cepat karena hanya partisi refresh inkremental yang disegarkan. Operasi pemrosesan lainnya masih harus terjadi, seperti menggabungkan partisi dan penghitungan ulang, tetapi biasanya membutuhkan waktu yang jauh lebih sedikit daripada refresh awal.

Refresh laporan otomatis

Untuk laporan yang menggunakan model 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 model Anda berada pada kapasitas Premium dengan titik akhir XMLA diaktifkan, refresh bertambah 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 semarak di mana MVP, pro BI, dan rekan berbagi keahlian dalam grup diskusi, video, blog, dan banyak lagi. Saat mempelajari tentang refresh inkremental, lihat sumber daya berikut: