March 31 - April 2, 2025, in Las Vegas, Nevada. Use code MSCUST for a $150 discount! Early bird discount ends December 31.
Register NowBe one of the first to start using Fabric Databases. View on-demand sessions with database experts and the Microsoft product team to learn just how easy it is to get started. Watch now
Pulse Responder y háganos saber qué piensa de los conjuntos de datos de DirectQuery para Power BI y Azure Analysis Services. Para obtener más información sobre esta función, visite esta entrada de blog o nuestra documentación.
Estas son algunas áreas de las que nos gustaría escuchar en particular:
Gracias y esperamos escuchar sus comentarios!
- El equipo de modelado de Power BI
'muy entusiasmado con esta funcionalidad. Todavía no lo he utilizado, pero he activado la casilla de verificación de vista previa. Noto la inestabilidad de mi conexión en vivo existente a los servicios de análisis de Azure. Mis objetos visuales se vuelven en blanco y el error dice "no se puede mostrar visual." Finalmente vuelve a mostrar los objetos visuales.
interesante - usted no cambió nada más?
Parece que no se puede deshacer la conexión. ¿Puede agregar una forma de eliminar conjuntos de datos agregados?
que es una limitación actual.
¡Hola!
Gran característica de desbloqueo de una gran cantidad de nuevas posibilidades, PERO POR FAVOR, pensar en el aspecto de la gobernanza, así. La capacidad de activar/desactivar esto por espacio de trabajo / conjunto de datos sería muy beneficioso.
gracias por los comentarios!
Esto es realmente un paso hacia el verdadero "BI de autoservicio", pero con un cuello de botella grande... "gobernanza de datos". Con RLS no permitido en la función, se pierde la goverance de uso de datos. Las personas pueden crear allí propios conjuntos de datos y compartir con otros sin que el "propietario" del conjunto de datos no tenga visibilidad de visibilidad visible con quién se comparten los datos. Y, mayor delicia es si tenemos la opción de inquilino B2B externa habilitada, la persona puede compartir contenido a usuarios no autorizados externos.
Considere la posibilidad de habilitar RLS (usuario eficaz dentro de la conexión de conjunto de datos) para esta característica, que tiene un gran caso de uso en la comunidad de "autoservicio" de Power BI. y con RLS realmente se convertirá en una joya de la característica.
Se aplicarán las reglas RLS en el origen original.
Quería hacerle saber que he publicado detalles adicionales relacionados con los errores de mi equipo aquí.
@Zarek @frostystoo : Creo que estos son los mismos errores que también está viendo:
He estado esperando esta capacidad y esperando con ansias desde que se anunció. Mi plan inicial de uso era dividir algunos conjuntos de datos complejos más grandes en conjuntos de datos "secundarios" que luego podrían combinarse de nuevo en el conjunto de datos primario más grande, pero seguir permitiendo que otras áreas de informes de la organización aprovechen parte del contenido específico de los conjuntos de datos secundarios para evitar la necesidad de agregar un montón de tablas que serían innecesarias para la aplicación.
Al principio esto se veía bien. Sin embargo, me encontré con una limitación con el modelo es directquery, a saber, la limitación de pasar más de un millón de registros a un origen externo.
Mi configuración era dos conjuntos de datos de Power BI independientes con una relación de uno a varios (también intenté bidireccional solo para ver) entre una tabla de hechos de cada uno. El objeto visual se representa correctamente hasta que se agrega una dimensión del segundo conjunto de datos al primero. Si se aplican filtros al segundo conjunto de datos para que el recuento de registros resultante esté por debajo de 1.000.000 de registros todo está bien. Aunque el primer conjunto de datos tiene mucho menos que 1.000.000 de registros, parece que el segundo está intentando pasar más de 1.000.000 en toda la relación y, por lo tanto, se produce un error debido a la limitación de directquery.
Desafortunadamente, esto es algo que probablemente con frecuencia sería un problema para nosotros al intentar construir un modelo empresarial sólido que aproveche los conjuntos de datos de diferentes áreas funcionales para aprovechar de manera más eficaz y eficiente nuestra capacidad premium.
Creo que esto todavía puede ser útil para algunos usos específicos, pero no tanto de un modelo de datos gobernado grande.
A menos que esté haciendo algo mal - entonces soy todo oídos!
Otro problema que encontré fue que ya no puedo obtener flujos de datos directquery para trabajar mientras que antes.
Hola @clementskr !
Ver mi entrada de blog - DirectQuery da consultas weired con enorme grande DAX...
¡Ve por "Importar"!
"Compuesto" llegó – PRECAUCION!
saludos
Oliver
¡Comparto su opinión, señor!
Gracias por su respuesta. Casi siempre uso la importación. Sin embargo, si HR tiene un conjunto de datos de Power BI que han creado con todas las capas semánticas de empresa integradas en medidas y, de igual manera, Finance tiene un conjunto de datos de Power BI (ambos importados por su cuenta), y quiero vincular los dos con una relación entre los dos sin reconstruir todas las medidas ya aprobadas, que es lo que esta característica me permite hacer , Estoy limitado por la limitación de filas máximas de consulta directa de la relación es de alta cardinalidad. Ambos orígenes se importan por sí mismos, pero atarlos lo obliga a un origen de consulta directo. Obviamente, se podría hacer un único conjunto de datos importado de una empresa completa, pero eso parece una pesadilla de mantenimiento y actualización.
Por lo que puedo decir, la conexión de grandes conjuntos de datos específicos funcionales a otros grandes conjuntos de datos específicos funcionales no está realmente habilitado (dependiendo de cuál es esa relación y la cardinalidad de tales) debido a las limitaciones de consulta directa.
Ok, yo no era consciente de que también hay límites cuando el directo es a un tabular en la memoria...
También tuve algunos otros problemas para conectar conjuntos de datos.
Ver:
Conjuntos de datos apilados
Hola otra vez.
Por alguna razón, estoy obteniendo este problema cada vez que publico informes con la nueva característica (conjunto de datos de PowerBI múltiple)
¿Alguien puede ayudarme a lo que está pasando?
Estoy teniendo exactamente el mismo problema de mi parte. Creo que está relacionado con problemas con el permiso de construcción. La publicación funciona correctamente al conectarse a conjuntos de datos ubicados en un área de trabajo de la que es miembro. La excepción anterior se produce cuando intenta publicar un informe que utiliza la conexión de consulta directa a un conjunto de datos para el que solo tiene permiso de compilación, pero que no es miembro de un área de trabajo en la que reside.
Tengo un ticket de apoyo abierto en esto, pero está progresando dolorosamente lento.
no está seguro, ¿esto sucede con otros conjuntos de datos "normales" también?
Hola @tessahurr!
Usted pidió conjuntos de datos apilados, intenté 😉
No pensemos en si esto tiene algún sentido para un propósito real...
Construí 3 conjuntos de datos separados y luego los uní con una tabla imprada:
1) funciona bien
2) Permisos de acceso a cada conjunto de datos sin problema
3) La consulta DAX está bien
4) Por supuesto que tiene algunos cómo manejar tablas de dimensiones duplicadas... (Geo)
Luego hice de este modelo completo un conjunto de datos de nuevo.
Este shoud es la base de un informe de usuario.
Pero tengo algún problema de acceso... ¿"Inicio de sesión único"?
Ok, lo tengo.
Sí que daría un modelo extraño - exactamente lo que trato de señalar en mi BLOG, ese diseño será aún más importante, qué unir, cómo unirse, qué datos utilizar...
¡Hola!
Una gran innovación largamente esperada.
Pero también un riesgo, ya que incluso en modelos de diseño perfecto y conjunto de datos pequeño que da consultas weired con 3.000 líneas o incluso 50.000 líneas de DAX!!!
Lea esto:
"Compuesto" llegó - PRECAUCION!
saludos
Oliver
Hola. Tengo un caso de uso para necesitar más de 3 longitudes de cadena para la consulta directa a AS. Nuestro departamento de operaciones utiliza múltiples aplicaciones en sus actividades diarias. Contamos con un almacén de datos donde hemos conectado lentamente la mayoría de estas aplicaciones y modelado sus datos de acuerdo con nuestros procesos para facilitar la generación de informes. Todavía tenemos algunas aplicaciones aún no agregadas a nuestro almacenamiento de datos y algunas fuentes de datos que nunca se agregarán a nuestro DWH, por lo que hemos utilizado flujos de datos para acceder a estas fuentes de datos. Hemos creado alrededor de 4 conjuntos de datos certificados para los datos de estas aplicaciones conectadas a nuestra DWH y los hemos compartido dentro de nuestra organización para que los empleados los usen si lo desean. Ahora nuestro departamento de operaciones quiere un conjunto de KPI en un único informe basado en datos de todas las diversas aplicaciones que utilizan. Hasta ahora, hemos tenido que desarrollar un único conjunto de datos BIG que contiene las mismas tablas de todo el conjunto de datos certificado más los datos de los flujos de datos mencionados anteriormente. Esto es para que podamos crear el único informe con varios marcadores, botones y segmentaciones de datos. Este conjunto de datos BIG ha sido una pesadilla para mantener (más de 100 medidas, más de 60 tablas) y preferiríamos compartimentar los datos en estos conjuntos de datos certificados más pequeños que serían más fáciles de mantener y administrar los cambios. Intenté crear el mismo modelo BIG usando la nueva característica DQ para AS, pero como contenía 4 conjuntos de datos y alrededor de 15 tablas de flujo de datos, no se publicaría en el servicio. ¡@tessahurr aumentar el número máximo de cadenas!
March 31 - April 2, 2025, in Las Vegas, Nevada. Use code MSCUST for a $150 discount!
Arun Ulag shares exciting details about the Microsoft Fabric Conference 2025, which will be held in Las Vegas, NV.