Procedimientos recomendados para la API REST de Ejecutar consultas DAX

Siga estas recomendaciones para sacar el máximo partido de la API REST para Consultas DAX en cargas de trabajo de producción.

Elección del punto de conexión adecuado

Nota:

La API Execute DAX Queries (Ejecutar consultas DAX) solo está disponible para los modelos semánticos que residen en una capacidad de Power BI (Premium, Fabric o Embedded). No se admiten modelos semánticos sin asignación de capacidad.

Power BI ofrece dos API REST para ejecutar consultas DAX. Elija la que coincida con las funcionalidades del cliente:

  • Ejecutar consultas DAX (flecha): use cada vez que la aplicación cliente pueda consumir secuencias IPC de flecha binaria. Arrow ofrece cargas útiles más pequeñas, fidelidad de tipos sin pérdida y deserialización de copia cero en frameworks columnares como pandas, Polars y Apache Spark. Esta API también admite parámetros avanzados como queryTimeout y resultsetRowcountLimit. Requiere capacidad Premium o Fabric.
  • Ejecutar consultas (JSON): Úselo cuando el consumidor sea una plataforma de código bajo, sin código, un flujo de Power Automate o cualquier herramienta que solo pueda analizar JSON. Esta API funciona en capacidades Pro, PPU y Premium/Fabric, pero tiene un límite máximo de 100 000 filas y 1000 000 valores por consulta.

Como regla general, si el conjunto de resultados supera varios cientos de filas, se alimenta en una canalización de análisis o requiere fidelidad de tipo precisa, use la API de Consultas DAX con Arrow.

Optimización de consultas DAX para el endpoint Arrow

DAX eficaz reduce tanto el tiempo de ejecución de consultas como el tamaño de la carga de respuesta:

  • Devuelve solo las columnas que necesita. Utilice SELECTCOLUMNS o listas explícitas de columnas en lugar de devolver tablas completas. Cada columna adicional se suma al esquema y al tamaño del paquete de registros.
  • Prefiere SUMMARIZECOLUMNS sobre ADDCOLUMNS con FILTER. SUMMARIZECOLUMNS genera planes de consulta más eficaces en el motor VertiPaq.
  • Use TOPN para limitar las filas. Cuando solo se necesitan los resultados principales, TOPN aplica el límite al motor en lugar de transferir todas las filas y filtrar en el lado del cliente.
  • Evite columnas calculadas complejas en las consultas. Las medidas y agregaciones son adecuadas, pero los cálculos a nivel de fila en tablas grandes pueden ralentizar significativamente la ejecución.
  • Combina varias declaraciones EVALUATE en una sola solicitud. La API Execute DAX Queries admite varias EVALUATE instrucciones dentro de una query cadena, cada una de las cuales devuelve un conjunto de resultados independiente. Esto evita la sobrecarga de recorridos de ida y vuelta HTTP independientes.

Administrar la autenticación de forma eficaz

  • Almacenar en caché y reutilizar tokens. Use la caché de tokens integrada de MSAL para evitar llamar a Microsoft Entra ID en cada solicitud. En el caso de los flujos de cliente confidenciales, MSAL almacena en caché los tokens automáticamente al reutilizar la misma ConfidentialClientApplication instancia.
  • Use credenciales de cliente confidenciales para los servicios. Para los servicios desatendidos de nivel medio, use credenciales de cliente (secreto de cliente o certificado) en lugar de tokens de usuario delegados. Esto evita la dependencia de una sesión de usuario autenticado.
  • Se prefieren identidades administradas en Azure. Cuando el servicio se ejecuta en Azure (App Service, Functions, AKS), use una identidad administrada para eliminar completamente la administración de credenciales.
  • Controle la expiración del token correctamente. Los tokens de acceso suelen expirar después de una hora. Compruebe si hay 401 Unauthorized respuestas y actualice el token antes de volver a intentarlo.

Control de errores y reintentos

La API Execute DAX Queries (Ejecutar consultas DAX) puede devolver errores de dos maneras:

  1. Errores de nivel HTTP : códigos de estado HTTP estándar con un cuerpo de error JSON. Códigos comunes:

    Código de estado Meaning Acción
    400 Solicitud incorrecta (DAX no válido, parámetros que faltan) Corregir la solicitud: no vuelva a intentarlo.
    401 No autorizado (token expirado o no válido) Actualice el token y vuelva a intentarlo una vez.
    403 Prohibido (permisos insuficientes) Compruebe que el autor de la llamada tiene permisos de compilación y lectura en el modelo semántico.
    429 Demasiadas solicitudes (restringidas) Espere la duración del Retry-After encabezado y vuelva a intentarlo.
    500 / 502 / 503 Errores transitorios del servidor Vuelva a intentarlo con retroceso exponencial.

  2. Errores de nivel de secuencia : HTTP 200 con un conjunto de filas de error incrustado en la respuesta de Arrow. Verifique los metadatos del esquema Arrow para IsError=true y lea los valores de metadatos de FaultCode y FaultString, además de las filas con errores para obtener información detallada sobre la ubicación.

En el caso de los errores transitorios, implemente retroceso exponencial con vibración. Comience en un segundo, doble en cada reintento y límite en 30 segundos. Limite los reintentos a tres o cuatro intentos.

Control del tamaño del conjunto de resultados

Los conjuntos de resultados grandes consumen memoria tanto en la capacidad del servicio como en el cliente que realiza la llamada. Cada solicitud está limitada por el límite de memoria de la capacidad.

Para mantener los conjuntos de resultados administrables:

  • Establezca resultsetRowcountLimit en el cuerpo de la solicitud. Esto aplica un límite de filas del lado servidor por conjunto de resultados. Si sabe que el consumidor solo necesita 10 000 filas, establezca el límite explícitamente.
  • Use TOPN en la consulta DAX. TOPN limita las filas en el nivel de motor, lo que es más eficaz que truncar el lado cliente.
  • Procesar lotes de registros incrementalmente. Las respuestas de Arrow se dividen en lotes de registros de hasta 100 000 filas. En Python, itera sobre lotes con reader.read_next_batch() en lugar de llamar a reader.read_all() al trabajar con resultados grandes, para mantener constante el uso de memoria.

Asegura tu servicio intermedio

Si construye un servicio de nivel medio que actúe como un proxy para consultas DAX dirigidas a consumidores posteriores:

  • Valide la identidad del autor de la llamada. Autentique las solicitudes entrantes con Microsoft Entra ID u otro proveedor de identidades antes de reenviar consultas a Power BI. Nunca exponga el endpoint de Ejecución de Consultas DAX como un proxy abierto.
  • Exigir privilegios mínimos. Conceda a la entidad de servicio solo los permisos que necesita (compilación y lectura en modelos semánticos específicos). No utilice roles de administrador de espacio de trabajo ni de administrador de arrendatario para el acceso a la API.
  • No inserte credenciales en el código. Almacene secretos de cliente en Azure Key Vault o use identidades administradas. Rotación de secretos según una programación normal.
  • Sane la entrada DAX. Si el nivel medio acepta texto de consulta DAX de los solicitantes, valide la entrada con el fin de evitar la inyección de operaciones inesperadas.
  • Use el effectiveUsername parámetro con cuidado. Este parámetro aplica Row-Level Security en nombre de un usuario específico. Asegúrese de que la identidad de llamada está autorizada para suplantar al usuario especificado.

Supervisión y registro

Realice un seguimiento del estado y el rendimiento del uso de la API:

  • Metadatos de consulta de registro : registre el texto de la consulta, el tamaño de respuesta, el estado HTTP y la duración de cada solicitud. Esto ayuda a identificar consultas lentas y picos de errores inesperados.
  • Supervisar las tasas de limitación : realice un seguimiento 429 de las respuestas como un porcentaje de las solicitudes totales. Una tendencia creciente indica que necesita reducir la frecuencia de solicitud o distribuir la carga a lo largo del tiempo.
  • Medir el tiempo de deserialización — Para las respuestas de Arrow, registrar el tiempo dedicado a leer y materializar lotes de registros por separado del tiempo de ida y vuelta HTTP. Esto ayuda a distinguir la latencia de red del procesamiento del lado cliente.
  • Use Application Insights o equivalente: si el nivel medio se ejecuta en Azure, habilite Application Insights para obtener seguimiento de dependencias, alertas de errores y seguimiento distribuido de un extremo a otro.
  • Seguimiento de las tasas de aciertos de caché de tokens: las tasas de aciertos de caché bajas significan llamadas frecuentes para la adquisición de tokens, que agregan latencia y son un signo de una configuración incorrecta de la caché de MSAL.

Contenido relacionado

  • Last updated on