Megjegyzés
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhat bejelentkezni vagy módosítani a címtárat.
Az oldalhoz való hozzáféréshez engedély szükséges. Megpróbálhatja módosítani a címtárat.
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é.
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.
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 |