Mengonfigurasi penyegaran bertahap dan data real-time untuk model semantik Power BI

Refresh bertahap dan data real time untuk model semantik di Power BI menyediakan cara yang efisien untuk menangani data dinamis dan meningkatkan performa refresh model. Dengan mengotomatiskan pembuatan dan manajemen partisi, refresh inkremental mengurangi jumlah data yang perlu di-refresh dan memungkinkan penyertaan data real-time. Artikel ini menjelaskan cara mengonfigurasi dan menggunakan fitur refresh inkremental di Power BI untuk mengambil data yang bergerak cepat dan meningkatkan performa.

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:

  • Lebih sedikit siklus refresh untuk data yang berubah cepat diperlukan: Mode DirectQuery mendapatkan pembaruan data terbaru saat kueri diproses, tanpa memerlukan irama refresh yang tinggi.
  • Refresh lebih cepat: Hanya data terbaru yang berubah yang perlu disegarkan.
  • Refresh lebih dapat diandalkan: Koneksi jangka panjang ke sumber data volatil tidak diperlukan. Kueri untuk sumber data berjalan lebih cepat, mengurangi potensi gangguan dari masalah jaringan.
  • 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 menyegarkan seluruh model dengan setiap operasi refresh.
  • Penyiapan sangat mudah: Kebijakan refresh bertahap ditentukan di Power BI Desktop hanya dengan beberapa langkah sederhana. 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 disediakan RangeStart dan peka huruf besar/kecil 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 diperbarui. Baris dengan tanggal/waktu yang tidak lagi termasuk dalam periode penyegaran kemudian menjadi bagian dari periode historis, yang tidak diperbarui. 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 penyegaran bertahap baru dibuat, partisi yang tidak lagi berada dalam periode penyegaran akan 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.

Grafik yang mewakili pola jendela bergulir.

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 rencana 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

Penyegaran inkremental dan data real-time berfungsi paling baik untuk sumber data terstruktur dan relasional 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 dari jenis data tanggal/waktu atau 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 lebih lanjut, lihat Mengonfigurasi refresh inkremental dan data real time - 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 penyegaran inkremental pelacakan dari instance 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 pada langkah kueri setelah kueri sumber awal, penting agar pelipatan kueri menggabungkan langkah kueri awal dengan langkah-langkah yang mereferensikan parameter RangeStart dan RangeEnd. Misalnya, dalam ekspresi kueri berikut, Table.SelectRows lipatan 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 untuk kueri akhir dalam mendukung pelipatan. Misalnya, dalam ekspresi berikut, kami menggunakan NativeQuery nonfolding 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 penyegaran bertahap termasuk untuk mendapatkan data real-time dengan DirectQuery, transformasi nonfolding 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 memerlukan pengambilan semua baris untuk tabel dari sumber data. Hal ini dapat menyebabkan refresh inkremental menjadi lambat, dan prosesnya dapat kehabisan sumber daya baik di layanan Power BI atau di gateway data lokal - secara efektif mengalahkan tujuan refresh inkremental.

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 ditampilkan dalam dialog kebijakan konfigurasi refresh bertahap.

Cuplikan layar peringatan penggabungan kueri

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 belum terjadi, pastikan bahwa logika filter sudah termasuk 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 dengan panduan pelipatan kueri secara menyeluruh di Power BI Desktop dan pelipatan kueri Power Query. Artikel-artikel berikut dapat membantu Anda menentukan apakah sumber data dan kueri Anda mendukung pelipatan kueri.

Sumber data tunggal

Saat Anda mengonfigurasi refresh bertahap dan data real time dengan menggunakan Power BI Desktop, atau mengonfigurasi solusi tingkat lanjut dengan menggunakan Bahasa Skrip Model Tabular (TMSL) atau Model Objek Tabular (TOM) melalui titik akhir XMLA, semua partisi, baik itu 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 intensif memori. 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 intensif proses, menggunakan 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 penyegaran bertahap, kecuali jika dilakukan melalui titik akhir XMLA, operasi penyegaran tetap terikat pada batas waktu 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 berikut menggunakan fungsi akses data SQL Server untuk mengatur CommandTimeout menjadi dua 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, pemulihan awal dapat dimulai. 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 - Menghindari batas waktu pada refresh lengkap awal.

Tanggal dan waktu saat ini

Secara default, tanggal dan waktu saat ini ditentukan berdasarkan Waktu Universal Terkoordinasi (UTC) pada saat refresh. Untuk refresh sesuai permintaan, terjadwal, dan REST API, Anda dapat mengonfigurasi zona waktu yang berbeda di bawah 'Refresh' yang akan diperhitungkan saat menentukan tanggal dan waktu saat ini. Misalnya, refresh yang terjadi pada pukul 20:00 Waktu Pasifik (AS dan Kanada) dengan zona waktu yang dikonfigurasi menentukan tanggal dan waktu saat ini berdasarkan Waktu Pasifik, bukan UTC, yang akan mengembalikan hari berikutnya.

Cuplikan layar dialog Refresh terjadwal memperlihatkan bidang Input zona waktu

Operasi refresh yang tidak dipanggil melalui layanan Power BI, seperti perintah refresh XMLA TMSL, tidak mempertimbangkan konfigurasi zona waktu dan menggunakan UTC secara default.

Mengonfigurasi penyegaran 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 inkremental dan data waktu nyata.

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. Pembaruan bertahap dengan data real-time hanya didukung untuk Power BI Premium.

Membuat parameter

Untuk mengonfigurasi refresh inkremental di Power BI Desktop, pertama-tama Anda membuat dua parameter tanggal/waktu Power Query dengan nama-nama yang dipesan dan peka huruf besar/kecil 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.

Catatan

Anda perlu mereferensikan parameter ini secara manual dalam ekspresi filter - parameter tersebut tidak dapat digunakan melalui antarmuka pengguna Filter Kustom standar.

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 mem-query data yang ditentukan oleh periode pemutakhiran yang ditentukan dalam pengaturan kebijakan penyegaran 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.

Cuplikan layar dialog Kelola Parameter memperlihatkan parameter RangeStart dan RangeEnd.

Penyaringan data

RangeStart Dengan parameter dan RangeEnd yang ditentukan, Anda perlu membuat filter berparameter pada kolom tanggal tabel Anda. Anda tidak dapat menggunakan opsi UI "Filter Kustom" standar untuk ini - sebagai gantinya, Anda harus menambahkan langkah-langkah filter secara manual yang mereferensikan parameter.

Di Editor Power Query, tambahkan langkah-langkah pemfilteran:

  1. Pilih Tambahkan Langkah, atau ubah kueri langsung di bilah rumus.
  2. Table.SelectRows Gunakan fungsi untuk membuat filter yang mereferensikan parameter Anda.
  3. Terapkan langkah-langkah filter terpisah untuk kondisi tanggal mulai dan berakhir.

Misalnya, untuk memfilter menurut OrderDateKey:

#"Filtered Rows" = Table.SelectRows(Source, each [OrderDateKey] >= Int32.From(DateTime.ToText(RangeStart,[Format="yyyyMMdd"]))),
#"Filtered Rows1" = Table.SelectRows(#"Filtered Rows", each [OrderDateKey] < Int32.From(DateTime.ToText(RangeEnd,[Format="yyyyMMdd"])))

Cuplikan layar menu konteks kolom dengan Filter Kustom dipilih

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 Penyegaran inkremental dan data real-time untuk mengatur pengaturan yang diperlukan dan opsional.

Cuplikan layar dialog Refresh bertahap dan data real time memperlihatkan opsi Refresh tabel ini secara bertahap.

Tabel

Kotak daftar Pilih tabel secara otomatis memilih tabel yang Anda pilih di tampilan Tabel. Aktifkan refresh bertahap untuk tabel dengan penggeser. Jika ekspresi Power Query untuk tabel tidak menyertakan filter berdasarkan parameter RangeStart dan RangeEnd, sakelar tidak tersedia.

Pengaturan yang Diperlukan

Arsip data yang dimulai sebelum tanggal refresh ditentukan sebagai periode historis di mana baris dengan tanggal/waktu dalam periode tersebut disertakan dalam model, juga mencakup baris untuk periode historis saat ini yang belum lengkap, serta baris dalam periode refresh hingga tanggal dan waktu sekarang.

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

Untuk model dalam kapasitas Premium, partisi historis yang diumumkan sebelumnya dapat disegarkan secara selektif pada tingkat granularitas yang ditetapkan oleh pengaturan ini. Untuk mempelajari selengkapnya, lihat Penyegaran bertingkat lanjut - Partisi.

Pengaturan refresh bertahap pada data 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 penyegaran saat ini diperbarui. 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 RangeStart dan RangeEnd yang sama harus digunakan meskipun periode penyimpanan dan pembaruan yang berbeda ditetapkan 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 hari lengkap yang di-refresh memastikan semua baris untuk seluruh hari disertakan dalam operasi penyegaran. Pengaturan ini bersifat opsional kecuali Anda mengaktifkan pengaturan Dapatkan data terbaru secara real time dengan DirectQuery (khusus Premium). Misalnya, refresh Anda dijadwalkan untuk dijalankan 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 parsial. Contoh lain adalah memperbarui data dari sistem keuangan di mana data untuk bulan sebelumnya disetujui pada hari kalender ke-12 bulan tersebut. Anda dapat mengatur periode refresh menjadi satu bulan dan menjadwalkan refresh untuk dijalankan pada hari kedua belas dalam sebulan. Jika opsi ini dipilih, misalnya, data Januari akan di-refresh pada 12 Februari.

Perlu diingat, kecuali zona waktu di bawah 'Refresh' dikonfigurasi untuk zona waktu non-UTC, operasi refresh dalam layanan berjalan di bawah waktu UTC, yang dapat memengaruhi penentuan tanggal efektif dan periode lengkap.

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 parameter RangeStart dan RangeEnd. Nilai maksimum kolom ini dievaluasi untuk setiap periode dalam rentang bertahap. Jika belum berubah sejak penyegaran terakhir, tidak perlu melakukan penyegaran periode, yang berpotensi mengurangi hari-hari yang diperbarui 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 Anda berpikir bahwa model mungkin tumbuh melebihi 1 GB, Anda dapat meningkatkan performa operasi refresh dan memastikan model tidak melampaui batas ukuran dengan mengaktifkan pengaturan format Penyimpanan Model Semantik 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 itu.

Muat Ulang

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, misalnya hubungan dan hierarki, dibuat 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.

Pembaruan otomatis laporan

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.

Penyegaran bertahap lanjutan

Jika model Anda berada pada kapasitas Premium dengan titik akhir XMLA diaktifkan, penyegaran bertahap dapat lebih jauh dikembangkan untuk skenario yang lebih kompleks. Misalnya, Anda dapat menggunakan SQL Server Management Studio untuk melihat dan mengelola partisi, memulai proses penyegaran awal, atau menyegarkan partisi historis yang sudah lampau. 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 ini:

Konten terkait

  • Last updated on