Best practices for Execute DAX Queries REST API'en

Følg disse anbefalinger for at få mest muligt ud af Execute DAX Queries REST API i produktionsarbejdsbelastninger.

Vælg det rigtige endepunkt

Bemærk

Execute DAX Queries API'en er kun tilgængelig for semantiske modeller, der ligger på en Power BI-kapacitet (Premium, Fabric eller Embedded). Semantiske modeller uden kapacitetstildeling understøttes ikke.

Power BI tilbyder to REST-API'er til udførelse af DAX-forespørgsler. Vælg den, der matcher din klients evner:

  • Udfør DAX-forespørgsler (Arrow) — Brug dengang, når din klientapplikation kan forbruge binære Arrow IPC-strømme. Arrow leverer mindre nyttelaster, tabsfri typenøjagtighed og zero-copy deserialisering i kolonnerammeværk som pandas, Polars og Apache Spark. Dette API understøtter også avancerede parametre som queryTimeout og resultsetRowcountLimit. Kræver Premium- eller Fabric-kapacitet.
  • Execute Queries (JSON) — Brug når din forbruger er en low-code/no-code platform, Power Automate flow eller ethvert værktøj, der kun kan parse JSON. Dette API fungerer på Pro-, PPU- og Premium/Fabric-kapaciteter, men har en hård grænse på 100.000 rækker og 1.000.000 værdier pr. forespørgsel.

Som en generel regel, hvis dit resultatsæt overstiger et par hundrede rækker, føres ind i en analysepipeline eller kræver præcis typenøjagtighed, så brug Execute DAX Queries API med Arrow.

Optimer DAX-forespørgsler for Arrow-endpointet

Effektiv DAX reducerer både udførelsestid for forespørgsler og størrelsen på responspayload:

  • Returner kun de kolonner, du har brug for. Brug SELECTCOLUMNS eller eksplicitte kolonnelister i stedet for at returnere hele tabeller. Hver ekstra kolonne tilføjer til skemaet og postens batchstørrelse.
  • Foretræk SUMMARIZECOLUMNS frem for ADDCOLUMNS .FILTER SUMMARIZECOLUMNS producerer mere effektive forespørgselsplaner i VertiPaq-motoren.
  • Brug TOPN det til at begrænse rækker. Når du kun har brug for de øverste resultater, TOPN presser du grænsen ind i motoren i stedet for at overføre alle rækker og filtrere på klientsiden.
  • Undgå komplekse beregnede kolonner i forespørgsler. Målinger og aggregeringer er fine, men række-niveau beregninger på store tabeller kan forsinke udførelsen betydeligt.
  • Kombiner flere EVALUATE sætninger i én enkelt anmodning. Execute DAX Queries API understøtter flere EVALUATE sætninger i én query streng, som hver returnerer et separat resultatsæt. Dette undgår overhead ved separate HTTP-rundture.

Administrer autentificering effektivt

  • Cache og genbrug tokens. Brug MSAL's indbyggede token-cache for at undgå at kalde Microsoft Entra ID ved hver forespørgsel. For fortrolige klientflows cacher MSAL tokens automatisk, når du genbruger den samme ConfidentialClientApplication instans.
  • Brug fortrolige klientoplysninger til tjenesterne. For ubemandede mid-tier tjenester skal klientoplysninger (klienthemmelighed eller certifikat) bruges i stedet for delegerede brugertokens. Dette undgår afhængighed af en indlogget brugersession.
  • Foretrækker managed identities i Azure. Når din tjeneste kører i Azure (App Service, Functions, AKS), brug en managed identity for helt at eliminere legitimationshåndtering.
  • Håndter token-udløb med ynde. Adgangstokens udløber typisk efter en time. Tjek for 401 Unauthorized svar og opdater tokenet, før du prøver igen.

Håndter fejl og forsøg

Execute DAX Queries API kan returnere fejl på to måder:

  1. HTTP-niveau fejl — Standard HTTP-statuskoder med en JSON-fejlkrop. Almindelige koder:

    Statuskode Betydning Handling
    400 Dårlig forespørgsel (ugyldig DAX, manglende parametre) Ret anmodningen — prøv ikke igen.
    401 Uautoriseret (udløbet eller ugyldig token) Opdater tokenet og prøv igen én gang.
    403 Forbudt (utilstrækkelige tilladelser) Kontroller at kalderen har Build and Read-tilladelser på den semantiske model.
    429 For mange forespørgsler (hæslet) Vent på varigheden i Retry-After headeren, og prøv så igen.
    500 / 502 / 503 Midlertidige serverfejl Prøv igen med eksponentiel tilbagetrækning.

  2. Stream-niveau fejl — HTTP 200 med et fejl-rækkesæt indlejret i Arrow-svaret. Tjek Arrow-skemaets metadata for IsError=true og læs metadata-værdierne FaultCodeFaultString samt fejlraderne for detaljeret lokationsinformation.

For midlertidige fejl implementeres eksponentiel backoff med jitter. Start ved ét sekund, fordobl hver gentagelse, og dæk ved 30 sekunder. Begræns genforsøg til tre eller fire forsøg.

Kontrolresultatmængdestørrelse

Store resultatsæt bruger hukommelse både på kapaciteten i tjenesten og på den kaldende klient. Hver anmodning er begrænset af kapacitetens hukommelsesgrænse.

For at holde resultatsættene håndterbare:

  • Sat resultsetRowcountLimit i anmodningskroppen. Dette håndhæver en rækkebegrænsning på serversiden pr. resultatsæt. Hvis du ved, at din forbruger kun behøver 10.000 rækker, så sæt grænsen eksplicit.
  • Brug TOPN den i din DAX-forespørgsel. TOPN Begrænser rækker på motorniveau, hvilket er mere effektivt end at afkorte klientsiden.
  • Behandl recordbatches gradvist. Arrow-svar opdeles i record-batches på op til 100.000 rækker. I Python itererer man over batches med reader.read_next_batch() i stedet for at kalde reader.read_all(), når man arbejder med store resultater, for at holde hukommelsesforbruget konstant.

Sikre din mid-tier service

Hvis du bygger en mid-tier service, der proxyer DAX-forespørgsler for downstream-forbrugere:

  • Bekræft opkalderens identitet. Autentificér indkommende forespørgsler med Microsoft Entra ID eller en anden identitetsudbyder, før du videresender forespørgsler til Power BI. Eksponér aldrig Execute DAX Queries-endpointet som en åben proxy.
  • Håndhæv princippet om mindst privilegier. Giv tjenesteprincipalen kun de tilladelser, den har brug for (Build og Read på specifikke semantiske modeller). Brug ikke workspace admin eller tenant admin-roller til API-adgang.
  • Indlejr ikke legitimationsoplysninger i koden. Gem klienthemmeligheder i Azure Key Vault eller brug administrerede identiteter. Rotér hemmeligheder efter en fast tidsplan.
  • Desinficér DAX-indgangen. Hvis din mid-tier accepterer DAX-forespørgselstekst fra kaldere, skal du validere inputtet for at forhindre injektion af uventede operationer.
  • Brug parameteren effectiveUsername med omhu. Denne parameter gælder Row-Level sikkerhed på vegne af en specifik bruger. Sørg for, at den kaldende identitet er autoriseret til at udgive sig for at være den angivne bruger.

Overvåg og logfør

Følg sundheden og ydeevnen af din API-brug:

  • Log forespørgselsmetadata — Registrer forespørgselsteksten, svarstørrelse, HTTP-status og varighed for hver forespørgsel. Dette hjælper med at identificere langsomme forespørgsler og uventede fejlspidser.
  • Overvåg throttling-hastigheder — Spor 429 svar som en procentdel af de samlede forespørgsler. En stigende tendens indikerer, at du skal reducere forespørgselsfrekvensen eller fordele belastningen over tid.
  • Mål deserialiseringstid — For Arrow-svar skal den tid, der bruges på at læse og materialisere recordbatches, logges separat fra HTTP-rundturstiden. Dette hjælper med at skelne mellem netværkslatens og klientside-behandling.
  • Brug Application Insights eller tilsvarende — Hvis din mid-tier kører i Azure, så aktivér Application Insights for at få afhængighedssporing, fejladvarsler og end-to-end distribueret sporing.
  • Spor token-cache-hitrater — Lave cache-hitrater betyder hyppige token-opkøbsopkald, hvilket øger latenstiden og er et tegn på forkert konfigureret MSAL-caching.

Relateret indhold

  • Last updated on