Trasforma le traduzioni SQL utilizzando i file YAML di configurazione
Questo documento mostra come utilizzare i file di configurazione YAML per trasformare il codice SQL durante la migrazione a BigQuery. Fornisce linee guida per creare i tuoi file YAML di configurazione e fornire esempi per vari trasformazioni di traduzione supportate da questa funzionalità.
Quando utilizzi lo strumento BigQuery traduttore SQL interattivo, utilizzando l'API BigQuery Migration, o eseguire una traduzione SQL batch, puoi fornire file YAML di configurazione per modificare una traduzione di query SQL. L'uso dei file YAML di configurazione consente un'ulteriore personalizzazione quando e tradurre le query SQL dal database di origine.
Puoi specificare un file YAML di configurazione da utilizzare in una traduzione SQL nel nei seguenti modi:
- Se utilizzi traduttore SQL interattivo, specifica il percorso del file del file di configurazione o dell'ID job di traduzione batch impostazioni.
- Se utilizzi l'API BigQuery Migration, posiziona il file YAML di configurazione nello stesso bucket Cloud Storage dei file SQL di input.
- Se stai eseguendo una traduzione SQL batch, posiziona il file YAML di configurazione nello stesso bucket Cloud Storage dei file SQL di input.
- Se utilizzi il client Python di traduzione batch, 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 supporta l'uso di più file YAML di configurazione in un unico job di traduzione. Consulta Applicazione di più configurazioni YAML per ulteriori informazioni.
Requisiti del file YAML di configurazione
Prima di creare un file YAML di configurazione, esamina le seguenti informazioni per assicurarti che il tuo file YAML sia compatibile per l'utilizzo BigQuery Migration Service:
- Devi caricare i file YAML di configurazione nella directory principale del bucket Cloud Storage contenente i file di input per la traduzione SQL. Per informazioni su come creare bucket e caricare file su 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.
- Le dimensioni totali di tutti i file YAML di configurazione utilizzati in una singola query il job di traduzione non deve superare i 4 MB.
- Se utilizzi la sintassi
regex
per la corrispondenza dei nomi, usa RE2/J. - Tutti i nomi dei file YAML di configurazione devono includere un
.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 specifichi il tipo
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 maiuscola di un nome:
type: object_rewriter
global:
case:
all: UPPERCASE
Selezione entità
Per eseguire trasformazioni specifiche dell'entità, specifica l'entità nel
di configurazione del deployment. Tutte le proprietà match
sono facoltative; utilizza solo le proprietà match
necessarie per una trasformazione. Il seguente file YAML di configurazione
espone le proprietà da associare per selezionare entità specifiche:
match:
db: <literal_name>
schema: <literal_name>
relation: <literal_name>
attribute: <literal_name>
dbRegex: <regex>
schemaRegex: <regex>
relationRegex: <regex>
attributeRegex: <regex>
Descrizione di ogni proprietà match
:
db
: il componente project_id.schema
: il componente del set di dati.relation
: il componente della tabella.attribute
: il componente della colonna. Valido solo per la selezione dell'attributodbRegex
: corrisponde a una proprietàdb
con un'espressione regolare (Anteprima).schemaRegex
: associa le proprietàschema
alle espressioni regolari (anteprima).relationRegex
: abbina le proprietàrelation
con espressioni regolari (Anteprima).attributeRegex
: abbinaattribute
proprietà con la normale le espressioni regolari. Valido solo per la selezione degli attributi (Anteprima).
Ad esempio, il seguente file YAML di configurazione specifica le proprietà match
per selezionare la tabella testdb.acme.employee
per una trasformazione della tabella provvisoria.
type: object_rewriter
relation:
-
match:
db: testdb
schema: acme
relation: employee
temporary: true
Puoi utilizzare le proprietà dbRegex
, schemaRegex
, relationRegex
e attributeRegex
per specificare espressioni regolari al fine di selezionare un sottoinsieme di entità. L'esempio seguente modifica tutte le relazioni dallo schema tmp_schema
in testdb
in temporanee, a condizione che il nome inizi con tmp_
:
type: object_rewriter
relation:
-
match:
schema: tmp_schema
relationRegex: "tmp_.*"
temporary: true
Sia le proprietà letterali che regex
vengono associate senza distinzione tra maiuscole e minuscole.
Puoi applicare la corrispondenza sensibile alle maiuscole utilizzando un regex
con un flag i
disabilitato, come mostrato nell'esempio seguente:
match:
relationRegex: "(?-i:<actual_regex>)"
Puoi anche specificare entità qualificate utilizzando una stringa corta equivalente
a riga di comando. Una sintassi a stringa corta prevede esattamente tre (per la selezione delle relazioni) o quattro
(per la selezione degli attributi) nome segmenti delimitati da punti, come esempio
testdb.acme.employee
. I segmenti vengono poi interpretati internamente come se
sono state superate rispettivamente come db
, schema
, relation
e attribute
.
Ciò significa che i nomi vengono abbinati letteralmente, quindi le espressioni regolari non vengono
consentiti nella sintassi breve. L'esempio seguente mostra l'utilizzo di stringhe brevi
per specificare un'entità valida in un file YAML di configurazione:
type: object_rewriter
relation:
-
match : "testdb.acme.employee"
temporary: true
Se il nome di una tabella contiene un punto, non puoi specificarlo utilizzando un breve
a riga di comando. In questo caso, devi utilizzare una corrispondenza dell'oggetto. Nell'esempio che segue
cambia la tabella testdb.acme.stg.employee
in temporanea:
type: object_rewriter
relation:
-
match:
db: testdb
schema: acme
relation: stg.employee
temporary: true
La configurazione YAML accetta key
come alias per
match
.
Database predefinito
Alcuni dialetti SQL di input, in particolare Teradata, non supportano database-name
nella
nome qualificato. In questo caso, il modo più semplice per creare una corrispondenza tra le entità è omettere db
proprietà in match
.
Tuttavia, puoi impostare la proprietà default_database
di BigQuery Migration Service
e utilizza quel database predefinito in match
.
Tipi di attributi target supportati
Puoi utilizzare il file YAML di configurazione per eseguire trasformazioni del tipo di attributo, ovvero trasformare il tipo di dati di una colonna dal tipo di origine a un tipo di destinazione. La di configurazione YAML supporta i seguenti tipi di destinazione:
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 YAML di configurazione
Questa sezione fornisce esempi per creare vari file YAML di configurazione
con le traduzioni SQL. Ogni esempio illustra la sintassi YAML
trasformare la traduzione SQL in modi specifici, insieme a una breve descrizione.
Ogni esempio fornisce anche i contenuti di un elemento teradata-input.sql
hive-input.sql
e un file bq-output.sql
per confrontare
effetti di un file YAML di configurazione su una query SQL di BigQuery
una traduzione automatica.
I seguenti esempi utilizzano Teradata o Hive come SQL di input
e BigQuery SQL come dialetto di output. I seguenti
esempi utilizzano anche testdb
come database predefinito e testschema
come
percorso di ricerca dello schema.
Modifica maiuscole/minuscole del nome oggetto
Il seguente codice YAML di configurazione modifica le maiuscole/minuscole superiori o inferiori dell'oggetto nomi:
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 ; |
Creare una tabella temporanea
Il seguente YAML di configurazione modifica una tabella normale in una tabella:
type: object_rewriter
relation:
-
match: "testdb.testschema.x"
temporary: true
Una traduzione SQL con questo file YAML di configurazione potrebbe essere simile seguenti:
teradata-input.sql |
create table x(a int); |
bq-output.sql |
CREATE TEMPORARY TABLE x ( a INT64 ) ; |
Imposta la tabella come temporanea
Il seguente codice YAML di configurazione modifica una tabella normale in un tempo temporaneo tabella con un Scadenza 60 secondi.
type: object_rewriter
relation:
-
match: "testdb.testschema.x"
ephemeral:
expireAfterSeconds: 60
Una traduzione SQL con questo file YAML di configurazione potrebbe essere simile seguenti:
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) ); |
Imposta scadenza della partizione
Il seguente YAML di configurazione modifica la scadenza di un tabella su 1 giorno:
type: object_rewriter
relation:
-
match: "testdb.testschema.x"
partitionLifetime:
expireAfterSeconds: 86400
Una traduzione SQL con questo file YAML di configurazione potrebbe essere simile seguenti:
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
Il seguente codice YAML di configurazione modifica la posizione esterna e la configurazione 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 essere simile seguenti:
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' ] ); |
Imposta o modifica 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 essere simile seguenti:
teradata-input.sql |
create table x(a int); |
bq-output.sql |
CREATE TABLE testdb.testschema.x ( a INT64 ) OPTIONS( description='Example description.' ); |
Imposta o modifica il partizionamento delle tabelle
Il seguente file YAML di configurazione modifica lo schema di partizione 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 essere simile seguenti:
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 ) ; |
Imposta o modifica il clustering delle tabelle
Il seguente codice 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 essere simile seguenti:
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
Il seguente codice YAML di configurazione modifica il tipo di dati per un attributo di un colonna:
type: object_rewriter
attribute:
-
match:
db: testdb
schema: testschema
attributeRegex: "a+"
type:
target: NUMERIC(10,2)
Puoi trasformare il tipo di dati di origine in uno dei tipi di attributi target supportati.
Una traduzione SQL con questo file YAML di configurazione potrebbe essere simile seguenti:
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) ) ; |
Aggiungi connessione a data lake esterno
Il seguente codice YAML di configurazione contrassegna la tabella di origine come esterna che punta a dati archiviati in un data lake esterno, specificati da un e la connessione al lake.
type: object_rewriter
relation:
-
key: "testdb.acme.employee"
external:
connection_id: "connection_test"
Una traduzione SQL con questo file YAML di configurazione potrebbe essere simile seguenti:
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 file YAML di configurazione specifica la codifica esplicita dei caratteri
del file di input come ISO-8859-1
.
type: experimental_input_formats
formats:
- source:
pathGlob: "*.sql"
contents:
raw:
charset: iso-8859-1
Conversione di tipo globale
Il seguente codice YAML della configurazione cambia un tipo di dati in un altro e specifica un tipo di dati di origine da evitare nello script sottoposto a transpile. È diverso da Modifica il tipo di attributo di una colonna. di configurazione, 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
- Da
TIMESTAMP
aDATETIME
(accetta il fuso orario facoltativo) - Da
TIMESTAMP WITH TIME ZONE
aDATETIME
(accetta il fuso orario facoltativo) - Da
CHAR
aVARCHAR
Nell'esempio seguente, la configurazione YAML converte un TIMESTAMP
di dati a DATETIME
.
type: experimental_object_rewriter
global:
typeConvert:
timestamp: DATETIME
In dialetti come Teradata, le funzioni correlate alla data/ora, come
Timestamp di restituzione di current_date
, current_time
o current_timestamp
in base a
al fuso orario configurato, locale o di sessione. BigQuery, nel
dall'altra parte, restituisce sempre i timestamp nel fuso orario UTC. Per garantire coerenza
comportamento tra i due dialetti, è necessario configurare il fuso orario
di conseguenza.
Nell'esempio seguente, la configurazione YAML converte un TIMESTAMP
e un
Tipo di dati TIMESTAMP WITH TIME ZONE
in DATETIME
, con fuso orario target
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 essere simile seguenti:
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 dell'istruzione
La configurazione YAML seguente modifica la proiezione a stella, GROUP BY
e
Clausole 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, il codice YAML di configurazione configura
proiezione in EXPAND
.
type: experimental_statement_rewriter
select:
starProjection: EXPAND
Una traduzione SQL con questo file YAML di configurazione potrebbe essere simile seguenti:
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 codice YAML di configurazione specifica la firma del file funzioni (UDF) utilizzate negli script di origine. Proprio come i file ZIP dei metadati, Le definizioni delle funzioni definite dall'utente possono aiutare a produrre una traduzione più accurata dell'input script.
type: metadata
udfs:
- "date parse_short_date(dt int)"
Una traduzione SQL con questo file YAML di configurazione potrebbe essere simile seguenti:
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 ; |
Impostare la severità di precisione decimale
Per impostazione predefinita, BigQuery Migration Service aumenta la precisione numerica al valore massimo precisione disponibile per una data scala. Il seguente file YAML di configurazione sostituisce questo comportamento configurando la severità di precisione per la conservazione la precisione decimale dell'istruzione di origine.
type: experimental_statement_rewriter
common:
decimalPrecision: STRICT
Una traduzione SQL con questo file YAML di configurazione potrebbe essere simile seguenti:
teradata-input.sql |
create table x(a decimal(3,0)); |
bq-output.sql |
CREATE TABLE x ( a NUMERIC(3) ) ; |
Mappatura nomi di output
Puoi utilizzare YAML di configurazione per mappare i nomi degli oggetti SQL. Puoi modificare diverse parti del nome a seconda dell'oggetto da mappare.
Mapping dei nomi statico
Utilizza la mappatura dei nomi statica per mappare il nome di un'entità. Se vuoi solo modificare parti specifiche del nome, mantenendo invariate altre parti del nome, includi solo le parti che devono essere modificate.
Il seguente file YAML di configurazione cambia 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 essere simile seguenti:
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 ) |
Mappatura dinamica dei nomi
Utilizza la mappatura dinamica dei nomi per modificare più oggetti contemporaneamente e creare nuovi nomi basati sugli oggetti mappati.
Il seguente codice YAML di configurazione modifica il nome di tutte le tabelle aggiungendo
il prefisso stg_
a quelli che appartengono allo schema staging
e poi sposta questi elementi
tabelle allo 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 essere simile seguenti:
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 dello schema e del database predefinito
Il seguente codice YAML di configurazione specifica un database predefinito e sul percorso di ricerca schema.
type: environment
session:
defaultDatabase: myproject
schemaSearchPath: [myschema1, myschema2]
Una traduzione SQL con questo file YAML di configurazione potrebbe essere simile seguenti:
teradata-input.sql |
SELECT * FROM database.table SELECT * FROM table1 |
bq-output.sql |
SELECT * FROM myproject.database.table. SELECT * FROM myproject.myschema1.table1 |
Riscrittura nome output globale
La configurazione YAML seguente modifica i nomi di output di tutti gli oggetti (database, schema, relazione e attributi) nello script secondo le 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 ) ; |
Ottimizza e migliora le prestazioni del linguaggio SQL tradotto
Le trasformazioni facoltative possono essere applicate all'SQL tradotto per introdurre modifiche che possono migliorare la query in termini di prestazioni o costi. Questi le ottimizzazioni dipendono strettamente dal caso in cui si verifichi la richiesta e devono essere valutate rispetto a Output SQL per valutare il loro effetto effettivo sulle prestazioni.
Il seguente codice YAML di configurazione abilita trasformazioni facoltative. La configurazione accetta un elenco di ottimizzazioni e, per quelle che accettano parametri, una sezione con valori parametro facoltativi.
type: experimental_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 una
nelle clausole PREDICATE o PROJECTION
con una variabile precalcolata. Questo sarà identificato come un predicato statico che
per ridurre la quantità di dati letti. Se l'ambito viene omesso, il valore predefinito è PREDICATE (ovvero clausole WHERE e JOIN-ON ).
Se estrai una sottoquery scalare in un'istruzione DECLARE ,
il predicato originale diventerà statico e potrà quindi essere pianificato per un'esecuzione migliore. Questa ottimizzazione introdurrà nuove istruzioni SQL.
|
REWRITE_CTE_TO_TEMP_TABLE |
threshold: N
|
Riscrivi le espressioni di tabella comune (CTE) in tabelle temporanee quando sono presenti più di N riferimenti alla stessa espressione di tabella comune. In questo modo,
si riduce la complessità della query e si forza l'esecuzione singola dell'espressione della tabella comune.
Se N viene omesso, il valore predefinito è 4.
Ti consigliamo di utilizzare questa ottimizzazione quando i CTE non banali vengono richiamati più volte. L'introduzione delle tabelle temporanee ha un overhead che potrebbe essere maggiore di quello finale esecuzioni multiple di CTE a bassa complessità o cardinalità a bassa cardinalità. Questa ottimizzazione introdurrà nuove istruzioni SQL. |
REWRITE_ZERO_SCALE_NUMERIC_AS_INTEGER |
bigint: N
|
Riscrive gli attributi NUMERIC/BIGNUMERIC con scala zero in
Tipo INT64 se la precisione è compresa tra N . Se N viene omesso, il valore predefinito è 18 .
Ti consigliamo di utilizzare questa ottimizzazione quando traduci da dialetti di origine che non includono tipi di numeri interi. La modifica dei tipi di colonna richiede la revisione di tutti gli utilizzi downstream per la compatibilità dei tipi e le modifiche semantiche. Ad esempio, le divisioni frazionarie divisioni intere, codice che prevede valori numerici |
DROP_TEMP_TABLE |
Aggiunge istruzioni DROP TABLE per tutte le tabelle temporanee create
in uno script e non eliminate al termine. 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 viene eseguito alcun accesso alle tabelle temporanee per ulteriori elaborazioni al termine dell'esecuzione dello script. Questa ottimizzazione introdurrà nuove istruzioni SQL. |
|
REGEXP_CONTAINS_TO_LIKE |
Riscrive alcune categorie di REGEXP_CONTAINS pattern corrispondenti
alle espressioni LIKE .
Consigliamo di utilizzare questa ottimizzazione quando non si basa nessun altro processo, come la sostituzione di macro, sui valori letterali del pattern di espressioni regolari che vengono conservati nell'SQL di output. |
|
ADD_DISTINCT_TO_SUBQUERY_IN_SET_COMPARISON |
Aggiunge la clausola DISTINCT alle sottoquery utilizzate come valore impostato per
Operatore [NOT] IN .
Ti consigliamo di utilizzare questa ottimizzazione quando la cardinalità (numero distinto di valori) del il risultato della sottoquery è significativamente inferiore al numero di valori. Se questo precondizionatore non viene soddisfatto, la trasformazione può avere effetti negativi sul rendimento. |
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 singolo job di traduzione per riflettere più trasformazioni. Se sono presenti più configurazioni conflitto, una trasformazione potrebbe prevalere su un'altra. È consigliabile 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 per un singolo job di traduzione SQL, uno per modificare l'attributo di una colonna, e l'altra 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 essere seguenti:
teradata-input.sql |
create table x(a int); |
bq-output.sql |
CREATE TEMPORARY TABLE x ( a NUMERIC(31, 2) ) ; |