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

Direct Lake szemantikai modellek fejlesztése

  • Cikk

Ez a cikk a Direct Lake szemantikai modellek fejlesztéséhez kapcsolódó tervezési témaköröket ismerteti.

A modell létrehozása

A Fabric portál használatával létrehozhat egy Direct Lake szemantikai modellt egy munkaterületen. Ez egy egyszerű folyamat, amely magában foglalja a szemantikai modellhez hozzáadni kívánt táblák kiválasztását egyetlen tóházból vagy raktárból.

Ezután a webes modellezési használatával tovább fejlesztheti a szemantikai modellt. Ez a felület lehetővé teszi a táblák közötti kapcsolatok létrehozását, mértékek és számítási csoportok létrehozását, dátumtáblák megjelölését, valamint a modell és objektumainak (például oszlopformátumok) tulajdonságait. A modell sorszintű biztonságát (RLS) is beállíthatja szerepkörök és szabályok definiálásával, valamint felhasználói fiókokat (Microsoft Entra) vagy biztonsági csoportokat adhat hozzá ezekhez a szerepkörökhöz.

Másik lehetőségként folytathatja a modell fejlesztését egy XMLA-kompatibilis eszközzel, például az SQL Server Management Studio (SSMS) (19.1-es vagy újabb verzió) vagy nyílt forráskódú közösségi eszközökkel. További információért lásd a Modell írási támogatása az XMLA-végponttal című részt a cikk későbbi szakaszában.

Borravaló

Megtanulhatja, hogyan hozzon létre egy Lakehouse-t, egy Delta-táblát és egy alapszintű Direct Lake szemantikai modellt az oktatóanyag végrehajtásával .

Modelltáblák

A modelltáblák egy táblán vagy az SQL Analytics-végpont nézetén alapulnak. Ha csak lehetséges, ne használjon nézeteket. Ennek az az oka, hogy a nézeten alapuló modelltáblák lekérdezései mindig DirectQuery módraesnek vissza, ami lassabb lekérdezési teljesítményt eredményezhet.

A tábláknak a modellkapcsolatokat támogató oszlopok mellett a szűréshez, csoportosításhoz, rendezéshez és összegzéshez szükséges oszlopokat is tartalmazniuk kell. Bár a szükségtelen oszlopok nem befolyásolják a szemantikai modell lekérdezési teljesítményét (mivel nem töltik be őket a memóriába), a OneLake nagyobb tárterület-méretet eredményez, és több számítási erőforrást igényelnek a betöltéshez és a karbantartáshoz.

Figyelmeztetés

A dinamikus adatmaszkolást (DDM) használó oszlopok használata a Direct Lake szemantikai modelljeiben nem támogatott.

A Direct Lake szemantikai modellbe felvenni kívánt táblák kiválasztásáról a A Direct Lake szemantikai modellek tábláinak szerkesztésecímű témakörben olvashat.

A szemantikai modelltáblákba felvenni kívánt oszlopokról további információt a A Direct Lake szemantikai modellek tárolási adataicímű témakörben talál.

Adathozzáférési szabályok kényszerítése

Ha a modelladatok részhalmazainak különböző felhasználóknak való továbbítására vonatkozó követelményekkel rendelkezik, adathozzáférési szabályokat kényszeríthet ki. A szabályokat az objektumszintű biztonság (OLS) és/vagy sorszintű biztonság (RLS) beállításával kényszerítheti ki az SQL Analytics-végponton vagy a szemantikai modellben.

Jegyzet

Az adathozzáférési szabályok témaköre más, mégis kapcsolódik ahhoz, hogy engedélyeket a szemantikai modellt (és a kapcsolódó hálóelemeket) kezelő tartalomfelhasználók, alkotók és felhasználók számára. További információ az engedélyek beállításáról: Direct Lake szemantikai modellek kezelése.

Objektumszintű biztonság (OLS)

Az OLS magában foglalja az objektumok vagy oszlopok felderítéséhez és lekérdezéséhez való hozzáférés korlátozását. Az OLS használatával például korlátozhatja azokat a felhasználókat, akik hozzáférhetnek a Salary oszlophoz a Employee táblából.

AZ SQL Analytics-végpontok esetében beállíthatja az OLS-t, hogy szabályozza a végpontobjektumokhoz való hozzáférést, például táblák vagy nézetek, valamint oszlopszintű biztonság (CLS) a végponttáblák oszlopaihoz való hozzáférés vezérlését.

Szemantikai modell esetén beállíthatja az OLS-t, hogy a modelltáblákhoz vagy -oszlopokhoz való hozzáférést. Az OLS beállításához nyílt forráskódú közösségi eszközöket kell használnia, például a Táblázatszerkesztőt.

Sorszintű biztonság (RLS)

Az RLS magában foglalja a táblák adathalmazaihoz való hozzáférés korlátozását. Használhatja például az RLS-t annak biztosítására, hogy az értékesítők csak az értékesítési régiójukban lévő ügyfelek értékesítési adataihoz férhessenek hozzá.

SQL Analytics-végpontok esetén beállíthatja az RLS-t, hogy szabályozza a végponttáblák soraihoz való hozzáférést.

Fontos

Ha egy lekérdezés olyan táblát használ, amely RLS-t tartalmaz az SQL Analytics-végponton, az visszaesik DirectQuery módba. A lekérdezés teljesítménye lassabb lehet.

Szemantikai modell esetén az RLS-t úgy állíthatja be, hogy szabályozza amodelltáblák soraihoz való hozzáférést. Az RLS a webes modellezési környezetben vagy egy külső eszköz használatával állítható be.

A lekérdezések kiértékelésének menete

A Direct Lake szemantikai modellek kifejlesztésének oka, hogy nagy teljesítményű lekérdezéseket hajtsunk végre nagy mennyiségű adaton a OneLake-ben. Ezért érdemes olyan megoldást tervezni, amely maximalizálja a memóriabeli lekérdezések esélyét.

Az alábbi lépések a lekérdezések kiértékelésének módját (és a sikertelenségeket) közelítik meg. A Direct Lake Storage mód előnyei csak az ötödik lépés elérésekor érhetők el.

  1. Ha a lekérdezés tartalmaz olyan táblát vagy oszlopot, amelyet a szemantikai modell OLS-sel korlátoz, a program hibaüzenetet ad vissza (a jelentésvizualizáció nem fog renderelni).
  2. Ha a lekérdezés tartalmaz olyan oszlopot, amelyet az SQL Analytics CLS-végpontja korlátoz (vagy a tábla megtagadva), a rendszer hibaüzenetet ad vissza (a jelentésvizualizáció nem jelenik meg).
    1. Ha a felhőkapcsolat SSO-t (alapértelmezett) használ, a CLS-t a jelentésfelhasználó hozzáférési szintje határozza meg.
    2. Ha a felhőkapcsolat rögzített identitást használ, a CLS-t a rögzített identitás hozzáférési szintje határozza meg.
  3. Ha a lekérdezés tartalmaz olyan táblát az SQL Analytics-végponton, amely kikényszeríti az RLS-t, vagy egy nézetet használ, a lekérdezés visszaesik DirectQuery módba.
    1. Ha a felhőkapcsolat SSO-t (alapértelmezett) használ, az RLS-t a jelentésfelhasználó hozzáférési szintje határozza meg.
    2. Ha a felhőkapcsolat rögzített identitást használ, az RLS-t a rögzített identitás hozzáférési szintje határozza meg.
  4. Ha a lekérdezés túllépi a kapacitáskorlátját, a DirectQuery módba kerül vissza.
  5. Ellenkező esetben a lekérdezés a memóriában lévő gyorsítótárból lesz kielégítve. Az oszlopadatok akkor kerülnek betöltésre a memóriába, amikor szükséges.

Forráselem-engedélyek

Az adatok eléréséhez használt fiók az alábbiak egyike.

  • Ha a felhőkapcsolat SSO-t használ (alapértelmezett), akkor az a jelentésfelhasználó.
  • Ha a felhőkapcsolat rögzített identitást használ, az a rögzített identitás.

A fióknak legalább Read és ReadData engedélyekkel kell rendelkeznie a forráselemhez (lakehouse vagy warehouse). Az elemengedélyek örökölhetők a munkaterületi szerepköröktől, vagy explicit módon hozzárendelhetők az elemhez a jelen cikk .

Feltételezve, hogy ez a követelmény teljesül, a Fabric biztosítja a szükséges hozzáférést a szemantikai modellhez 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), és adatelérési szabályok alkalmazhatók.

Adatelérési szabály beállításai

Az adathozzáférési szabályokat az alábbiakban állíthatja be:

  • Csak a szemantikai modell.
  • Csak az SQL Analytics-végpont.
  • Mind a szemantikai modellben, mind az SQL Analytics-végpontban.

Szabályok a szemantikai modellben

Ha adathozzáférési szabályokat kell kikényszerítenie, ezt minden esetben a szemantikai modellben kell megtennie. Ennek az az oka, hogy a szemantikai modell által kikényszerített RLS az adatok memóriabeli gyorsítótárának szűrésével érhető el a nagy teljesítményű lekérdezések eléréséhez.

Ez akkor is megfelelő módszer, ha a jelentés felhasználói nem kapnak engedélyt a tóház vagy a raktár lekérdezésére.

Mindkét esetben erősen ajánlott, hogy a felhőkapcsolat az egyszeri bejelentkezés helyett rögzített identitást használjon. Az egyszeri bejelentkezés azt jelentené, hogy a végfelhasználók közvetlenül hozzáférhetnek az SQL Analytics-végponthoz, ezért megkerülhetik a szemantikai modell biztonsági szabályait.

Fontos

A szemantikai modellelem-engedélyeket explicit módon lehet beállítani Power BI-alkalmazások, vagy a munkaterületi szerepkörökön keresztül implicit módon beszerezni.

Nevezetesen a szemantikai modell adathozzáférési szabályai nem lesznek kényszerítve azokra a felhasználókra, akik Írási engedéllyel rendelkeznek a szemantikai modellen. Ezzel szemben az adathozzáférési szabályok azokra a felhasználókra vonatkoznak, akik a Viewer munkaterületi szerepkörhöz vannak hozzárendelve. A Rendszergazdai, Tagvagy Közreműködői-munkaterület szerepkörhöz hozzárendelt felhasználók azonban implicit módon Írási engedéllyel rendelkeznek a szemantikai modellen, így az adathozzáférési szabályok nem lesznek kényszerítve. További információ: Szerepkörök a munkaterületeken.

Szabályok az SQL Analytics-végpontban

Az SQL Analytics-végpont adathozzáférési szabályait célszerű kikényszeríteni, ha a szemantikai modell felhőalapú kapcsolategyszeri bejelentkezést (SSO)használ. Ennek az az oka, hogy a felhasználó identitása delegálva van az SQL Analytics-végpont lekérdezéséhez, biztosítva, hogy a lekérdezések csak azokat az adatokat adja vissza, amelyekhez a felhasználó hozzáférhet. Ezen a szinten adathozzáférési szabályokat is célszerű kikényszeríteni, ha a felhasználók közvetlenül lekérdezik az SQL Analytics-végpontot más számítási feladatokhoz (például többoldalas Power BI-jelentés létrehozásához vagy adatok exportálásához).

A szemantikai modelllekérdezés azonban visszavált DirectQuery módba, ha tartalmaz bármely táblát, amely alkalmazza az RLS-t az SQL Analytics-végponton. Emiatt előfordulhat, hogy a szemantikai modell soha nem gyorsítótárazza az adatokat a memóriába a nagy teljesítményű lekérdezések elérése érdekében.

Szabályok mindkét rétegben

Az adatelérési szabályok mindkét rétegben kikényszeríthetők. Ez a megközelítés azonban további összetettséggel és felügyeleti többletterheléssel jár. Ebben az esetben erősen ajánlott, hogy a felhőkapcsolat az egyszeri bejelentkezés helyett rögzített identitást használjon.

Adatelérési szabály beállításainak összehasonlítása

Az alábbi táblázat az adathozzáférés beállítási beállításait hasonlítja össze.

Adathozzáférési szabályok alkalmazása Megjegyzés
Csak szemantikai modell Akkor használja ezt a lehetőséget, ha a felhasználók nem kapnak elemengedélyeket a tóház vagy a raktár lekérdezéséhez. Állítsa be a felhőkapcsolatot rögzített identitás használatára. A memóriabeli gyorsítótárból nagy lekérdezési teljesítmény érhető el.
Csak SQL Analytics-végpont Ezt a lehetőséget akkor használja, ha a felhasználóknak a raktárból vagy a szemantikai modellből, valamint konzisztens adatelérési szabályokkal kell hozzáférnie az adatokhoz. Győződjön meg arról, hogy az egyszeri bejelentkezés engedélyezve van a felhőkapcsolathoz. A lekérdezési teljesítmény lassú lehet.
Lakehouse vagy warehouse és szemantikai modell Ez a lehetőség további felügyeleti többletterhelést is magában foglal. Állítsa be a felhőkapcsolatot rögzített identitás használatára.

Az alábbi ajánlott eljárások az adathozzáférési szabályok kikényszerítésével kapcsolatosak:

  • Ha a különböző felhasználókat csak az adatok részhalmazaira kell korlátozni, akkor az RLS-t csak a szemantikai modellrétegen kényszerítse ki. Így a felhasználók a nagy teljesítményű memóriabeli lekérdezések előnyeit élvezhetik. Ebben az esetben erősen ajánlott, hogy a felhőkapcsolat az egyszeri bejelentkezés helyett rögzített identitást használjon.
  • Ha lehetséges, ne kényszerítse ki az OLS-t és a CLS-t mindkét rétegben, mert az hibákat eredményez a jelentésvizualizációkban. A hibák zavarhoz vagy aggodalomhoz vezethetnek a felhasználók számára. Összegezhető oszlopok esetén érdemes lehet olyan mértékeket létrehozni, amelyek a CLS helyett bizonyos feltételek között ÜRES értéket adnak vissza (ha lehetséges).

Modellírás támogatása az XMLA-végponttal

A Direct Lake szemantikai modelljei támogatják az XMLA-végponttal végzett írási műveleteket olyan eszközökkel, mint az SSMS (19.1 vagy újabb) és a nyílt forráskódú közösségi eszközök.

Borravaló

A szemantikai modellek fejlesztéséhez, kezeléséhez vagy optimalizálásához külső eszközök használatával kapcsolatos további információkért tekintse meg a fejlett adatmodell-kezelési használati forgatókönyvet.

Az írási műveletek végrehajtása előtt engedélyezni kell az XMLA olvasás-írás lehetőséget a kapacitáshoz. További információért lásd: XMLA írás-olvasás engedélyezése.

Modellírási műveletek az XMLA-végpont támogatásával:

  • A Direct Lake-modell metaadatainak testreszabása, egyesítése, szkriptelése, hibakeresése és tesztelése.
  • Forrás- és verziókövetés, folyamatos integráció és folyamatos üzembe helyezés (CI/CD) az Azure DevOps és a GitHub használatával. További információ: Tartalom életciklus-kezelési.
  • Automatizálási feladatok, például szemantikai modellek frissítése és módosítások alkalmazása a Direct Lake szemantikai modelljeire a PowerShell és a REST API-k használatával.

Ha XMLA használatával módosít egy szemantikai modellt, frissítenie kell a ChangedProperties és PBI_RemovedChildren gyűjteményt, hogy a módosított objektum tartalmazza a módosított vagy eltávolított tulajdonságokat. Ha nem hajtja végre ezt a frissítést, a Power BI modellezési eszközei felülírhatják a módosításokat, amikor a séma legközelebb szinkronizálódik a Lakehouse-ral.

További információért a szemantikai modell objektumainak leszármazási címkéiről olvassa el a Power BI szemantikai modellek leszármazási címkékről szóló cikket.

Fontos

Az XMLA-alkalmazásokkal létrehozott Direct Lake-táblák kezdetben feldolgozatlan állapotban lesznek, amíg az alkalmazás nem küld frissítési parancsot. A feldolgozatlan táblákat tartalmazó lekérdezések mindig DirectQuery módba kerülnek. Ezért amikor új szemantikai modellt hoz létre, mindenképpen frissítse a modellt a táblák feldolgozásához.

További információ: Szemantikai modell kapcsolata az XMLA-végponttal.

Direct Lake-modell metaadatai

Amikor egy Direct Lake szemantikai modellhez csatlakozik az XMLA-végponttal, a metaadatok bármely más modell metaadataihoz hasonlóan néznek ki. A Direct Lake-modellek azonban a következő különbségeket mutatják:

  • Az adatbázis-objektum compatibilityLevel tulajdonsága 1604 (vagy magasabb).
  • A Direct Lake-partíciók módtulajdonsága directLake.
  • A Direct Lake-partíciók megosztott kifejezéseket használnak az adatforrások definiálásához. A kifejezés a lakehouse vagy a raktár SQL Analytics-végpontjára mutat. A Direct Lake az SQL Analytics-végpontot használja a séma- és biztonsági információk felderítésére, de közvetlenül a OneLake-ből tölti be az adatokat (kivéve, ha bármilyen okból visszaesik DirectQuery módba).

Közzététel utáni feladatok

A Direct Lake szemantikai modell közzététele után el kell végeznie néhány beállítási feladatot. További információ: Direct Lake szemantikai modellek kezelése.

Nem támogatott funkciók

A Direct Lake szemantikai modelljei nem támogatják a következő modellszolgáltatásokat:

  • Számított táblák, amelyek táblákra vagy oszlopokra hivatkoznak Direct Lake tárolási módban
  • Számított oszlopok, melyek táblákra vagy oszlopokra hivatkoznak „Direct Lake” tárolási módban
  • Hibrid táblák
  • Felhasználó által definiált összesítések
  • Összetett modellek esetén a Direct Lake tárolási módú táblák nem kombinálhatók a DirectQuery vagy Kettős tárolási módú táblákkal ugyanabban a modellben. A Power BI Desktop használatával azonban élő kapcsolatot hozhat létre egy Direct Lake szemantikai modellel, majd új mértékekkel bővítheti azt, és innen kattintva módosíthatja ezt a modellt, új táblák hozzáadásához (Importálás, DirectQuery vagy Kettős tárolási mód használata). Ez a művelet DirectQuery-kapcsolatot hoz létre a szemantikai modellhez Direct Lake módban, így a táblák DirectQuery tárolási módként jelennek meg, de ez a tárolási mód nem jelzi a DirectQueryre való visszatérést. Csak az új modell és a Direct Lake-modell közötti kapcsolat DirectQuery, és a lekérdezések továbbra is a Direct Lake-t használják az adatok OneLake-ből való lekéréséhez. További információ: Összetett modell létrehozása szemantikai modellre.
  • Dinamikus adatmaszkolást alkalmazó SQL Analytics-végpontoszlopokon alapuló oszlopok.

Kapcsolódó tartalom