Gambaran umum Direct Lake
Direct Lake adalah opsi mode penyimpanan untuk tabel dalam model semantik Power BI yang disimpan di ruang kerja Microsoft Fabric. Pengoptimalan ini ditujukan untuk volume data besar yang dapat dimuat dengan cepat ke dalam memori dari tabel Delta , yang menyimpan data mereka dalam file Parquet di OneLake—satu-satunya tempat penyimpanan 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 Fabric lakehouse atau Fabric warehouse. Item Fabric ini dan model semantik Direct Lake keduanya 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 bisa selesai dalam beberapa detik. 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).
Nota
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 menggunakan 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.
Nota
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 memasukkan data untuk tabel dalam mode penyimpanan Impor ke tabel Delta di OneLake tanpa perlu upaya migrasi. Dengan menggunakan opsi ini, Anda dapat mewujudkan banyak manfaat Fabric yang tersedia untuk pengguna model semantik Impor, seperti integrasi dengan lakehouse melalui pintasan, kueri SQL, notebook, dan masih 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 sudah melakukan persiapan data di data lake), Anda dapat bergantung pada pembaruan otomatis untuk menyesuaikan sebagai respons terhadap modifikasi tersebut. Dalam hal ini, kueri yang dikirim ke model semantik mengembalikan data terbaru. Kemampuan ini berfungsi baik bersama 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, jika analis layanan mandiri tidak memiliki izin tulis pada 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, perhitungkan pertimbangan dan batasan yang dijelaskan nanti dalam artikel ini.
Petunjuk
Kami menyarankan agar 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 memori kolom yang berasal dari tabel Delta. Penyimpanan yang mendasar untuk tabel Delta adalah satu atau beberapa file Parquet di OneLake. File Parquet mengatur data menurut kolom, bukan 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 pengalihan secara mulus ke mode DirectQuery . Fallback DirectQuery mengambil data langsung dari titik akhir analitik SQL dari lakehouse atau gudang. Misalnya, fallback mungkin terjadi ketika tabel Delta berisi lebih banyak baris data daripada yang didukung oleh kapasitas Fabric Anda (dijelaskan nanti dalam 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 
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 pada saat 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 apa pun yang langsung digunakan oleh kueri diperlukan, dan juga kolom yang diperlukan oleh hubungan dan pengukuran. Biasanya, jumlah kolom yang diperlukan untuk menghasilkan hasil kueri secara signifikan lebih kecil dari jumlah kolom yang ditentukan dalam model semantik.
Setelah memahami 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 cepat, namun dapat bergantung pada faktor-faktor seperti kardinalitas data yang disimpan dalam kolom.
Kolom yang dimuat ke dalam memori kemudian tetap berada dalam memori. Kueri di masa mendatang yang hanya melibatkan kolom yang berada tidak perlu memuat kolom tambahan ke dalam memori.
Kolom tetap berada dalam memori sampai ada alasan untuk menghapus (mengeluarkan)nya. Alasan kolom mungkin dihapus meliputi:
- Model dan/atau tabel diperbarui setelah pembaruan tabel Delta di sumbernya (lihat Framing di pada 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 SKU Fabric Anda menentukan jumlah 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.
Pembingkaian
Framing memberi pemilik model kendali pada titik waktu tertentu atas data yang dimuat ke dalam model semantik. Pembingkaian adalah operasi Direct Lake yang dipicu oleh refresh model semantik, dan dalam kebanyakan kasus hanya membutuhkan waktu beberapa detik untuk diselesaikan. Itu karena ini adalah operasi berbiaya rendah di mana model semantik menganalisis metadata versi terbaru tabel Delta Lake dan diperbarui untuk mereferensikan file Parquet terbaru di OneLake.
Saat pembingkaian terjadi, segmen kolom tabel residen dan kamus mungkin dikeluarkan dari memori jika data yang mendasar telah berubah dan titik waktu penyegaran menjadi garis besar baru untuk semua peristiwa transcoding di masa mendatang. Dari titik ini, kueri Direct Lake hanya mempertimbangkan data dalam tabel Delta pada saat operasi pembingkaian terkini. Untuk alasan itu, tabel Direct Lake dikueri untuk mengembalikan data berdasarkan status tabel Delta pada titik operasi pembingkaian terbaru. Waktu tersebut belum tentu merupakan keadaan terbaru dari tabel Delta.
Perhatikan bahwa model semantik menganalisis log Delta dari setiap tabel Delta selama pembingkaian untuk hanya menghilangkan segmen kolom yang terpengaruh dan memuat ulang data yang baru ditambahkan selama transcoding. Pengoptimalan penting adalah bahwa kamus biasanya tidak akan dihilangkan ketika pembingkaian bertahap berlaku, dan nilai baru ditambahkan ke kamus yang ada. Pendekatan pembingkaian inkremental ini membantu mengurangi beban muatan ulang dan menguntungkan performa kueri. Dalam kasus ideal, ketika tabel Delta tidak menerima pembaruan, tidak ada pemuatan ulang yang diperlukan untuk kolom yang sudah tinggal dalam memori dan kueri menunjukkan dampak performa yang jauh lebih sedikit setelah pembingkaian karena pembingkaian inkremental pada dasarnya memungkinkan model semantik untuk memperbarui bagian substansial dari data dalam memori yang ada di tempat.
Diagram berikut menunjukkan cara kerja operasi pembingkaian Direct Lake.
diagram 
Diagram menggambarkan proses dan fitur berikut.
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 saat terjadi proses ekstrak, transformasi, dan pemuatan (ETL) yang berlangsung lama.
Refresh untuk model semantik Direct Lake dapat dilakukan secara manual, otomatis, atau terprogram. Untuk informasi selengkapnya, lihat Menyegarkan model semantik Direct Lake.
Untuk informasi selengkapnya tentang 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. Ini 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.
Petunjuk
Anda bisa mengatur 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 endpoint 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 kinerja kueri yang lebih lambat.
Anda dapat mengontrol fallback dari model semantik Direct Lake Anda dengan mengatur properti DirectLakeBehavior. 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 sebaiknya mempertimbangkan untuk membeli langganan kapasitas Fabric (F SKU) sebagai alternatif.
Untuk informasi lebih lanjut, lihat Pembaruan penting yang akan datang ke lisensi Power BI Premium dan Power BI Premium.
| Kain SKU | File format parquet untuk setiap tabel | Kelompok baris per tabel | Baris per tabel (jutaan) | Ukuran model maksimum pada disk/OneLake (GB) | Memori maksimum (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 | Tak Terbatas | 25 |
| F128/P2 | 5,000 | 5,000 | 3,000 | Tak Terbatas | 50 |
| F256/P3 | 5,000 | 5,000 | 6,000 | Tak Terbatas | 100 |
| F512/P4 | 10.000 | 10.000 | 12,000 | Tak Terbatas | 200 |
| F1024/P5 | 10.000 | 10.000 | 24,000 | Tak Terbatas | 400 |
| F2048 | 10.000 | 10.000 | 24,000 | Tak Terbatas | 400 |
1 Untuk model semantik Direct Lake, Memori Maksimal mewakili batas atas sumber daya memori untuk berapa banyak data yang dapat dimuat. Oleh karena itu, ini bukan pembatas pengaman karena melebihinya tidak mengakibatkan fallback ke mode DirectQuery; namun, hal ini dapat berdampak pada kinerja jika jumlah data cukup besar untuk menyebabkan pengambilan dan pelepasan data model secara berlebihan dari data OneLake.
Jika ukuran model Max pada disk/OneLake terlampaui, semua kueri ke model semantik akan kembali ke mode DirectQuery. Semua pagar pembatas lain yang disajikan dalam tabel dievaluasi per kueri. Oleh karena itu penting bahwa Anda mengoptimalkan tabel Delta Anda 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 maksimum memori 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.
Nota
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 Dual (kecuali untuk kasus khusus, termasuk grup perhitungan , parameter bagaimana-jika, dan parameter bidang ).
- Kolom terhitung dan tabel terhitung yang merujuk pada kolom atau tabel dalam modus penyimpanan Direct Lake tidak didukung. Grup perhitungan, parameter 'what-if', dan parameter bidang, yang secara implisit membuat tabel terhitung, serta tabel terhitung yang tidak merujuk pada 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 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.
- Publikasikan ke web dari Power BI menggunakan principal layanan 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, tabulasi Direct Lake dalam riwayat pemutakhiran hanya mencantumkan kegagalan pemutakhiran yang terkait dengan Direct Lake. Operasi refresh (pembingkaian) yang berhasil tidak tercantum.
- SKU Fabric Anda menentukan memori maksimum yang tersedia per model semantik Direct Lake untuk kapasitas. Jika batas terlampaui, kueri ke model semantik kemungkinan akan lebih lambat karena proses paging data model yang berlebihan.
- Membuat model semantik Direct Lake di ruang kerja yang terletak di wilayah yang berbeda dari ruang kerja sumber data tidak didukung. Misalnya, jika Lakehouse berada di US Tengah Barat, maka Anda hanya dapat membuat model semantik dari Lakehouse ini di wilayah yang sama. Solusi alternatif adalah membuat Lakehouse di ruang kerja wilayah lain dan membuat pintasan ke tabel sebelum membuat model semantik. Untuk menemukan wilayah tempat Anda berada, lihat menemukan wilayah asal Fabric Anda.
- Anda dapat membuat dan melihat model semantik Direct Lake kustom menggunakan identitas Perwakilan Layanan, tetapi model semantik Direct Lake default tidak mendukung Perwakilan Layanan. Pastikan autentikasi perwakilan layanan diaktifkan untuk FABRIC REST API di penyewa Anda dan berikan Kontributor perwakilan layanan atau izin yang lebih tinggi ke ruang kerja model semantik Direct Lake Anda.
- Menyematkan laporan memerlukan token semat V2.
- Direct Lake tidak mendukung profil perwakilan layanan untuk autentikasi.
- Model semantik Direct Lake yang disesuaikan yang dibuat oleh Service Principal dan penampil dengan Service Principal didukung, tetapi model semantik Direct Lake default tidak didukung.
Perbandingan dengan mode penyimpanan lainnya
Tabel berikut membandingkan mode penyimpanan Direct Lake dengan mode penyimpanan Impor dan DirectQuery.
| Kemampuan | Danau Langsung | Mengimpor | DirectQuery |
|---|---|---|---|
| Perizinan | 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 | Tidak ada 1 | Ya – dapat dikombinasikan dengan tabel Mode penyimpanan DirectQuery atau Dual | Ya – dapat dikombinasikan dengan tabel mode penyimpanan Impor atau Ganda |
| Sistem masuk tunggal (SSO) | Ya | Tidak berlaku | Ya |
| Tabel terhitung | Tidak – kecuali grup perhitungan , parameter "what-if" , dan parameter bidang , yang secara implisit membentuk tabel terhitung. | Ya | Tidak – tabel terhitung menggunakan mode penyimpanan Impor meskipun merujuk ke tabel lain dalam mode DirectQuery. |
| Kolom yang dihitung | Tidak | Ya | Ya |
| Tabel hibrid | Tidak | Ya | Ya |
| Partisi model tabel | Tidak – namun partisi dapat dilakukan di tingkat tabel Delta | Ya – dibuat secara otomatis oleh pencadangan bertahap, atau dibuat secara manual dengan menggunakan titik akhir XMLA | Tidak |
| 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 pada 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 |
| Model semantik keamanan tingkat baris (RLS) | Ya – tetapi sangat disarankan untuk menggunakan koneksi cloud dengan identitas tetap | Ya | Ya |
| Keamanan tingkat objek model semantik (OLS) | Ya | Ya | Ya |
| Volume data besar tanpa persyaratan refresh | Ya | Kurang cocok - mungkin diperlukan ukuran kapasitas yang lebih besar untuk permintaan data dan memperbarui. | Ya |
| Mengurangi latensi data | Ya – saat pembaruan otomatis diaktifkan, atau reframing terprogram; namun, penyiapan data harus dilakukan di hulu terlebih dahulu | Tidak | Ya |
| Power BI Embedded | Ya 2 | Ya | Ya |
1 Anda tidak dapat menggabungkan tabel mode penyimpanan Direct Lake dengan tabel mode penyimpanan DirectQuery atau Dual 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.
2 Memerlukan token semat V2. Jika Anda menggunakan prinsipal layanan, Anda harus menggunakan identitas tetap koneksi awan.