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 a OneLake-ben tárolt Delta-táblákból – 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ű interaktív elemzést tesz lehetővé.

Az ábrán egy Direct Lake szemantikai modell látható, és az előző bekezdésekben leírt módon kapcsolódik a Delta-táblákhoz a OneLake-ben.

A Direct Lake ideális olyan szemantikai modellekhez, amikor nagy Fabric-tóházakhoz, raktárakhoz és más forrásokhoz csatlakoznak Delta-táblákkal, különösen akkor, ha a teljes adatkötet replikálása importálási modellbe kihívást jelent vagy lehetetlen. A Direct Lake-lekérdezéseket a VertiPaq lekérdezési motor dolgozza fel az Importálás módhoz hasonlóan, míg a DirectQuery a lekérdezéseket az alapul szolgáló adatforráshoz irányítja. Ez azt jelenti, hogy a Direct Lake-lekérdezések, például az Importálás mód, általában felülmúlják a DirectQueryt.

A Direct Lake azonban lényegesen eltér az importálási módtól: a Direct Lake szemantikai modell frissítési művelete elméletileg eltér az Importálás szemantikai modellek frissítési műveletétől. Az importálási mód replikálja az adatokat, és létrehoz egy teljes gyorsítótárazott másolatot az adatokról a szemantikai modellhez, míg a Direct Lake-frissítés csak metaadatokat másol (a cikk későbbi részében ismertetett keretezést), ami eltarthat néhány másodpercig. A Direct Lake-frissítés egy alacsony költségű művelet, amely elemzi a Delta-táblák legújabb verziójának metaadatait, és a OneLake legújabb fájljaira hivatkozva frissül. Ezzel szemben az importálási frissítés egy 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 CPU-t) használhat fel. A Direct Lake áthelyezi az adatok előkészítését a OneLake-be, és ennek során a Fabric-technológiák teljes körű használatát használja az adat-előkészítéshez, beleértve a Spark-feladatokat, a T-SQL DML-utasításokat, az adatfolyamokat, a folyamatokat stb.

A Direct Lake Storage mód a következő fő előnyöket kínálja:

  • Az importálási módhoz hasonlóan a Direct Lake-lekérdezéseket a VertiPaq motor dolgozza fel, így az importálási módhoz hasonló lekérdezési teljesítményt nyújt anélkül, hogy az adatfrissítési ciklusok felügyeleti többletterhelése terhelné a teljes adatmennyiséget.
  • A meglévő Fabric-befektetéseket úgy használja, hogy zökkenőmentesen integrálható nagy tóházakkal, raktárakkal és más Fabric-forrásokkal Delta-táblákkal. A Direct Lake például ideális választás a medallion lakehouse architektúra gold elemzési rétegéhez.
  • Maximalizálja a megtérülést (ROI), mivel az elemzett adatmennyiségek túlléphetik a kapacitás maximális memóriakorlátját, mivel csak a lekérdezés megválaszolásához szükséges adatok töltődnek be a memóriába.
  • Minimalizálja az adatkéséseket azáltal, hogy gyorsan és automatikusan szinkronizál egy szemantikai modellt a forrásaival, így az új adatok frissítési ütemezés nélkül érhetők el az üzleti felhasználók számára.

Mikor érdemes Direct Lake-tárolási módot használnia?

A Direct Lake storage mód elsődleges használati esete általában a tóközpontú architektúrákat használó informatikai elemzési projektekhez használható. Ilyen esetekben nagy mennyiségű adat halmozódik fel vagy várható 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.

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, így a Fabric számos előnye elérhető a szemantikai modell felhasználói számára, például a lakehouse-okkal való integráció billentyűparancsokkal, SQL-lekérdezésekkel, jegyzetfüzetekkel stb. Ezt a lehetőséget javasoljuk, hogy gyorsan kihasználhassa a Fabric előnyeit anélkül, hogy szükség esetén vagy azonnal újraterveznénk a meglévő adattárházat és/vagy elemzési rendszert.

A Direct Lake a data lake-ben végzett adatelőkészítéstől függ. Az adat-előkészítés különböző eszközökkel végezhető el, például olyan Spark-feladatokkal, amelyek a Fabric lakehouse-okhoz készültek, valamint T-SQL DML utasításokkal a Fabric raktárakhoz. Továbbá adatfolyamok és folyamatok is használhatók, amelyek segítenek biztosítani az adat-előkészítési logika végrehajtását az architektúrában az újrahaszná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ó tóházban, akkor a modell importálási tárolási módú táblákkal való kibővítése jó választás lehet, mivel az Importálás mód támogatja az adatok előkészítését a Power Query használatával. a szemantikai modell részeként definiált.

A Direct Lake storage mód használatakor mindenképpen vegye figyelembe az aktuális Fabric-kapacitáslicencet és a Fabric-kapacitáskorlátokat . Emellett vegye figyelembe a cikk későbbi részében ismertetett szempontokat és korlátozásokat is.

Borravaló

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.

Főbb fogalmak és terminológia

Ez a cikk a következő fogalmak ismeretét feltételezi:

  • A felhasználók a Power BI-jelentések vizualizációival kommunikálnak, amelyek DAX-lekérdezéseket hoznak létre a szemantikai modellben.
  • Tárolási mód: A szemantikai modell az alkalmazott tárolási módtól függően eltérő módon dolgozza fel a DAX-lekérdezéseket. Például:
    • Az importálási és Direct Lake-tárolási módok a VertiPaq motorral dolgozzák fel a DAX-lekérdezéseket, és visszaadják az eredményeket a Power BI-jelentésnek és a felhasználónak.
    • A DirectQuery viszont lefordítja a DAX-lekérdezéseket az adatforrás lekérdezési szintaxisára (általában az SQL egy formájára), és összevonja őket az alapul szolgáló adatbázissal. A forrásadatbázis-lekérdezésfeldolgozók gyakran nem BI-stílusú, összesített lekérdezésekhez vannak állítva, ezért lassabb teljesítményt és kevesebb felhasználói interaktivitást eredményeznek az Importálás és a Direct Lake módhoz képest.

A tárolási mód egy tábla tulajdonsága a szemantikai modellben. Ha egy szemantikai modell különböző tárolási módokkal rendelkező táblákat tartalmaz, összetett modellnek nevezzük. A tárolási módokkal kapcsolatos további információkért tekintse meg a Szemantikai modell módokat a Power BI szolgáltatásban.

  • A Direct Lake mód két különböző hozzáférési módszert használhat:

    • A OneLake-en futó Direct Lake nem függ az SQL-végpontoktól, és bármely Fabric-adatforrásból származó adatokat használhat Delta-táblákkal. A OneLake-en futó Direct Lake nem áll vissza DirectQuery módba.

    Jegyzet

    A OneLake-en futó Direct Lake jelenleg nyilvános előzetes verzióban érhető el.

    • Az SQL-végpontokon futó Direct Lake egy Fabric lakehouse vagy -raktár SQL-végpontját használja a Delta-tábla felderítéséhez és engedélyellenőrzéséhez. Az SQL-végpontokon futó Direct Lake visszaeshet DirectQuery módba, ha nem tudja közvetlenül betölteni az adatokat egy Delta-táblából, például ha az adatforrás SQL-nézet, vagy amikor a Warehouse SQL-alapú sorszintű biztonságot (RLS) használ. Az SQL-végpontokon futó Direct Lake általánosan elérhető és teljes mértékben támogatott az éles környezetben.

Tárolási módok összehasonlítása

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 a OneLake-en Direct Lake SQL-végpontokon Importál DirectQuery
Licencelési Csak hálókapacitás-előfizetés (termékváltozatok) 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 A Delta-táblák által támogatott Fabric-adatforrások táblázatai 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 Nem Igen – de automatikusan visszaesik DirectQuery módba Igen Igen
Összetett modellek 1. szám 1. szám 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 Igen Nem alkalmazható Igen
Számított táblák Igen – de a számítások nem hivatkozhatnak a Táblák oszlopaira Direct Lake módban. 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 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 Igen – de a számítások nem hivatkozhatnak a Táblák oszlopaira Direct Lake módban. Nem Igen Igen
Hibrid táblák Nem Nem Igen Igen
Táblapartíciók modellezése Nem – a particionálás azonban elvégezhető a Delta tábla szintjén Nem – a particionálás azonban elvégezhető a Delta tábla szintjén Igen – akár automatikusan az inkrementális frissítéssel, akár manuálisan az XMLA-végpont használatával Nem
Felhasználó által definiált összesítések Nem Nem Igen – A DirectQuery-táblák összesítő tábláinak importálása támogatott Igen
SQL Analytics-végpont objektumszintű biztonsága vagy oszlopszintű biztonsága Nem Igen – de hibákat eredményezhet, 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) Nem 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 – de erősen ajánlott rögzített identitásfelhő-kapcsolat használata Igen Igen
Szemantikai modell objektumszintű biztonsága (OLS) Igen Igen Igen Igen
Nagy adatmennyiségek frissítési követelmény nélkül Igen Igen Nem Igen
Adatkésés csökkentése Igen – ha az automatikus frissítések engedélyezve vannak, vagy programozott reframing Igen – ha az automatikus frissítések engedélyezve vannak, vagy programozott reframing Nem Igen
Power BI Embedded Igen 2 Igen 2 Igen Igen

1 Ha a Direct Lake-t SQL-végpontokon használja, nem kombinálhatja a Direct Lake tárolási módú táblázatait 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ásiszerepkört használ, rögzített identitású felhőkapcsolatot kell alkalmaznia.

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 alapjául szolgáló tároló 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 OneLake-en futó Direct Lake nincs összekapcsolva az SQL-végponttal, és szorosabb integrációt biztosít a OneLake-funkciókkal, például a OneLake-biztonsággal és a hatékonyabb DAX-lekérdezési tervekkel, mert például nem szükséges sql-alapú biztonság ellenőrzése. A DirectQuery tartalékot a OneLake-en futó Direct Lake nem támogatja.

Az SQL-végpontokon futó Direct Lake esetén a DAX-lekérdezések DirectQuery-tartalékot használhatnak, 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. A tartalékolás például akkor fordul elő, ha az SQL-alapú biztonságot az SQL-végponton észleli a rendszer. 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.

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 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 a memóriában vannak. 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ítése a forrásnál történt Delta-táblafrissítés után történt (lásd a következő szakaszban található Keretezést ).
  • 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 bővebben a cikk későbbi részében található Fabric kapacitás védőkorlátok és korlátozások című szakaszban olvashat.

Keretezés

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

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 az átkó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.

Az á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 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 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.

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

Ha a Direct Lake-t SQL-végpontokon használja, a Direct Lake szemantikai modellbe küldött lekérdezés visszaeshet DirectQuery módba , ebben az esetben a tábla már nem működik Direct Lake módban. Közvetlenül a lakehouse vagy a raktár SQL Analytics-végpontjáról kéri le az 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.

Amikor DirectQuery visszaesés bekövetkezik, a lekérdezés már nem használja a Direct Lake módot. A lekérdezések nem használhatják a Direct Lake módot, 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. Emellett a lekérdezések nem használhatják a Direct Lake módot, ha egy Delta-tábla túllépi a kapacitás 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. Ez a beállítás csak az SQL-végpontokon futó Direct Lake-ra vonatkozik. A OneLake-en futó Direct Lake nem támogatja a DirectQuery-tartalékot. További információ: A Direct Lake viselkedési tulajdonságának beállítása.

Adatbiztonsági és hozzáférési engedélyek

A Direct Lake alapértelmezés szerint egyszeri bejelentkezést (SSO) használ, ami azt jelenti, hogy a szemantikai modellt lekérdező identitásnak (gyakran jelentésfelhasználónak) engedélyeznie kell az adatok elérését. Azt is megteheti, hogy a Direct Lake-modellt egy megosztható felhőkapcsolathoz (SCC) köti, hogy rögzített identitást biztosítson, és letiltsa az egyszeri bejelentkezést. Ebben az esetben csak a rögzített identitás igényel olvasási hozzáférést a forrásban lévő adatokhoz.

Szövetcikk-engedélyek

A Direct Lake szemantikai modelljei egy rétegzett biztonsági modellhez igazodnak. Engedélyellenőrzéseket végeznek annak megállapításához, hogy az adatokhoz hozzáférni próbáló identitás rendelkezik-e a szükséges adathozzáférési engedélyekkel a forrásadatelemben és a szemantikai modellben. Az engedélyek hozzárendelhetők közvetlenül vagy implicit módon, a Microsoft Fabric munkaterületi szerepköreinek használatával.

Fontos tudni, hogy a OneLake-en futó Direct Lake és az SQL-végpontokon futó Direct Lake eltérő engedélyellenőrzéseket végez.

  • A OneLake-en található Direct Lake olvasási és ReadAll-engedélyekkel rendelkezik a tóházban/raktárban a Delta-táblák eléréséhez.
  • Az SQL-végpontokon futó Direct Lake olvasási és ReadData-engedélyeket igényel a lakehouse/warehouse-on az SQL Analytics-végpont adatainak eléréséhez.

Jegyzet

A OneLake-en futó Direct Lake használatához a felhasználóknak engedélyt kell adni a Delta-táblák oneLake-ben való olvasására, és nem feltétlenül az SQL-végpontra. Ez olyan központosított biztonsági kialakítást kényszerít ki, amelyben a OneLake a hozzáférés-vezérlés egyetlen forrása.

Az SQL-végpontokon futó Direct Lake esetében viszont a felhasználók olvasási hozzáféréssel rendelkeznek az SQL-végponthoz, és nem feltétlenül a OneLake Delta-tábláihoz. Ennek az az oka, hogy a Fabric megadja a szükséges engedélyeket a szemantikai modellnek a Delta-táblák és a kapcsolódó Parquet-fájlok olvasásához ( az oszlopadatok memóriába való betöltéséhez ). A szemantikai modell rendelkezik a szükséges engedélyekkel az SQL Analytics-végpont rendszeres olvasásához, hogy engedély-ellenőrzéseket hajtson végre annak megállapításához, hogy a lekérdezést végző felhasználó (vagy a rögzített identitás) milyen adatokhoz férhet hozzá.

Szemantikai modell engedélyei

A Fabric-elemek engedélyei mellett engedélyeket is meg kell adnia a felhasználóknak, hogy használhassák vagy felügyelhessék a Direct Lake szemantikai modelljét. Röviden: a jelentésfelhasználóknak olvasási engedélyre van szükségük, a jelentéskészítőknek pedig további összeállítási engedélyre van szükségük. A szemantikai modell engedélyei hozzárendelhetők közvetlenül vagy implicit módon a munkaterületi szerepkörök használatával. A szemantikai modell beállításainak kezeléséhez (a frissítéshez és más konfigurációkhoz) szemantikai modell tulajdonosának kell lennie.

Engedélykövetelmények

Vegye figyelembe a következő forgatókönyveket és engedélykövetelményeket.

Forgatókönyv Szükséges engedélyek Megjegyzések
A felhasználók megtekinthetik a jelentéseket Olvasási engedélyt adjon a jelentésekhez és Olvasási engedélyt a szemantikai modellhez.

Ha a szemantikai modell Direct Lake-t használ AZ SQL-végpontokon, és a felhőkapcsolat egyszeri bejelentkezést használ, adjon meg legalább Olvasási és ReadData-engedélyeket a lakehouse-hoz vagy a raktárhoz.

Ha a szemantikai modell Direct Lake-t használ a OneLake-en, és a felhőkapcsolat egyszeri bejelentkezést használ, adjon legalább Olvasási és ReadAll-engedélyt a Delta-táblákhoz a OneLake-ben.		 A jelentéseknek nem kell ugyanahhoz a munkaterülethez tartoznia, mint a szemantikai modellnek. További információkért lásd: Stratégia csak olvasásra jogosult felhasználók számára.
A felhasználók jelentéseket hozhatnak létre Megadni a Build jogosultságot a szemantikai modellhez.

Ha a szemantikai modell a Direct Lake-t használja az SQL-végpontokon, és a felhőkapcsolat egyszeri bejelentkezést használ, adjon meg legalább Olvasási és ReadData jogosultságokat a lakehouse-ra vagy a raktárra.

Ha a szemantikai modell Direct Lake-t használ a OneLake-en, és a felhőkapcsolat egyszeri bejelentkezést használ, adjon legalább Olvasási és ReadAll-engedélyt a Delta-táblákhoz a OneLake-ben.		 További információ: Tartalomkészítők stratégiája.
A felhasználók megtekinthetik a jelentéseket, de nem kérdezik le a Lakehouse- és SQL Analytics-végpontot vagy Delta-táblákat a OneLake-ben Olvasási engedélyt adjon a jelentésekhez és Olvasási engedélyt a szemantikai modellhez.

Ne engedélyezzen semmilyen hozzáférést a felhasználóknak a lakehouse, a raktár vagy a Delta-táblák esetében.		 Csak akkor alkalmas, ha a Direct Lake-modell rögzített identitást használ egy letiltott egyszeri bejelentkezéssel rendelkező felhőkapcsolaton keresztül.
A szemantikai modell kezelése, beleértve a frissítési beállításokat is Szemantikai modell tulajdonjogát igényli. További információ: Szemantikai modell tulajdonjoga.

Fontos

Mindig alaposan tesztelje az engedélyeket, mielőtt a szemantikai modellt és a jelentéseket éles környezetben kiadná.

További információ: Szemantikai modell engedélyei.

Szövetkapacitásra vonatkozó követelmények

A Direct Lake szemantikai modellekhez 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. A Microsoft összevonja 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.

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 3000 Korlátlan 50
F256/P3 5,000 5,000 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 a lemez/OneLake maximális modellmérete túllépi a megengedett értéket, akkor a szemantikai modell összes lekérdezése DirectQuery módra áll át. 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 aDirect Lake szemantikai modellt , hogy elkerülje a szükségtelen skálázást egy magasabb Fabric SKU-ra.

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.

Jegyzet

A Direct Lake szemantikai modelljeinek képességei és funkciói gyorsan fejlődnek. A megfontolandó szempontok és korlátozások legújabb listájának áttekintéséhez mindenképpen rendszeresen térjen vissza.

Megfontolandó szempontok /korlátozások Direct Lake a OneLake-en Direct Lake az SQL-en (elemzési végpont)
Amikor az SQL Analytics-végpont sorszintű biztonságot kényszerít, a DAX-lekérdezések feldolgozása az alkalmazott Direct Lake-mód típusától függően eltérő módon történik.

A OneLake-en futó Direct Lake használata esetén a lekérdezések sikeresek lesznek, és az SQL-alapú RLS nem lesz alkalmazva. A OneLake-en futó Direct Lake használatához a felhasználónak hozzá kell férnie a OneLake fájljaihoz, ami nem figyeli meg az SQL-alapú RLS-t.		 A lekérdezések sikeresek lesznek. Igen, kivéve, ha a tartalék funkció le van tiltva, ebben az esetben a lekérdezések sikertelenek lesznek.
Ha a szemantikai modell egyik táblája (nem materializált) SQL-nézeten alapul, a DAX-lekérdezések feldolgozása az alkalmazott Direct Lake-mód típusától függően eltérő módon történik.

Ebben az esetben a Direct Lake az SQL-végpontokon a DirectQueryre fog visszaállni.

Nem támogatott Direct Lake létrehozása a OneLake táblán egy nem materializált SQL-nézet alapján. Ehelyett használhat egy tóházi materializált nézetet, mert a Delta-táblák létre lettek hozva. Másik lehetőségként másik tárolási módot is használhat, például importálást vagy DirectLake-t a nem materializált SQL-nézeteken alapuló táblákhoz.		 Nem alkalmazható Igen, kivéve, ha a tartalék funkció le van tiltva, ebben az esetben a lekérdezések sikertelenek lesznek.
Az összetett modellezés jelenleg nem támogatott, ami 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, a lehetőségelemzési paramétereket és a mezőparamétereket). Nem támogatott Nem támogatott
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. Nem támogatott Nem támogatott
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. Nem támogatott Nem támogatott
A táblakapcsolatoknak meg kell felelnie a kapcsolódó oszlopok adattípusainak. Igen Igen
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. Igen Igen
Automatikus dátum-/időintelligencia a Power BI Desktopban a dátum/idő oszlop dátumrészét használó kapcsolatok létrehozásához. Megjegyzés: A saját dátumtábla dátumtáblázatként való megjelölése és a dátumoszlopok használatával történő kapcsolatok létrehozása támogatott. Támogatott Nem támogatott
A sztringoszlopértékek hossza legfeljebb 32 764 Unicode-karakter lehet. Igen Igen
A nem numerikus lebegőpontos értékek, például a NaN (nem szám) nem támogatottak. Igen Igen
A Power BI szolgáltatásnévvel történő webes közzététele csak akkor támogatott, ha rögzített identitást használ a Direct Lake szemantikai modellhez. Igen Igen
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. Igen Igen
A Fabric portálon a Direct Lake lap a frissítési előzmények között felsorolja a Direct Lake-hez kapcsolódó frissítési hibákat. A sikeres frissítési (keretezési) műveletek általában csak akkor jelennek meg a listában, ha a frissítés állapota megváltozik, például nincs korábbi futtatás vagy frissítési hiba esetén sikeres frissítéssé vagy figyelmeztetéssel járó sikeres frissítéssé alakul. Igen Igen
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. Igen Igen
A 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ó, nem támogatott. 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, keresse meg a Fabric otthoni régióját. Igen Igen
A jelentések beágyazásához V2-beágyazási jogkivonat szükséges. Igen Nem támogatott
Szolgáltatási főprofilok hitelesítéshez. Nem támogatott Nem támogatott
A Power BI Direct Lake szemantikai modelleket a Szolgáltatási Főkulcsok és a Megtekintő szerepkör tagsága is létrehozhatja és lekérdezheti, de a Lakehouse és Warehouse alapértelmezett Direct Lake szemantikai modelljei nem támogatják ezt a forgatókönyvet. Igen Igen
A lakehouse-ban található billentyűparancsok adatforrásként használhatók szemantikai modelltáblákhoz. Nem támogatott a nyilvános előzetes verzió Támogatott
Direct Lake-modellek létrehozása személyes munkaterületeken (Saját munkaterület). Nem támogatott Nem támogatott
Az üzembehelyezési folyamat szabályai az adatforrás újrakötéséhez. Nem támogatott Támogatott

Kapcsolódó tartalom