Danau Langsung
Mode Direct Lake adalah kemampuan model semantik untuk menganalisis volume data yang sangat besar di Power BI. Direct Lake didasarkan pada pemuatan file berformat parket langsung dari data lake tanpa harus mengkueri lakehouse atau titik akhir gudang, dan tanpa harus mengimpor atau menduplikasi data ke dalam model Power BI. Direct Lake adalah jalur cepat untuk memuat data dari danau langsung ke mesin Power BI, siap untuk analisis. Diagram berikut menunjukkan bagaimana mode impor klasik dan DirectQuery dibandingkan dengan mode Direct Lake.
Dalam mode DirectQuery, mesin Power BI meminta data di sumbernya, yang bisa lambat tetapi menghindari harus menyalin data seperti dengan mode impor. Setiap perubahan di sumber data segera tercermin dalam hasil kueri.
Di sisi lain, dengan mode impor, performa bisa lebih baik karena data di-cache dan dioptimalkan untuk kueri laporan DAX dan MDX tanpa harus menerjemahkan dan meneruskan SQL atau jenis kueri lainnya ke sumber data. Namun, mesin Power BI harus terlebih dahulu menyalin data baru apa pun ke dalam model selama refresh. Setiap perubahan di sumber hanya diambil dengan refresh model berikutnya.
Mode Direct Lake menghilangkan persyaratan impor dengan memuat data langsung dari OneLake. Tidak seperti DirectQuery, tidak ada terjemahan dari DAX atau MDX ke bahasa kueri lain atau eksekusi kueri pada sistem database lain, menghasilkan performa yang mirip dengan mode impor. Karena tidak ada proses impor eksplisit, dimungkinkan untuk mengambil perubahan apa pun di sumber data saat terjadi, menggabungkan keuntungan mode DirectQuery dan impor sambil menghindari kerugiannya. Mode Direct Lake dapat menjadi pilihan ideal untuk menganalisis model dan model yang sangat besar dengan pembaruan yang sering di sumber data.
Direct Lake juga mendukung keamanan tingkat baris dan keamanan tingkat objek sehingga pengguna hanya melihat data yang izinnya mereka lihat.
Prasyarat
Direct Lake hanya didukung pada SKU Microsoft Premium (P) dan Microsoft Fabric (F).
Penting
Untuk pelanggan baru, Direct Lake hanya didukung pada SKU Microsoft Fabric (F). Pelanggan yang ada dapat terus menggunakan Direct Lake dengan SKU Premium (P), tetapi transisi ke SKU kapasitas Fabric disarankan. Lihat pengumuman lisensi untuk informasi selengkapnya tentang lisensi Power BI Premium.
Lakehouse
Sebelum menggunakan Direct Lake, Anda harus menyediakan lakehouse (atau gudang) dengan satu atau beberapa tabel Delta di ruang kerja yang dihosting pada kapasitas Microsoft Fabric yang didukung. Lakehouse diperlukan karena menyediakan lokasi penyimpanan untuk file berformat parket Anda di OneLake. Lakehouse juga menyediakan titik akses untuk meluncurkan fitur Pemodelan Web untuk membuat model Direct Lake.
Untuk mempelajari cara menyediakan lakehouse, buat tabel Delta di lakehouse, dan buat model dasar untuk lakehouse, lihat Membuat lakehouse untuk Direct Lake.
Titik akhir SQL
Sebagai bagian dari penyediaan lakehouse, titik akhir SQL untuk kueri SQL dan model default untuk pelaporan dibuat dan diperbarui dengan tabel apa pun yang ditambahkan ke lakehouse. Meskipun mode Direct Lake tidak mengkueri titik akhir SQL saat memuat data langsung dari OneLake, model Direct Lake harus dengan mulus kembali ke mode DirectQuery, seperti ketika sumber data menggunakan fitur tertentu seperti keamanan atau tampilan tingkat lanjut yang tidak dapat dibaca melalui Direct Lake. Mode Direct Lake juga mengkueri titik akhir SQL untuk informasi terkait skema dan keamanan.
Gudang Data
Sebagai alternatif untuk lakehouse dengan titik akhir SQL, Anda juga dapat menyediakan gudang dan menambahkan tabel dengan menggunakan pernyataan SQL atau alur data. Prosedur untuk menyediakan gudang data mandiri hampir identik dengan prosedur untuk lakehouse.
Dukungan penulisan model dengan titik akhir XMLA
Model Direct Lake mendukung operasi tulis melalui titik akhir XMLA dengan menggunakan alat seperti SQL Server Management Studio (19.1 dan yang lebih tinggi), dan versi terbaru alat BI eksternal seperti Editor Tabular dan studio DAX. Operasi penulisan model melalui dukungan titik akhir XMLA:
Menyesuaikan, menggabungkan, membuat skrip, men-debug, dan menguji metadata model Direct Lake.
Kontrol sumber dan versi, integrasi berkelanjutan, dan penyebaran berkelanjutan (CI/CD) dengan Azure DevOps dan GitHub.
Tugas otomatisasi seperti merefresh, dan menerapkan perubahan pada model Direct Lake dengan menggunakan PowerShell dan REST API.
Perhatikan bahwa tabel Direct Lake yang dibuat menggunakan aplikasi XMLA pada awalnya akan berada dalam status tidak diolah hingga aplikasi mengeluarkan perintah refresh. Tabel yang tidak diolah kembali ke mode DirectQuery. Saat membuat model semantik baru, pastikan untuk menyegarkan model semantik Anda untuk memproses tabel Anda.
Aktifkan XMLA baca-tulis
Sebelum melakukan operasi tulis pada model Direct Lake melalui titik akhir XMLA, baca-tulis XMLA harus diaktifkan untuk kapasitas.
Untuk kapasitas uji coba Fabric, pengguna uji coba memiliki hak istimewa admin yang diperlukan untuk mengaktifkan baca-tulis XMLA.
Di portal Admin, pilih Pengaturan kapasitas.
Klik tab Uji Coba .
Pilih kapasitas dengan Uji Coba dan nama pengguna Anda dalam nama kapasitas.
Perluas beban kerja Power BI, lalu di pengaturan Titik Akhir XMLA, pilih Baca Tulis.
Perlu diingat, pengaturan Titik Akhir XMLA berlaku untuk semua ruang kerja dan model yang ditetapkan ke kapasitas.
Metadata model Direct Lake
Saat menyambungkan ke model Direct Lake mandiri melalui titik akhir XMLA, metadata terlihat seperti model lainnya. Namun, model Direct Lake menunjukkan perbedaan berikut:
Properti
compatibilityLevelobjek database adalah 1604 atau lebih tinggi.ModeProperti partisi Direct Lake diatur kedirectLake.Partisi Direct Lake menggunakan ekspresi bersama untuk menentukan sumber data. Ekspresi menunjuk ke titik akhir SQL dari lakehouse atau gudang. Direct Lake menggunakan titik akhir SQL untuk menemukan skema dan informasi keamanan tetapi memuat data langsung dari tabel Delta (kecuali Direct Lake harus kembali ke mode DirectQuery karena alasan apa pun).
Berikut adalah contoh kueri XMLA di SSMS:
Untuk mempelajari selengkapnya tentang dukungan alat melalui titik akhir XMLA, lihat Konektivitas model semantik dengan titik akhir XMLA.
Fallback
Model semantik Power BI dalam mode Direct Lake membaca tabel Delta langsung dari OneLake. Namun, jika kueri DAX pada model Direct Lake melebihi batas untuk SKU, atau menggunakan fitur yang tidak mendukung mode Direct Lake, seperti tampilan SQL di gudang, kueri dapat kembali ke mode DirectQuery. Dalam mode DirectQuery, kueri menggunakan SQL untuk mengambil hasil dari titik akhir SQL lakehouse atau gudang, yang dapat memengaruhi performa kueri. Anda dapat menonaktifkan fallback ke mode DirectQuery jika Anda ingin memproses kueri DAX hanya dalam mode Direct Lake murni. Menonaktifkan fallback disarankan jika Anda tidak memerlukan fallback ke DirectQuery. Ini juga dapat membantu saat menganalisis pemrosesan kueri untuk model Direct Lake untuk mengidentifikasi apakah dan seberapa sering fallback terjadi. Untuk mempelajari selengkapnya tentang mode DirectQuery, lihat Mode model semantik di Power BI.
Pagar pembatas menentukan batas sumber daya untuk mode Direct Lake di luar mode fallback ke DirectQuery diperlukan untuk memproses kueri DAX. Untuk detail tentang cara menentukan jumlah file parket dan grup baris untuk tabel Delta, lihat referensi properti tabel Delta.
Untuk model semantik Direct Lake, Memori Maks mewakili batas sumber daya memori atas untuk berapa banyak data yang dapat di-paged in. Akibatnya, ini bukan pagar pembatas karena melebihinya tidak menyebabkan fallback ke DirectQuery; namun, hal ini dapat berdampak pada performa jika jumlah data cukup besar untuk menyebabkan paging masuk dan keluar dari data model dari data OneLake.
Tabel berikut mencantumkan pagar pembatas sumber daya dan Memori Maks:
| SKU Fabric | File parket per tabel | Grup baris per tabel | Baris per tabel (jutaan) | Ukuran model maks pada disk/OneLake1 (GB) | Memori maks (GB) |
|---|---|---|---|---|---|
| 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 - Jika terlampaui, Ukuran model maks pada disk/Onelake akan menyebabkan semua kueri ke model kembali ke DirectQuery, tidak seperti pagar pembatas lain yang dievaluasi per kueri.
Bergantung pada SKU Fabric Anda, unit Kapasitas tambahan dan batas memori Maks per kueri juga berlaku untuk model Direct Lake. Untuk mempelajari lebih lanjut, lihat Kapasitas dan SKU.
Perilaku fallback
Model Direct Lake mencakup properti DirectLakeBehavior , yang memiliki tiga opsi:
Otomatis - (Default) Menentukan kueri kembali ke mode DirectQuery jika data tidak dapat dimuat secara efisien ke dalam memori.
DirectLakeOnly - Menentukan semua kueri hanya menggunakan mode Direct Lake. Mode Fallback ke DirectQuery dinonaktifkan. Jika data tidak dapat dimuat ke dalam memori, kesalahan akan dikembalikan. Gunakan pengaturan ini untuk menentukan apakah kueri DAX gagal memuat data ke dalam memori, memaksa kesalahan dikembalikan.
DirectQueryOnly - Menentukan semua kueri hanya menggunakan mode DirectQuery. Gunakan pengaturan ini untuk menguji performa fallback.
Properti DirectLakeBehavior dapat dikonfigurasi dengan menggunakan Model Objek Tabular (TOM) atau Bahasa Pembuatan Skrip Model Tabular (TMSL).
Contoh berikut menentukan semua kueri hanya menggunakan mode Direct Lake:
// Disable fallback to DirectQuery mode.
//
database.Model.DirectLakeBehavior = DirectLakeBehavior.DirectLakeOnly = 1;
database.Model.SaveChanges();
Menganalisis pemrosesan kueri
Untuk menentukan apakah kueri DAX visual laporan ke sumber data memberikan performa terbaik dengan menggunakan mode Direct Lake, atau kembali ke mode DirectQuery, Anda dapat menggunakan Penganalisis performa di Power BI Desktop, SQL Server Profiler, atau alat pihak ketiga lainnya untuk menganalisis kueri. Untuk mempelajari selengkapnya, lihat Menganalisis pemrosesan kueri untuk model Direct Lake.
Refresh
Secara default, perubahan data di OneLake secara otomatis tercermin dalam model Direct Lake. Anda dapat mengubah perilaku ini dengan menonaktifkan Selalu perbarui data Direct Lake Anda di pengaturan model.
Anda mungkin ingin menonaktifkan jika, misalnya, Anda perlu mengizinkan penyelesaian pekerjaan persiapan data sebelum mengekspos data baru kepada konsumen model. Saat dinonaktifkan, Anda dapat memanggil refresh secara manual atau dengan menggunakan API refresh. Memanggil refresh untuk model Direct Lake adalah operasi biaya rendah di mana model menganalisis metadata versi terbaru tabel Delta Lake dan diperbarui untuk mereferensikan file terbaru di OneLake.
Perhatikan bahwa Power BI dapat menjeda pembaruan otomatis tabel Direct Lake jika kesalahan yang tidak dapat dipulihkan ditemui selama refresh, jadi pastikan model semantik Anda dapat berhasil di-refresh. Power BI secara otomatis melanjutkan pembaruan otomatis saat refresh yang dipanggil pengguna berikutnya selesai tanpa kesalahan.
Keamanan akses data berlapis
Model Direct Lake yang dibuat di atas lakehouse dan gudang mematuhi model keamanan berlapis yang didukung lakehouses dan gudang dengan melakukan pemeriksaan izin melalui Titik Akhir T-SQL untuk menentukan apakah identitas yang mencoba mengakses data memiliki izin akses data yang diperlukan. Secara default, model Direct Lake menggunakan akses menyeluruh (SSO), sehingga izin efektif pengguna interaktif menentukan apakah pengguna diizinkan atau ditolak akses ke data. Jika model Direct Lake dikonfigurasi untuk menggunakan identitas tetap, izin efektif dari identitas tetap menentukan apakah pengguna yang berinteraksi dengan model semantik dapat mengakses data. Titik Akhir T-SQL mengembalikan Izin atau Ditolak ke model Direct Lake berdasarkan kombinasi keamanan OneLake dan izin SQL.
Misalnya, administrator gudang dapat memberikan izin SELECT pengguna pada tabel sehingga pengguna dapat membaca dari tabel tersebut meskipun pengguna tidak memiliki izin keamanan OneLake. Pengguna diotorisasi di tingkat lakehouse/gudang. Sebaliknya, administrator gudang juga dapat MENOLAK akses baca pengguna ke tabel. Pengguna kemudian tidak akan dapat membaca dari tabel tersebut meskipun pengguna memiliki izin Baca keamanan OneLake. Pernyataan DENY mengesampingkan keamanan OneLake atau izin SQL yang diberikan. Lihat tabel berikut untuk izin efektif yang dapat diberikan pengguna kombinasi keamanan OneLake dan izin SQL.
| Izin keamanan OneLake | Izin SQL | Izin efektif |
|---|---|---|
| Izinkan | Tidak | Izinkan |
| Tidak | Bolehkan | Bolehkan |
| Bolehkan | Tolak | Tolak |
| Tidak | Tolak | Tolak |
Masalah dan batasan yang diketahui
Secara desain, hanya tabel dalam model semantik yang berasal dari tabel dalam mode Lakehouse atau Gudang mendukung Direct Lake. Meskipun tabel dalam model dapat berasal dari tampilan SQL di Lakehouse atau Gudang, kueri yang menggunakan tabel tersebut akan kembali ke mode DirectQuery.
Tabel model semantik Direct Lake hanya dapat berasal dari tabel dan pemandangan dari satu Lakehouse atau Gudang.
Tabel Direct Lake saat ini tidak dapat dicampur dengan jenis tabel lain, seperti Impor, DirectQuery, atau Dual, dalam model yang sama. Model komposit saat ini tidak didukung.
Hubungan DateTime tidak didukung dalam model Direct Lake.
Kolom terhitung dan tabel terhitung tidak didukung.
Beberapa jenis data mungkin tidak didukung, seperti desimal presisi tinggi dan jenis uang.
Tabel 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 jenis data kolom kuncinya bertepatan. Kolom kunci primer harus berisi nilai unik. Kueri DAX akan gagal jika nilai kunci primer duplikat terdeteksi.
Panjang nilai kolom string dibatasi hingga 32.764 karakter Unicode.
Nilai titik mengambang 'NaN' (Bukan Angka) tidak didukung dalam model Direct Lake.
Skenario yang disematkan yang mengandalkan entitas yang disematkan belum didukung.
Validasi terbatas untuk model Direct Lake. Pilihan pengguna diasumsikan benar dan tidak ada kueri yang akan memvalidasi pilihan kardinalitas dan filter silang untuk hubungan, atau untuk kolom tanggal yang dipilih dalam tabel tanggal.
Tab Direct Lake dalam riwayat Refresh hanya mencantumkan kegagalan refresh terkait Direct Lake. Refresh yang berhasil saat ini dihilangkan.
Memulai
Cara terbaik untuk memulai solusi Direct Lake di organisasi Anda adalah dengan membuat Lakehouse, membuat tabel Delta di dalamnya, lalu membuat model semantik dasar untuk lakehouse di ruang kerja Microsoft Fabric Anda. Untuk mempelajari selengkapnya, lihat Membuat lakehouse untuk Direct Lake.
Konten terkait
Saran dan Komentar
Segera hadir: Sepanjang tahun 2024 kami akan menghentikan penggunaan GitHub Issues sebagai mekanisme umpan balik untuk konten dan menggantinya dengan sistem umpan balik baru. Untuk mengetahui informasi selengkapnya, lihat: https://aka.ms/ContentUserFeedback.
Kirim dan lihat umpan balik untuk