Vägledning om frågedelegering i Power BI Desktop

  • Artikel
  • 2 minuter för att läsa

Den här artikeln vänder sig till datamodellerare som utvecklar modeller i Power BI Desktop. Den innehåller rekommendationer om när och hur du kan åstadkomma Power Query-frågedelegering.

Frågedelegering är möjligheten för en Power Query-fråga att generera ett enda frågeuttryck som hämtar och transformerar källdata. Mer information finns i Power Query-frågedelegering.

Vägledning

Vägledningen om frågedelegering är olika beroende på modelläget.

Power Query-frågan måste uppnå frågedelegering för DirectQuery eller tabeller med dubbelt lagringsläge.

För en tabell av typen Import kan det vara möjligt att uppnå frågedelegering. När frågan baseras på en relationskälla, och om en enda SELECT-instruktion kan konstrueras, får du bästa möjliga prestanda för datauppdateringen genom att säkerställa att frågedelegering verkligen sker. Om Power Query-kombinationsmotorn fortfarande måste bearbeta transformationer bör du minimera den mängd arbete den måste utföra, särskilt för stora datamängder.

I följande punktlista ges specifik vägledning.

  • Delegera så mycket bearbetning till datakällan som möjligt: När alla steg i en Power Query-fråga inte kan delegeras kan du identifiera det steg som förhindrar frågedelegering. Om det går kan du flytta senare steg till en tidigare position i sekvensen så att de omfattas av frågedelegeringen. Observera att Power Query-kombinationsmotorn kan vara tillräckligt smart för att ordna om frågestegen när den genererar källfrågan.

    För en relationsdatakälla gäller att om det steg som förhindrar frågedelegeringen kan utföras i en enda SELECT-instruktion, eller i procedurlogiken för en lagrad procedur, så bör du överväga att använda en intern SQL-fråga enligt nedanstående beskrivning.

  • Använd en intern SQL fråga: När en Power Query-fråga hämtar data från en relationskälla är det möjligt för vissa källor att använda en intern SQL fråga. Frågan kan faktiskt vara valfri giltig instruktion, även att köra en lagrad procedur. Om instruktionen genererar flera resultatuppsättningar returneras bara den första. Parametrar kan deklareras i instruktionen, och vi rekommenderar att du använder M-funktionen Value.NativeQuery. Den här funktionen har utformats för att på ett säkert och smidigt sätt skicka parametervärden. Det är viktigt att du förstår att Power Query-kombinationsmotorn inte kan delegera efterföljande frågesteg. Därför bör du inkludera all transformeringslogik, eller så mycket som möjligt, i den interna frågeinstruktionen.

    Det finns två viktiga saker att tänka på när du använder interna SQL-frågor:

    • För en DirectQuery-modelltabell måste frågan vara en SELECT-instruktion, och den kan inte använda vanliga tabelluttryck (CTE) eller en lagrad procedur.
    • Inkrementell uppdatering kan inte använda en intern SQL-fråga. Detta skulle tvinga Power Query-kombinationsmotorn att hämta alla källrader och sedan använda filter för att fastställa inkrementella ändringar.

    Viktigt

    En intern SQL-fråga kan göra mer än att bara hämta data. Du kan köra valfri giltig instruktion (eventuellt flera gånger), även sådana som ändrar eller tar bort data. Det är viktigt att du använder principen om minsta behörighet så att det konto som används för åtkomst till databasen bara har läsbehörighet till nödvändiga data.

  • Förbereda och transformera data i källan: När du identifierar att vissa Power Query-frågesteg inte kan viktas kan det vara möjligt att tillämpa transformeringen i datakällan. Transformeringarna kan uppnås genom att du skriver en databasvy som logiskt transformerar källdata. Det kan även gå att fysiskt förbereda och materialisera data innan Power BI kör frågor mot dem. Ett relationsbaserat informationslager är ett utmärkt exempel på förberedda data, eftersom det vanligtvis består av förintegrerade källor till organisationsdata.

Nästa steg

Mer information om den här artikeln finns i följande resurser: