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 Delta-táblákból, amelyek az adataikat Parquet-fájlokban tárolják OneLake- az összes elemzési adat egyetlen tárolójában. 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ód használatával egyetlen Fabric lakehouse- vagy Fabric-raktártábláihoz vagy nézeteihez csatlakozhat. A Fabric-elemekhez és a Direct Lake szemantikai modellekhez Fabric-kapacitáslicenc szükséges.
Bizonyos módokon a Direct Lake szemantikai modell hasonló az Import szemantikai modell. Ennek az az oka, hogy a VertiPaq motor betölti a modelladatokat a memóriába a gyors lekérdezési teljesítmény érdekében (kivéve DirectQuery tartalékesetében, 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 egy művelet keretezését foglalja magában (ezt a cikk későbbi részében ismertetjük), amely néhány másodpercig is eltarthat. 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.
Jegyzet
Import szemantikai modell növekményes frissítési 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 projektek esetében fordul elő. 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.
Jegyzet
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 az Import tárolási mód 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 ne függjön az informatikától az új adatelemek hozzáadásában.
Emellett OneLake integrációs automatikusan adatokat ír a táblákhoz importálási tárolási módban, hogy Delta-táblákat a OneLake-ben 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 végzett adatelőkészítést a data lake-ben), automatikus frissítésektől a módosításokra válaszul újrakeretezést végezhet. Ebben az esetben a szemantikai modellnek küldött lekérdezések a legújabb adatokat adják vissza. Ez a funkció jól együttműködik a Power BI-jelentések automatikus oldalfrissítési funkciójával.
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 ha egy önkiszolgáló elemző nem rendelkezik írási engedélyekkel az informatikai felügyelet alatt álló lakehouse-on, 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 a jelenlegi Fabric-kapacitás-licenc-et és a Fabric kapacitáskorlátját, ha a Direct Lake tárolási módot mérlegeli. Figyelembe kell venni az szempontokat és korlátozásokatis, amelyeket a cikk későbbi részében ismertetünk.
Borravaló
Javasoljuk, hogy készítsen egy prototípust– vagy a koncepció igazolását (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ékis használható, amely magában foglalja DirectQuery módra való zökkenőmentes váltást. A DirectQuery tartalék közvetlenül a lakehouse vagy a raktár SQL Analytics-végpontjáról kéri le az adatokat. Például visszaesés következhet be, ha egy Delta-tábla több adatsort tartalmaz, mint amennyit a Fabric-kapacitás támogat (a cikkben később leírtak szerint). 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.
| Cikk | 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 optimalizált. |
|
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 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 meghaladja a kapacitás védőkorlátokat, a szemantikai modell lekérdezései automatikusan DirectQuery módba kerülnek vissza. Ebben a módban a rendszer lekérdezéseket küld a lakehouse vagy az adattárház 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 az igény szerint betöltött adatok folyamata transzkódolásnéven ismert.
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 lekérdezés által közvetlenül használt oszlopokra, valamint a kapcsolatok és mértékek által megkövetelt oszlopokra is szükség van. A lekérdezés eredményének létrehozásához szükséges oszlopok száma általában jelentősen kisebb, mint a szemantikai modellben definiált oszlopok száma.
Miután megismerte, hogy mely oszlopokra van szükség, a szemantikai modell meghatározza, 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 gyors művelet, azonban olyan tényezőktől függhet, mint az oszlopokban tárolt adatok számossága.
A memóriába betöltött oszlopok ezután memóriabeli rezidens. A jövőbeli lekérdezések, amelyek csak rezidens oszlopokat tartalmaznak, nem igénylik további oszlopok memóriába tölését.
Az oszlop mindaddig a memóriában marad, amíg nincs ok a memóriából való eltávolítására. Az oszlopok eltávolításának okai a következők lehetnek:
- A modell vagy tábla frissült a forrás Delta-táblájának frissítése után (lásd a következő szakaszban Keretezés).
- Egy ideje egy lekérdezés sem használta 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 SKU választása meghatározza a kapacitás minden egyes 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, a Fabric-kapacitáskorlátok és korlátozások kifejtésénél olvashat több információt alatt.
Keretezés
Keretezés lehetővé teszi a modelltulajdonosok számára, hogy pontszerű irányítást biztosítson, mely adatok kerüljenek betöltésre a szemantikai modellbe. 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ésre kerül sor, a táblázat oszlopainak rezidens szegmensei és szótárai eltávolíthatók a memóriából, ha az alapul szolgáló adatok megváltoztak, és a frissítés időpontja lesz az új alap 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. A Direct Lake-táblák lekérdezése során emiatt az adatok úgy kerülnek visszaadásra, hogy figyelembe veszik a Delta-tábla állapotát a legutóbbi keretezési művelet időpontjában . Ez az időpont nem feltétlenül tükrözi a Delta-táblák legújabb állapotát.
Vegye figyelembe, hogy a szemantikai modell elemzi az egyes Delta-táblák Delta-naplóját a keretezés során, hogy csak az érintett oszlopszegmenseket dobja el, és az újonnan hozzáadott adatokat újra betöltse a transzkódolás során. Fontos optimalizálás, hogy a szótárakat általában nem vetik el, amikor az inkrementális keretezés érvénybe lép, és új értékeket adnak hozzá a meglévő szótárakhoz. Ez a fokozatos keretezési megközelítés segít csökkenteni az újratöltési terhet, és javítja a lekérdezési teljesítményt. Ideális esetben, ha egy Delta-tábla nem kapott frissítéseket, nincs szükség újratöltésre a memóriában már található oszlopokhoz, és a lekérdezések sokkal kisebb teljesítményt mutatnak a keretezés után, mivel a növekményes keretezés lényegében lehetővé teszi a szemantikai modell számára a meglévő memóriabeli adatok jelentős részének frissítését.
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.
| Cikk | 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 minden jövőbeli transzkódolási esemény alaptervét 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 a utolsó keretezési művelet előtt adtak hozzá. |
|
|
A későbbi keretezési művelet a utolsó keretezési művelet után hozzáadott Parquet-fájlokat is tartalmazza. |
|
|
Előfordulhat, hogy a Direct Lake szemantikai modell rezidens oszlopai eltávolíthatók a memóriából, és a frissítés időpontja lesz az új alapérték az összes jövőbeni á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áblák verziószámozásával és keretek használatával kapcsolatos további információkért lásd: A Direct Lake szemantikai modelljeinek tárolásával kapcsolatos tudnivalókat.
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.
Borravaló
A Power BI-jelentésekben beállíthatja az oldalak automatikus frissítését . 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 modellbe 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.
Egy lekérdezés mindig visszatér, ha az SQL Analytics-végponton a szemantikai modell lekérdez egy nézetet, vagy lekérdez egy táblát, amely sorszintű biztonságot (RLS)alkalmaz.
A lekérdezések akkor is visszaeshetnek, ha a szemantikai modell meghaladja a kapacitáskorlátját.
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 visszalépésé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.
Szövetkapacitás-védőkorlátok és korlátozások
A Direct Lake szemantikai modelljeihez Fabric-kapacitás licencre van szükség. 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 kerül bevezetésre a Power BI Premium licenceléshez és Power BI Premium.
| Szövet cikkszám | Parquet fájlok táblánként | Sorcsoportok táblánként | Sorok táblázatonként (millió) | Maximális modellméret lemezen vagy OneLake-en (GB) | Maximális memória (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 | Korlátlan | 25 |
| F128/P2 | 5,000 | 5,000 | 3,000 | Korlátlan | 50 |
| F256/P3 | 5,000 | 5,000 | 6,000 | 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 Direct Lake szemantikai modellek esetén a Max memória a memória felső határát jelenti, hogy mennyi adatot lehessen be lapozni. 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épik a maximális modellméretet a lemezen vagy a OneLake-en, a szemantikai modell összes lekérdezése visszaesik a 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 elkerülje a szükségtelen felskálázást egy magasabb Fabric SKU-ra (ami nagyobb költséget eredményez).
Emellett kapacitásegység és Lekérdezésenkénti maximális memóriakorlátok vonatkoznak a Direct Lake szemantikai modelljeire. 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.
Jegyzet
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ódú 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, awhat-if paramétereket és 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. Számítási csoportok, és mezőparaméterek, amelyek implicit módon létrehoznak számított táblákat, és a Direct Lake-oszlopokra vagy táblákra nem hivatkozó számított táblák támogatottak.
- 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 meghiúsulnak, ha ismétlődő értékeket észlel egy egyoldalas oszlopban.
- Power BI Desktop automatikus adat-/időintelligencia nem támogatott. Saját dátumtábla dátumtáblaként való megjelölése támogatott.
- A sztringoszlopértékek hossza legfeljebb 32 764 Unicode-karakter lehet.
- A lebegőpontos érték NaN- (nem szám) nem támogatott.
- Power BI- szolgáltatásnév használatával történő webes közzététel csak akkor támogatott, ha rögzített identitást használ a Direct Lake szemantikai modellhez.
- A webes modellezésiesetén 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 Fabric portálon a Direct Lake lap a frissítési előzményekben 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 Fabric SKU határozza meg a kapacitáshoz tartozó Direct Lake szemantikai modellekenkénti maximálisan 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. Alternatív megoldásként hozzunk létre egy Lakehouse-t a másik régió munkaterületén, és készítsünk parancsikont a táblákhoz a szemantikai modell létrehozása előtt. Ha meg szeretné tudni, hogy melyik régióban tartózkodik, tekintse 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 Service Principal hitelesítése engedélyezve van a Fabric REST API-k számára a bérlői környezetben, és adjon a Service Principalnak közreműködői vagy magasabb szintű engedélyeket a Direct Lake szemantikai modell munkaterületéhez.
- A jelentések beágyazásához V2-beágyazási jogkivonatra van szükség.
- A Direct Lake nem támogatja a szolgáltatásnév-profilokat a hitelesítéshez.
- A Szolgáltatási főkomponens és a Szolgáltatási főkomponenssel rendelkező megjelenítő által létrehozott testreszabott Direct Lake szemantikai modellek támogatottak, de az alapértelmezett Direct Lake szemantikai modellek nem támogatottak.
Ö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.
| Képesség | Direct Lake | Importál | DirectQuery |
|---|---|---|---|
| Licencelési | 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 | Nincs 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 számítási csoportokat, , valamint 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 Import tárolási módot használnak, még akkor is, ha DirectQuery módban lévő más táblákra hivatkoznak. |
| Számított oszlopok | Nem | Igen | Igen |
| Hibrid táblák | Nem | Igen | Igen |
| Táblapartíciók modellezése | Nem – azonban particionálás elvégezhető a Delta tábla szintjén | Igen – automatikusan növekményes frissítéssel, vagy manuálisan létrehozott 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ás felhőalapú 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 automatikus frissítések engedélyezve van, vagy programozott átszervezés; azonban adatelőkészítés először a felsőbb rétegben kell elvégezni | Nem | Igen |
| Power BI Embedded | Igen 2 | Igen | Igen |
1 Nem kombinálhatja a Direct Lake tárolási módú táblázatokat 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.
2 V2 beágyazási jogkivonatot igényel. Ha szolgáltatásfiókot használ, akkor rögzített identitással rendelkező felhőkapcsolatot kell használnia.