Condividi tramite

Filtrare i dati delle tabelle sensibili usando filtri di riga e maschere di colonna

  • Articolo

Questo articolo fornisce indicazioni ed esempi per l'uso di filtri di riga, maschere di colonna e tabelle di mapping per filtrare i dati sensibili nelle tabelle. Queste funzionalità richiedono il catalogo Unity.

Che cosa sono i filtri di riga?

I filtri di riga consentono di applicare un filtro a una tabella in modo che le query restituisca solo righe che soddisfano i criteri di filtro. Si implementa un filtro di riga come funzione definita dall'utente SQL. Sono supportate anche funzioni definite dall'utente Python e Scala, ma solo quando vengono incluse in funzioni definite dall'utente sql.

Che cosa sono le maschere di colonna?

Le maschere di colonna consentono di applicare una funzione di maschera a una colonna di tabella. La funzione masking valuta in fase di esecuzione della query, sostituendo ogni riferimento della colonna di destinazione con i risultati della funzione di mascheramento. Per la maggior parte dei casi d'uso, le maschere di colonna determinano se restituire il valore della colonna originale o modificarlo in base all'identità dell'utente chiamante. Le maschere di colonna sono espressioni scritte come funzioni definite dall'utente di SQL o come funzioni definite dall'utente Python o Scala di cui viene eseguito il wrapping nelle funzioni definite dall'utente SQL.

A ogni colonna della tabella può essere applicata una sola funzione di maschera. La funzione masking accetta il valore non mascherato della colonna come input e restituisce il valore mascherato come risultato. Il valore restituito della funzione masking deve essere lo stesso tipo della colonna mascherata. La funzione di mascheramento può anche accettare colonne aggiuntive come parametri di input e usarle nella logica di maschera.

Qual è la differenza tra questi filtri e le visualizzazioni dinamiche?

Le visualizzazioni dinamiche, i filtri di riga e le maschere di colonna consentono di applicare logica complessa alle tabelle ed elaborare le decisioni di filtro in fase di esecuzione delle query.

Una visualizzazione dinamica è una vista astratta di sola lettura di una o più tabelle di origine. L'utente può accedere a una visualizzazione dinamica senza avere accesso diretto alle tabelle di origine. La creazione di una vista dinamica definisce un nuovo nome di tabella che non deve corrispondere al nome di tabelle di origine o di altre tabelle e viste presenti nello stesso schema.

D'altra parte, l'associazione di un filtro di riga o di una maschera di colonna a una tabella di destinazione applica la logica corrispondente direttamente alla tabella stessa senza introdurre nuovi nomi di tabella. Le query successive possono continuare a fare riferimento direttamente alla tabella di destinazione usando il nome originale.

Usare le visualizzazioni dinamiche se è necessario applicare la logica di trasformazione, ad esempio filtri e maschere alle tabelle di sola lettura, e se è accettabile che gli utenti facciano riferimento alle visualizzazioni dinamiche usando nomi diversi. Se si desidera filtrare i dati quando lo si condivide usando la condivisione differenziale, è necessario usare le visualizzazioni dinamiche. Usare filtri di riga e maschere di colonna se si desidera filtrare o calcolare espressioni su dati specifici, ma fornire comunque agli utenti l'accesso alle tabelle usando i nomi originali.

Operazioni preliminari

Per aggiungere filtri di riga e maschere di colonna alle tabelle, è necessario disporre di:

  • Un'area di lavoro abilitata per il catalogo Unity
  • Funzione registrata in Unity Catalog. Può trattarsi di una funzione definita dall'utente sql o di una funzione definita dall'utente Python o Scala registrata nel catalogo unity e di cui è stato eseguito il wrapping in una funzione definita dall'utente SQL. Per informazioni dettagliate, vedere Che cosa sono le funzioni definite dall'utente?, la clausola Column mask e la clausola FILTRO DI RIGA.

Si devono soddisfare anche i requisiti seguenti:

  • Per assegnare una funzione che aggiunge filtri di riga o maschere di colonna a una tabella, è necessario disporre del privilegio EXECUTE per la funzione, USE SCHEMA nello schema e USE CATALOG nel catalogo padre.
  • Se si aggiungono filtri o maschere quando si crea una nuova tabella, è necessario disporre del privilegio CREATE TABLE per lo schema.
  • Se si aggiungono filtri o maschere a una tabella esistente, è necessario essere il proprietario della tabella o disporre dei privilegi MODIFY e SELECT nella tabella.

Per accedere a una tabella con filtri di riga o maschere di colonna, la risorsa di calcolo deve soddisfare uno dei requisiti seguenti:

  • Un'istanza di SQL Warehouse.

  • Modalità di accesso condiviso in Databricks Runtime 12.2 LTS o versione successiva.

  • Modalità di accesso utente singolo in Databricks Runtime 15.4 LTS o versione successiva.

    Non è possibile leggere filtri di riga o maschere di colonna usando il calcolo utente singolo in Databricks Runtime 15.3 o versione successiva.

    Per sfruttare i vantaggi del filtro dei dati fornito in Databricks Runtime 15.4 LTS e versioni successive, è anche necessario verificare che l'area di lavoro sia abilitata per il calcolo serverless, perché la funzionalità di filtro dei dati che supporta filtri di riga e maschere di colonna viene eseguita nel calcolo serverless. È quindi possibile che vengano addebitati costi per le risorse di calcolo serverless quando si usa il calcolo utente singolo per leggere le tabelle che usano filtri di riga o maschere di colonna. Vedere Controllo di accesso con granularità fine per il calcolo di un singolo utente.

Applica un filtro della riga

Per creare un filtro di riga, scrivere una funzione (UDF) per definire i criteri di filtro e quindi applicarla a una tabella. Ogni tabella può avere solo un filtro di riga. Un filtro di riga accetta zero o più parametri di input in cui ogni parametro di input è associato a una colonna della tabella corrispondente.

È possibile applicare un filtro di riga usando Esplora cataloghi o comandi SQL. Le istruzioni di Esplora cataloghi presuppongono che sia già stata creata una funzione e che sia registrata in Unity Catalog. Le istruzioni SQL includono esempi di creazione di una funzione di filtro di riga e applicazione a una tabella.

Esplora cataloghi

  1. Nell'area di lavoro di Azure Databricks fare clic su Icona catalogo Catalogo.
  2. Individuare o cercare la tabella da filtrare.
  3. Nella scheda Panoramica fare clic su Filtro di riga: Aggiungi filtro.
  4. Nella finestra di dialogo Aggiungi filtro di riga selezionare il catalogo e lo schema che contengono la funzione di filtro, quindi selezionare la funzione .
  5. Nella finestra di dialogo espansa visualizzare la definizione della funzione e selezionare le colonne della tabella corrispondenti alle colonne incluse nell'istruzione della funzione.
  6. Fare clic su Aggiungi.

Per rimuovere il filtro dalla tabella, fare clic su Filtro riga fx e fare clic su Rimuovi.

SQL

Per creare un filtro di riga e quindi aggiungerlo a una tabella esistente, usare CREATE FUNCTION e applicare la funzione usando ALTER TABLE. È anche possibile applicare una funzione quando si crea una tabella usando CREATE TABLE.

  1. Creare il filtro di riga:

    CREATE FUNCTION <function_name> (<parameter_name> <parameter_type>, ...)
RETURN {filter clause whose output must be a boolean};

  2. Applicare il filtro di riga a una tabella usando un nome di colonna:

    ALTER TABLE <table_name> SET ROW FILTER <function_name> ON (<column_name>, ...);

Esempi di sintassi aggiuntivi:

  • Applicare il filtro di riga a una tabella usando un valore letterale costante che corrisponde a un parametro di funzione:

    ALTER TABLE <table_name> SET ROW FILTER <function_name> ON (<constant_literal>, ...);

  • Rimuovere un filtro di riga da una tabella:

    ALTER TABLE <table_name> DROP ROW FILTER;

  • Modificare un filtro di riga:

    Run a DROP FUNCTION statement to drop the existing function, or use CREATE OR REPLACE FUNCTION to replace it.

  • Eliminare un filtro di riga:

    ALTER TABLE <table_name> DROP ROW FILTER;
DROP FUNCTION <function_name>;

    Nota

    È necessario eseguire il comando ALTER TABLE ... DROP ROW FILTER prima di eliminare la funzione. In caso contrario, la tabella sarà inaccessibile.

    Se la tabella diventa inaccessibile in questo modo, modificare la tabella ed eliminare il riferimento al filtro di riga orfano usando ALTER TABLE <table_name> DROP ROW FILTER;.

Vedere anche clausola FILTRO DI RIGA.

Esempi di filtro di riga

In questo esempio viene creata una funzione sql definita dall'utente che si applica ai membri del gruppo admin nell'area US.

Quando questa funzione di esempio viene applicata alla tabella sales, i membri del gruppo admin possono accedere a tutti i record nella tabella. Se la funzione viene chiamata da un non amministratore, la condizione RETURN_IF ha esito negativo e l'espressione region='US' viene valutata, filtrando la tabella in modo da visualizzare solo i record nell'area US.

CREATE FUNCTION us_filter(region STRING)
RETURN IF(IS_ACCOUNT_GROUP_MEMBER('admin'), true, region='US');

Applicare la funzione a una tabella come filtro di riga. Le query successive dalla tabella sales restituiscono quindi un subset di righe.

CREATE TABLE sales (region STRING, id INT);
ALTER TABLE sales SET ROW FILTER us_filter ON (region);

Disabilitare il filtro di riga. Le query utente future dalla tabella sales restituiscono quindi tutte le righe della tabella.

ALTER TABLE sales DROP ROW FILTER;

Creare una tabella con la funzione applicata come filtro di riga come parte dell'istruzione CREATE TABLE. Le query future dalla tabella sales restituiscono quindi un subset di righe.

CREATE TABLE sales (region STRING, id INT)
WITH ROW FILTER us_filter ON (region);

Applicare una maschera di colonna

Per applicare una maschera di colonna, creare una funzione (UDF) e quindi applicarla a una colonna di tabella.

È possibile applicare una maschera di colonna usando Esplora cataloghi o i comandi SQL. Le istruzioni di Esplora cataloghi presuppongono che sia già stata creata una funzione e che sia registrata in Unity Catalog. Le istruzioni SQL includono esempi di creazione di una funzione maschera di colonna e applicazione a una colonna di tabella.

Esplora cataloghi

  1. Nell'area di lavoro di Azure Databricks fare clic su Icona catalogo Catalogo.
  2. Esplorare o ricercare la tabella.
  3. Nella scheda Panoramica individuare la riga a cui applicare la maschera di colonna e fare clic sull'icona di modifica Icona Modifica Maschera.
  4. Nella finestra di dialogo Aggiungi maschera di colonna selezionare il catalogo e lo schema che contengono la funzione di filtro, quindi selezionare la funzione.
  5. Nella finestra di dialogo espansa visualizzare la definizione della funzione. Se la funzione include parametri oltre alla colonna mascherata, selezionare le colonne della tabella a cui si desidera eseguire il cast di tali parametri di funzione aggiuntivi.
  6. Fare clic su Aggiungi.

Per rimuovere la maschera di colonna dalla tabella, fare clic su Maschera colonna fx nella riga della tabella e fare clic su Rimuovi.

SQL

Per creare una maschera di colonna e aggiungerla a una colonna di tabella esistente, usare CREATE FUNCTION e applicare la funzione di maschera tramite ALTER TABLE. È anche possibile applicare una funzione quando si crea una tabella usando CREATE TABLE.

Si usa SET MASK per applicare la funzione di mascheramento. All'interno della clausola MASK è possibile usare una qualsiasi delle funzioni di runtime predefinite di Azure Databricks o chiamare altre funzioni definite dall'utente. I casi d'uso comuni includono l'ispezione dell'identità dell'utente chiamante che esegue la funzione usando current_user( ) o ottenendo i gruppi di cui sono membri tramite is_account_group_member( ). Per informazioni dettagliate, vedere Clausola column mask e funzioni predefinite.

  1. Creare una maschera di colonna:

    CREATE FUNCTION <function_name> (<parameter_name> <parameter_type>, ...)
RETURN {expression with the same type as the first parameter};

  2. Applicare la maschera di colonna a una colonna in una tabella esistente:

    ALTER TABLE <table_name> ALTER COLUMN <col_name> SET MASK <mask_func_name> USING COLUMNS <additional_columns>;

Esempi di sintassi aggiuntivi:

  • Applicare la maschera di colonna a una colonna in una tabella esistente usando un valore letterale costante che corrisponde a un parametro di funzione:

    ALTER TABLE <table_name> ALTER COLUMN <col_name> SET MASK <mask_func_name> USING COLUMNS (<constant_name>, ...);

  • Rimuovere una maschera di colonna da una colonna in una tabella:

    ALTER TABLE <table_name> ALTER COLUMN <column where mask is applied> DROP MASK;

  • Modificare una maschera di colonna: DROP la funzione esistente o usare CREATE OR REPLACE TABLE.

  • Eliminare una maschera di colonna:

    ALTER TABLE <table_name> ALTER COLUMN <column where mask is applied> DROP MASK;
DROP FUNCTION <function_name>;

    Nota

    È necessario eseguire il comando ALTER TABLE prima di eliminare la funzione o la tabella sarà inaccessibile.

    Se la tabella diventa inaccessibile in questo modo, modificare la tabella ed eliminare il riferimento alla maschera orfana usando ALTER TABLE <table_name> ALTER COLUMN <column where mask is applied> DROP MASK;.

Esempi di maschera di colonna

In questo esempio viene creata una funzione definita dall'utente che maschera la colonna ssn in modo che solo gli utenti membri del gruppo HumanResourceDept possano visualizzare i valori in tale colonna.

CREATE FUNCTION ssn_mask(ssn STRING)
  RETURN CASE WHEN is_member('HumanResourceDept') THEN ssn ELSE '***-**-****' END;

Applicare la nuova funzione a una tabella come maschera di colonna. È possibile aggiungere la maschera di colonna quando si crea la tabella o dopo.

--Create the `users` table and apply the column mask in a single step:

CREATE TABLE users (
  name STRING,
  ssn STRING MASK ssn_mask);

--Create the `users` table and apply the column mask after:

CREATE TABLE users
  (name STRING, ssn STRING);

ALTER TABLE users ALTER COLUMN ssn SET MASK ssn_mask;

Le query su tale tabella restituiscono ora valori di colonna ssn mascherati quando l'utente che esegue query non è un membro del gruppo HumanResourceDept:

SELECT * FROM users;
  James  ***-**-****

Per disabilitare la maschera di colonna in modo che le query restituisca i valori originali nella colonna ssn:

ALTER TABLE users ALTER COLUMN ssn DROP MASK;

Usare le tabelle di mapping per creare un elenco di controllo di accesso

Per ottenere la sicurezza a livello di riga, è consigliabile definire una tabella di mapping (o un elenco di controllo di accesso). Ogni tabella di mapping è una tabella di mapping completa che codifica le righe di dati nella tabella originale sono accessibili a determinati utenti o gruppi. Le tabelle di mapping sono utili perché offrono una semplice integrazione con le tabelle dei fatti tramite join diretti.

Questa metodologia risulta utile nell'affrontare molti casi d'uso con requisiti personalizzati. Alcuni esempi:

  • Imposizione di restrizioni in base all'utente connesso, mantenendo al tempo stesso regole diverse per gruppi di utenti specifici.
  • Creazione di gerarchie complesse, ad esempio strutture organizzative, che richiedono set diversi di regole.
  • Replica di modelli di sicurezza complessi da sistemi di origine esterni.

Adottando le tabelle di mapping in questo modo, è possibile affrontare efficacemente questi scenari complessi e garantire implementazioni di sicurezza affidabili a livello di riga e a livello di colonna.

Esempi di tabelle di mapping

Usare una tabella di mapping per verificare se l'utente corrente si trova in un elenco:

USE CATALOG main;

Creare una nuova tabella di mapping:

DROP TABLE IF EXISTS valid_users;

CREATE TABLE valid_users(username string);
INSERT INTO valid_users
VALUES
  ('fred@databricks.com'),
  ('barney@databricks.com');

Creare un nuovo filtro:

Nota

Tutti i filtri vengono eseguiti con i diritti del definer, ad eccezione delle funzioni che controllano il contesto utente (ad esempio, le funzioni CURRENT_USER e IS_MEMBER ) eseguite come invoker.

In questo esempio la funzione verifica se l'utente corrente si trova nella valid_users tabella. Se l’utente viene trovato, la funzione restituisce true.

DROP FUNCTION IF EXISTS row_filter;

CREATE FUNCTION row_filter()
  RETURN EXISTS(
    SELECT 1 FROM valid_users v
    WHERE v.username = CURRENT_USER()
);

Nell'esempio seguente viene applicato il filtro di riga durante la creazione della tabella. È anche possibile aggiungere il filtro in un secondo momento usando un'istruzione ALTER TABLE. Quando si applica a un'intera tabella, usare la sintassi ON (). Per una riga specifica, usare ON (row);.

DROP TABLE IF EXISTS data_table;

CREATE TABLE data_table
  (x INT, y INT, z INT)
  WITH ROW FILTER row_filter ON ();

INSERT INTO data_table VALUES
  (1, 2, 3),
  (4, 5, 6),
  (7, 8, 9);

Selezione di dati dalla tabella. Deve restituire i dati solo se l'utente si trova nella tabella valid_users.

SELECT * FROM data_table;

Creare una tabella di mapping che include gli account che devono sempre avere accesso per visualizzare tutte le righe della tabella, indipendentemente dai valori delle colonne:

CREATE TABLE valid_accounts(account string);
INSERT INTO valid_accounts
VALUES
  ('admin'),
  ('cstaff');

Creare ora una funzione definita dall'utente SQL che restituisce true se i valori di tutte le colonne della riga sono minori di cinque o se l'utente chiamante è un membro della tabella di mapping precedente.

CREATE FUNCTION row_filter_small_values (x INT, y INT, z INT)
  RETURN (x < 5 AND y < 5 AND z < 5)
  OR EXISTS(
    SELECT 1 FROM valid_accounts v
    WHERE IS_ACCOUNT_GROUP_MEMBER(v.account));

Applicare infine la funzione definita dall'utente SQL alla tabella come filtro di riga:

ALTER TABLE data_table SET ROW FILTER row_filter_small_values ON (x, y, z);

Supporto e limitazioni

I filtri di riga e le maschere di colonna non sono supportati con tutte le funzionalità di Azure Databricks o in tutte le risorse di calcolo. Questa sezione elenca le funzionalità e le limitazioni supportate.

Funzionalità e formati supportati

Questo elenco di funzionalità supportate non è esaustivo. Alcuni elementi sono elencati perché non sono stati supportati durante l'anteprima pubblica.

  • Sono supportati i notebook di Databricks SQL e Databricks per i carichi di lavoro SQL.

  • Sono supportati i comandi DML da parte degli utenti con privilegi MODIFY. I filtri e le maschere vengono applicati ai dati letti da istruzioni UPDATE e DELETE e non vengono applicati ai dati scritti (incluso INSERT).

  • Formati di dati supportati:

    • Delta e Parquet per tabelle gestite ed esterne.
    • Più altri formati di dati per le tabelle esterne registrate in Unity Catalog tramite Lakehouse Federation.

  • I parametri dei criteri possono includere espressioni costanti (stringhe, numeri, intervalli, valori booleani, valori Null).

  • Le funzioni definite dall'utente SQL, Python e Scala sono supportate come funzioni di filtro di riga o maschera di colonna, purché siano registrate nel catalogo unity. Le funzioni definite dall'utente Python e Scala devono essere incapsulate in una funzione definita dall'utente SQL.

  • È possibile creare viste nelle tabelle che fanno riferimento a maschere di colonna o filtri di riga, ma non è possibile aggiungere maschere di colonna o filtri di riga a una vista.

  • I feed di dati delle modifiche delta Lake sono supportati purché lo schema sia compatibile con i filtri di riga e le maschere di colonna applicabili alla tabella di destinazione.

  • Le tabelle esterne sono supportate.

  • Il campionamento delle tabelle è supportato.

  • Le istruzioni MERGE sono supportate quando tabelle di origine, tabelle di destinazione o entrambi usano filtri di riga e maschere di colonna. Sono incluse le tabelle con funzioni di filtro di riga che contengono semplici sottoquery, ma esistono limitazioni elencate nella sezione seguente.

  • Le viste materializzate di Databricks SQL e le tabelle di streaming SQL di Databricks supportano filtri di riga e maschere di colonna (anteprima pubblica):

    • È possibile aggiungere filtri di riga e maschere di colonna a una vista materializzata o a una tabella di streaming sql di Databricks. Questa operazione deve essere eseguita in modo dichiarativo quando viene definita la vista materializzata o la tabella di streaming. Vedere CREATE MATERIALIZED VIEW o CREATE STREAMING TABLE.See CREATE MATERIALIZED VIEW or CREATE STREAMING TABLE.
    • È possibile definire viste materializzate Databricks SQL o tabelle di streaming in tabelle che includono filtri di riga e maschere di colonna.

  • Le viste materializzate e le tabelle di streaming dichiarate e pubblicate in Tabelle live Delta supportano filtri di riga o maschere di colonna (anteprima pubblica):

    • È possibile aggiungere filtri di riga e maschere di colonna a una vista materializzata o a una tabella di streaming Delta Live Tables.
    • È possibile definire viste materializzate Delta Live Tables o tabelle di streaming in tabelle che includono filtri di riga e maschere di colonna.

    Vedere Pubblicare tabelle con filtri di riga o maschere di colonna.

Considerazioni sulle prestazioni

I filtri di riga e le maschere di colonna garantiscono la visibilità dei dati assicurando che nessun utente possa visualizzare il contenuto dei valori delle tabelle di base prima di filtrare e mascherare le operazioni. Sono progettati per ottenere prestazioni buone in risposta alle query nei casi d'uso più comuni. Nelle applicazioni meno frequenti, in cui il motore di query deve scegliere tra ottimizzare le prestazioni delle query e proteggersi dalla perdita di informazioni dai valori filtrati/mascherati, prenderà sempre la decisione sicura a scapito di un certo impatto sulle prestazioni delle query. Per ridurre al minimo questo impatto sulle prestazioni, applicare i principi seguenti:

  • Usare funzioni di criteri semplici: le funzioni dei criteri con un minor numero di espressioni offrono in genere prestazioni migliori rispetto a espressioni più complesse. Evitare di usare tabelle di mapping e sottoquery di espressioni a favore di funzioni CASE semplici.
  • Ridurre il numero di argomenti della funzione: Azure Databricks non è in grado di ottimizzare i riferimenti di colonna alla tabella di origine risultante dagli argomenti della funzione dei criteri, anche se queste colonne non vengono altrimenti usate nella query. Usare le funzioni dei criteri con un minor numero di argomenti, perché le query di queste tabelle offrono prestazioni migliori.
  • Evitare di aggiungere filtri di riga con un numero eccessivo di congiunzioni AND: poiché ogni tabella supporta solo l'aggiunta al massimo di un filtro di riga, un approccio comune consiste nel combinare più funzioni dei criteri desiderate con AND. Tuttavia, per ogni congiunzione, le probabilità aumentano che le congiunzione includano componenti menzionati altrove in questa tabella che potrebbero influire sulle prestazioni, ad esempio l'uso di tabelle di mapping. Usare meno congiunzioni per migliorare le prestazioni.
  • Usare espressioni deterministiche che non possono generare errori nei criteri di tabella e nelle query da queste tabelle: alcune espressioni possono generare errori se gli input forniti non sono validi, ad esempio la divisione ANSI. In questi casi, il compilatore SQL non deve eseguire il push delle operazioni con tali espressioni (ad esempio filtri) troppo in basso nel piano di query, per evitare la possibilità di errori come "divisione per zero" che rivelano informazioni sui valori prima di filtrare e/o mascherare le operazioni. Usare espressioni deterministiche e mai generare errori, ad esempio try_divide in questo esempio.
  • Eseguire query di test sulla tabella per misurare le prestazioni: creare query realistiche che rappresentano il carico di lavoro previsto per la tabella con filtri di riga e/o maschere di colonna e misurare le prestazioni. Apportare piccole modifiche alle funzioni dei criteri e osservare i relativi effetti fino a raggiungere un buon equilibrio tra prestazioni ed espressività della logica di filtro e mascheramento.

Limitazioni

  • Le versioni di Databricks Runtime inferiori alla 12.2 LTS non supportano filtri di riga o maschere di colonna. Questi runtime hanno esito negativo in modo sicuro, ovvero se si tenta di accedere alle tabelle da versioni non supportate di questi runtime, non vengono restituiti dati.
  • La condivisione differenziale non funziona con le maschere di colonna o di sicurezza a livello di riga.
  • Non è possibile applicare maschere di sicurezza a livello di riga o di colonna a una visualizzazione.
  • Il tempo di spostamento non funziona con le maschere di colonna o di sicurezza a livello di riga.
  • L'accesso basato sul percorso ai file nelle tabelle con criteri non è supportato.
  • I criteri di filtro di riga o maschera di colonna con dipendenze circolari ai criteri originali non sono supportati.
  • I cloni profondi e superficiali non sono supportati.
  • Le istruzioni MERGE non supportano tabelle con criteri di filtro di riga che contengono annidamento, aggregazioni, finestre, limiti o funzioni non deterministiche.
  • Le API Delta Lake non sono supportate.

Limitazione delle risorse di calcolo per utente singolo

Non è possibile accedere a una tabella con filtri di riga o maschere di colonna da una singola risorsa di calcolo utente in Databricks Runtime 15.3 o versione successiva. È possibile usare la modalità di accesso utente singolo in Databricks Runtime 15.4 LTS o versione successiva, se l'area di lavoro è abilitata per il calcolo serverless. Per altre informazioni, vedere Controllo di accesso con granularità fine per il calcolo di un singolo utente.