A Direct Lake áttekintése
A Direct Lake a Microsoft Fabric-munkaterületen tárolt Power BI szemantikai modell tábláinak tárolási módja. Nagy mennyiségű adathoz van optimalizálva, amelyek gyorsan betölthetők a memóriába a Delta-táblákból, amelyek parquet-fájlokban tárolják az adataikat a OneLake-ben – ez az összes elemzési adat egyetlen tárolója. Miután betöltötte a memóriát, a szemantikai modell nagy teljesítményű lekérdezéseket tesz lehetővé. A Direct Lake kiküszöböli az adatok modellbe való importálásának lassú és költséges szükségességét.
A Direct Lake Storage móddal egyetlen Fabric lakehouse vagy Fabric-raktár tábláihoz vagy nézeteihez csatlakozhat. Mindkét Fabric-elemhez és a Direct Lake szemantikai modellhez Fabric-kapacitáslicencet kell igényelni.
Bizonyos módokon a Direct Lake szemantikai modellje hasonló az Import szemantikai modellhez. Ennek az az oka, hogy a VertiPaq motor a gyors lekérdezési teljesítmény érdekében betölti a modelladatokat a memóriába (kivéve a DirectQuery-tartalékot, amelyet a cikk későbbi részében ismertetünk).
A Direct Lake szemantikai modell azonban lényegesen eltér az Import szemantikai modelltől. Ennek az az oka, hogy a Direct Lake szemantikai modell frissítési művelete fogalmilag eltér az Importálás szemantikai modellek frissítési műveletéhez. A Direct Lake szemantikai modell esetében a frissítés keretezési művelettel jár (amelyet a cikk későbbi részében ismertetünk), ami eltarthat néhány másodpercig. Ez egy alacsony költségű művelet, amelyben a szemantikai modell elemzi a Delta-táblák legújabb verziójának metaadatait, és a OneLake legújabb fájljaira hivatkozva frissül. Ezzel szemben egy importálási szemantikai modell esetében a frissítés másolatot készít az adatokról, ami jelentős időt vehet igénybe, és jelentős adatforrás- és kapacitáserőforrásokat (memóriát és PROCESSZORt) használhat fel.
Feljegyzés
Az Importálás szemantikai modell növekményes frissítése segíthet csökkenteni a frissítési időt és a kapacitáserőforrások használatát.
Mikor érdemes Direct Lake-tárolási módot használnia?
A Direct Lake-tárolási mód elsődleges használati esete általában a tóközpontú architektúrákat használó, informatikai alapú elemzési projektekre vonatkozik. Ebben a forgatókönyvben nagy mennyiségű adat van vagy várhatóan halmozódik fel a OneLake-ben. Ebben a használati esetben mind fontos az adatok gyors betöltése a memóriába, a gyakori és gyors frissítési műveletek, a kapacitáserőforrások hatékony használata és a gyors lekérdezési teljesítmény.
Feljegyzés
Az importálási és DirectQuery szemantikai modellek továbbra is relevánsak a Fabricben, és bizonyos forgatókönyvek esetében ezek a szemantikai modellek megfelelő választásának számítanak. Például a tárolási mód importálása gyakran jól működik egy önkiszolgáló elemző számára, akinek szüksége van a szabadságra és a rugalmasságra, hogy gyorsan cselekedjen, és anélkül, hogy az informatikai függőségtől függenek az új adatelemek hozzáadásához.
A OneLake-integráció emellett automatikusan adatokat ír a táblákhoz importálási tárolási módban a OneLake Delta-tábláiba anélkül, hogy migrálási erőfeszítést igényel. Ezzel a lehetőséggel a Fabric számos előnyét kihasználhatja, amelyek a szemantikai modell felhasználói számára elérhetővé válnak, például a lakehouse-okkal való integráció billentyűparancsokkal, SQL-lekérdezésekkel, jegyzetfüzetekkel és egyebekkel. Azt javasoljuk, hogy ezt a lehetőséget a Fabric előnyeinek gyors kihasználásához vegye figyelembe anélkül, hogy szükség esetén vagy azonnal újraterven tartana a meglévő adattárházat és/vagy elemzési rendszert.
A Direct Lake Storage mód az adatkésés minimalizálására is alkalmas, hogy gyorsan elérhetővé tegye az adatokat az üzleti felhasználók számára. Ha a Delta-táblák időnként módosulnak (és feltételezzük, hogy már elvégezte az adatelőkészítést a data lake-ben), a módosításokra válaszul automatikus frissítésektől is függhet. Ebben az esetben a szemantikai modellnek küldött lekérdezések a legfrissebb adatokat fogják visszaadni. Ez a funkció jól működik a Power BI-jelentések automatikus oldalfrissítési funkciójával együttműködve.
Ne feledje, hogy a Direct Lake a data lake-ben végzett adatelőkészítéstől függ. Az adatok előkészítése különböző eszközökkel végezhető el, például a Fabric lakehouse-hoz készült Spark-feladatok, a Fabric-raktárak T-SQL DML-utasításai, adatfolyamok, folyamatok és egyéb eszközök használatával. Ez a megközelítés segít biztosítani az adat-előkészítési logika lehető legalacsonyabb szintű végrehajtását az architektúrában az újrafelhasználhatóság maximalizálása érdekében. Ha azonban a szemantikai modell szerzője nem tudja módosítani a forráselemet, például egy önkiszolgáló elemző esetében, aki esetleg nem rendelkezik írási engedélyekkel az informatikai felügyelet alatt álló tóházban, akkor a Tárolási mód importálása jobb választás lehet. Ennek az az oka, hogy támogatja az adatok előkészítését a Szemantikai modell részeként definiált Power Query használatával.
Ügyeljen arra, hogy figyelembe vegye az aktuális Fabric-kapacitáslicencet és a Fabric-kapacitáskorlátokat , ha a Direct Lake Storage módot veszi figyelembe. Emellett vegye figyelembe a cikk későbbi részében ismertetett szempontokat és korlátozásokat is.
Tipp.
Javasoljuk, hogy készítsen prototípust vagy megvalósíthatósági igazolást (POC) annak megállapításához, hogy a Direct Lake szemantikai modell a megfelelő megoldás-e, és hogy mérsékelje a kockázatokat.
A Direct Lake működése
A Direct Lake szemantikai modellbe küldött lekérdezéseket általában a Delta-táblákból származó oszlopok memóriabeli gyorsítótárából kezelik. A Delta-táblák mögöttes tárolója egy vagy több Parquet-fájl a OneLake-ben. A parquet-fájlok sorok helyett oszlopok szerint rendezik az adatokat. A szemantikai modellek teljes oszlopokat töltenek be a Delta-táblákból a memóriába, ahogy a lekérdezések megkövetelik.
A Direct Lake szemantikai modell directQuery tartalékot is használhat, ami magában foglalja a DirectQuery módra való zökkenőmentes váltást. A DirectQuery tartalék az adatokat közvetlenül a lakehouse vagy a raktár SQL Analytics-végpontjáról kéri le. Tartalék lehet például, ha egy Delta-tábla több adatsort tartalmaz, mint amennyit a Háló kapacitása támogat (erről a cikk későbbi részében olvashat). Ebben az esetben egy DirectQuery-művelet lekérdezést küld az SQL Analytics-végpontnak. A tartalék műveletek lassabb lekérdezési teljesítményt eredményezhetnek.
Az alábbi ábra bemutatja, hogyan működik a Direct Lake egy Power BI-jelentést megnyitó felhasználó forgatókönyvével.
A diagram a következő felhasználói műveleteket, folyamatokat és funkciókat ábrázolja.
| Elem | Leírás |
|---|---|
 |
A OneLake egy adattó, amely parquet formátumban tárolja az elemzési adatokat. Ez a fájlformátum a Direct Lake szemantikai modellek adatainak tárolására van optimalizálva . |
 |
A Fabric lakehouse vagy Fabric-raktár egy Fabric-kapacitással rendelkező munkaterületen található. A lakehouse egy SQL Analytics-végponttal rendelkezik, amely SQL-alapú lekérdezési felületet biztosít. A táblák (vagy nézetek) lehetővé teszik a Delta-táblák lekérdezését a OneLake-ben a Transact-SQL (T-SQL) használatával. |
 |
Egy Direct Lake szemantikai modell létezik egy Fabric-munkaterületen. A tóházban vagy a raktárban lévő táblákhoz vagy nézetekhez csatlakozik. |
 |
A felhasználó megnyit egy Power BI-jelentést. |
 |
A Power BI-jelentés adatelemzési kifejezéseket (DAX) küld a Direct Lake szemantikai modelljének. |
 |
Ha lehetséges (és szükséges), a szemantikai modell közvetlenül a OneLake-ben tárolt Parquet-fájlokból tölti be az oszlopokat a memóriába. A lekérdezések memórián belüli teljesítményt érnek el, ami nagyon gyors. |
 |
A szemantikai modell lekérdezési eredményeket ad vissza. |
 |
A Power BI-jelentés rendereli a vizualizációkat. |
 |
Bizonyos körülmények között, például ha a szemantikai modell túllépi a kapacitás védőkorlátjait , a szemantikai modell lekérdezései automatikusan Visszaesnek DirectQuery módba. Ebben a módban a rendszer lekérdezéseket küld a lakehouse vagy a raktár SQL Analytics-végpontjára. |
 |
Az SQL Analytics-végpontnak küldött DirectQuery-lekérdezések viszont lekérdezik a Delta-táblákat a OneLake-ben. Emiatt a lekérdezés teljesítménye lassabb lehet, mint a memóriában lévő lekérdezések. |
A következő szakaszok a Direct Lake-fogalmakat és funkciókat ismertetik, beleértve az oszlopbetöltést, a keretezést, az automatikus frissítéseket és a DirectQuery-tartalékokat.
Oszlopbetöltés (átkódolás)
A Direct Lake szemantikai modelljei csak akkor töltik be az adatokat a OneLake-ből, amikor és amikor először kérdezik le az oszlopokat. A OneLake-ből igény szerinti adatok betöltésének folyamatát átkódolásnak nevezzük.
Amikor a szemantikai modell KAP egy DAX-lekérdezést (vagy többdimenziós kifejezéseket –MDX), először meghatározza, hogy milyen oszlopok szükségesek a lekérdezés eredményének létrehozásához. A szükséges oszlopok közé tartoznak a lekérdezés által közvetlenül használt oszlopok, valamint a kapcsolatok és mértékek által megkövetelt oszlopok. A lekérdezés eredményének létrehozásához szükséges oszlopok száma általában sokkal kisebb, mint a szemantikai modellben definiált oszlopok száma.
Miután megismerte, hogy mely oszlopokra van szükség, a szemantikai modell határozza meg, hogy mely oszlopok vannak már a memóriában. Ha a lekérdezéshez szükséges oszlopok nem szerepelnek a memóriában, a szemantikai modell minden adatot betölt ezekhez az oszlopokhoz a OneLake-ből. Az oszlopadatok betöltése általában nagyon gyors művelet, azonban olyan tényezőktől függhet, mint például az oszlopokban tárolt adatok számossága.
A memóriába betöltött oszlopok ezután a memóriában vannak. A csak rezidens oszlopokat tartalmazó jövőbeli lekérdezések nem kell több oszlopot betölteni a memóriába.
Az oszlopok mindaddig állandóak maradnak, amíg el nem távolítják (kiürítik) a memóriából. Az oszlopok eltávolításának okai a következők lehetnek:
- A modell vagy a tábla frissült (lásd a következő szakaszban található keretezést ).
- Egy ideje nem használt lekérdezés az oszlopot.
- Egyéb memóriakezelési okok, beleértve a kapacitáson belüli memóriaterhelést más, egyidejű műveletek miatt.
A Fabric termékváltozat választása határozza meg a kapacitás minden Direct Lake szemantikai modelljéhez rendelkezésre álló maximális memóriát. Az erőforrás-védőkorlátokról és a maximális memóriakorlátokról a cikk későbbi részében található fabrickapacitás-védőkorlátokról és korlátozásokról olvashat.
Kialakítása
A keretezés időalapú vezérlést biztosít a modelltulajdonosok számára a szemantikai modellbe betöltött adatok felett. A keretezés egy Direct Lake-művelet, amelyet egy szemantikai modell frissítése vált ki, és a legtöbb esetben csak néhány másodpercet vesz igénybe. Ennek az az oka, hogy ez egy alacsony költségű művelet, amelyben a szemantikai modell elemzi a Delta Lake-táblák legújabb verziójának metaadatait, és a OneLake legújabb Parquet-fájljaira hivatkozva frissül.
Ha keretezés történik, előfordulhat, hogy a rezidens oszlopok ki lesznek távolítva a memóriából, és a frissítés időpontja lesz az új alapkonfiguráció az összes jövőbeli átkódolási eseményhez. Ettől a ponttól kezdve a Direct Lake-lekérdezések csak a legutóbbi keretezési művelet időpontjától veszik figyelembe a Delta-táblák adatait. Emiatt a Direct Lake-táblák lekérdezhetők, hogy a rendszer adatokat ad vissza a Delta-tábla állapotától függően a legutóbbi keretezési művelet időpontjában. Ez az idő nem feltétlenül a Delta-táblák legújabb állapota.
Az alábbi ábra a Direct Lake keretezési műveleteinek működését mutatja be.
A diagram a következő folyamatokat és funkciókat ábrázolja.
| Elem | Leírás |
|---|---|
|
A Fabric-munkaterületen szemantikai modell létezik. |
|
A keretezési műveletek rendszeres időközönként történnek, és az alapkonfigurációt minden jövőbeli átkódolási eseményhez beállítják. A keretezési műveletek automatikusan, manuálisan, ütemezés szerint vagy programozott módon is megtörténhetnek. |
|
A OneLake metaadatokat és Parquet-fájlokat tárol, amelyek Delta-táblákként vannak ábrázolva. |
|
Az utolsó keretezési művelet tartalmazza a Delta-táblákhoz kapcsolódó Parquet-fájlokat, és különösen azokat a Parquet-fájlokat, amelyeket az utolsó keretezési művelet előtt adtak hozzá. |
|
Egy későbbi keretezési művelet tartalmazza az utolsó keretezési művelet után hozzáadott Parquet-fájlokat. |
|
Előfordulhat, hogy a Direct Lake szemantikai modell rezidens oszlopai ki lesznek távolítva a memóriából, és a frissítés időpontja lesz az új alapkonfiguráció az összes jövőbeli átkódolási eseményhez. |
|
Az új Parquet-fájlok által képviselt további adatmódosítások csak a következő keretezési művelet végrehajtásáig láthatók. |
Nem mindig kívánatos, hogy egy átkódolási művelet végrehajtásakor a Delta-táblák legújabb állapotát képviselő adatokkal rendelkezzenek. Vegye figyelembe, hogy a keretezés segíthet konzisztens lekérdezési eredmények biztosításában olyan környezetekben, ahol a Delta-táblák adatai átmenetiek. Az adatok több okból is átmenetiek lehetnek, például hosszú ideig futó kinyerési, átalakítási és betöltési (ETL-) folyamatok esetén.
A Direct Lake szemantikai modell frissítése manuálisan, automatikusan vagy programozott módon is elvégezhető. További információ: Direct Lake szemantikai modellek frissítése.
A Delta-tábla verziószámozásával és keretezésével kapcsolatos további információkért lásd a Direct Lake szemantikai modelljeinek tárolási adatait.
Automatikus frissítések
Van egy szemantikai modellszintű beállítás a Direct Lake-táblák automatikus frissítéséhez. Alapértelmezés szerint engedélyezve van. Biztosítja, hogy a OneLake adatváltozásai automatikusan megjelenjenek a Direct Lake szemantikai modelljében. Ha keretezéssel szeretné szabályozni az adatváltozásokat, le kell tiltania az automatikus frissítéseket, amit az előző szakaszban ismertetettünk. További információ: Direct Lake szemantikai modellek kezelése.
Tipp.
A Power BI-jelentésekben beállíthatja az automatikus oldalfrissítést . Ez egy funkció, amely automatikusan frissít egy adott jelentésoldalt, feltéve, hogy a jelentés direct lake-i szemantikai modellhez (vagy más szemantikai modellhez) csatlakozik.
DirectQuery tartalék
A Direct Lake szemantikai modellnek küldött lekérdezések visszaeshetnek DirectQuery módba. Ebben az esetben közvetlenül a lakehouse vagy a raktár SQL Analytics-végpontjáról kér le adatokat. Az ilyen lekérdezések mindig a legújabb adatokat adnak vissza, mert nincsenek korlátozva az utolsó keretezési művelet időpontjához.
A lekérdezések mindig visszaesnek, ha a szemantikai modell lekérdez egy nézetet az SQL Analytics-végponton, vagy egy táblát az SQL Analytics-végponton, amely sorszintű biztonságot (RLS) kényszerít.
Egy lekérdezés akkor is visszaeshet, ha a szemantikai modell túllépi a kapacitás védőkorlátjait.
Fontos
Ha lehetséges, a DirectQuery visszaesésének elkerülése érdekében mindig tervezzen megoldást – vagy méretezhesse a kapacitást. Ennek az az oka, hogy lassabb lekérdezési teljesítményt eredményezhet.
A Direct Lake szemantikai modelljeinek visszavételét a DirectLakeBehavior tulajdonság beállításával szabályozhatja. További információ: A Direct Lake viselkedési tulajdonságának beállítása.
Hálókapacitás-védőkorlátok és korlátozások
A Direct Lake szemantikai modelljeinek fabrickapacitás-licencre van szükségük. Emellett a Fabric-kapacitás-előfizetésre (SKU) vonatkozó kapacitáskorlátok és korlátozások is érvényesek az alábbi táblázatban ismertetett módon.
Fontos
A következő táblázat első oszlopa a Power BI Premium-kapacitás-előfizetéseket (P SKU-kat) is tartalmazza. Vegye figyelembe, hogy a Microsoft konszolidálja a vásárlási lehetőségeket, és visszavonul a Power BI Premium kapacitásonkénti termékváltozataitól. Az új és a meglévő ügyfeleknek érdemes megfontolni a Fabric-kapacitás-előfizetések (F SKU-k) megvásárlását.
További információ: Fontos frissítés a Power BI Premium licenceléséhez és a Power BI Premiumhoz.
| Háló termékváltozata | Táblázatonkénti fájlok parquet | Sorcsoportok táblánként | Sorok táblázatonként (millió) | Maximális modellméret lemezen/OneLake-en (GB) | Maximális memória (GB) 1 |
|---|---|---|---|---|---|
| F2 | 1000 | 1000 | 300 | 10 | 3 |
| F4 | 1000 | 1000 | 300 | 10 | 3 |
| F8 | 1000 | 1000 | 300 | 10 | 3 |
| F16 | 1000 | 1000 | 300 | 20 | 5 |
| F32 | 1000 | 1000 | 300 | 40 | 10 |
| F64/FT1/P1 | 5000 | 5000 | 1500 | Korlátlan | 25 |
| F128/P2 | 5000 | 5000 | 3000 | Korlátlan | 50 |
| F256/P3 | 5000 | 5000 | 6000 | Korlátlan | 100 |
| F512/P4 | 10,000. | 10,000. | 12 000 | Korlátlan | 200 |
| F1024/P5 | 10,000. | 10,000. | 24,000 | Korlátlan | 400 |
| F2048 | 10,000. | 10,000. | 24,000 | Korlátlan | 400 |
1 A Direct Lake szemantikai modelljei esetében a Maximális memória azt a felső memóriaerőforrás-korlátot jelöli, amelyben az adatok hány adatot tartalmazhatnak. Ezért ez nem egy védőkorlát, mert a túllépése nem jár a DirectQuery módra való visszalépéssel; azonban a teljesítményre is hatással lehet, ha az adatok mennyisége elég nagy ahhoz, hogy túlzott lapozást okozzon a modell adataiban és azon kívül a OneLake-adatokból.
Ha túllépi, a lemez/OneLake maximális modellmérete miatt a szemantikai modell összes lekérdezése Visszaesik DirectQuery módba. A táblában bemutatott összes többi védőkorlátot a rendszer lekérdezésenként értékeli ki. Ezért fontos, hogy optimalizálja a Delta-táblákat és a Direct Lake szemantikai modellt , hogy ne kelljen szükségtelenül felskáláznia egy magasabb fabric termékváltozatra (ami nagyobb költséget eredményez).
Emellett a kapacitásegység és a lekérdezésenkénti maximális memóriakorlát a Direct Lake szemantikai modelljeire is vonatkozik. További információ: Kapacitások és termékváltozatok.
Szempontok és korlátozások
A Direct Lake szemantikai modelljei megfontolandó szempontokat és korlátozásokat jelentenek.
Feljegyzés
A Direct Lake szemantikai modelljeinek képességei és funkciói folyamatosan fejlődnek. A megfontolandó szempontok és korlátozások legújabb listájának áttekintéséhez mindenképpen rendszeresen térjen vissza.
- Ha egy Direct Lake szemantikai modelltábla csatlakozik egy táblához az SQL Analytics-végponton, amely sorszintű biztonságot (RLS) kényszerít, a modelltáblát tartalmazó lekérdezések mindig DirectQuery módba kerülnek. A lekérdezés teljesítménye lassabb lehet.
- Amikor egy Direct Lake szemantikai modelltábla csatlakozik egy nézethez az SQL Analytics-végponton, a modelltáblát tartalmazó lekérdezések mindig DirectQuery módba kerülnek. A lekérdezés teljesítménye lassabb lehet.
- Az összetett modellezés nem támogatott. Ez azt jelenti, hogy a Direct Lake szemantikai modelltáblái nem keverhetők más tárolási módokon lévő táblákkal, például Importálás, DirectQuery vagy Kettős (kivéve a speciális eseteket, beleértve a számítási csoportokat, a lehetőségelemzési paramétereket és a mezőparamétereket).
- A Direct Lake Storage módban lévő oszlopokra vagy táblákra hivatkozó számított oszlopok és számított táblák nem támogatottak. Támogatottak a számított táblákat implicit módon létrehozó számítási csoportok, lehetőségelemzési paraméterek és mezőparaméterek, valamint a Direct Lake-oszlopokra vagy táblákra nem hivatkozó számított táblák.
- A Direct Lake storage módú táblák nem támogatják az összetett Delta-táblaoszloptípusokat. A bináris és GUID szemantikai típusok szintén nem támogatottak. Ezeket az adattípusokat sztringekké vagy más támogatott adattípusokká kell konvertálnia.
- A táblakapcsolatoknak meg kell felelnie a kapcsolódó oszlopok adattípusainak.
- A kapcsolatok egyoldalas oszlopainak egyedi értékeket kell tartalmazniuk. A lekérdezések sikertelenek lesznek, ha ismétlődő értékeket észlel egy egyoldalas oszlopban.
- Az automatikus adat-/időintelligencia a Power BI Desktopban nem támogatott. A saját dátumtáblázat dátumtáblázatként való megjelölése támogatott.
- A sztringoszlopértékek hossza legfeljebb 32 764 Unicode-karakter lehet.
- A naN lebegőpontos érték (nem szám) nem támogatott.
- Az ügyfélhasználati forgatókönyvet használó beágyazási forgatókönyvek nem támogatottak.
- A Webes közzététel a Power BI-ból csak akkor támogatott, ha rögzített identitást használ a Direct Lake szemantikai modellhez.
- A webes modellezési felületen az ellenőrzés a Direct Lake szemantikai modelljeire korlátozódik. A rendszer feltételezi, hogy a felhasználói beállítások helyesek, és a rendszer nem ad ki lekérdezéseket a kapcsolatok számosságának vagy keresztszűrésének ellenőrzésére, illetve a kijelölt dátumtábla kijelölt dátumoszlopára vonatkozóan.
- A Háló portálon a frissítési előzmények Direct Lake lapja csak a Direct Lake-hez kapcsolódó frissítési hibákat sorolja fel. A sikeres frissítési (keretezési) műveletek nincsenek felsorolva.
- A Háló termékváltozat határozza meg a kapacitáshoz tartozó Direct Lake szemantikai modellenkénti maximális rendelkezésre álló memóriát. Ha túllépi a korlátot, a szemantikai modellbe való lekérdezések lassabbak lehetnek a modell adatainak túlzott lapozása miatt.
- Nem támogatott Direct Lake szemantikai modell létrehozása egy olyan munkaterületen, amely az adatforrás-munkaterület egy másik régiójában található. Ha például a Lakehouse az USA nyugati középső régiójában található, akkor ebből a Lakehouse-ból csak ugyanabban a régióban hozhat létre szemantikai modelleket. Megkerülő megoldásként létre kell hozni egy Lakehouse-t a másik régió munkaterületén, és a táblákra mutató parancsikont a szemantikai modell létrehozása előtt. Ha meg szeretné tudni, hogy melyik régióban tartózkodik, keresse meg a Fabric otthoni régióját.
- Létrehozhat és megtekinthet egyéni Direct Lake szemantikai modellt szolgáltatásnév-identitással, de az alapértelmezett Direct Lake szemantikai modell nem támogatja a szolgáltatásnevek használatát. Győződjön meg arról, hogy a szolgáltatásnév hitelesítése engedélyezve van a fabric REST API-k számára a bérlőben, és adjon a szolgáltatásnév közreműködőjének vagy magasabb szintű engedélyeket a Direct Lake szemantikai modell munkaterületének.
- A Direct Lake nem támogatja a szolgáltatásnév-profilokat a hitelesítéshez.
Összehasonlítás más tárolási móddal
Az alábbi táblázat összehasonlítja a Direct Lake tárolási módot az Importálás és a DirectQuery tárolási móddal.
| Funkció | Direct Lake | Importálás | DirectQuery |
|---|---|---|---|
| Licencek | Csak hálókapacitás-előfizetés (termékváltozatok) | Bármilyen Fabric- vagy Power BI-licenc (beleértve a Microsoft Fabric ingyenes licenceit is) | Bármilyen Fabric- vagy Power BI-licenc (beleértve a Microsoft Fabric ingyenes licenceit is) |
| Adatforrás | Csak lakehouse- vagy raktártáblák (vagy nézetek) | Bármely összekötő | Minden olyan összekötő, amely támogatja a DirectQuery módot |
| Csatlakozás SQL Analytics-végpontnézetekhez | Igen – de automatikusan visszaesik DirectQuery módba | Igen | Igen |
| Összetett modellek | No 1 | Igen – Kombinálható DirectQuery- vagy kettős tárolási módú táblákkal | Igen – kombinálható importálási vagy kettős tárolási módú táblákkal |
| Egyszeri bejelentkezés (SSO) | Igen | Nem alkalmazható | Igen |
| Számított táblák | Nem – kivéve a számítási csoportokat, a lehetőségelemzési paramétereket és a mezőparamétereket, amelyek implicit módon számított táblákat hoznak létre | Igen | Nem – a számított táblák akkor is importálják a tárolási módot, ha más táblákra hivatkoznak DirectQuery módban |
| Számított oszlopok | Nem | Igen | Igen |
| Hibrid táblák | Nem | Igen | Igen |
| Táblapartíciók modellezése | Nem – a particionálás azonban elvégezhető a Delta tábla szintjén | Igen – automatikusan növekményes frissítéssel, vagy manuálisan az XMLA-végpont használatával | Nem |
| Felhasználó által definiált összesítések | Nem | Igen | Igen |
| SQL Analytics-végpont objektumszintű biztonsága vagy oszlopszintű biztonsága | Igen – de a lekérdezések visszaesnek DirectQuery módba, és hibákat eredményezhetnek, ha az engedély megtagadva van | Igen – de duplikálnia kell az engedélyeket szemantikai modell objektumszintű biztonságával | Igen – de a lekérdezések hibákat eredményezhetnek, ha az engedély megtagadva van |
| SQL Analytics-végpont sorszintű biztonsága (RLS) | Igen – de a lekérdezések vissza fognak esni DirectQuery módba | Igen – de duplikálnia kell az engedélyeket szemantikai modell RLS-sel | Igen |
| Szemantikai modell sorszintű biztonsága (RLS) | Igen – de erősen ajánlott rögzített identitásfelhő-kapcsolat használata | Igen | Igen |
| Szemantikai modell objektumszintű biztonsága (OLS) | Igen | Igen | Igen |
| Nagy adatmennyiségek frissítési követelmény nélkül | Igen | Kevésbé megfelelő – nagyobb kapacitásméretre lehet szükség a lekérdezéshez és a frissítéshez | Igen |
| Adatkésés csökkentése | Igen – ha az automatikus frissítések engedélyezve vannak, vagy programozott reframing; az adatelőkészítést azonban előbb a felsőbb rétegben kell elvégezni | Nem | Igen |
1 A Direct Lake tárolási módú táblák nem kombinálhatók DirectQuery- vagy kettős tárolási módú táblákkal ugyanabban a szemantikai modellben. A Power BI Desktop használatával azonban létrehozhat egy összetett modellt egy Direct Lake szemantikai modellen, majd kiterjesztheti új táblákkal (Importálás, DirectQuery vagy Kettős tárolási mód használatával) vagy számításokkal. További információ: Összetett modell létrehozása szemantikai modellre.