Pular para o conteúdo principal

Controle de acesso refinado em compute dedicado (anteriormente, usuário único compute)

Este artigo apresenta a funcionalidade de filtragem de dados que permite o controle de acesso refinado em consultas que são executadas em compute dedicado. Dedicado compute é multifuncional ou Job compute configurado com o modo de acesso Dedicado . Consulte Modos de acesso.

A funcionalidade de filtragem de dados é executada automaticamente usando o site serverless compute.

Por que algumas consultas no site dedicado compute exigem filtragem de dados?​

Unity Catalog permite controlar o acesso a dados tabulares no nível da coluna e da linha (também conhecido como controle de acesso refinado) usando o seguinte recurso:

Quando o senhor consulta um view que exclui dados de tabelas referenciadas ou consulta tabelas que aplicam filtros e máscaras, pode usar qualquer um dos seguintes compute recursos sem limitações:

  • SQL warehouses
  • Padrão compute (anteriormente compartilhado compute)

No entanto, se o senhor usar o compute dedicado para executar essas consultas, o compute e o workspace deverão atender a requisitos específicos:

Se o compute recurso e o workspace dedicados atenderem a esses requisitos, a filtragem de dados será executada automaticamente sempre que o senhor consultar um view ou uma tabela que use controle de acesso refinado.

Suporte para visualização materializada, tabelas de transmissão e visualização padrão​

Além da visualização dinâmica, os filtros de linha e a filtragem de dados de mascaramento de coluna também permitem consultas na visualização e nas tabelas a seguir que não são compatíveis com o site dedicado compute que está executando o Databricks Runtime 15.3 e abaixo:

No site compute dedicado que executa o Databricks Runtime 15.3 e abaixo, o usuário que executa a consulta no view deve ter SELECT nas tabelas e na visualização referenciadas pelo view, o que significa que não é possível usar a visualização para fornecer controle de acesso refinado. No site Databricks Runtime 15.4 com filtragem de dados, o usuário que consulta o site view não precisa acessar as tabelas e a visualização referenciadas.

Como funciona a filtragem de dados no site dedicado compute?​

Sempre que uma consulta acessa os seguintes objetos de banco de dados, o recurso dedicado compute passa a consulta para serverless compute para realizar a filtragem de dados:

  • visualização criada sobre tabelas nas quais o usuário não tem o privilégio SELECT
  • Visualização dinâmica
  • Tabelas com filtros de linha ou máscaras de coluna definidos
  • Visualização materializada e tabelas de transmissão

No diagrama a seguir, um usuário tem SELECT em table_1, view_2 e table_w_rls, que têm filtros de linha aplicados. O usuário não tem 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.

Quais custos são incorridos?​

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

Você pode consultar a tabela de uso do faturamento do sistema para ver quanto foi cobrado. 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​

  • Não há suporte para operações de gravação ou refresh em tabelas que tenham filtros de linha ou máscaras de coluna aplicadas.

    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