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 mette a confronto 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 impostateallowedLiteralComparisonColumns, solo le colonne elencate possono essere confrontate con un valore letterale e tutte le colonne non elencate sono bloccate, ad eccezione dei confronti con valori sempre consentiti. Per ulteriori informazioni, consulta Valori letterali sempre consentiti. Lo stesso comportamento della lista consentita si applica ai confronti da colonna a colonna. allowedColumnComparisonColumns L'aggiunta di una colonna a una lista consentita non la aggiunge all'altra.

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

Se non si esegue la configurazione comparisonControls ma si imposta una soglia minima di aggregazione, i confronti rimangono altrimenti senza restrizioni. Tuttavia, AWS Clean Rooms non consente un confronto letterale su una colonna elencata in. identityColumns L'unica eccezione è rappresentata dai confronti con valori sempre consentiti. Tale restrizione deriva dalla soglia stessa, quindi si applica indipendentemente dalla configurazione o meno dei controlli di confronto. Per ulteriori informazioni, consulta Soglie minime di aggregazione e Valori letterali sempre consentiti.

Se si esegue la configurazione comparisonControls insieme a colonne di output non consentite, i due controlli sono indipendenti e si applicano entrambi. I controlli di confronto determinano quali colonne possono essere confrontate da una query; le colonne di output non consentite determinano quali colonne possono apparire nel risultato della query. È possibile consentire l'inserimento di una colonna in un confronto e continuare ad essere 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 (ad esempio, una stringa, un numero, una data, un valore booleano o). NULL 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, ad eccezione dei valori sempre consentiti (vedi). Valori letterali sempre consentiti Ciò consente di evitare che il Query Runner invii una query filtrata a un gruppo di utenti singolo o specifico. Evita di consentire il confronto letterale su colonne a bassa cardinalità che possono individuare piccoli gruppi o singoli soggetti di dati.

{ "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, coarse region code). Anche se queste colonne non sono il identityColumns valore configurato, il confronto con i 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.

Valori letterali sempre consentiti

AWS Clean Rooms consente sempre a una query di confrontare una colonna con i seguenti valori letterali, denominati valori sempre consentiti, anche se la colonna non è elencata o è elencata inallowedLiteralComparisonColumns: identityColumns

  • NULL, incluse e condizioni IS NULL IS NOT NULL

  • La stringa vuota ('')

  • I valori booleani e true false

  • Il numero zero in qualsiasi forma numerica, ad esempio0, 0.0 o. -0 La stringa '0' non è un numero, quindi segue i controlli di confronto.

Poiché questi valori sono fissi, un Query Runner non può modificarli per indirizzarli a un valore specifico nei dati.

Ciò si applica quando la colonna viene confrontata direttamente o all'interno di un'espressione comeCASE, IFCOALESCE, oUPPER. Se la colonna è racchiusa in un'altra funzione o in aritmetica (ad esempio, ABS(revenue) = 0 orevenue - 50 = 0), il confronto segue i controlli di confronto.

I confronti con qualsiasi altro valore letterale, inclusi altri numeri come, seguono i controlli di confronto e1, per le colonne di identità, la restrizione della soglia minima di aggregazione. Se configuri le soglie minime di aggregazione, queste si applicano comunque a ogni riga del risultato della query.

Ad esempio, ciascuna delle seguenti condizioni è consentita anche quando la colonna non è elencata in: allowedLiteralComparisonColumns

-- Allowed: comparisons against always-allowed values WHERE user_id IS NOT NULL WHERE revenue > 0 WHERE is_active = true

Ognuna delle seguenti condizioni è bloccata quando la colonna non è elencata inallowedLiteralComparisonColumns:

-- Blocked: other literal values, or a column wrapped in a function WHERE revenue > 1 WHERE status_code = '0' WHERE ABS(revenue) = 0

Esempio: consentire il confronto letterale su una colonna della campagna

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

Poiché user_id è la colonna dell'identità, non può essere confrontata con un valore letterale come un ID utente specifico. Questo aiuta a impedire all'inserzionista di filtrare i risultati fino a un singolo utente. Tuttavia, event_date si tratta di dimensioni con elevata cardinalità campaign_id e non identificative, quindi l'editore le aggiungeallowedLiteralComparisonColumns, il che consente all'inserzionista di filtrare per campagna e di limitare 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;

A parità di configurazione, questa interrogazione è bloccata:

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

La prima query restituisce comunque solo le righe supportate da almeno 100 utenti distinti, mentre i confronti letterali campaign_id e event_date filtrano le righe in base alle quali vengono prese in considerazione. La seconda interrogazione viene rifiutata perché tenta di individuare un singolo soggetto dei dati.

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:

  • WHEREretail_price < wholesale_price

  • WHEREusers.id = orders.user_id

Quando viene utilizzatoSoglie minime di aggregazione, un fornitore di dati può consentire il confronto tra colonne in base al identityColumns valore per i casi d'uso che richiedono l'unione di più tabelle, come un rapporto sulla sovrapposizione del pubblico.

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

Esempio: consentire il confronto delle colonne nella colonna Identity per un rapporto di sovrapposizione

Un publisher e un inserzionista vogliono misurare la sovrapposizione del pubblico, vale a dire quanti utenti compaiono in entrambi i set di dati, senza che nessuna delle parti scopra chi è ogni singolo utente. Ciò richiede l'unione delle due tabelleuser_id, che consiste in un confronto da colonna a colonna. L'editore consente all'inserzionista di eseguire un'analisi della sovrapposizione del pubblico mirata a ID di campagna specifici.

Poiché user_id è la colonna dell'identità, blocca AWS Clean Rooms già il confronto con un valore specifico, come un ID utente. Questo aiuta a evitare il filtraggio diretto a una sola persona. Per abilitare l'unione tra tabelle, l'editore aggiunge user_id aallowedColumnComparisonColumns. 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;

A parità di 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 viene valutato dinamicamente per riga e non consente al Query Runner di individuare un valore noto. Il risultato applica la soglia minima di aggregazione, garantendo che il conteggio delle sovrapposizioni venga restituito solo se rappresenta almeno 100 utenti distinti. La seconda interrogazione è bloccata perché non email è nella allowedColumnComparisonColumns lista consentita e non può essere utilizzata per un confronto, ma può solo farlo. user_id

Controlli ed espressioni di confronto

I controlli di confronto seguono confronti letterali indiretti, non solo un predicato diretto WHEREcolumn = 'literal'. Se consenti l'utilizzo delle funzioni aggregate ANY_EXPRESSION interneallowedAggregateExpressionType, i controlli di confronto bloccano comunque un confronto letterale su una colonna che non è presente. allowedLiteralComparisonColumns Questo vale anche quando il valore letterale è annidato all'interno di un'espressione. AWS Clean Rooms consente comunque confronti con valori sempre consentiti all'interno di espressioni come,, e. CASE IF COALESCE UPPER Ad esempio, è consentito. SUM(CASE WHEN bonus = 0 THEN salary ELSE 0 END) Per ulteriori informazioni, consulta Valori letterali sempre consentiti.

L'esempio seguente mostra una query che rimane bloccata perché non zip_code è nella lista consentita, anche se il valore letterale si trova all'interno di un'CASEespressione anziché essere 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;

Questo è il motivo per cui i due controlli sono complementari: consentire espressioni all'interno degli aggregati amplia ciò che una query può calcolare, mentre i controlli di confronto limitano comunque le colonne che una query può individuare in base al valore. Per ulteriori informazioni, consulta Consentire espressioni annidate nelle funzioni aggregate.