Forum Discussion
Uso del Generador de informes para DirectQuery Azure Databricks
Hola
Disculpas, esta es una pregunta en Report Builder, me doy cuenta de que este es el foro de escritorio ... pero ¿a dónde voy?!?! 😁
Actualmente estoy trabajando en una solución en la que un cliente tiene datos en Azure Databricks Unity Catalog, con RLS configurado en un esquema "gold". Debido al RLS en el origen, necesitamos usar DirectQuery en Power BI para acceder a los datos. El usuario final necesita usar el Generador de informes para crear informes paginados y se siente cómodo usando esta herramienta debido al historial de SSRS.
Para obtener información adicional, si ayuda, hemos configurado un gran clúster de almacenamiento de SQL sin servidor en databricks.
Además, los informes se implementan en una SKU F64 (no en una capacidad de prueba).
El problema que tengo es que en el servicio no parece estar obteniendo ningún paso a través de AAD, por lo que DirectQuery está accediendo al origen con las credenciales de usuario que se usaron para configurar la conexión y no con las credenciales del usuario que ve o ejecuta el informe.
Esto es lo que he hecho hasta ahora:
Tengo una conexión a la nube configurada en el servicio para acceder a la instancia de Azure Databricks. Se ha seleccionado Azure Active Directory para el método de autenticación y se ha habilitado "Usar SSO a través de Azure AD para consultas de DirectQuery". El nivel de privacidad se establece en "Organizativo". Actualmente no tengo permiso para confirmar si se ha configurado el catálogo inicial; No sé si esto hace la diferencia.
He creado un informe paginado que usa NativeQuery en el mashup, ya que los usuarios desean poder escribir/agregar SQL al código M, similar a la experiencia de "Consulta" al conectar Report Builder a SQL Server. Este informe se ha configurado para utilizar la conexión a la nube creada en el punto anterior.
El informe se publica en el servicio, pero debido al hecho de que no hay ningún modelo semántico, no veo que sea posible habilitar la opción "Los visores de informes solo pueden acceder a este origen de datos con sus propias identidades de Power BI mediante DirectQuery".
Cuando probamos el informe, el informe se ejecuta en mi contexto de seguridad, ya que configuré el informe y la conexión.
Podemos observar esto de dos maneras diferentes:
1) Cada probador solo puede ver los datos que puedo ver en la fuente, ya que solo puedo ver una subsección de datos debido a RLS.
2) Al mirar el historial de consultas en databricks, podemos ver que el usuario "Usuario" y el usuario "Ejecutar como" se registran como yo.
He examinado la documentación específica de Databrick y hay una sugerencia de que el SSO de la cuenta debe estar habilitado, del cual necesito verificar el estado.
(Me doy cuenta de que la imagen dice AWS, pero estoy trabajando sobre la base de que este podría ser el mismo requisito en Azure).
También he leído que, potencialmente, puede ser necesaria una puerta de enlace de datos de red virtual. Uso de la puerta de enlace de datos de red virtual y orígenes de datos en Power BI | Microsoft Learn, sin embargo, como no puedo configurar la configuración de la fuente de datos, debido al uso de informes paginados y DirectQuery, no estoy seguro de si esto funcionará.
Toda la documentación parece centrarse en Power BI Desktop (por ejemplo, Conectar Power BI a Azure Databricks - Azure Databricks | Microsoft Learn), y la documentación del Generador de informes que está disponible sobre este tema es mínima y breve en el mejor de los casos.
Una última cosa que hay que mencionar es que la creación de un modelo semántico intermedio, que esté conectado a la fuente, al que Report Builder podría conectarse no es una opción viable.
Si bien puede ser una solución, ¡y una que aún no he probado!, no será una solución que sea aceptada por los desarrolladores del informe.
¿Alguien se ha encontrado con este problema antes, específicamente con los informes paginados al usar DirectQuery para consultar esquemas de Unity Catalog en Azure Databricks y, si es así, podría ofrecer algunos consejos?
Gracias de antemano por cualquier ayuda que se pueda ofrecer ✌️
3 Replies
Hola @Node4Ben ,
Hemos trasladado su publicación al foro correspondiente del servidor de informes. Habrá más usuarios o publicaciones relacionadas aquí para ayudarte. Las siguientes son sugerencias iniciales.
En primer lugar, asegúrese de que la instancia de Azure Databricks tiene el inicio de sesión único (SSO) de AAD configurado correctamente. Esta es clave para pasar credenciales de usuario a través de DirectQuery. En segundo lugar, la opción "Los visores de informes solo pueden acceder a este origen de datos a través de DirectQuery con su propia identidad de Power BI" no se puede habilitar sin un modelo semántico. Se trata de una limitación cuando se usan informes paginados en Power BI. Puede considerar formas alternativas de administrar la seguridad de nivel de fila (RLS) directamente en Databricks.
También puede obtener más ayuda revisando la siguiente documentaciónRLS en Databricks Unity Catalog y Power BI | Miles Cole
Utilice el modelo semántico de Power BI dentro de Power BI Re... - Comunidad de Microsoft FabricSaludos
Alberto HeSi esta publicación ayuda, considere Acéptalo como la solución para ayudar a los otros miembros a encontrarlo más rápidamente
Gracias por su respuesta.
Puedo confirmar que el SSO está configurado correctamente.
Lo probé mediante la implementación de un informe de Power BI Desktop, con un modelo semántico, y configuré el modelo semántico para usar la conexión a la nube configurada que intentaba usar con el informe paginado. Para mí, el nuevo informe mostraba solo los datos a los que podía acceder, y para otros evaluadores, mostraba los datos que solo se les permitía ver en la fuente. Esto también reafirmó que el RLS se configuró correctamente en el origen.
Creé una conexión que usaba una puerta de enlace de red virtual preconfigurada, con SSO habilitado para las consultas de DirectQuery, pero el informe paginado se bloqueó o falló. Para ser justos, se trata de una limitación documentada de los informes paginados (Conexión de informes paginados a orígenes de datos mediante Power Query - Power BI | Microsoft Learn), sin embargo, pasé esto por alto en mi investigación. La conexión de puerta de enlace de red virtual funcionó correctamente con el modelo semántico de prueba y se cumplió RLS en el origen al usar esta conexión.
Una vez confirmado que las conexiones a la nube actuales funcionan (en Power BI Desktop/modelos semánticos) y que la opción de puerta de enlace de red virtual no funciona con informes paginados, ahora he registrado esto con el soporte técnico de Microsoft.
Hola @Node4Ben
El problema se deriva del hecho de que el Generador de informes no admite el paso a través del inicio de sesión único (SSO) de Azure Active Directory (AAD) al conectarse a Azure Databricks a través de DirectQuery. A diferencia de Power BI, donde los modelos semánticos permiten aplicar la autenticación de nivel de usuario, los informes paginados con DirectQuery funcionan de forma diferente. Dado que no hay ningún modelo semántico para habilitar "Los visores de informes solo pueden acceder a este origen de datos con sus propias identidades de Power BI", la conexión se establece de forma predeterminada en las credenciales usadas al configurar el origen de datos. Es por eso que todos los usuarios ven los datos como si fueran tú. Una posible solución es habilitar el inicio de sesión único de cuenta en Databricks, que puede permitir la propagación de identidades, aunque esto necesita confirmación. Además, es posible que se requiera una puerta de enlace de datos de red virtual si el entorno de Databricks se encuentra dentro de una red protegida. Sin embargo, el enfoque nativo de Report Builder para consultar bases de datos, especialmente cuando se usa DirectQuery, no se integra completamente con el modelo de autenticación de Power BI. Si un modelo semántico intermedio no es una opción, es posible que tenga que explorar si las entidades de servicio o las directivas de acceso del catálogo de Databricks Unity se pueden aprovechar para la aplicación dinámica de la seguridad.
