DirectQuery Power BI:ssä

DirectQuery Power BI:ssä antaa sinun pitää tiedot lähteessä ja hakea sitä raportoinnin aikaan sen sijaan, että tuoda ne maahan. Tässä artikkelissa kerrotaan, milloin DirectQueryä kannattaa käyttää, sen rajoitukset ja vaihtoehdot, kuten yhdistelmätaulukot, Direct Lake ja reaaliaikaiset yhteydet, jotta voit valita oikean tilan.

Tässä artikkelissa kuvataan:

• Power BI:n datayhteystilat ja mihin DirectQuery sopii
• Milloin DirectQueryä kannattaa käyttää tuontiin, yhdistelmätaulukoihin, Direct Lakeen tai reaaliaikaiseen yhteyteen verrattuna?
• Rajoitukset, vaikutukset ja suorituskykyyn liittyvät näkökohdat
• Suositukset mallintamiseen ja raporttien suunnitteluun
• Diagnosoi ja paranna suorituskykyä

Nopea päätösopas

Seuraava taulukko tiivistää, mitä Power BI:n yhteystilaa kannattaa harkita tarpeidesi perusteella. Käytä sitä pikaoppaana, jonka avulla voit valita tuonti-, DirectQuery-, yhdistelmätaulukoiden, Direct Laken tai reaaliaikaisten yhteyksien välillä:

Power BI:n datayhteystilat

Power BI yhdistää moniin tietolähteisiin:

• Verkkopalvelut kuten Salesforce ja Dynamics 365
• Tietokannat kuten SQL Server, PostgreSQL, MySQL, Oracle, Snowflake ja Amazon Redshift
• Tiedostot (Excel, CSV, JSON, Parquet)
• Big data- ja analytiikkamoduulit, kuten Spark ja Databricks
• Muita lähteitä, kuten verkkosivustot ja Microsoft Exchange

Tuo tietoja näistä lähteistä. Jotkut tukevat myös DirectQueryä. Ylläpidetyn listan löydät katsosta Power BI tietolähteet. DirectQuery-yhteensopivat lähteet tarjoavat yleensä vuorovaikutteisen koostekyselyn suorituskyvyn.

Käytä tuontia oletuksena. Se käyttää Power BI:n suorituskykyistä muistimoottoria ja tarjoaa monipuolisimman ominaisuusvalikoiman. Siirry tuonnin ulkopuolelle vain, kun tietyt rajoitukset (viive, koko, hallinto, suojaus tai arkkitehtuuri) sitä edellyttävät.

Nykyaikaiset parannukset, kuten hybriditaulukot, Direct Lake, automaattiset koosteet, yhdistelmämallit ja lisäävä päivitys, vähentävät puhtaan DirectQueryn tarvetta.

Seuraavissa osissa käsitellään tuonti-, DirectQuery- ja reaaliaikaisen yhteyden tiloja. Artikkelin loppuosa keskittyy DirectQueryyn ja tunnustaa samalla vaihtoehtoiset lähestymistavat.

Tuontiyhteydet

Kun tuot dataa:

• Hae tietovalinnat Määritä kyselyt taulukkojoukkoa kohti; Voit muotoilla ne (suodattaa, yhdistää, liittää) ennen lataamista.
• Kaikki näiden kyselyiden määrittämät tiedot ladataan semanttisen mallin muistissa olevaan välimuistiin.
• Visualisointien luominen kyselee vain välimuistiin tallennettuja tietoja – nopeasti ja täysin vuorovaikutteisesti.
• Visualisoinnit eivät heijasta lähteen muutoksia, ennen kuin päivität (tuot uudelleen).
• Julkaiseminen lataa semanttisen mallin, joka sisältää tuodut tiedot. Voit ajoittaa päivityksen (tiheys riippuu käyttöoikeudesta) ja saatat tarvita paikallisen tietoyhdyskäytävän.
• Raporttien rakentaminen tai avaaminen palvelussa käyttää tuotua dataa.
• Kiinnitetyt koontinäytön ruudut päivittyvät, kun semanttinen malli päivitetään.

DirectQuery-yhteydet

Kun käytät DirectQueryä:

• Hae tiedot muodostaa yhteyden tuettuun lähteeseen. Relaatiolähteissä voit edelleen valita taulukoita tai näkymiä. monidimensioisille lähteille (esimerkiksi SAP BW) valitaan lähdemalli.
• Tietoja ei tuoda latauksen aikana. Kukin visualisointi käynnistää yhden tai useamman kyselyn pohjana olevaan lähteeseen.
• Visuaalisen päivityksen viive riippuu täysin pohjana olevasta lähteen suorituskyvystä (ja verkon/yhdyskäytävän kuormituksesta tarvittaessa).
• Lähdetietojen muutokset tulevat näkyviin vasta uudelleenkyselyn jälkeen (siirtyminen, osittajan/suodattimen muutokset, manuaalinen päivitys).
• Julkaiseminen luo semanttisen mallin määrittelyn (rakenne ja metatiedot) ilman tuotuja tietoja.
• Palvelun raportit kysyvät lähdettä. Paikallisissa lähteissä saatetaan tarvita yhdyskäytävä.
• DirectQuery-malleihin perustuvat koontinäytön ruudut päivittyvät aikataulun mukaan, jotta ruudun tulokset tallennetaan välimuistiin koontinäytön nopeaa avaamista varten.
• Koontinäytön ruudut näyttävät viimeisimmän ajoitetun päivityksen tulokset, ellei niitä päivitetä manuaalisesti.

Reaaliaikaiset yhteydet

Elävä yhteys yhdistää Power BI:n suoraan olemassa olevaan semanttiseen malliin (esimerkiksi Analysis Services tai jokin muu julkaistu Power BI:n semanttinen malli). Se on samanlainen kuin DirectQuery (ei tuotuja tietoja), mutta semantiikkaa (kuten roolien pakotusta) käsittelee ylävirran malli. Kun muodostat yhteyden livenä:

• Täydellinen ulkoisen mallin kenttien lista ilmestyy—ei Power Query -kyselymääritelmää.
• Live-yhteydet välittävät aina käyttäjän identiteetin analyysipalveluille tai Power BI:n semanttiselle mallille turvallisuuden karsimista varten.
• Jotkin mallinnustoiminnot (kuten laskettujen taulukoiden lisääminen) eivät ole käytettävissä, koska malli on ulkoinen.

Missä DirectQuery sopii uudempien vaihtoehtojen joukkoon

DirectQuery oli ensisijainen ratkaisu erittäin suurille tai nopeasti muuttuville tiedoille, joita ei voitu tuoda tehokkaasti. Tänään:

• Yhdistelmätaulukoiden avulla voit sekoittaa muistissa olevat ja DirectQuery-osiot yhteen taulukkoon (viimeisimmät vs. historialliset).
• Direct Lake (Fabric) mahdollistaa lähes reaaliaikaisen pääsyn järvimajan pöytiin ilman perinteistä päivitystä.
• Automaattiset koosteet ja manuaaliset koostetaulukot nopeuttavat toistuvia kyselyitä.
• Reaaliaikainen lisäävä päivitys mahdollistaa viimeisimmän aikaikkunan DirectQueryn lähteen, kun taas vanhemmat tiedot tuodaan.

Arvioi nämä vaihtoehdot ennen kuin otat käyttöön täysin DirectQuery-mallin.

Reaaliaikaisissa, suurivolyymisissa aikasarjakuormissa Microsoft Fabric:llä yleinen malli on DirectQuery Fabric KQL-tietokantaan (Real-Time Intelligence) yhdistettynä lähdepuolen aggregaatioihin ja dynaamisiin M-parametreihin. Katso Kusto-pohjaiset lähdeharkinnat ohjeita tästä työkuormasta.

DirectQueryn käyttötapaukset

DirectQuery on hyödyllisin, kun:

• Tiedot muuttuvat liian usein tuontia varten (jopa inkrementaalisella päivityksellä ja ajoitetun päivityksen enimmäistiheydellä), ja tarvitset pienen viiveen näkyvyyden.
• Tietojen määrä tai hallintarajoitukset tekevät täydellisestä käsittelystä epäkäytännöllistä.
• Lähteen pakottaman suojauksen (hienorakeiset rivisäännöt) on pysyttävä hallitsevina läpiviennin kautta.
• Tietojen suvereniteetti tai sääntelysäännöt rajoittavat säilyviä täydellisiä kopioita.
• Lähde on monidimensioinen tai mittarikeskeinen (kuten SAP BW), ja palvelimen määrittämät mittarit on ratkaistava visualisointikohtaisesti.

Tiedot muuttuvat usein ja tarvitset lähes reaaliaikaista raportointia

Tuodut mallit (Pro) voivat ajoittaa enintään 8 päivitystä päivässä (sekä on-demand-/API-käynnistimet). Premium ja PPU tukevat jopa 48 ajoitettua päivitystä päivässä sekä lisäävää päivitystä ja reaaliaikaista DirectQueryä uusimmalle osiolle (hybridi). Jos vaadittua viivettä ei vieläkään voida täyttää tai täysi tuonti ei ole mahdollista, käytä DirectQueryä, yhdistelmätaulukoita tai Direct Lakea. DirectQuery-koontinäytöt voivat päivittää ruutuja jopa 15 minuutin välein.

Data on suuri

Täysi tuonti saattaa ylittää muistin tai päivitysjaksot. DirectQuery kysyy tietoja paikallaan. Jos lähde on liian hidas interaktiiviseen suorituskykyyn, harkitse seuraavaa:

• Tuodaan vain koostetut tai suodatetut osajoukot.
• Inkrementaalisen päivityksen ja koosteiden käyttäminen.
• Hybriditaulukoiden tai Direct Laken käyttäminen uusimmille ja arvokkaille segmenteille.

Katso Suuret semanttiset mallit Power BI Premiumissa hallitaksesi suuria muistitietoja.

Lähteen pakotettu suojaus

Tuonti perustuu Power BI -tunnuksiin sekä valinnaiseen rivitason tietoturvaan (RLS), joka on määritelty semanttisessa mallissa. DirectQuery voi (kun sitä tuetaan) välittää käyttäjätiedot (SSO), jotta lähde pakottaa omat suojaussääntönsä. Katso Yleiskatsaus yksittäisestä kirjautumisesta (SSO) paikallisille dataporteille Power BI.

Datasuvereniteetin rajoitukset

Kun säädökset edellyttävät, että tiedot pysyvät hallitun rajan sisällä, DirectQuery rajoittaa säilyneitä kopioita. Visuaaliset välimuistit ja ruutuvälimuistit voivat silti sisältää rajoitettuja koostettuja tietoja.

Lähde palvelimen määrittämillä mittareilla

Jotkin järjestelmät (kuten SAP BW) sisältävät semanttista logiikkaa (mittareita ja hierarkioita), jotka ratkaistaan kyselyn aikana. DirectQuery ottaa käyttöön visuaalisen tarkkuuden. Katso DirectQuery ja SAP BW sekä DirectQuery ja SAP HANA.

Lähdekohtaiset näkökohdat (mukaan lukien PostgreSQL ja MySQL)

Käyttäytyminen ja suorituskyky vaihtelevat moottoreittain:

• PostgreSQL: Lainausmerkeissä olevissa tunnisteissa kirjainkoolla on merkitystä. Varmista, että liitos- ja suodatinsarakkeissa on asianmukaiset b-puuindeksit. Vältä funktioita, jotka katkaisevat kyselyn delegoinnin lähteeseen aikaisin. Tarkista implisiittiset vedot tekstiin ja numeerisiin liitoksiin.
• MySQL: Käytä johdonmukaisia lajitteluja ja SQL-tiloja. Luo yhdistelmäindeksejä yleisiä suodatus- ja liitosmalleja varten. Suuret TEXT pylväät voivat vähentää taittumista tai pakottaa jälkikäsittelyn.
• Snowflake, BigQuery ja Databricks: Elastinen skaalaus parantaa samanaikaisuutta, mutta kylmäkäynnistysviive voi vaikuttaa ensimmäiseen kyselyyn. Lähetä lämmittelypingejä tai ajoita säännöllistä toimintaa.
• Azure Synapse, SQL ja Fabric Warehouse: Columnstore-indeksit ja tulosjoukkojen välimuisti tarjoavat vahvan vauhdin. Yhdistä ne automaattisiin koosteisiin.
• Kusto-pohjaiset lähteet (Azure Data Explorer ja Fabric KQL -tietokannat): Projektioiden karsinta on tärkeää. Valitse vain tarvittavat sarakkeet ja työnnä suodattimet ajoissa. Suurivolyymisessa aikasarjatelemetriassa käytä lähdepuolen aggregaatiota asiakaspuolen ryhmittelyn sijaan: työnnä make-series, summarize, ja series_decompose_anomalies KQL-moottoriin ja palauta kootut tulokset visuaaleihin. Varmista, että Power Query -vaiheet taittuvat natiiviksi KQL:ksi, jotta tiivistetyt tulokset — eivät raakatapahtumat — palautetaan Power BI:hen.
• SAP BW ja SAP HANA: Mittaresoluutio ja hierarkian semantiikka ohjaavat kyselykuvioita. Vältä päällekkäisiä muunnoksia, jotka estävät taittoa.

Vahvista kyselyn taittaminen (valitse View Native Query Power Query -editori), jotta muunnokset laskevat alas.

DirectQuery-rajoitukset

DirectQueryn käyttö vaikuttaa johdonmukaisuuteen, suorituskykyyn, suojaukseen, muunnoksiin, mallintamiseen ja raportointiin.

Yleiset vaikutukset

Seuraavat yleiset seuraukset pätevät DirectQueryä käytettäessä Power BI:ssä:

• Päivitä nähdäksesi uusimmat tiedot. Välimuistit (visualisointi, ruutu, tulos) tarkoittavat, että visualisointi voi näyttää aiempia tuloksia, kunnes se päivitetään. Valitse Päivitä , jos haluat pakottaa sivun kaikkien visualisointien uudelleenkyselyn.
• Visuaalinen ilme ei aina ole ajan mukainen. Eri visualisoinnit (tai yhden visualisoinnin sisäiset kyselyt) voidaan suorittaa hieman eri aikoina. Päivitä sivu tai suunnittele koostetut tilannevedokset, jos tarvitaan tiukkaa ajankohdan tarkkuutta.
• Skeemamuutokset vaativat Power BI Desktopin päivityksen. Palvelu ei tunnista automaattisesti pudonneita tai uudelleennimettyjä sarakkeita. Avaa malli Power BI Desktopissa ja päivitä, jotta mallin metatiedot sovitetaan yhteen.
• Miljoonan rivin välitulosraja. Kaikki kyselyt (tai välitoiminnot), jotka palauttavat yli 1 000 000 riviä, epäonnistuvat. Premium-kapasiteetit voivat nostaa tätä rajaa – katso Välirivin enimmäismäärä.
• Tallennustilan vaihtaminen on rajoitettua. Et voi vaihtaa vain tuonti -mallia DirectQueryyn maailmanlaajuisesti. Katso seuraava osio.

Tallennustilojen muuttaminen (Direct Queryn tuonti ↔)

Et voi vaihtaa koko tuontimallia DirectQueryyn. Sen sijaan:

• Lisää uusi DirectQuery-yhteys samaan lähteeseen ja yhdistä visualisoinnit uusiin taulukoihin.
• Luo yhdistelmämalli: säilytä Tuo dimensiot, lisää DirectQuery-faktataulukot (tai päinvastoin) ja määritä valinnaisesti jotkin taulukot kaksoistaulukoiksi.
• Käytä yhdistelmätaulukoita (viimeisimmät DirectQuery-osiot ja historiallinen tuonti) kuuma- ja kylmäoptimointiin.
• Muodosta uudelleen taittoystävällisillä muunnoksilla, jos aiemmat vaiheet estävät DirectQueryn.

Vaikutukset suorituskykyyn ja kuormitukseen

Vuorovaikutteinen suorituskyky riippuu lähteen viiveestä ja samanaikaisuudesta. Pyri yleisiin visuaalisiin päivitysaikoihin alle 5 sekunnissa; yli 30 sekuntia heikentää käytettävyyttä. Jokainen käyttäjän toiminto käynnistää kyselyt. Suuret käyttäjä-, visualisointi- ja ruutujen päivitysmäärät voivat aiheuttaa merkittävää kuormitusta – suunnittele kapasiteetti sen mukaisesti.

Vaikutukset tietoturvaan

Ellei kertakirjautumista ole määritetty, DirectQuery käyttää määritettyjä tallennettuja tunnistetietoja kaikille katselijoille. Määritä rivitason suojaus semanttisessa mallissa tarpeen mukaan. Yhdistelmämallien useat lähteet voivat siirtää tietoja lähteiden välillä. Arvioi arkaluonteisten tietojen siirtoja – katso Vaikutukset tietoturvaan.

Tietojen muunnoksen rajoitukset

Power Query -taittaminen on välttämätöntä skaalautuvan suorituskyvyn saavuttamiseksi. Muunnosten on tiivistyttävä yhdeksi alkuperäiseksi kyselyksi. Monimutkaiset vaiheet (ei-taitettavat toiminnot, tietyt mukautetut toiminnot, monivaiheinen proseduurilogiikka) voivat aiheuttaa virheitä, jotka edellyttävät yksinkertaistamista tai siirtymistä tuontiin. OLAP-lähteet, kuten SAP BW, eivät salli kyselyn sisäisiä muunnoksia, koska koko ulkoinen malli paljastuu. Tallennettuja proseduurikutsuja ja yleisiä taulukkolausekkeita (CTE) ei tueta tavalla, joka sallii delegoinnin lähteeseen DirectQueryssä.

Mallinnusrajoitukset

Useimmat rikastukset toimivat, mutta jotkin ominaisuudet ovat vähentyneet:

• Ei automaattista päivämäärähierarkiaa (luo eksplisiittinen päivämäärätaulukko).
• Ajan tarkkuus rajoitettu sekunteihin (poista millisekunnit lähteestä).
• Lasketut sarakkeet rajoittuvat rivitason lausekkeisiin, jotka taittuvat; Toimintoja, joita ei tueta, jätetään pois automaattisesta täydennyksestä.
• Ei ylätason ja lapsen PATH-funktioita.
• Klusterointia ei tueta.

Raportoinnin rajoitukset

Useimmat visualisoinnit toimivat, jos lähde reagoi. Katso nämä rajoitukset ja suorituskykyyn liittyvät seikat:

• Pitkiä yli 32 764 merkin pituisia tekstisarakkeita ei tueta.
• Mittasuodattimet, TopN-suodattimet, Medianlisäteksti sisältää/alkaa -suodattimet, monivalintaiset osittajat ja summat/välisummat (erityisesti ) DistinctCountvoivat lisätä ylimääräisiä kyselyitä tai heikentää suorituskykyä.
• Harkitse suunnittelun yksinkertaistamista tai tiettyjen vuorovaikutusten poistamista käytöstä.

Esimerkki (mittasuodatin):

DirectQuery-suositukset

Tämä osio tarjoaa käytännön suosituksia DirectQuery-mallien suunnitteluun, optimointiin ja vianetsintään Power BI:ssä. Näiden ohjeiden avulla voit parantaa suorituskykyä, luotettavuutta ja käyttökokemusta DirectQuery-yhteyksiä käsiteltäessä.

Pohjana olevan tietolähteen suorituskyky

Vahvista vuorovaikutteiset peruskyselyt. Jos ne ovat hitaita, tarkista kyselyt Suorityskyvyn analysointi -työkalulla ja optimoi lähdeskeema (indeksit, tilastot ja sarakkeikka, jos sovellettavissa). Suosi liitosten kokonaislukuavaimia.

Mallin rakenne

• Pidä Power Query -vaiheet yksinkertaisina ja taitettavina. Esikatsele "Näytä alkuperäinen kysely" usein.
• Aloita yksinkertaisilla toimenpiteillä ja iteroi sitten.
• Vältä liitoksia laskettujen lausekkeiden sarakkeissa – materialisoi ne tarvittaessa lähteessä.
• Vältä liitoksia uniqueidentifier missä heitot rikkovat indeksin käyttöä; materialisoida vaihtoehtoisia avaintyyppejä.
• Piilota korvike-/järjestelmäavaimet; Luo tarvittaessa näkyviä aliasarakkeita.
• Tarkista lasketut taulukot tai sarakkeet , jotka voivat tuottaa ei-delegoitavia lausekkeita.
• Rajoita kaksisuuntaiset suodattimet vain pakollisiin tapauksiin. Testaa suorituskykyvaikutusta.
• Harkitse Oleta viite-eheys käytön mahdollistamiseksi INNER JOIN .
• Vältä suhteellisten päivämääräsuodattimia Power Query:ssa. Ota sen sijaan käyttöön suhteellinen logiikka mallissa tai raporttikerroksessa.

Suodatusesimerkki:

Tuloksena oleva alkuperäinen kysely käyttää kiinteää literaalipäivämäärää:

Raportin suunnittelu

Kun suunnittelet DirectQueryä käyttäviä raportteja, ota huomioon seuraavat parhaat käytännöt käytettävyyden ja suorituskyvyn optimoimiseksi:

• Käytä kyselyn vähentämisasetuksia (käytä Käytä-painiketta osittajille ja suodattimille ja poista ristiinkorostaminen käytöstä, jos viive vahingoittaa käyttökokemusta).

  

• Käytä avainsuodattimia varhaisessa vaiheessa vähentääksesi välirivien määrää ja välttääksesi rajojen ylittymisen.

• Rajoita sivukohtaisia visualisointeja rinnakkaisten ja sarjoitettujen kyselyiden minimoimiseksi.

• Poista tarpeettomat vuorovaikutukset käytöstä (ristiinsuodatus tai korostaminen), jos ne käynnistävät kalliita lähdekyselyitä.

  

Yhteyksien enimmäismäärä

Säädä tiedostokohtaista DirectQuery-samanaikaisuutta (oletusarvo 10) Tiedoston > asetukset ja asetukset > DirectQuery-asetukset > nykyiselle tiedostolle.

Suuremmat arvot voivat parantaa monien visualisointien siirtonopeutta, mutta ne voivat myös lisätä lähteen kuormitusta. Julkaistu toiminta riippuu myös palvelu- tai kapasiteettirajoituksista.

Suorituskyvyn lieventämisominaisuudet

Näiden ominaisuuksien avulla voit parantaa DirectQueryn suorituskykyä:

• Automaattiset koosteet ja manuaaliset koostetaulukot: Tallenna yhteenvetotiedot välimuistiin lähdekyselyiden vähentämiseksi.
• Hybridipöydät: Ylläpidä viimeisimpiä tietoja DirectQueryn kautta, historiallisia tietoja tuonnin kautta.
• Koostetietoinen mittarirakenne: Varmista, että DAX arvioi koostekerroksessa mahdollisuuksien mukaan.
• Dynaamiset M-parametrit: Työnnä käyttäjän valinnat lähdepredikaatteihin aikaisin.
• Kyselyn ja tulosten välimuistiin tallentaminen (kapasiteettiasetukset): Käytä uusimpia tulosjoukkoja uudelleen toistuvissa visualisoinneissa.
• Jaettujen dimensiotaulukoiden kaksoistallennustila: Vähennä toistuvia etämittaskannauksia.

DirectQuery Power BI -palvelu -palvelussa

Kaikki DirectQueryn tietolähteet ovat tuettuja Power BI Desktopin kautta. Vain rajoitettu osajoukko alkaa suoraan palvelun käyttöliittymästä. Aloita Power BI Desktopista saadaksesi monipuolisemman mallinnuksen ja muunnoksen hallinnan. Nykyisen luettelon suoraan palvelussa saatavilla olevista lähteistä löytyy Power BI data sources.

Palvelun suorituskyky riippuu:

• Samanaikaisten käyttäjien määrä
• Visuaalinen monimutkaisuus ja määrä sivua kohden
• Rivitason suojaus (voi vähentää välimuistin uudelleenkäyttöä)
• Ruudun päivitysaikataulut

Ilmoita käyttäytymisestä Power BI -palvelu

Raporttisivun avaaminen suorittaa kyselyt kullekin visualisoinnille (joskus useita visualisointia kohden). Vuorovaikutukset (osittajan muutokset, ristiinkorostus, suodattimet) suorittavat kyselyt uudelleen. Palvelu tallentaa joitakin tuloksia välimuistiin. Tarkat toistuvat kyselyt voivat palata välittömästi, elleivät suojausrajat poikkea toisistaan.

Kyvykkyyden vivahteet:

• Nopeat oivallukset: Ei tueta DirectQueryn semanttisissa malleissa.
• Tutki Excel / Analysoi Excel: Tuettu, mutta voi tuntua hitaammalta. Harkitse tuontitilaa tai aggregaatioita Excel-runsaan käytön vuoksi.
• hierarkiat Excel: Jotkut DirectQueryn semanttiset mallihierarkiat eivät näytä samalta Excel:ssa.

Koontinäytön päivitys

DirectQuery-ruudut päivittyvät aikataulun mukaan. Oletusarvo on tunneittain ja voit asettaa sen 15 minuutin välein viikoittaiseksi. Rivitason suojauksen avulla jokainen käyttäjä suorittaa erilliset ruutukyselyt. Suuri ruutujen määrä kerrottuna käyttäjien määrällä ja päivitystiheydellä voi aiheuttaa suuren kuormituksen – suunnittele kapasiteettia ja harkitse koosteita.

Kyselyn aikakatkaisut

Palvelu pakottaa 4 minuutin aikakatkaisun kyselyä kohden. Rajan ylittävät visualisoinnit epäonnistuvat aikakatkaisuvirheen vuoksi. Varmista, että pohjana olevat lähteet tarjoavat vuorovaikutteisen suorituskyvyn, ennen kuin valitset DirectQueryn.

Suorituskyvyn diagnostiikka

Suorituskyvyn diagnosointi ensin Power BI Desktopissa.

Suorituskyvyn analysoinnin avulla voit eristää hitaat visualisoinnit. Keskity yhteen ongelmalliseen visualisointiin kerrallaan.

Käytä SQL Server Profileria nähdäksesi kyselyt

Power BI Desktop kirjoittaa istuntojäljityksiä, mukaan lukien DirectQuery SQL joillekin lähteille, FlightRecorderCurrent.trc-tiedostoon käyttäjän AnalysisServicesWorkspaces-kansiossa.

Jäljityksen paikantaminen:

1. Power BI Desktopissa valitse Tiedosto > Asetukset ja asetukset > Vaihtoehdot > Diagnostiikka.

2. Valitse Avaa kaatumisvedos/jäljityskansio.

   

3. Siirry yhden tason ylöspäin kohtaan AnalysisServicesWorkspaces, avaa aktiivinen työtilakansio, sitten Tiedot ja etsi FlightRecorderCurrent.trc.

4. SQL Server Profilerissa avaa tiedosto: File > Open > Trace File.

Profilointi näyttää ryhmitellyt tapahtumat:

Tapahtuman sarakkeet:

• Tekstitiedot: DAX (kyselyn alku/loppu) tai alkuperäinen SQL (DirectQuery Begin/End).
• Kesto (ms) ja EndTime auttavat paikantamaan hitaat vaiheet.
• ActivityID ryhmittelee liittyvät tapahtumat.

Sieppausohjeet:

• Pidä istunnot lyhyinä (≈10 sekuntia kohdennettuja toimintoja).
• Avaa jäljitystiedosto uudelleen, jotta voit tarkastella juuri tyhjennettyjä tapahtumia.
• Vältä useita samanaikaisia työpöytäesiintymiä sekaannusten vähentämiseksi.

Kyselyjen muodon ymmärtäminen

Power BI käyttää usein alivalintaa (johdettua taulukkoa) jokaiselle viitatulle loogiselle taululle, joka määritellään Power Query -vaiheilla.

Esimerkki kyselylogiikasta:

SalesAmount (SUMX(Web_Sales, [ws_sales_price]*[ws_quantity]))
by Item[i_category]
for Date_dim[d_year] = 2000

Tuloksena oleva visualisointi:

Luotu SQL alivalinnoilla:

Alivalintakyselymallit eivät yleensä heikennä tuettujen moduulien suorituskykyä, koska optimoijat poistavat käyttämättömät sarakkeet. Aseta taitettavuus etusijalle.

Liittyvä sisältö

• Käytä DirectQueryä Power BI Desktopissa
• DirectQuery ja SAP HANA
• DirectQuery ja SAP BW
• Käytä DirectQueryä Power BI semanttisiin malleihin ja analyysipalveluihin
• aggregaatiot Power BI
• Suorituskyvyn analysaattori
• Komposiittimallit
• Rivitason suojauksen yleiskatsaus
• Kertakirjautuminen (SSO)