Control de acceso específico en un solo proceso de usuario

En este artículo se presenta la funcionalidad de filtrado de datos que permite un control de acceso específico en las consultas que se ejecutan en un solo proceso de usuario (todo uso o trabajos calculados configurados con el modo de acceso de usuario único). Consulte Modos de acceso.

Este filtrado de datos se realiza en segundo plano mediante el proceso sin servidor.

¿Por qué algunas consultas en un solo proceso de usuario requieren filtrado de datos?

Unity Catalog permite controlar el acceso a los datos tabulares en el nivel de column y fila (también conocido como control de acceso específico) mediante las siguientes características:

• views dinámicas
• Filtros de fila y máscaras de column

Cuando los usuarios realizan consultas de views que excluyen datos referenciados de tables o de tables que aplica filtros y máscaras, pueden usar cualquiera de los siguientes recursos de computación sin limitaciones.

• Almacenes de SQL
• Proceso compartido

Sin embargo, si usa un único proceso de usuario para ejecutar estas consultas, el proceso y el área de trabajo deben cumplir requisitos específicos:

• El recurso de proceso de usuario único debe estar en Databricks Runtime 15.4 LTS o superior.

• El área de trabajo debe estar habilitada para el proceso sin servidor en trabajos, cuadernos y en Delta Live Tables.

  Para confirmar que la región del área de trabajo admite el proceso sin servidor, consulte Características con disponibilidad regional limitada.

Si su recurso de cálculo para un único usuario y su área de trabajo cumplen con estos requisitos, el filtrado de datos se ejecuta automáticamente siempre que consulte una vista o table que utilice control de acceso detallado.

Compatibilidad con views materializadas, tables de streaming y views estándar

Además de las views dinámicas, los filtros de fila y las máscaras de column, el filtrado de datos también habilita las consultas en las siguientes views y tables que no se admiten en el proceso de un solo usuario que ejecuta Databricks Runtime 15.3 y versiones anteriores:

• Estándar views

  En el proceso de un solo usuario que ejecuta Databricks Runtime 15.3 y versiones posteriores, el usuario que ejecuta la consulta en la vista debe tener SELECT en las tables y views a las que hace referencia la vista, lo que significa que no puede usar views para proporcionar un control de acceso específico. En Databricks Runtime 15.4 con filtrado de datos, el usuario que consulta la vista no necesita acceso a las tables y views a las que se hace referencia.

• tables de streaming

• views materializadas

¿Cómo funciona el filtrado de datos en un solo proceso de usuario?

Cada vez que una consulta accede a los siguientes objetos de base de datos, el recurso de proceso de usuario único pasa la consulta a un proceso sin servidor para realizar el filtrado de datos:

• Views creadas sobre tables en las que el usuario no tiene el privilegio en SELECT
• views dinámicas
• Tables con filtros de fila o máscaras de column definidas
• views materializadas y tables de streaming

En el diagrama siguiente, un usuario tiene SELECT en table_1, view_2, y table_w_rls, que tiene aplicados filtros de fila. El usuario no tiene SELECT en table_2, al que hace referencia view_2.

El recurso de proceso de usuario único controla completamente la consulta en table_1 , ya que no se requiere ningún filtrado. Las consultas en view_2 y table_w_rls requieren el filtrado de datos para devolver los datos a los que el usuario tiene acceso. Estas consultas se controlan mediante la funcionalidad de filtrado de datos en el proceso sin servidor.

¿En qué costos se incurre?

Los clientes se cobran por los recursos de proceso sin servidor que se usan para realizar operaciones de filtrado de datos. Para obtener información sobre los precios, consulte Niveles de plataforma y complementos.

Puede consultar la table de uso de facturación del sistema para ver cuánto se le ha cargado. Por ejemplo, la consulta siguiente desglosa los costos de proceso por usuario:

SELECT usage_date,
sku_name,
 identity_metadata.run_as,
SUM(usage_quantity) AS `DBUs consumed by FGAC`
FROM system.billing.usage
WHERE usage_date BETWEEN '2024-08-01' AND '2024-09-01'
 AND billing_origin_product = 'FINE_GRAINED_ACCESS_CONTROL'
GROUP BY 1, 2, 3 ORDER BY 1;

Visualización del rendimiento de las consultas cuando se activa el filtrado de datos

La interfaz de usuario de Spark para el proceso de un solo usuario muestra las métricas que puede usar para comprender el rendimiento de las consultas. Para cada consulta que se ejecuta en el recurso de proceso, la pestaña SQL/Dataframe muestra la representación del grafo de consulta. Si una consulta participaba en el filtrado de datos, la interfaz de usuario muestra un nodo de operador RemoteSparkConnectScan en la parte inferior del gráfico. Ese nodo muestra las métricas que puede usar para investigar el rendimiento de las consultas. Consulte Ver información de proceso en la interfaz de usuario de Apache Spark.

Expanda el nodo operador RemoteSparkConnectScan para ver las métricas que abordan preguntas como las siguientes:

• ¿Cuánto tiempo tarda el filtrado de datos? Ver "tiempo total de ejecución remota".
• ¿Cuántas filas permanecen después del filtrado de datos? Ver "salida de filas".
• ¿Cuántos datos (en bytes) se devolvieron después del filtrado de datos? Ver "tamaño de salida de filas".
• ¿Cuántos archivos de datos se eliminaron por partition y no tenían que leerse desde el almacenamiento? Vea "Archivos podados" y "Tamaño de los archivos podados".
• ¿Cuántos archivos de datos no se pudieron eliminar y tenían que leerse desde el almacenamiento? Vea "Archivos leídos" y "Tamaño de los archivos leídos".
• De los archivos que tenían que leerse, ¿cuántos ya estaban en la memoria caché? Vea "Tamaño de aciertos de caché" y "Tamaño de errores de caché".

Limitaciones

• No se admiten operaciones de escritura o refreshtable en tables que tengan aplicados filtros de fila o máscaras de column.

  En concreto, no se admiten las operaciones DML, como INSERT,,DELETE, UPDATE, REFRESH TABLE, y MERGE. Solo puedes leer (SELECT) de estas tables.

• Las autocombinaciones se bloquean de forma predeterminada cuando se llama al filtrado de datos, pero se pueden permitir estableciendo spark.databricks.remoteFiltering.blockSelfJoins en false en el proceso en el que se ejecutan estos comandos.

  Antes de habilitar las autocombinaciones en un recurso de proceso de un solo usuario, tenga en cuenta que una consulta de autojoin controlada por la funcionalidad de filtrado de datos podría devolver diferentes instantáneas de la misma table remota.