Bagikan melalui

Refresh bertahap tingkat lanjut dan data real-time dengan titik akhir XMLA

  • Artikel

Model semantik dalam kapasitas Premium dengan titik akhir XMLA yang diaktifkan untuk operasi baca/tulis memungkinkan penyegaran yang lebih canggih, manajemen partisi, dan penyebaran metadata hanya melalui alat, pembuatan skrip, dan dukungan API. Selain itu, operasi refresh melalui titik akhir XMLA tidak terbatas pada 48 refresh per hari, dan batas waktu refresh terjadwal tidak diberlakukan.

Partisi

Partisi tabel model semantik tidak terlihat dan tidak dapat dikelola dengan menggunakan Power BI Desktop atau layanan Power BI. Untuk model di ruang kerja yang ditetapkan ke kapasitas Premium, partisi dapat dikelola melalui titik akhir XMLA dengan menggunakan alat seperti SQL Server Management Studio (SSMS), Editor Tabular sumber terbuka, diskrip dengan Tabular Model Scripting Language (TMSL), dan secara terprogram dengan Model Objek Tabular (TOM).

Ketika Anda pertama kali menerbitkan model ke layanan Power BI, setiap tabel dalam model baru memiliki satu partisi. Untuk tabel tanpa kebijakan refresh bertahap, bahwa satu partisi berisi semua baris data untuk tabel tersebut, kecuali filter telah diterapkan. Untuk tabel dengan kebijakan refresh bertambah bertahap, satu partisi awal hanya ada karena Power BI belum menerapkan kebijakan. Anda mengonfigurasi partisi awal di Power BI Desktop saat menentukan filter rentang tanggal/waktu untuk tabel Anda berdasarkan RangeStart parameter dan RangeEnd , dan filter lain yang diterapkan di Editor Power Query. Partisi awal ini hanya berisi baris data yang memenuhi kriteria filter Anda.

Saat Anda melakukan operasi refresh pertama , tabel tanpa kebijakan refresh bertahap me-refresh semua baris yang terkandung dalam partisi tunggal default tabel tersebut. Untuk tabel dengan kebijakan refresh bertahap, partisi refresh dan historis dibuat secara otomatis dan baris dimuat ke dalamnya sesuai dengan tanggal/waktu untuk setiap baris. Jika kebijakan refresh bertahap mendapatkan data secara real time, Power BI juga menambahkan partisi DirectQuery ke tabel.

Operasi refresh pertama ini dapat memakan waktu cukup lama bergantung pada jumlah data yang perlu dimuat dari sumber data. Kompleksitas model juga dapat menjadi faktor yang signifikan karena operasi refresh harus melakukan lebih banyak pemrosesan dan penghitungan ulang. Operasi ini dapat di-bootstrap. Untuk informasi selengkapnya, lihat Mencegah batas waktu pada refresh penuh awal.

Partisi dibuat dan dinamai berdasarkan granularitas periode: Tahun, kuartal, bulan, dan hari. Partisi terbaru, partisi refresh , berisi baris dalam periode refresh yang Anda tentukan dalam kebijakan. Partisi historis berisi baris menurut periode lengkap hingga periode refresh. Jika real time diaktifkan, partisi DirectQuery mengambil perubahan data apa pun yang terjadi setelah tanggal akhir periode refresh. Granularitas untuk refresh dan partisi historis bergantung pada periode refresh dan historis (penyimpanan) yang Anda pilih saat menentukan kebijakan.

Misalnya, jika tanggal hari ini adalah 2 Februari 2021 dan tabel FactInternetSales kami di sumber data berisi baris hingga hari ini, jika kebijakan kami menentukan untuk menyertakan perubahan real time, refresh baris dalam periode refresh satu hari terakhir, dan menyimpan baris dalam periode historis tiga tahun terakhir. Kemudian dengan operasi refresh pertama, partisi DirectQuery dibuat untuk perubahan di masa depan, partisi impor baru dibuat untuk baris hari ini, partisi historis dibuat untuk kemarin, periode sepanjang hari, 1 Februari 2021. Partisi historis dibuat untuk periode seluruh bulan sebelumnya (Januari 2021), partisi historis dibuat untuk periode seluruh tahun sebelumnya (2020), dan partisi historis untuk periode tahun 2019 dan 2018 dibuat. Tidak ada seluruh partisi kuartal yang dibuat karena kami belum menyelesaikan kuartal penuh pertama 2021.

Diagram shows the partition naming granularity described in the text.

Dengan setiap operasi refresh, hanya partisi periode refresh yang di-refresh dan filter tanggal partisi DirectQuery diperbarui untuk hanya menyertakan perubahan yang terjadi setelah periode refresh saat ini. Partisi refresh baru dibuat untuk baris baru dengan tanggal/waktu baru dalam periode refresh yang diperbarui, dan baris yang sudah ada dengan tanggal/waktu yang sudah ada dalam partisi yang ada dalam periode refresh disegarkan dengan pembaruan. Baris dengan tanggal/waktu yang lebih lama dari periode refresh tidak lagi di-refresh.

Saat seluruh periode ditutup, partisi digabungkan. Misalnya, jika periode refresh satu hari dan periode penyimpanan historis tiga tahun ditentukan dalam kebijakan, pada hari pertama dalam sebulan, partisi sepanjang hari untuk bulan sebelumnya digabungkan menjadi partisi bulan. Pada hari pertama kuartal baru, ketiga partisi bulan sebelumnya digabungkan menjadi partisi seperempat. Pada hari pertama tahun baru, keempat partisi kuartal sebelumnya digabungkan menjadi partisi setahun.

Model selalu mempertahankan partisi untuk seluruh periode penyimpanan historis ditambah partisi seluruh periode hingga periode refresh saat ini. Dalam contoh, tiga tahun penuh data historis disimpan dalam partisi untuk 2018, 2019, 2020, dan juga partisi untuk periode bulan 2021Q101, periode hari 2021Q10201, dan partisi periode refresh hari saat ini. Karena contoh menyimpan data historis selama tiga tahun, partisi 2018 dipertahankan hingga refresh pertama pada 1 Januari 2022.

Dengan refresh bertahap Power BI dan data real-time, layanan menangani manajemen partisi untuk Anda berdasarkan kebijakan. Meskipun layanan dapat menangani semua manajemen partisi untuk Anda, dengan menggunakan alat melalui titik akhir XMLA, Anda dapat secara selektif menyegarkan partisi satu per satu, secara berurutan, atau paralel.

Refresh manajemen dengan SQL Server Management Studio

SQL Server Management Studio (SSMS) dapat digunakan untuk melihat dan mengelola partisi yang dibuat oleh penerapan kebijakan refresh bertahap. Dengan menggunakan SQL Server Management Studio, Anda dapat me-refresh partisi historis tertentu yang tidak dalam periode refresh bertahap untuk melakukan pembaruan tanggal ulang tanpa harus me-refresh semua data historis. SSMS juga dapat digunakan saat bootstrapping untuk memuat data historis untuk model besar dengan menambahkan/menyegarkan partisi historis secara bertahap dalam batch.

Screenshot shows the Partitions window in SSMS.

Mengambil alih perilaku refresh bertahap

Dengan SQL Server Management Directory, Anda juga memiliki kontrol lebih atas cara memanggil refresh dengan menggunakan Bahasa Skrip Model Tabular dan Model Objek Tabular. Misalnya, di SQL Server Management Studio, di Object Explorer, klik kanan tabel lalu pilih opsi menu Tabel Proses, lalu pilih tombol Skrip untuk menghasilkan perintah refresh TMSL.

Screenshot shows the Script button in Process Table dialog.

Parameter ini dapat digunakan dengan perintah refresh TMSL untuk mengambil alih perilaku refresh bertahap default:

  • applyRefreshPolicy. Jika tabel memiliki kebijakan refresh bertahap yang ditentukan, applyRefreshPolicy menentukan apakah kebijakan diterapkan atau tidak. Jika kebijakan tidak diterapkan, operasi penuh proses membuat definisi partisi tidak berubah dan semua partisi dalam tabel sepenuhnya disegarkan. Nilai defaultnya adalah true.

  • effectiveDate. Jika kebijakan refresh bertahap diterapkan, perlu mengetahui tanggal saat ini untuk menentukan rentang jendela bergulir untuk refresh bertahap dan periode historis. Parameter effectiveDate memungkinkan Anda mengambil alih tanggal saat ini. Parameter ini berguna untuk pengujian, demo, dan skenario bisnis di mana data disegarkan secara bertahap hingga tanggal di masa lalu atau di masa mendatang, misalnya, anggaran di masa mendatang. Nilai defaultnya adalah tanggal saat ini.

{ 
  "refresh": {
    "type": "full",

    "applyRefreshPolicy": true,
    "effectiveDate": "12/31/2013",

    "objects": [
      {
        "database": "IR_AdventureWorks", 
        "table": "FactInternetSales" 
      }
    ]
  }
}

Untuk mempelajari selengkapnya tentang mengesampingkan perilaku refresh bertahap default dengan TMSL, lihat Perintah refresh.

Memastikan performa optimal

Dengan setiap operasi refresh, layanan Power BI mungkin mengirim kueri inisialisasi ke sumber data untuk setiap partisi refresh bertahap. Anda mungkin dapat meningkatkan performa refresh bertambah bertahap dengan mengurangi jumlah kueri inisialisasi dengan memastikan konfigurasi berikut:

  • Tabel yang Anda konfigurasikan menggunakan refresh bertahap harus mendapatkan data dari satu sumber data. Jika tabel mendapatkan data dari lebih dari satu sumber data, jumlah kueri yang dikirim oleh layanan untuk setiap operasi refresh dikalikan dengan jumlah sumber data, yang berpotensi mengurangi performa refresh. Pastikan kueri untuk tabel refresh bertahap adalah untuk satu sumber data.
  • Untuk solusi dengan refresh bertahap partisi impor dan data real-time dengan Direct Query, semua partisi harus mengkueri data dari satu sumber data.
  • Jika persyaratan keamanan Anda mengizinkan, atur pengaturan Tingkat privasi sumber data ke Organisasi atau Publik. Secara default, tingkat privasi adalah Privat, namun tingkat ini dapat mencegah data ditukar dengan sumber cloud lainnya. Untuk mengatur tingkat privasi, pilih menu Opsi lainnya lalu pilih Pengaturan> Pengaturan privasi Edit kredensial>>sumber data ini. Jika Tingkat privasi diatur dalam model Power BI Desktop sebelum diterbitkan ke layanan, tingkat privasi tidak ditransfer ke layanan saat Anda menerbitkan. Anda masih harus mengaturnya dalam pengaturan model semantik dalam layanan. Untuk mempelajari selengkapnya, lihat Tingkat privasi.
  • Jika menggunakan Gateway Data Lokal, pastikan Anda menggunakan versi 3000.77.3 atau yang lebih tinggi.

Mencegah waktu habis pada refresh penuh awal

Setelah Anda mempublikasikan ke layanan Power BI, operasi refresh penuh awal untuk model membuat partisi untuk tabel refresh inkremental, memuat, dan memproses data historis untuk seluruh periode yang ditentukan dalam kebijakan refresh inkremental. Untuk beberapa model yang memuat dan memproses data dalam jumlah besar, jumlah waktu yang diperlukan operasi refresh awal dapat melebihi batas waktu refresh yang diberlakukan oleh layanan atau batas waktu kueri yang diberlakukan oleh sumber data.

Proses bootstrap operasi refresh awal memungkinkan layanan untuk membuat objek partisi pada tabel refresh bertahap, tetapi tidak memuat dan memproses data historis ke salah satu partisi. SQL Server Management Studio kemudian digunakan untuk memproses partisi secara selektif. Bergantung pada jumlah data yang akan dimuat untuk setiap partisi, Anda dapat memproses setiap partisi secara berurutan atau dalam batch kecil untuk mengurangi potensi waktu habis pada satu atau beberapa partisi tersebut. Metode berikut berfungsi untuk sumber data apa pun.

Menerapkan Kebijakan Refresh

Alat Tabular Editor 2 sumber terbuka menyediakan cara mudah untuk bootstrap operasi refresh awal. Setelah menerbitkan model dengan kebijakan refresh inkremental yang ditentukan untuknya dari Power BI Desktop ke layanan, sambungkan ke model dengan menggunakan titik akhir XMLA dalam mode Baca/Tulis. Jalankan Terapkan Kebijakan Refresh pada tabel refresh bertahap. Dengan menerapkan kebijakan tersebut, partisi dibuat tetapi tidak ada data yang dimuat ke dalamnya. Kemudian sambungkan dengan SQL Server Management Studio untuk me-refresh partisi secara berurutan atau dalam batch guna memuat dan memproses data. Untuk informasi selengkapnya, lihat Refresh inkremental di dokumentasi editor Tabular.

Screenshot show the Tabular Editor with Apply Refresh Policy selected.

Filter Power Query untuk partisi kosong

Sebelum menerbitkan model ke layanan, di Editor Power Query, tambahkan filter lain ke ProductKey kolom yang memfilter nilai apa pun selain 0, secara efektif atau memfilter semua data dari tabel FactInternetSales.

Screenshot shows the Power Query Editor with code that filters out the product key.

Setelah memilih Tutup & Terapkan di Editor Power Query, tentukan kebijakan refresh bertahap, dan simpan model, model diterbitkan ke layanan. Dari layanan, operasi refresh awal dijalankan pada model. Partisi untuk tabel FactInternetSales dibuat sesuai dengan kebijakan, tetapi tidak ada data yang dimuat dan diproses karena semua data difilter.

Setelah operasi refresh awal selesai, kembali ke Editor Power Query, filter lain pada ProductKey kolom dihapus. Setelah memilih Tutup & Terapkan di Editor Power Query dan menyimpan model, model tidak diterbitkan lagi. Jika model diterbitkan lagi, model akan menimpa pengaturan kebijakan refresh bertahap dan memaksa refresh penuh pada model saat operasi refresh berikutnya dilakukan dari layanan. Sebagai gantinya, lakukan penyebaran metadata hanya dengan menggunakan Toolkit Manajemen Siklus Hidup Aplikasi (ALM) yang menghapus filter pada ProductKey kolom dari model. Kemudian SQL Server Management Studio dapat digunakan untuk memproses partisi secara selektif. Ketika semua partisi telah diproses sepenuhnya, yang harus menyertakan pengkalkulasian ulang proses pada semua partisi, dari SSMS, operasi refresh berikutnya pada model dari layanan hanya me-refresh partisi refresh inkremental.

Tip

Pastikan untuk melihat video, blog, dan lebih banyak lagi yang disediakan oleh komunitas pakar BI di Power BI.

Untuk mempelajari selengkapnya tentang memproses tabel dan partisi dari SQL Server Management Studio, lihat Memproses database, tabel, atau partisi (Azure Analysis Services). Untuk mempelajari selengkapnya tentang memproses model, tabel, dan partisi dengan menggunakan TMSL, lihat Perintah refresh (TMSL).

Kueri kustom untuk mendeteksi perubahan data

TMSL dan TOM dapat digunakan untuk mengambil alih perilaku perubahan data yang terdeteksi. Metode ini tidak hanya dapat digunakan untuk menghindari bertahannya kolom pembaruan terakhir dalam cache dalam memori, metode ini dapat mengaktifkan skenario di mana konfigurasi atau tabel instruksi disiapkan dengan mengekstrak, mengubah, dan memuat (ETL) proses untuk menandai hanya partisi yang perlu disegarkan. Metode ini dapat membuat proses refresh bertahap yang lebih efisien di mana hanya periode yang diperlukan yang di-refresh, tidak peduli berapa lama pembaruan data berlangsung.

pollingExpression dimaksudkan untuk menjadi ekspresi M yang ringan atau nama kueri M lainnya. Seharusnya memunculkan nilai skalar dan akan dijalankan untuk setiap partisi. Jika nilai yang dikembalikan berbeda dengan apa yang terakhir kali terjadi refresh bertahap, partisi ditandai untuk pemrosesan penuh.

Contoh berikut mencakup semua 120 bulan dalam periode historis untuk perubahan yang didukung. Menentukan 120 bulan alih-alih 10 tahun berarti kompresi data mungkin tidak cukup efisien, tetapi menghindari harus menyegarkan seluruh tahun historis, yang akan lebih mahal ketika sebulan akan cukup untuk perubahan yang didukung.

"refreshPolicy": {
    "policyType": "basic",
    "rollingWindowGranularity": "month",
    "rollingWindowPeriods": 120,
    "incrementalGranularity": "month",
    "incrementalPeriods": 120,
    "pollingExpression": "<M expression or name of custom polling query>",
    "sourceExpression": [
    "let ..."
    ]
}

Tip

Pastikan untuk melihat video, blog, dan lebih banyak lagi yang disediakan oleh komunitas pakar BI di Power BI.

Penyebaran metadata saja

Saat menerbitkan versi baru file .pbix dari Power BI Desktop ke ruang kerja, jika model dengan nama yang sama sudah ada, Anda akan diminta untuk mengganti model yang sudah ada.

Screenshot shows the Replace model dialog.

Dalam beberapa kasus, Anda mungkin tidak ingin mengganti model, terutama dengan refresh inkremental. Model di Power BI Desktop bisa jauh lebih kecil daripada yang ada di layanan Power BI. Jika model dalam layanan Power BI memiliki kebijakan refresh bertahap yang diterapkan, mungkin memiliki beberapa tahun data historis yang akan hilang jika model diganti. Me-refresh semua data historis dapat memakan waktu berjam-jam dan mengakibatkan waktu henti sistem bagi pengguna.

Sebaliknya, lebih baik melakukan penyebaran metadata saja agar dapat melakukan penyebaran objek baru tanpa kehilangan data historis. Misalnya, jika Anda telah menambahkan beberapa langkah, Anda hanya dapat menyebarkan langkah-langkah baru tanpa perlu me-refresh data, menghemat waktu.

Untuk ruang kerja yang ditetapkan ke kapasitas Premium yang dikonfigurasi untuk baca/tulis titik akhir XMLA, alat yang kompatibel hanya mengaktifkan penyebaran metadata. Misalnya, ALM Toolkit adalah alat diff skema untuk model Power BI dan dapat digunakan untuk melakukan penyebaran metadata saja.

Unduh dan instal ALM Toolkit versi terbaru dari Repositori Git Azure Analysis Services. Panduan langkah demi langkah tentang menggunakan ALM Toolkit tidak disertakan dalam dokumentasi Microsoft. Tautan dokumentasi Toolkit ALM dan informasi tentang dukungan tersedia di pita Bantuan . Untuk melakukan penyebaran metadata saja, lakukan perbandingan dan pilih instans Power BI Desktop yang sedang berjalan sebagai sumbernya, dan model yang ada di layanan Power BI sebagai target. Pertimbangkan perbedaan yang ditampilkan dan lewati pembaruan tabel dengan partisi refresh bertahap atau gunakan dialog Opsi untuk mempertahankan partisi untuk pembaruan tabel. Validasi pilihan untuk memastikan integritas model target, lalu perbarui.

Screenshot shows the ALM Toolkit window.

Menambahkan kebijakan refresh bertahap dan data real-time secara terprogram

Anda juga dapat menggunakan TMSL dan TOM untuk menambahkan kebijakan refresh inkremental ke model yang ada melalui titik akhir XMLA.

Catatan

Untuk menghindari masalah kompatibilitas, pastikan Anda menggunakan versi terbaru pustaka klien Azure Analysis Services. Misalnya, untuk bekerja dengan kebijakan Hibrid, versinya harus 19.27.1.8 atau yang lebih tinggi.

Prosesnya meliputi langkah-langkah berikut:

  1. Pastikan model target memiliki tingkat kompatibilitas minimum yang diperlukan. Di SSMS, klik kanan [nama model]>Tingkat Kompatibilitas Properti.> Untuk meningkatkan tingkat kompatibilitas, gunakan skrip TMSL createOrReplace atau periksa kode sampel TOM berikut sebagai contoh.

    a. Import policy - 1550
b. Hybrid policy - 1565

  2. RangeStart Tambahkan parameter dan RangeEnd ke ekspresi model. Jika perlu, tambahkan juga fungsi untuk mengonversi nilai Tanggal/Waktu menjadi kunci tanggal.

  3. RefreshPolicy Tentukan objek dengan pengarsipan yang diinginkan (jendela bergulir) dan periode refresh inkremental serta ekspresi sumber yang memfilter tabel target berdasarkan RangeStart parameter dan RangeEnd . Atur mode kebijakan refresh ke Impor atau Hibrid tergantung pada persyaratan data real time Anda. Hibrid menyebabkan Power BI menambahkan partisi DirectQuery ke tabel untuk mengambil perubahan terbaru dari sumber data yang terjadi setelah waktu refresh terakhir.

  4. Tambahkan kebijakan refresh ke tabel dan lakukan refresh penuh sehingga Power BI mempartisi tabel sesuai dengan kebutuhan Anda.

Sampel kode berikut menunjukkan cara melakukan langkah-langkah sebelumnya dengan menggunakan TOM. Jika Anda ingin menggunakan sampel ini apa adanya, Anda harus memiliki salinan untuk database AdventureWorksDW dan mengimpor tabel FactInternetSales ke dalam model. Sampel kode mengasumsikan bahwa RangeStart parameter dan RangeEnd dan DateKey fungsi tidak ada dalam model. Cukup impor tabel FactInternetSales dan terbitkan model ke ruang kerja di Power BI Premium. Kemudian perbarui workspaceUrl sehingga sampel kode dapat tersambung ke model Anda. Perbarui baris kode lagi seperlunya.

using System;
using TOM = Microsoft.AnalysisServices.Tabular;
namespace Hybrid_Tables
{
    class Program
    {
        static string workspaceUrl = "<Enter your Workspace URL here>";
        static string databaseName = "AdventureWorks";
        static string tableName = "FactInternetSales";
        static void Main(string[] args)
        {
            using (var server = new TOM.Server())
            {
                // Connect to the dataset.
                server.Connect(workspaceUrl);
                TOM.Database database = server.Databases.FindByName(databaseName);
                if (database == null)
                {
                    throw new ApplicationException("Database cannot be found!");
                }
                if(database.CompatibilityLevel < 1565)
                {
                    database.CompatibilityLevel = 1565;
                    database.Update();
                }
                TOM.Model model = database.Model;
                // Add RangeStart, RangeEnd, and DateKey function.
                model.Expressions.Add(new TOM.NamedExpression {
                    Name = "RangeStart",
                    Kind = TOM.ExpressionKind.M,
                    Expression = "#datetime(2021, 12, 30, 0, 0, 0) meta [IsParameterQuery=true, Type=\"DateTime\", IsParameterQueryRequired=true]"
                });
                model.Expressions.Add(new TOM.NamedExpression
                {
                    Name = "RangeEnd",
                    Kind = TOM.ExpressionKind.M,
                    Expression = "#datetime(2021, 12, 31, 0, 0, 0) meta [IsParameterQuery=true, Type=\"DateTime\", IsParameterQueryRequired=true]"
                });
                model.Expressions.Add(new TOM.NamedExpression
                {
                    Name = "DateKey",
                    Kind = TOM.ExpressionKind.M,
                    Expression =
                        "let\n" +
                        "    Source = (x as datetime) => Date.Year(x)*10000 + Date.Month(x)*100 + Date.Day(x)\n" +
                        "in\n" +
                        "    Source"
                });
                // Apply a RefreshPolicy with Real-Time to the target table.
                TOM.Table salesTable = model.Tables[tableName];
                TOM.RefreshPolicy hybridPolicy = new TOM.BasicRefreshPolicy
                {
                    Mode = TOM.RefreshPolicyMode.Hybrid,
                    IncrementalPeriodsOffset = -1,
                    RollingWindowPeriods = 1,
                    RollingWindowGranularity = TOM.RefreshGranularityType.Year,
                    IncrementalPeriods = 1,
                    IncrementalGranularity = TOM.RefreshGranularityType.Day,
                    SourceExpression =
                        "let\n" +
                        "    Source = Sql.Database(\"demopm.database.windows.net\", \"AdventureWorksDW\"),\n" +
                        "    dbo_FactInternetSales = Source{[Schema=\"dbo\",Item=\"FactInternetSales\"]}[Data],\n" +
                        "    #\"Filtered Rows\" = Table.SelectRows(dbo_FactInternetSales, each [OrderDateKey] >= DateKey(RangeStart) and [OrderDateKey] < DateKey(RangeEnd))\n" +
                        "in\n" +
                        "    #\"Filtered Rows\""
                };
                salesTable.RefreshPolicy = hybridPolicy;
                model.RequestRefresh(TOM.RefreshType.Full);
                model.SaveChanges();
            }
            Console.WriteLine("{0}{1}", Environment.NewLine, "Press [Enter] to exit...");
            Console.ReadLine();
        }
    }
}

Konten terkait