Lisäävän päivityksen ja reaaliaikaisten tietojen vianmääritys
Lisäävän päivityksen ja reaaliaikaisten tietojen ratkaisun käyttöönottoon on kaksi vaihetta, joissa ensimmäinen on parametrien määrittäminen, suodattaminen ja käytännön määrittäminen Power BI Desktopissa ja toinen on ensimmäinen semanttinen mallin päivitystoiminto ja sitä seuraavat päivitykset palvelussa. Tässä artikkelissa käsitellään vianmääritystä erikseen kussakin näistä vaiheista.
Kun taulukko on osioitu Power BI -palvelu, on tärkeää pitää mielessä, että lisäävästi päivitetyt taulukot, jotka saavat myös reaaliaikaisia tietoja DirectQueryn avulla, toimivat nyt yhdistelmätilassa, mikä tarkoittaa, että ne toimivat sekä tuonti- että DirectQuery-tilassa. Kaikkien taulukoiden, joilla on yhteyksiä tähän lisäävästi päivitettävään hybriditaulukkoon, on käytettävä kaksoistilaa, jotta niitä voidaan käyttää tuonti- ja DirectQuery-tilassa ilman suorituskykyrangaistuksia. Lisäksi raportin visualisoinnit saattavat tallentaa välimuistiin tuloksia, jotta vältytään lähettämästä kyselyitä takaisin tietolähteeseen, mikä estäisi taulukkoa poimimasta uusimpia tietopäivityksiä reaaliaikaisesti. Viimeisessä vianmääritysosiossa käsitellään nämä hybriditilaongelmat.
Ennen kuin suoritat lisäävän päivityksen ja reaaliaikaisten tietojen vianmäärityksen, tarkista mallien ja reaaliaikaisten tietojen lisäävä päivitys sekä vaiheittaiset tiedot artikkelissa Lisäävän päivityksen ja reaaliaikaisten tietojen määrittäminen.
Määrittäminen Power BI Desktopissa
Useimmat ongelmat, joita esiintyy lisäävän päivityksen ja reaaliaikaisten tietojen määrittämisessä, liittyvät kyselyn delegointaan lähteeseen. Kuten artikkelissa Mallien lisäävän päivityksen yleiskatsaus – Tuetut tietolähteet on tuettava kyselyn delegointia lähteeseen,
Ongelma: tietojen lataaminen kestää liian kauan
Kun olet Power Query -editori valinnut Käytä, tietojen lataamiseen kuluu liikaa aikaa ja tietokoneresursseja. On useita mahdollisia syitä.
Syy: Tietotyyppiristiriita
Tämä ongelma voi johtua tietotyyppiristiriitasta, jossa Date/Time on - ja RangeEnd -parametrien RangeStart pakollinen tietotyyppi, mutta taulukon päivämääräsarake, jossa suodattimia käytetään, ei Date/Time ole tietotyyppiä tai päinvastoin. Sekä parametritietotyypin että suodatetun tietosarakkeen on oltava Date/Time tietotyyppiä ja muodon on oltava sama. Jos näin ei ole, kyselyä ei voi delegoida lähteeseen.
Ratkaisu: Tarkista tietotyyppi
Varmista, että lisäävän päivitystaulukon päivämäärä/aika-sarakkeen Date/Time tietotyyppi on. Jos taulukossa ei ole tietotyyppiä olevaa sarakettaDate/Time, vaan se käyttää kokonaislukutietotyyppiä, voit luoda funktion, joka muuntaa kohteen ja -parametrien päivämäärä- ja RangeEnd aika-arvon RangeStart vastaamaan tietolähdetaulukon kokonaisluvun korvaavaa avainta. Lisätietoja on artikkelissa Lisäävän päivityksen määrittäminen – Päivämäärän ja ajan muuntaminen kokonaisluvuksi.
Syy: Tietolähde ei tue kyselyn delegointia lähteeseen
Kuten artikkelissa Lisäävä päivitys ja mallien reaaliaikaiset tiedot on kuvattu - Vaatimukset, lisäävä päivitys on suunniteltu tietolähteille, jotka tukevat kyselyn delegointia lähteeseen. Varmista, että tietolähdekyselyt taitetaan Power BI Desktopissa ennen palveluun julkaisemista, jossa kyselyn delegointi lähteeseen voi lisääntyä huomattavasti. Tämä lähestymistapa on erityisen tärkeä, kun reaaliaikaisia tietoja lisätään lisäävään päivityskäytäntöön, koska reaaliaikainen DirectQuery-osio edellyttää kyselyn delegointia lähteeseen.
Ratkaisu: Tarkista ja testaa kyselyitä
Useimmissa tapauksissa lisäävän päivityksen käytäntö -valintaikkunassa näkyy varoitus, joka ilmaisee, eikö tietolähteelle suoritettava kysely tue kyselyn delegointia lähteeseen. Joissakin tapauksissa voi kuitenkin olla tarpeen varmistaa, että kyselyn delegointi lähteeseen on mahdollista. Jos mahdollista, valvo tietolähteelle välitettyä kyselyä SQL Profilerin kaltaisen työkalun avulla. Kysely, joka sisältää perustuu - ja RangeEnd -suodattimiaRangeStart, on suoritettava yksittäisessä kyselyssä.
Voit myös määrittää -parametrien ja RangeEnd -parametreihin lyhyen päivämääränRangeStart/ajanjakson, joka sisältää enintään muutamia tuhansia rivejä. Jos suodatetun tiedon lataaminen tietolähteestä malliin kestää kauan ja prosessi vie paljon aikaa, se todennäköisesti tarkoittaa, ettei kyselyä ole delegoitu lähteeseen.
Jos päätät, että kyselyä ei ole taitettu, katso power BI Desktopin ja Power Query -kyselyn lähteeseen delegoinnin ohjeet kohdasta Kyselyn delegointi lähteeseen, jotta voit selvittää, mikä saattaa estää kyselyn delegoimisen lähteeseen ja miten tai kuinka tietolähde voi jopa tukea kyselyn delegointia lähteeseen.
Semanttinen mallin päivitys palvelussa
Palvelun lisäävän päivityksen ongelmien vianmääritys vaihtelee sen mukaan, millaiseen kapasiteettiin mallisi on julkaistu. Premium-kapasiteettien semanttiset mallit tukevat sellaisten työkalujen kuin SQL Server Management Studion (SSMS) käyttöä yksittäisten osioiden tarkastelemiseen ja valikoivaan päivittämiseen. Power BI Pro -mallit eivät kuitenkaan tarjoa työkalujen käyttöoikeuksia XMLA-päätepisteen kautta, joten lisäävän päivityksen ongelmien vianmääritys saattaa edellyttää hieman enemmän kokeiluversiota ja virheitä.
Ongelma: Ensimmäinen päivitys aikakatkaistaan
Jaetun kapasiteetin Power BI Pro -mallien ajoitetun päivityksen aikaraja on kaksi tuntia. Tätä aikarajaa on korotettu viiteen tuntiin Premium-kapasiteetin malleissa. Tietolähdejärjestelmät saattavat myös määrätä kyselyn palautuksen kokorajan tai kyselyn aikakatkaisun.
Syy: Tietolähdekyselyitä ei delegoida lähteeseen
Vaikka kyselyn delegoinnin delegointi lähteeseen voidaan yleensä määrittää Power BI Desktopissa ennen palveluun julkaisemista, on mahdollista, että mallin päivityskyselyitä ei ole delegoitu lähteeseen, mikä johtaa liiallisiin päivitysaikoihin ja kyselyn koostemoduulin resurssien käyttöön. Tämä tilanne ilmenee, koska kysely luodaan mallin jokaiselle osiolle. Jos kyselyitä ei ole taitettu eikä tietoja suodateta tietolähteessä, moduuli yrittää suodattaa tietoja.
Ratkaisu: Tarkista kyselyn delegointi lähteeseen
Käytä tietolähteessä olevaa jäljitystyökalua määrittämään, että kullekin osiolle välitetty kysely on yksittäinen kysely, joka sisältää RangeStart- ja RangeEnd-parametreihin perustuvan suodattimen. Jos näin ei ole, varmista, että kyselyn delegointi lähteeseen tapahtuu Power BI Desktop -mallissa ladattaessa pientä suodatettua tietomäärää malliin. Jos näin ei ole, korjaa malli ensin, suorita metatietojen päivitys malliin (XMLA-päätepisteen avulla) tai jos Power BI Pro -malli on jaetussa kapasiteetissa, poista keskeneräinen malli palvelusta, julkaise se uudelleen ja yritä ensimmäistä päivitystoimintoa uudelleen.
Jos päätät, että kyselyitä ei ole taitettu, lue Ohjeet Kyselyn delegointi lähteeseen Power BI Desktopissa ja Power Query -kyselyn delegoinnissa lähteeseen, jotta voit selvittää, mikä saattaa estää kyselyn delegoimisen lähteeseen.
Syy: Osioihin ladatut tiedot ovat liian suuria
Ratkaisu: pienennä mallin kokoa
Monissa tapauksissa aikakatkaisu johtuu siitä, paljonko tietoja täytyy kysellä ja ladata mallin osioihin, mikä ylittää kapasiteetin asettamat aikarajat. Pienennä mallisi kokoa tai monimutkaisuutta tai jaa malli pienempiin osiin.
Ratkaisu: Ota käyttöön suuren mallin tallennusmuoto
Jos malli on julkaistu Premium-kapasiteetteihin, joiden koko on yli 1 Gt, voit parantaa päivitystoiminnon suorituskykyä ja varmistaa, että malli ei ylitä kokorajoituksia ottamalla suuren mallin tallennusmuoto käyttöön ennen ensimmäisen päivitystoiminnon suorittamista palvelussa. Lisätietoja on artikkelissa Suuret mallit Power BI Premiumissa.
Ratkaisu: Bootstrapin ensimmäinen päivitys
Premium-kapasiteetteihin julkaistujen mallien kohdalla voit käynnistää ensimmäisen päivitystoiminnon. Bootstrappingin avulla palvelu voi luoda mallille taulukko- ja osio-objekteja mutta ei ladata ja käsitellä historiallisia tietoja mihinkään osioon. Lisätietoja on artikkelissa Kehittynyt lisäävä päivitys – Estä aikakatkaisut ensimmäisen täyden päivityksen yhteydessä.
Syy: Tietolähdekyselyn aikakatkaisu
Tietolähteen oletusaikarajoitus voi rajoittaa kyselyitä.
Ratkaisu: Ohita aikaraja kyselylausekkeessa
Monet tietolähteet sallivat aikarajan ohittamisen kyselylausekkeessa. Lisätietoja on artikkelissa Mallien lisäävä päivitys – Aikarajat.
Ongelma: päivitys epäonnistuu arvojen kaksoiskappaleiden vuoksi
Syy: Postipäivät ovat muuttuneet
Päivitystoiminnolla mallissa päivitetään vain tietolähteessä muuttuneet tiedot. Koska tiedot jaetaan päivämäärällä, on suositeltavaa, että julkaisupäivämääriä (tapahtuma) ei muuteta.
Jos päivämäärä muutetaan vahingossa, voi ilmetä kaksi ongelmaa: käyttäjät huomaavat joidenkin summien muuttuneen historiallisissa tiedoissa (mitä ei pitäisi tapahtua) tai päivityksen aikana palautetaan virhe, joka ilmaisee, että yksilöllinen arvo ei ole todellisuudessa yksilöllinen.
Jälkimmäisessä tapauksessa tämä tilanne voi tapahtua, kun lisäävää päivitystä määritettyä taulukkoa käytetään 1:N suhteessa toiseen taulukkoon puolena 1 , ja sillä pitäisi olla yksilöllisiä arvoja. Kun tietyn tunnuksen tietoja muutetaan, kyseinen tunnus näkyy toisessa osiossa ja moduuli havaitsee, ettei arvo ole yksilöllinen.
Ratkaisu: päivitä tietyt osiot
Jos liiketoiminnan on muutettava joitakin aiempia tietoja päivämääristä, voit ehkä ratkaista ongelman käyttämällä SSMS:tä kaikkien osioiden päivittämiseen siitä kohdasta, jossa muutos on nykyiseen päivitysosioon asti, jolloin suhteen puoli on 1 yksilöllinen.
Ongelma: tiedot katkaistaan
Syy: Tietolähteen kyselyn raja on ylitetty
Joidenkin tietolähteiden, kuten Azure Data Explorerin, Log Analyticsin ja Application Insightsin, enimmäisraja tiedoille on 64 Mt (pakattu), jotka voidaan palauttaa ulkoista kyselyä varten. Azure Data Explorer saattaa palauttaa eksplisiittisen virheen, mutta muille, kuten Log Analytics ja Application Insights, palautetut tiedot katkaistaan.
Ratkaisu: Määritä pienemmät päivitys- ja myymäläjaksot
Määritä käytännölle pienemmät päivitys- ja myymäläjaksot. Jos esimerkiksi määritit yhden vuoden päivitysjakson, ja kyselyvirhe palautetaan tai palautettavat tiedot katkaistaan, kokeile 12 kuukauden päivitysjaksoa. Haluat varmistaa, että nykyisen päivitysosion tai päivitys- ja myymäläjaksoihin perustuvien historiallisten osioiden kyselyt palauttavat enintään 64 Mt tietoa.
Ongelma: uudelleen lataaminen epäonnistuu osion avain -ristiriitojen vuoksi
Syy: Päivämäärä tietolähteen päivämääräsarakkeessa päivitetään
Päivämääräsarakkeen suodatinta käytetään tietojen jakamiseen dynaamisesti aikavälialueisiin Power BI -palvelu. Lisäävää päivitystä ei ole suunniteltu tukemaan tapauksia, joissa suodatettu päivämääräsarake on päivitetty lähdejärjestelmässä. Päivitys tulkitaan lisäämiseksi ja poistamiseksi (ei todelliseksi päivitykseksi). Jos poisto tehdään historialliselta alueelta eikä lisäävästä alueelta, sitä ei poimita, mikä voi aiheuttaa tietojen päivittämisen virheitä osion avain -ristiriitojen vuoksi.
Palvelun hybriditila (esikatselu)
Kun Power BI ottaa käyttöön lisäävän päivityskäytännön, joka sisältää reaaliaikaisia tietoja, se muuttaa lisäävästi päivitetyn taulukon yhdistelmätaulukoksi, joka toimii sekä tuonti- että DirectQuery-tilassa. Huomaa DirectQuery-osio mallitaulukon seuraavan osioluettelon lopussa. DirectQuery-osion läsnäololla on vaikutuksia liittyviin taulukoihin ja raportin visualisointeihin, jotka kyselevät tätä taulukkoa.
Ongelma: Kyselyn suorituskyky on heikko
Syy: Liittyvät taulukot eivät ole kaksoistilassa
Sekä tuonti- että DirectQuery-tilassa toimivat hybriditaulukot edellyttävät kaikkien liittyvien taulukoiden toimintaa kaksoistilassa, jotta ne voivat toimia joko välimuistiin tallennettuina tai siihen tallentamatta jätettyinä riippuen Power BI -malliin lähetetyn kyselyn kontekstista. Kaksois-tilassa Power BI voi vähentää mallin rajoitettujen suhteiden määrää ja luoda tehokkaita tietolähdekyselyitä hyvän suorituskyvyn varmistamiseksi. Rajoitettuja suhteita ei voida lähettää tietolähteeseen, jolloin Power BI:n on noudettava enemmän tietoja kuin on tarpeen. Tältä vältytään, koska kaksoistaulukot voivat toimia DirectQuery- tai tuontitaulukoina.
Ratkaisu: liittyvien taulukoiden muuntaminen kaksoistilaan
Määrittäessäsi lisäävän päivityksen käytäntöä Power BI Desktop muistuttaa sinua vaihtamaan liittyvät taulukot kaksois-tilaan, kun valitset Hae uusimmat tiedot reaaliaikaisesti DirectQueryllä (vain Premium).. Varmista myös, että tarkistat kaikki olemassa olevat taulukkosuhteet mallinäkymässä.
DirectQuery-tilassa tällä hetkellä toimivat taulukot vaihdetaan helposti kaksoistilaan. Valitse taulukon ominaisuuksien Lisäasetukset-kohdassa Tallennus tila -luetteloruudusta Kaksoistaulukko. Tällä hetkellä tuontitilassa toimivat taulukot edellyttävät kuitenkin manuaalista työtä. Kaksoistaulukoilla on samat toiminnalliset rajoitukset kuin DirectQuery-taulukoilla. Power BI Desktop ei siksi voi muuntaa tuontitaulukoita, koska ne saattavat käyttää muita toimintoja, jotka eivät ole käytettävissä kaksoistilassa. Nämä taulukot on luotava manuaalisesti uudelleen DirectQuery-tilassa, ja ne on sitten muunnettava kaksoistilaan. Lisätietoja on kohdassa Tallennustilan hallinta Power BI Desktopissa.
Ongelma: Raportin visualisoinnit eivät näytä uusimpia tietoja
Syy: Power BI tallentaa kyselytulokset välimuistiin parantaa suorituskykyä ja vähentää taustakuormitusta
Power BI tallentaa oletusarvoisesti kyselyn tulokset välimuistiin, jotta raportin visualisointikyselyt voidaan käsitellä nopeasti, vaikka ne perustuivat DirectQueryyn. Tarpeettomien tietolähdekyselyiden välttäminen parantaa suorituskykyä ja vähentää tietolähteen kuormitusta, mutta se voi myös tarkoittaa sitä, että uusimmat tietolähteen muutokset eivät sisälly tuloksiin.
Ratkaisu: automaattisen sivun päivityksen määrittäminen
Jos haluat jatkaa uusimpien tietojen muutosten noutamista lähteestä, määritä Power BI -palvelu raportteihin automaattinen sivun päivitys. Automaattinen sivun päivitys voidaan suorittaa kiintein väliajoin, kuten viisi sekuntia tai kymmenen minuuttia. Kun tämä tietty aikaväli saavutetaan, kaikki kyseisen sivun visualisoinnit lähettävät päivityskyselyn tietolähteeseen ja päivittävät sen mukaisesti. Vaihtoehtoisesti voit päivittää sivun visualisointeja tietojen muutosten havaitsemisen perusteella. Tämä lähestymistapa edellyttää muutoksen havaitsemisen mittaria, jota Power BI käyttää sitten tietolähteen kyselyssä muutosten osalta. Muutoksen havaitsemista tuetaan vain työtiloissa, jotka ovat osa Premium-kapasiteettia. Lisätietoja on artikkelissa Automaattinen sivun päivitys Power BI:ssä.