Guide de traduction SQL Snowflake

Ce document décrit les similitudes et les différences de syntaxe SQL entre Snowflake et BigQuery pour vous aider à accélérer la planification et l'exécution de la migration de votre entrepôt de données d'entreprise (EDW, Enterprise Data Warehouse) vers BigQuery. L'entreposage de données Snowflake est conçu pour fonctionner avec la syntaxe SQL propre à Snowflake. Vous devrez peut-être modifier les scripts écrits pour Snowflake pour pouvoir les utiliser dans BigQuery, car les dialectes SQL varient selon les services. Utilisez la traduction SQL par lot pour migrer vos scripts SQL de façon groupée, ou la traduction SQL interactive pour traduire des requêtes ad hoc. Snowflake SQL est compatible avec les deux outils en version preview.

Remarque : Dans certains cas, il n'existe pas de correspondance direct entre un élément SQL dans Snowflake et BigQuery. Cependant, dans la plupart des cas, vous pouvez obtenir la même fonctionnalité dans BigQuery que dans Snowflake par un autre moyen, comme indiqué dans les exemples fournis dans ce document.

Types de données

Cette section présente les équivalences entre les types de données dans Snowflake et BigQuery.

Snowflake	BigQuery	Remarques
NUMBER/ DECIMAL/NUMERIC	NUMERIC/BIGNUMERIC	Peut être mis en correspondance avec NUMERIC ou BIGNUMERIC, selon la précision et l'échelle. Le type de données NUMBER dans Snowflake accepte 38 chiffres de précision et 37 chiffres d'échelle. La précision et l'échelle peuvent être spécifiées en fonction de l'utilisateur. BigQuery accepte NUMERIC et BIGNUMERIC avec la précision et l'échelle facultatives dans certaines limites.
INT/INTEGER	BIGNUMERIC	INT/INTEGER et tous les autres types de données INT, tels que BIGINT, TINYINT, SMALLINT, BYTEINT, représentent un alias pour le type de données NUMBER, où la précision et l'échelle ne peuvent pas être spécifiées, et sont toujours définies sur NUMBER(38, 0) BigQuery convertit INTEGER en INT64 par défaut. Pour configurer la traduction SQL afin de la convertir en d'autres types de données, vous pouvez utiliser l'option de configuration REWRITE_ZERO_SCALE_NUMERIC_AS_INTEGER.
BIGINT	BIGNUMERIC
SMALLINT	BIGNUMERIC
TINYINT	BIGNUMERIC
BYTEINT	BIGNUMERIC
FLOAT/ FLOAT4/ FLOAT8	FLOAT64	Le type de données FLOAT de Snowflake établit "NaN" comme étant supérieur à X, où X est une valeur FLOAT (autre que "NaN"). Le type de données FLOAT de BigQuery établit "NaN" sur <X, où X est une valeur FLOAT (autre que "NaN").
DOUBLE/ DOUBLE PRECISION/ REAL	FLOAT64	Le type de données DOUBLE de Snowflake est synonyme du type de données FLOAT dans Snowflake, mais il s'affiche généralement de manière incorrecte comme FLOAT. Il est correctement stocké sous le nom DOUBLE.
VARCHAR	STRING	Le type de données VARCHAR dans Snowflake ne doit pas dépasser 128 Mo de longueur (non compressé). Si la longueur n'est pas spécifiée, la valeur par défaut est la longueur maximale. Dans BigQuery, le type de données STRING est stocké sous la forme d'un Unicode encodé UTF-8 de longueur variable. Pour en savoir plus sur les limites de colonnes et de lignes, consultez Jobs de requête.
CHAR/CHARACTER	STRING
STRING/TEXT	STRING	Le type de données STRING dans Snowflake est synonyme de VARCHAR de Snowflake.
BINARY	BYTES
VARBINARY	BYTES
BOOLEAN	BOOL	Le type de données BOOL de BigQuery ne peut accepter que TRUE/FALSE, contrairement au type de données BOOL de Snowflake, qui peut accepter TRUE/FALSE/NULL.
DATE	DATE	Le type DATE dans Snowflake accepte les formats de date les plus courants, contrairement au type DATE dans BigQuery, qui n'accepte que les dates au format AAAA-[M]M-[D]D.
TIME	TIME	Le type TIME de Snowflake accepte une précision de 0 à 9 nanosecondes, tandis que le type TIME de BigQuery accepte une précision de 0 à 6 nanosecondes.
TIMESTAMP	DATETIME	TIMESTAMP est un alias configurable par l'utilisateur dont la valeur par défaut est TIMESTAMP_NTZ et qui correspond à DATETIME dans BigQuery.
TIMESTAMP_LTZ	TIMESTAMP
TIMESTAMP_NTZ/DATETIME
DATETIME
TIMESTAMP_TZ	TIMESTAMP
OBJECT	JSON
VARIANT	JSON
ARRAY	ARRAY<JSON>	Le service de traduction SQL préserve le type de données pour les tableaux typés. Pour les tableaux non typés, tels que ARRAY<VARIANT>, BigQuery les convertit en ARRAY<JSON>.

BigQuery dispose également des types de données suivants, qui ne disposent pas d'un équivalent direct Snowflake :

• DATETIME
• GEOGRAPHY

Syntaxe de CREATE FUNCTION

Le tableau suivant traite des différences de syntaxe de création d'UDF (fonctions définies par l'utilisateur) SQL entre Snowflake et BigQuery.

Snowflake	BigQuery
CREATE [ OR REPLACE ] FUNCTION function_name ([sql_arg_name sql_arg_data_type[,..]]) RETURNS data_type AS sql_function_definition s	CREATE [OR REPLACE] FUNCTION function_name ([sql_arg_name sql_arg_data_type[,..]]) AS sql_function_definition Remarque: Dans la fonction définie par l'utilisateur SQL de BigQuery, le type de données renvoyé est facultatif. BigQuery déduit le type renvoyé par votre fonction à partir du corps de la fonction SQL lorsqu'elle est appelée par une requête.
CREATE [OR REPLACE] FUNCTION function_name ([sql_arg_name sql_arg_data_type[,..]]) RETURNS TABLE (col_name, col_data_type[,..]) AS sql_function_definition	CREATE [OR REPLACE] FUNCTION function_name ([sql_arg_name sql_arg_data_type[,..]]) RETURNS data_type AS sql_function_definition Remarque : Dans une UDF SQL BigQuery, le type de table renvoyé n'est pas compatible, mais figure sur la feuille de route du produit et le sera bientôt. Cependant, BigQuery accepte le renvoi de tableaux de type STRUCT.
CREATE [SECURE] FUNCTION function_name ([sql_arg_name sql_arg_data_type[,..]]) RETURNS data_type AS sql_function_definition Remarque: Snowflake fournit une option sécurisée permettant de limiter la définition et les détails des fonctions définies par l'utilisateur uniquement aux utilisateurs autorisés (c'est-à-dire aux utilisateurs auxquels le rôle est propriétaire de la vue).	CREATE FUNCTION function_name ([sql_arg_name sql_arg_data_type[,..]]) RETURNS data_type AS sql_function_definition Remarque : La sécurité des fonctions n'est pas un paramètre configurable dans BigQuery. BigQuery permet de créer des rôles et des autorisations IAM pour restreindre l'accès aux données sous-jacentes et à la définition de fonctions.
CREATE [OR REPLACE] FUNCTION function_name ([sql_arg_name sql_arg_data_type[,..]]) RETURNS data_type [ { CALLED ON NULL INPUT | { RETURNS NULL ON NULL INPUT | STRICT } } ] AS sql_function_definition	CREATE [OR REPLACE] FUNCTION function_name ([sql_arg_name sql_arg_data_type[,..]]) RETURNS data_type AS sql_function_definition Remarque: Le comportement de la fonction pour les entrées nulles est implicitement géré dans BigQuery et ne doit pas être spécifié comme option distincte.
CREATE [OR REPLACE] FUNCTION function_name ([sql_arg_name sql_arg_data_type[,..]]) RETURNS data_type [VOLATILE | IMMUTABLE] AS sql_function_definition	CREATE [OR REPLACE] FUNCTION function_name ([sql_arg_name sql_arg_data_type[,..]]) RETURNS data_type AS sql_function_definition Remarque : La volatilité des fonctions n'est pas un paramètre configurable dans BigQuery. Toute volatilité d'UDF BigQuery est équivalente à la volatilité IMMUTABLE de Snowflake (c'est-à-dire qu'elle n'effectue pas de recherches de base de données et n'utilise pas d'autres informations que celles directement présentes dans sa liste d'arguments).
CREATE [OR REPLACE] FUNCTION function_name ([sql_arg_name sql_arg_data_type[,..]]) RETURNS data_type AS [' | $$] sql_function_definition [' | $$]	CREATE [OR REPLACE] FUNCTION function_name ([sql_arg_name sql_arg_data_type[,..]]) RETURNS data_type AS sql_function_definition Remarque : L'utilisation de guillemets simples ou d'une séquence de caractères telle que les guillemets dollars ($$) is not required or supported in BigQuery. BigQuery implicitly interprets the SQL expression.
CREATE [OR REPLACE] FUNCTION function_name ([sql_arg_name sql_arg_data_type[,..]]) RETURNS data_type [COMMENT = '<string_literal>'] AS sql_function_definition	CREATE [OR REPLACE] FUNCTION function_name ([sql_arg_name sql_arg_data_type[,..]]) RETURNS data_type AS sql_function_definition Note: Adding comments or descriptions in UDFs is not supported in BigQuery.
CREATE [OR REPLACE] FUNCTION function_name (x integer, y integer) RETURNS integer AS $$ SELECT x + y $$ Note: Snowflake does not support ANY TYPE for SQL UDFs. However, it supports using VARIANT data types.	CREATE [OR REPLACE] FUNCTION function_name (x ANY TYPE, y ANY TYPE) AS SELECT x + y 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
DROP FUNCTION [IF EXISTS] function_name ([arg_data_type, ... ])	DROP FUNCTION [IF EXISTS] dataset_name.function_name 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
CREATE [OR REPLACE] PROCEDURE procedure_name ([arg_name arg_data_type[,..]]) RETURNS data_type AS procedure_definition; Note: Snowflake requires that stored procedures return a single value. Hence, return data type is a required option.	CREATE [OR REPLACE] PROCEDURE procedure_name ([arg_mode arg_name arg_data_type[,..]]) BEGIN procedure_definition END; arg_mode: IN | OUT | INOUT 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 procedure_name ([arg_name arg_data_type[,..]]) RETURNS data_type AS $$ javascript_code $$;	CREATE [OR REPLACE] PROCEDURE procedure_name ([arg_name arg_data_type[,..]]) BEGIN statement_list END;
CREATE [OR REPLACE] PROCEDURE procedure_name ([arg_name arg_data_type[,..]]) RETURNS data_type [{CALLED ON NULL INPUT | {RETURNS NULL ON NULL INPUT | STRICT}}] AS procedure_definition;	CREATE [OR REPLACE] PROCEDURE procedure_name ([arg_name arg_data_type[,..]]) BEGIN procedure_definition END; Remarque: Le comportement de la procédure pour les entrées nulles est implicitement géré dans BigQuery et ne doit pas être spécifié comme option distincte.
CREATE [OR REPLACE] PROCEDURE procedure_name ([arg_name arg_data_type[,..]]) RETURNS data_type [VOLATILE | IMMUTABLE] AS procedure_definition;	CREATE [OR REPLACE] PROCEDURE procedure_name ([arg_name arg_data_type[,..]]) BEGIN procedure_definition END; Remarque : La volatilité des procédures n'est pas un paramètre configurable dans BigQuery. Il est équivalent à la volatilité IMMUTABLE de Snowflake.
CREATE [OR REPLACE] PROCEDURE procedure_name ([arg_name arg_data_type[,..]]) RETURNS data_type [COMMENT = '<string_literal>'] AS procedure_definition;	CREATE [OR REPLACE] PROCEDURE procedure_name ([arg_name arg_data_type[,..]]) BEGIN procedure_definition END; Remarque : L'ajout de commentaires ou de descriptions dans les définitions de procédure n'est pas disponible dans BigQuery.
CREATE [OR REPLACE] PROCEDURE procedure_name ([arg_name arg_data_type[,..]]) RETURNS data_type [EXECUTE AS { CALLER | OWNER }] AS procedure_definition; Remarque: Snowflake permet de spécifier l'appelant ou le propriétaire de la procédure pour l'exécution.	CREATE [OR REPLACE] PROCEDURE procedure_name ([arg_name arg_data_type[,..]]) BEGIN procedure_definition END; Remarque: Les procédures stockées BigQuery sont toujours exécutées en tant qu'appelant

BigQuery accepte également l'instruction CREATE PROCEDURE IF NOT EXISTS, qui traite la requête comme réussie et n'effectue aucune action si une fonction du même nom existe déjà.

Syntaxe de DROP PROCEDURE

Le tableau suivant traite des différences de syntaxe de DROP FUNCTION entre Snowflake et BigQuery.

Snowflake	BigQuery
DROP PROCEDURE [IF EXISTS] procedure_name ([arg_data_type, ... ])	DROP PROCEDURE [IF EXISTS] dataset_name.procedure_name Remarque: BigQuery ne nécessite pas d'utiliser la signature de la procédure (type de données d'argument) pour supprimer la procédure.

BigQuery nécessite que vous spécifiiez project_name si la procédure ne se trouve pas dans le projet actuel.

Commandes de procédure supplémentaires

Snowflake fournit des commandes supplémentaires telles que :ALTER PROCEDURE ,DESC[RIBE] PROCEDURE etSHOW PROCEDURES pour gérer les procédures stockées. Celles-ci ne sont pas compatibles avec BigQuery.

Instructions SQL de métadonnées et de transactions

Snowflake	BigQuery
BEGIN [ { WORK | TRANSACTION } ] [ NAME <name> ]; START_TRANSACTION [ name <name> ];	BigQuery utilise toujours l'isolation d'instantané. Pour en savoir plus, consultez la section Garanties de cohérence ailleurs dans ce document.
COMMIT;	Non utilisé dans BigQuery.
ROLLBACK;	Non utilisé dans BigQuery
SHOW LOCKS [ IN ACCOUNT ]; SHOW TRANSACTIONS [ IN ACCOUNT ]; Note: If the user has the ACCOUNTADMIN role, the user can see locks/transactions for all users in the account.	Non utilisé dans BigQuery.

Instructions SQL multi-instructions et multilignes

Snowflake et BigQuery acceptent les transactions (sessions) et donc les instructions séparées par un point-virgule qui sont systématiquement exécutées ensemble. Pour plus d'informations, consultez la section Transactions multi-instructions.

Colonnes de métadonnées pour les fichiers intermédiaires

Snowflake génère automatiquement des métadonnées pour les fichiers aux étapes internes et externes. Vous pouvez interroger et charger ces métadonnées dans une table avec les colonnes de données standards. Les colonnes de métadonnées suivantes peuvent être utilisées:

• METADATA$FILENAME
• METADATA$FILE_ROW_NUMBER

Garanties de cohérence et isolation de transaction

Snowflake et BigQuery sont tous deux atomiques, c'est-à-dire conformes à la norme ACID au niveau de chaque mutation sur de nombreuses lignes.

Transactions

Chaque transaction Snowflake se voit attribuer une heure de début unique (avec millisecondes) définie comme ID de transaction. Snowflake n'est compatible qu'avec le niveau d'isolation READ COMMITTED. Toutefois, une instruction peut voir les modifications apportées par une autre instruction si elles se trouvent toutes les deux dans la même transaction, même si ces modifications ne sont pas encore validées. Les transactions Snowflake acquièrent des verrous sur les ressources (tables) lorsque ces ressources sont modifiées. Les utilisateurs peuvent ajuster le délai maximal d'attente d'une instruction bloquée jusqu'à ce qu'elle expire. Les instructions LMD sont validées automatiquement si le paramètre AUTOCOMMIT est activé.

BigQuery est également compatible avec les transactions. BigQuery permet d'assurer un contrôle de simultanéité optimiste (le premier à effectuer un commit l'emporte) avec isolation d'instantané, où une requête lit les dernières données validées avant le démarrage de la requête. Cette approche garantit le même niveau de cohérence par ligne, par mutation et entre les lignes d'une même instruction LMD, tout en évitant les interblocages. Si plusieurs mises à jour LMD sont effectuées sur la même table, BigQuery bascule vers le contrôle de simultanéité pessimiste. Les jobs de chargement peuvent s'exécuter complètement indépendamment et ajouter des données aux tables. Cependant, BigQuery ne fournit pas de limite de transaction explicite ni de session.

Rollback

Si la session d'une transaction Snowflake est arrêtée de manière inattendue avant le commit ou le rollback de la transaction, elle est laissée dans un état dissocié. L'utilisateur doit exécuter SYSTEM$ABORT_TRANSACTION pour annuler la transaction dissociée, ou Snowflake effectuera un rollback de la transaction dissociée au bout de quatre heures d'inactivité. Dans ce cas, Snowflake détecte l'interblocage et sélectionne l'instruction la plus récente pour effectuer un rollback. Si l'instruction LMD d'une transaction explicitement ouverte échoue, les modifications sont annulées, mais la transaction reste ouverte jusqu'à ce qu'elle soit validée ou annulée. Les instructions LDD de Snowflake ne peuvent pas faire l'objet d'un rollback, car elles sont validées automatiquement.

BigQuery accepte l'instruction ROLLBACK TRANSACTION. Il n'y a pas d'instruction ABORT dans BigQuery.

Limites des bases de données

Vérifiez toujours les derniers quotas et les dernières limites dans la documentation publique BigQuery. Les utilisateurs ayant un volume de requêtes important peuvent demander l'augmentation de nombreux quotas en contactant l'équipe d'assistance Cloud.

Tous les comptes Snowflake ont des limites flexibles définies par défaut. Les limites flexibles sont définies lors de la création d'un compte et peuvent varier. De nombreuses limites flexibles de Snowflake peuvent être augmentées via l'équipe de gestion de compte Snowflake ou une demande d'assistance.

Le tableau suivant présente une comparaison des limites de base de données pour Snowflake et BigQuery.

Limite	Snowflake	BigQuery
Taille du texte de la requête	1 Mo	1 Mo
Nombre maximal de requêtes simultanées	XS Warehouse - 8 S Warehouse - 16 M Warehouse - 32 L Warehouse - 64 XL Warehouse - 128	100