Beste praksis for Execute DAX Queries REST API

Følg disse anbefalingene for å få mest mulig ut av Execute DAX Queries REST API i produksjonsarbeidsbelastninger.

Velg riktig endepunkt

Power BI tilbyr to REST-API-er for å kjøre DAX-spørringer. Velg den som matcher kundens evner:

• Kjør DAX-spørringer (Arrow) — Bruk når klientapplikasjonen din kan konsumere binære Arrow IPC-strømmer. Arrow leverer mindre nyttelaster, tapsfri typenøyaktighet og null-kopi deserialisering i kolonnerammeverk som pandas, Polars og Apache Spark. Dette API-et støtter også avanserte parametere som queryTimeout og resultsetRowcountLimit. Krever Premium- eller Fabric-kapasitet.
• Execute Queries (JSON) — Bruk når forbrukeren din er en low-code/no-code plattform, Power Automate flow, eller et hvilket som helst verktøy som kun kan analysere JSON. Dette API-et fungerer på Pro-, PPU- og Premium/Fabric-kapasiteter, men har en hard grense på 100 000 rader og 1 000 000 verdier per spørring.

Som en generell regel, hvis resultatsettet ditt overstiger noen hundre rader, mates inn i en analysepipeline, eller krever presis typenøyaktighet, bruk Execute DAX Queries API med Arrow.

Optimaliser DAX-spørringer for Arrow-endepunktet

Effektiv DAX reduserer både spørringsutførelsestid og responsnyttelast:

• Returner kun de kolonnene du trenger. Bruk SELECTCOLUMNS eller eksplisitte kolonnelister i stedet for å returnere hele tabeller. Hver ekstra kolonne legger til skjema- og postbatchstørrelsen.
• Foretrekk SUMMARIZECOLUMNS over ADDCOLUMNS med FILTER. SUMMARIZECOLUMNS produserer mer effektive spørringsplaner i VertiPaq-motoren.
• Bruk TOPN det for å begrense rader. Når du bare trenger toppresultatene, TOPN presser du grensen inn i motoren i stedet for å overføre alle rader og filtrere klientsiden.
• Unngå komplekse kalkulerte kolonner i spørringer. Målinger og aggregeringer er greit, men radnivåberegninger på store tabeller kan forsinke utførelsen betydelig.
• Kombiner flere EVALUATE setninger i én forespørsel. Execute DAX Queries API støtter flere EVALUATE setninger i én query streng, hver returnerer et eget resultatsett. Dette unngår overhead ved separate HTTP-rundturer.

Administrer autentisering effektivt

• Cache og gjenbruk tokens. Bruk MSALs innebygde token-cache for å unngå å kalle Microsoft Entra ID på hver forespørsel. For konfidensielle klientflyter cacher MSAL tokens automatisk når du gjenbruker samme ConfidentialClientApplication instans.
• Bruk konfidensielle klientopplysninger for tjenestene. For ubemannede mellomnivåtjenester, bruk klientlegitimasjon (klienthemmelig eller sertifikat) i stedet for delegerte brukertokens. Dette unngår avhengighet av en innlogget brukerøkt.
• Foretrekk administrerte identiteter i Azure. Når tjenesten din kjører i Azure (App Service, Functions, AKS), bruk en administrert identitet for å eliminere legitimasjonshåndtering helt.
• Håndter token-utløp på en elegant måte. Tilgangstokens utløper vanligvis etter én time. Sjekk for 401 Unauthorized svar og oppdater tokenet før du prøver på nytt.

Håndter feil og forsøk på nytt

Execute DAX Queries API kan returnere feil på to måter:

1. HTTP-nivå feil — Standard HTTP-statuskoder med en JSON-feilkropp. Vanlige koder:

   Statuskode	Betydningen	Handling
   400	Dårlig forespørsel (ugyldig DAX, manglende parametere)	Fiks forespørselen — ikke prøv på nytt.
   401	Uautorisert (utløpt eller ugyldig token)	Oppdater tokenet og prøv på nytt én gang.
   403	Forbudt (utilstrekkelige tillatelser)	Sjekk at kalleren har Bygg- og Lesetillatelser på den semantiske modellen.
   429	For mange forespørsler (strupet)	Vent på varigheten i Retry-After headeren, og prøv på nytt.
   500 / 502 / 503	Forbigående serverfeil	Prøv på nytt med eksponentiell tilbakegang.

2. Strømnivåfeil — HTTP 200 med et feilradsett innebygd i Arrow-svaret. Sjekk Arrow-skjemaets metadata for IsError=true og les FaultCode metadataverdiene FaultString , pluss feilradene for detaljert posisjonsinformasjon.

For midlertidige feil, implementer eksponentiell backoff med jitter. Start på ett sekund, doble på hvert forsøk, og begrens til 30 sekunder. Begrens forsøkene til tre eller fire forsøk.

Kontrollresultatsettstørrelse

Store resultatsett bruker minne både på kapasiteten i tjenesten og på den kallende klienten. Hver forespørsel er bundet av kapasitetens minnegrense.

For å holde resultatsettene håndterbare:

• Satt resultsetRowcountLimit i forespørselskroppen. Dette håndhever en server-side radbegrensning per resultatsett. Hvis du vet at forbrukeren din bare trenger 10 000 rader, sett grensen eksplisitt.
• Bruk TOPN i DAX-spørringen din. TOPN Begrenser rader på motornivå, noe som er mer effektivt enn å forkorte klientsiden.
• Behandle postbatchene trinnvis. Arrow-svar deles opp i postpartier på opptil 100 000 rader. I Python, iterer over batcher med reader.read_next_batch() i stedet for å kalle reader.read_all() når du jobber med store resultater, for å holde minnebruket konstant.

Sikre din mellomstore tjeneste

Hvis du bygger en mellomstor tjeneste som proxyer DAX-forespørsler for nedstrøms forbrukere:

• Bekreft innringerens identitet. Autentiser innkommende forespørsler med Microsoft Entra ID eller en annen identitetsleverandør før du videresender forespørsler til Power BI. Aldri eksponer Execute DAX Queries-endepunktet som en åpen proxy.
• Håndhev minst mulig tilgang. Gi tjenesteprincipalen kun de tillatelsene den trenger (Build and Read på spesifikke semantiske modeller). Ikke bruk arbeidsplass- eller leietakeradministratorroller for API-tilgang.
• Ikke legg inn legitimasjon i koden. Lagre klienthemmeligheter i Azure Key Vault eller bruk administrerte identiteter. Roter hemmeligheter etter en jevn timeplan.
• Desinfiser DAX-inngangen. Hvis mellomnivået ditt aksepterer DAX-spørringstekst fra kallere, valider inputen for å forhindre injeksjon av uventede operasjoner.
• Bruk parameteren effectiveUsername med omhu. Denne parameteren gjelder Row-Level sikkerhet på vegne av en spesifikk bruker. Sørg for at anropsidentiteten er autorisert til å utgi seg for å være den angitte brukeren.

Overvåk og logg

Følg helsen og ytelsen til API-bruken din:

• Logg spørringsmetadata — Registrer spørringsteksten, svarstørrelse, HTTP-status og varighet for hver forespørsel. Dette hjelper til med å identifisere trege spørringer og uventede feiltopper.
• Overvåk throttling-hastigheter — Spor 429 svar som en prosentandel av totale forespørsler. En økende trend indikerer at du må redusere forespørselsfrekvensen eller spre belastningen over tid.
• Mål deserialiseringstid — For Arrow-svar, logg tiden brukt på å lese og materialisere postbatcher separat fra HTTP-rundturen. Dette hjelper med å skille nettverksforsinkelse fra klientbasert prosessering.
• Bruk Application Insights eller tilsvarende — Hvis mellomlageret ditt kjører i Azure, aktiver Application Insights for å få avhengighetssporing, feilvarsler og ende-til-ende distribuert sporing.
• Spor token-cache-treffrater — Lave cache-treffrater betyr hyppige tokenanskaffelsesanrop, noe som øker forsinkelsen og er et tegn på feilkonfigurert MSAL-caching.

Relatert innhold

• Forstå Execute DAX Query API-et
• Kom i gang med Execute DAX Queries REST API-et
• Veiledning: Bygg en mellomstor DAX-spørringstjeneste
• Veiledning: Ekstraksjon med høyt volum Python for data science