Guida alla traduzione SQL di Snowflake
Questo documento descrive in dettaglio le somiglianze e le differenze nella sintassi SQL tra Snowflake e BigQuery per contribuire ad accelerare la pianificazione e l'esecuzione del trasferimento dell'EDW (Enterprise Data Warehouse) a BigQuery. Il data warehousing Snowflake è progettato per funzionare con la sintassi SQL specifica di Snowflake. Gli script scritti per Snowflake potrebbero dover essere modificati prima di poter essere utilizzati in BigQuery, perché i dialetti SQL variano tra i servizi. Utilizza la traduzione SQL batch per eseguire la migrazione degli script SQL in blocco oppure la traduzione SQL interattiva per tradurre le query ad hoc. Snowflake SQL è supportato da entrambi gli strumenti in anteprima.
Tipi di dati
Questa sezione mostra le equivalenze tra i tipi di dati in Snowflake e in BigQuery.
| Snowflake | BigQuery | Note |
|---|---|---|
NUMBER/
DECIMAL/NUMERIC |
NUMERIC/BIGNUMERIC |
Può essere mappato su NUMERIC o BIGNUMERIC, a seconda della precisione e della scala.Il tipo di dati NUMBER in Snowflake supporta 38 cifre di precisione e 37 cifre di scalabilità. La precisione e la scala possono essere specificate in base all'utente.BigQuery supporta NUMERIC e BIGNUMERIC con precisione e scala specificate facoltativamente entro determinati limiti. |
INT/INTEGER |
BIGNUMERIC |
INT/INTEGER e tutti gli altri tipi di dati simili a INT, come BIGINT, TINYINT, SMALLINT, BYTEINT, rappresentano un alias per il tipo di dati NUMBER in cui la precisione e la scala non possono essere specificate ed è sempre NUMBER(38, 0)BigQuery converte INTEGER in INT64 per impostazione predefinita. Per configurare la traduzione SQL in modo da convertirla in altri tipi di dati, puoi utilizzare l'opzione di configurazione REWRITE_ZERO_SCALE_NUMERIC_AS_INTEGER. |
BIGINT |
BIGNUMERIC |
|
SMALLINT |
BIGNUMERIC |
|
TINYINT |
BIGNUMERIC |
|
BYTEINT |
BIGNUMERIC |
|
FLOAT/ |
FLOAT64 |
Il tipo di dati FLOAT in Snowflake stabilisce che "NaN" è > X, dove X è qualsiasi valore FLOAT (diverso da "NaN").Il tipo di dati FLOAT in BigQuery stabilisce che "NaN" è < X, dove X è qualsiasi valore FLOAT (diverso da "NaN"). |
DOUBLE/REAL |
FLOAT64 |
Il tipo di dati DOUBLE in Snowflake è sinonimo del tipo di dati FLOAT in Snowflake, ma viene spesso visualizzato in modo errato come FLOAT. Viene archiviato correttamente come DOUBLE. |
VARCHAR |
STRING |
Il tipo di dati VARCHAR in Snowflake ha una lunghezza massima di 128 MB (non compressi). Se la lunghezza non è specificata, il valore predefinito è la lunghezza massima.Il tipo di dati STRING in BigQuery viene archiviato come Unicode con codifica UTF-8 a lunghezza variabile. Per saperne di più sui limiti di colonne e righe, consulta Job di query. |
CHAR/CHARACTER |
STRING |
|
STRING/TEXT |
STRING |
Il tipo di dati STRING in Snowflake è sinonimo di VARCHAR di Snowflake. |
BINARY |
BYTES |
|
VARBINARY |
BYTES |
|
BOOLEAN |
BOOL |
Il tipo di dati BOOL in BigQuery può accettare solo TRUE/FALSE, a differenza del tipo di dati BOOL in Snowflake, che può accettare TRUE/FALSE/NULL. |
DATE |
DATE |
Il tipo DATE in Snowflake accetta i formati di data più comuni, a differenza del tipo DATE in BigQuery, che accetta solo date nel formato "AAAA-[M]M-[G]G". |
TIME |
TIME |
Il tipo TIME in Snowflake supporta da 0 a 9 nanosecondi di precisione, mentre il tipo TIME in BigQuery supporta da 0 a 6 nanosecondi di precisione. |
TIMESTAMP |
DATETIME |
TIMESTAMP è un alias configurabile dall'utente che per impostazione predefinita è TIMESTAMP_NTZ, che corrisponde a DATETIME in BigQuery. |
TIMESTAMP_LTZ |
TIMESTAMP |
|
TIMESTAMP_NTZ/DATETIME | ||
DATETIME |
||
TIMESTAMP_TZ |
TIMESTAMP |
|
OBJECT |
JSON |
|
VARIANT |
JSON |
|
ARRAY |
ARRAY<JSON> |
Il servizio di traduzione SQL conserva il tipo di dati per gli array tipizzati. Per gli array non tipizzati, ad esempio ARRAY<VARIANT>, BigQuery li converte in ARRAY<JSON> |
BigQuery dispone anche dei seguenti tipi di dati che non hanno un analogo Snowflake diretto:
Sintassi CREATE FUNCTION
La seguente tabella illustra le differenze nella sintassi di creazione delle UDF SQL tra Snowflake e BigQuery.
| Snowflake | BigQuery |
|---|---|
|
Nota: nel SQL UDF di BigQuery, il tipo di dati restituito è facoltativo. BigQuery deduce il tipo di risultato della funzione dal corpo della funzione SQL quando una query chiama la funzione. |
|
Nota:in BigQuery SQL UDF, il tipo di tabella restituito non è supportato, ma è nella roadmap del prodotto e sarà disponibile a breve. Tuttavia, BigQuery supporta la restituzione di ARRAY di tipo STRUCT. |
|
Nota: Snowflake offre un'opzione sicura per limitare la definizione e i dettagli delle UDF solo agli utenti autorizzati (ovvero gli utenti a cui è stato concesso il ruolo proprietario della visualizzazione). |
Nota: la sicurezza delle funzioni non è un parametro configurabile in BigQuery. BigQuery supporta la creazione di ruoli e autorizzazioni IAM per limitare l'accesso ai dati e alla definizione della funzione sottostanti. |
|
Nota: il comportamento della funzione per gli input nulli viene gestito implicitamente in BigQuery e non deve essere specificato come opzione separata. |
|
Nota:la volatilità della funzione non è un parametro configurabile in BigQuery. Tutta la volatilità delle UDF BigQuery è equivalente alla volatilità IMMUTABLE di Snowflake (ovvero non esegue ricerche nel database o utilizza in altro modo informazioni non direttamente presenti nell'elenco degli argomenti). |
|
CREATE [OR REPLACE] FUNCTION
Nota: l'utilizzo di virgolette singole o di una sequenza di caratteri come le virgolette del dollaro ($$) is not required or supported in BigQuery. BigQuery implicitly interprets the SQL expression. |
|
Note: Adding comments or descriptions in UDFs is not supported in BigQuery. |
|
Note: BigQuery supports using ANY TYPE as argument type. The function will accept an input of any type for this argument. For more information, see templated parameter in BigQuery. |
BigQuery also supports the CREATE FUNCTION IF NOT EXISTSstatement
which treats the query as successful and takes no action if a function with the
same name already exists.
BigQuery's CREATE FUNCTIONstatement also supports creating
TEMPORARY or TEMP functions, which do
not have a Snowflake equivalent. See
calling UDFs
for details on executing a BigQuery persistent UDF.
DROP FUNCTION syntax
The following table addresses differences in DROP FUNCTION syntax between Snowflake and BigQuery.
| Snowflake | BigQuery |
|---|---|
|
Note: BigQuery does not require using the function's signature (argument data type) for deleting the function. |
BigQuery requires that you specify the project_name if the function
is not located in the current project.
Additional function commands
This section covers additional UDF commands supported by Snowflake that are not directly available in BigQuery.
ALTER FUNCTION syntax
Snowflake supports the following operations using
ALTER FUNCTION
syntax.
- Renaming a UDF
- Converting to (or reverting from) a secure UDF
- Adding, overwriting, removing a comment for a UDF
As configuring function security and adding function comments is not available
in BigQuery, ALTER FUNCTION syntax is not supported. However,
the CREATE FUNCTION
statement can be used to create a UDF with the same function definition but a
different name.
DESCRIBE FUNCTION syntax
Snowflake supports describing a UDF using DESC[RIBE] FUNCTION syntax. This is not supported in BigQuery. However, querying UDF metadata via INFORMATION SCHEMA will be available soon as part of the product roadmap.
SHOW USER FUNCTIONS syntax
In Snowflake, SHOW USER FUNCTIONS syntax can be used to list all UDFs for which users have access privileges. This is not supported in BigQuery. However, querying UDF metadata via INFORMATION SCHEMA will be available soon as part of the product roadmap.
Stored procedures
Snowflake stored procedures are written in JavaScript, which can execute SQL statements by calling a JavaScript API. In BigQuery, stored procedures are defined using a block of SQL statements.
CREATE PROCEDURE syntax
In Snowflake, a stored procedure is executed with a CALL command while in BigQuery, stored procedures are executed like any other BigQuery function.
The following table addresses differences in stored procedure creation syntax between Snowflake and BigQuery.
| Snowflake | BigQuery |
|---|---|
|
Note: Snowflake requires that stored procedures return a single value. Hence, return data type is a required option. |
CREATE [OR REPLACE] PROCEDURE
Note: BigQuery doesn't support a return type for stored procedures. Also, it requires specifying argument mode for each argument passed. |
|
|
|
CREATE [OR REPLACE] PROCEDURE
Nota: il comportamento della procedura per gli input nulli viene gestito implicitamente in BigQuery e non deve essere specificato come opzione separata. |
CREATE [OR REPLACE] PROCEDURE
|
Nota:la volatilità della procedura non è un parametro configurabile in BigQuery. È equivalente alla volatilità IMMUTABLE di Snowflake. |
CREATE [OR REPLACE] PROCEDURE
|
Nota: l'aggiunta di commenti o descrizioni nelle definizioni delle procedure non è supportata in BigQuery. |
CREATE [OR REPLACE] PROCEDURE
Nota: Snowflake supporta la specifica del chiamante o del proprietario della procedura per l'esecuzione |
Nota: le stored procedure BigQuery vengono sempre eseguite come chiamante |
BigQuery supporta anche l'istruzione CREATE PROCEDURE IF NOT EXISTS, che considera la query riuscita e non esegue alcuna azione se esiste già una funzione con lo stesso nome.
Sintassi DROP PROCEDURE
La seguente tabella illustra le differenze nella sintassi DROP FUNCTION tra Snowflake e BigQuery.
| Snowflake | BigQuery |
|---|---|
|
Nota: BigQuery non richiede l'utilizzo della firma della procedura (tipo di dati dell'argomento) per l'eliminazione della procedura. |
BigQuery richiede di specificare project_name se la procedura
non si trova nel progetto corrente.
Comandi per procedure aggiuntive
Snowflake fornisce comandi aggiuntivi come
ALTER PROCEDURE,
DESC[RIBE] PROCEDURE
e
SHOW PROCEDURES
per gestire le stored procedure. Questi non sono supportati in
BigQuery.
Istruzioni SQL per metadati e transazioni
| Snowflake | BigQuery |
|---|---|
|
BigQuery utilizza sempre l'isolamento dello snapshot. Per i dettagli, consulta la sezione Garanzie di coerenza in questo documento. |
|
Non utilizzato in BigQuery. |
|
Non utilizzato in BigQuery |
|
Non utilizzato in BigQuery. |
Istruzioni SQL multiriga e con più istruzioni
Sia Snowflake che BigQuery supportano le transazioni (sessioni) e quindi le istruzioni separate da punti e virgola che vengono eseguite in modo coerente insieme. Per maggiori informazioni, consulta la sezione Transazioni con più estratti conto.
Colonne di metadati per i file di staging
Snowflake genera automaticamente i metadati per i file nelle fasi interne ed esterne. Questi metadati possono essere interrogati e caricati in una tabella insieme alle normali colonne di dati. È possibile utilizzare le seguenti colonne di metadati:
Garanzie di coerenza e isolamento delle transazioni
Sia Snowflake che BigQuery sono atomici, ovvero conformi ad ACID a livello di mutazione in molte righe.
Transazioni
A ogni transazione Snowflake viene assegnato un orario di inizio univoco (inclusi
i millisecondi) impostato come ID transazione. Snowflake supporta solo il
READ COMMITTED
livello di isolamento. Tuttavia, un'istruzione può vedere le modifiche apportate da un'altra istruzione
se entrambe si trovano nella stessa transazione, anche se queste modifiche non sono
ancora state eseguite. Le transazioni Snowflake acquisiscono blocchi sulle risorse (tabelle) quando
la risorsa viene modificata. Gli utenti possono regolare il tempo massimo di attesa di un'istruzione bloccata prima che scada il relativo timeout. Le istruzioni DML vengono
eseguite automaticamente se il
parametro AUTOCOMMIT
è attivo.
BigQuery supporta anche le transazioni. BigQuery contribuisce a garantire il controllo della concorrenza ottimistico (vince chi esegue il commit per primo) con l'isolamento dello snapshot, in cui una query legge gli ultimi dati di cui è stato eseguito il commit prima dell'inizio della query. Questo approccio garantisce lo stesso livello di coerenza per riga, per mutazione e tra le righe all'interno della stessa istruzione DML, evitando al contempo i deadlock. In caso di più aggiornamenti DML sulla stessa tabella, BigQuery passa al controllo della concorrenza pessimistico. I job di caricamento possono essere eseguiti in modo completamente indipendente e aggiungere dati alle tabelle. Tuttavia, BigQuery non fornisce un limite di transazione esplicito o una sessione.
Esegui il rollback
Se la sessione di una transazione Snowflake viene terminata in modo imprevisto prima che la transazione venga eseguita o annullata, la transazione viene lasciata in uno stato separato. L'utente deve eseguire SYSTEM$ABORT_TRANSACTION per interrompere la transazione separata oppure Snowflake eseguirà il rollback della transazione separata dopo quattro ore di inattività. Se si verifica un deadlock, Snowflake lo rileva e seleziona l'istruzione più recente da eseguire il rollback. Se l'istruzione DML in una transazione aperta in modo esplicito non va a buon fine, le modifiche vengono annullate, ma la transazione rimane aperta finché non viene eseguito il commit o il rollback. Le istruzioni DDL in Snowflake non possono essere ripristinate perché vengono eseguite automaticamente.
BigQuery supporta l'istruzione
ROLLBACK TRANSACTION.
Non esiste un'istruzione
ABORT
in BigQuery.
Limiti per i database
Controlla sempre la documentazione pubblica di BigQuery per quote e limiti più recenti. Molte quote per gli utenti con volumi elevati possono essere aumentate contattando il team di assistenza Cloud.
Per impostazione predefinita, tutti gli account Snowflake hanno limiti temporanei. I limiti temporanei vengono impostati durante la creazione dell'account e possono variare. Molti limiti temporanei di Snowflake possono essere aumentati tramite il team dedicato all'account Snowflake o un ticket di assistenza.
La tabella seguente mostra un confronto tra i limiti dei database Snowflake e BigQuery.
| Limite | Snowflake | BigQuery |
|---|---|---|
| Dimensioni del testo della query | 1 MB | 1 MB |
| Numero massimo di query simultanee | XS Warehouse - 8 S Warehouse - 16 M Warehouse - 32 L Warehouse - 64 XL Warehouse - 128 |
100 |