Megosztás a következőn keresztül:


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.

diagram egy Direct Lake szemantikai modellt mutat be, és azt, hogy hogyan kapcsolódik a OneLake Delta-tábláihoz az előző bekezdésekben leírtak szerint.

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.

Diagram a Direct Lake szemantikai modelljeinek működését mutatja be. A képen látható fogalmakat az alábbi táblázat ismerteti.

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.

Diagram 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.