DirectQuery Power BI:ssä

Power BI Desktopissa tai Power BI -palvelussa voit muodostaa yhteyden moniin eri tietolähteisiin eri tavoilla. Voit tuoda tietoja Power BI:hin, mikä on yleisin tapa hakea tietoja. Voit myös muodostaa yhteyden suoraan joihinkin tietoihin niiden alkuperäisessä lähdesäilössä, jota kutsutaan DirectQueryksi. Tässä artikkelissa käsitellään ensisijaisesti DirectQuery-ominaisuuksia.

Tässä artikkelissa kuvataan:

• Eri Power BI -tietoyhteysasetukset.
• Ohjeita DirectQueryn käyttämiseen tuonnin sijaan.
• DirectQueryn käyttämisen rajoitukset ja vaikutukset.
• DirectQueryn onnistuneen käytön suositukset.
• DirectQuery-suorituskykyongelmien vianmääritys.

Artikkelissa keskitytään DirectQuery-työnkulkuun, kun luot raportin Power BI Desktopissa, mutta myös yhteyden muodostamiseen DirectQueryn kautta Power BI -palvelussa.

Muistiinpano

DirectQuery on myös SQL Server Analysis Servicesin ominaisuus. Ominaisuus jakaa useita tietoja DirectQueryn kanssa Power BI:ssä, mutta myös niiden välillä on tärkeitä eroja. Tässä artikkelissa käsitellään pääasiassa DirectQueryä Power BI:n kanssa, ei SQL Server Analysis Servicesiä.

Lisätietoja DirectQueryn käyttämisestä SQL Server Analysis Servicesin kanssa on artikkelissa Yhdistelmämallien käyttäminen Power BI Desktopissa). Voit myös ladata PDF DirectQueryn SQL Server 2016 Analysis Servicesissä.

Power BI:n tietoyhteystilat

Power BI:llä voi muodostaa yhteyksiä moniin erilaisiin tietolähteisiin, kuten:

• Online-palvelut, kuten Salesforce ja Dynamics 365.
• Tietokannat, kuten SQL Server, Access ja Amazon Redshift.
• Yksinkertaiset tiedostot Excelissä, JSON:ssä ja muissa muodoissa.
• Muut tietolähteet, kuten Spark, sivustot ja Microsoft Exchange.

Voit tuoda tietoja näistä lähteistä Power BI:hin. Joidenkin lähteiden kohdalla voit myös muodostaa yhteyden DirectQueryn avulla. Yhteenveto DirectQueryä tukevista lähteistä on artikkelissa Power BI -tietolähteet. DirectQueryä käyttävät lähteet ovat pääasiassa lähteitä, jotka voivat tuottaa hyvää vuorovaikutteista kyselyjen suorituskykyä.

Tiedot kannattaa tuoda Power BI:hin aina, kun se on mahdollista. Tuonnissa hyödynnetään Power BI:n suorituskykyistä kyselymoduulia. Lisäksi tämä tarjoaa erittäin vuorovaikutteisen ja kattavammin suositellun käyttökokemuksen.

Jos et voi saavuttaa tavoitteitasi tuomalla tietoja, esimerkiksi jos tiedot muuttuvat usein ja raporttien täytyy sisältää uusimmat tiedot, harkitse DirectQueryn käyttöä. DirectQuery on toteuttamiskelpoinen vain silloin, kun taustalla oleva tietolähde kykenee tarjoamaan vuorovaikutteisia kyselytuloksia alle viidessä sekunnissa tyypillisille koostekyselyille ja kykenee käsittelemään luodun kyselykuormituksen. Harkitse tarkemmin DirectQueryn käyttämisen rajoituksia ja vaikutuksia.

Power BI:n tuonti- ja DirectQuery-ominaisuudet kehittyvät ajan myötä. Jos muutoksia on enemmän joustavuutta tuotujen tietojen käytölle, voit tuoda niitä useammin ja poistaa joitakin DirectQueryn käytön varjopuolia. Parannuksista riippumatta taustalla olevan tietolähteen suorituskyky on merkittävä huomioiva seikka DirectQuerya käytettäessä. Jos taustalla oleva tietolähde on hidas, DirectQueryn käyttäminen tämän lähteen kanssa on edelleen mahdotonta.

Seuraavissa osioissa käsitellään näitä kolmea eri vaihtoehtoa tietoihin yhdistämiseksi: tuonti, DirectQuery ja reaaliaikainen yhteys. Artikkelin loppuosassa keskitytään DirectQueryun.

Tuontiyhteydet

Kun muodostat yhteyden tietolähteeseen, kuten SQL Serveriin, ja tuot tietoja Power BI Desktopiin, seuraavat yhteysehdot täyttyvät:

• Kun käytät aluksi Nouda tiedot -komentoa, jokainen valitsemasi taulukkojoukko määrittää kyselyn, joka palauttaa tietojoukon. Voit muokata kyseisiä kyselyitä ennen tietojen lataamista. Voit esimerkiksi käyttää suodattimia, koostaa tietoja tai liittää eri taulukoita.

• Ladattaessa kaikki tiedot, jotka kyselyt määrittävät, tuodaan Power BI:n välimuistiin.

• Visualisoinnin luominen Power BI Desktopissa tekee kyselyjä välimuistiin tallennetuille tiedoille. Power BI -säilö varmistaa, että kysely on nopea ja että kaikki visualisointiin tehdyt muutokset näkyvät heti.

• Visualisoinnit eivät vastaa tietosäilön pohjana olevien tietojen muutoksia. Sinun on saatava tieto päivittymään uudelleen.

• Raportin julkaiseminen Power BI -palveluun .pbix-tiedostona luo ja lataa semanttisen mallin, joka sisältää tuodut tiedot. Voit sitten ajoittaa tietojen päivittämisen, jos haluat esimerkiksi tuoda tiedot uudelleen päivittäin. Alkuperäisen tietolähteen sijainnista riippuen sinun täytyy ehkä määrittää paikallinen tietoyhdyskäytävä päivitystä varten.

• Jos avaat aiemmin luodun raportin tai luot uuden raportin Power BI -palvelussa, tuodut tiedot kyselyihin uudelleen, mikä takaa vuorovaikutteisuuden.

• Voit kiinnittää visualisointeja tai kokonaisia raporttisivuja koontinäytön ruutuina Power BI -palvelussa. Ruudut päivittyvät automaattisesti aina, kun taustalla oleva semanttinen malli päivittyy.

DirectQuery-yhteydet

Kun käytät DirectQueryä yhteyden muodostamiseen tietolähteeseen Power BI Desktopissa, seuraavat tietoyhteysehdot täyttyvät:

• Valitset lähteen Nouda tiedot -valikon avulla. Suhteellisia tietolähteitä varten voit silti valita joukon taulukoita, jotka määrittävät kyselyn, joka palauttaa loogisesti tietojoukon. Jos käytät SAP Business Warehousen (SAP BW) kaltaista monidimensioista lähdettä, valitset vain lähteen.

• Ladattaessa mitään tietoja ei tuoda Power BI -säilöön. Kun luot visualisoinnin, Power BI Desktop lähettää sen sijaan kyselyjä pohjana olevaan tietolähteeseen tarvittavien tietojen noutamista varten. Visualisoinnin päivittämiseksi kuluva aika riippuu pohjana olevan tietolähteen suorituskyvystä.

• Mitkään taustalla olevien tietojen muutokset eivät näy heti olemassa olevissa visualisoinneissa. Päivittäminen on yhä tarpeen. Power BI Desktop lähettää tarvittavat kyselyt uudelleen kullekin visualisoinnille ja päivittää visualisoinnin tarvittaessa.

• Raportin julkaiseminen Power BI -palveluun luo ja lataa semanttisen mallin, kuten tietoja tuotaessa. Kyseinen semanttinen malli ei kuitenkaan sisällä tietoja.

• Aiemmin luodun raportin avaaminen tai uuden raportin luominen Power BI -palvelussa tekee kyselyjä pohjana olevaan tietolähteeseen tarvittavien tietojen noutamiseksi. Alkuperäisen tietolähteen sijainnista riippuen sinun täytyy ehkä määrittää paikallinen tietoyhdyskäytävä tietojen noutamista varten.

• Voit kiinnittää visualisointeja tai kokonaisia raporttisivuja koontinäytön ruutuina. Koontinäytön avaamisen latauksen takaamiseksi ruudut päivittyvät automaattisesti aikataulun mukaan, esimerkiksi kerran tunnissa. Voit hallita päivitystiheyttä sen mukaan, kuinka usein tiedot muuttuvat ja kuinka tärkeää uusimpien tietojen näkeminen on.

• Kun avaat koontinäytön, ruudut kuvastavat tietoja viimeisimmän päivityksen ajankohdalta, eivät välttämättä taustalla olevan tietolähteen uusimpien tietojen mukaisesti. Voit päivittää avoimen koontinäytön varmistaaksesi, että se on ajan tasalla.

Reaaliaikaiset yhteydet

Kun muodostat yhteyden SQL Server Analysis Servicesiin, voit joko tuoda tiedot tai käyttää reaaliaikaista yhteyttä valittuun tietomalliin. Reaaliaikaisen yhteyden käyttäminen vastaa DirectQueryn käyttöä. Tietoja ei tuoda, ja pohjana olevaan tietolähteeseen tehdään kysely visualisointien päivittämiseksi.

Kun esimerkiksi käytät tuontia yhteyden muodostamiseksi SQL Server Analysis Servicesiin, määrität kyselyn ulkoiselle SQL Server Analysis Services -lähteelle ja tuot tiedot. Jos muodostat reaaliaikaisen yhteyden, et määritä kyselyä, ja koko ulkoinen malli näkyy Kentät-luettelossa.

Tämä tilanne pätee myös, kun muodostat yhteyden seuraaviin lähteisiin, mutta tietojen tuominen ei ole vaihtoehtona:

• Semanttiset Power BI -mallit, esimerkiksi yhteyden muodostaminen palveluun jo julkaistuun Power BI -semanttiseen malliin, jotta voit luoda uuden raportin siitä.

• Microsoft Dataverse.

Kun julkaiset SQL Server Analysis Services -raportteja, jotka käyttävät reaaliaikaisia yhteyksiä, Power BI -palvelu toimii samankaltaisesti kuin DirectQuery-raportit seuraavin tavoin:

• Aiemmin luodun raportin avaaminen tai uuden raportin luominen Power BI -palvelussa tekee kyselyjä pohjana olevasta SQL Server Analysis Services -lähteestä, mikä saattaa vaatia paikallista tietoyhdyskäytävää.

• Koontinäytön ruudut päivittyvät automaattisesti aikataulun mukaan, esimerkiksi kerran tunnissa.

Myös reaaliaikainen yhteys eroaa DirectQuerystä useilla tavoilla. Esimerkiksi reaaliaikaiset yhteydet välittävät aina raportin avaavan käyttäjän käyttäjätiedot pohjana olevaan SQL Server Analysis Services -lähteeseen.

DirectQueryn käyttötapaukset

Yhteyden muodostaminen DirectQueryllä voi olla hyödyllistä seuraavissa tilanteissa. Monissa näissä tapauksissa tietojen jättäminen alkuperäiseen lähdesijaintiin on välttämätöntä tai hyödyllistä.

Power BI:n DirectQuery tarjoaa suurimmat edut seuraavissa skenaarioissa:

• Tiedot muuttuvat usein, ja tarvitset lähes reaaliaikaista raportointia.
• Sinun on käsiteltävä suuria tietoja ilman esikoostetussa koostamista.
• Taustalla oleva lähde määrittää ja soveltaa suojaussääntöjä.
• Voimassa on tietojen suvereniteettirajoituksia.
• Lähde on monidimensioinen lähde, joka sisältää mittareita, kuten SAP BW.

Tiedot muuttuvat usein, ja tarvitset lähes reaaliaikaista raportointia.

Voit päivittää tuotuja tietoja sisältävät mallit vähintään kerran tunnissa tai useammin Power BI Pro- tai Power BI Premium -tilauksilla. Jos tiedot muuttuvat jatkuvasti ja raporttien täytyy näyttää uusimmat tiedot, tietojen tuominen ja ajoitetut päivitykset eivät ehkä vastaa tarpeitasi. Voit suoratoistaa tietoja suoraan Power BI:hin, vaikka tässä tapauksessa tuettujen tietojen määrällä on rajoituksia.

DirectQueryn käyttö tarkoittaa sitä, että raportin tai koontinäytön avaaminen tai päivittäminen näyttää aina uusimmat tiedot lähteestä. Koontinäytön ruutuja voi myös päivittää useammin, jopa 15 minuutin välein.

Tietoja on erittäin paljon.

Jos tietoja on erittäin paljon, kaikkien tietojen tuominen ei ole järkevää. DirectQuery ei vaadi suuren tietomäärän siirtämistä, koska se tekee kyselyjä paikoillaan olevista tiedoista. Jos tietoja on erittäin paljon, kyselyt taustalla olevaan tietolähteeseen saattavat kuitenkin myös hidastua.

Sinun ei aina tarvitse tuoda täydellisiä, yksityiskohtaisia tietoja. Power Query -editorin avulla on helppo esikoosttaa tietoja tuonnin aikana. Teknisesti on mahdollista tuoda juuri ne koostetiedot, joita tarvitset kullekin visualisoinnille. Vaikka DirectQuery on yksinkertaisin tapa, kun tietoja on paljon, koostetietojen tuominen voi olla ratkaisu, jos taustalla oleva tietolähde on liian hidas DirectQuerylle.

Nämä tiedot liittyvät pelkästään Power BI:n käyttöön. Lisätietoja suurten mallien käyttämisestä Power BI:ssä on artikkelissa Suuret semanttiset mallit Power BI Premiumissa. Tietojen päivitysvälille ei ole rajoituksia.

Taustalla oleva lähde määrittää suojaussäännöt

Kun tuot tietoja, Power BI muodostaa yhteyden tietolähteeseen nykyisen käyttäjän Power BI Desktop -tunnistetiedoilla tai Power BI -palvelussa ajoitetulle päivitykselle määritetyillä tunnistetiedoilla. Kun julkaiset ja jaat raportteja, jotka ovat tuoneet tietoja, sinun täytyy olla varovainen, että jaat vain niille käyttäjille, joilla on lupa tarkastella tietoja. Tai rivitason suojaus on määritettävä osana semanttista mallia.

DirectQuery mahdollistaa raportin katselijan tunnistetietojen välittämisen taustalla olevaan lähteeseen, joka soveltaa suojaussääntöjä. DirectQuery tukee kertakirjautumista (SSO) Azure SQL -tietolähteisiin ja tietoyhdyskäytävän kautta paikallisiin SQL-palvelimiin. Lisätietoja on artikkelissa Yleiskatsaus kertakirjautumiseen (SSO) paikallisissa tietoyhdyskäytäviä varten Power BI:ssä.

Voimassa on tietojen suvereniteettirajoituksia.

Joillakin organisaatioilla on käytäntöjä tietojen suvereniteettiin nähden, mikä tarkoittaa sitä, että tietoja ei voi siirtää organisaation paikallisesti. Nämä tiedot esittelevät tietojen tuontiin perustuvia ratkaisuja koskevia ongelmia. DirectQueryä käytettäessä tiedot pysyvät pohjana olevassa lähdesijainnissa. Myös DirectQueryä käytettäessä Power BI -palvelu kuitenkin säilyttää joitakin tietojen välimuisteja visualisointitasolla ruutujen ajoitetun päivityksen vuoksi.

Pohjana oleva tietolähde käyttää mittareita

Taustalla oleva tietolähde, kuten SAP HANA tai SAP BW, sisältää mittareita. Mittarit tarkoittavat sitä, että tuodut tiedot ovat jo tietyllä koostamistasolla kyselyn määrittämällä tavalla. Visualisointi, joka pyytää tietoja korkeammalta koostetasolta, kuten kokonaismyynti vuoden mukaan, koostaa koostearvoa edelleen. Koostaminen ei ole ongelma lisääville mittareille, kuten Summa ja Vähimmäisarvo, mutta se voi olla ongelma mittareille, jotka eivät ole lisääviä, kuten Keskiarvo ja Erillisten määrä.

Visualisoinnille tarvittavien koostetietojen helppo saaminen suoraan lähteestä edellyttää kyselyjen lähettämistä visualisointikohtaisesti, kuten DirectQueryssä. Kun muodostat yhteyden SAP BW:hen, voit käsitellä mittareita tällä tavalla valitsemalla DirectQueryn. Katso lisätietoja artikkelista DirectQuery ja SAP BW.

Kun käytät DirectQueryä SAP HANAn kanssa, tiedot käsitellään tällä hetkellä samoin kuin relaatiolähdettä, ja tiedot käyttäytyvät samalla tavalla kuin tietoja tuotaessa. Katso lisätietoja artikkelista DirectQuery ja SAP HANA.

DirectQuery-rajoitukset

DirectQueryn käytöllä on mahdollisesti kielteisiä vaikutuksia. Jotkin näistä rajoituksista vaihtelevat hieman käyttämäsi lähteen mukaan. Seuraavissa osioissa luetellaan DirectQueryn yleisvaikutuksia sekä suorituskykyyn, suojaukseen, muunnoksiin, mallinnukseen ja raportointiin liittyviä rajoituksia.

Yleiset vaikutukset

DirectQueryn käyttöön liittyviä yleisiä huomioitavia seikkoja ja rajoituksia ovat seuraavat:

• Jos tiedot muuttuvat, tiedot on päivitettävä, jotta näet uusimmat tiedot. Välimuistien käytöstä huolimatta ei ole mitään takeita sille, että visualisoinnit näyttävät aina uusimmat tiedot. Visualisointi voi esimerkiksi näyttää edellisen päivän tapahtumat. Osittajan muutos saattaa päivittää visualisoinnin näyttämään kahden edellisen päivän tapahtumat, mukaan lukien äskettäin saapuneet tapahtumat. Osittajan palauttaminen alkuperäiseen arvoonsa voi taas tuoda välimuistiin tallennetun edellisen arvon. Valitse Päivitä , jos haluat tyhjentää kaikki välimuistit ja päivittää sivun kaikki visualisoinnit, jotta näet uusimmat tiedot.

• Jos tiedot muuttuvat, visualisointien välistä johdonmukaisuutta ei taata. Eri visualisointeja voidaan päivittää eri aikoihin riippumatta siitä, ovatko ne samalla sivulla vai eri sivuilla. Jos taustatietolähteen tiedot muuttuvat, ei ole mitään takeita sille, että jokainen visualisointi näyttää tiedot samanaikaisesti.

  Koska yksittäinen visualisointi voi edellyttää useita kyselyitä, esimerkiksi tarkempien tietojen ja kokonaissumman hakemiseksi, edes yksittäisen visualisoinnin johdonmukaisuutta ei voida taata. Johdonmukaisuuden takaaminen edellyttäisi sitä, että kaikki visualisoinnit päivitettäisiin taustatietolähteestä aina, kun mitä tahansa visualisointia päivitetään, ja lisäksi tämä edellyttäisi kalliita ominaisuuksia, kuten tilannevedoksen eristämistä.

  Voit kuitenkin suuressa määrin ratkaista ongelman päivittämällä sivun kaikki visualisoinnit valitsemalla Päivitä . Tuontitilassakin on samankaltainen ongelma johdonmukaisuuden säilyttämisessä, kun tuot tietoja useista taulukoista.

• Sinun on päivitettävä Power BI Desktopissa, jotta rakennemuutokset näkyvät. Kun raportti on julkaistu, Power BI -palvelussa päivitys päivittää raportin visualisoinnit. Mutta jos pohjana oleva lähderakenne muuttuu, Power BI -palvelu ei päivitä automaattisesti käytettävissä olevien kenttien luetteloa. Jos taustalähteestä poistetaan taulukoita tai sarakkeita, kysely saattaa epäonnistua päivitettäessä. Jos haluat päivittää mallin kentät vastaamaan muutoksia, sinun on avattava raportti Power BI Desktopissa ja valittava Päivitä.

• Minkä tahansa kyselyn voi palauttaa enintään miljoona riviä. Yhdellä taustatietolähteen kyselyllä on kiinteä 1 miljoonan rivin rajoitus. Rajalla ei yleensä ole käytännöllisiä vaikutuksia, sillä visualisoinnit eivät näytä näin montaa pistettä. Tämä rajoitus saattaa kuitenkin ilmetä tapauksissa, joissa Power BI ei optimoi täysin lähetettävien kyselyiden tuloksia ja pyytää jotain välitulosta, joka ylittää tämän rajoituksen.

  Raja voi ilmetä myös visualisointia luotaessa, kun se ei ole vielä lopullisessa muodossaan. Esimerkiksi asiakkaiden ja kokonaismyyntimäärän sisällyttäminen voi saavuttaa tämän rajoituksen, jos asiakkaita on yli miljoona, ennen kuin käytät suodatinta. Virhe, joka palauttaa seuraavan: Ulkoisen tietolähteen kyselyn tulosjoukko on ylittänyt suurimman sallitun koon, joka on 1000000 riviä.

  Muistiinpano

  Premium-kapasiteettien avulla voit ylittää miljoonan rivin rajoituksen. Lisätietoja on kohdassa Välirivien enimmäismäärä.

• Mallia ei voi muuttaa tuontitilasta DirectQuery-tilaan. Voit vaihtaa mallin DirectQuery-tilasta tuontitilaan, jos tuot kaikki tarvittavat tiedot. DirectQuery-tilaan ei voi vaihtaa takaisin, pääasiassa siksi, että DirectQuery-tila ei tue tätä ominaisuusjoukkoa. Sap BW:n kaltaisissa monidimensioisissa lähteissä et voi vaihtaa DirectQuery-tilasta tuontitilaan, koska ulkoisia mittareita käsitellään eri tavalla.

Vaikutukset suorituskykyyn ja kuormitukseen

Kun käytät DirectQueryä, yleinen käyttökokemus riippuu pohjana olevan tietolähteen suorituskyvystä. Jos kunkin visualisoinnin päivittäminen esimerkiksi osittajan arvon muuttamisen jälkeen kestää alle viisi sekuntia, käyttökokemus on kohtuullinen, vaikka se saattaa tuntua hitaalta verrattuna välittömään vasteeseen tuotujen tietojen kanssa. Jos lähteen hitaus aiheuttaa sen, että yksittäisten visualisointien päivittyminen kestää yli kymmeniä sekunteja, kokemus muuttuu kohtuuttoman huonoksi. Kyselyt saattavat jopa aikakatkaista.

Taustalla olevan tietolähteen tehokkuuden lisäksi lähteeseen kohdistuva kuormitus vaikuttaa myös suorituskykyyn. Jokainen käyttäjä, joka avaa jaetun raportin, ja jokainen päivittyvä koontinäytön ruutu lähettää pohjana olevaan lähteeseen vähintään yhden kyselyn visualisointia kohden. Lähteen on pystyttävä suoriutumaan tällaisesta kuormituksesta siten, että sen suorituskyky pysyy kohtuullisena.

Vaikutukset tietoturvaan

Ellei taustalla oleva tietolähde käytä kertakirjautumista, DirectQuery-raportti käyttää aina samoja kiinteitä tunnistetietoja yhteyden muodostamiseen lähteeseen, kun se on julkaistu Power BI -palveluun. Heti kun olet julkaissut DirectQuery-raportin, sinun on määritettävä käyttäjän tunnistetiedot käytettäväksi. Raportin avaaminen Power BI -palvelussa ennen tunnistetietojen määrittämistä aiheuttaa virheen.

Kun olet antanut käyttäjän tunnistetiedot, Power BI käyttää näitä tunnistetietoja raportin avaaville käyttäjille samalla tavalla kuin tuoduille tiedoille. Jokainen käyttäjä näkee samat tiedot, ellei rivitason suojausta ole määritetty osana raporttia. Sinun on kiinnitettävä samaa huomiota raportin jakamiseen kuin tuotuihin tietoihin, vaikka taustalla olevassa lähteessä olisi määritetty suojaussääntöjä.

• Yhteyden muodostaminen Power BI:n semanttisiin malleihin ja Analysis Servicesiin DirectQuery-tilassa käyttää aina kertakirjautumista, joten suojaus vastaa reaaliaikaisia yhteyksiä Analysis Servicesiin.

• Vaihtoehtoisia tunnistetietoja ei tueta luotaessa DirectQuery-yhteyksiä SQL Serveriin Power BI Desktopista. Voit käyttää nykyisiä Windows-tunnistetietojasi tai tietokannan tunnistetietojasi.

• Voit käyttää useita tietolähteitä DirectQuery-mallissa yhdistelmämallien avulla. Kun käytät useita tietolähteitä, on tärkeää ymmärtää tietoturvavaikutukset siitä, miten tiedot siirtyvät edestakaisin pohjana olevien tietolähteiden välillä.

Tietojen muunnoksen rajoitukset

DirectQuery rajoittaa tietojen muunnoksia, joita voit käyttää Power Query -editorissa. Tuotujen tietojen avulla voit helposti käyttää kehittyneitä muunnossarjoja, joiden avulla voit puhdistaa tietoja ja muotoilla niitä uudelleen, ennen kuin käytät niitä visualisointien luomiseen. Voit esimerkiksi jäsentää JSON-tiedostoja tai pivotoida tietoja sarakkeesta rivilomakkeeseen. Nämä muunnokset ovat rajoitetumpia DirectQueryssä.

Kun muodostat yhteyden SAP BW:n kaltaiseen online-analyyttisen käsittelyn lähteeseen, et voi määrittää mitään muunnoksia, ja koko ulkoinen malli on otettu lähteestä. Jos käytät SQL Serverin kaltaista suhteellista lähdettä, voit silti määrittää joukon muunnoksia per kysely, mutta näitä muunnoksia rajoitetaan suorituskykysyistä.

Mitkä tahansa muunnokset on otettava käyttöön jokaisessa kyselyssä taustalähteeseen (sen sijaan, että niitä olisi kerran päivitettävä). Muunnosten on pystyttävä kohtuullisesti kääntämään yhdeksi alkuperäiseksi kyselyksi. Jos käytät liian monimutkaista muunnoksia, saat virheilmoituksen, jossa sanotaan, että joko muunnos on poistettava tai yhteysmalli on vaihdettava tuontimalliin.

Lisäksi Nouda tiedot -valintaikkuna tai Power Query -editori käyttää alivalintoja luomissaan kyselyissä ja lähettää niitä visualisoinnin tietojen noutamiseen. Power Query -editorissa määritettyjen kyselyiden on oltava kelvollisia tässä kontekstissa. Et etenkään voi käyttää kyselyä, joka käyttää yleisiä taulukkolausekkeita tai kutsuu tallennettuja toimintasarjoja.

Mallinnusrajoitukset

Tässä kontekstissa mallinnus tarkoittaa raakatietojen tarkentamista ja täydentämistä osana raportin luomista tietojen avulla. Esimerkkejä mallinnuksen käytöstä ovat seuraavat:

• Suhteiden määrittäminen taulukoiden välillä.
• Uusien laskutoimitusten, kuten laskettujen sarakkeiden ja mittareiden, lisääminen.
• Sarakkeiden ja mittarien piilottaminen sekä nimeäminen uudelleen.
• Hierarkioiden määrittäminen
• Sarakkeen muotoilun määrittäminen, oletusyhteenveto ja lajittelujärjestys.
• arvojen ryhmittely tai klusterointi.

Voit edelleen hyödyntää monia näistä mallin rikastuksista DirectQueryä käytettäessä ja voit käyttää periaatetta raakatietojen rikastamiseen myöhemmän kulutuksen parantamiseksi. Jotkin mallinnusominaisuudet eivät kuitenkaan ole käytettävissä tai niitä on rajoitettu DirectQuerylla. Rajoituksia sovelletaan suorituskykyongelmien välttämiseksi.

Seuraavat rajoitukset ovat yleisiä kaikille DirectQuery-lähteille. Yksittäisiin lähteisiin voi liittyä lisää rajoituksia.

• Ei sisäistä päivämäärähierarkiaa: Tuotujen tietojen yhteydessä jokaisella päivämääräsarakkeella ja päivämäärän ja kellonajan sarakkeella on oletusarvoisesti käytettävissä sisäinen hierarkia. Jos tuot esimerkiksi myyntitilaustaulukon, joka sisältää orderDate-sarakkeen, ja käytät OrderDate-päivämäärää visualisoinnissa, voit valita käytettävän päivämäärätason, kuten vuoden, kuukauden tai päivän. Tämä sisäinen päivämäärähierarkia ei ole käytettävissä DirectQueryllä. Jos taustalla olevassa lähteessä on käytettävissä päivämäärätaulukko , kuten monissa tietovarastoissa on, voit käyttää DAX (Data Analysis Expressions) -aikatietofunktioita tavalliseen tapaan.

• Päivämäärän ja ajan tuki vain sekuntien tasolla: Aika-sarakkeita käyttävissä semanttisissa malleissa Power BI lähettää kyselyt taustalla olevaan DirectQuery-lähteeseen vain sekuntien tietotasolle asti, ei millisekunteihin. Poista millisekunnit lähdesarakkeista.

• Laskettujen sarakkeiden rajoitukset: Lasketut sarakkeet voivat olla vain rivin sisäisiä, eli ne voivat viitata vain saman taulukon muiden sarakkeiden arvoihin ilman mitään koostefunktioita. Lisäksi sallitut DAX-skalaarifunktiot, kuten LEFT(), on rajoitettu niihin funktioihin, jotka voidaan lähettää pohjana olevaan lähteeseen. Funktiot vaihtelevat lähteen ominaisuuksista riippuen. Funktioita, joita ei tueta, ei näytetä automaattisessa täydennyksessä, kun kirjoitat lasketun sarakkeen DAX-kyselyä. Jos annat funktion, jota ei tueta, saat virheilmoituksen.

• Ei tukea pää- ja alielementti-DAX-funktioille: DirectQuery-tilassa ei ole mahdollista käyttää funktioperhettä DAX PATH() , joka tavallisesti käsittelee pää- ja alielementtirakenteita, kuten tilikaavioita tai työntekijähierarkioita.

• Ei klusterointia: Kun käytät DirectQueryä, et voi etsiä ryhmiä automaattisesti klusterointitoiminnon avulla.

Raportoinnin rajoitukset

DirectQuery-malleissa tuetaan lähes kaikkia raportointitoimintoja. Voit käyttää samoja visualisointeja kuin tuodut tiedot, kunhan taustalla oleva lähde tarjoaa sopivan suoritustason.

Eräs yleinen rajoitus on, että DirectQuery-semanttisten mallien tekstisarakkeen tietojen enimmäispituus on 32 764 merkkiä. Pidempien tekstien raportointi aiheuttaa virheen.

Seuraavat Power BI -raportointiominaisuudet voivat aiheuttaa suorituskykyongelmia DirectQuery-pohjaisissa raporteissa:

• Mittarisuodattimet: Mittareita tai sarakkeiden koosteita käyttävät visualisoinnit voivat sisältää suodattimia näille mittareille. Seuraavassa kuvassa näytetään myyntiluokan mukaan (SalesAmount by Category), mutta vain luokissa, joiden myynti on vähintään 20 miljoonaa .

  

  Tämän lähestymistavan vuoksi taustalähteeseen lähetetään kaksi kyselyä:

  • Ensimmäinen kysely hakee luokat, jotka täyttävät yli 20 miljoonan myyntimäärän ehdon.
  • Toinen kysely noutaa visualisoinnissa tarvittavat tiedot, jotka sisältävät ehdon täyttäneet WHERE luokat.

  Tämä menetelmä toimii yleensä hyvin, jos luokkia on satoja tai tuhansia, kuten tässä esimerkissä. Suorituskyky voi heikentyä, jos luokkia on paljon enemmän. Kysely epäonnistuu, jos luokkia on yli miljoona.

• Ylimmät N -suodattimet: Voit määrittää lisäsuodattimia suodattamaan vain ylimmät tai alimmat N arvot, jotka on luokiteltu jonkin mittarin mukaan. Suodattimet voivat esimerkiksi sisältää kymmenen ylintä luokkaa. Tämä menetelmä lähettää taas kaksi kyselyä taustalähteeseen. Ensimmäinen kysely kuitenkin palauttaa kaikki luokat taustalähteestä, ja sitten - TopN luokat määritetään palautettujen tulosten perusteella. Käytetyn sarakkeen kardinaliteetista riippuen tämä menetelmä voi johtaa suorituskykyongelmiin tai kyselyn epäonnistumiseen, jos kyselyn tuloksille on rajattu miljoona riviä.

• Mediaani: Mikä tahansa kooste, kuten Sum tai Count Distinct, lähetetään pohjana olevaan lähteeseen. median Pohjana oleva lähde ei kuitenkaan yleensä tue koostetta. -kohteelle mediantiedot noudetaan taustalähteestä ja mediaani lasketaan palautetuista tuloksista. Tämä menetelmä toimii kohtuullisesti mediaanin laskemiseksi kohtuullisen pienestä tulosmäärästä.

  Suorituskykyyn liittyviä ongelmia tai kyselyvirheitä voi ilmetä, jos kardinaliteetti on suuri miljoonan rivin rajoituksen vuoksi. Esimerkiksi kyselyt maan tai alueen mediaanin asukasmäärästä saattavat olla kohtuullisia, mutta myyntihinnan mediaanin hakeminen ei välttämättä ole kohtuullista.

• Kehittyneet tekstisuodattimet, kuten sisältää: Tekstisarakkeen lisäsuodatus mahdollistaa esimerkiksi contains ja begins with-suodattimet. Nämä suodattimet voivat heikentää suorituskykyä joissain tietolähteissä. Älä erityisesti käytä oletussuodatinta contains , jos tarvitset tarkan vastineen. Vaikka tulokset voivat olla samoja todellisista tiedoista riippuen, suorituskyky voi poiketa merkittävästi indeksien vuoksi.

• Usean osittajan valinta: Osittajat sallivat oletusarvoisesti vain yhden valinnan. Monivalinnan salliminen suodattimissa voi aiheuttaa suorituskykyongelmia. Jos käyttäjä esimerkiksi valitsee kymmenen kiinnostavaa tuotetta, jokainen uusi valinta johtaa lähteeseen lähetttäytyihin kyselyihin. Vaikka käyttäjä voikin valita seuraavan kohteen ennen kyselyn valmistumista, tämä menetelmä aiheuttaa lisäkuormitusta pohjana olevalle lähteelle.

• Taulukon visualisointien summat: Taulukot ja matriisit näyttävät oletusarvoisesti kokonaissummat ja välisummat. Monissa tapauksissa tällaisten summien arvojen saaminen edellyttää erillisten kyselyiden lähettämistä pohjana olevaan lähteeseen. Tämä vaatimus pätee aina, kun käytät DistinctCount koostetta tai kaikissa tapauksissa, joissa käytät DirectQueryä SAP BW:n tai SAP HANAn kanssa. Voit poistaa tällaiset summat käytöstä Muotoile-ruudussa.

DirectQuery-suositukset

Tässä osiossa on korkean tason ohjeita DirectQueryn onnistuneeseen käyttöön sen vaikutusten mukaisesti.

Pohjana olevan tietolähteen suorituskyky

Varmista, että yksinkertaiset visualisoinnit päivittyvät viiden sekunnin kuluessa kohtuullisen vuorovaikutteisen käyttökokemuksen tarjoamiseksi. Jos visualisointien päivittäminen kestää yli 30 sekuntia, on todennäköistä, että raportin julkaisemisen jälkeen ongelmat tekevät ratkaisusta käyttökelvottoman.

Jos kyselyt toimivat hitaasti, tarkista taustalähteeseen lähetetyt kyselyt ja syy hitaaseen suorituskykyyn. Lisätietoja on artikkelissa Suorituskyvyn diagnostiikka.

Tässä artikkelissa ei käsitellä tietokannan optimointisuosituksia, jotka koskevat kaikkia mahdollisia pohjana olevia tietolähteitä. Seuraavat vakiotietokantakäytännöt koskevat useimpia tilanteita:

• Jotta suorituskyky olisi parempi, perusta suhteet kokonaislukusarakkeisiin sen sijaan, että liiisivät muiden tietotyyppien sarakkeita.

• Luo soveltuvat indeksit. Indeksien luonti tarkoittaa yleensä sarakesäilöindeksien käyttämistä lähteissä, jotka tukevat niitä, esimerkiksi SQL Server.

• Päivitä kaikki lähteen tarvittavat tilastot.

Mallin rakenne

Kun määrität mallia, noudata seuraavia ohjeita:

• Vältä monimutkaisia kyselyitä Power Query -editorissa. Power Query -editori kääntää monimutkaisen kyselyn yksittäiseksi SQL-kyselyksi. Yksittäinen kysely näkyy jokaisen kyseiseen taulukkoon lähetetyn kyselyn alivalintaan. Jos tämä kysely on monimutkainen, jokainen lähetettävä kysely saattaa toimia hitaasti. Saat vaihejoukon varsinaisen SQL-kyselyn napsauttamalla viimeistä vaihetta hiiren kakkospainikkeella Power Query -editorin Käytössä olevat vaiheet -kohdassa ja valitsemalla Näytä alkuperäinen kysely.

• Pidä mittarit yksinkertaisina. Rajoita mittarit ainakin aluksi yksinkertaisiin koosteihin. Jos mittarit toimivat tyydyttävästi, voit määrittää monimutkaisempia mittareita, mutta kiinnitä huomiota suorituskykyyn.

• Vältä suhteita lasketuissa sarakkeissa. Tietokannoissa, joissa on tehtävä monisarakkeisia liitoksia, Power BI ei salli suhteiden perustamista useisiin sarakkeisiin perusavaimena tai viiteavaimena. Yleensä tämän voi kiertää ketjuttamalla sarakkeet lasketulla sarakkeella ja perustamalla liitokset tähän sarakkeeseen.

  Tämä kiertotapa toimii kohtuullisesti tuoduille tiedoille, mutta DirectQueryn kohdalla se aiheuttaa liitoksen lausekkeessa. Tämä tulos yleensä estää indeksien käyttämisen ja johtaa heikkoon suorituskykyyn. Ainoa vaihtoehtoinen menetelmä on muodostaa useiden sarakkeiden tiedot yhteen sarakkeeseen pohjana olevassa tietolähteessä.

• Vältä suhteita uniqueidentifier-sarakkeissa. Power BI ei suoraan tue tietotyyppiä uniqueidentifier . Jos määrität yhteyden sarakkeiden välille uniqueidentifier , tuloksena on kysely, jossa on liitos, johon liittyy tyyppilause. Yleensä myös tämä menetelmä johtaa heikkoon suorituskykyyn. Ainoa vaihtoehtoinen menetelmä on luoda sarakkeet erityyppisillä sarakkeilla pohjana olevassa tietolähteessä.

• Piilota To-sarake suhteissa. Suhteiden to sarake on usein taulukon perusavain to . Sarakkeen tulee olla piilotettu, mutta jos se on piilotettu, sitä ei näytetä Kentät-luettelossa eikä sitä voi käyttää visualisoinneissa. Usein sarakkeet, joihin suhteet perustuvat, ovat itse asiassa järjestelmäsarakkeita, esimerkiksi tietovaraston korvaavia avaimia. Nämä sarakkeet kannattaa silti piilottaa.

  Jos sarakkeella on merkitys, luo laskettu sarake, joka on näkyvissä ja jossa on yksinkertainen lauseke sille, että sen arvo on sama kuin perusavaimella. Esimerkki:

      ProductKey_PK   (Destination of a relationship, hidden)
      ProductKey (= [ProductKey_PK],   visible)
      ProductName
      ...
  

• Tutki kaikkia laskettuja sarakkeita ja tietotyyppimuutoksia. Voit käyttää laskettuja taulukoita, kun käytät DirectQueryä yhdistelmämallien kanssa. Nämä ominaisuudet eivät välttämättä ole haitallisia, mutta ne aiheuttavat kyselyjä, jotka sisältävät lausekkeita yksinkertaisten sarakeviittausten sijaan. Nämä kyselyt saattavat johtaa siihen, että indeksejä ei käytetä.

• Vältä kaksisuuntaista ristiinsuodatusta suhteissa. Kaksisuuntaisen ristiinsuodatuksen käyttö voi johtaa kyselylausekkeisiin, jotka eivät toimi kunnolla. Saat lisätietoja kaksisuuntaisesta ristiinsuodatuksesta ohjeartikkelista DirectQueryn kaksisuuntaisen ristiinsuodatuksen käyttöönotto Power BI Desktopissa tai lataamalla kaksisuuntaisen ristiinsuodatuksen valkoisen raportin. Artikkelin esimerkit koskevat SQL Server Analysis Servicesiä, mutta pääperiaatteet koskevat myös Power BI:tä.

• Kokeile Oleta viite-eheys -asetusta. Suhteiden Oleta viite-eheys -asetus mahdollistaa sen, että kyselyt voivat käyttää INNER JOIN -lausekkeiden asemesta OUTER JOIN . Yleensä tämä ohjeistus parantaa kyselyn tehokkuutta, vaikka se riippuu tietolähteen ominaisuuksista.

• Älä käytä suhteellista päivämäärien suodatusta Power Query -editorissa. Power Query -editorissa voi määrittää suhteellisen päivämääräsuodatuksen. Voit esimerkiksi suodattaa näkyviin rivit, joiden päivämäärä on edellisen 14 päivän aikana.

  

  Tämä suodatin kuitenkin tarkoittaa suodatinta, joka perustuu kiinteään päivämäärään, kuten kyselyn luontiaikaan, kuten näet alkuperäisessä kyselyssä.

  

  Nämä tiedot eivät todennäköisesti ole sitä, mitä haluat. Jos haluat varmistaa, että suodatinta käytetään sen päivämäärän perusteella, jolloin raportti suoritetaan, ota päivämääräsuodatin käyttöön raportissa. Voit luoda lasketun sarakkeen, joka laskee päivien määrän sitten -funktion DAX DATE() avulla, ja käyttää tätä laskettua saraketta suodattimessa.

Raportin suunnittelu

Kun luot DirectQuery-yhteyttä käyttävän raportin, noudata seuraavia ohjeita:

• Harkitse kyselyn pienentämisasetusten käyttöä: Power BI tarjoaa raporttivaihtoehtoja lähetettävien kyselyiden määrän pienentämiseksi. Lisäksi se tarjoaa mahdollisuuden poistaa käytöstä tiettyjä toimintoja, jotka johtavat heikkoon käyttökokemukseen, jos tulokseksi saatavien kyselyiden suorittaminen kestää kauan. Nämä asetukset ovat käytössä, kun käsittelet raporttia Power BI Desktopissa, ja niitä käytetään myös käyttäessäsi raporttia Power BI -palvelussa.

  Jos haluat käyttää näitä asetuksia Power BI Desktopissa, siirry kohtaan Tiedosto>Asetukset ja vaihtoehdot>Asetukset ja valitse Kyselyn pienentäminen.

  

  Kyselyn pienentäminen -näytön valintojen avulla voit näyttää Käytä-painikkeen osittajille tai suodatinvalinnille. Kyselyitä ei lähetetä ennen kuin valitset suodattimen tai osittajan Käytä-painikkeen . Kyselyt suodattavat sitten tietoja valintojen avulla. Tämän painikkeen avulla voit tehdä useita osittaja- ja suodatinvalintoja, ennen kuin otat ne käyttöön.

• Ota suodattimet käyttöön ensin: Ota aina kaikki soveltuvat suodattimet käyttöön, kun aloitat visualisoinnin luomisen. Älä siis esimerkiksi vedä Kokonaismyynti- ja Tuotenimi-sarakkeiden mukaan ja suodata sitten näkyviin tiettyä vuotta, vaan ota suodatin käyttöön Vuosi-sarakkeessa alussa.

  Jokainen visualisoinnin luomisen vaihe lähettää kyselyn. Vaikka voitkin tehdä toisen muutoksen, ennen kuin ensimmäinen kysely on valmis, tämä menetelmä jättää silti tarpeettoman kuormituksen taustalähteelle. Kun otat suodattimet käyttöön aikaisessa vaiheessa, nämä välivaiheen kyselyt eivät yleensä ole niin kalliita. Jos et ota suodattimia käyttöön aikaisessa vaiheessa, miljoonan rivin rajoitus ylittyy.

• Rajoita sivun visualisointien määrää: Kun avaat sivun tai muutat sivun osittajaa tai suodatinta, kaikki sivun visualisoinnit päivitetään. Rinnakkaisten kyselyiden määrää on rajoitettu. Kun visualisointien määrä kasvaa, jotkin visualisoinnit päivittyvät sarjaittain, mikä pidentää sivun päivittämiseen kuluvaa aikaa. Siksi suosittelemme, että rajoitat yhden sivun visualisointien määrää. Voit käyttää sen sijaan useita yksinkertaisempia sivuja.

• Harkitse visualisointien välisen vuorovaikutuksen käytöstä poistamista: Raporttisivun visualisoinneilla voidaan oletusarvoisesti ristiinsuodattaa ja ristiinkorostaa sivun muita visualisointeja. Jos esimerkiksi valitset ympyräkaaviosta vuoden 1999 , pylväskaavio voidaan ristiinkorostaa näyttämään myynnin luokan mukaan vuonna 1999.

  

  Ristiinsuodatus ja ristiinkorostus DirectQueryssä edellyttävät, että kyselyt lähetetään pohjana olevaan lähteeseen. Poista tämä vuorovaikutus käytöstä, jos käyttäjien valinteihin vastaamiseen kuluva aika on kohtuuttoman pitkä.

  Kyselyn pienentäminen -asetusten avulla voit poistaa ristiinkorostamisen käytöstä koko raportissa tai tapauskohtaisesti. Lisätietoja on artikkelissa Visualisointien ristiinsuodatus keskenään Power BI -raportissa.

Yhteyksien enimmäismäärä

Voit määrittää niiden yhteyksien enimmäismäärän, jotka DirectQuery avaa kullekin pohjana olevalle tietolähteelle, ja hallita siten kuhunkin tietolähteeseen samanaikaisesti lähetettävien kyselyjen määrää.

DirectQuery avaa oletusarvoisen enimmäismäärän, joka on 10 samanaikaista yhteyttä. Jos haluat muuttaa nykyisen tiedoston enimmäislukumäärää Power BI Desktopissa, valitse Tiedosto>Asetukset ja vaihtoehdot>Asetukset ja valitse DirectQuery vasemmanpuoleisen ruudun Nykyinen tiedosto -osassa.

Asetus on käytössä vain, kun nykyisessä raportissa on vähintään yksi DirectQuery-lähde. Arvoa sovelletaan kaikkiin DirectQuery-lähteisiin ja raporttiin lisättyihin kaikkiin uusiin DirectQuery-lähteisiin.

Nostamalla Yhteyksien enimmäismäärä tietolähdettä kohden -asetuksen arvoa voit lähettää enemmän kyselyitä pohjana olevaan tietolähteeseen määritettyyn enimmäismäärään asti. Tästä menetelmästä on hyötyä, kun yhdellä sivulla on useita visualisointeja tai kun monet käyttäjät käyttävät raporttia samanaikaisesti. Kun yhteyksien enimmäismäärä on saavutettu, lisäkyselyt asetetaan jonoon, kunnes yhteys tulee saataville. Korkeampi rajoitus lisää taustalla olevan tietolähteen kuormitusta, joten asetus ei välttämättä paranna yleistä suorituskykyä.

Kun julkaiset raportin Power BI -palveluun, samanaikaisten kyselyiden enimmäismäärä riippuu myös niistä kohdeympäristön kiinteistä rajoista, joissa raportti julkaistaan. Power BI, Power BI Premium ja Power BI -raporttipalvelin asettavat erilaisia rajoja. Alla olevassa taulukossa luetellaan aktiivisten yhteyksien yläraja tietolähdettä kohden kussakin Power BI -ympäristössä. Nämä rajoitukset koskevat pilvitietolähteitä ja paikallisia tietolähteitä, kuten SQL Serveriä, Oraclea ja Teradataa.

Ympäristö	Enimmäisraja tietolähdettä kohden
Power BI Pro	10 aktiivista yhteyttä
Power BI Premium	Riippuu semanttisen mallin SKU-rajoituksesta
Power BI Report Server	10 aktiivista yhteyttä

Muistiinpano

DirectQuery-yhteyksien enimmäismäärän asetus koskee kaikkia DirectQuery-lähteitä, kun otat käyttöön parannetut metatiedot. Se on oletusasetus kaikille Power BI Desktopissa luoduille malleille.

DirectQuery Power BI -palvelussa

Kaikkia DirectQuery-tietolähteitä tuetaan Power BI Desktopista, ja jotkin lähteet ovat myös käytettävissä suoraan Power BI -palvelusta. Yrityskäyttäjä voi muodostaa Power BI:n avulla yhteyden esimerkiksi Salesforce-tietoihinsa, ja hän saa heti koontinäytön ilman Power BI Desktopin käyttöä.

Power BI -palvelussa on suoraan käytettävissä vain kaksi DirectQueryä käyttävää lähdettä:

• Spark
• Azure Synapse Analytics (aiemmin SQL Data Warehouse)

Näistä kahdesta lähteestäkin on silti parasta aloittaa DirectQueryn käyttö Power BI Desktopissa. Vaikka yhteyden muodostaminen Power BI -palvelussa on aluksi helppoa, tuloksena saatavan raportin parantamiseen liittyy rajoituksia. Esimerkiksi palvelussa ei ole mahdollista luoda laskutoimituksia, käyttää monia analyysitoimintoja tai päivittää metatietoja vastaamaan pohjana olevaan rakenteeseen tehtyjä muutoksia.

DirectQuery-raportin suorituskyky Power BI -palvelussa riippuu pohjana olevan tietolähteen kuormituksesta. Kuormitus riippuu seuraavista:

• Raportin ja koontinäytön jakavien käyttäjien määrä.
• Raportin monimutkaisuus.
• Määrittääkö raportti rivitason suojauksen.

Raportin toiminta Power BI -palvelussa

Kun avaat raportin Power BI -palvelussa, kaikki näkyvissä olevan sivun visualisoinnit päivitetään. Jokainen visualisointi edellyttää ainakin yhtä kyselyä pohjana olevaan tietolähteeseen. Jotkin visualisoinnit saattavat vaatia useamman kuin yhden kyselyn. Visualisointi voi esimerkiksi näyttää koostearvot kahdesta erillisestä taulukosta, sisältää monimutkaisemman mittarin tai sisältää summia mittayksiköistä, jotka eivät ole lisääviä, kuten Erillisten määrä. Uuteen sivuun siirtyminen päivittää nämä visualisoinnit. Päivitys lähettää uuden kyselyjoukon pohjana olevaan lähteeseen.

Jokainen käyttäjän käsittely raportissa saattaa aiheuttaa visualisointien päivittämisen. Jos esimerkiksi valitset eri arvon osittajassa, järjestelmän täytyy lähettää uudet kyselyt, jotta kaikki tähän vaikuttavat visualisoinnit päivitetään. Sama pätee visualisoinnin valitsemiseen ristiinkorostamiseen muissa visualisoinneissa tai suodattimen muuttamiseen. Vastaavasti raportin luominen tai muokkaaminen edellyttää, että kyselyt lähetetään visualisoinnin luomisen jokaisessa vaiheessa.

Jotkin tulokset välimuistiin tallentamisen jälkeen. Visualisointi päivittetään heti, jos tulokset ovat täysin samat. Jos rivitason suojaus on määritetty, näitä välimuisteja ei jaeta käyttäjien välillä.

DirectQueryn käyttäminen asettaa joitain tärkeitä rajoituksia joihinkin ominaisuuksiin, joita Power BI -palvelu tarjoaa julkaistuja raportteja varten:

• Nopeita merkityksellisiä tietoja ei tueta: Power BI: n nopeat merkitykselliset tiedot hakevat semanttisen mallisi eri alijoukkoja ja hyödyntävät kehittyneitä algoritmeja, joiden avulla ne löytävät mahdollisesti kiinnostavia merkityksellisiä tietoja. Koska nopeat merkitykselliset tiedot edellyttävät suorituskykyisiä kyselyjä, tämä ominaisuus ei ole käytettävissä DirectQueryä käyttävissä semanttisissa malleissa.

• Tutki-toiminnon käyttäminen Excelissä johtaa heikkoon suorituskykyyn: Voit tutkia semanttista mallia Tutki Excelissä -toiminnolla, jonka avulla voit luoda pivot-taulukoita ja pivot-kaavioita Excelissä. Tätä ominaisuutta tuetaan DirectQueryä käyttävissä semanttisissa malleissa, mutta suorituskyky on hitaampi kuin visualisointien luominen Power BI:ssä. Jos Excelin käyttäminen on tärkeää skenaarioissasi, ota tämä ongelma huomioon päätettäessä DirectQueryn käytöstä.

• Excel ei näytä hierarkioita: esimerkiksi Käytettäessä Analysoi Excelissä -toimintoa Excel ei näytä mitään Hierarkioita, jotka on määritetty Azure Analysis Services malleissa tai DirectQueryä käyttävissä Power BI:n semanttisissa malleissa.

Koontinäytön päivitys

Power BI -palvelussa voit kiinnittää yksittäisiä visualisointeja tai kokonaisia sivuja koontinäyttöihin ruutuina. DirectQueryn semanttisiin malleihin perustuvat ruudut päivittyvät automaattisesti lähettämällä kyselyjä taustalla oleviin tietolähteisiin aikataulun mukaisesti. Semanttiset mallit päivittyvät oletusarvoisesti tunnin välein, mutta voit määrittää päivitysaikataulut viikoittaisten ja 15 minuutin väliltä osana semanttisia malliasetuksia.

Jos mallissa ei ole määritetty mitään rivitason suojausta , kukin ruutu päivitetään kerran, ja tulokset jaetaan kaikille käyttäjille. Jos käytät rivitason suojausta, jokainen ruutu edellyttää erillisiä kyselyitä kutakin käyttäjää kohden taustalähteeseen.

Tällä voi olla suuri kerrannaisvaikutus. 10 ruutua sisältävä koontinäyttö, joka on jaettu 100 käyttäjälle ja joka on luotu semanttisesta mallista DirectQueryä käyttäen rivitason suojauksella, johtaa vähintään 1 000 kyselyn lähettämiseen pohjana olevaan tietolähteeseen jokaista päivitystä kohden. Harkitse tarkkaan rivitason suojauksen käyttöä ja päivitysaikataulun määritystä.

Kyselyn aikakatkaisut

Power BI -palvelun yksittäisten kyselyiden aikakatkaisuraja on neljä minuuttia. Yli neljä minuuttia kestävät kyselyt epäonnistuvat. Tämän rajoituksen tarkoituksena on estää liian pitkien suoritusaikojen aiheuttamat ongelmat. Käytä DirectQueryä vain lähteille, jotka voivat tuottaa vuorovaikutteisia kyselyjä.

Suorituskyvyn diagnostiikka

Tässä osiossa kerrotaan, miten voit diagnosoida suorituskykyyn liittyviä ongelmia ja miten voit hankkia lisätietoja raporttien optimoimiseksi.

Aloita suorituskykyongelmien vianmääritys Power BI Desktopissa, ei Power BI -palvelussa. Suorituskykyyn liittyvät ongelmat perustuvat usein pohjana olevan lähteen suorituskykyyn. Voit helpommin tunnistaa ja diagnosoida ongelmia eristetymmessä Power BI Desktop -ympäristössä.

Tämä lähestymistapa sulkee ensin pois joitakin osia, kuten Power BI -yhdyskäytävän. Jos suorituskykyyn liittyviä ongelmia ei ilmene Power BI Desktopissa, voit tutkia raportin erityispiirteet Power BI -palvelussa.

Power BI Desktopin suorituskyvyn analysointi on hyödyllinen työkalu ongelmien tunnistamiseen. Yritä eristää kaikki ongelmat yhdessä visualisoinnissa sivun useiden visualisointien asemesta. Jos Power BI Desktop -sivun yksittäinen visualisointi toimii hitaasti, analysoi Power BI Desktopin pohjana olevaan lähteeseen lähettämät kyselyt Suorituskyvyn analysointi -toiminnolla.

Voit myös tarkastella jäljitys- ja diagnostiikkatietoja, joita jotkin pohjana olevat tietolähteet tuottavat. Vaikka lähteestä ei olisi jäljitystietoja, jäljitystiedosto voi sisältää hyödyllisiä tietoja siitä, miten kysely suoritetaan ja miten voit parantaa sitä. Seuraavan prosessin avulla voit tarkastella Power BI:n lähettämia kyselyitä ja niiden suoritusaikoja.

Kyselyjen tarkasteleminen SQL Server profilerin avulla

Power BI Desktop kirjaa oletusarvoisesti tietyn istunnon tapahtumat jäljitystiedostoon, jonka nimi on FlightRecorderCurrent.trc. Jäljitystiedosto on nykyisen käyttäjän Power BI Desktop -kansiossa AnalysisServicesWorkspaces-kansiossa.

Joissain DirectQuery-lähteissä tämä jäljitystiedosto sisältää kaikki pohjana olevaan tietolähteeseen lähetetyt kyselyt. Seuraavat tietolähteet lähettävät kyselyjä lokiin:

• SQL Server
• Azure SQL Database
• Azure Synapse Analytics (aiemmin SQL Data Warehouse)
• Oracle
• Teradata
• SAP HANA

Voit lukea jäljitystiedostot käyttämällä SQL Serverin profilointi-toimintoa, joka on osa maksutonta SQL Server Management Studio -latausta.

Voit avata nykyisen istunnon jäljitystiedoston seuraavasti:

1. Valitse Power BI Desktop -istunnon aikana Tiedosto>Asetukset ja vaihtoehdot>Asetukset ja valitse sitten Diagnostiikka.

2. Valitse Kaatumisvedoskokoelma-kohdassa Avaa kaatumisvedosten/jäljitysten kansio.

   

   Power BI Desktop\Traces-kansio avautuu.

3. Siirry pääkansioon ja analysisServicesWorkspaces-kansioon, joka sisältää yhden työtilakansion jokaiselle avoimelle Power BI Desktop -esiintymälle. Näiden kansioiden nimen loppupääte on kokonaisluku, esimerkiksi AnalysisServicesWorkspace2058279583. Työtilakansio poistetaan, kun siihen liittyvä Power BI Desktop -istunto päättyy.

   Nykyisen Power BI -istunnon työtilakansion \Data-kansio sisältää jäljitystiedoston FlightRecorderCurrent.trc . Kirjoita sijainti muistiin.

4. Avaa SQL Server Profiler ja valitse Tiedosto>Avaa>jäljitystiedosto.

5. Siirry nykyisen Power BI -istunnon jäljitystiedoston polkuun tai anna polku ja avaa FlightRecorderCurrent.trc.

SQL Serverin profilointi näyttää kaikki nykyisen istunnon tapahtumat. Seuraavassa näyttökuvassa korostuu ryhmä kyselyä varten. Jokaisella kyselyryhmällä on seuraavat tapahtumat:

• - Query Begin ja Query End -tapahtuma, joista voit aloittaa DAX-kyselyn, joka luodaan muuttamalla visualisointia tai suodatinta Power BI:n käyttöliittymässä tai suodattamalla tai muuntamalla tietoja Power Query -editorissa.

• Niissä on DirectQuery Begin ainakin yksi pari - ja DirectQuery End -tapahtumia, jotka edustavat taustatietolähteeseen lähetettyjä kyselyjä, kun DAX-kyselyt arvioitiin.

Useita DAX-kyselyitä voidaan suorittaa rinnakkain, joten eri ryhmien tapahtumat voivat olla limittäisiä. -arvon avulla ActivityID voit määrittää, mitkä tapahtumat kuuluvat samaan ryhmään.

Myös seuraavat sarakkeet ovat kiinnostavia:

• TextData: Tämä on tapahtuman tekstitiedot. - Query Begin ja Query End -tapahtumissa tiedot ovat DAX-kyselyjä. - DirectQuery Begin ja DirectQuery End -tapahtumissa tiedot ovat SQL-kyselyjä, jotka lähetetään pohjana olevaan lähteeseen. Valitun tapahtuman TextData näkyy myös näytön alareunan ruudussa.
• EndTime: tämä on tapahtuman päättymisaika.
• Duration: DAX- tai SQL-kyselyn suorittaminen kesti millisekunteja.
• Virhe: Ilmenikö virhe, jolloin tapahtuma näkyy myös punaisena.

Voit kirjata jäljityksen mahdollisen suorituskykyongelman vianmääritykseen seuraavasti:

1. Avaa yksi Power BI Desktop -istunto, jotta sinulla ei ole useita työtilakansioita.

2. Tee Power BI Desktopissa toiminnot, joita haluat tutkia. Suorita vielä muutama toiminto. Näin varmistat, että tapahtumat, joita haluat tutkia, kirjataan jäljitystiedostoon.

3. Avaa SQL Server profiler ja tutki jäljitystiedostoa. Muista, että jäljitystiedosto poistetaan, kun suljet Power BI Desktopin. Muita Power BI Desktopin toimintoja ei myöskään näytetä heti. Sinun on suljettava jäljitystiedosto ja avattava se uudelleen, jotta näet uudet tapahtumat.

Pidä yksittäiset istunnot kohtuullisen pieninä siten, että käytettävissä on esimerkiksi 10 sekuntia toimintoja, ei satoja. Tämä lähestymistapa helpottaa jäljitystiedoston tulkitsemista. Jäljitystiedoston kokoa on myös rajoitettu. Pitkien istuntojen aikana on mahdollista, että varhaiset tapahtumat poistetaan.

Kyselyjen muodon ymmärtäminen

Power BI Desktop -kyselyiden yleisessä muodossa käytetään alivalintoja kullekin taulukolle, johon ne viittaavat. Power Query -editorin kysely määrittää alivalintakyselyt. Oletetaan esimerkiksi, että sinulla on seuraavat TPC-DS-taulukot SQL Serverissä:

Suoritetaan seuraava kysely:

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

Tuottaa seuraavan visualisoinnin Power BI:ssä:

Tämän visualisoinnin päivittäminen tuottaa SQL-kyselyn seuraavassa kuvassa. -, Item- ja Date_dim-taulukoille Web_Saleson kolme alivalintakyselyä, joista kukin palauttaa kaikki vastaavan taulukon sarakkeet, vaikka visualisointi viittaa vain neljään sarakkeeseen.

Power Query -editori määrittää tarkat alivalintakyselyt. Tämän alivalintakyselyiden käytön ei ole osoitettu vaikuttavan DirectQueryn tukemien tietolähteiden suorituskykyyn. SQL Serverin kaltaiset tietolähteet optimoivat pois viittaukset muihin sarakkeisiin.

Power BI käyttää tätä mallia, koska analyytikko tarjoaa SQL-kyselyn suoraan. Power BI käyttää kyselyä sellaisena kuin se on annettu eikä sitä yritetä kirjoittaa uudelleen.

Liittyvä sisältö

Jos haluat lisätietoja DirectQuerystä Power BI:ssä, katso:

• DirectQueryn käyttö Power BI Desktopissa

Tässä artikkelissa kuvataan DirectQueryn ominaisuuksia, jotka ovat yhteisiä kaikille tietolähteille. Lisätietoja tietyistä lähteistä on seuraavissa artikkeleissa:

• DirectQuery ja SAP HANA
• DirectQuery ja SAP BW
• DirectQueryn käyttö Power BI:n semanttisissa malleissa ja Analysis Servicesissa