Utilizzare gli analizzatori di testo
L'istruzione DDL CREATE SEARCH INDEX
, la funzione SEARCH
e la funzione TEXT_ANALYZE
supportano le opzioni di configurazione avanzata dell'analisi del testo. Comprendere gli analizzatori di testo di BigQuery e le relative opzioni ti consente di perfezionare la tua esperienza di ricerca.
Questo documento fornisce una panoramica dei diversi analizzatori di testo disponibili in BigQuery e delle relative opzioni di configurazione, nonché esempi di come gli analizzatori di testo funzionano con la ricerca in BigQuery. Per ulteriori informazioni sulla sintassi dell'analizzatore di testo, consulta Analisi del testo.
Analizzatori di testo
BigQuery supporta i seguenti analizzatori di testo:
NO_OP_ANALYZER
LOG_ANALYZER
PATTERN_ANALYZER
NO_OP_ANALYZER
Utilizza NO_OP_ANALYZER
quando hai dati pre-elaborati che vuoi associare esattamente. Al testo non viene applicata alcuna tokenizzazione o normalizzazione. Poiché questo analizzatore non esegue la tokenizzazione o la normalizzazione, non accetta alcuna configurazione. Per maggiori informazioni su
NO_OP_ANALYZER
, consulta
NO_OP_ANALYZER
.
LOG_ANALYZER
LOG_ANALYZER
modifica i dati nei seguenti modi:
- Il testo viene scritto in minuscolo.
I valori ASCII superiori a 127 vengono mantenuti invariati.
Il testo viene suddiviso in singoli termini chiamati token dai seguenti delimitatori:
[ ] < > ( ) { } | ! ; , ' " * & ? + / : = @ . - $ % \ _ \n \r \s \t %21 %26 %2526 %3B %3b %7C %7c %20 %2B %2b %3D %3d %2520 %5D %5d %5B %5b %3A %3a %0A %0a %2C %2c %28 %29
Se non vuoi utilizzare i delimitatori predefiniti, puoi specificare quelli che vuoi utilizzare come opzioni dell'analizzatore di testo.
LOG_ANALYZER
ti consente di configurare delimitatori e filtri di token specifici per un maggiore controllo sui risultati di ricerca. Per ulteriori informazioni sulle opzioni di configurazione specifiche disponibili quando si utilizzaLOG_ANALYZER
, consulta l'opzione di analisidelimiters
e l'opzione di analisitoken_filters
.
PATTERN_ANALYZER
L'analizzatore di testo PATTERN_ANALYZER
estrae i token dal testo utilizzando un'espressione regolare. Il motore e la sintassi delle espressioni regolari utilizzati con
PATTERN_ANALYZER
sono RE2. PATTERN_ANALYZER
tokenize i pattern nel seguente ordine:
- Trova la prima sottostringa che corrisponde al pattern (da sinistra) nella stringa. Si tratta di un token da includere nell'output.
- Rimuove tutto dalla stringa di input fino alla fine della sottostringa trovata nel passaggio 1.
- Ripete la procedura finché la stringa non è vuota.
La tabella seguente fornisce esempi di estrazione di token PATTERN_ANALYZER
:
Pattern | Testo di input | Token di output |
---|---|---|
ab | ababab |
|
ab | abacad |
|
[a-z]{2} | abacad |
|
aaa | aaaaa |
|
[a-z]/ | a/b/c/d/e |
|
/[^/]+/ | aa/bb/cc |
|
[0-9]+ | abc | |
(?:/?)[a-z] | /abc |
|
(?:/)[a-z] | /abc |
|
(?:[0-9]abc){3}(?:[a-z]000){2} | 7abc7abc7abcx000y000 |
|
".+" | "gatti" e "cani" |
Tieni presente che l 'utilizzo dei quantificatori avidi + rende la corrispondenza più lunga possibile nel testo, causando l'estrazione di"gatti " e"cani" come token nel testo. |
".+?" | "gatti" e "cani" |
Tieni presente che l'utilizzo dei quantificatori pigri +? fa sì che l'espressione regolare corrisponda alla stringa più breve possibile nel testo, causando l'estrazione di ""gatti"", ""cani"" come due token distinti nel testo. |
L'utilizzo dell'analizzatore di testo PATTERN_ANALYZER
ti offre un maggiore controllo sui token estratti da un testo se utilizzato con la funzione SEARCH
. La tabella seguente mostra in che modo modelli e risultati diversi generano risultati SEARCH
diversi:
Pattern | Query | Testo | Token dal testo | CERCA(testo; query) | Spiegazione |
---|---|---|---|---|---|
abc | abcdef | abcghi |
|
VERO | 'abc' in ['abcghi'] |
cd[a-z] | abcdef | abcghi |
|
FALSE | 'cde' in ['abcghi'] |
[a-z]/ | a/b/ | a/b/c/d/ |
|
VERO | 'a/' in ['a/', 'b/', 'c/', 'd/'] AND 'b/' in ['a/', 'b/', 'c/', 'd/'] |
/[^/]+/ | aa/bb/ | aa/bb/cc/ |
|
VERO | '/bb/' in ['/bb/'] |
/[^/]+/ | bb | aa/bb/cc/ |
|
ERRORE | Nessuna corrispondenza trovata nel termine di query |
[0-9]+ | abc | abc123 | ERRORE | Nessuna corrispondenza trovata nel termine di query | |
[0-9]+ | "abc" | abc123 | ERRORE | Nessuna corrispondenza trovata nel termine di query Il carattere barra verticale viene considerato come barra verticale, non come carattere speciale. |
|
[a-z][a-z0-9]*@google\.com | Questo è il mio indirizzo email: test@google.com | test@google.com |
|
VERO | 'test@google.com' in 'test@google.com' |
abc | abc\ abc | abc |
|
VERO | 'abc' in ['abc'] Tieni presente che "abc abc" è una singola sottoquery dopo essere stata analizzata dal parser delle query di ricerca, poiché lo spazio è preceduto da un carattere di escape. |
(?i)(?:Abc) (nessuna normalizzazione) | aBcd | Abc |
|
FALSE | 'aBc' in ['Abc'] |
(?i)(?:Abc) normalization: lower_case = true |
aBcd | Abc |
|
VERO | 'abc' in ['abc'] |
(?:/?)abc | bc/abc | /abc/abc/ |
|
VERO | '/abc' in ['/abc'] |
(?:/?)abc | abc | d/abc |
|
FALSE | 'abc' in ['/abc'] |
".+" | "gatti" | "gatti" e "cani" |
|
FALSE | '"gatti"' in ['"gatti" e "cani"] Tieni presente che l'utilizzo dei quantificatori avidi + fa sì che l'espressione regolare corrisponda alla stringa più lunga possibile nel testo, causando l'estrazione di "gatti" e "cani" come token nel testo. |
".+?" | "gatti" | "gatti" e "cani" |
|
VERO | '"gatti"' in ['"gatti"', '"cani"] Tieni presente che l'utilizzo dei quantificatori pigri +? fa sì che l'espressione regolare corrisponda alla stringa più breve possibile nel testo, causando l'estrazione di '"gatti"', '"cani"' come due token distinti nel testo. |
Esempi
I seguenti esempi mostrano l'utilizzo dell'analisi del testo con opzioni di personalizzazione per creare indici di ricerca, estrarre token e restituire risultati di ricerca.
LOG_ANALYZER
con normalizzazione ICU NFKC e parole proibite
L'esempio seguente configura le opzioni LOG_ANALYZER
con la normalizzazione ICU NFKC e le parole proibite. L'esempio presuppone la seguente tabella di dati con i dati già inseriti:
CREATE TABLE dataset.data_table( text_data STRING );
Per creare un indice di ricerca con la normalizzazione ICU NFKC e un elenco di parole proibite,
crea una stringa in formato JSON nell'opzione analyzer_options
dell'istruzione DDL CREATE
SEARCH INDEX
.
Per un elenco completo delle opzioni disponibili quando crei un indice di ricerca con LOG_ANALYZER
, consulta LOG_ANALYZER
.
Per questo esempio, le parole proibite sono "the", "of", "and", "for"
.
CREATE OR REPLACE SEARCH INDEX `my_index` ON `dataset.data_table`(ALL COLUMNS) OPTIONS( analyzer='PATTERN_ANALYZER', analyzer_options= '''{ "token_filters": [ { "normalizer": { "mode": "ICU_NORMALIZE", "icu_normalize_mode": "NFKC", "icu_case_folding": true } }, { "stop_words": ["the", "of", "and", "for"] } ] }''');
Dato l'esempio precedente, la tabella seguente descrive l'estrazione dei token per vari valori di text_data
. Tieni presente che in questo documento il carattere del doppio punto interrogativo (⁇) è in corsivo per distinguere tra due punti interrogativi (??):
Testo dati | Token per l'indice | Spiegazione |
---|---|---|
La volpe marrone veloce | ["quick", "brown", "fox"] | La tokenizzazione di LOG_ANALYZER produce i token ["The", "Quick", "Brown", "Fox"]. Successivamente, la normalizzazione T.I. con icu_case_folding = true mette in minuscolo i token per produrre ["the", "quick", "brown", "fox"]Infine, il filtro delle parole proibite rimuove "the" dall'elenco. |
Il Ⓠuick Ⓑrown Ⓕox | ["quick", "brown", "fox"] | La tokenizzazione di LOG_ANALYZER produce i token ["The", "Ⓠuick", "Ⓑrown", "Ⓕox"]. Successivamente, la normalizzazione ICU NFKC con icu_case_folding = true mette in minuscolo i token per produrre ["the", "quick", "brown", "fox"]Infine, il filtro delle parole proibite rimuove "the" dall'elenco. |
Ⓠuick⁇Ⓕox | ["quick??fox"] | La tokenizzazione di LOG_ANALYZER produce i token ["The", "Ⓠuick⁇Ⓕox"]. Successivamente, la normalizzazione ICU NFKC con icu_case_folding = true mette in minuscolo i token da produrre ["quick??fox"]. Tieni presente che il carattere Unicode doppio punto interrogativo è stato normalizzato in 2 caratteri ASCII punto interrogativo.Infine, il filtro delle parole proibite non fa nulla perché nessuno dei token è presente nell'elenco dei filtri. |
Ora che l'indice di ricerca è stato creato, puoi utilizzare la funzione SEARCH
per cercare nella tabella utilizzando le stesse configurazioni dell'analizzatore specificate nell'indice di ricerca. Tieni presente
che se le configurazioni dell'analizzatore nella funzione SEARCH
non corrispondono a quelle
dell'indice di ricerca, quest'ultimo non verrà utilizzato. Utilizza la seguente query:
SELECT SEARCH( analyzer => 'LOG_ANALYZER', analyzer_options => '''{ "token_filters": [ { "normalizer": { "mode": "ICU_NORMALIZE", "icu_normalize_mode": "NFKC", "icu_case_folding": true } }, { "stop_words": ["the", "of", "and", "for"] } ] }''')
Sostituisci quanto segue:
search_query
: il testo da cercare.
La tabella seguente mostra vari risultati in base a diversi testi di ricerca e diversi valori di search_query
:
text_data | search_query |
Risultato | Spiegazione |
---|---|---|---|
La volpe marrone veloce | "Ⓠuick" |
TRUE |
L'elenco finale di token estratti
dal testo è ["quick", "brown", "fox"]. L'elenco finale dei token estratti dalla query di testo è ["quick"]. Tutti i token di query dell'elenco sono disponibili nei token di testo. |
Il Ⓠuick Ⓑrown Ⓕox | "quick" |
TRUE |
L'elenco finale di token estratti dal testo è ["quick", "brown", "fox"]. L'elenco finale dei token estratti dalla query di testo è ["quick"]. Tutti i token di query dell'elenco sono disponibili nei token di testo. |
Ⓠuick⁇Ⓕox | "quick" |
FALSE |
L'elenco finale di token estratti dal testo è ["quick??fox"]. L'elenco finale dei token estratti dalla query di testo è ["quick"]. "rapido" non è presente nell'elenco dei token del testo. |
Ⓠuick⁇Ⓕox | "quick⁇fox" |
TRUE |
L'elenco finale di token estratti dal testo è ["quick??fox"]. L'elenco finale dei token estratti dalla query di testo è ["quick??fox"]. "quick??fox" è presente nell'elenco dei token del testo. |
Ⓠuick⁇Ⓕox | "`quick⁇fox`" |
FALSE |
In LOG_ANALYZER , la barra rovesciata richiede una corrispondenza esatta del testo. |
PATTERN_ANALYZER
per la ricerca IPv4 con parole proibite
L'esempio seguente configura l'analizzatore di testo PATTERN_ANALYZER
per cercare un pattern specifico filtrando determinate parole proibite. In questo esempio, il pattern corrisponde a un indirizzo IPv4 e ignora il valore localhost (127.0.0.1
).
Questo esempio presuppone che la seguente tabella sia compilata con i dati:
CREATE TABLE dataset.data_table( text_data STRING );
Per creare un indice di ricerca, l'opzione pattern
e un elenco di parole proibite, crea una stringa in formato JSON nell'opzione analyzer_options
dell'istruzione DDL CREATE SEARCH
INDEX
.
Per un elenco completo delle opzioni disponibili quando crei un indice di ricerca con PATTERN_ANALYZER
, consulta PATTERN_ANALYZER
.
Per questo esempio, le parole proibite sono l'indirizzo localhost,
127.0.0.1
.
CREATE SEARCH INDEX my_index ON dataset.data_table(text_data) OPTIONS (analyzer = 'PATTERN_ANALYZER', analyzer_options = '''{ "patterns": [ "(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)[.]){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)" ], "token_filters": [ { "stop_words": [ "127.0.0.1" ] } ] }''' );
Quando utilizzi espressioni regolari con analyzer_options
, includi tre simboli \
iniziali per eseguire correttamente l'escape delle espressioni regolari che includono un simbolo \
, ad esempio \d
o \b
.
La tabella seguente descrive le opzioni di tokenizzazione per vari valori di text_data
Testo dati | Token per l'indice | Spiegazione |
---|---|---|
abc192.168.1.1def 172.217.20.142 | ["192.168.1.1", "172.217.20.142"] | Gli schemi IPv4 acquisiscono gli indirizzi IPv4 anche se non c'è spazio tra l'indirizzo e il testo. |
104.24.12.10abc 127.0.0.1 | ["104.24.12.10"] | "127.0.0.1" viene filtrato perché è nell'elenco delle parole proibite. |
Ora che l'indice di ricerca è stato creato, puoi utilizzare la funzione SEARCH
per cercare nella tabella in base alla tokenizzazione specificata in analyzer_options
. Utilizza la
seguente query:
SELECT SEARCH(dataset.data_table.text_data "search_data", analyzer => 'PATTERN_ANALYZER', analyzer_options => '''{ "patterns": [ "(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)[.]){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)" ], "token_filters": [ { "stop_words": [ "127.0.0.1" ] } ] }''' );
Sostituisci quanto segue:
search_query
: il testo da cercare.
La tabella seguente mostra vari risultati in base a diversi testi di ricerca e diversi valori di search_query
:
text_data | search_query |
Risultato | Spiegazione |
---|---|---|---|
128.0.0.2 | "127.0.0.1" | ERRORE | Nessun token di ricerca nella query. La query viene analizzata dall'analizzatore di testo, che filtra il token "127.0.0.1". |
abc192.168.1.1def 172.217.20.142 | "192.168.1.1abc" | VERO | L'elenco di token estratti dalla query è ["192.168.1.1"]. L'elenco di token estratti dal testo è ["192.168.1.1", "172.217.20.142"]. |
abc192.168.1.1def 172.217.20.142 | "`192.168.1.1`" | VERO | L'elenco di token estratti dalla query è ["192.168.1.1"]. L'elenco di token estratti dal testo è ["192.168.1.1", "172.217.20.142"]. Tieni presente che le barre graffe vengono trattate come caratteri normali per PATTERN_ANALYZER. |
Passaggi successivi
- Per una panoramica dei casi d'uso, dei prezzi, delle autorizzazioni richieste e delle limitazioni degli indici di ricerca, consulta l'Introduzione alla ricerca in BigQuery.
- Per informazioni sulla ricerca efficiente delle colonne indicizzate, consulta Eseguire ricerche con un indice.