Pular para o conteúdo principal

Controle de acesso refinado em sistemas dedicados compute

O controle de acesso refinado permite restringir o acesso a visualizações específicas de uso de dados, filtros de linha e máscaras de coluna. Esta página explica como o serverless compute é usado para impor controles de acesso refinados no recurso dedicado compute.

nota

Dedicado compute é multifuncional ou Job compute configurado com o modo de acesso Dedicado (anteriormente, modo de acesso de usuário único). Consulte Modos de acesso.

Requisitos​

Para usar o site compute dedicado para consultar um view ou uma tabela com controles de acesso refinados:

Se o seu compute recurso dedicado e o workspace atenderem a esses requisitos, a filtragem de dados será executada automaticamente.

Como a filtragem de dados funciona no dedicado compute​

Sempre que uma consulta acessa um objeto de banco de dados com controles de acesso refinados, o recurso dedicado compute passa a consulta para o seu workspace's serverless compute para realizar a filtragem de dados. Os dados filtrados são então transferidos entre o serverless e o compute dedicado usando arquivos temporários no armazenamento em nuvem interno do workspace.

Essa funcionalidade se aplica aos seguintes objetos de banco de dados:

No diagrama a seguir, um usuário tem o privilégio SELECT em table_1, view_2 e table_w_rls, que tem filtros de linha aplicados. O usuário não tem o privilégio SELECT em table_2, que é referenciado por view_2.

Diagrama que mostra como a filtragem de dados funciona

A consulta em table_1 é tratada inteiramente pelo recurso dedicado compute, pois não é necessária nenhuma filtragem. As consultas em view_2 e table_w_rls exigem filtragem de dados para retornar os dados aos quais o usuário tem acesso. Essas consultas são tratadas pelo recurso de filtragem de dados em serverless compute.

Suporte para operações de gravação​

info

Visualização

Esse recurso está em Public Preview.

Em Databricks Runtime 16.3 e acima, o senhor pode gravar em tabelas que tenham filtros de linha ou máscaras de coluna aplicados, usando essas opções:

  • O comando MERGE INTO SQL, que o senhor pode usar para obter as funcionalidades INSERT, UPDATE e DELETE.
  • O site Delta merge operações.
  • A API DataFrame.write.mode("append").

sem servidor compute custos​

Os clientes são cobrados pelo recurso serverless compute que realiza operações de filtragem de dados. Para obter informações sobre preços, consulte Platform Tiers and Add-Ons.

Os usuários com acesso podem consultar a tabela system.billing.usage para ver quanto foram cobrados. Por exemplo, a consulta a seguir detalha os custos do compute por usuário:

SQL
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;

desempenho da consulta de visualização quando a filtragem de dados está ativada​

O site Spark UI para compute dedicado exibe métricas que o senhor pode usar para entender o desempenho de suas consultas. Para cada consulta que o senhor executar no recurso compute, o SQL/Dataframe tab exibe a representação gráfica da consulta. Se uma consulta estiver envolvida na filtragem de dados, a interface do usuário exibirá um nó de operador RemoteSparkConnectScan na parte inferior do gráfico. Esse nó exibe métricas que o senhor pode usar para investigar o desempenho da consulta. Consulte a visualização de compute informações na UI de Apache Spark.

SparkUI mostrando o nó RemoteSparkConnectScan

Expanda o nó do operador RemoteSparkConnectScan para ver as métricas que abordam questões como as seguintes:

  • Quanto tempo demorou a filtragem de dados? visualizar "tempo total de execução remota".
  • Quantas linhas permaneceram após a filtragem de dados? visualizar "saída de linhas".
  • Quantos dados (em bytes) foram retornados após a filtragem de dados? visualizar "tamanho da saída das linhas".
  • Quantos arquivos de dados foram removidos por partição e não precisaram ser lidos do armazenamento? visualize "Files pruned" (Arquivos removidos) e "Size of files pruned" (Tamanho dos arquivos removidos).
  • Quantos arquivos de dados não puderam ser removidos e precisaram ser lidos do armazenamento? visualize "Files read" (Arquivos lidos) e "Size of files read" (Tamanho dos arquivos lidos).
  • Dos arquivos que precisavam ser lidos, quantos já estavam no cache? visualize "Cache hits size" e "Cache misses size".

Limitações​

  • O catálogo default (spark.sql.catalog.spark_catalog) não pode ser modificado.

  • Não há suporte para comandos DDL, como ALTER TABLE ou DESCRIBE TABLE.

  • Em Databricks Runtime 16.2 e abaixo, não há suporte para operações de gravação ou refresh em tabelas que tenham filtros de linha ou máscaras de coluna aplicados.

    Especificamente, as operações DML, como INSERT, DELETE, UPDATE, REFRESH TABLE e MERGE, não são compatíveis. Você só pode ler (SELECT) dessas tabelas.

  • Em Databricks Runtime 16.2 e abaixo, o self-join é bloqueado por default quando a filtragem de dados é chamada porque essas consultas podem retornar diferentes Snapshot da mesma tabela remota. No entanto, o senhor pode ativar essas consultas definindo spark.databricks.remoteFiltering.blockSelfJoins como false em compute no qual está executando esse comando.

    Em Databricks Runtime 16.3 e acima, o Snapshot é sincronizado automaticamente entre o dedicado e serverless compute recurso. Devido a essa sincronização, as consultas autojoin que usam a funcionalidade de filtragem de dados retornam Snapshot idênticos e são ativadas por default. As exceções são a visualização materializada e qualquer visualização, visualização materializada e tabelas de transmissão compartilhadas usando Delta Sharing. Para esses objetos, o self-join é bloqueado por default, mas é possível habilitar essas consultas definindo spark.databricks.remoteFiltering.blockSelfJoins como false em compute no qual o comando está sendo executado.

    Se o senhor ativar as consultas autojoin para a visualização materializada e qualquer visualização, visualização materializada e tabelas de transmissão, deverá garantir que não haja gravações concorrentes nos objetos que estão sendo unidos.

  • Não há suporte em Docker Image.

  • Se o seu workspace foi implantado com um firewall antes de novembro de 2024, o senhor deve abrir as portas 8443 e 8444 para permitir o controle de acesso refinado no compute dedicado. Consulte Grupos de segurança.

Última atualização em