Trasforma le traduzioni SQL utilizzando i file YAML di configurazione
Questo documento mostra come utilizzare i file YAML di configurazione per trasformare il codice SQL durante la relativa migrazione a BigQuery. Fornisce linee guida per creare i tuoi file YAML di configurazione e fornisce esempi per varie trasformazioni di traduzione supportate da questa funzionalità.
Quando utilizzi il traduttore SQL interattivo di BigQuery, l'API BigQuery Migration o esegui una traduzione SQL batch, puoi fornire file YAML di configurazione per modificare una traduzione di query SQL. L'utilizzo dei file YAML di configurazione consente un'ulteriore personalizzazione durante la traduzione delle query SQL dal database di origine.
Puoi specificare un file YAML di configurazione da utilizzare in una traduzione SQL nei seguenti modi:
- Se utilizzi il traduttore SQL interattivo, specifica il percorso del file di configurazione o l'ID job di traduzione batch nelle impostazioni di traduzione.
- Se utilizzi l'API BigQuery Migration, inserisci il file YAML di configurazione nello stesso bucket Cloud Storage dei file SQL di input.
- Se esegui una traduzione SQL batch, inserisci il file YAML di configurazione nello stesso bucket Cloud Storage dei file SQL di input.
- Se utilizzi il client Python per la traduzione batch, inserisci il file YAML di configurazione nella cartella di input della traduzione locale.
Il traduttore SQL interattivo, l'API BigQuery Migration, il traduttore SQL batch e il client Python di traduzione batch supportano l'utilizzo di più file YAML di configurazione in un unico job di traduzione. Per ulteriori informazioni, consulta la sezione Applicazione di più configurazioni YAML.
Requisiti del file YAML di configurazione
Prima di creare un file YAML di configurazione, esamina le seguenti informazioni per assicurarti che il file YAML sia compatibile con BigQuery Migration Service:
- Devi caricare i file YAML di configurazione nella directory principale del bucket Cloud Storage che contiene i file di input per la traduzione SQL. Per informazioni su come creare bucket e caricare file in Cloud Storage, consulta Creare bucket e Caricare oggetti da un file system.
- Le dimensioni di un singolo file YAML di configurazione non devono superare 1 MB.
- La dimensione totale di tutti i file YAML di configurazione utilizzati in un singolo job di traduzione SQL non deve superare i 4 MB.
- Se utilizzi la sintassi
regex
per la corrispondenza dei nomi, utilizza RE2/J. - Tutti i nomi dei file YAML di configurazione devono includere un'estensione
.config.yaml
, ad esempiochange-case.config.yaml
.config.yaml
da solo non è un nome valido per il file di configurazione.
Linee guida per creare un file YAML di configurazione
Questa sezione fornisce alcune linee guida generali per creare un file YAML di configurazione:
Intestazione
Ogni file di configurazione deve contenere un'intestazione che specifica il tipo di
configurazione. Il tipo object_rewriter
viene utilizzato per specificare le traduzioni SQL in un file YAML di configurazione. L'esempio seguente utilizza il tipo object_rewriter
per trasformare la combinazione di maiuscole e minuscole di un nome:
type: object_rewriter
global:
case:
all: UPPERCASE
Selezione delle entità
Per eseguire trasformazioni specifiche per l'entità, specifica l'entità nel
file di configurazione. Tutte le proprietà match
sono facoltative; utilizza solo le proprietà match
necessarie per una trasformazione. Il seguente YAML di configurazione
espone le proprietà da abbinare per selezionare entità specifiche:
match:
database: <literal_name>
schema: <literal_name>
relation: <literal_name>
attribute: <literal_name>
databaseRegex: <regex>
schemaRegex: <regex>
relationRegex: <regex>
attributeRegex: <regex>
Descrizione di ogni proprietà match
:
database
odb
: il componente project_id.schema
: il componente del set di dati.relation
: il componente tabella.attribute
: il componente della colonna. Valido solo per la selezione degli attributidatabaseRegex
odbRegex
: corrisponde a una proprietàdatabase
con un'espressione regolare (Anteprima).schemaRegex
: associa le proprietàschema
alle espressioni regolari (anteprima).relationRegex
: corrisponde alle proprietàrelation
con espressioni regolari (anteprima).attributeRegex
: corrisponde alle proprietàattribute
con espressioni regolari. Valido solo per la selezione degli attributi (Anteprima).
Ad esempio, il seguente YAML di configurazione specifica le proprietà match
per selezionare la tabella testdb.acme.employee
per una trasformazione
della tabella temporanea.
type: object_rewriter
relation:
-
match:
database: testdb
schema: acme
relation: employee
temporary: true
Puoi utilizzare le proprietà databaseRegex
, schemaRegex
, relationRegex
e
attributeRegex
per specificare espressioni regolari al fine di selezionare un
sottoinsieme di entità. Il seguente esempio modifica tutte le relazioni dallo schema
tmp_schema
in testdb
in temporanee, purché il loro nome inizi
con tmp_
:
type: object_rewriter
relation:
-
match:
schema: tmp_schema
relationRegex: "tmp_.*"
temporary: true
Le proprietà letterali e regex
vengono confrontate senza distinzione tra maiuscole e minuscole.
Puoi applicare la corrispondenza sensibile alle maiuscole e minuscole utilizzando un regex
con il flag i
disattivato, come mostrato nell'esempio seguente:
match:
relationRegex: "(?-i:<actual_regex>)"
Puoi anche specificare entità complete utilizzando una sintassi di stringa breve equivalente. Una sintassi di stringa breve prevede esattamente 3 (per la selezione della relazione) o 4 (per la selezione dell'attributo) segmenti di nome delimitati da punti, come nell'esempio testdb.acme.employee
. I segmenti vengono poi interpretati internamente come se fossero stati passati come database
, schema
, relation
e attribute
rispettivamente.
Ciò significa che i nomi vengono confrontati letteralmente, quindi le espressioni regolari non sono
consentite nella sintassi breve. L'esempio seguente mostra l'utilizzo della sintassi
della stringa breve per specificare un'entità completa in un file YAML di configurazione:
type: object_rewriter
relation:
-
match : "testdb.acme.employee"
temporary: true
Se una tabella contiene un punto nel nome, non puoi specificare il nome utilizzando una sintassi
abbreviata. In questo caso, devi utilizzare una corrispondenza esatta. L'esempio seguente
modifica la tabella testdb.acme.stg.employee
in temporanea:
type: object_rewriter
relation:
-
match:
database: testdb
schema: acme
relation: stg.employee
temporary: true
Il file YAML di configurazione accetta key
come alias di
match
.
Database predefinito
Alcuni dialetti SQL di input, in particolare Teradata, non supportano database-name
nel nome qualificato. In questo caso, il modo più semplice per abbinare le entità è omettere la proprietà database
in match
.
Tuttavia, puoi impostare la proprietà default_database
di BigQuery Migration Service
e utilizzare il database predefinito in match
.
Tipi di attributi di destinazione supportati
Puoi utilizzare il file YAML di configurazione per eseguire trasformazioni del tipo di attributo, in cui trasformi il tipo di dati di una colonna dal tipo di origine a un tipo di destinazione. Il file YAML di configurazione supporta i seguenti tipi di target:
BOOLEAN
TINYINT
SMALLINT
INTEGER
BIGINT
FLOAT
DOUBLE
NUMERIC
(supporta precisione e scala facoltative, ad esempioNUMERIC(18, 2)
)TIME
TIMETZ
DATE
DATETIME
TIMESTAMP
TIMESTAMPTZ
CHAR
(supporta la precisione facoltativa, ad esempioCHAR(42)
)VARCHAR
(supporta la precisione facoltativa, ad esempioVARCHAR(42)
)
Esempi di YAML di configurazione
Questa sezione fornisce esempi per creare vari file YAML di configurazione da
utilizzare con le traduzioni SQL. Ogni esempio descrive la sintassi YAML per
trasformare la traduzione SQL in modi specifici, insieme a una breve descrizione.
Ogni esempio fornisce anche i contenuti di un file teradata-input.sql
o
hive-input.sql
e di un file bq-output.sql
in modo da poter confrontare gli
effetti di un file YAML di configurazione su una traduzione
di query SQL BigQuery.
Gli esempi seguenti utilizzano Teradata o Hive come dialetto SQL di input e BigQuery SQL come dialetto di output. Anche i seguenti
esempi utilizzano testdb
come database predefinito e testschema
come
percorso di ricerca dello schema.
Modificare le maiuscole/minuscole del nome dell'oggetto
La seguente configurazione YAML modifica le maiuscole o le minuscole dei nomi degli oggetti:
type: object_rewriter
global:
case:
all: UPPERCASE
database: LOWERCASE
attribute: LOWERCASE
Una traduzione SQL con questo file YAML di configurazione potrebbe avere il seguente aspetto:
teradata-input.sql |
create table x(a int); select * from x; |
bq-output.sql |
CREATE TABLE testdb.TESTSCHEMA.X ( a INT64 ) ; SELECT X.a FROM testdb.TESTSCHEMA.X ; |
Rendere temporanea la tabella
La seguente configurazione YAML trasforma una tabella normale in una tabella temporanea:
type: object_rewriter
relation:
-
match: "testdb.testschema.x"
temporary: true
Una traduzione SQL con questo file YAML di configurazione potrebbe avere il seguente aspetto:
teradata-input.sql |
create table x(a int); |
bq-output.sql |
CREATE TEMPORARY TABLE x ( a INT64 ) ; |
Rendere temporanea la tabella
La seguente configurazione YAML trasforma una tabella normale in una tabella temporanea con una scadenza di 60 secondi.
type: object_rewriter
relation:
-
match: "testdb.testschema.x"
ephemeral:
expireAfterSeconds: 60
Una traduzione SQL con questo file YAML di configurazione potrebbe avere il seguente aspetto:
teradata-input.sql |
create table x(a int); |
bq-output.sql |
CREATE TABLE testdb.testschema.x ( a INT64 ) OPTIONS( expiration_timestamp=timestamp_add(current_timestamp(), interval 60 SECOND) ); |
Impostare la scadenza della partizione
La seguente configurazione YAML modifica la scadenza di una tabella partizionata a 1 giorno:
type: object_rewriter
relation:
-
match: "testdb.testschema.x"
partitionLifetime:
expireAfterSeconds: 86400
Una traduzione SQL con questo file YAML di configurazione potrebbe avere il seguente aspetto:
teradata-input.sql |
create table x(a int, b int) partition by (a); |
bq-output.sql |
CREATE TABLE testdb.testschema.x ( a INT64, b INT64 ) CLUSTER BY a OPTIONS( partition_expiration_days=1 ); |
Modificare la posizione o il formato esterno di una tabella
La seguente configurazione YAML modifica la posizione e la formazione esterne per una tabella:
type: object_rewriter
relation:
-
match: "testdb.testschema.x"
external:
locations: "gs://path/to/department/files"
format: ORC
Una traduzione SQL con questo file YAML di configurazione potrebbe avere il seguente aspetto:
teradata-input.sql |
create table x(a int); |
bq-output.sql |
CREATE EXTERNAL TABLE testdb.testschema.x ( a INT64 ) OPTIONS( format='ORC', uris=[ 'gs://path/to/department/files' ] ); |
Impostare o modificare la descrizione della tabella
Il seguente YAML di configurazione imposta la descrizione di una tabella:
type: object_rewriter
relation:
-
match: "testdb.testschema.x"
description:
text: "Example description."
Una traduzione SQL con questo file YAML di configurazione potrebbe avere il seguente aspetto:
teradata-input.sql |
create table x(a int); |
bq-output.sql |
CREATE TABLE testdb.testschema.x ( a INT64 ) OPTIONS( description='Example description.' ); |
Impostare o modificare il partizionamento delle tabelle
La seguente configurazione YAML modifica lo schema di partizionamento di una tabella:
type: object_rewriter
relation:
-
match: "testdb.testschema.x"
partition:
simple:
add: [a]
-
match: "testdb.testschema.y"
partition:
simple:
remove: [a]
Una traduzione SQL con questo file YAML di configurazione potrebbe avere il seguente aspetto:
teradata-input.sql |
create table x(a date, b int); create table y(a date, b int) partition by (a); |
bq-output.sql |
CREATE TABLE testdb.testschema.x ( a DATE, b INT64 ) PARTITION BY a; CREATE TABLE testdb.testschema.y ( a DATE, b INT64 ) ; |
Impostare o modificare il clustering delle tabelle
Il seguente YAML di configurazione modifica lo schema di clustering di una tabella:
type: object_rewriter
relation:
-
match: "testdb.testschema.x"
clustering:
add: [a]
-
match: "testdb.testschema.y"
clustering:
remove: [b]
Una traduzione SQL con questo file YAML di configurazione potrebbe avere il seguente aspetto:
hive-input.sql |
create table x(a int, b int); create table y(a int, b int) clustered by (b) into 16 buckets; |
bq-output.sql |
CREATE TABLE testdb.testschema.x ( a INT64, b INT64 ) CLUSTER BY a; CREATE TABLE testdb.testschema.y ( a INT64, b INT64 ) ; |
Modificare il tipo di un attributo di colonna
La seguente configurazione YAML modifica il tipo di dati per un attributo di una colonna:
type: object_rewriter
attribute:
-
match:
database: testdb
schema: testschema
attributeRegex: "a+"
type:
target: NUMERIC(10,2)
Puoi trasformare il tipo di dati di origine in uno qualsiasi dei tipi di attributo target supportati.
Una traduzione SQL con questo file YAML di configurazione potrebbe avere il seguente aspetto:
teradata-input.sql |
create table x(a int, b int, aa int); |
bq-output.sql |
CREATE TABLE testdb.testschema.x ( a NUMERIC(31, 2), b INT64, aa NUMERIC(31, 2) ) ; |
Aggiungere una connessione a un data lake esterno
Il seguente YAML di configurazione contrassegna la tabella di origine come tabella esterna che punta ai dati archiviati in un data lake esterno, specificato da una connessione al data lake.
type: object_rewriter
relation:
-
key: "testdb.acme.employee"
external:
connection_id: "connection_test"
Una traduzione SQL con questo file YAML di configurazione potrebbe avere il seguente aspetto:
hive-input.sql |
CREATE TABLE x ( a VARCHAR(150), b INT ); |
bq-output.sql |
CREATE EXTERNAL TABLE x ( a STRING, b INT64 ) WITH CONNECTION `connection_test` OPTIONS( ); |
Modificare la codifica dei caratteri di un file di input
Per impostazione predefinita, BigQuery Migration Service tenta di rilevare automaticamente la codifica dei caratteri dei file di input. Nei casi in cui BigQuery Migration Service potrebbe identificare erroneamente la codifica di un file, puoi utilizzare un file YAML di configurazione per specificare esplicitamente la codifica dei caratteri.
Il seguente YAML di configurazione specifica la codifica dei caratteri esplicita
del file di input come ISO-8859-1
.
type: experimental_input_formats
formats:
- source:
pathGlob: "*.sql"
contents:
raw:
charset: iso-8859-1
Conversione del tipo globale
La seguente configurazione YAML modifica un tipo di dati in un altro in tutti gli script e specifica un tipo di dati di origine da evitare nello script sottoposto a transpiling. Questa operazione è diversa dalla configurazione Modifica il tipo di un attributo di colonna, in cui viene modificato solo il tipo di dati per un singolo attributo.
BigQuery supporta le seguenti conversioni dei tipi di dati:
- Da
DATETIME
aTIMESTAMP
TIMESTAMP
aDATETIME
(accetta il fuso orario facoltativo)TIMESTAMP WITH TIME ZONE
aDATETIME
(accetta il fuso orario facoltativo)- Da
CHAR
aVARCHAR
Nell'esempio seguente, la configurazione YAML converte un tipo di dati TIMESTAMP
in DATETIME
.
type: experimental_object_rewriter
global:
typeConvert:
timestamp: DATETIME
In dialetti come Teradata, le funzioni correlate a data e ora, come
current_date
, current_time
o current_timestamp
, restituiscono timestamp in base
al fuso orario configurato, locale o di sessione. BigQuery, d'altra parte, restituisce sempre i timestamp in formato UTC. Per garantire un comportamento coerente tra i due dialetti, è necessario configurare il fuso orario di conseguenza.
Nell'esempio seguente, il file YAML di configurazione converte un tipo di dati TIMESTAMP
e un tipo di dati TIMESTAMP WITH TIME ZONE
in DATETIME
, con il fuso orario di destinazione impostato su Europe/Paris
.
type: experimental_object_rewriter
global:
typeConvert:
timestamp:
target: DATETIME
timezone: Europe/Paris
timestamptz:
target: DATETIME
timezone: Europe/Paris
Una traduzione SQL con questo file YAML di configurazione potrebbe avere il seguente aspetto:
teradata-input.sql |
create table x(a timestamp); select a from x where a > current_timestamp(0); |
bq-output.sql |
CREATE TABLE x ( a TIMESTAMP ) ; SELECT x.a FROM test.x WHERE x.a > datetime_trunc(current_datetime('Europe/Paris'), SECOND) ; |
Seleziona la modifica della dichiarazione
La seguente configurazione YAML modifica la proiezione a stella, GROUP BY
e
ORDER BY
nelle istruzioni SELECT
.
starProjection
supporta le seguenti configurazioni:
ALLOW
PRESERVE
(valore predefinito)EXPAND
groupBy
e orderBy
supportano le seguenti configurazioni:
EXPRESSION
ALIAS
INDEX
Nell'esempio seguente, la configurazione YAML configura la proiezione
stellare su EXPAND
.
type: experimental_statement_rewriter
select:
starProjection: EXPAND
Una traduzione SQL con questo file YAML di configurazione potrebbe avere il seguente aspetto:
teradata-input.sql |
create table x(a int, b TIMESTAMP); select * from x; |
bq-output.sql |
CREATE TABLE x ( a INT64, b DATETIME ) ; SELECT x.a x.b FROM x ; |
Specifiche delle funzioni definite dall'utente
Il seguente YAML di configurazione specifica la firma delle funzioni definite dall'utente (UDF) utilizzate negli script di origine. Come i file zip dei metadati, le definizioni delle UDF possono contribuire a produrre una traduzione più accurata degli script di input.
type: metadata
udfs:
- "date parse_short_date(dt int)"
Una traduzione SQL con questo file YAML di configurazione potrebbe avere il seguente aspetto:
teradata-input.sql |
create table x(dt int); select parse_short_date(dt) + 1 from x; |
bq-output.sql |
CREATE TABLE x ( dt INT64 ) ; SELECT date_add(parse_short_date(x.dt), interval 1 DAY) FROM x ; |
Impostazione del livello di rigore della precisione decimale
Per impostazione predefinita, BigQuery Migration Service aumenta la precisione numerica alla massima precisione disponibile per una determinata scala. La seguente configurazione YAML esegue l'override di questo comportamento configurando la rigidità della precisione in modo da mantenere la precisione decimale dell'istruzione di origine.
type: experimental_statement_rewriter
common:
decimalPrecision: STRICT
Una traduzione SQL con questo file YAML di configurazione potrebbe avere il seguente aspetto:
teradata-input.sql |
create table x(a decimal(3,0)); |
bq-output.sql |
CREATE TABLE x ( a NUMERIC(3) ) ; |
Mapping dei nomi di output
Puoi utilizzare il file YAML di configurazione per mappare i nomi degli oggetti SQL. Puoi modificare diverse parti del nome a seconda dell'oggetto mappato.
Mapping statico dei nomi
Utilizza la mappatura statica dei nomi per mappare il nome di un'entità. Se vuoi modificare solo parti specifiche del nome mantenendo invariate le altre, includi solo le parti da modificare.
La seguente configurazione YAML modifica il nome della tabella da
my_db.my_schema.my_table
a my_new_db.my_schema.my_new_table
.
type: experimental_object_rewriter
relation:
-
match: "my_db.my_schema.my_table"
outputName:
database: "my_new_db"
relation: "my_new_table"
Una traduzione SQL con questo file YAML di configurazione potrebbe avere il seguente aspetto:
teradata-input.sql |
create table my_db.my_schema.my_table(a int); |
bq-output.sql |
CREATE TABLE my_new_db.my_schema.my_new_table ( a INT64 ) |
Puoi utilizzare la mappatura statica dei nomi per aggiornare la regione utilizzata dai nomi nelle funzioni definite dall'utente pubbliche.
L'esempio seguente modifica i nomi nella UDF bqutil.fn
in modo che utilizzi la regione europe_west2
anziché la regione multiregionale us
predefinita:
type: experimental_object_rewriter
function:
-
match:
database: bqutil
schema: fn
outputName:
database: bqutil
schema: fn_europe_west2
Mapping dinamico dei nomi
Utilizza la mappatura dinamica dei nomi per modificare più oggetti contemporaneamente e creare nuovi nomi in base agli oggetti mappati.
La seguente configurazione YAML modifica il nome di tutte le tabelle aggiungendo il
prefisso stg_
a quelle che appartengono allo schema staging
, quindi sposta queste
tabelle nello schema production
.
type: experimental_object_rewriter
relation:
-
match:
schema: staging
outputName:
schema: production
relation: "stg_${relation}"
Una traduzione SQL con questo file YAML di configurazione potrebbe avere il seguente aspetto:
teradata-input.sql |
create table staging.my_table(a int); |
bq-output.sql |
CREATE TABLE production.stg_my_table ( a INT64 ) ; |
Specifica del percorso di ricerca predefinito di database e schema
Il seguente YAML di configurazione specifica un database predefinito e un percorso di ricerca dello schema.
type: environment
session:
defaultDatabase: myproject
schemaSearchPath: [myschema1, myschema2]
Una traduzione SQL con questo file YAML di configurazione potrebbe avere il seguente aspetto:
teradata-input.sql |
SELECT * FROM database.table SELECT * FROM table1 |
bq-output.sql |
SELECT * FROM myproject.database.table. SELECT * FROM myproject.myschema1.table1 |
Riscrittura del nome dell'output globale
Il seguente file YAML di configurazione modifica i nomi di output di tutti gli oggetti (database, schema, relazione e attributi) nello script in base alle regole configurate.
type: experimental_object_rewriter
global:
outputName:
regex:
- match: '\s'
replaceWith: '_'
- match: '>='
replaceWith: 'gte'
- match: '^[^a-zA-Z_].*'
replaceWith: '_$0'
Una traduzione SQL con questo file YAML di configurazione potrebbe avere il seguente aspetto:
teradata-input.sql |
create table "test special chars >= 12"("42eid" int, "custom column" varchar(10)); |
bq-output.sql |
CREATE TABLE test_special_chars_employees_gte_12 ( _42eid INT64, custom_column STRING ) ; |
Ottimizzare e migliorare le prestazioni dell'SQL tradotto
È possibile applicare trasformazioni facoltative all'SQL tradotto per introdurre modifiche che possono migliorare la query in termini di prestazioni o costi. Queste ottimizzazioni dipendono strettamente dalla distinzione tra maiuscole e minuscole e devono essere valutate rispetto all'output SQL non modificato per valutarne l'effetto effettivo sul rendimento.
Il seguente YAML di configurazione attiva le trasformazioni facoltative. La configurazione accetta un elenco di ottimizzazioni e, per le ottimizzazioni che accettano parametri, una sezione con valori di parametri facoltativi.
type: optimizer
transformations:
- name: PRECOMPUTE_INDEPENDENT_SUBSELECTS
- name: REWRITE_CTE_TO_TEMP_TABLE
parameters:
threshold: 1
Ottimizzazione | Parametro facoltativo | Descrizione |
---|---|---|
PRECOMPUTE_INDEPENDENT_SUBSELECTS |
scope: [PREDICATE, PROJECTION]
|
Riscrive la query aggiungendo un'istruzione DECLARE per sostituire un'espressione nelle clausole PREDICATE o PROJECTION con una variabile precalcolata. Verrà identificato come predicato statico che consente
di ridurre la quantità di dati letti. Se l'ambito viene omesso, il valore predefinito
è PREDICATE (ovvero la clausola WHERE e JOIN-ON ).
L'estrazione di una sottoquery scalare in un'istruzione DECLARE
renderà statico il predicato originale e quindi idoneo a una pianificazione
dell'esecuzione migliorata. Questa ottimizzazione introdurrà nuove istruzioni SQL.
|
REWRITE_CTE_TO_TEMP_TABLE |
threshold: N
|
Riscrive le espressioni di tabella comuni (CTE) in tabelle temporanee quando sono presenti più di N riferimenti alla stessa espressione di tabella comune. Ciò
riduce la complessità della query e forza la singola esecuzione dell'espressione della tabella comune.
Se N viene omesso, il valore predefinito è 4.
Ti consigliamo di utilizzare questa ottimizzazione quando le CTE non banali vengono referenziate più volte. L'introduzione di tabelle temporanee comporta un overhead che potrebbe essere maggiore di quello di più esecuzioni di un'espressione di tabella comune a bassa complessità o bassa cardinalità. Questa ottimizzazione introdurrà nuove istruzioni SQL. |
REWRITE_ZERO_SCALE_NUMERIC_AS_INTEGER |
bigint: N
|
Riscrive gli attributi NUMERIC/BIGNUMERIC a zero scala nel tipo INT64 se la precisione rientra in N . Se
N viene omesso, il valore predefinito è 18 .
Ti consigliamo di utilizzare questa ottimizzazione quando traduci da dialetti di origine che non hanno tipi interi. La modifica dei tipi di colonne richiede la revisione di tutti gli utilizzi downstream per la compatibilità dei tipi e le modifiche semantiche. Ad esempio, le divisioni frazionarie diventano divisioni intere, il codice prevede valori numerici |
DROP_TEMP_TABLE |
Aggiunge istruzioni DROP TABLE per tutte le tabelle temporanee create
in uno script e non eliminate alla fine. In questo modo, il periodo di fatturazione
dello spazio di archiviazione per la tabella temporanea viene ridotto da 24 ore al tempo di esecuzione dello script. Questa ottimizzazione introdurrà nuove istruzioni SQL.
Ti consigliamo di utilizzare questa ottimizzazione quando non si accede alle tabelle temporanee per ulteriori elaborazioni dopo la fine dell'esecuzione dello script. Questa ottimizzazione introdurrà nuove istruzioni SQL. |
|
REGEXP_CONTAINS_TO_LIKE |
Riscrive alcune categorie di pattern di corrispondenza REGEXP_CONTAINS
in espressioni LIKE .
Ti consigliamo di utilizzare questa ottimizzazione quando nessun altro processo, come la sostituzione delle macro, si basa sui valori letterali del pattern dell'espressione regolare che vengono conservati invariati nell'SQL di output. |
|
ADD_DISTINCT_TO_SUBQUERY_IN_SET_COMPARISON |
Aggiunge la clausola DISTINCT alle sottoquery utilizzate come insieme di valori per
l'operatore [NOT] IN .
Ti consigliamo di utilizzare questa ottimizzazione quando la cardinalità (numero distinto di valori) del risultato della sottoquery è significativamente inferiore al numero di valori. Se questa precondizione non viene soddisfatta, questa trasformazione può avere effetti negativi sul rendimento. |
Crea un file YAML di configurazione basato su Gemini
Per generare l'output dell'AI, la directory di origine contenente l'input di traduzione SQL deve includere un file YAML di configurazione.
Requisiti
Il file YAML di configurazione per gli output dell'AI deve avere il suffisso .ai_config.yaml
.
Ad esempio, rules_1.ai_config.yaml
.
Campi supportati
Puoi utilizzare i seguenti campi per configurare l'output della traduzione con l'AI:
suggestion_type
(facoltativo): specifica il tipo di suggerimento dell'AI da generare. Sono supportati i seguenti tipi di suggerimenti:QUERY_CUSTOMIZATION
(impostazione predefinita): genera suggerimenti basati sull'AI per il codice SQL in base alle regole di traduzione specificate nel file YAML di configurazione.TRANSLATION_EXPLANATION
: genera un testo che include un riepilogo della query GoogleSQL tradotta e le differenze e le incongruenze tra la query SQL di origine e la query GoogleSQL tradotta.
rewrite_target
(facoltativo): specificaSOURCE_SQL
se vuoi applicare la regola di traduzione all'SQL di input oTARGET_SQL
(impostazione predefinita) se vuoi applicarla all'SQL di output.instruction
(facoltativo): descrivi in linguaggio naturale una modifica all'SQL di destinazione. La traduzione SQL ottimizzata con Gemini valuta la richiesta e apporta la modifica specificata.examples
(facoltativo): fornisci esempi SQL di come vuoi che venga modificato il pattern SQL.
Puoi aggiungere ulteriori translation_rules
e examples
, se necessario.
Esempi
Gli esempi seguenti creano file YAML di configurazione basati su Gemini che puoi utilizzare con le traduzioni SQL.
Rimuovi la funzione upper nella query di output della traduzione predefinita
translation_rules:
- instruction: "Remove upper() function"
examples:
- input: "upper(X)"
output: "X"
Crea più regole di traduzione per personalizzare l'output della traduzione
translation_rules:
- instruction: "Remove upper() function"
suggestion_type: QUERY_CUSTOMIZATION
rewrite_target: TARGET_SQL
examples:
- input: "upper(X)"
output: "X"
- instruction: "Insert a comment at the head that explains each statement in detail.
suggestion_type: QUERY_CUSTOMIZATION
rewrite_target: TARGET_SQL
Rimuovi i commenti SQL dalla query di input della traduzione
translation_rules:
- instruction: "Remove all the sql comments in the input sql query."
suggestion_type: QUERY_CUSTOMIZATION
rewrite_target: SOURCE_SQL
Generare spiegazioni della traduzione utilizzando il prompt LLM predefinito
Questo esempio utilizza i prompt LLM predefiniti forniti dal servizio di traduzione per generare spiegazioni di testo:
translation_rules:
- suggestion_type: "TRANSLATION_EXPLANATION"
Genera spiegazioni della traduzione utilizzando i tuoi prompt in linguaggio naturale
translation_rules:
- suggestion_type: "TRANSLATION_EXPLANATION"
instruction: "Explain the syntax differences between the source Teradata query and the translated GoogleSQL query."
Più tipi di suggerimenti in un unico file YAML di configurazione
translation_rules:
- suggestion_type: "TRANSLATION_EXPLANATION"
instruction: "Explain the syntax differences between the source Teradata query and the translated GoogleSQL query."
- instruction: "Remove upper() function"
suggestion_type: QUERY_CUSTOMIZATION
rewrite_target: TARGET_SQL
examples:
- input: "upper(X)"
output: "X"
- instruction: "Remove all the sql comments in the input sql query."
suggestion_type: QUERY_CUSTOMIZATION
rewrite_target: SOURCE_SQL
Applicazione di più configurazioni YAML
Quando specifichi un file YAML di configurazione in una traduzione SQL batch o interattiva, puoi selezionare più file YAML di configurazione in un unico job di traduzione per riflettere più trasformazioni. Se più configurazioni sono in conflitto, una trasformazione potrebbe sostituirne un'altra. Ti consigliamo di utilizzare diversi tipi di impostazioni di configurazione in ogni file per evitare trasformazioni in conflitto nello stesso job di traduzione.
L'esempio seguente elenca due file YAML di configurazione separati forniti per un singolo job di traduzione SQL, uno per modificare l'attributo di una colonna e l'altro per impostare la tabella come temporanea:
change-type-example.config.yaml
:
type: object_rewriter
attribute:
-
match: "testdb.testschema.x.a"
type:
target: NUMERIC(10,2)
make-temp-example.config.yaml
:
type: object_rewriter
relation:
-
match: "testdb.testschema.x"
temporary: true
Una traduzione SQL con questi due file YAML di configurazione potrebbe avere il seguente aspetto:
teradata-input.sql |
create table x(a int); |
bq-output.sql |
CREATE TEMPORARY TABLE x ( a NUMERIC(31, 2) ) ; |