View a markdown version of this page

Controlli di confronto - AWS Clean Rooms

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Controlli di confronto

In SQL, il confronto letterale confronta una colonna del set di dati con un valore letterale digitato direttamente nella query. Il confronto tra colonne confronta i valori di due colonne diverse, all'interno della stessa tabella o tra tabelle unite.

Comportamento predefinito

I controlli di confronto sono una lista consentita. Una volta impostatiallowedLiteralComparisonColumns, solo le colonne elencate possono essere confrontate con un valore letterale e ogni colonna non elencata viene bloccata. Lo stesso vale allowedColumnComparisonColumns per i confronti da colonna a colonna. L'aggiunta di una colonna a una lista consentita non la aggiunge all'altra.

Se non AWS Clean Rooms si configuracomparisonControls, non vengono applicate restrizioni di confronto: una query può confrontare qualsiasi colonna con un valore letterale o con un'altra colonna.

Se non si configura comparisonControls ma si imposta una soglia minima di aggregazione, per il resto i confronti rimangono illimitati. Tuttavia, AWS Clean Rooms non consente mai un confronto letterale su una colonna elencata in. identityColumns Tale restrizione deriva dalla soglia stessa, quindi si applica indipendentemente dal fatto che si configurino o meno i controlli di confronto. Per ulteriori informazioni, consulta Soglie minime di aggregazione.

Se si esegue la configurazione comparisonControls insieme a colonne di output non consentite, i due controlli sono indipendenti ed entrambi si applicano. I controlli di confronto determinano le colonne che una query può confrontare; le colonne di output non consentite determinano quali colonne possono apparire nel risultato dell'interrogazione. Una colonna può essere consentita in un confronto ed essere comunque esclusa dal risultato. Per ulteriori informazioni, consulta Colonne di output non consentite.

Confronto letterale

Un confronto letterale valuta una colonna rispetto a una singola costante codificata (una stringa, un numero o una data). Il lato destro dell'operatore non cambia mai durante l'esecuzione della query. Gli esempi di sintassi includono:

  • WHEREstatus = 'Attivo'

  • WHEREprezzo > 49,99

Quando si utilizzaSoglie minime di aggregazione, AWS Clean Rooms non consente il confronto letterale sul identityColumns valore. Ciò impedisce al Query Runner di inviare una query filtrata a un singolo utente o a un gruppo specifico di utenti. Evita di consentire il confronto letterale su colonne a bassa cardinalità che possono individuare piccoli gruppi o singoli interessati.

{ "comparisonControls": { "allowedLiteralComparisonColumns": [ "status", "price" ] } }
Scelta delle colonne per il confronto letterale

Consenti il confronto letterale solo su colonne che non identificano individui o piccoli gruppi. Evita di consentirlo su colonne a bassa cardinalità (ad esempio, age_band, codice regionale approssimativo). Anche se queste colonne non sono il identityColumns valore configurato, il confronto con valori letterali può restringere i risultati a una popolazione piccola e identificabile. High-cardinality, dimensioni non identificative come campaign_id o product_sku sono scelte più sicure.

Esempio: consentire il confronto letterale su una colonna della campagna

Un editore configura una regola di analisi personalizzata con una soglia minima di aggregazione in modo che ogni riga di output rappresenti almeno 100 utenti distinti (). user_id Un inserzionista esegue delle query su questa tabella, ma deve limitare la propria analisi a una specifica campagna pubblicitaria, ad esempio per misurare la copertura di una campagna alla volta.

Poiché user_id è la colonna dell'identità, non può essere paragonata a un valore letterale, impedendo all'inserzionista di filtrare i risultati fino a un singolo utente. event_dateSi tratta tuttavia di dimensioni ad alta cardinalità campaign_id e non identificative, per cui l'editore le aggiunge, il che consente all'allowedLiteralComparisonColumnsinserzionista di filtrare per campagna e circoscrivere l'analisi a un intervallo di date:

{ "aggregationThresholds": [ { "identityColumns": ["user_id"], "minimumIdentityCount": 100 } ], "comparisonControls": { "allowedLiteralComparisonColumns": ["campaign_id", "event_date"] } }

Data la configurazione precedente, questa interrogazione è consentita:

-- Allowed: campaign_id and event_date are both in allowedLiteralComparisonColumns SELECT campaign_id, COUNT(DISTINCT user_id) AS reach FROM impressions WHERE campaign_id = 'CMP-1024' AND event_date >= '2026-01-01' GROUP BY campaign_id;

Data la stessa configurazione, questa interrogazione è bloccata:

-- Blocked: user_id is the identity column and can never be compared to a literal SELECT campaign_id, COUNT(DISTINCT user_id) AS reach FROM impressions WHERE user_id = 'U-88231' GROUP BY campaign_id;

La prima query restituisce ancora solo le righe supportate da almeno 100 utenti distinti, mentre la ricerca letterale confronta campaign_id e event_date filtra le righe considerate. La seconda query viene rifiutata perché tenta di individuare un singolo interessato.

Confronto tra colonne

Un confronto tra colonne valuta il valore di una colonna rispetto al valore di un'altra colonna in modo dinamico per ogni singola riga. Gli esempi di sintassi includono:

  • WHEREprezzo_vendita al dettaglio < prezzo_all'ingrosso

  • WHEREusers.id = orders.user_id

Durante l'utilizzoSoglie minime di aggregazione, un fornitore di dati può consentire il confronto tra colonne sul identityColumns valore per i casi d'uso che richiedono l'unione tra tabelle, ad esempio un rapporto sulla sovrapposizione dell'audience.

{ "comparisonControls": { "allowedColumnComparisonColumns": [ "user_id" ] } }

Esempio: consentire il confronto tra colonne nella colonna di identità per un report di sovrapposizione

Un editore e un inserzionista vogliono misurare la sovrapposizione del pubblico, ossia quanti utenti compaiono in entrambi i set di dati, senza che nessuna delle parti sappia chi sia il singolo utente. Ciò richiede l'unione delle due tabelleuser_id, ovvero un confronto da colonna a colonna. Il publisher consente all'inserzionista di eseguire un'analisi della sovrapposizione del pubblico basata su ID di campagna specifici.

Poiché user_id si tratta della colonna relativa all'identità, l'editore ha già bloccato i confronti letterali su di essa (quindi nessuno può filtrare in base a una persona specifica). Per abilitare l'unione tra tabelle, l'editore aggiunge user_id a. allowedColumnComparisonColumns Per abilitare il filtro delle campagne, l'editore aggiunge campaign_id aallowedLiteralComparisonColumns.

{ "aggregationThresholds": [ { "identityColumns": ["user_id"], "minimumIdentityCount": 100 } ], "comparisonControls": { "allowedLiteralComparisonColumns": ["campaign_id"], "allowedColumnComparisonColumns": ["user_id"] } }

Data la configurazione precedente, questa interrogazione è consentita:

-- Allowed: user_id is compared against another column (column-to-column join) SELECT COUNT(DISTINCT p.user_id) AS overlapping_users FROM publisher_audience p JOIN advertiser_audience a ON p.user_id = a.user_id;

Data la stessa configurazione, questa interrogazione è bloccata:

-- Blocked: email is not in allowedColumnComparisonColumns SELECT COUNT(DISTINCT p.user_id) AS overlapping_users FROM publisher_audience p JOIN advertiser_audience a ON p.email = a.email;

L'unione ha esito positivo perché un confronto da colonna a colonna valuta dinamicamente per riga e non consente al gestore della query di scegliere come target un valore noto. Il risultato impone la soglia minima di aggregazione, garantendo che il conteggio delle sovrapposizioni venga restituito solo se rappresenta almeno 100 utenti distinti. La seconda query è bloccata perché non email è presente nella allowedColumnComparisonColumns lista consentita e non può essere utilizzata in un confronto, ma solo. user_id

Controlli ed espressioni di confronto

I controlli di confronto seguono confronti letterali indiretti, non solo un predicato diretto WHEREcolumn = 'literal'. Se si autorizzano le funzioni aggregate ANY_EXPRESSION interneallowedAggregateExpressionType, i controlli di confronto bloccano comunque un confronto letterale su una colonna che non è presente. allowedLiteralComparisonColumns Ciò vale anche quando il valore letterale è annidato all'interno di un'espressione.

L'esempio seguente mostra una query che rimane bloccata perché non zip_code è nella lista consentita, anche se il valore letterale è all'interno di un'CASEespressione anziché scritto come predicato diretto:

-- Blocked: zip_code is not in allowedLiteralComparisonColumns, -- even though the literal comparison is nested inside a CASE expression SELECT SUM(CASE WHEN zip_code = '00001' THEN salary ELSE 0 END) AS total FROM employees;

Ecco perché i due controlli sono complementari: consentire espressioni all'interno di aggregati amplia ciò che una query può calcolare, mentre i controlli di confronto limitano ancora le colonne che una query può individuare in base al valore. Per ulteriori informazioni, consulta Consentire espressioni annidate nelle funzioni aggregate.