Jaa


Direct Lake -yleiskatsaus

Direct Lake on Semanttisen Power BI -mallin taulukoiden tallennustilan tilavaihtoehto, joka on tallennettu Microsoft Fabric -työtilaan. Se on optimoitu suurille tietomäärille, jotka voidaan ladata nopeasti muistiin Delta-taulukoista, jotka tallentavat tietonsa Parquet-tiedostoihin OneLakeen, joka on kaikkien analyysitietojen yksittäinen säilö. Kun semanttinen malli on ladattu muistiin, semanttinen malli mahdollistaa suuren suorituskyvyn kyselyt. Direct Lake poistaa hitaan ja kalliin tarpeen tuoda tietoja malliin.

Direct Lake -tallennustilan avulla voit muodostaa yhteyden yhden Fabric Lakehouse- tai Fabric-varaston taulukoihin tai näkymiin. Kumpikin näistä Fabric-kohteista ja Direct Laken semanttisista malleista edellyttää Fabric-kapasiteetin käyttöoikeutta.

Kaaviossa näkyy semanttinen Direct Lake -malli ja se, miten se muodostaa yhteyden OneLaken Delta-taulukoihin edellisissä kappaleissa kuvatulla tavalla.

Semanttinen Direct Lake -malli on jollain tapaa samankaltainen kuin tuonnin semanttinen malli. Tämä johtuu siitä, että VertiPaq-moduuli lataa mallitiedot muistiin kyselyjen nopeaa suorituskykyä varten (lukuun ottamatta DirectQuery-varatoimintoa, joka selitetään myöhemmin tässä artikkelissa).

Semanttinen Direct Lake -malli eroaa kuitenkin tuonnin semanttisesta mallista tärkeällä tavalla. Tämä johtuu siitä, että Direct Lake -semanttisen mallin päivitystoiminto poikkeaa käsitteellisesti tuonnin semanttisen mallin päivitystoiminnosta. Semanttisen Direct Lake -mallin päivitykseen liittyy määritystoiminto (kuvataan myöhemmin tässä artikkelissa), jonka suorittaminen voi kestää muutamia sekunteja. Se on halpa toiminto, jossa semanttinen malli analysoi Delta-taulukoiden uusimman version metatiedot ja päivitetään viittaamaan OneLaken uusimpiin tiedostoihin. Tuonti-semanttisen mallin kohdalla päivitys sen sijaan tuottaa tiedoista kopion, mikä voi kestää huomattavasti aikaa ja kuluttaa merkittävästi tietolähde- ja kapasiteettiresursseja (muisti ja suoritin).

Muistiinpano

Tuontisen semanttisen mallin lisäävä päivitys voi auttaa lyhentämään kapasiteettiresurssien päivitysaikaa ja käyttöä.

Milloin kannattaa käyttää Direct Lake -tallennustilaa?

Direct Lake -tallennustilan ensisijainen käyttötapaus on yleensä IT-perustuvissa analytiikkaprojekteissa, jotka hyödyntävät järvikeskeisiä arkkitehtuureja. Tässä skenaariossa sinulla on – tai oletat kerääväsi – suuria tietomääriä OneLakessa. Näiden tietojen nopea lataaminen muistiin, usein toistuvat ja nopeat päivitystoiminnot, kapasiteetin resurssien tehokas käyttö ja nopea kyselyjen suorituskyky ovat kaikki tärkeitä tässä käyttötapauksessa.

Muistiinpano

Semanttiset tuonti- ja DirectQuery-mallit ovat edelleen merkityksellisiä Fabricissa, ja ne ovat joissakin tilanteissa oikea valinta semanttiseen malliin. Esimerkiksi Tuonnin tallennustila toimii usein hyvin omatoimiiselle analyytikolle, joka tarvitsee vapautta ja ketteryyttä toimiakseen nopeasti ja ilman riippuvuutta IT-tietoelementteihin uusien tietoelementtien lisäämiseksi.

OneLake-integrointi kirjoittaa automaattisesti tietoja taulukoille Tuonnin tallennustilan tila -kohdassa OneLaken Delta-taulukoihin ilman siirtotoimia. Tämän vaihtoehdon avulla voit hyödyntää monia Fabricin etuja, jotka ovat semanttisten mallikäyttäjien käytettävissä, kuten integrointi lakehouse-taloihin pikakuvakkeiden, SQL-kyselyjen ja muistikirjojen kautta. Suosittelemme, että pidät tätä vaihtoehtoa nopeana tapana hyödyntää Fabricin etuja ilman, että suunnittelet olemassa olevaa tietovarastoa ja/tai analytiikkajärjestelmääsi heti uudelleen.

Direct Lake -tallennustila soveltuu myös tietojen viiveen minimointiin, jotta tiedot saadaan nopeasti yrityskäyttäjien saataville. Jos Delta-taulukoitasi muokataan ajoittain (ja olettaen, että olet jo valmistellut tiedot Data Lakeen), voit luottaa siihen, että automaattiset päivitykset käsittelevät uudelleen näiden muutosten johdosta. Tässä tapauksessa semanttiseen malliin lähetetyt kyselyt palauttavat uusimmat tiedot. Tämä ominaisuus toimii hyvin yhdessä Power BI -raporttien automaattisen sivun päivitysominaisuuden kanssa.

Muista, että Direct Lake riippuu datan valmistelusta Data Lake -tallennustilassa. Tietojen valmistelu voidaan tehdä erilaisilla työkaluilla, kuten Spark-työt Fabric lakehouseille, T-SQL DML -lausekkeet Fabric-varastoille, tietovoille, putkille ja muille. Tämä lähestymistapa auttaa varmistamaan, että tietojen valmistelulogiikka suoritetaan arkkitehtuurissa mahdollisimman matalalla uudelleenkäytettävyyden maksimoimiseksi. Jos semanttisen mallin tekijä ei kuitenkaan pysty muokkaamaan lähdekohdetta, esimerkiksi jos kyseessä on omatoiminen analyytikko, jolla ei ehkä ole kirjoitusoikeuksia IT-järjestelmän hallitsemaan lakehouse-tallennustilaan, tuontitallennustilan tila voi olla parempi vaihtoehto. Tämä johtuu siitä, että se tukee tietojen valmistelua käyttämällä Power Queryä, joka on määritetty osana semanttista mallia.

Kun huomioit Direct Lake -tallennustilan tilan, ota huomioon nykyinen Fabric-kapasiteetin käyttöoikeutesi ja Fabric-kapasiteetin suojakaiteet. Ota huomioon myös huomioitavat asiat ja rajoitukset, jotka kuvataan myöhemmin tässä artikkelissa.

Vihje

Suosittelemme, että luot prototyypin tai soveltuvuusselvityksen sen määrittämiseksi, onko Semanttinen Direct Lake -malli oikea ratkaisu, ja pienentämään riskejä.

Miten Direct Lake toimii?

Yleensä Direct Lake -semanttiseen malliin lähetetyt kyselyt käsitellään Delta-taulukoista peräisin olevien sarakkeiden välimuistista. Delta-taulukon pohjana oleva tallennustila on vähintään yksi Parquet-tiedosto OneLakessa. Parquet-tiedostot järjestävät tiedot sarakkeiden mukaan rivien sijaan. Semanttiset mallit lataavat kokonaisia sarakkeita Delta-taulukoista muistiin, koska kyselyt vaativat niitä.

Semanttinen Direct Lake -malli voi käyttää myös DirectQuery-varamallia, mikä edellyttää saumatonta siirtymistä DirectQuery-tilaan. DirectQuery-varajoukko noutaa tiedot suoraan Lakehousen tai varaston SQL-analytiikan päätepisteestä. Vara varautumista voi ilmetä esimerkiksi silloin, kun Delta-taulukko sisältää enemmän tietorivejä kuin Fabric-kapasiteettisi tukema (kuvataan myöhemmin tässä artikkelissa). Tässä tapauksessa DirectQuery-toiminto lähettää kyselyn SQL-analytiikan päätepisteeseen. Varatoiminnot saattavat hidastaa kyselyn suorituskykyä.

Seuraavassa kaaviossa esitetään Direct Laken toiminta käyttämällä skenaariota käyttäjälle, joka avaa Power BI -raportin.

Kaaviossa näkyy, miten Direct Laken semanttiset mallit toimivat. Kuvassa näytetyt käsitteet kuvataan seuraavassa taulukossa.

Kaaviossa esitetään seuraavat käyttäjän toiminnot, prosessit ja ominaisuudet.

Kohde Kuvaus
OneLake on Data Lake -tallennustila, joka tallentaa analytiikkatiedot Parquet-muodossa. Tämä tiedostomuoto on optimoitu Direct Lake -semanttisten mallien tietojen tallentamista varten.
Fabric Lakehouse- tai Fabric-varasto sijaitsee Fabric-kapasiteetin työtilassa. Lakehousessa on SQL-analytiikan päätepiste, joka tarjoaa SQL-pohjaisen kyselykokemuksen. Taulukot (tai näkymät) tarjoavat keinon tehdä kyselyjä OneLaken Delta-taulukoista Transact-SQL:n (T-SQL) avulla.
Fabric-työtilassa on semanttinen Direct Lake -malli. Se muodostaa yhteyden joko lakehousen tai varaston taulukoihin tai näkymiin.
Käyttäjä avaa Power BI -raportin.
Power BI -raportti lähettää DATA Analysis Expressions (DAX) -kyselyjä Direct Lake -semanttiseen malliin.
Kun semanttinen malli on mahdollista (ja tarpeen), semanttinen malli lataa sarakkeet muistiin suoraan OneLakeen tallennetuista Parquet-tiedostoista. Kyselyillä saavutetaan muistissa oleva suorituskyky, mikä on hyvin nopeaa.
Semanttinen malli palauttaa kyselyn tulokset.
Power BI -raportti hahmontaa visualisoinnit.
Semanttiset mallikyselyt palaavat automaattisesti DirectQuery-tilaan tietyissä tilanteissa, kuten silloin, kun semanttinen malli ylittää kapasiteetin suojakaiteet . Tässä tilassa kyselyt lähetetään Lakehousen tai varaston SQL-analytiikan päätepisteeseen.
SQL-analytiikan päätepisteeseen lähetetyt DirectQuery-kyselyt puolestaan kyselevät OneLaken Delta-taulukoita. Tästä syystä kyselyn suorituskyky voi olla hitaampi kuin muistissa olevien kyselyiden.

Seuraavissa osioissa kuvataan Direct Laken käsitteitä ja ominaisuuksia, kuten sarakkeiden lataaminen, kehystys, automaattiset päivitykset ja DirectQueryn varaversio.

Sarakkeiden lataaminen (koodaus)

Semanttiset Direct Lake -mallit lataavat tietoja OneLakesta vain, kun sarakkeista tehdään kyselyjä ensimmäistä kertaa. Tietojen lataamista pyydettäessä OneLakesta kutsutaan transkoodaukseksi.

Kun semanttinen malli vastaanottaa DAX-kyselyn (tai MDX-lausekkeet, Multidimensional Expressions), se määrittää ensin, mitä sarakkeita tarvitaan kyselyn tuloksen tuottamiseen. Tarvittaviin sarakkeisiin kuuluvat kaikki sarakkeet, joita kysely käyttää suoraan, sekä suhteiden ja mittareiden edellyttämät sarakkeet. Yleensä kyselyn tuloksen tuottamiseen tarvittavien sarakkeiden määrä on paljon pienempi kuin semanttisessa mallissa määritettyjen sarakkeiden määrä.

Kun on selvää, mitä sarakkeita tarvitaan, semanttinen malli määrittää, mitkä sarakkeet ovat jo muistissa. Jos kyselyn edellyttämät sarakkeet eivät ole muistissa, semanttinen malli lataa kaikki tiedot näille sarakkeille OneLakesta. Saraketietojen lataaminen on yleensä erittäin nopea toiminto, mutta se voi riippua eri tekijöistä, kuten sarakkeisiin tallennettujen tietojen kardinaliteetista.

Muistiin ladatut sarakkeet säilytetään sen jälkeen muistissa. Tulevissa kyselyissä, joihin liittyy vain asukassarakkeita, ei tarvitse ladata enempää sarakkeita muistiin.

Sarake on asukas, kunnes se poistetaan (häädetään) muistista siihen saakka, kunnes se poistetaan. Syitä sarakkeiden poistamiseen ovat esimerkiksi seuraavat:

  • Malli tai taulukko on päivitetty (katso framing seuraavasta osiosta).
  • Mikään kysely ei ole käyttänyt saraketta hetkeen.
  • Muita muistinhallintasyitä, kuten muista samanaikaisista toiminnoista johtuva muistinhallintapaine kapasiteetissa.

Fabric SKU -valintasi määrittää kapasiteetin kunkin Direct Lake -semanttisen mallin käytettävissä olevan enimmäismuistin. Lisätietoja resurssien suojakaiteesta ja muistin enimmäisrajasta on tämän artikkelin kohdassa Fabric-kapasiteetin suojakaiteet ja rajoitukset.

Kehystys

Framing tarjoaa mallin omistajille ajankohtaisen hallinnan siitä, mitä tietoja semanttiseen malliin ladataan. Framing on Direct Lake -toiminto, joka käynnistetään semanttisen mallin päivityksellä, ja useimmissa tapauksissa sen suorittaminen kestää vain muutaman sekunnin. Tämä johtuu siitä, että kyseessä on halpa toiminto, jossa semanttinen malli analysoi Delta Lake -taulukoiden uusimman version metatiedot ja päivitetään viittaamaan OneLaken uusimpiin Parquet-tiedostoihin.

Kun kehystää, asukassarakkeet saatetaan häätää muistista ja päivityksen ajankohdasta tulee uusi perusarvo kaikille tuleville transkoodaustapahtumille. Tästä alkaen Direct Lake -kyselyt ottavat huomioon Delta-taulukoiden tiedot vain viimeisimmän kehystoiminnon ajankohdalta. Tästä syystä Direct Lake -taulukoihin tehdään kysely, jotta ne palauttavat tietoja, jotka perustuvat Delta-taulukon tilaan viimeisimmän määritystoiminnon pisteessä. Se aika ei välttämättä ole Delta-taulukoiden viimeisin tila.

Seuraavasta kaaviosta näet, miten Direct Laken framing-toiminnot toimivat.

Kaaviossa näkyy, miten Direct Laken kehystoiminnot toimivat.

Kaaviossa esitetään seuraavat prosessit ja ominaisuudet.

Kohde Kuvaus
Fabric-työtilassa on semanttinen malli.
Määritystoiminnot suoritetaan säännöllisesti, ja ne määrittävät perusarvon kaikille tuleville transkoodaustapahtumille . Framing-toiminnot voivat tapahtua automaattisesti, manuaalisesti, aikataulussa tai ohjelmallisesti.
OneLake tallentaa metatiedot ja Parquet-tiedostot, jotka esitetään Delta-taulukkoina.
Viimeinen framing-toiminto sisältää Parquet-tiedostot, jotka liittyvät Delta-taulukoihin, ja erityisesti Parquet-tiedostot, jotka lisättiin ennen viimeistä kehystoimintoa.
Myöhempi framing-toiminto sisältää Parquet-tiedostot, jotka on lisätty viimeisen kehystoiminnon jälkeen.
Semanttisen Direct Lake -mallin asukassarakkeet saatetaan häätää muistista ja päivityksen ajankohdasta tulee uusi perusarvo kaikille tuleville muuntotapahtumille.
Seuraavat tietojen muutokset, joita edustavat uudet Parquet-tiedostot, eivät näy ennen seuraavaa muotoilutoimintoa.

Ei ole aina toivottavaa, että tiedot edustavat minkään Delta-taulukon viimeisintä tilaa transkoodaustoiminnon yhteydessä. Huomaa, että framing voi auttaa sinua tarjoamaan yhdenmukaisia kyselytuloksia ympäristöissä, joissa Delta-taulukoiden tiedot ovat tilapäisiä. Tiedot voivat olla tilapäisiä useista syistä, kuten pitkäkestoisen poiminnan, muuntamisen ja lataamisen (ETL) prosessien tapahtuessa.

Direct Laken semanttisen mallin päivitys voidaan tehdä manuaalisesti, automaattisesti tai ohjelmallisesti. Lisätietoja on kohdassa Direct Laken semanttisten mallien päivittäminen.

Lisätietoja Delta-taulukon versioinnista ja framingista on kohdassa Direct Laken semanttisten mallien tallennustilan ymmärtäminen.

Automaattiset päivitykset

Direct Lake -taulukoiden automaattiseen päivittämiseen on olemassa semanttinen mallitason asetus. Se on oletusarvoisesti käytössä. Se varmistaa, että OneLaken tietojen muutokset näkyvät automaattisesti Direct Laken semanttisessa mallissa. Poista automaattiset päivitykset käytöstä, kun haluat hallita tietojen muutoksia kehystämällä, mikä selitettiin edellisessä osiossa. Lisätietoja on kohdassa Semanttisten Direct Lake -mallien hallinta.

Vihje

Voit määrittää automaattisen sivun päivityksen Power BI -raporteissasi. Se on ominaisuus, joka päivittää automaattisesti tietyn raporttisivun, jos raportti muodostaa yhteyden semanttiseen Direct Lake -malliin (tai muuntyyppiseen semanttiseen malliin).

DirectQuery-vara varatila

Direct Lake -semanttiseen malliin lähetetty kysely voi palata DirectQuery-tilaan. Tässä tapauksessa se noutaa tiedot suoraan Lakehousen tai varaston SQL-analytiikan päätepisteestä. Tällaiset kyselyt palauttavat aina uusimmat tiedot, koska niitä ei ole rajoitettu viimeisimmän kehystoiminnon aikaan.

Kysely epäonnistuu aina, kun semanttinen malli tekee kyselyn SQL-analytiikan päätepisteen näkymään tai SQL-analytiikan päätepisteen taulukkoon, joka pakottaa rivitason suojauksen (RLS).

Kysely saattaa myös perääntyä, kun semanttinen malli ylittää kapasiteetin suojakaiteet.

Tärkeä

Jos mahdollista, suunnittele ratkaisusi – tai koko kapasiteettisi – aina, jotta vältät DirectQueryn varatoiminnon. Tämä johtuu siitä, että se saattaa hidastaa kyselyn suorituskykyä.

Voit hallita Direct Laken semanttisten mallien varatoimintoa asettamalla sen DirectLakeBehavior-ominaisuuden . Lisätietoja on kohdassa Direct Lake -toimintaominaisuuden määrittäminen.

Fabric-kapasiteetin suojakaiteet ja rajoitukset

Semanttisiin Direct Lake -malleihin tarvitaan Fabric-kapasiteetin käyttöoikeus. Fabric-kapasiteetin tilaukseen (SKU) liittyy myös kapasiteetin suojakaiteita ja rajoituksia, jotka esitetään seuraavassa taulukossa.

Tärkeä

Seuraavan taulukon ensimmäinen sarake sisältää myös Power BI Premium -kapasiteettitilaukset (P-varastointiyksiköt). Ota huomioon, että Microsoft vahvistaa ostovaihtoehtoja ja poistaa käytöstä Kapasiteettikohtaisen Power BI Premiumin. Uusien ja nykyisten asiakkaiden kannattaa harkita Fabric-kapasiteettitilausten (F-varastointiyksiköiden) ostamista.

Lisätietoja on artikkelissa Power BI Premium -käyttöoikeuksien ja Power BI Premiumin tärkeä päivitys.

Fabric SKU Parquet-tiedostot taulukkoa kohden Riviryhmät taulukkoa kohden Rivit taulukkoa kohti (miljoonia) Mallin enimmäiskoko levyllä/OneLakessa (Gt) Muistin enimmäismäärä (Gt) 1
F2 1000 1 000 300 10 3
F4 1000 1 000 300 10 3
F8 1000 1 000 300 10 3
F16 1000 1 000 300 20 5
F32 1000 1 000 300 40 10
F64/FT1/P1 5,000 5,000 1 500 Ei rajoitettu 25
F128/P2 5,000 5,000 3 000 Ei rajoitettu 50
F256/P3 5,000 5,000 6 000 Ei rajoitettu 100
F512/P4 10 000 10,000 12,000 Ei rajoitettu 200
F1024/P5 10 000 10 000 24,000 Ei rajoitettu 400
F2048 10 000 10 000 24,000 Ei rajoitettu 400

1 Semanttisten Direct Lake -mallien muistin enimmäismäärä edustaa muistin resurssien ylärajaa sille, kuinka paljon tietoja voidaan sivuta. Tästä syystä se ei ole suojakaide, koska sen ylittäminen ei aiheuta varautumista DirectQuery-tilaan; Tällä voi kuitenkin olla suorituskykyvaikutus, jos tietojen määrä on niin suuri, että se aiheuttaa liiallista sivutuskäyttöä OneLake-tietojen mallitiedoissa ja niissä.

Jos mallin enimmäiskoko ylittyy levyllä tai OneLakessa, kaikki semanttisen mallin kyselyt palaavat DirectQuery-tilaan. Kaikki muut taulukossa esitetyt suojakaiteet arvioidaan kyselyä kohden. Siksi on tärkeää optimoida Delta-taulukot ja semanttinen Direct Lake -malli, jotta sinun ei tarvitse skaalautua tarpeettomasti jopa suurempaan Fabric-varastointiyksikköön (mikä kasvattaa kustannuksia).

Lisäksi semanttisia Direct Lake -malleja koskevat kapasiteettiyksikkö ja muistin enimmäismäärä kyselyä kohden. Lisätietoja on kohdassa Kapasiteetit ja SKU.

Huomioitavat asiat ja rajoitukset

Semanttiset Direct Lake -mallit esittävät joitakin huomioon otettavia seikkoja ja rajoituksia.

Muistiinpano

Direct Laken semanttisten mallien ominaisuudet ja ominaisuudet kehittyvät. Muista tarkistaa säännöllisesti, mikä on viimeisin huomioon otettavien seikkojen ja rajoitusten luettelo.

  • Kun semanttinen Direct Lake -mallitaulukko muodostaa yhteyden SQL-analytiikan päätepisteen taulukkoon, joka ottaa käyttöön rivitason suojauksen (RLS), tähän mallitaulukkoon liittyvät kyselyt palataan aina DirectQuery-tilaan. Kyselyn suorituskyky voi olla hitaampi.
  • Kun semanttinen Direct Lake -mallitaulukko muodostaa yhteyden SQL-analytiikan päätepisteen näkymään, tähän mallitaulukkoon liittyvät kyselyt palaavat aina DirectQuery-tilaan. Kyselyn suorituskyky voi olla hitaampi.
  • Yhdistelmämallinnusta ei tueta. Tämä tarkoittaa, että semanttisia Direct Lake -mallitaulukoita ei voi sekoittaa muissa tallennustiloissa olevien taulukoiden, kuten tuonti, DirectQuery tai kaksoistaulukko, kanssa (lukuun ottamatta erityistapauksia, kuten laskentaryhmiä, entä jos -parametreja ja kenttäparametreja).
  • Laskettuja sarakkeita ja laskettuja taulukoita, jotka viittaavat sarakkeisiin tai taulukoihin Direct Lake -tallennustilassa, ei tueta. Laskentaryhmiä, entä jos -parametreja ja kentän parametreja, jotka luovat implisiittisesti laskettuja taulukoita ja laskettuja taulukoita, jotka eivät viittaa Direct Lake -sarakkeisiin tai -taulukoihin, tuetaan.
  • Direct Lake -tallennustilan tilataulukot eivät tue monimutkaisia Delta-taulukon saraketyyppejä. Myös semanttisia binaarisia tyyppejä ja GUID-tunnuksia ei tueta. Nämä tietotyypit on muunnettava merkkijonoiksi tai muuksi tuetuksi tietotyypiksi.
  • Taulukkosuhteet edellyttävät, että liittyvien sarakkeiden tietotyypit vastaavat toisiaan.
  • Yhden puolen suhteiden sarakkeissa on oltava yksilöllisiä arvoja. Kyselyt epäonnistuvat, jos yhden puolen sarakkeesta havaitaan arvojen kaksoiskappaleita.
  • Automaattista tietojen/aikatietojen käyttö Power BI Desktopissa ei ole tuettua. Oman päivämäärätaulukon merkitsemistä päivämäärätaulukoksi tuetaan.
  • Merkkijonosarakearvojen pituus on rajoitettu 32 764 Unicode-merkkiin.
  • Liukulukuarvoa NaN (ei luku) ei tueta.
  • Upotustilanteita, jotka käyttävät For your customer -käyttöskenaariota, ei tueta.
  • Power BI:n Julkaise verkkoon - toimintoa tuetaan vain, kun käytössä on kiinteät käyttäjätiedot Direct Laken semanttisessa mallissa.
  • Verkkomallintamiskokemuksessa semanttisten Direct Lake -mallien vahvistus on rajoitettu. Käyttäjän valintojen oletetaan olevan oikein, eikä kyselyjä anneta kardinaliteetin tai ristiinsuodatuksen suhteiden vahvistamiseksi tai merkityn päivämäärätaulukon valitulle päivämääräsarakkeelle.
  • Fabric-portaalissa päivityshistorian Direct Lake -välilehdessä luetellaan vain Direct Lakeen liittyvät päivitysvirheet. Onnistuneita päivitystoimintoja ei luetella.
  • Fabric-varastointiyksikkö määrittää kapasiteetin suurimman käytettävissä olevan muistin per Direct Lake -semanttinen malli. Kun raja ylitetään, semanttiseen malliin lähetetyt kyselyt voivat olla hitaampia mallitietojen liiallisen sivutuksen vuoksi.
  • Direct Lake -semanttisen mallin luomista työtilaan, joka sijaitsee tietolähdetyötilan eri alueella, ei tueta. Jos Lakehouse sijaitsee esimerkiksi Yhdysvaltojen läntisessä keskiosassa, voit luoda semanttisia malleja vain tästä Lakehousesta samalla alueella. Vaihtoehtoinen menetelmä on luoda Lakehouse toisen alueen työtilaan ja pikakuvake taulukoihin ennen semanttisen mallin luomista. Jos haluat tietää, millä alueella olet, etsi Fabric-kotialueesi.
  • Voit luoda ja tarkastella mukautettua semanttista Direct Lake -semanttista mallia palvelun päänimen käyttäjätietojen avulla, mutta semanttinen Direct Lake -oletusmalli ei tue palvelun päänimiä. Varmista, että palvelun päänimen todentaminen on käytössä vuokraajan Fabric REST -ohjelmointirajapinnoille, ja myönnä palvelun päänimelle Osallistuja tai suuremmat käyttöoikeudet Direct Laken semanttisen mallin työtilaan.
  • Direct Lake ei tue palvelun päänimiprofiileja todentamisessa.

Vertailu muihin tallennustiloihin

Seuraavassa taulukossa verrataan Direct Lake -tallennustilaa tuonti- ja DirectQuery-tallennustiloihin.

Ominaisuus Direct Lake Tuo DirectQuery
Käyttöoikeudet Fabric-kapasiteetin tilaus (vain SKU) Mikä tahansa Fabric- tai Power BI -käyttöoikeus (mukaan lukien Microsoft Fabric Free -käyttöoikeudet) Mikä tahansa Fabric- tai Power BI -käyttöoikeus (mukaan lukien Microsoft Fabric Free -käyttöoikeudet)
Data source Vain Lakehouse- tai varastotaulukot (tai näkymät) Mikä tahansa liitin Mikä tahansa DirectQuery-tilaa tukeva liitin
SQL-analytiikan päätepistenäkymiin yhdistäminen Kyllä – mutta palaa automaattisesti DirectQuery-tilaan Kyllä Kyllä
Yhdistelmämallit Nro 1 Kyllä – voidaan yhdistää DirectQueryn tai kaksoistallennustilan taulukoihin Kyllä – voidaan yhdistää tuonti- tai kaksoistallennustilan taulukoihin
Kertakirjautuminen (SSO) Kyllä Ei käytettävissä Kyllä
Lasketut taulukot Ei – lukuun ottamatta laskentaryhmiä, entä jos -parametreja ja kenttäparametreja, jotka implisiittisesti luovat laskettuja taulukoita Kyllä Ei – lasketut taulukot käyttävät Tuonti-tallennustilaa, vaikka ne viittaavat muihin taulukoihin DirectQuery-tilassa
Lasketut sarakkeet Ei Kyllä Kyllä
Yhdistelmätaulukot Ei Kyllä Kyllä
Mallitaulukon osiot Ei – osiointi voidaan kuitenkin tehdä Delta-taulukon tasolla Kyllä – joko automaattisesti luotu lisäävällä päivityksellä tai manuaalisesti XMLA-päätepisteen avulla En
Käyttäjän määrittämät koosteet Ei Kyllä Kyllä
SQL Analytics -päätepisteen objektitason suojaus tai saraketason suojaus Kyllä – mutta kyselyt palaavat DirectQuery-tilaan ja saattavat tuottaa virheitä, kun käyttöoikeus hylätään Kyllä – mutta päällekkäisten käyttöoikeuksien on oltava semanttisen mallin objektitason suojauksessa Kyllä – mutta kyselyt saattavat aiheuttaa virheitä, kun käyttöoikeus hylätään
SQL Analytics -päätepisteen rivitason suojaus (RLS) Kyllä – mutta kyselyt palaavat DirectQuery-tilaan Kyllä – mutta käyttöoikeuksien on oltava kaksoiskappaleita semanttisen mallin rivitason suojauksen avulla Kyllä
Semanttisen mallin rivitason suojaus (RLS) Kyllä – mutta on erittäin suositeltavaa käyttää kiinteää käyttäjätietojen pilviyhteyttä Kyllä Kyllä
Semanttisen mallin objektitason suojaus (OLS) Kyllä Kyllä Kyllä
Suuret tietomäärät ilman päivitysvaatimuksia Kyllä Vähemmän sopiva – kyselyihin ja päivityksiin saatetaan tarvita suurempi kapasiteetin koko Kyllä
Tietojen viiveen pienentäminen Kyllä – kun automaattiset päivitykset ovat käytössä, tai ohjelmallinen uudelleenmääritys; tietojen valmistelu on kuitenkin tehtävä ensin ennen tietojen valmistelua . Ei Kyllä

1 Et voi yhdistää Direct Lake -tallennustilan taulukoita DirectQuery- tai kaksoistallennustilan taulukoihin samassa semanttisessa mallissa. Voit kuitenkin käyttää Power BI Desktopia yhdistelmämallin luomiseen semanttisessa Direct Lake -mallissa ja laajentaa sitä sitten uusilla taulukoilla (käyttämällä tuonti-, DirectQuery- tai kaksoistallennustilaa) tai laskutoimituksia. Lisätietoja on artikkelissa Yhdistelmämallin luominen semanttisesta mallista.