Direct Lake

Direct Lake - tila on semanttinen malliominaisuus erittäin suurten tietomäärien analysoinnissa Power BI:ssä. Direct Lake perustuu parquet-muotoiltujen tiedostojen lataamiseen suoraan Data Lake -tallennustilasta ilman kyselyä Lakehousen tai varaston päätepisteeseen eikä tietoja tarvitse tuoda tai monistaa Power BI -malliin. Direct Lake on nopea polku tietojen lataamiseen järvestä suoraan Power BI -moduuliin, joka on valmis analysoitavaksi. Seuraavassa kaaviossa näytetään, miten perinteiset tuonti- ja DirectQuery-tilat vertautuvat Direct Lake -tilaan.

Direct Lake -ominaisuuksien kaavio.

DirectQuery-tilassa Power BI -moduuli tekee kyselyn lähteen tietoihin, mikä voi olla hidasta, mutta tällä tavalla vältetään tietojen kopiointi tuontitilassa. Tietolähteen muutokset näkyvät heti kyselyn tuloksissa.

Toisaalta tuontitilassa suorituskyky voi olla parempi, koska tiedot tallennetaan välimuistiin ja optimoidaan DAX- ja MDX-raporttikyselyille ilman, että niitä tarvitsee kääntää ja välittää SQL-kyselyitä tai muita kyselytyyppejä tietolähteelle. Power BI -moduulin on kuitenkin ensin kopioitava malliin kaikki uudet tiedot päivityksen aikana. Lähteen muutokset haetaan vain seuraavan mallipäivityksen yhteydessä.

Direct Lake -tila poistaa tuontivaatimuksen lataamalla tiedot suoraan OneLakesta. Toisin kuin DirectQuery, DAX:ää tai MDX:ää ei käännetä muille kyselykielille tai kyselyiden suorittamista muissa tietokantajärjestelmissä, mikä tuottaa tuontitilan kaltaisen suorituskyvyn. Koska eksplisiittistä tuontiprosessia ei ole, on mahdollista noutaa muutokset tietolähteestä sellaisinaan yhdistämällä sekä DirectQuery- että tuontitilojen edut ja välttämällä niiden haitat. Direct Lake -tila voi olla erinomainen valinta erittäin suurten mallien ja mallien analysointiin, sillä tietolähde päivittää niitä usein.

Direct Lake tukee myös rivitason suojausta ja objektitason suojausta, joten käyttäjät näkevät vain tiedot, jotka heillä on oikeus nähdä.

Edellytykset

Direct Lakea tuetaan vain Microsoft Fabric F -tuotteissa.

Lakehouse

Ennen Kuin käytät Direct Lakea, sinun on valmisteltava Lakehouse (tai varasto), jossa on yksi tai useampi Delta-taulukko työtilassa, jota isännöidään tuetussa Microsoft Fabric -kapasiteetissa. Lakehouse-tallennustilaa tarvitaan, koska se tarjoaa parquet-muotoisten tiedostojen tallennussijainnin OneLakessa. Lakehouse tarjoaa myös kantopisteen verkkomallinnusominaisuuden käynnistämiseen Direct Lake -mallin luomiseksi.

Lisätietoja Lakehousen valmistelusta, Delta-taulukon luomisesta Lakehousessa ja perusmallin luomisesta Lakehouselle on kohdassa Lakehousen luominen Direct Lakelle.

SQL-päätepiste

Lakehousen valmistelun osana luodaan SQL-kyselyiden SQL-päätepiste ja raporttien oletusmalli, ja kaikki taulukot päivitetään Lakehouseen lisätyillä taulukoilla. Vaikka Direct Lake -tila ei tee kyselyä SQL-päätepisteelle ladattaessa tietoja suoraan OneLakesta, direct lake -mallin on palattava saumattomasti DirectQuery-tilaan. Tällöin tietolähde käyttää tiettyjä ominaisuuksia, kuten edistynyttä suojausta tai näkymiä, joita ei voi lukea Direct Laken kautta. Direct Lake -tila lähettää sql-päätepisteeseen kyselyn myös rakenteeseen ja suojaukseen liittyvien tietojen osalta.

Tietovarasto

Vaihtoehtona Lakehouselle, jossa on SQL-päätepiste, voit myös valmistella varaston ja lisätä taulukoita käyttämällä SQL-lausekkeita tai tietoputkia. Menettely erillisen tietovaraston valmistelemiseksi on lähes samanlainen kuin lakehouse-järjestelmän menettely.

Mallin kirjoitustuki XMLA-päätepisteellä

Direct Lake -mallit tukevat kirjoitustoimintoja XMLA-päätepisteen kautta käyttämällä työkaluja, kuten SQL Server Management Studiota (19.1 ja uudempia), sekä ulkoisten BI-työkalujen, kuten Tabular Editorin ja DAX Studion, uusimpia versioita. Mallin kirjoitustoiminnot XMLA-päätepistetuen kautta:

  • Direct Lake -mallin metatietojen mukauttaminen, yhdistäminen, komentosarjat, virheenkorjaus ja testaus.

  • Lähteen ja version hallinta, jatkuva integrointi ja jatkuva käyttöönotto (CI/CD) Azure DevOpsin ja GitHubin kanssa.

  • Automaatiotehtävät, kuten päivittäminen ja muutosten lisääminen Direct Lake -malleihin PowerShellin ja REST-ohjelmointirajapintojen avulla.

Huomaa, että XMLA-sovelluksilla luodut Direct Lake -taulukot ovat aluksi käsittelemättömässä tilassa, kunnes sovellus myöntää päivityskomennon. Käsittelemättömät taulukot palataan DirectQuery-tilaan. Kun luot uutta semanttista mallia, muista päivittää semanttinen mallisi taulukoiden käsittelyäksi.

XMLA:n luku/kirjoitusten ottaminen käyttöön

Ennen kuin suoritat kirjoitustoimintoja Direct Lake -malleissa XMLA-päätepisteen kautta, XMLA:n luku/kirjoitus täytyy ottaa käyttöön kapasiteetille.

Fabric-kokeilukapasiteetissa kokeiluversion käyttäjällä on järjestelmänvalvojan oikeudet, joita tarvitaan XMLA:n luku/kirjoitusoikeuden käyttöön ottamiseksi.

  1. Valitse Hallinta-portaalissa Kapasiteettiasetukset.

  2. Napsauta Kokeiluversio-välilehteä .

  3. Valitse kapasiteetin, jossa on kokeiluversio , ja käyttäjänimesi kapasiteetin nimestä.

  4. Laajenna Power BI -kuormituksia ja valitse sitten XMLA-päätepiste-asetuksesta Luku ja kirjoitus.

    Näyttökuva Fabric-kokeilukapasiteetin XMLA-päätepisteen luku/kirjoitus -asetuksesta.

Muista, että XMLA-päätepiste-asetus koskee kaikkia kapasiteettiin määritettyjä työtiloja ja malleja.

Direct Lake -mallin metatiedot

Kun yhdistät erilliseen Direct Lake -malliin XMLA-päätepisteen kautta, metatiedot näyttävät samalta kuin mikä tahansa muu malli. Direct Lake -mallit näyttävät kuitenkin seuraavat erot:

  • compatibilityLevel Tietokantaobjektin ominaisuus on vähintään 1604.

  • Mode Direct Lake -osioiden -ominaisuuden arvona directLakeon .

  • Direct Lake -osiot käyttävät jaettuja lausekkeita tietolähteiden määrittämiseen. Lauseke osoittaa Lakehousen tai varaston SQL-päätepisteeseen. Direct Lake käyttää SQL-päätepistettä rakenne- ja suojaustietojen etsimiseen, mutta lataa tiedot suoraan Delta-taulukoista (ellei Direct Laken tarvitse jostain syystä palata DirectQuery-tilaan).

Tässä on esimerkki XMLA-kyselystä SSMS:ssä:

Näyttökuva XMLA-kyselystä SSMS:ssä.

Lisätietoja työkalutuesta XMLA-päätepisteen kautta on artikkelissa Semanttinen malliyhteys XMLA-päätepisteeseen.

Varakohde

Direct Lake -tilassa olevat Power BI:n semanttiset mallit lukevat Delta-taulukoita suoraan OneLakesta. Jos Direct Lake -mallin DAX-kysely kuitenkin ylittää varastointiyksikön rajoitukset tai käyttää ominaisuuksia, jotka eivät tue Direct Lake -tilaa, kuten varaston SQL-näkymiä, kysely voi palata DirectQuery-tilaan. DirectQuery-tilassa kyselyt hakevat SQL:llä tulokset Lakehousen tai varaston SQL-päätepisteestä, mikä voi vaikuttaa kyselyn suorituskykyyn. Voit poistaa DirectQuery-tilaan varautumisen käytöstä, jos haluat käsitellä DAX-kyselyt vain puhtaassa Direct Lake -tilassa. Varauman poistamista käytöstä suositellaan, jos et tarvitse directquery-varaohjausta. Siitä voi olla hyötyä myös analysoitaessa Direct Lake -mallin kyselyjen käsittelyä sen selvittämiseksi, esiintyykö varakysely ja kuinka usein. Lisätietoja DirectQuery-tilasta on artikkelissa Semanttisen mallin tilat Power BI:ssä.

Suojakaiteet määrittävät Direct Lake -tilan resurssirajoitukset, minkä lisäksi DAX-kyselyiden käsittelemiseen tarvitaan varatila DirectQuery-tilaan. Lisätietoja Delta-taulukon jäsennystiedostojen ja riviryhmien määrän määrittämisestä on Delta-taulukon ominaisuudet -viittauksessa.

Semanttisissa Direct Lake -malleissa Muistin enimmäismäärä edustaa muistin resurssien ylärajaa sille, kuinka paljon tietoja voidaan sivuta. Itse asiassa se ei ole suojakaiteen, koska sen ylittäminen ei aiheuta varautumista DirectQueryyn; Tällä voi kuitenkin olla suorituskykyvaikutus, jos tietojen määrä on niin suuri, että se aiheuttaa sivutustietoja OneLake-tiedoista ja mallista.

Seuraavassa taulukossa on lueteltu sekä resurssien suojakaiteet että Enimmäismuisti:

Fabric SKU Parquet-tiedostot taulukkoa kohden Riviryhmät taulukkoa kohden Rivit taulukkoa kohti (miljoonia) Mallin enimmäiskoko levyllä/OneLake1 (Gt) Muistin enimmäismäärä (Gt)
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 – Jos malli ylittyy, mallin enimmäiskoko levyllä/Onelakessa palauttaa kaikki mallin kyselyt DirectQueryyn toisin kuin muut kyselyä kohti lasketut suojakaiteet.

Fabric-SKU:stasi riippuen Direct Lake -malleihin sovelletaan myös muuta kapasiteettiyksikköä ja kyselykohtaista muistin enimmäismäärää. Lisätietoja on kohdassa Kapasiteetit ja SKU.

Varatoiminto

Direct Lake -mallit sisältävät DirectLakeBehavior-ominaisuuden , jolla on kolme vaihtoehtoa:

Automaattinen – (oletus) Määrittää, että kyselyt palataan DirectQuery-tilaan , jos tietoja ei voida ladata tehokkaasti muistiin.

DirectLakeOnly – Määrittää, että kaikki kyselyt käyttävät vain Direct Lake -tilaa. DirectQuery-tilaan varavalinta on poistettu käytöstä. Jos tietoja ei voida ladata muistiin, palautetaan virhe. Tämän asetuksen avulla voit selvittää, epäonnistuvatko DAX-kyselyt tietojen lataamisen muistiin ja pakottavat virheen palautettamaan.

DirectQueryOnly – Määrittää, että kaikki kyselyt käyttävät vain DirectQuery-tilaa. Tämän asetuksen avulla voit testata varasuorituskykyä.

DirectLakeBehavior-ominaisuus voidaan määrittää käyttämällä taulukko-objektimallia (TOM) tai taulukkomallin komentosarjakieltä (TMSL).

Seuraavassa esimerkissä määritetään, että kaikki kyselyt käyttävät vain Direct Lake -tilaa:

// Disable fallback to DirectQuery mode.
//
database.Model.DirectLakeBehavior = DirectLakeBehavior.DirectLakeOnly = 1;
database.Model.SaveChanges();

Kyselyn käsittelyn analysointi

Voit analysoida kyselyjä käyttämällä Performance Analyzeria Power BI Desktopissa, SQL Serverin profilointi tai muissa kolmannen osapuolen työkaluissa sen selvittämiseksi, tarjoaako raportin visualisoinnin DAX-kyselyt tietolähteelle parhaan suorituskyvyn Direct Lake -tilan avulla tai palaamalla takaisin DirectQuery-tilaan. Lisätietoja on artikkelissa Direct Lake -mallien kyselyjen käsittelyn analysointi.

Päivitä

Oletusarvoisesti OneLake-tietojen muutokset näkyvät automaattisesti Direct Lake -mallissa. Voit muuttaa tätä toimintaa poistamalla Käytöstä Pidä Direct Lake -tietosi ajan tasalla mallin asetuksissa.

Näyttökuva Direct Lake -päivitysvaihtoehdosta malliasetuksissa.

Saatat haluta poistaa käytöstä esimerkiksi silloin, jos sinun on sallittava tietojen valmistelutöiden loppuunsaattaminen ennen uusien tietojen paljastamista mallin kuluttajille. Kun tämä on poissa käytöstä, voit käynnistää päivityksen manuaalisesti tai käyttämällä päivitysten ohjelmointirajapintoja. Direct Lake -mallin päivityksen käynnistäminen on halpa toiminto, jossa malli analysoi Delta Lake -taulukon uusimman version metatiedot ja päivitetään viittaamaan OneLaken uusimpiin tiedostoihin.

Huomaa, että Power BI voi keskeyttää Direct Lake -taulukoiden automaattiset päivitykset, jos päivityksen aikana ilmenee ei-rekisteröitävä virhe, joten varmista, että semanttinen mallisi voidaan päivittää onnistuneesti. Power BI jatkaa automaattisesti automaattisia päivityksiä, kun seuraava käyttäjän käynnistäma päivitys valmistuu ilman virheitä.

Monikerroksisen tietojen käytön suojaus

Lakehouse-talojen ja varastojen päälle luodut Direct Lake -mallit noudattavat lakehousejen ja varastojen tukemaa monikerroksista suojausmallia tekemällä käyttöoikeustarkistuksia T-SQL-päätepisteen kautta selvittääkseen, onko tietoja käyttävillä käyttäjätiedoilla tarvittavat tietojen käyttöoikeudet. Direct Lake -mallit käyttävät oletusarvoisesti kertakirjautumista, joten vuorovaikutteisen käyttäjän voimassa olevat käyttöoikeudet määrittävät, onko käyttäjällä tietojen käyttöoikeus vai evätty. Jos Direct Lake -malli on määritetty käyttämään kiinteitä käyttäjätietoja, kiinteiden käyttäjätietojen voimassa oleva käyttöoikeus määrittää, voivatko semanttista mallia käyttävät käyttäjät käyttää tietoja. T-SQL-päätepiste palauttaa Direct Lake -mallin sallitun tai estettyjen arvon OneLake-suojauksen ja SQL-käyttöoikeuksien yhdistelmän perusteella.

Esimerkiksi varaston järjestelmänvalvoja voi myöntää käyttäjän SELECT-käyttöoikeudet taulukkoon niin, että käyttäjä voi lukea taulukosta, vaikka käyttäjällä ei olisi OneLake-suojausoikeuksia. Käyttäjä sai valtuutetun kohteen Lakehouse/warehouse-tasolla. Vastaavasti varaston järjestelmänvalvoja voi myös kieltää käyttäjältä taulukon lukuoikeuden. Käyttäjä ei pysty lukemaan taulukosta, vaikka käyttäjällä olisi OneLake-suojauksen lukuoikeudet. DENY-lauseke ohittaa kaikki myönnetyt OneLake-suojaus- tai SQL-käyttöoikeudet. Katso seuraavasta taulukosta voimassa olevat käyttöoikeudet, jotka käyttäjä voi antaa minkä tahansa OneLake-suojauksen ja SQL-käyttöoikeuksien yhdistelmän.

OneLake-suojausoikeudet SQL-käyttöoikeudet Tehokkaat käyttöoikeudet
Salli Ei ole Salli
Ei ole Salli Salli
Salli Deny Deny
Ei ole Deny Deny

Tunnetut ongelmat ja rajoitukset

  • Oletusarvon mukaan vain Semanttisen mallin taulukot, jotka on johdettu Lakehouse- tai Warehouse-taulukoista, tukevat Direct Lake -tilaa. Vaikka mallin taulukot voidaan johtaa Lakehousen tai Warehousen SQL-näkymistä, näitä taulukoita käyttävät kyselyt palaavat DirectQuery-tilaan.

  • Semanttiset Direct Lake -mallitaulukot voidaan johtaa vain yksittäisen Lakehouse- tai Warehouse-mallin taulukoista ja näkymistä.

  • Direct Lake -taulukoita ei tällä hetkellä voi sekoittaa muiden taulukkotyyppien kanssa, kuten tuonti, DirectQuery tai kaksoistaulukko, samassa mallissa. Yhdistelmämalleja ei tällä hetkellä tueta.

  • Päivämäärä ja aika -suhteita ei tueta Direct Lake -malleissa.

  • Laskettuja sarakkeita ja laskettuja taulukoita ei tueta.

  • Joitakin tietotyyppejä ei välttämättä tueta, kuten suuren tarkkuuden desimaalit ja rahatyypit.

  • Direct Lake -taulukot eivät tue monimutkaisia Delta-taulukon saraketyyppejä. Myös semanttisia binaarisia tyyppejä ja Guid-tyyppejä ei tueta. Nämä tietotyypit on muunnettava merkkijonoiksi tai muuksi tuetuksi tietotyypiksi.

  • Taulukkosuhteet edellyttävät, että niiden avainsarakkeiden tietotyypit ajoittuvat yhteen. Perusavainsarakkeissa on oltava yksilöllisiä arvoja. DAX-kyselyt epäonnistuvat, jos perusavainarvojen kaksoiskappaleita havaitaan.

  • Merkkijonosarakearvojen pituus on rajoitettu 32 764 Unicode-merkkiin.

  • Liukulukuarvoa NaN (ei numero) ei tueta Direct Lake -malleissa.

  • Upotettuja entiteettejä käyttäviä upotettuja skenaarioita ei vielä tueta.

  • Direct Lake -mallien vahvistus on rajoitettu. Käyttäjän valintojen oletetaan olevan oikeat, eikä yksikään kysely vahvista kardinaliteettia ja ristiinsuodatuksen valintoja suhteissa tai päivämäärätaulukon valitussa päivämääräsarakkeessa.

  • Päivityshistorian Direct Lake -välilehdessä näkyvät vain Direct Lakeen liittyvät päivitysvirheet. Onnistuneet päivitykset jätetään tällä hetkellä pois.

Aloittaminen

Paras tapa aloittaa Direct Lake -ratkaisun käyttö organisaatiossasi on luoda Lakehouse-taulukko, luoda siihen Delta-taulukko ja luoda sitten Semanttinen perusmalli Lakehouselle Microsoft Fabric -työtilassasi. Lisätietoja on kohdassa Lakehousen luominen Direct Lakelle.