Gambaran umum Direct Lake
Direct Lake adalah opsi mode penyimpanan untuk tabel dalam model semantik Power BI yang disimpan di ruang kerja Microsoft Fabric. Ini dioptimalkan untuk data dalam volume besar yang dapat dengan cepat dimuat ke dalam memori dari tabel Delta, yang menyimpan data mereka dalam file Parquet di OneLake—penyimpanan tunggal untuk semua data analitik. Setelah dimuat ke dalam memori, model semantik memungkinkan kueri performa tinggi. Direct Lake menghilangkan kebutuhan yang lambat dan mahal untuk mengimpor data ke dalam model.
Anda dapat menggunakan mode penyimpanan Direct Lake untuk menyambungkan ke tabel atau tampilan satu gudang Fabric lakehouse atau Fabric. Kedua item Fabric ini dan model semantik Direct Lake memerlukan lisensi kapasitas Fabric.
Dalam beberapa hal, model semantik Direct Lake mirip dengan model semantik Impor. Itu karena data model dimuat ke dalam memori oleh mesin VertiPaq untuk performa kueri yang cepat (kecuali dalam kasus fallback DirectQuery, yang dijelaskan nanti dalam artikel ini).
Namun, model semantik Direct Lake berbeda dari model semantik Impor dengan cara yang penting. Itu karena operasi refresh untuk model semantik Direct Lake secara konseptual berbeda dengan operasi refresh untuk model semantik Impor. Untuk model semantik Direct Lake, refresh melibatkan operasi pembingkaian (dijelaskan nanti dalam artikel ini), yang dapat memakan waktu beberapa detik untuk diselesaikan. Ini adalah operasi bernilai rendah di mana model semantik menganalisis metadata versi terbaru tabel Delta dan diperbarui untuk mereferensikan file terbaru di OneLake. Sebaliknya, untuk model semantik Impor, refresh menghasilkan salinan data, yang dapat memakan waktu cukup lama dan mengonsumsi sumber data dan sumber daya kapasitas yang signifikan (memori dan CPU).
Catatan
Refresh bertahap untuk model semantik Impor dapat membantu mengurangi waktu refresh dan penggunaan sumber daya kapasitas.
Kapan Anda harus menggunakan mode penyimpanan Direct Lake?
Kasus penggunaan utama untuk mode penyimpanan Direct Lake biasanya untuk proyek analitik berbasis IT yang memanfaatkan arsitektur yang ber sentris danau. Dalam skenario ini, Anda memiliki—atau mengharapkan untuk mengakumulasi—data dalam volume besar di OneLake. Pemuatan cepat data tersebut ke dalam memori, operasi refresh yang sering dan cepat, penggunaan sumber daya kapasitas yang efisien, dan performa kueri yang cepat semuanya penting untuk kasus penggunaan ini.
Catatan
Model semantik Impor dan DirectQuery masih relevan dalam Fabric, dan merupakan pilihan model semantik yang tepat untuk beberapa skenario. Misalnya, Mode penyimpanan Impor sering berfungsi dengan baik bagi analis layanan mandiri yang membutuhkan kebebasan dan kelincahan untuk bertindak dengan cepat, dan tanpa dependensi pada IT untuk menambahkan elemen data baru.
Selain itu, integrasi OneLake secara otomatis menulis data untuk tabel dalam mode Impor penyimpanan ke tabel Delta di OneLake tanpa melibatkan upaya migrasi apa pun. Dengan menggunakan opsi ini, Anda dapat mewujudkan banyak manfaat Fabric yang tersedia untuk Mengimpor pengguna model semantik, seperti integrasi dengan lakehouse melalui pintasan, kueri SQL, notebook, dan banyak lagi. Kami menyarankan agar Anda mempertimbangkan opsi ini sebagai cara cepat untuk menuai manfaat Fabric tanpa harus atau segera merancang ulang gudang data dan/atau sistem analitik yang ada.
Mode penyimpanan Direct Lake juga cocok untuk meminimalkan latensi data agar data tersedia dengan cepat bagi pengguna bisnis. Jika tabel Delta Anda dimodifikasi secara terputus-putus (dan dengan asumsi Anda telah melakukan persiapan data di data lake), Anda dapat bergantung pada pembaruan otomatis untuk memperbaiki sebagai respons terhadap modifikasi tersebut. Dalam hal ini, kueri yang dikirim ke model semantik akan mengembalikan data terbaru. Kemampuan ini bekerja dengan baik dalam kemitraan dengan fitur refresh halaman otomatis laporan Power BI.
Perlu diingat bahwa Direct Lake tergantung pada persiapan data yang dilakukan di data lake. Penyiapan data dapat dilakukan dengan menggunakan berbagai alat, seperti pekerjaan Spark untuk Fabric lakehouse, pernyataan T-SQL DML untuk gudang Fabric, aliran data, alur, dan lainnya. Pendekatan ini membantu memastikan logika persiapan data dilakukan serendah mungkin dalam arsitektur untuk memaksimalkan penggunaan kembali. Namun, jika pembuat model semantik tidak memiliki kemampuan untuk memodifikasi item sumber, misalnya, dalam kasus analis layanan mandiri yang mungkin tidak memiliki izin tulis di lakehouse yang dikelola oleh IT, maka Mode penyimpanan Impor mungkin menjadi pilihan yang lebih baik. Itu karena mendukung persiapan data dengan menggunakan Power Query, yang didefinisikan sebagai bagian dari model semantik.
Pastikan untuk memperhitungkan lisensi kapasitas Fabric Anda saat ini dan pagar pembatas kapasitas Fabric saat Anda mempertimbangkan mode penyimpanan Direct Lake. Juga, faktor dalam pertimbangan dan batasan, yang dijelaskan nanti dalam artikel ini.
Tip
Sebaiknya Anda menghasilkan prototipe—atau proof of concept (POC)—untuk menentukan apakah model semantik Direct Lake adalah solusi yang tepat, dan untuk mengurangi risiko.
Cara kerja Direct Lake
Biasanya, kueri yang dikirim ke model semantik Direct Lake ditangani dari cache dalam memori kolom yang bersumber dari tabel Delta. Penyimpanan yang mendasar untuk tabel Delta adalah satu atau beberapa file Parquet di OneLake. File parquet mengatur data menurut kolom daripada baris. Model semantik memuat seluruh kolom dari tabel Delta ke dalam memori karena diperlukan oleh kueri.
Model semantik Direct Lake mungkin juga menggunakan fallback DirectQuery, yang melibatkan peralihan dengan mulus ke mode DirectQuery. Fallback DirectQuery mengambil data langsung dari titik akhir analitik SQL lakehouse atau gudang. Misalnya, fallback mungkin terjadi ketika tabel Delta berisi lebih banyak baris data daripada yang didukung oleh kapasitas Fabric Anda (dijelaskan nanti di artikel ini). Dalam hal ini, operasi DirectQuery mengirimkan kueri ke titik akhir analitik SQL. Operasi fallback dapat mengakibatkan performa kueri yang lebih lambat.
Diagram berikut menunjukkan cara kerja Direct Lake dengan menggunakan skenario pengguna yang membuka laporan Power BI.
Diagram menggambarkan tindakan, proses, dan fitur pengguna berikut.
Bagian berikut menjelaskan konsep dan fitur Direct Lake, termasuk pemuatan kolom, pembingkaian, pembaruan otomatis, dan fallback DirectQuery.
Pemuatan kolom (transcoding)
Model semantik Direct Lake hanya memuat data dari OneLake sebagai dan kapan kolom dikueri untuk pertama kalinya. Proses pemuatan data sesuai permintaan dari OneLake dikenal sebagai transcoding.
Saat model semantik menerima kueri DAX (atau Ekspresi Multidmensional—MDX), model semantik terlebih dahulu menentukan kolom apa yang diperlukan untuk menghasilkan hasil kueri. Kolom yang diperlukan mencakup kolom apa pun yang langsung digunakan oleh kueri, dan juga kolom yang diperlukan oleh hubungan dan pengukuran. Biasanya, jumlah kolom yang diperlukan untuk menghasilkan hasil kueri jauh lebih kecil daripada jumlah kolom yang ditentukan dalam model semantik.
Setelah dipahami kolom mana yang diperlukan, model semantik menentukan kolom mana yang sudah ada dalam memori. Jika ada kolom yang diperlukan untuk kueri yang tidak ada dalam memori, model semantik memuat semua data untuk kolom tersebut dari OneLake. Memuat data kolom biasanya merupakan operasi yang sangat cepat, namun dapat bergantung pada faktor-faktor seperti kardinalitas data yang disimpan dalam kolom.
Kolom yang dimuat ke dalam memori kemudian disimpan dalam memori. Kueri di masa mendatang yang hanya melibatkan kolom penduduk tidak perlu memuat kolom lagi ke dalam memori.
Kolom tetap tinggal sampai ada alasan untuk dihapus (dikeluarkan) dari memori. Alasan kolom mungkin dihapus meliputi:
- Model atau tabel telah disegarkan (lihat Pembingkaian di bagian berikutnya).
- Tidak ada kueri yang menggunakan kolom untuk beberapa waktu.
- Alasan manajemen memori lainnya, termasuk tekanan memori dalam kapasitas karena operasi bersamaan lainnya.
Pilihan Fabric SKU Anda menentukan memori maksimum yang tersedia untuk setiap model semantik Direct Lake pada kapasitas. Untuk informasi selengkapnya tentang pagar pembatas sumber daya dan batas memori maksimum, lihat Pagar pembatas kapasitas Fabric dan batasan nanti di artikel ini.
Framing
Pembingkaian memberi pemilik model kontrol point-in-time atas data apa yang dimuat ke dalam model semantik. Framing adalah operasi Direct Lake yang dipicu oleh refresh model semantik, dan dalam banyak kasus hanya membutuhkan waktu beberapa detik untuk diselesaikan. Itu karena ini adalah operasi bernilai rendah di mana model semantik menganalisis metadata versi terbaru tabel Delta Lake dan diperbarui untuk mereferensikan file Parquet terbaru di OneLake.
Saat pembingkaian terjadi, kolom penduduk mungkin dikeluarkan dari memori dan titik waktu refresh menjadi garis besar baru untuk semua peristiwa transkode di masa mendatang. Dari titik ini, kueri Direct Lake hanya mempertimbangkan data dalam tabel Delta pada saat operasi pembingkaian terbaru. Untuk alasan itu, tabel Direct Lake dikueri untuk mengembalikan data berdasarkan status tabel Delta pada titik operasi pembingkaian terbaru. Waktu tersebut belum tentu menjadi status terbaru tabel Delta.
Diagram berikut menunjukkan cara kerja operasi pembingkaian Direct Lake.
Diagram menggambarkan proses dan fitur berikut.
| Item | Deskripsi |
|---|---|
 |
Model semantik ada di ruang kerja Fabric. |
 |
Operasi pembingkaian berlangsung secara berkala, dan mereka mengatur garis besar untuk semua peristiwa transcoding di masa mendatang. Operasi pembingkaian dapat terjadi secara otomatis, manual, sesuai jadwal, atau terprogram. |
 |
OneLake menyimpan metadata dan file Parquet, yang diwakili sebagai tabel Delta. |
 |
Operasi pembingkaian terakhir mencakup file Parquet yang terkait dengan tabel Delta, dan khususnya file Parquet yang ditambahkan sebelum operasi pembingkaian terakhir . |
 |
Operasi pembingkaian selanjutnya mencakup file Parquet yang ditambahkan setelah operasi pembingkaian terakhir . |
 |
Kolom penduduk dalam model semantik Direct Lake mungkin dikeluarkan dari memori, dan titik waktu penyegaran menjadi garis besar baru untuk semua peristiwa transkode di masa mendatang. |
 |
Modifikasi data berikutnya, yang diwakili oleh file Parquet baru, tidak terlihat sampai operasi pembingkaian berikutnya terjadi. |
Tidak selalu diinginkan untuk memiliki data yang mewakili status terbaru tabel Delta apa pun ketika operasi transkode berlangsung. Pertimbangkan bahwa pembingkaian dapat membantu Anda memberikan hasil kueri yang konsisten di lingkungan tempat data dalam tabel Delta bersifat sementara. Data dapat bersifat sementara karena beberapa alasan, seperti ketika proses ekstrak, transformasi, dan pemuatan (ETL) berjalan lama terjadi.
Refresh untuk model semantik Direct Lake dapat dilakukan secara manual, otomatis, atau terprogram. Untuk informasi selengkapnya, lihat Merefresh model semantik Direct Lake.
Untuk informasi selengkapnya tentang penerapan versi dan pembingkaian tabel Delta, lihat Memahami penyimpanan untuk model semantik Direct Lake.
Pembaruan otomatis
Ada pengaturan tingkat model semantik untuk memperbarui tabel Direct Lake secara otomatis. Status diaktifkan secara default. Ini memastikan bahwa perubahan data di OneLake secara otomatis tercermin dalam model semantik Direct Lake. Anda harus menonaktifkan pembaruan otomatis saat ingin mengontrol perubahan data dengan pembingkaian, yang dijelaskan di bagian sebelumnya. Untuk informasi selengkapnya, lihat Mengelola model semantik Direct Lake.
Tip
Anda bisa menyiapkan refresh halaman otomatis di laporan Power BI Anda. Ini adalah fitur yang secara otomatis me-refresh halaman laporan tertentu asalkan laporan terhubung ke model semantik Direct Lake (atau jenis model semantik lainnya).
Fallback DirectQuery
Kueri yang dikirim ke model semantik Direct Lake dapat kembali ke mode DirectQuery. Dalam hal ini, ia mengambil data langsung dari titik akhir analitik SQL dari lakehouse atau gudang. Kueri tersebut selalu mengembalikan data terbaru karena tidak dibatasi ke titik waktu operasi pembingkaian terakhir.
Kueri selalu kembali saat model semantik meminta tampilan di titik akhir analitik SQL, atau tabel di titik akhir analitik SQL yang memberlakukan keamanan tingkat baris (RLS).
Selain itu, kueri mungkin mundur ketika model semantik melebihi pagar pembatas kapasitas.
Penting
Jika memungkinkan, Anda harus selalu merancang solusi Anda—atau mengukur kapasitas Anda—untuk menghindari fallback DirectQuery. Itu karena mungkin mengakibatkan performa kueri yang lebih lambat.
Anda dapat mengontrol fallback model semantik Direct Lake Anda dengan mengatur properti DirectLakeBehavior-nya. Untuk informasi selengkapnya, lihat Mengatur properti perilaku Direct Lake.
Pembatas dan batasan kapasitas fabric
Model semantik Direct Lake memerlukan lisensi kapasitas Fabric. Selain itu, ada pagar pembatas kapasitas dan batasan yang berlaku untuk langganan kapasitas Fabric (SKU) Anda, seperti yang disajikan dalam tabel berikut.
Penting
Kolom pertama dalam tabel berikut ini juga menyertakan langganan kapasitas Power BI Premium (SKU P). Ketahuilah bahwa Microsoft mengonsolidasikan opsi pembelian dan menghentikan SKU Power BI Premium per kapasitas. Pelanggan baru dan yang sudah ada harus mempertimbangkan untuk membeli langganan kapasitas Fabric (F SKU) sebagai gantinya.
Untuk informasi selengkapnya, lihat Pembaruan penting yang masuk ke lisensi Power BI Premium dan Power BI Premium.
| Fabric SKU | File parket per tabel | Grup baris per tabel | Baris per tabel (jutaan) | Ukuran model maksimum pada disk/OneLake (GB) | Memori maks (GB) 1 |
|---|---|---|---|---|---|
| F2 | 1,000 | 1,000 | 300 | 10 | 3 |
| F4 | 1,000 | 1,000 | 300 | 10 | 3 |
| F8 | 1,000 | 1,000 | 300 | 10 | 3 |
| F16 | 1,000 | 1,000 | 300 | 20 | 5 |
| F32 | 1,000 | 1,000 | 300 | 40 | 10 |
| F64/FT1/P1 | 5\.000 | 5\.000 | 1.500 | Tidak Terbatas | 25 |
| F128/P2 | 5\.000 | 5\.000 | 3.000 | Tidak Terbatas | 50 |
| F256/P3 | 5\.000 | 5\.000 | 6.000 | Tidak Terbatas | 100 |
| F512/P4 | 10,000 | 10,000 | 12.000 | Tidak Terbatas | 200 |
| F1024/P5 | 10,000 | 10,000 | 24.000 | Tidak Terbatas | 400 |
| F2048 | 10,000 | 10,000 | 24.000 | Tidak Terbatas | 400 |
1 Untuk model semantik Direct Lake, Memori Maks mewakili batas sumber daya memori atas untuk berapa banyak data yang dapat di-paged in. Untuk alasan ini, ini bukan pagar pembatas karena melebihinya tidak mengakibatkan fallback ke mode DirectQuery; namun, hal ini dapat berdampak pada performa jika jumlah data cukup besar untuk menyebabkan paging yang berlebihan masuk dan keluar dari data model dari data OneLake.
Jika terlampaui, ukuran Model maks pada disk/OneLake akan menyebabkan semua kueri ke model semantik kembali ke mode DirectQuery. Semua pagar pembatas lain yang disajikan dalam tabel dievaluasi per kueri. Oleh karena itu, penting bagi Anda untuk mengoptimalkan tabel Delta dan model semantik Direct Lake untuk menghindari perlunya meningkatkan skala ke Fabric SKU yang lebih tinggi (menghasilkan peningkatan biaya).
Selain itu, unit Kapasitas dan Batas memori maks per kueri berlaku untuk model semantik Direct Lake. Untuk informasi selengkapnya, lihat Kapasitas dan SKU.
Pertimbangan dan batasan
Model semantik Direct Lake menyajikan beberapa pertimbangan dan batasan.
Catatan
Kemampuan dan fitur model semantik Direct Lake berkembang. Pastikan untuk memeriksa kembali secara berkala untuk meninjau daftar pertimbangan dan batasan terbaru.
- Saat tabel model semantik Direct Lake tersambung ke tabel di titik akhir analitik SQL yang memberlakukan keamanan tingkat baris (RLS), kueri yang melibatkan tabel model tersebut akan selalu kembali ke mode DirectQuery. Performa kueri mungkin lebih lambat.
- Saat tabel model semantik Direct Lake tersambung ke tampilan di titik akhir analitik SQL, kueri yang melibatkan tabel model tersebut akan selalu kembali ke mode DirectQuery. Performa kueri mungkin lebih lambat.
- Pemodelan komposit tidak didukung. Itu berarti tabel model semantik Direct Lake tidak dapat dicampur dengan tabel dalam mode penyimpanan lain, seperti Impor, DirectQuery, atau Ganda (kecuali untuk kasus khusus, termasuk grup perhitungan, parameter bagaimana-jika, dan parameter bidang).
- Kolom terhitung dan tabel terhitung yang mereferensikan kolom atau tabel dalam mode penyimpanan Direct Lake tidak didukung. Grup perhitungan, parameter bagaimana-jika, dan parameter bidang, yang secara implisit membuat tabel terhitung, dan tabel terhitung yang tidak mereferensikan kolom atau tabel Direct Lake didukung.
- Tabel mode penyimpanan Direct Lake tidak mendukung jenis kolom tabel Delta yang kompleks. Jenis semantik biner dan GUID juga tidak didukung. Anda harus mengonversi jenis data ini menjadi string atau jenis data lain yang didukung.
- Hubungan tabel mengharuskan tipe data kolom terkait cocok.
- Kolom hubungan satu sisi harus berisi nilai unik. Kueri akan gagal jika nilai duplikat terdeteksi dalam kolom satu sisi.
- Kecerdasan data/waktu otomatis di Power BI Desktop tidak didukung. Menandai tabel tanggal Anda sendiri sebagai tabel tanggal didukung.
- Panjang nilai kolom string dibatasi hingga 32.764 karakter Unicode.
- Nilai titik mengambang NaN (bukan angka) tidak didukung.
- Skenario penyematan yang menggunakan skenario Untuk penggunaan pelanggan Anda tidak didukung.
- Terbitkan ke web dari Power BI hanya didukung saat menggunakan identitas tetap untuk model semantik Direct Lake.
- Dalam pengalaman pemodelan web, validasi terbatas untuk model semantik Direct Lake. Pilihan pengguna diasumsikan benar, dan tidak ada kueri yang dikeluarkan untuk memvalidasi pilihan kardinalitas atau filter silang untuk hubungan, atau untuk kolom tanggal yang dipilih dalam tabel tanggal yang ditandai.
- Di portal Fabric, tab Direct Lake dalam riwayat refresh hanya mencantumkan kegagalan refresh terkait Direct Lake. Operasi refresh (pembingkaian) yang berhasil tidak tercantum.
- SKU Fabric Anda menentukan memori maksimum yang tersedia per model semantik Direct Lake untuk kapasitas. Ketika batas terlampaui, kueri ke model semantik mungkin lebih lambat karena penomoran berlebihan masuk dan keluar dari data model.
- Membuat model semantik Direct Lake di ruang kerja yang berada di wilayah ruang kerja sumber data yang berbeda tidak didukung. Misalnya, jika Lakehouse berada di US Tengah Barat, maka Anda hanya dapat membuat model semantik dari Lakehouse ini di wilayah yang sama. Solusinya adalah membuat Lakehouse di ruang kerja dan pintasan wilayah lain ke tabel sebelum membuat model semantik. Untuk menemukan wilayah tempat Anda berada, lihat menemukan wilayah asal Fabric Anda.
Perbandingan dengan mode penyimpanan lainnya
Tabel berikut membandingkan mode penyimpanan Direct Lake dengan mode penyimpanan Impor dan DirectQuery.
| Kemampuan | Danau Langsung | Impor | DirectQuery |
|---|---|---|---|
| Pelisensian | Langganan kapasitas fabric (SKU) saja | Lisensi Fabric atau Power BI apa pun (termasuk lisensi Microsoft Fabric Free) | Lisensi Fabric atau Power BI apa pun (termasuk lisensi Microsoft Fabric Free) |
| Sumber data | Hanya lakehouse atau tabel gudang (atau tampilan) | Konektor apa pun | Konektor apa pun yang mendukung mode DirectQuery |
| Menyambungkan ke tampilan titik akhir analitik SQL | Ya – tetapi akan secara otomatis kembali ke mode DirectQuery | Ya | Ya |
| Model komposit | No 1 | Ya – dapat dikombinasikan dengan tabel Mode penyimpanan DirectQuery atau Dual | Ya – dapat dikombinasikan dengan tabel mode penyimpanan Impor atau Ganda |
| Akses menyeluruh (SSO) | Ya | Tidak berlaku | Ya |
| Tabel terhitung | Tidak – kecuali grup perhitungan, parameter bagaimana-jika, dan parameter bidang, yang secara implisit membuat tabel terhitung | Ya | Tidak – tabel terhitung menggunakan mode Impor penyimpanan bahkan saat merujuk ke tabel lain dalam mode DirectQuery |
| Kolom terhitung | Tidak | Ya | Ya |
| Tabel hibrid | Tidak | Ya | Ya |
| Partisi tabel model | Tidak – namun pemartisian dapat dilakukan di tingkat tabel Delta | Ya – dibuat secara otomatis oleh refresh bertambah bertahas, atau dibuat secara manual dengan menggunakan titik akhir XMLA | No |
| Agregasi yang ditentukan pengguna | Tidak | Ya | Ya |
| Keamanan tingkat objek titik akhir analitik SQL atau keamanan tingkat kolom | Ya – tetapi kueri akan kembali ke mode DirectQuery dan mungkin menghasilkan kesalahan saat izin ditolak | Ya – tetapi harus menduplikasi izin dengan keamanan tingkat objek model semantik | Ya – tetapi kueri mungkin menghasilkan kesalahan saat izin ditolak |
| Keamanan tingkat baris titik akhir analitik SQL (RLS) | Ya – tetapi kueri akan kembali ke mode DirectQuery | Ya – tetapi harus menduplikasi izin dengan RLS model semantik | Ya |
| Keamanan tingkat baris model semantik (RLS) | Ya – tetapi sangat disarankan untuk menggunakan koneksi cloud identitas tetap | Ya | Ya |
| Keamanan tingkat objek model semantik (OLS) | Ya | Ya | Ya |
| Volume data besar tanpa persyaratan refresh | Ya | Kurang cocok - ukuran kapasitas yang lebih besar mungkin diperlukan untuk mengkueri dan menyegarkan | Ya |
| Mengurangi latensi data | Ya – ketika pembaruan otomatis diaktifkan, atau reframing terprogram; namun, persiapan data harus dilakukan di hulu terlebih dahulu | Tidak | Ya |
1 Anda tidak dapat menggabungkan tabel mode penyimpanan Direct Lake dengan tabel mode Penyimpanan DirectQuery atau Ganda dalam model semantik yang sama. Namun, Anda dapat menggunakan Power BI Desktop untuk membuat model komposit pada model semantik Direct Lake lalu memperluasnya dengan tabel baru (dengan menggunakan Mode penyimpanan Impor, DirectQuery, atau Ganda) atau perhitungan. Untuk informasi selengkapnya, lihat Membangun model komposit pada model semantik.