Jaa

Direct Lake -semanttisten mallien hallinta

  • Artikkeli

Tässä artikkelissa kuvataan Direct Lake -semanttisten mallien hallintaan liittyviä suunnitteluaiheita.

Julkaisun jälkeiset tehtävät

Kun olet ensin julkaissut semanttisen Direct Lake -mallin, joka on valmis raportointia varten, suorita heti joitakin julkaisun jälkeisiä tehtäviä. Näitä tehtäviä voidaan myös säätää milloin tahansa semanttisen mallin elinkaaren aikana.

Vaihtoehtoisesti voit myös määrittää tietojen etsimisen , jotta raportin tekijät voivat lukea metatietoja, jolloin he voivat löytää tietoja OneLake-tietokeskuksesta ja pyytää käyttöoikeutta niihin. Voit myös tukea (sertifioitua tai ylennettyä) semanttista mallia ilmoittaaksesi, että se edustaa käyttöön sopivia laadukkaita tietoja.

Pilviyhteyden määrittäminen

Semanttinen Direct Lake -malli käyttää pilviyhteyttä muodostaakseen yhteyden SQL-analytiikan päätepisteeseen. Sen avulla voidaan käyttää lähdetietoja, jotka ovat joko Parquet-tiedostoja OneLakessa (Direct Lake -tallennustila, johon liittyy saraketietojen lataaminen muistiin) tai SQL-analytiikan päätepistettä (kun kyselyt palataan DirectQuery-tilaan).

Pilvipalvelun oletusyhteys

Kun luot semanttisen Direct Lake -mallin, käytetään oletusarvoista pilviyhteyttä. Se hyödyntää kertakirjautumista (SSO), mikä tarkoittaa sitä, että semanttista mallia (usein raportin käyttäjä) kyselevät SQL-analytiikan päätepistetiedot.

Jaettava pilviyhteys

Vaihtoehtoisesti voit luoda jaettavan pilviyhteyden (SCC), jotta yhteydet tietolähteeseen voidaan muodostaa kiinteillä käyttäjätiedoilla. Se voi auttaa yritysasiakkaita suojaamaan organisaation tietosäilöjä. IT-osasto voi hallita tunnistetietoja, luoda sccs-paketteja ja jakaa ne aiotuille luojille keskitettyä käyttöoikeuksien hallintaa varten.

Jos haluat määrittää kiinteät käyttäjätiedot, katso Direct Lake -semanttisen mallin kiinteän käyttäjätiedon määrittäminen.

Todentaminen

Kiinteät käyttäjätiedot voidaan todentaa joko OAuth 2.0:n tai palvelun päänimen avulla.

Muistiinpano

Vain Microsoft Entra -todennusta tuetaan. Tämän vuoksi perustodentamista ei tueta semanttisissa Direct Lake -malleissa.

OAuth 2.0

Kun käytät OAuth 2.0:aa, voit todentautua Microsoft Entra -käyttäjätilillä. Käyttäjätilillä on oltava oikeus suorittaa kyselyjä SQL-analytiikan päätepisteiden taulukoista ja näkymistä sekä rakenteen metatiedoista.

Tietyn käyttäjätilin käyttäminen ei ole suositeltu käytäntö. Tämä johtuu siitä, että semanttiset mallikyselyt epäonnistuvat, jos salasana muuttuu tai käyttäjätili poistetaan (kuten silloin, kun työntekijä poistuu organisaatiosta).

Palvelun päänimi

Todentaminen palvelun päänimen avulla on suositeltu käytäntö, koska se ei ole riippuvainen tietystä käyttäjätilistä. Suojausobjektilla on oltava oikeus tehdä kyselyjä SQL-analytiikan päätepisteiden taulukoista ja näkymistä sekä rakenteen metatiedoista.

Jatkuvuuden vuoksi palvelun päänimen tunnistetietoja voidaan hallita salaisen koodin/varmenteen kiertolla.

Muistiinpano

Fabric-vuokraajan asetusten on sallittava palvelun päänimet ja palvelun päänimen on kuuluttava määritettyihin käyttöoikeusryhmään.

Kertakirjautuminen

Kun luot jaettavan pilviyhteyden, kertakirjautumisen valintaruutua ei ole oletusarvoisesti valittu. Se on oikea määritys, kun käytät kiinteitä käyttäjätietoja.

Voit ottaa kertakirjautumisen käyttöön, kun haluat, että semanttiseen malliin kyselyjä suorittava käyttäjätieto tekee kyselyn myös SQL-analytiikan päätepisteeseen. Tässä kokoonpanossa semanttinen Direct Lake -malli käyttää kiinteitä käyttäjätietoja mallin ja käyttäjätietojen päivittämiseen tietojen kyselemiseksi.

Käytettäessä kiinteitä käyttäjätietoja on yleinen käytäntö poistaa kertakirjautuminen käytöstä niin, että kiinteitä käyttäjätietoja käytetään sekä päivityksissä että kyselyissä, mutta teknisiä vaatimuksia ei ole.

Seuraavassa on suositeltuja käytäntöjä, jotka liittyvät pilviyhteyksiin:

  • Kun kaikki käyttäjät voivat käyttää tietoja (ja heillä on siihen käyttöoikeus), ei ole tarvetta luoda jaettua pilviyhteyttä. Pilviyhteyden oletusasetuksia voi sen sijaan käyttää. Tässä tapauksessa malliin kyselyn suorittavan käyttäjän käyttäjätiedot palautetaan DirectQuery-tilaan.
  • Luo jaettu pilviyhteys, kun haluat käyttää kiinteitä käyttäjätietoja lähdetietojen kyselemiseen. Tämä voi johtua siitä, että semanttista mallia kyselyille käyttäjille ei myönnetä oikeutta lukea Lakehousea tai varastoa. Tämä lähestymistapa on erityisen tärkeä, kun semanttinen malli toteuttaa rivitason suojauksen.
  • Jos käytät kiinteitä käyttäjätietoja, käytä Palvelun päänimi -vaihtoehtoa, koska se on turvallisempi ja luotettavampi. Tämä johtuu siitä, että tili ei perustu yhteen käyttäjätiliin tai hänen käyttöoikeuksiinsa eikä se edellytä ylläpitoa (ja häiriöitä), jos he vaihtavat salasanansa tai lähtevät organisaatiosta.
  • Jos eri käyttäjien on oltava rajoitettu käyttämään vain tietojen alijoukkoja, jos se on kannattavaa, ota rivitason suojaus käyttöön vain semanttisessa mallikerroksessa. Näin käyttäjät hyötyvät suorituskykyisistä muistissa olevista kyselyistä.
  • Jos mahdollista, vältä OLS- ja CLS-paketteja, koska se aiheuttaa virheitä raportin visualisoinneissa. Virheet voivat aiheuttaa sekaannusta tai huolta käyttäjille. Luotaessa yhteenvedettäviä sarakkeita kannattaa luoda mittareita, jotka palauttavat tietyissä olosuhteissa TYHJÄ-arvon CLS-mittarin (jos mahdollista) sijaan.

Käyttöoikeusroolin jäsenyyden hallinta

Jos semanttinen Direct Lake -mallisi ottaa käyttöön rivitason suojauksen (RLS), sinun on ehkä hallittava jäseniä, jotka on määritetty käyttöoikeusrooleihin. Lisätietoja on artikkelissa Mallin suojauksen hallinta.

Fabric-kohteen käyttöoikeuksien määrittäminen

Semanttiset Direct Lake -mallit noudattavat monikerroksista suojausmallia. He suorittavat käyttöoikeustarkistuksia SQL-analytiikan päätepisteen kautta määrittääkseen, onko tietoja yritetään käyttää käyttäjätiedoilla tarvittavat käyttöoikeudet.

Käyttäjille on myönnettävä käyttöoikeudet, jotta he voivat käyttää tai hallita Semanttista Direct Lake -mallia. Lyhyesti sanottuna raporttien kuluttajat tarvitsevat lukuoikeuden ja raportin luojat muodostamisoikeuksia . Semanttisen mallin käyttöoikeudet voidaan määrittää suoraan tai hankkia implisiittisesti työtilaroolien kautta. Jotta voit hallita semanttisen mallin asetuksia (päivitystä ja muita määrityksiä varten), sinun on oltava semanttisen mallin omistaja.

Määritetyn pilvipalveluyhteyden ja sen mukaan, onko käyttäjien tehtävä kysely Lakehouse- vai SQL-analytiikan päätepisteeseen, sinun on ehkä myönnettävä muita käyttöoikeuksia (kuvattu tämän osion taulukossa).

Muistiinpano

Käyttäjät eivät tarvitse koskaan lupaa lukea tietoja OneLakessa. Tämä johtuu siitä, että Fabric myöntää semanttiseen malliin tarvittavat käyttöoikeudet Delta-taulukoiden ja niihin liittyvien Parquet-tiedostojen lukemiseen (saraketietojen lataamiseen muistiin). Semanttisella mallilla on myös tarvittavat oikeudet lukea säännöllisesti SQL-analytiikan päätepistettä käyttöoikeustarkistusten suorittamiseksi sen määrittämiseksi, mitä tietoja kyselykäyttäjä (tai kiinteät käyttäjätiedot) voivat käyttää.

Kokeile seuraavia skenaarioita ja käyttöoikeusvaatimuksia.

Skenaario Tarvittavat oikeudet Kommentit
Käyttäjät voivat tarkastella raportteja • Myönnä raporttien lukuoikeus ja semanttisen mallin lukuoikeus .
• Jos pilvipalveluyhteys käyttää kertakirjautumista, myönnä vähintään lukuoikeus Lakehouseen tai varastoon.		 Raporttien ei tarvitse kuulua samaan työtilaan kuin semanttisen mallin. Lisätietoja on artikkelissa Vain luku -kuluttajien strategia.
Käyttäjät voivat luoda raportteja • Myönnä semanttisen mallin muodostamisoikeus .
• Jos pilvipalveluyhteys käyttää kertakirjautumista, myönnä vähintään lukuoikeus Lakehouseen tai varastoon.		 Lisätietoja on artikkelissa Sisällöntekijöille tarkoitettu strategia.
Käyttäjät voivat tehdä kyselyjä semanttisesta mallista, mutta heiltä ei evätä kyselyä Lakehousen tai SQL-analytiikan päätepisteeseen • Älä myönnä mitään lupaa lakehouseen tai varastoon. Sopii vain, kun pilviyhteys käyttää kiinteitä käyttäjätietoja.
Käyttäjät voivat tehdä kyselyn semanttiseen malliin ja SQL-analytiikan päätepisteeseen, mutta heiltä ei evätä kyselyä Lakehousesta • Myönnä Read - ja ReadData-käyttöoikeudet lakehouse- tai warehouse-tiloja varten. Tärkeää: SQL-analytiikan päätepisteeseen lähetetyt kyselyt ohittavat semanttisen mallin pakottamat tietojen käytön käyttöoikeudet.
Hallitse semanttista mallia, mukaan lukien päivitysasetuksia • Vaatii semanttisen mallin omistajuuden. Lisätietoja on artikkelissa Semanttisen mallin omistajuus.

Tärkeä

Testaa aina käyttöoikeudet perusteellisesti ennen semanttisen mallin ja raporttien julkaisemista tuotantoon.

Lisätietoja on artikkelissa Semanttisen mallin käyttöoikeudet.

Direct Lake -semanttisten mallien päivittäminen

Semanttisen Direct Lake -mallin päivitys johtaa kehystoimintoon . Päivitystoiminto voidaan käynnistää:

  • Manuaalisesti suorittamalla pyydettäessä suoritettava päivitys Fabric-portaalissa tai suorittamalla TMSL (Tabular Model Scripting Language) -päivityskomento SQL Server Management Studion (SSMS) komentosarjasta tai käyttämällä kolmannen osapuolen työkalua, joka muodostaa yhteyden XMLA-päätepisteen kautta.
  • Automaattisesti määrittämällä päivitysaikataulu Fabric-portaalissa.
  • Automaattisesti, kun pohjana olevista Delta-taulukoista havaitaan muutoksia . Lisätietoja on kohdassa Automaattiset päivitykset (kuvailtu seuraavaksi).
  • Ohjelmallisesti käynnistämällä päivitys Power BI REST -ohjelmointirajapinnan tai TOM:n avulla. Ohjelmallinen päivitys saattaa käynnistyä poiminta-, muunnos- ja latausprosessin (ETL) viimeisenä vaiheena.

Automaattiset päivitykset

Käytössä on semanttinen mallitason asetus nimeltä Pidä Direct Lake -tietosi ajan tasalla , joka tekee Direct Lake -taulukoiden automaattiset päivitykset. Se on oletusarvoisesti käytössä. Se varmistaa, että OneLaken tietojen muutokset näkyvät automaattisesti Direct Laken semanttisessa mallissa. Asetus on käytettävissä Semanttisen mallin asetusten Päivitä-osiossa Fabric-portaalissa.

Kun asetus on käytössä, semanttinen malli suorittaa kehystoiminnon aina, kun pohjana olevissa Delta-taulukoissa havaitaan tietojen muutoksia. Framing-toiminto koskee aina vain niitä taulukoita, joissa tiedot muokataan.

Suosittelemme, että jätät asetuksen käyttöön erityisesti silloin, kun käytössä on pieni tai keskikokoinen semanttinen malli. Se on erityisen hyödyllistä, kun sinulla on pienen viiveen raportointivaatimukset ja Delta-taulukoita muokataan säännöllisesti.

Joissakin tilanteissa saatat haluta poistaa automaattiset päivitykset käytöstä. Saatat esimerkiksi joutua sallimaan tietojen valmistelutöiden tai ETL-prosessin valmistumisen, ennen kuin julkaiset uusia tietoja semanttisen mallin kuluttajille. Kun tämä on poistettu käytöstä, voit käynnistää päivityksen ohjelmallisella menetelmällä (kuvattu aiemmin).

Muistiinpano

Power BI keskeyttää automaattiset päivitykset, kun päivityksen aikana ilmenee virhe , jota ei voi palauttaa. Palautettamaton virhe voi ilmetä esimerkiksi silloin, kun päivitys epäonnistuu useiden yritysten jälkeen. Varmista siis, että semanttinen mallisi voidaan päivittää onnistuneesti. Power BI jatkaa automaattisesti automaattisia päivityksiä, kun myöhempi pyydettäessä suoritettava päivitys valmistuu ilman virheitä.

Tallenna välimuisti lämpimästi

Semanttinen Direct Lake -mallin päivitystoiminto saattaa häätää kaikki asukassarakkeet muistista. Tämä tarkoittaa sitä, että ensimmäiset kyselyt Direct Lake -järjestelmän semanttisen mallin päivittämisen jälkeen voivat kohdata viiveitä, kun sarakkeet ladataan muistiin. Viiveet saattavat olla havaittavissa vain, jos tietomääriä on erittäin paljon.

Jos haluat välttää tällaiset viiveet, harkitse välimuistin lämpenemistä lähettämällä kysely ohjelmallisesti semanttiseen malliin. Kätevä tapa lähettää kysely on käyttää semanttista linkkiä. Tämä toiminto tulee tehdä heti, kun päivitystoiminto on valmis.

Tärkeä

Välimuistin lämmittäminen voi olla järkevää vain, jos viivästykset eivät ole sietämättömiä. Varo lataamasta tietoja tarpeettomasti muistiin, joka voi aiheuttaa painetta muille kapasiteetin kuormitusten kuormituksella, jolloin ne voivat jumittua tai vanhentua.

Direct Lake Behavior -ominaisuuden määrittäminen

Voit hallita Direct Laken semanttisten mallien varatoimintoa asettamalla sen DirectLakeBehavior ominaisuuden. Sen arvoksi voidaan määrittää:

  • Automaattinen: (oletus) Kyselyt siirtyvät takaisin DirectQuery-tilaan, jos vaadittuja tietoja ei voida ladata tehokkaasti muistiin.
  • DirectLakeOnly: Kaikki kyselyt käyttävät vain Direct Lake -tallennustilaa. DirectQuery-tilaan palaaminen on poistettu käytöstä. Jos tietoja ei voida ladata muistiin, palautetaan virhe.
  • DirectQueryOnly: Kaikki kyselyt käyttävät vain DirectQuery-tilaa. Tämän asetuksen avulla voit testata varasuoritustehoa, jossa voit esimerkiksi tarkkailla kyselyn suorituskykyä yhdistetyissä raporteissa.

Voit määrittää -ominaisuuden verkkomallinnuskokemuksessa tai käyttämällä taulukko-objektimallia (TOM) tai taulukkomallin komentosarjakieltä (TMSL).

Vihje

Harkitse DirectQuery-varaohjausta, jos haluat käsitellä kyselyitä vain Direct Lake -tallennustilassa. Suosittelemme poistamaan vara varautumisen käytöstä, kun et halua palata DirectQueryyn. Siitä voi olla hyötyä myös silloin, kun haluat analysoida Direct Lake -semanttisen mallin kyselyjen käsittelyä sen selvittämiseksi, esiintyykö varatoiminto ja kuinka usein.

Direct Lake -semanttisten mallien valvonta

Voit valvoa semanttista Direct Lake -mallia, joka määrittää raportin visualisointien DAX-kyselyiden suorituskyvyn tai määrittää, milloin se palaa DirectQuery-tilaan.

Voit käyttää suorituskyvyn analysointia, SQL Serverin profilointia, Azure Log Analyticsia tai avoimen lähdekoodin yhteisötyökalua, kuten DAX Studiota.

Suorituskyvyn analysointi

Performance Analyzerin avulla Power BI Desktopissa voit tallentaa prosessointiajan, joka tarvitaan kyselyn suorittamiseen johtaneen käyttäjän vuorovaikutuksen tuloksena aloitettujen raporttielementtien päivittämiseen. Jos valvontatuloksissa näkyy DirectQuery-kyselyarvo , se tarkoittaa, että DAX-kyselyt on käsitelty DirectQuery-tilassa. Jos kyseistä mittausarvoa ei ole, DAX-kyselyt käsiteltiin Direct Lake -tilassa.

Lisätietoja on artikkelissa Analysoi suorituskyvyn analysoinnin avulla.

SQL Server Profiler

SQL Serverin profiloinnin avulla voit hakea tietoja kyselyn suorituskyvystä jäljittämällä kyselytapahtumia. Se asennetaan SQL Server Management Studion (SSMS) kanssa. Varmista ennen aloittamista, että asennettuna on SSMS:n uusin versio.

Lisätietoja on artikkelissa Analysoi SQL Serverin profilointitoiminnon avulla.

Tärkeä

Yleensä Direct Lake -tallennustila tarjoaa nopean kyselyn suorituskyvyn, ellei DirectQuery-tilaan varatoiminto ole tarpeen. Koska DirectQuery-tilaan siirtyminen voi vaikuttaa kyselyn suorituskykyyn, on tärkeää analysoida Direct Laken semanttisen mallin kyselyjen käsittelyä sen selvittämiseksi, esiintyykö ja kuinka usein varatoimintoja tapahtuu.

Azuren lokianalytiikka

Azure Log Analyticsin avulla voit kerätä, analysoida ja käsitellä Direct Laken semanttiseen malliin liittyviä telemetriatietoja. Se on Azure Monitorin palvelu, jota Power BI käyttää toimintolokien tallentamiseen.

Lisätietoja on artikkelissa Azure Log Analyticsin käyttäminen Power BI:ssä.

Liittyvä sisältö