Orkestrasi Refresh Semantic Model Power BI dengan Semantic Link (SemPy)

Refresh semantic model di Power BI sering terlihat sederhana: pilih Refresh now, buat jadwal, atau jalankan notebook. Namun, ketika ukuran model membesar dan tabel mulai dipartisi, pertanyaan yang lebih penting bukan hanya bagaimana menjalankan refresh, tetapi objek apa yang diproses, kebijakan apa yang diterapkan, dan berapa banyak data yang benar-benar dibaca dari sumber.

Di sinilah SemPy menjadi menarik. SemPy memberi antarmuka Python untuk berinteraksi dengan semantic model dari Microsoft Fabric. Tetapi SemPy tidak menggantikan Power Query dan bukan mesin ingestion baru. Untuk refresh, fungsi sempy.fabric.refresh_dataset() merupakan wrapper terhadap Power BI Refresh Dataset API, sehingga kekuatan utamanya adalah kontrol programatis, observability, dan orkestrasi.

Apa yang Sudah Bisa Dilakukan Power BI Tanpa SemPy?

Untuk operasi rutin, Power BI Service sudah menyediakan Refresh now dan scheduled refresh. Jika tabel menggunakan Incremental Refresh, service juga dapat membuat dan mengelola partisi berdasarkan policy yang telah ditentukan. Artinya, notebook tidak perlu dijadikan dependency harian hanya untuk menjalankan refresh biasa.

Incremental Refresh memperluas scheduled refresh dengan otomatisasi lifecycle partisi. Power BI menggunakan parameter seperti RangeStart dan RangeEnd untuk menentukan rentang data yang disimpan dan rentang yang perlu disegarkan. Fitur ini berguna ketika tabel terus bertambah dan hanya periode tertentu yang perlu diproses ulang.

Untuk kebutuhan yang lebih terkontrol, Power BI Enhanced Refresh REST API juga mendukung refresh pada level tabel dan partisi, penerapan incremental refresh policy, detail eksekusi, pembatalan refresh, pengaturan timeout, serta commit mode. Jadi kemampuan targeted refresh bukan eksklusif milik SemPy.

Lalu Apa yang Ditambahkan SemPy?

Nilai SemPy adalah membawa kontrol tersebut ke Fabric Notebook dan Python. Dengan satu notebook, kita dapat menggabungkan discovery metadata, validasi, pemilihan objek refresh, pencatatan request ID, pemeriksaan status, dan pengujian hasil setelah refresh.

Hal penting lainnya: jangan menyamakan seluruh SemPy dengan XMLA. Beberapa fungsi metadata dan TOM, seperti inspeksi partisi yang diperluas, memang dapat menggunakan Tabular Object Model melalui XMLA dan membutuhkan permission yang sesuai. Namun refresh_dataset() sendiri didokumentasikan Microsoft sebagai wrapper terhadap Power BI Refresh Dataset In Group API. Dengan kata lain, jalur inspeksi metadata dapat berbeda dari jalur eksekusi refresh.

Contoh Targeted Partition Refresh dengan SemPy

import sempy.fabric as fabric

request_id = fabric.refresh_dataset(
    dataset="Sales Semantic Model",
    workspace="Analytics Workspace",
    refresh_type="full",
    objects=[{"table": "FactSales", "partition": "FY_2026"}],
    apply_refresh_policy=False,
    commit_mode="transactional",
    verbose=1
)

print(request_id)

Contoh tersebut meminta Power BI memproses satu partisi tertentu. apply_refresh_policy=False digunakan ketika tujuan operasi adalah mempertahankan definisi partisi yang sudah ada dan melakukan exception refresh secara terkontrol. Jika sebuah tabel memang dikelola oleh Incremental Refresh policy, parameter ini harus diperlakukan sebagai bagian dari kontrak operasi, bukan sekadar switch teknis.

Targeted Partition Refresh Tidak Sama dengan Source Pruning

Ini adalah bagian yang paling mudah disalahpahami. Refreshing satu partisi tidak otomatis berarti sumber data hanya membaca data sebesar satu partisi.

Semantic engine dapat memilih partisi FY_2026 sebagai target processing. Tetapi efisiensi pembacaan dari sumber tetap bergantung pada Power Query dan query folding. Jika filter partisi dapat dilipat ke sumber, database dapat menerima query yang sudah memiliki pembatas rentang. Jika folding rusak, mesin dapat membaca data jauh lebih banyak lalu melakukan filtering setelah data meninggalkan sumber.

Dokumentasi Microsoft untuk Incremental Refresh juga menekankan hal yang sama: masalah query folding dapat membuat query setiap partisi tidak terfilter secara efisien di sumber dan meningkatkan durasi serta penggunaan resource.

SemPy dapat membantu memilih objek semantic yang diproses. Namun Power Query tetap menentukan bagaimana data diambil dan apakah filter dapat diteruskan ke sumber.

Incremental Refresh Bukan Syarat untuk Targeted Partition Refresh

Targeted refresh pada satu partisi dapat dilakukan tanpa harus menggunakan Incremental Refresh policy. Jika model memiliki partisi manual, REST API atau SemPy dapat menunjuk partisi tersebut secara eksplisit.

Perbedaan utamanya adalah siapa yang mengelola lifecycle partisi:

Kedua pendekatan tidak seharusnya dijadikan dua controller yang saling bersaing tanpa kontrak yang jelas. Jika partisi manual sudah menjadi arsitektur utama, menambahkan Incremental Refresh policy harus diuji terlebih dahulu pada model sintetis atau canary sebelum diterapkan ke model produksi.

Apa Fungsi apply_refresh_policy?

Pada SemPy, parameter apply_refresh_policy menentukan apakah Incremental Refresh policy yang ada akan diterapkan ketika refresh dijalankan. Microsoft mendokumentasikan bahwa ketika policy tidak diterapkan, definisi partisi dipertahankan. Ini penting untuk targeted historical refresh karena tujuan kita biasanya adalah memperbarui data pada objek yang sudah dipilih, bukan meminta service membentuk ulang topology partisi.

Routine Incremental Refresh
→ policy-managed lifecycle
→ apply_refresh_policy=True

Manual / exception partition refresh
→ preserve partition topology
→ apply_refresh_policy=False

Nilai tersebut bukan aturan universal untuk semua model. Prinsipnya adalah memastikan hanya satu controller yang berwenang mengubah lifecycle partisi pada satu operasi.

Hasil Canary: Targeted Refresh Dapat Divalidasi Tanpa Mengubah Model Asli

Dalam salah satu canary internal yang kami gunakan untuk menguji arsitektur ini, model uji memiliki lima partisi dengan total 6.353.671 baris. Seluruh partisi mencapai status Ready, parity tahunan mencapai 100%, dan delapan pengujian exact-equality menghasilkan MismatchRows = 0. Model sumber tetap tidak berubah selama canary.

Hasil tersebut memvalidasi bahwa targeted partition refresh dapat dikontrol dan diuji secara terpisah. Namun hasil parity tidak boleh disalahartikan sebagai bukti efisiensi I/O dari sumber. Untuk membuktikan source pruning, pengujian harus mengukur query yang dikirim ke sumber, jumlah baris yang dibaca, durasi, CU, dan peak memory.

Eksperimen yang Lebih Tepat untuk Menguji Efisiensi Refresh

Untuk membedakan efek partition targeting dan query folding, eksperimen dapat dibuat dalam empat skenario:

Metrik yang perlu dibandingkan bukan hanya waktu refresh. Ukur juga source query atau rows read, CU, peak memory, jumlah baris yang akhirnya dimuat, serta ukuran semantic model. Dengan desain ini, kita dapat membedakan manfaat lifecycle automation dari Incremental Refresh dengan manfaat source-side filtering dari query folding.

Pola Operasional yang Lebih Aman

Untuk production, pola yang seimbang adalah membiarkan Power BI Service menangani refresh rutin, sementara notebook digunakan untuk pekerjaan yang membutuhkan kontrol lebih tinggi.

Pada arsitektur ini, SemPy berfungsi sebagai control dan validation layer. Power Query tetap menjadi ingestion engine, semantic model tetap menjadi target processing, dan Power BI REST API menyediakan execution contract untuk refresh.

SemPy, REST API, atau Data Factory?

SemPy bukan satu-satunya jalur automasi. Enhanced Refresh REST API dapat dipanggil langsung dari aplikasi, sedangkan Microsoft Fabric Data Factory juga menyediakan Semantic model refresh activity yang dapat memilih tabel dan partisi dari pipeline. Pilihan terbaik bergantung pada kebutuhan operasi.

Notebook SemPy unggul ketika refresh perlu digabungkan dengan inspeksi metadata, pengambilan keputusan berbasis Python, validasi hasil, dan audit teknis. REST API lebih langsung ketika aplikasi hanya membutuhkan execution contract dan request ID. Pipeline cocok ketika refresh merupakan bagian dari orkestrasi data yang lebih besar.

Kesimpulan

SemPy tidak membuat Power BI memiliki jenis refresh yang sepenuhnya berbeda. Ia membuat kemampuan semantic model dan Enhanced Refresh lebih mudah dikendalikan dari Python dan Fabric Notebook.

1. Targeted partition refresh tidak membutuhkan Incremental Refresh. Incremental Refresh terutama mengotomatisasi lifecycle partisi.
2. Memilih satu partisi tidak membuktikan sumber hanya membaca satu partisi. Query folding tetap menentukan source-side filtering.
3. SemPy sebaiknya menjadi lapisan kontrol dan validasi, bukan dependency wajib untuk refresh rutin. Gunakan notebook ketika memang membutuhkan audit, exception handling, targeted repair, atau evidence yang lebih rinci.

Dengan memisahkan ingestion, partition lifecycle, refresh execution, dan validation, refresh semantic model menjadi lebih mudah diaudit dan lebih aman untuk dioperasikan pada model yang semakin besar.

Referensi

• Microsoft Learn — What is semantic link?
• Microsoft Learn — sempy.fabric package
• Microsoft Learn — Enhanced refresh with the Power BI REST API
• Microsoft Learn — Incremental refresh for semantic models
• Microsoft Learn — Troubleshoot incremental refresh and query folding
• Microsoft Learn — Refresh data in Power BI
• Microsoft Learn — Semantic model refresh activity in Data Factory