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	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).
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 16 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. La longueur ne doit pas dépasser 16 000 caractères.
CHAR/CHARACTER	STRING	Le type de données CHAR dans Snowflake a une longueur maximale de 1.
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	Le type OBJECT de Snowflake n'accepte pas les valeurs de type explicite. Les valeurs sont de type VARIANT.
VARIANT	JSON	Le type OBJECT de Snowflake n'accepte pas les valeurs de type explicite. Les valeurs sont de type VARIANT.
ARRAY	ARRAY<JSON>	Le type ARRAY de Snowflake n'accepte que les types VARIANT, tandis que le type ARRAY de BigQuery peut accepter tous les types de données, à l'exception d'un tableau lui-même.

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

• DATETIME
• GEOGRAPHY

Syntaxe des requêtes et opérateurs de requêtes

Cette section traite des différences de syntaxe des requêtes entre Snowflake et BigQuery.

Instruction SELECT

La plupart des instructions SELECT Snowflake sont compatibles avec BigQuery. Le tableau suivant contient une liste de différences mineures.

Snowflake		BigQuery
SELECT TOP ... FROM table		SELECT expression FROM table ORDER BY expression DESC LIMIT number
SELECT x/total AS probability, ROUND(100 * probability, 1) AS pct FROM raw_data Remarque : Snowflake permet de créer et de référencer un alias dans la même instruction SELECT.		SELECT x/total AS probability, ROUND(100 * (x/total), 1) AS pct FROM raw_data
SELECT * FROM ( VALUES (1), (2), (3) )		SELECT AS VALUE STRUCT(1, 2, 3)

Par défaut, les alias et les identifiants Snowflake ne sont pas sensibles à la casse. Pour conserver la casse, placez les alias et les identifiants entre guillemets doubles (").

Clause FROM

Une clause FROM d'une requête spécifie les tables, les vues, les sous-requêtes ou les fonctions de table possibles à utiliser dans une instruction SELECT. Toutes ces références de table sont acceptées dans BigQuery.

Le tableau suivant contient une liste de différences mineures.

Snowflake		BigQuery
SELECT $1, $2 FROM (VALUES (1, 'one'), (2, 'two'));		WITH table1 AS ( SELECT STRUCT(1 as number, 'one' as spelling) UNION ALL SELECT STRUCT(2 as number, 'two' as spelling) ) SELECT * FROM table1
SELECT* FROM table SAMPLE(10)		SELECT* FROM table TABLESAMPLE BERNOULLI (0.1 PERCENT)
SELECT * FROM table1 AT(TIMESTAMP => timestamp) SELECT * FROM table1 BEFORE(STATEMENT => statementID)		SELECT * FROM table FOR SYSTEM_TIME AS OF timestamp Remarque: BigQuery ne dispose pas d'une alternative directe à BEFORE de Snowflake avec utilisation d'un ID d'instruction. La valeur du code temporel ne peut pas être antérieure de plus de sept jours au code temporel actuel.
@[namespace]<stage_name>[/path]		BigQuery n'est pas compatible avec le concept de fichier intermédiaires.
SELECT* FROM table START WITH predicate CONNECT BY [PRIOR] col1 = [PRIOR] col2 [, ...] ...		BigQuery ne propose pas d'alternative directe à CONNECT BY de Snowflake.

Les tables BigQuery peuvent être référencées dans la clause FROM à l'aide des commandes suivantes:

• [project_id].[dataset_id].[table_name]
• [dataset_id].[table_name]
• [table_name]

BigQuery accepte également d'autres références de table :

• Versions historiques de la définition de table et des lignes, en utilisant FOR SYSTEM_TIME AS OF
• Chemins d'accès de champ, ou tout chemin menant à un champ dans un type de données (c'est-à-dire un objet STRUCT)
• Tableaux aplatis.

Clause WHERE

Les clauses WHERE de Snowflake et WHERE de BigQuery sont identiques, à l'exception des éléments suivants :

Snowflake		BigQuery
SELECT col1, col2 FROM table1, table2 WHERE col1 = col2(+)		SELECT col1, col2 FROM table1 INNER JOIN table2 ON col1 = col2 Remarque: BigQuery n'est pas compatible avec la syntaxe (+) pour les JOIN.

Types JOIN

Snowflake et BigQuery sont tous deux compatibles avec les types de jointure suivants:

• [INNER] JOIN
• LEFT [OUTER] JOIN
• RIGHT [OUTER] JOIN
• FULL [OUTER] JOIN
• CROSS JOIN et la jointure croisée avec virgules implicite équivalente

Snowflake et BigQuery sont tous deux compatibles avec la clause ON et USING.

Le tableau suivant contient une liste de différences mineures.

Snowflake		BigQuery
SELECT col1 FROM table1 NATURAL JOIN table2		SELECT col1 FROM table1 INNER JOIN table2 USING (col1, col2 [, ...]) Remarque : dans BigQuery, les clauses JOIN nécessitent une condition JOIN, sauf s'il s'agit d'une jointure CROSS JOIN ou si l'une des tables jointes est un champ dans un type de données ou un tableau.
SELECT ... FROM table1 AS t1, LATERAL ( SELECT* FROM table2 AS t2 WHERE t1.col = t2.col ) Remarque: Contrairement à la sortie d'une jointure non latérale, le résultat d'une jointure latérale n'inclut que les lignes générées à partir de la vue intégrée. Les lignes du côté gauche ne doivent pas nécessairement être jointes au côté droit, car les lignes du côté gauche ont déjà été prises en compte en étant transmises dans la vue intégrée.		SELECT ... FROM table1 as t1 LEFT JOIN table2 as t2 ON t1.col = t2.col Remarque: BigQuery n'est pas compatible avec une alternative directe à LATERAL JOIN.

Clause WITH

Une clause WITH BigQuery contient une ou plusieurs sous-requêtes nommées qui s'exécutent chaque fois qu'une instruction SELECT ultérieure leur fait référence. Les clauses WITH Snowflake se comportent de la même manière que BigQuery, à l'exception que BigQuery n'est pas compatible avec WITH RECURSIVE.

Clause GROUP BY

Les clauses GROUP BY Snowflake sont compatibles avec GROUP BY, GROUP BY ROLLUP, GROUP BY GROUPING SETS et GROUP BY CUBE, tandis que les clauses GROUP BY BigQuery sont compatibles avec GROUP BY, GROUP BY ALL, GROUP BY ROLLUP, GROUP BY GROUPING SETS et GROUP BY CUBE.

Snowflake HAVING et BigQuery HAVING sont synonymes. Notez que HAVING se produit après GROUP BY et l'agrégation, et avant ORDER BY.

Snowflake		BigQuery
SELECT col1 as one, col2 as two FROM table GROUP BY (one, 2)		SELECT col1 as one, col2 as two FROM table GROUP BY (one, 2)
SELECT col1 as one, col2 as two FROM table GROUP BY ROLLUP (one, 2)		SELECT col1 as one, col2 as two FROM table GROUP BY ROLLUP (one, 2)
SELECT col1 as one, col2 as two FROM table GROUP BY GROUPING SETS (one, 2) Remarque: Snowflake autorise jusqu'à 128 ensembles de regroupement dans le même bloc de requête		SELECT col1 as one, col2 as two FROM table GROUP BY GROUPING SETS (one, 2)
SELECT col1 as one, col2 as two FROM table GROUP BY CUBE (one,2) Remarque: Snowflake autorise jusqu'à sept éléments (128 ensembles de regroupement) dans chaque cube		SELECT col1 as one, col2 as two FROM table GROUP BY CUBE (one, 2)

Clause ORDER BY

Il existe des différences mineures entre les clauses ORDER BY de Snowflake et les clauses ORDER BY de BigQuery.

Snowflake		BigQuery
Dans Snowflake, les valeurs NULL sont classées en dernier par défaut (ordre croissant).		Dans BigQuery, les valeurs NULLS sont classées par défaut en premier (par ordre croissant).
Vous pouvez spécifier si les valeurs NULL doivent être triées en premier ou en dernier à l'aide de NULLS FIRST ou de NULLS LAST, respectivement.		Il n'y a pas d'équivalent pour spécifier si les valeurs NULL doivent être affichées en premier ou en dernier dans BigQuery.

Clause LIMIT/FETCH

La clause LIMIT/FETCH de Snowflake limite le nombre maximal de lignes renvoyées par une instruction ou une sous-requête. LIMIT (Postgres syntax) et FETCH (syntaxe ANSI) produisent le même résultat.

Dans Snowflake et BigQuery, l'application d'une clause LIMIT à une requête n'a aucune incidence sur la quantité de données lues.

Snowflake		BigQuery
SELECT col1, col2 FROM table ORDER BY col1 LIMIT count OFFSET start SELECT ... FROM ... ORDER BY ... OFFSET start {[ROW | ROWS]} FETCH {[FIRST | NEXT]} count {[ROW | ROWS]} [ONLY] Remarque: Les valeurs NULL, de chaîne vide ('') et $$$$ sont acceptées et traitées comme "illimitées". Elles sont principalement utilisées pour les connecteurs et les pilotes.		SELECT col1, col2 FROM table ORDER BY col1 LIMIT count OFFSET start REMARQUE : BigQuery n'est pas compatible avec FETCH. Remplacement de FETCH par LIMIT. Remarque : Dans BigQuery, OFFSET doit être utilisé avec un LIMIT count. Pour des performances optimales, veillez à définir la valeur INT64 count sur le nombre minimal de lignes ordonnées nécessaires. Le classement de toutes les lignes de résultats entraîne inutilement de mauvaises performances lors de l'exécution de la requête.

Clause QUALIFY

La clause QUALIFY de Snowflake vous permet de filtrer les résultats des fonctions de fenêtrage similairement à ce que HAVING fait avec les fonctions d'agrégation et les clauses GROUP BY.

Snowflake		BigQuery
SELECT col1, col2 FROM table QUALIFY ROW_NUMBER() OVER (PARTITION BY col1 ORDER BY col2) = 1;		La clause QUALIFY de Snowflake avec une fonction d'analyse telle que ROW_NUMBER(), COUNT(), et avec OVER PARTITION BY est exprimée dans BigQuery en tant que clause WHERE sur une sous-requête contenant la valeur d'analyse. Avec ROW_NUMBER() : SELECT col1, col2 FROM ( SELECT col1, col2 ROW NUMBER() OVER (PARTITION BY col1 ORDER by col2) RN FROM table ) WHERE RN = 1; Avec ARRAY_AGG(), compatible avec les partitions plus volumineuses: SELECT result.* FROM ( SELECT ARRAY_AGG(table ORDER BY table.col2 DESC LIMIT 1) [OFFSET(0)] FROM table GROUP BY col1 ) AS result;

Fonctions

Les sections suivantes répertorient les fonctions Snowflake et leurs équivalents dans BigQuery.

Fonctions d'agrégation

Le tableau suivant présente les mappages des fonctions courantes d'agrégation, d'analyse agrégée et d'agrégation approximative Snowflake avec leurs équivalents dans BigQuery.

Snowflake	BigQuery
ANY_VALUE([DISTINCT] expression) [OVER ...] Remarque: DISTINCT n'a aucun effet	ANY_VALUE(expression) [OVER ...]
APPROX_COUNT_DISTINCT([DISTINCT] expression) [OVER ...] Remarque: DISTINCT n'a aucun effet	APPROX_COUNT_DISTINCT(expression) Remarque: BigQuery ne permet pas la compatibilité de la fonction APPROX_COUNT_DISTINCT avec les fonctions de fenêtrage.
APPROX_PERCENTILE(expression, percentile) [OVER ...] Remarque: Snowflake n'a pas l'option RESPECT NULLS	APPROX_QUANTILES([DISTINCT] expression,100) [OFFSET((CAST(TRUNC(percentile * 100) as INT64))] Remarque: BigQuery ne permet pas la compatibilité de la fonction APPROX_QUANTILES avec les fonctions de fenêtrage.
APPROX_PERCENTILE_ACCUMULATE (expression)	BigQuery ne permet pas de stocker l'état intermédiaire lors de la prédiction de valeurs approximatives.
APPROX_PERCENTILE_COMBINE(state)	BigQuery ne permet pas de stocker l'état intermédiaire lors de la prédiction de valeurs approximatives.
APPROX_PERCENTILE_ESTIMATE(state, percentile)	BigQuery ne permet pas de stocker l'état intermédiaire lors de la prédiction de valeurs approximatives.
APPROX_TOP_K(expression, [number [counters]] Remarque: Si aucun paramètre de nombre n'est spécifié, la valeur par défaut est 1. Les compteurs doivent être beaucoup plus volumineux que le nombre.	APPROX_TOP_COUNT(expression, number) Remarque: BigQuery ne permet pas la compatibilité de la fonction APPROX_TOP_COUNT avec les fonctions de fenêtrage.
APPROX_TOP_K_ACCUMULATE(expression, counters)	BigQuery ne permet pas de stocker l'état intermédiaire lors de la prédiction de valeurs approximatives.
APPROX_TOP_K_COMBINE(state, [counters])	BigQuery ne permet pas de stocker l'état intermédiaire lors de la prédiction de valeurs approximatives.
APPROX_TOP_K_ESTIMATE(state, [k])	BigQuery ne permet pas de stocker l'état intermédiaire lors de la prédiction de valeurs approximatives.
APPROXIMATE_JACCARD_INDEX([DISTINCT] expression)	Vous pouvez utiliser une fonction définie par l'utilisateur personnalisée pour mettre en œuvre MINHASH avec des fonctions de hachage distinctes de k. Une autre approche permettant de réduire la variance dans MINHASH consiste à conserver k des valeurs minimales d'une fonction de hachage. Dans ce cas, l'index Jaccard peut être évalué comme suit: WITH minhash_A AS ( SELECT DISTINCT FARM_FINGERPRINT(TO_JSON_STRING(t)) AS h FROM TA AS t ORDER BY h LIMIT k), minhash_B AS ( SELECT DISTINCT FARM_FINGERPRINT(TO_JSON_STRING(t)) AS h FROM TB AS t ORDER BY h LIMIT k) SELECT COUNT(*) / k AS APPROXIMATE_JACCARD_INDEX FROM minhash_A INNER JOIN minhash_B ON minhash_A.h = minhash_B.h
APPROXIMATE_SIMILARITY([DISTINCT] expression)	Il s'agit d'un synonyme de APPROXIMATE_JACCARD_INDEX et peut être mis en œuvre de la même manière.
ARRAY_AGG([DISTINCT] expression1) [WITHIN GROUP (ORDER BY ...)] [OVER ([PARTITION BY expression2])] Note: Snowflake does not support ability to IGNORE|RESPECT NULLS and to LIMIT directly in ARRAY_AGG.	ARRAY_AGG([DISTINCT] expression1 [{IGNORE|RESPECT}] NULLS] [ORDER BY ...] LIMIT ...]) [OVER (...)]
AVG([DISTINCT] expression) [OVER ...]	AVG([DISTINCT] expression) [OVER ...] Remarque: La fonction AVG de BigQuery n'effectue pas de conversion automatique sur les STRING.
BITAND_AGG(expression) [OVER ...]	BIT_AND(expression) [OVER ...] Remarque: BigQuery ne convertit pas implicitement les colonnes de caractères/texte vers l'INTEGER le plus proche.
BITOR_AGG(expression) [OVER ...]	BIT_OR(expression) [OVER ...] Remarque: BigQuery ne convertit pas implicitement les colonnes de caractères/texte vers l'INTEGER le plus proche.
BITXOR_AGG([DISTINCT] expression) [OVER ...]	BIT_XOR([DISTINCT] expression) [OVER ...] Remarque: BigQuery ne convertit pas implicitement les colonnes de caractères/texte vers l'INTEGER le plus proche.
BOOLAND_AGG(expression) [OVER ...] Remarque: Snowflake permet aux valeurs numériques, décimales et à virgule flottante d'être traitées comme TRUE si ce n'est pas zéro.	LOGICAL_AND(expression) [OVER ...]
BOOLOR_AGG(expression) [OVER ...] Remarque: Snowflake permet aux valeurs numériques, décimales et à virgule flottante d'être traitées comme TRUE si ce n'est pas zéro.	LOGICAL_OR(expression) [OVER ...]
BOOLXOR_AGG(expression) [OVER ([PARTITION BY <partition_expr> ]) Remarque: Snowflake permet aux valeurs numériques, décimales et à virgule flottante d'être traitées comme TRUE si ce n'est pas zéro.	Pour l'expression numérique: SELECT CASE COUNT(*) WHEN 1 THEN TRUE WHEN 0 THEN NULL ELSE FALSE END AS BOOLXOR_AGG FROM T WHERE expression != 0 Pour utiliser OVER, vous pouvez exécuter l'exemple booléen suivant : SELECT CASE COUNT(expression) OVER (PARTITION BY partition_expr) WHEN 0 THEN NULL ELSE CASE COUNT( CASE expression WHEN TRUE THEN 1 END) OVER (PARTITION BY partition_expr) WHEN 1 THEN TRUE ELSE FALSE END END AS BOOLXOR_AGG FROM T
CORR(dependent, independent) [OVER ...]	CORR(dependent, independent) [OVER ...]
COUNT([DISTINCT] expression [,expression2]) [OVER ...]	COUNT([DISTINCT] expression [,expression2]) [OVER ...]
COVAR_POP(dependent, independent) [OVER ...]	COVAR_POP(dependent, independent) [OVER ...]
COVAR_SAMP(dependent, independent) [OVER ...]	COVAR_SAMP(dependent, independent) [OVER ...]
GROUPING(expression1, [,expression2...])	BigQuery ne dispose pas d'une alternative directe compatible avec GROUPING de Snowflake. Disponible via une fonction définie par l'utilisateur.
GROUPING_ID(expression1, [,expression2...])	BigQuery n'est pas compatible avec une alternative directe à GROUPING_ID de Snowflake. Disponible via une fonction définie par l'utilisateur.
HASH_AGG([DISTINCT] expression1, [,expression2]) [OVER ...]	SELECT BIT_XOR( FARM_FINGERPRINT( TO_JSON_STRING(t))) [OVER] FROM t
SELECT HLL([DISTINCT] expression1, [,expression2]) [OVER ...] Remarque: Snowflake ne vous permet pas de spécifier la précision.	SELECT HLL_COUNT.EXTRACT(sketch) FROM ( SELECT HLL_COUNT.INIT(expression) AS sketch FROM table ) Remarque: BigQuery ne permet pas la compatibilité de la fonction HLL_COUNT… avec les fonctions de fenêtrage. Un utilisateur ne peut pas inclure plusieurs expressions dans une même fonction HLL_COUNT....
HLL_ACCUMULATE([DISTINCT] expression) Remarque: Snowflake ne vous permet pas de spécifier la précision.	HLL_COUNT.INIT(expression [, précision])
HLL_COMBINE([DISTINCT] state)	HLL_COUNT.MERGE_PARTIAL(résumé)
HLL_ESTIMATE(state)	HLL_COUNT.EXTRACT(sketch)
HLL_EXPORT(binary)	BigQuery n'est pas compatible avec une alternative directe à HLL_EXPORT de Snowflake.
HLL_IMPORT(object)	BigQuery n'est pas compatible avec une alternative directe à HLL_IMPORT de Snowflake.
KURTOSIS(expression) [OVER ...]	BigQuery n'est pas compatible avec une alternative directe à KURTOSIS de Snowflake.
LISTAGG( [DISTINCT] aggregate_expression [, delimiter] ) [OVER ...]	STRING_AGG( [DISTINCT] aggregate_expression [, delimiter] ) [OVER ...]
MEDIAN(expression) [OVER ...] Remarque: Snowflake n'est pas en mesure de IGNORE|RESPECT NULLS et LIMIT directement dans ARRAY_AGG..	PERCENTILE_CONT( value_expression, 0.5 [ {RESPECT | IGNORE} NULLS] ) OVER()
MAX(expression) [OVER ...] MIN(expression) [OVER ...]	MAX(expression) [OVER ...] MIN(expression) [OVER ...]
MINHASH(k, [DISTINCT] expressions)	Vous pouvez utiliser une fonction définie par l'utilisateur personnalisée pour implémenter MINHASH avec des fonctions de hachage distinctes de k. Une autre approche permettant de réduire la variance dans MINHASH consiste à conserver k des valeurs minimales d'une fonction de hachage : SELECT DISTINCT FARM_FINGERPRINT( TO_JSON_STRING(t)) AS MINHASH FROM t ORDER BY MINHASH LIMIT k
MINHASH_COMBINE([DISTINCT] state)	<code<select FROM ( SELECT DISTINCT FARM_FINGERPRINT( TO_JSON_STRING(t)) AS h FROM TA AS t ORDER BY h LIMIT k UNION SELECT DISTINCT FARM_FINGERPRINT( TO_JSON_STRING(t)) AS h FROM TB AS t ORDER BY h LIMIT k ) ORDER BY h LIMIT k
MODE(expr1) OVER ( [ PARTITION BY <expr2> ] )	SELECT expr1 FROM ( SELECT expr1, ROW_NUMBER() OVER ( PARTITION BY expr2 ORDER BY cnt DESC) rn FROM ( SELECT expr1, expr2, COUNTIF(expr1 IS NOT NULL) OVER (PARTITION BY expr2, expr1) cnt FROM t)) WHERE rn = 1
OBJECT_AGG(key, value) [OVER ...]	Vous pouvez envisager d'utiliser TO_JSON_STRING pour convertir une valeur en chaîne au format JSON.
PERCENTILE_CONT(percentile) WITHIN GROUP (ORDER BY value_expression) [OVER ...]	PERCENTILE_CONT( value_expression, percentile [ {RESPECT | IGNORE} NULLS] ) OVER()
PERCENTILE_DISC(percentile) WITHIN GROUP (ORDER BY value_expression) [OVER ...]	PERCENTILE_DISC( value_expression, percentile [ {RESPECT | IGNORE} NULLS] ) OVER()
REGR_AVGX(dependent, independent) [OVER ...]	SELECT AVG(independent) [OVER ...] FROM table WHERE ( (dependent IS NOT NULL) AND (independent IS NOT NULL) )
REGR_AVGY(dependent, independent) [OVER ...]	SELECT AVG(dependent) [OVER ...] FROM table WHERE ( (dependent IS NOT NULL) AND (independent IS NOT NULL) )
REGR_COUNT(dependent, independent) [OVER ...]	SELECT COUNT(*) [OVER ...] FROM table WHERE ( (dependent IS NOT NULL) AND (independent IS NOT NULL) )
REGR_INTERCEPT(dependent, independent) [OVER ...]	SELECT AVG(dependent) - COVAR_POP(dependent,independent)/ VAR_POP(dependent) * AVG(independent) [OVER ...] FROM table WHERE ( (dependent IS NOT NULL) AND (independent IS NOT NULL) ) [GROUP BY ...]
REGR_R2(dependent, independent) [OVER ...]	SELECT CASE WHEN VAR_POP(independent) = 0 THEN NULL WHEN VAR_POP(dependent) = 0 AND VAR_POP(independent) != 0 THEN 1 ELSE POWER(CORR(dependent, independent), 2) END AS ... FROM table WHERE ( (dependent IS NOT NULL) AND (independent IS NOT NULL) ) [GROUP BY ...]
REGR_SLOPE(dependent, independent) [OVER ...]	SELECT COVAR_POP(dependent,independent)/ VAR_POP(dependent) [OVER ...] FROM table WHERE ( (dependent IS NOT NULL) AND (independent IS NOT NULL) ) [GROUP BY ...]
REGR_SXX(dependent, independent) [OVER ...]	SELECT COUNT(*)*VAR_POP(independent) [OVER ...] FROM table WHERE ( (dependent IS NOT NULL) AND (independent IS NOT NULL) ) [GROUP BY ...]
REGR_SYY(dependent, independent) [OVER ...]	SELECT COUNT(*)*VAR_POP(dependent) [OVER ...] FROM table WHERE ( (dependent IS NOT NULL) AND (independent IS NOT NULL) ) [GROUP BY ...]
SKEW(expression)	BigQuery n'est pas compatible avec une alternative directe à SKEW de Snowflake.
STDDEV([DISTINCT] expression) [OVER ...]	STDDEV([DISTINCT] expression) [OVER ...]
STDDEV_POP([DISTINCT] expression) [OVER ...]	STDDEV_POP([DISTINCT] expression) [OVER ...]
STDDEV_SAMP([DISTINCT] expression) [OVER ...]	STDDEV_SAMP([DISTINCT] expression) [OVER ...]
SUM([DISTINCT] expression) [OVER ...]	SUM([DISTINCT] expression) [OVER ...]
VAR_POP([DISTINCT] expression) [OVER ...] Remarque: Snowflake permet de convertir des valeurs VARCHAR en valeurs à virgule flottante.	VAR_POP([DISTINCT] expression) [OVER ...]
VARIANCE_POP([DISTINCT] expression) [OVER ...] Remarque: Snowflake permet de convertir des valeurs VARCHAR en valeurs à virgule flottante.	VAR_POP([DISTINCT] expression) [OVER ...]
VAR_SAMP([DISTINCT] expression) [OVER ...] Remarque: Snowflake permet de convertir des valeurs VARCHAR en valeurs à virgule flottante.	VAR_SAMP([DISTINCT] expression) [OVER ...]
VARIANCE([DISTINCT] expression) [OVER ...] Remarque: Snowflake permet de convertir des valeurs VARCHAR en valeurs à virgule flottante.	VARIANCE([DISTINCT] expression) [OVER ...]

BigQuery propose également les fonctions d'agrégation, d'analyse analytique et d'agrégation approximative comme indiqué ci-dessous, qui n'ont pas d'équivalent direct dans Snowflake :

• COUNTIF
• ARRAY_CONCAT_AGG
• HLL_COUNT.MERGE

Fonctions d'expression bit à bit

Le tableau suivant présente les mappages des fonctions d'expression bit à bit Snowflake courantes avec leurs équivalents dans BigQuery.

Si le type de données d'une expression n'est pas INTEGER, Snowflake tente de le convertir en INTEGER. Cependant, BigQuery ne tente pas de le convertir en INTEGER.

Snowflake	BigQuery
BITAND(expression1, expression2)	BIT_AND(x) FROM UNNEST([expression1, expression2]) AS x expression1 & expression2
BITNOT(expression)	~ expression
BITOR(expression1, expression2)	BIT_OR(x) FROM UNNEST([expression1, expression2]) AS x expression1 | expression2
BITSHIFTLEFT (expression, n)	expression << n
BITSHIFTRIGHT (expression, n)	expression >> n
BITXOR(expression, expression) Remarque: Snowflake n'est pas compatible avec DISTINCT..	BIT_XOR([DISTINCT] x) FROM UNNEST([expression1, expression2]) AS x expression ^ expression

Fonctions d'expression conditionnelle

Le tableau suivant présente les mappages des expressions conditionnelles Snowflake courantes avec leurs équivalents dans BigQuery.

Snowflake	BigQuery
expression [ NOT ] BETWEEN lower AND upper	(expression >= lower AND expression <= upper)
BOOLAND(expression1, expression2) Remarque: Snowflake permet aux valeurs numériques, décimales et à virgule flottante d'être traitées comme TRUE si ce n'est pas zéro.	LOGICAL_AND(x) FROM UNNEST([expression1, expression2]) AS x expression1 AND expression2
BOOLNOT(expression1) Remarque: Snowflake permet aux valeurs numériques, décimales et à virgule flottante d'être traitées comme TRUE si ce n'est pas zéro.	NOT expression
BOOLOR Remarque: Snowflake permet aux valeurs numériques, décimales et à virgule flottante d'être traitées comme des valeurs TRUE si elles ne sont pas nulles.	LOGICAL_OR(x) FROM UNNEST([expression1, expression2]) AS x expression1 OR expression2
BOOLXOR Remarque: Snowflake permet aux valeurs numériques, décimales et à virgule flottante d'être traitées comme des valeurs TRUE si elles ne sont pas nulles.	BigQuery n'est pas compatible avec une alternative directe au BOOLXOR. de Snowflake
CASE [expression] WHEN condition1 THEN result1 [WHEN condition2 THEN result2] [...] [ELSE result3] END	CASE [expression] WHEN condition1 THEN result1 [WHEN condition2 THEN result2] [...] [ELSE result3] END
COALESCE(expr1, expr2, [,...]) Remarque: Snowflake nécessite au moins deux expressions. BigQuery n'en nécessite qu'une.	COALESCE(expr1, [,...])
DECODE(expression, search1, result1, [search2, result2...] [,default])	CASE [expression] WHEN condition1 THEN result1 [WHEN condition2 THEN result2] [...] [ELSE result3] END Remarque: BigQuery accepte les sous-requêtes dans les instructions de condition. Cela peut être utilisé pour reproduire DECODE de Snowflake. L'utilisateur doit utiliser IS NULL au lieu de = NULL pour faire correspondre les expressions de sélection NULL avec les expressions de recherche NULL.
EQUAL_NULL(expression1, expression2)	BigQuery n'est pas compatible avec une alternative directe au EQUAL_NULL. de Snowflake
GREATEST(expression1, [,expression2]...)	GREATEST(expression1, [,expression2]...)
IFF(condition, true_result, false_result)	IF(condition, true_result, false_result)
IFNULL(expression1, expression2)	IFNULL(expression1, expression2)
[ NOT ] IN ...	[ NOT ] IN ...
expression1 IS [ NOT ] DISTINCT FROM expression2	BigQuery n'est pas compatible avec une alternative directe au IS [ NOT ] DISTINCT FROM. de Snowflake
expression IS [ NOT ] NULL	expression IS [ NOT ] NULL
IS_NULL_VALUE(variant_expr)	BigQuery n'accepte pas les types de données VARIANT.
LEAST(expression,...)	LEAST(expression,...)
NULLIF(expression1,expression2)	NULLIF(expression1,expression2)
NVL(expression1, expression2)	IFNULL(expression1,expression2)
NVL2(expr1,expr2,expr2)	IF(expr1 IS NOT NULL, expr2,expr3)
REGR_VALX(expr1,expr2)	IF(expr1 IS NULL, NULL, expr2) Remarque: BigQuery n'est pas compatible avec une alternative directe aux fonctions REGR... de Snowflake.
REGR_VALY(expr1,expr2)	IF(expr2 IS NULL, NULL, expr1) Remarque: BigQuery n'est pas compatible avec une alternative directe aux fonctions REGR... de Snowflake.
ZEROIFNULL(expression)	IFNULL(expression,0)

Fonctions de contexte

Le tableau suivant présente les mappages des fonctions de contexte Snowflake courantes avec leurs équivalents dans BigQuery.

Snowflake	BigQuery
CURRENT_ACCOUNT()	SESSION_USER() Remarque: Pas de comparaison directe. Snowflake renvoie l'ID de compte, BigQuery renvoie l'adresse e-mail de l'utilisateur.
CURRENT_CLIENT()	Concept non utilisé dans BigQuery
CURRENT_DATABASE()	SELECT catalog_name FROM INFORMATION_SCHEMA.SCHEMATA Cette commande renvoie une table des noms de projets. Il ne s'agit pas d'une comparaison directe.
CURRENT_DATE[()] Remarque: Snowflake n'applique pas "()" après la commande CURRENT_DATE pour se conformer aux normes ANSI.	CURRENT_DATE([timezone]) Remarque: La fonction CURRENT_DATE de BigQuery accepte la spécification facultative du fuseau horaire.
CURRENT_REGION()	SELECT location FROM INFORMATION_SCHEMA.SCHEMATA Remarque: la fonction INFORMATION_SCHEMA.SCHEMATA de BigQuery renvoie des références d'emplacements plus généralisées que la fonction CURRENT_REGION() de Snowflake. Il ne s'agit pas d'une comparaison directe.
CURRENT_ROLE()	Concept non utilisé dans BigQuery
CURRENT_SCHEMA()	SELECT schema_name FROM INFORMATION_SCHEMA.SCHEMATA Cette commande renvoie une table de tous les ensembles de données (également appelés schémas) disponibles dans le projet ou la région. Il ne s'agit pas d'une comparaison directe.
CURRENT_SCHEMAS()	Concept non utilisé dans BigQuery
CURRENT_SESSION()	Concept non utilisé dans BigQuery
CURRENT_STATEMENT()	SELECT query FROM INFORMATION_SCHEMA.JOBS_BY_* Remarque: la fonction INFORMATION_SCHEMA.JOBS_BY_* de BigQuery permet de rechercher des requêtes par type de tâche, de début de fin, etc.
CURRENT_TIME[([frac_sec_prec])] Remarque: Snowflake autorise la précision facultative par fraction de seconde. Les valeurs valides sont comprises entre 0 et 9 nanosecondes. La valeur par défaut est 9. Pour respecter l'ANSI, il est possible d'appeler cette méthode sans "()".	CURRENT_TIME()
CURRENT_TIMESTAMP[([frac_sec_prec])] Remarque: Snowflake autorise la précision facultative par fraction de seconde. Les valeurs valides sont comprises entre 0 et 9 nanosecondes. La valeur par défaut est 9. Pour respecter l'ANSI, il est possible d'appeler cette méthode sans "()". Définissez TIMEZONE en tant que paramètre de session.	CURRENT_DATETIME([timezone]) CURRENT_TIMESTAMP() Remarque : CURRENT_DATETIME renvoie le type de données DATETIME (non compatible avec Snowflake). CURRENT_TIMESTAMP renvoie le type de données TIMESTAMP.
CURRENT_TRANSACTION()	SELECT job_id FROM INFORMATION_SCHEMA.JOBS_BY_* Remarque: La fonction INFORMATION_SCHEMA.JOBS_BY_* de BigQuery permet de rechercher des ID de tâche par type de tâche, type de début/fin, etc.
CURRENT_USER[()] Remarque: Snowflake n'applique pas "()" après la commande CURRENT_USER pour se conformer aux normes ANSI.	SESSION_USER() SELECT user_email FROM INFORMATION_SCHEMA.JOBS_BY_* Remarque: pas d'une comparaison directe. Snowflake renvoie le nom d'utilisateur. BigQuery renvoie l'adresse e-mail de l'utilisateur.
CURRENT_VERSION()	Concept non utilisé dans BigQuery
CURRENT_WAREHOUSE()	SELECT catalg_name FROM INFORMATION_SCHEMA.SCHEMATA
LAST_QUERY_ID([num])	SELECT job_id FROM INFORMATION_SCHEMA.JOBS_BY_* Remarque: La fonction INFORMATION_SCHEMA.JOBS_BY_* de BigQuery permet de rechercher des ID de tâche par type de tâche, type de début/fin, etc.
LAST_TRANSACTION()	SELECT job_id FROM INFORMATION_SCHEMA.JOBS_BY_* Remarque: La fonction INFORMATION_SCHEMA.JOBS_BY_* de BigQuery permet de rechercher des ID de tâche par type de tâche, type de début/fin, etc.
LOCALTIME() Remarque: Snowflake n'applique pas "()" après la commande LOCALTIME pour se conformer aux normes ANSI.	CURRENT_TIME()
LOCALTIMESTAMP()	CURRENT_DATETIME([timezone]) CURRENT_TIMESTAMP() Remarque : CURRENT_DATETIME renvoie le type de données DATETIME (non compatible avec Snowflake). CURRENT_TIMESTAMP renvoie le type de données TIMESTAMP.

Fonctions de conversion

Le tableau suivant présente les mappages des fonctions de conversion courantes de Snowflake avec leurs équivalents dans BigQuery.

Gardez à l'esprit que les fonctions qui semblent identiques dans Snowflake et BigQuery peuvent renvoyer des types de données différents.

Snowflake	BigQuery
CAST(expression AS type) expression :: type	CAST(expression AS type)
TO_ARRAY(expression)	[expression] ARRAY(subquery)
TO_BINARY(expression[, format]) Remarque: Snowflake accepte les conversions HEX, BASE64 et UTF-8. Snowflake accepte également TO_BINARY à l'aide du type de données VARIANT. BigQuery ne dispose pas d'une alternative au type de données VARIANT.	TO_HEX(CAST(expression AS BYTES)) TO_BASE64(CAST(expression AS BYTES)) CAST(expression AS BYTES) Remarque: Le casting STRING par défaut de BigQuery utilise l'encodage UTF-8. Snowflake ne dispose pas d'une option permettant l'encodage BASE32.
TO_BOOLEAN(expression) Remarque : INT64 TRUE: sinon, FALSE: 0 STRING TRUE: "true"/"t"/"yes"/"y"/"on"/"1", FALSE: "false"/"f"/"no"/"n"/"off"/"0"	CAST(expression AS BOOL) Remarque : INT64 TRUE: sinon, FALSE: 0 STRING TRUE: "true", FALSE: "false"
TO_CHAR(expression[, format]) TO_VARCHAR(expression[, format]) Remarque: Les modèles de format de Snowflake sont disponibles ici. BigQuery ne dispose pas d'une alternative au type de données VARIANT.	CAST(expression AS STRING) Remarque: L'expression d'entrée de BigQuery peut être mise en forme à l'aide de FORMAT_DATE, FORMAT_DATETIME, FORMAT_TIME ou FORMAT_TIMESTAMP.
TO_DATE(expression[, format]) DATE(expression[, format]) Remarque: Snowflake accepte la conversion directe des types INTEGER en types DATE. Les modèles de format Snowflake sont disponibles ici. BigQuery ne dispose pas d'une alternative au type de données VARIANT.	CAST(expression AS DATE) Remarque: L'expression d'entrée de BigQuery peut être mise en forme à l'aide de FORMAT, FORMAT_DATETIME ou FORMAT_TIMESTAMP.
TO_DECIMAL(expression[, format] [,precision[, scale]] TO_NUMBER(expression[, format] [,precision[, scale]] TO_NUMERIC(expression[, format] [,precision[, scale]] Remarque: Les modèles de format Snowflake pour les types de données DECIMAL, NUMBER et NUMERIC sont disponibles ici. BigQuery ne dispose pas d'une alternative au type de données VARIANT.	ROUND(CAST(expression AS NUMERIC) , x) Remarque: L'expression d'entrée de BigQuery peut être mise en forme à l'aide de FORMAT..
TO_DOUBLE(expression[, format]) Remarque: Les modèles de format Snowflake pour les types de données DOUBLE sont disponibles ici. BigQuery ne dispose pas d'une alternative au type de données VARIANT.	CAST(expression AS FLOAT64) Remarque: L'expression d'entrée de BigQuery peut être mise en forme à l'aide de FORMAT..
TO_JSON(variant_expression)	BigQuery ne dispose pas d'une alternative au type de données VARIANT de Snowflake.
TO_OBJECT(variant_expression)	BigQuery ne dispose pas d'une alternative au type de données VARIANT de Snowflake.
TO_TIME(expression[, format]) TIME(expression[, format]) Remarque: Les modèles de format Snowflake pour les types de données STRING sont disponibles ici. BigQuery ne dispose pas d'une alternative au type de données VARIANT.	CAST(expression AS TIME) Remarque: BigQuery ne dispose pas d'une alternative au type de données VARIANT de Snowflake. L'expression d'entrée de BigQuery peut être mise en forme à l'aide de FORMAT, FORMAT_DATETIME, FORMAT_TIMESTAMP ou FORMAT_TIME.
TO_TIMESTAMP(expression[, scale]) TO_TIMESTAMP_LTZ(expression[, scale]) TO_TIMESTAMP_NTZ(expression[, scale]) TO_TIMESTAMP_TZ(expression[, scale]) Remarque: BigQuery ne dispose pas d'une alternative au type de données VARIANT.	CAST(expression AS TIMESTAMP) Remarque: L'expression d'entrée de BigQuery peut être mise en forme à l'aide de FORMAT, FORMAT_DATE, FORMAT_DATETIME et FORMAT_TIME. Le fuseau horaire peut être inclus/non inclus via les paramètres FORMAT_TIMESTAMP.
TO_VARIANT(expression)	BigQuery ne dispose pas d'une alternative au type de données VARIANT de Snowflake.
TO_XML(variant_expression)	BigQuery ne dispose pas d'une alternative au type de données VARIANT de Snowflake.
TRY_CAST(expression AS type)	SAFE_CAST(expression AS type)
TRY_TO_BINARY(expression[, format])	TO_HEX(SAFE_CAST(expression AS BYTES)) TO_BASE64(SAFE_CAST(expression AS BYTES)) SAFE_CAST(expression AS BYTES)
TRY_TO_BOOLEAN(expression)	SAFE_CAST(expression AS BOOL)
TRY_TO_DATE(expression)	SAFE_CAST(expression AS DATE)
TRY_TO_DECIMAL(expression[, format] [,precision[, scale]] TRY_TO_NUMBER(expression[, format] [,precision[, scale]] TRY_TO_NUMERIC(expression[, format] [,precision[, scale]]	ROUND( SAFE_CAST(expression AS NUMERIC) , x)
TRY_TO_DOUBLE(expression)	SAFE_CAST(expression AS FLOAT64)
TRY_TO_TIME(expression)	SAFE_CAST(expression AS TIME)
TRY_TO_TIMESTAMP(expression) TRY_TO_TIMESTAMP_LTZ(expression) TRY_TO_TIMESTAMP_NTZ(expression) TRY_TO_TIMESTAMP_TZ(expression)	SAFE_CAST(expression AS TIMESTAMP)

BigQuery propose également les fonctions de conversion suivantes, qui n'ont pas d'équivalent direct dans Snowflake:

• CODE_POINTS_TO_BYTES
• CODE_POINTS_TO_STRING
• FORMAT
• FROM_BASE32
• FROM_BASE64
• FROM_HEX
• SAFE_CONVERT_BYTES_TO_STRING
• TO_BASE32
• TO_CODE_POINTS

Fonctions de génération de données

Le tableau suivant présente les mappages des fonctions courantes de génération de données Snowflake avec leurs équivalents dans BigQuery.

Snowflake	BigQuery
NORMAL(mean, stddev, gen)	BigQuery n'est pas compatible avec une comparaison directe avec l'élément NORMAL. de Snowflake
RANDOM([seed])	IF(RAND()>0.5, CAST(RAND()*POW(10, 18) AS INT64), (-1)*CAST(RAND()*POW(10, 18) AS INT64)) Remarque: BigQuery n'est pas compatible avec l'amorçage.
RANDSTR(length, gen)	BigQuery n'est pas compatible avec une comparaison directe avec l'élément RANDSTR. de Snowflake
SEQ1 / SEQ2 / SEQ4 / SEQ8	BigQuery n'est pas compatible avec une comparaison directe avec l'élément SEQ_. de Snowflake
UNIFORM(min, max, gen)	CAST(min + RAND()*(max-min) AS INT64) Remarque: Utilisez des fonctions persistantes définies par l'utilisateur pour créer un équivalent à UNIFORM de Snowflake. Exemple ici.
UUID_STRING([uuid, name]) Remarque: Snowflake renvoie 128 bits aléatoires. Snowflake accepte les UUID de version 4 (aléatoire) et 5 (nommé).	GENERATE_UUID() Remarque: BigQuery renvoie 122 bits aléatoires. BigQuery n'est compatible qu'avec les UUID de la version 4.
ZIPF(s, N, gen)	BigQuery n'est pas compatible avec une comparaison directe avec l'élément ZIPF. de Snowflake

Fonctions de date et heure

Le tableau suivant présente les mappages des fonctions de date et heure courantes de Snowflake avec leurs équivalents dans BigQuery. Les fonctions de données et de date et heure de BigQuery incluent : les fonctions de date, les fonctions de date et heure, les fonctions temporelles, et les fonctions de code temporel.

Snowflake	BigQuery
ADD_MONTHS(date, months)	CAST( DATE_ADD( date, INTERVAL integer MONTH ) AS TIMESTAMP )
CONVERT_TIMEZONE(source_tz, target_tz, source_timestamp) CONVERT_TIMEZONE(target_tz, source_timestamp)	PARSE_TIMESTAMP( "%c%z", FORMAT_TIMESTAMP( "%c%z", timestamp, target_timezone ) ) Remarque: source_timezone est toujours UTC dans BigQuery.
DATE_FROM_PARTS(year, month, day) Remarque: Snowflake accepte les dépassements et les dates négatives. Par exemple, DATE_FROM_PARTS(2000, 1 + 24, 1) renvoie le 1er janvier 2002. Ceci n'est pas compatible avec BigQuery.	DATE(year, month, day) DATE(timestamp_expression[, timezone]) DATE(datetime_expression)
DATE_PART(part, dateOrTime) Remarque: Snowflake est compatible avec les parties de dates de type jour de la semaine ISO, nanoseconde et epoch (secondes/millisecondes/microsecondes/nanoseconde). BigQuery ne l'est pas. Pour obtenir la liste complète des types de parties de date Snowflake, cliquez ici ..	EXTRACT(part FROM dateOrTime) Remarque: BigQuery accepte les parties de date de type hebdomadaire (<jour de la semaine>), microsecondes et milliseconde. Pas Snowflake. Consultez la liste complète des types de parties de date de BigQuery ici et ici.
DATE_TRUNC(part, dateOrTime) Remarque: Snowflake accepte le type de partie de date à la nanoseconde près. BigQuery ne l'est pas. Pour obtenir la liste complète des types de parties de date Snowflake, cliquez ici ..	DATE_TRUNC(date, part) DATETIME_TRUNC(datetime, part) TIME_TRUNC(time, part) TIMESTAMP_TRUNC(timestamp, part[, timezone]) Remarque: BigQuery est compatible avec les parties de date de type semaine (<jour de la semaine>), semaine ISO et année ISO. Pas Snowflake.
DATEADD(part, value, dateOrTime)	DATE_ADD(date, INTERVAL value part)
DATEDIFF( part, expression1, expression2 ) Remarque: Snowflake accepte le calcul de la différence entre deux types de date, d'heure et d'horodatage dans cette fonction.	DATE_DIFF( dateExpression1, dateExpression2, part ) DATETIME_DIFF( datetimeExpression1, datetimeExpression2, part ) TIME_DIFF( timeExpression1, timeExpression2, part ) TIMESTAMP_DIFF( timestampExpression1, timestampExpression2, part ) Remarque: BigQuery est compatible avec les parties de date de type semaine (<jour de la semaine>) et année ISO.
DAYNAME(dateOrTimestamp)	FORMAT_DATE('%a', date) FORMAT_DATETIME('%a', datetime) FORMAT_TIMESTAMP('%a', timestamp)
EXTRACT(part FROM dateOrTime) Remarque: Snowflake est compatible avec les parties de dates de type jour de la semaine ISO, nanoseconde et epoch (secondes/millisecondes/microsecondes/nanoseconde). BigQuery ne l'est pas. Pour obtenir la liste complète des types de parties de date Snowflake, cliquez ici ..	EXTRACT(part FROM dateOrTime) Remarque: BigQuery accepte les parties de date de type hebdomadaire (<jour de la semaine>), microsecondes et milliseconde. Pas Snowflake. Consultez la liste complète des types de parties de date de BigQuery ici et ici.
[HOUR, MINUTE, SECOND](timeOrTimestamp)	EXTRACT(part FROM timestamp [AT THE ZONE timezone])
LAST_DAY(dateOrTime[, part])	DATE_SUB( DATE_TRUNC( DATE_ADD(date, INTERVAL 1 part), part), INTERVAL 1 DAY)
MONTHNAME(dateOrTimestamp)	FORMAT_DATE('%b', date) FORMAT_DATETIME('%b', datetime) FORMAT_TIMESTAMP('%b', timestamp)
NEXT_DAY(dateOrTime, dowString)	DATE_ADD( DATE_TRUNC( date, WEEK(dowString)), INTERVAL 1 WEEK) Remarque: dowString peut avoir besoin d'être reformaté. Par exemple, "su" de Snowflake sera "SUNDAY" de BigQuery.
PREVIOUS_DAY(dateOrTime, dowString)	DATE_TRUNC( date, WEEK(dowString) ) Remarque: dowString peut avoir besoin d'être reformaté. Par exemple, "su" de Snowflake sera "SUNDAY" de BigQuery.
TIME_FROM_PARTS(hour, minute, second[, nanosecond) Remarque: Snowflake accepte les dépassements de temps. Par exemple, TIME_FROM_PARTS(0, 100, 0) renvoie 01:40:00… Ceci n'est pas compatible avec BigQuery. BigQuery n'accepte pas les nanosecondes.	TIME(hour, minute, second) TIME(timestamp, [timezone]) TIME(datetime)
TIME_SLICE(dateOrTime, sliceLength, part[, START] TIME_SLICE(dateOrTime, sliceLength, part[, END]	DATE_TRUNC( DATE_SUB(CURRENT_DATE(), INTERVAL value MONTH), MONTH) DATE_TRUNC( DATE_ADD(CURRENT_DATE(), INTERVAL value MONTH), MONTH) Remarque: BigQuery n'est pas compatible avec une comparaison directe et exacte de TIME_SLICE de Snowflake. Utilisez DATETINE_TRUNC, TIME_TRUNC et TIMESTAMP_TRUNC pour le type de données approprié.
TIMEADD(part, value, dateOrTime)	TIME_ADD(time, INTERVAL value part)
TIMEDIFF( part, expression1, expression2, ) Remarque: Snowflake accepte le calcul de la différence entre deux types de date, d'heure et d'horodatage dans cette fonction.	DATE_DIFF( dateExpression1, dateExpression2, part ) DATETIME_DIFF( datetimeExpression1, datetimeExpression2, part ) TIME_DIFF( timeExpression1, timeExpression2, part ) TIMESTAMP_DIFF( timestampExpression1, timestampExpression2, part ) Remarque: BigQuery est compatible avec les parties de date de type semaine (<jour de la semaine>) et année ISO.
TIMESTAMP_[LTZ, NTZ, TZ _]FROM_PARTS (year, month, day, hour, second [, nanosecond][, timezone])	TIMESTAMP( string_expression[, timezone] | date_expression[, timezone] | datetime_expression[, timezone] ) Remarque: BigQuery nécessite que les horodatages soient saisis en tant que types STRING. Exemple : "2008-12-25 15:30:00"
TIMESTAMPADD(part, value, dateOrTime)	TIMESTAMPADD(timestamp, INTERVAL value part)
TIMESTAMPDIFF( part, expression1, expression2, ) Remarque: Snowflake accepte le calcul de la différence entre deux types de date, d'heure et d'horodatage dans cette fonction.	DATE_DIFF( dateExpression1, dateExpression2, part ) DATETIME_DIFF( datetimeExpression1, datetimeExpression2, part ) TIME_DIFF( timeExpression1, timeExpression2, part ) TIMESTAMP_DIFF( timestampExpression1, timestampExpression2, part ) Remarque: BigQuery est compatible avec les parties de date de type semaine (<jour de la semaine>) et année ISO.
TRUNC(dateOrTime, part) Remarque: Snowflake accepte le type de partie de date à la nanoseconde près. BigQuery ne l'est pas. Pour obtenir la liste complète des types de parties de date Snowflake, cliquez ici ..	DATE_TRUNC(date, part) DATETIME_TRUNC(datetime, part) TIME_TRUNC(time, part) TIMESTAMP_TRUNC(timestamp, part[, timezone]) Remarque: BigQuery est compatible avec les parties de date de type semaine (<jour de la semaine>), semaine ISO et année ISO. Pas Snowflake.
[YEAR*, DAY*, WEEK*, MONTH, QUARTER](dateOrTimestamp)	EXTRACT(part FROM timestamp [AT THE ZONE timezone])

BigQuery propose également les fonctions de date et heure suivantes, qui n'ont pas d'équivalent direct dans Snowflake:

DATE_SUB PARSE_DATE DATETIME_ADD PARSE_DATETIME PARSE_TIME TIMESTAMP_SUB TIMESTAMP_SECONDS UNIX_SECONDS	DATE_FROM_UNIX_DATE UNIX_DATE DATETIME_SUB TIME_SUB STRING FORMAT_TIMESTAMP TIMESTAMP_MILLIS UNIX_MILLIS	FORMAT_DATE DATETIME FORMAT_DATETIME FORMAT_TIME TIMESTAMP_ADD PARSE_TIMESTAMP TIMESTAMP_MICROS UNIX_MICROS

Schéma d'informations et fonctions de table

D'un point de vue conceptuel, BigQuery n'est pas compatible avec de nombreux schémas d'informations et fonctions de table. Snowflake offre les schémas d'information et les fonctions de table suivants, qui n'ont pas d'équivalent direct dans BigQuery:

• AUTOMATIC_CLUSTERING_HISTORY
• COPY_HISTORY
• DATA_TRANSFER_HISTORY
• DATABASE_REFRESH_HISTORY
• DATABASE_REFRESH_PROGRESS, DATABASE_REFRESH_PROGRESS_BY_JOB
• DATABASE_STORAGE_USAGE_HISTORY
• EXTERNAL_TABLE_FILES
• EXTERNAL_TABLE_FILE_REGISTRATION_HISTORY
• LOGIN_HISTORY, LOGIN_HISTORY_BY_USER
• MATERIALIZED_VIEW_REFRESH_HISTORY
• PIPE_USAGE_HISTORY
• REPLICATION_USAGE_HISTORY
• STAGE_STORAGE_USAGE_HISTORY
• TASK_DEPENDENTS
• VALIDATE_PIPE_LOAD
• WAREHOUSE_LOAD_HISTORY
• WAREHOUSE_METERING_HISTORY

Vous trouverez ci-dessous la liste des fonctions de table et de schéma d'informations BigQuery et Snowflake associés.

Snowflake	BigQuery
QUERY_HISTORY QUERY_HISTORY_BY_*	INFORMATION_SCHEMA.JOBS_BY_* Remarque: Pas d'alternative directe.
TASK_HISTORY	INFORMATION_SCHEMA.JOBS_BY_* Remarque: Pas d'alternative directe.

BigQuery propose le schéma d'informations et les fonctions de table suivants, qui n'ont pas d'équivalent direct dans Snowflake:

• INFORMATION_SCHEMA.SCHEMATA
• INFORMATION_SCHEMA.ROUTINES
• INFORMATION_SCHEMA.TABLES
• INFORMATION_SCHEMA.VIEWS

Fonctions numériques

Le tableau suivant présente les mappages des fonctions numériques Snowflake courantes avec leurs équivalents dans BigQuery.

Snowflake	BigQuery
ABS(expression)	ABS(expression)
ACOS(expression)	ACOS(expression)
ACOSH(expression)	ACOSH(expression)
ASIN(expression)	ASIN(expression)
ASINH(expression)	ASINH(expression)
ATAN(expression)	ATAN(expression)
ATAN2(y, x)	ATAN2(y, x)
ATANH(expression)	ATANH(expression)
CBRT(expression)	POW(expression, ⅓)
CEIL(expression [, scale])	CEIL(expression) Remarque: La méthode CEIL de BigQuery n'est pas compatible avec la précision ou l'échelle. ROUND ne permet pas de spécifier des arrondis.
COS(expression)	COS(expression)
COSH(expression)	COSH(expression)
COT(expression)	1/TAN(expression)
DEGREES(expression)	(expression)*(180/ACOS(-1))
EXP(expression)	EXP(expression)
FACTORIAL(expression)	BigQuery ne dispose pas d'une alternative directe au FACTORIAL de Snowflake. Utilisez une fonction définie par l'utilisateur.
FLOOR(expression [, scale])	FLOOR(expression) Remarque: La méthode FLOOR de BigQuery n'est pas compatible avec la précision ou l'échelle. ROUND ne permet pas de spécifier des arrondis. TRUNC fait de même pour les nombres positifs mais pas négatifs, car il évalue la valeur absolue.
HAVERSINE(lat1, lon1, lat2, lon2)	ST_DISTANCE( ST_GEOGPOINT(lon1, lat1), ST_GEOGPOINT(lon2, lat2) )/1000 Remarque: Il ne s'agit pas d'une correspondance exacte, mais suffisamment proche.
LN(expression)	LN(expression)
LOG(base, expression)	LOG(expression [,base]) LOG10(expression) Remarque: La valeur par défaut de la base de LOG est de 10.
MOD(expression1, expression2)	MOD(expression1, expression2)
PI()	ACOS(-1)
POW(x, y) POWER(x, y)	POW(x, y) POWER(x, y)
RADIANS(expression)	(expression)*(ACOS(-1)/180)
ROUND(expression [, scale])	ROUND(expression, [, scale])
SIGN(expression)	SIGN(expression)
SIN(expression)	SIN(expression)
SINH(expression)	SINH(expression)
SQRT(expression)	SQRT(expression)
SQUARE(expression)	POW(expression, 2)
TAN(expression)	TAN(expression)
TANH(expression)	TANH(expression)
TRUNC(expression [, scale]) TRUNCATE(expression [, scale])	TRUNC(expression [, scale]) Remarque: La valeur renvoyée par BigQuery doit être inférieure à celle de l'expression. Elles ne peuvent pas être égales.

BigQuery propose également les fonctions mathématiques suivantes, qui n'ont pas d'équivalent direct dans Snowflake:

• IS_INF
• IS_NAN
• IEEE_DIVIDE
• DIV
• SAFE_DIVIDE
• SAFE_MULTIPLY
• SAFE_NEGATE
• SAFE_ADD
• SAFE_SUBTRACT
• RANGE_BUCKET

Fonctions de données semi-structurées

Snowflake	BigQuery
ARRAY_APPEND	Fonction définie par l'utilisateur personnalisée.
ARRAY_CAT	ARRAY_CONCAT
ARRAY_COMPACT	Fonction définie par l'utilisateur personnalisée.
ARRAY_CONSTRUCT	[ ]
ARRAY_CONSTRUCT_COMPACT	Fonction définie par l'utilisateur personnalisée.
ARRAY_CONTAINS	Fonction définie par l'utilisateur personnalisée.
ARRAY_INSERT	Fonction définie par l'utilisateur personnalisée.
ARRAY_INTERSECTION	Fonction définie par l'utilisateur personnalisée.
ARRAY_POSITION	Fonction définie par l'utilisateur personnalisée.
ARRAY_PREPEND	Fonction définie par l'utilisateur personnalisée.
ARRAY_SIZE	ARRAY_LENGTH
ARRAY_SLICE	Fonction définie par l'utilisateur personnalisée.
ARRAY_TO_STRING	ARRAY_TO_STRING
ARRAYS_OVERLAP	Fonction définie par l'utilisateur personnalisée.
AS_<object_type>	CAST
AS_ARRAY	CAST
AS_BINARY	CAST
AS_BOOLEAN	CAST
AS_CHAR , AS_VARCHAR	CAST
AS_DATE	CAST
AS_DECIMAL , AS_NUMBER	CAST
AS_DOUBLE , AS_REAL	CAST
AS_INTEGER	CAST
AS_OBJECT	CAST
AS_TIME	CAST
AS_TIMESTAMP_*	CAST
CHECK_JSON	Fonction définie par l'utilisateur personnalisée.
CHECK_XML	Fonction définie par l'utilisateur personnalisée.
FLATTEN	UNNEST
GET	Fonction définie par l'utilisateur personnalisée.
GET_IGNORE_CASE	Fonction définie par l'utilisateur personnalisée.
GET_PATH , :	Fonction définie par l'utilisateur personnalisée.
IS_<object_type>	Fonction définie par l'utilisateur personnalisée.
IS_ARRAY	Fonction définie par l'utilisateur personnalisée.
IS_BINARY	Fonction définie par l'utilisateur personnalisée.
IS_BOOLEAN	Fonction définie par l'utilisateur personnalisée.
IS_CHAR , IS_VARCHAR	Fonction définie par l'utilisateur personnalisée.
IS_DATE , IS_DATE_VALUE	Fonction définie par l'utilisateur personnalisée.
IS_DECIMAL	Fonction définie par l'utilisateur personnalisée.
IS_DOUBLE , IS_REAL	Fonction définie par l'utilisateur personnalisée.
IS_INTEGER	Fonction définie par l'utilisateur personnalisée.
IS_OBJECT	Fonction définie par l'utilisateur personnalisée.
IS_TIME	Fonction définie par l'utilisateur personnalisée.
IS_TIMESTAMP_*	Fonction définie par l'utilisateur personnalisée.
OBJECT_CONSTRUCT	Fonction définie par l'utilisateur personnalisée.
OBJECT_DELETE	Fonction définie par l'utilisateur personnalisée.
OBJECT_INSERT	Fonction définie par l'utilisateur personnalisée.
PARSE_JSON	JSON_EXTRACT
PARSE_XML	Fonction définie par l'utilisateur personnalisée.
STRIP_NULL_VALUE	Fonction définie par l'utilisateur personnalisée.
STRTOK_TO_ARRAY	SPLIT
TRY_PARSE_JSON	Fonction définie par l'utilisateur personnalisée.
TYPEOF	Fonction définie par l'utilisateur personnalisée.
XMLGET	Fonction définie par l'utilisateur personnalisée.

Fonctions de chaîne et binaires

Snowflake	BigQuery
string1 || string2	CONCAT(string1, string2)
ASCII	TO_CODE_POINTS(string1)[OFFSET(0)]
BASE64_DECODE_BINARY	SAFE_CONVERT_BYTES_TO_STRING( FROM_BASE64(<bytes_input>) )
BASE64_DECODE_STRING	SAFE_CONVERT_BYTES_TO_STRING( FROM_BASE64(<string1>) )
BASE64_ENCODE	TO_BASE64( SAFE_CAST(<string1> AS BYTES) )
BIT_LENGTH	BYTE_LENGTH * 8 CHARACTER_LENGTH
CHARINDEX(substring, string)	STRPOS(string, substring)
CHR,CHAR	CODE_POINTS_TO_STRING([number])
COLLATE	Fonction définie par l'utilisateur personnalisée.
COLLATION	Fonction définie par l'utilisateur personnalisée.
COMPRESS	Fonction définie par l'utilisateur personnalisée.
CONCAT(string1, string2)	CONCAT(string1, string2) Remarque : La fonction CONCAT(...) de BigQuery accepte la concaténation de n'importe quel nombre de chaînes.
CONTAINS	Fonction définie par l'utilisateur personnalisée.
DECOMPRESS_BINARY	Fonction définie par l'utilisateur personnalisée.
DECOMPRESS_STRING	Fonction définie par l'utilisateur personnalisée.
EDITDISTANCE	EDIT_DISTANCE
ENDSWITH	Fonction définie par l'utilisateur personnalisée.
HEX_DECODE_BINARY	SAFE_CONVERT_BYTES_TO_STRING( FROM_HEX(<string1>)
HEX_DECODE_STRING	SAFE_CONVERT_BYTES_TO_STRING( FROM_HEX(<string1>)
HEX_ENCODE	TO_HEX( SAFE_CAST(<string1> AS BYTES))
ILIKE	Fonction définie par l'utilisateur personnalisée.
ILIKE ANY	Fonction définie par l'utilisateur personnalisée.
INITCAP	INITCAP
INSERT	Fonction définie par l'utilisateur personnalisée.
LEFT	Fonction définie par l'utilisateur
LENGTH	LENGTH(expression)
LIKE	LIKE
LIKE ALL	Fonction définie par l'utilisateur personnalisée.
LIKE ANY	Fonction définie par l'utilisateur personnalisée.
LOWER	LOWER(string)
LPAD	LPAD(string1, length[, string2])
LTRIM	LTRIM(string1, trim_chars)
MD5,MD5_HEX	MD5(string)
MD5_BINARY	Fonction définie par l'utilisateur personnalisée.
OCTET_LENGTH	Fonction définie par l'utilisateur personnalisée.
PARSE_IP	Fonction définie par l'utilisateur personnalisée.
PARSE_URL	Fonction définie par l'utilisateur personnalisée.
POSITION	STRPOS(string, substring)
REPEAT	REPEAT(string, integer)
REPLACE	REPLACE(string1, old_chars, new_chars)
REVERSE number_characters )	REVERSE(expression)
RIGHT	Fonction définie par l'utilisateur
RPAD	RPAD
RTRIM	RTRIM(string, trim_chars)
RTRIMMED_LENGTH	Fonction définie par l'utilisateur personnalisée.
SHA1,SHA1_HEX	SHA1(string)
SHA1_BINARY	Fonction définie par l'utilisateur personnalisée.
SHA2,SHA2_HEX	Fonction définie par l'utilisateur personnalisée.
SHA2_BINARY	Fonction définie par l'utilisateur personnalisée.
SOUNDEX	Fonction définie par l'utilisateur personnalisée.
SPACE	Fonction définie par l'utilisateur personnalisée.
SPLIT	SPLIT
SPLIT_PART	Fonction définie par l'utilisateur personnalisée.
SPLIT_TO_TABLE	Fonction définie par l'utilisateur personnalisée.
STARTSWITH	Fonction définie par l'utilisateur personnalisée.
STRTOK	SPLIT(instring, delimiter)[ORDINAL(tokennum)] Remarque : L'argument de chaîne délimiteur entier est utilisé comme un délimiteur unique. Le délimiteur par défaut est une virgule.
STRTOK_SPLIT_TO_TABLE	Fonction définie par l'utilisateur personnalisée.
SUBSTR,SUBSTRING	SUBSTR
TRANSLATE	Fonction définie par l'utilisateur personnalisée.
TRIM	TRIM
TRY_BASE64_DECODE_BINARY	Fonction définie par l'utilisateur personnalisée.
TRY_BASE64_DECODE_STRING	SUBSTR(string, 0, integer)
TRY_HEX_DECODE_BINARY	SUBSTR(string, -integer)
TRY_HEX_DECODE_STRING	LENGTH(expression)
UNICODE	Fonction définie par l'utilisateur personnalisée.
UPPER	UPPER

Fonctions de chaîne (expressions régulières)

Snowflake	BigQuery
REGEXP	IF(REGEXP_CONTAINS,1,0)=1
REGEXP_COUNT	ARRAY_LENGTH( REGEXP_EXTRACT_ALL( source_string, pattern ) ) Si position est spécifié: ARRAY_LENGTH( REGEXP_EXTRACT_ALL( SUBSTR(source_string, IF(position <= 0, 1, position)), pattern ) ) Remarque : La bibliothèque re2 permet d'utiliser des expressions régulières dans BigQuery. Consultez la documentation de cette bibliothèque pour en savoir plus sur la syntaxe d'expression régulière à utiliser.
REGEXP_INSTR	IFNULL( STRPOS( source_string, REGEXP_EXTRACT( source_string, pattern) ), 0) Si position est spécifié: IFNULL( STRPOS( SUBSTR(source_string, IF(position <= 0, 1, position)), REGEXP_EXTRACT( SUBSTR(source_string, IF(position <= 0, 1, position)), pattern) ) + IF(position <= 0, 1, position) - 1, 0) Si occurrence est spécifié: IFNULL( STRPOS( SUBSTR(source_string, IF(position <= 0, 1, position)), REGEXP_EXTRACT_ALL( SUBSTR(source_string, IF(position <= 0, 1, position)), pattern )[SAFE_ORDINAL(occurrence)] ) + IF(position <= 0, 1, position) - 1, 0) Remarque : La bibliothèque re2 permet d'utiliser des expressions régulières dans BigQuery. Consultez la documentation de cette bibliothèque pour en savoir plus sur la syntaxe d'expression régulière à utiliser.
REGEXP_LIKE	IF(REGEXP_CONTAINS,1,0)=1
REGEXP_REPLACE	REGEXP_REPLACE( source_string, pattern, "" ) Si replace_string est spécifié: REGEXP_REPLACE( source_string, pattern, replace_string ) Si position est spécifié: CASE WHEN position > LENGTH(source_string) THEN source_string WHEN position <= 0 THEN REGEXP_REPLACE( source_string, pattern, "" ) ELSE CONCAT( SUBSTR( source_string, 1, position - 1), REGEXP_REPLACE( SUBSTR(source_string, position), pattern, replace_string ) ) END Remarque : La bibliothèque re2 permet d'utiliser des expressions régulières dans BigQuery. Consultez la documentation de cette bibliothèque pour en savoir plus sur la syntaxe d'expression régulière à utiliser.
REGEXP_SUBSTR	REGEXP_EXTRACT( source_string, pattern ) Si position est spécifié: REGEXP_EXTRACT( SUBSTR(source_string, IF(position <= 0, 1, position)), pattern ) Si occurrence est spécifié: REGEXP_EXTRACT_ALL( SUBSTR(source_string, IF(position <= 0, 1, position)), pattern )[SAFE_ORDINAL(occurrence)] Remarque : La bibliothèque re2 permet d'utiliser des expressions régulières dans BigQuery. Consultez la documentation de cette bibliothèque pour en savoir plus sur la syntaxe d'expression régulière à utiliser.
RLIKE	IF(REGEXP_CONTAINS,1,0)=1

Fonctions système

Snowflake	BigQuery
SYSTEM$ABORT_SESSION	Fonction définie par l'utilisateur personnalisée.
SYSTEM$ABORT_TRANSACTION	Fonction définie par l'utilisateur personnalisée.
SYSTEM$CANCEL_ALL_QUERIES	Fonction définie par l'utilisateur personnalisée.
SYSTEM$CANCEL_QUERY	Fonction définie par l'utilisateur personnalisée.
SYSTEM$CLUSTERING_DEPTH	Fonction définie par l'utilisateur personnalisée.
SYSTEM$CLUSTERING_INFORMATION	Fonction définie par l'utilisateur personnalisée.
SYSTEM$CLUSTERING_RATIO — Deprecated	Fonction définie par l'utilisateur personnalisée.
SYSTEM$CURRENT_USER_TASK_NAME	Fonction définie par l'utilisateur personnalisée.
SYSTEM$DATABASE_REFRESH_HISTORY	Fonction définie par l'utilisateur personnalisée.
SYSTEM$DATABASE_REFRESH_PROGRESS , SYSTEM$DATABASE_REFRESH_PROGRESS_BY_JOB	Fonction définie par l'utilisateur personnalisée.
SYSTEM$GET_AWS_SNS_IAM_POLICY	Fonction définie par l'utilisateur personnalisée.
SYSTEM$GET_PREDECESSOR_RETURN_VALUE	Fonction définie par l'utilisateur personnalisée.
SYSTEM$LAST_CHANGE_COMMIT_TIME	Fonction définie par l'utilisateur personnalisée.
SYSTEM$PIPE_FORCE_RESUME	Fonction définie par l'utilisateur personnalisée.
SYSTEM$PIPE_STATUS	Fonction définie par l'utilisateur personnalisée.
SYSTEM$SET_RETURN_VALUE	Fonction définie par l'utilisateur personnalisée.
SYSTEM$SHOW_OAUTH_CLIENT_SECRETS	Fonction définie par l'utilisateur personnalisée.
SYSTEM$STREAM_GET_TABLE_TIMESTAMP	Fonction définie par l'utilisateur personnalisée.
SYSTEM$STREAM_HAS_DATA	Fonction définie par l'utilisateur personnalisée.
SYSTEM$TASK_DEPENDENTS_ENABLE	Fonction définie par l'utilisateur personnalisée.
SYSTEM$TYPEOF	Fonction définie par l'utilisateur personnalisée.
SYSTEM$USER_TASK_CANCEL_ONGOING_EXECUTIONS	Fonction définie par l'utilisateur personnalisée.
SYSTEM$WAIT	Fonction définie par l'utilisateur personnalisée.
SYSTEM$WHITELIST	Fonction définie par l'utilisateur personnalisée.
SYSTEM$WHITELIST_PRIVATELINK	Fonction définie par l'utilisateur personnalisée.

Fonctions de table

Snowflake		BigQuery
GENERATOR		Fonction définie par l'utilisateur personnalisée.
GET_OBJECT_REFERENCES		Fonction définie par l'utilisateur personnalisée.
RESULT_SCAN		Fonction définie par l'utilisateur personnalisée.
VALIDATE		Fonction définie par l'utilisateur personnalisée.

Fonctions utilitaire et de hachage

Snowflake		BigQuery
GET_DDL		Demande de fonctionnalité
HASH		HASH est une fonction propriétaire spécifique à Snowflake. Impossible de traduire sans connaître la logique sous-jacente utilisée par Snowflake.

Fonctions de fenêtrage

Snowflake		BigQuery
CONDITIONAL_CHANGE_EVENT		Fonction définie par l'utilisateur personnalisée.
CONDITIONAL_TRUE_EVENT		Fonction définie par l'utilisateur personnalisée.
CUME_DIST		CUME_DIST
DENSE_RANK		DENSE_RANK
FIRST_VALUE		FIRST_VALUE
LAG		LAG
LAST_VALUE		LAST_VALUE
LEAD		LEAD
NTH_VALUE		NTH_VALUE
NTILE		NTILE
PERCENT_RANK		PERCENT_RANK
RANK		RANK
RATIO_TO_REPORT		Fonction définie par l'utilisateur personnalisée.
ROW_NUMBER		ROW_NUMBER
WIDTH_BUCKET		Fonction définie par l'utilisateur personnalisée.

BigQuery est également compatible avec SAFE_CAST(expression AS typename), qui renvoie NULL si BigQuery ne peut pas effectuer de casting (par exemple, SAFE_CAST("apple" AS INT64) renvoie NULL).

Opérateurs

Les sections suivantes répertorient les opérateurs Snowflake et leurs équivalents dans BigQuery.

Opérateurs arithmétiques

Le tableau suivant présente les mappages des opérateurs arithmétiques de Snowflake avec leurs équivalents dans BigQuery.

Snowflake	BigQuery
(Unary) (+'5')	CAST("5" AS NUMERIC)
a + b	a + b
(Unary) (-'5')	(-1) * CAST("5" AS NUMERIC) Remarque: BigQuery est compatible avec le moins unaire standard, mais ne convertit pas les entiers au format de chaîne en type INT64, NUMERIC ou FLOAT64.
a - b	a - b
date1 - date2 date1 - 365	DATE_DIFF(date1, date2, date_part) DATE_SUB(date1, date2, date_part)
a * b	a * b
a / b	a / b
a % b	MOD(a, b)

Pour afficher les détails d'échelle et de précision Snowflake lors de l'exécution d'opérations arithmétiques, consultez la documentation de Snowflake.

Opérateurs de comparaison

Les opérateurs de comparaison de Snowflake et les opérateurs de comparaison de BigQuery sont identiques.

Opérateurs logiques/booléens

Les opérateurs logiques/booléens de Snowflake et les opérateurs logiques/booléens BigQuery sont identiques.

Opérateurs d'ensemble

Le tableau suivant présente les mappages des opérateurs d'ensemble Snowflake avec leurs équivalents dans BigQuery.

Snowflake	BigQuery
SELECT ... INTERSECT SELECT ...	SELECT ... INTERSECT DISTINCT SELECT...
SELECT ... MINUS SELECT ... SELECT ... EXCEPT SELECT … Remarque : MINUS et EXCEPT sont des synonymes.	SELECT ... EXCEPT DISTINCT SELECT ...
SELECT ... UNION SELECT ... SELECT ... UNION ALL SELECT ...	SELECT ... UNION DISTINCT SELECT ... SELECT ... UNION ALL SELECT ...

Opérateurs de sous-requêtes

Le tableau suivant présente les mappages des opérateurs de sous-requêtes Snowflake avec leurs équivalents dans BigQuery.

Snowflake	BigQuery
SELECT ... FROM ... WHERE col <operator> ALL … SELECT ... FROM ... WHERE col <operator> ANY ...	BigQuery n'est pas compatible avec une alternative directe à ALL/ANY de Snowflake.
SELECT ... FROM ... WHERE [NOT] EXISTS...	SELECT ... FROM ... WHERE [NOT] EXISTS...
SELECT ... FROM ... WHERE [NOT] IN...	SELECT ... FROM ... WHERE [NOT] IN...
SELECT * FROM table1 UNION SELECT * FROM table2 EXCEPT SELECT * FROM table3	SELECT * FROM table1 UNION ALL ( SELECT * FROM table2 EXCEPT SELECT * FROM table3 ) Remarque : BigQuery nécessite des parenthèses pour séparer les différentes opérations d'ensemble. Si le même opérateur d'ensemble est répété, les parenthèses ne sont pas nécessaires.

Syntaxe LMD

Cette section traite des différences de syntaxe du langage de manipulation de données entre Snowflake et BigQuery.

Instruction INSERT

Snowflake propose un mot clé DEFAULT configurable pour les colonnes. Dans BigQuery, la valeur DEFAULT des colonnes pouvant être vides est NULL, et DEFAULT n'est pas accepté pour les colonnes obligatoires. La plupart des instructions INSERT de Snowflake sont compatibles avec BigQuery. Le tableau suivant présente les exceptions.

Snowflake	BigQuery
INSERT [OVERWRITE] INTO table VALUES [... | DEFAULT | NULL] ... Remarque: BigQuery n'accepte pas l'insertion d'objets JSON avec une instruction INSERT ..	INSERT [INTO] table (column1 [, ...]) VALUES (DEFAULT [, ...]) Remarque: BigQuery n'est pas compatible avec une alternative directe à OVERWRITE de Snowflake. Utilisez plutôt DELETE.
INSERT INTO table (column1 [, ...]) SELECT... FROM ...	INSERT [INTO] table (column1, [,...]) SELECT ... FROM ...
INSERT [OVERWRITE] ALL <intoClause> ... INSERT [OVERWRITE] {FIRST | ALL} {WHEN condition THEN <intoClause>} [...] [ELSE <intoClause>] ... Remarque<intoClause> représente l'élément INSERT statement standard répertorié ci-dessus.	BigQuery n'est pas compatible avec les tables multiples conditionnelles et inconditionnelles INSERTs.

BigQuery permet également d'insérer des valeurs à l'aide d'une sous-requête (où l'une des valeurs est calculée à l'aide d'une sous-requête), ce qui n'est pas compatible avec Snowflake. Par exemple :

INSERT INTO table (column1, column2)
VALUES ('value_1', (
  SELECT column2
  FROM table2
))

Instruction COPY

Snowflake accepte les copies de données de fichiers d'étapes dans une table existante et depuis une table vers une étape interne nommée, une étape externe nommée et un emplacement externe (Amazon S3, Google Cloud Storage ou Microsoft Azure).

• COPY INTO <table>
• COPY INTO <location>

BigQuery n'utilise pas la commande SQL COPY pour charger des données, mais vous pouvez utiliser n'importe lequel de ces outils et n'importe laquelle de ces options non-SQL pour charger des données dans des tables BigQuery. Vous pouvez également utiliser les récepteurs de pipelines de données fournis dans Apache Spark ou Apache Beam pour écrire des données dans BigQuery.

Instruction UPDATE

La plupart des instructions UPDATE Snowflake sont compatibles avec BigQuery. Le tableau suivant présente les exceptions.

Snowflake		BigQuery
UPDATE table SET col = value [,...] [FROM ...] [WHERE ...]		UPDATE table SET column = expression [,...] [FROM ...] WHERE TRUE Remarque : Toutes les instructions UPDATE de BigQuery nécessitent un mot clé WHERE, suivi d'une condition.

Instructions DELETE et TRUNCATE TABLE

Les instructions DELETE et TRUNCATE TABLE permettent de supprimer des lignes d'une table sans que cela n'affecte son schéma ou ses index.

Dans Snowflake, DELETE et TRUNCATE TABLE conservent les données supprimées à l'aide de la fonctionnalité temporelle de Snowflake à des fins de récupération pour la période de conservation des données. Toutefois, DELETE ne supprime pas l'historique de chargement des fichiers externes ni les métadonnées de chargement.

Dans BigQuery, l'instruction DELETE doit comporter une clause WHERE. Pour en savoir plus sur l'instruction DELETE dans BigQuery, consultez les exemples d'instructions DELETE BigQuery dans la documentation sur le LMD.

Snowflake	BigQuery
DELETE FROM table_name [USING ...] [WHERE ...] TRUNCATE [TABLE] [IF EXISTS] table_name	DELETE [FROM] table_name [alias] WHERE ... Remarque: Les instructions BigQuery DELETE nécessitent une clause WHERE .

Instruction MERGE

L'instruction MERGE peut combiner les opérations INSERT, UPDATE et DELETE en une seule instruction "upsert" et effectuer les opérations de manière automatique. L'opération MERGE doit correspondre à une ligne source au maximum pour chaque ligne cible.

Les tables BigQuery sont limitées à 1 000 instructions LMD par jour. Vous devez donc optimiser en consolidant les instructions INSERT, UPDATE et DELETE en une seule instruction MERGE, comme indiqué dans le tableau suivant:

Snowflake	BigQuery
MERGE INTO target USING source ON target.key = source.key WHEN MATCHED AND source.filter = 'Filter_exp' THEN UPDATE SET target.col1 = source.col1, target.col1 = source.col2, ... Remarque: Snowflake accepte un paramètre de session ERROR_ON_NONDETERMINISTIC_MERGE pour gérer les résultats non déterministes.	MERGE target USING source ON target.key = source.key WHEN MATCHED AND source.filter = 'filter_exp' THEN UPDATE SET target.col1 = source.col1, target.col2 = source.col2, ... Remarque : Toutes les colonnes doivent être répertoriées si vous souhaitez mettre à jour toutes les colonnes.

Instructions GET et LIST

L'instruction GET télécharge les fichiers de données de l'une des étapes Snowflake suivantes dans un répertoire/dossier local sur une machine cliente:

• Étape interne nommée
• Étape interne pour une table spécifiée
• Étape interne pour l'utilisateur actuel

L'instruction LIST (LS) renvoie la liste des fichiers intermédiaires (c'est-à-dire importés depuis un système de fichiers local ou déchargés d'une table) dans l'une des les étapes Snowflake suivantes:

• Étape interne nommée
• Étape externe nommée
• Étape pour une table spécifiée
• Étape pour l'utilisateur actuel

BigQuery n'est pas compatible avec le concept de préproduction et ne dispose pas d'équivalent GET et LIST.

Instructions PUT et REMOVE

L'instruction PUT importe (par étape) des fichiers de données depuis un répertoire/dossier local d'une machine cliente vers l'une des étapes Snowflake suivantes:

• Étape interne nommée
• Étape interne pour une table spécifiée
• Étape interne pour l'utilisateur actuel

L'instruction REMOVE (RM) supprime les fichiers qui ont été importés dans l'une des étapes internes de Snowflake suivantes:

• Étape interne nommée
• Étape pour une table spécifiée
• Étape pour l'utilisateur actuel

BigQuery n'est pas compatible avec le concept de préproduction et ne dispose pas d'équivalent PUT et REMOVE.

Syntaxe LDD

Cette section traite des différences de syntaxe du langage de définition de données entre Snowflake et BigQuery.

Base de données, schéma et partage LDD

La plupart des termes de Snowflake correspondent à ceux de BigQuery, à la différence que la base de données Snowflake est semblable à l'ensemble de données BigQuery. Consultez le mappage détaillé de la terminologie Snowflake vers BigQuery.

Instruction CREATE DATABASE

Snowflake permet de créer et de gérer une base de données via les commandes de gestion des bases de données tandis que BigQuery propose plusieurs options, telles que l'utilisation de la console, de la CLI, des bibliothèques clientes, etc. pour créer des ensembles de données. Cette section utilise les commandes de CLI BigQuery correspondant aux commandes Snowflake pour traiter les différences.

Snowflake	BigQuery
CREATE DATABASE <name> Remarque: Snowflake fournit ces exigences pour la dénomination des bases de données. Le nom ne peut contenir que 255 caractères.	bq mk <name> Remarque: BigQuery présente des exigences de dénomination des ensembles de données semblables à celles de Snowflake, sauf qu'il autorise 1 024 caractères dans le nom.
CREATE OR REPLACE DATABASE <name>	Le remplacement de l'ensemble de données n'est pas disponible dans BigQuery.
CREATE TRANSIENT DATABASE <name>	La création d'un ensemble de données temporaire n'est pas disponible dans BigQuery.
CREATE DATABASE IF NOT EXISTS <name>	Concept non compatible avec BigQuery
CREATE DATABASE <name> CLONE <source_db> [ { AT | BEFORE } ( { TIMESTAMP => <timestamp> | OFFSET => <time_difference> | STATEMENT => <id> } ) ]	Le clonage d'ensembles de données n'est pas encore disponible dans BigQuery.
CREATE DATABASE <name> DATA_RETENTION_TIME_IN_DAYS = <num>	Les fonctionnalités temporelles ne sont pas disponibles dans BigQuery pour les ensembles de données. Cependant, les fonctionnalités temporelles sont disponibles pour les résultats de tables et de requêtes.
CREATE DATABASE <name> DEFAULT_DDL_COLLATION = '<collation_specification>'	Le classement LDD n'est pas compatible avec BigQuery.
CREATE DATABASE <name> COMMENT = '<string_literal>'	bq mk \ --description "<string_literal>" \ <name>
CREATE DATABASE <name> FROM SHARE <provider_account>.<share_name>	La création d'ensembles de données partagés n'est pas disponible dans BigQuery. Cependant, les utilisateurs peuvent partager l'ensemble de données via la console/l'interface utilisateur une fois l'ensemble de données créé.
CREATE DATABASE <name> AS REPLICA OF <region>.<account>.<primary_db_name> AUTO_REFRESH_MATERIALIZED_VIEWS_ON_SECONDARY = { TRUE | FALSE } Remarque: Snowflake fournit l'option de maintenance automatique en arrière-plan des vues matérialisées dans la base de données secondaire, qui n'est pas compatible avec BigQuery.	bq mk --transfer_config \ --target_dataset = <name> \ --data_source = cross_region_copy \ --params=' {"source_dataset_id":"<primary_db_name>" ,"source_project_id":"<project_id>" ,"overwrite_destination_table":"true"}' Remarque: BigQuery permet de copier des ensembles de données à l'aide du service de transfert de données BigQuery. Consultez cette section pour connaître les conditions préalables à la copie d'un ensemble de données.

BigQuery propose également les options de commande bq mk suivantes, qui n'ont pas d'équivalent direct dans Snowflake:

• --location <dataset_location>
• --default_table_expiration <time_in_seconds>
• --default_partition_expiration <time_in_seconds>

Instruction ALTER DATABASE

Cette section utilise les commandes de la CLI BigQuery correspondant aux commandes Snowflake pour traiter les différences entre les instructions ALTER.

Snowflake	BigQuery
ALTER DATABASE [ IF EXISTS ] <name> RENAME TO <new_db_name>	Il n'est pas possible de renommer des ensembles de données dans BigQuery, mais il est possible de les copier.
ALTER DATABASE <name> SWAP WITH <target_db_name>	Échanger des ensembles de données n'est pas compatible avec BigQuery.
ALTER DATABASE <name> SET [DATA_RETENTION_TIME_IN_DAYS = <num>] [ DEFAULT_DDL_COLLATION = '<value>']	La gestion de la conservation et du classement des données au niveau de l'ensemble de données n'est pas disponible dans BigQuery.
ALTER DATABASE <name> SET COMMENT = '<string_literal>'	bq update \ --description "<string_literal>" <name>
ALTER DATABASE <name> ENABLE REPLICATION TO ACCOUNTS <snowflake_region>.<account_name> [ , <snowflake_region>.<account_name> ... ]	Concept non compatible avec BigQuery.
ALTER DATABASE <name> DISABLE REPLICATION [ TO ACCOUNTS <snowflake_region>.<account_name> [ , <snowflake_region>.<account_name> ... ]]	Concept non compatible avec BigQuery.
ALTER DATABASE <name> SET AUTO_REFRESH_MATERIALIZED_VIEWS_ON_SECONDARY = { TRUE | FALSE }	Concept non compatible avec BigQuery.
ALTER DATABASE <name> REFRESH	Concept non compatible avec BigQuery.
ALTER DATABASE <name> ENABLE FAILOVER TO ACCOUNTS <snowflake_region>.<account_name> [ , <snowflake_region>.<account_name> ... ]	Concept non compatible avec BigQuery.
ALTER DATABASE <name> DISABLE FAILOVER [ TO ACCOUNTS <snowflake_region>.<account_name> [ , <snowflake_region>.<account_name> ... ]]	Concept non compatible avec BigQuery.
ALTER DATABASE <name> PRIMARY	Concept non compatible avec BigQuery.

Instruction DROP DATABASE

Cette section utilise la commande CLI BigQuery correspondant à la commande Snowflake pour traiter la différence concernant l'instruction DROP.

Snowflake

BigQuery

DROP DATABASE [ IF EXISTS ] <name> [ CASCADE | RESTRICT ] Remarque: Dans Snowflake, le fait de retirer une base de données ne la supprime pas définitivement du système. Une version de la base de données retirée est conservée pendant le nombre de jours spécifié par le paramètre DATA_RETENTION_TIME_IN_DAYS de la base de données.

bq rm -r -f -d <name> Where -r consiste à supprimer tous les objets de l'ensemble de données . -f is to skip confirmation for execution -d indique un ensemble de données Remarque: Dans BigQuery, la suppression d'un ensemble de données est définitive. De plus, les données en cascade ne sont pas acceptées au niveau de l'ensemble de données, car toutes les données et tous les objets de l'ensemble de données sont supprimés.

Snowflake accepte également la commande UNDROP DATASET qui restaure la version la plus récente d'un ensemble de données retiré. Cette fonctionnalité n'est actuellement pas compatible avec BigQuery au niveau de l'ensemble de données.

Instruction USE DATABASE

Snowflake offre la possibilité de définir la base de données pour une session utilisateur à l'aide de la commande USE DATABASE. Cela évite d'avoir à spécifier des noms d'objets complets dans les commandes SQL. BigQuery ne fournit aucune alternative à la commande USE DATABASE de Snowflake.

Instruction SHOW DATABASE

Cette section utilise la commande CLI BigQuery correspondant à la commande Snowflake pour traiter la différence concernant l'instruction SHOW.

Snowflake	BigQuery
SHOW DATABASES Remarque: Snowflake fournit une seule option pour répertorier et afficher les détails de toutes les bases de données, y compris celles qui sont retirées pendant la période de conservation.	bq ls --format=prettyjson et / ou bq show <dataset_name> Remarque: Dans BigQuery, la commande ls ne fournit que des noms d'ensemble de données et des informations de base, et la commande show fournit des détails tels que la dernière modification de l'horodatage, les LCA et les libellés d'un ensemble de données. BigQuery fournit également plus de détails sur les ensembles de données via le schéma d'informations.
SHOW TERSE DATABASES Remarque: Avec l'option TERSE, Snowflake permet d'afficher uniquement les informations/champs spécifiques sur les ensembles de données.	Concept non compatible avec BigQuery.
SHOW DATABASES HISTORY	Les concepts de fonctionnalité temporelle ne sont pas compatibles avec BigQuery au niveau de l'ensemble de données.
SHOW DATABASES [LIKE '<pattern>'] [STARTS WITH '<name_string>']	Le filtrage des résultats par nom d'ensemble de données n'est pas disponible dans BigQuery. Toutefois, le filtrage par libellé est compatible.
SHOW DATABASES LIMIT <rows> [FROM '<name_string>'] Remarque: Par défaut, Snowflake ne limite pas le nombre de résultats. Toutefois, la valeur de LIMIT ne peut pas dépasser 10 000.	bq ls \ --max_results <rows> Remarque: Par défaut, BigQuery n'affiche que 50 résultats.

BigQuery propose également les options de commande bq suivantes, qui n'ont pas d'équivalent direct dans Snowflake:

• bq ls --format=pretty: renvoie les résultats formatés de base
• *bq ls -a: *renvoie uniquement les ensembles de données anonymes (ceux commençant par un trait de soulignement).
• bq ls --all: renvoie tous les ensembles de données, y compris les ensembles anonymes
• bq ls --filter labels.key:value: renvoie les résultats filtrés par libellé d'ensemble de données.
• bq ls --d: exclut les ensembles de données des résultats
• bq show --format=pretty: renvoie les résultats détaillés au format de base pour tous les ensembles de données

Gestion de SCHEMA

Snowflake fournit plusieurs commandes de gestion de schéma semblables à ses commandes de gestion de base de données. Ce concept de création et de gestion de schéma n'est pas disponible dans BigQuery.

Cependant, BigQuery vous permet de spécifier le schéma d'une table lorsque vous chargez des données dans une table et lorsque vous créez une table vide. Vous pouvez également utiliser la détection automatique de schéma pour les formats de données compatibles.

Gestion de SHARE

Snowflake fournit plusieurs commandes de gestion de partage semblables à ses commandes de gestion de base de données et de schéma. Ce concept de création et de gestion des partages n'est pas disponible dans BigQuery.

Table, vue et séquence LDD

Instruction CREATE TABLE

La plupart des instructions CREATE TABLE Snowflake sont compatibles avec BigQuery, à l'exception des éléments de syntaxe suivants, qui ne sont pas utilisés dans BigQuery :

Snowflake	BigQuery
CREATE TABLE table_name ( col1 data_type1 NOT NULL, col2 data_type2 NULL, col3 data_type3 UNIQUE, col4 data_type4 PRIMARY KEY, col5 data_type5 ) Remarque: Les contraintes UNIQUE et PRIMARY KEY sont informatives et ne sont pas appliquées par le système Snowflake.	CREATE TABLE table_name ( col1 data_type1 NOT NULL, col2 data_type2, col3 data_type3, col4 data_type4, col5 data_type5, )
CREATE TABLE table_name ( col1 data_type1[,...] table_constraints ) où table_constraints sont: [UNIQUE(column_name [, ... ])] [PRIMARY KEY(column_name [, ...])] [FOREIGN KEY(column_name [, ...]) REFERENCES reftable [(refcolumn)] Remarque: Les contraintes UNIQUE et PRIMARY KEY sont informatives et ne sont pas appliquées par le système Snowflake.	CREATE TABLE table_name ( col1 data_type1[,...] ) PARTITION BY column_name CLUSTER BY column_name [, ...] Remarque : BigQuery n'utilise pas les contraintes de table UNIQUE, PRIMARY KEY ou FOREIGN KEY. Pour obtenir une optimisation similaire à celle fournie par ces contraintes lors de l'exécution des requêtes, partitionnez et mettez en cluster vos tables BigQuery. CLUSTER BY accepte jusqu'à quatre colonnes.
CREATE TABLE table_name LIKE original_table_name	Consultez cet exemple pour apprendre à utiliser les tables INFORMATION_SCHEMA pour copier les noms de colonnes, les types de données et les contraintes NOT NULL dans une nouvelle table.
CREATE TABLE table_name ( col1 data_type1 ) BACKUP NO Remarque: Dans Snowflake, le paramètre BACKUP NO est spécifié pour "économiser du temps de traitement lors de la création d'instantanés et de la restauration à partir d'instantanés, et pour réduire l'espace de stockage".	L'option de table BACKUP NO n'est pas utilisée ou nécessaire, car BigQuery conserve automatiquement jusqu'à sept jours de versions historiques de toutes vos tables, sans effet sur le temps de traitement ou le stockage facturé.
CREATE TABLE table_name ( col1 data_type1 ) table_attributes où table_attributes sont: [DISTSTYLE {AUTO|EVEN|KEY|ALL}] [DISTKEY (column_name)] [[COMPOUND|INTERLEAVED] SORTKEY (column_name [, ...])]	BigQuery accepte le clustering, ce qui permet de stocker les clés dans un ordre trié.
CREATE TABLE table_name AS SELECT ...	CREATE TABLE table_name AS SELECT ...
CREATE TABLE IF NOT EXISTS table_name ...	CREATE TABLE IF NOT EXISTS table_name ...

BigQuery est également compatible avec l'instruction LDD CREATE OR REPLACE TABLE, qui écrase une table si elle existe déjà.

L'instruction BigQuery CREATE TABLE accepte également les clauses suivantes, qui n'ont pas d'équivalent Snowflake:

• PARTITION BY partition_statement
• CLUSTER BY clustering_column_list
• OPTIONS (table_options_list)

Pour en savoir plus sur CREATE TABLE dans BigQuery, consultez les exemples d'instructions CREATE TABLE dans la documentation LDD.

Instruction ALTER TABLE

Cette section utilise les commandes de CLI BigQuery correspondant aux commandes Snowflake pour traiter les différences concernant les instructions ALTER pour les tables.

Snowflake	BigQuery
ALTER TABLE [ IF EXISTS ] <name> RENAME TO <new_name>	ALTER TABLE [IF EXISTS] <name> SET OPTIONS (friendly_name="<new_name>")
ALTER TABLE <name> SWAP WITH <target_db_name>	Échanger des tables n'est pas compatible avec BigQuery.
ALTER TABLE <name> SET [DEFAULT_DDL_COLLATION = '<value>']	La gestion du classement des données dans les tables n'est pas disponible dans BigQuery.
ALTER TABLE <name> SET [DATA_RETENTION_TIME_IN_DAYS = <num>]	ALTER TABLE [IF EXISTS] <name> SET OPTIONS (expiration_timestamp=<timestamp>)
ALTER TABLE <name> SET COMMENT = '<string_literal>'	ALTER TABLE [IF EXISTS] <name> SET OPTIONS (description='<string_literal>')

En outre, Snowflake fournit des options de clustering, de colonne et de contrainte pour modifier les tables non compatibles avec BigQuery.

Instructions DROP TABLE et UNDROP TABLE

Cette section utilise la commande BigQuery CLI correspondant à la commande Snowflake pour traiter la différence concernant les instructions DROP et UNDROP.

Snowflake	BigQuery
DROP TABLE [IF EXISTS] <table_name> [CASCADE | RESTRICT] Remarque: Dans Snowflake, le fait de retirer une table ne la supprime pas définitivement du système. Une version de la table retirée est conservée pendant le nombre de jours spécifié par le paramètre DATA_RETENTION_TIME_IN_DAYS de la base de données.	bq rm -r -f -d <dataset_name>.<table_name> Where -r consiste à supprimer tous les objets de l'ensemble de données -f permet d'ignorer la confirmation d'exécution -d indique l'ensemble de données Remarque: Dans BigQuery, la suppression d'une table n'est pas permanente, mais un instantané n'est actuellement conservé que pendant sept jours.
UNDROP TABLE <table_name>	bq cp \ <dataset_name>.<table_name>@<unix_timestamp> <dataset_name>.<new_table_name> Remarque: Dans BigQuery, vous devez d'abord déterminer un horodatage UNIX (en millisecondes) correspondant à la période d'existence de la table. Ensuite, copiez la table à cet horodatage dans une nouvelle table. La nouvelle table doit avoir un nom différent de celui de la table supprimée.

Instruction CREATE EXTERNAL TABLE

BigQuery permet de créer des tables externes permanentes et temporaires, et d'interroger des données directement à partir de :

• Bigtable
• Cloud Storage
• Google Drive
• Cloud SQL (version bêta)

Snowflake permet de créer une table externe permanente qui, lorsqu'elle est interrogée, lit les données d'un ensemble d'un ou de plusieurs fichiers dans une étape externe spécifiée.

Cette section utilise la commande CLI BigQuery correspondant à la commande Snowflake pour traiter les différences concernant l'instruction CREATE EXTERNAL TABLE.

Snowflake	BigQuery
CREATE [OR REPLACE] EXTERNAL TABLE table ((<col_name> <col_type> AS <expr> ) | (<part_col_name> <col_type> AS <part_expr>)[ inlineConstraint ] [ , ... ] ) LOCATION = externalStage FILE_FORMAT = ({FORMAT_NAME='<file_format_name>' |TYPE=source_format [formatTypeOptions]}) Where: externalStage = @[namespace.]ext_stage_name[/path] Remarque: Snowflake permet de préparer les fichiers contenant des données à lire et de spécifier les options de type de format pour les tables externes. Les types de formats Snowflake : CSV, JSON, AVRO, PARQUET et ORC sont tous compatibles avec BigQuery, à l'exception du type XML.	[1] bq mk \ --external_table_definition=definition_file \ dataset.table OR [2] bq mk \ --external_table_definition=schema_file@source_format={Cloud Storage URI | drive_URI} \ dataset.table OR [3] bq mk \ --external_table_definition=schema@source_format = {Cloud Storage URI | drive_URI} \ dataset.table Remarque: BigQuery permet de créer une table permanente associée à votre source de données à l'aide d'un fichier de définition de table [1], d'un fichier de schéma JSON [2] ou d'une définition de schéma en ligne [3]. La préparation des fichiers à la lecture et la spécification des options de type de format n'est pas acceptée dans BigQuery.
CREATE [OR REPLACE] EXTERNAL TABLE [IF EXISTS] <table_name> ((<col_name> <col_type> AS <expr> ) [ , ... ] ) [PARTITION BY (<identifier>, ...)] LOCATION = externalStage [REFRESH_ON_CREATE = {TRUE|FALSE}] [AUTO_REFRESH = {TRUE|FALSE}] [PATTERN = '<regex_pattern>'] FILE_FORMAT = ({FORMAT_NAME = '<file_format_name>' | TYPE = { CSV | JSON | AVRO | ORC | PARQUET} [ formatTypeOptions]}) [COPY GRANTS] [COMMENT = '<string_literal>']	bq mk \ --external_table_definition=definition_file \ dataset.table Remarque: BigQuery n'est actuellement compatible avec aucune des options de paramètres facultatives fournies par Snowflake pour la création de tables externes. Pour le partitionnement, BigQuery permet d'utiliser la pseudo-colonne _FILE_NAME pour créer des tables/vues partitionnées venant en surcouche des tables externes. Pour en savoir plus, consultez la section Interroger la pseudocolonne _FILE_NAME.

De plus, BigQuery est également compatible avec l'interrogation des données partitionnées en externe aux formats AVRO, PARQUET, ORC, JSON et CSV stockées sur Google Cloud Storage à l'aide d'une configuration de partitionnement Hive par défaut.

Instruction CREATE VIEW

Le tableau suivant présente les équivalences entre Snowflake et BigQuery pour l'instruction CREATE VIEW.

Snowflake	BigQuery
CREATE VIEW view_name AS SELECT ...	CREATE VIEW view_name AS SELECT ...
CREATE OR REPLACE VIEW view_name AS SELECT ...	CREATE OR REPLACE VIEW view_name AS SELECT ...
CREATE VIEW view_name (column_name, ...) AS SELECT ...	CREATE VIEW view_name AS SELECT ...
Non compatible	CREATE VIEW IF NOT EXISTS view_name OPTIONS(view_option_list) AS SELECT ...
CREATE VIEW view_name AS SELECT ... WITH NO SCHEMA BINDING	Dans BigQuery, tous les objets référencés doivent déjà exister pour créer une vue. BigQuery vous permet d'interroger des sources de données externes.

Instruction CREATE SEQUENCE

Les séquences ne sont pas utilisées dans BigQuery. Pour ce faire, vous pouvez utiliser le traitement par le lot suivant. Pour en savoir plus sur les clés de substitution et les dimensions à évolution lente, consultez les guides suivants:

• Clés de substitution BigQuery
• BigQuery et clés de substitution : une approche pratique

INSERT INTO dataset.table SELECT *, ROW_NUMBER() OVER () AS id FROM dataset.table

Chargement et déchargement de données LDD

Snowflake accepte le chargement et le déchargement de données via des commandes de gestion d'étape, de format de fichier et de canalisation. BigQuery fournit également plusieurs options telles que le chargement bq, le service de transfert de données BigQuery, l'extraction bq, etc. Cette section met en évidence les différences d'utilisation de ces méthodologies pour le chargement et le déchargement des données.

Compte et session LDD

Les concepts de compte et de session de Snowflake ne sont pas compatibles avec BigQuery. BigQuery permet la gestion des comptes via Cloud IAM à tous les niveaux. De plus, les transactions multi-instructions ne sont pas encore disponibles dans BigQuery.

Fonctions définies par l'utilisateur (User-defined functions, UDF)

Les fonctions définies par l'utilisateur (UDF) vous permettent de créer des fonctions pour des opérations personnalisées. Ces fonctions acceptent des colonnes d'entrée, effectuent des actions et renvoient le résultat de ces actions sous la forme d'une valeur.

Snowflake et BigQuery sont tous deux compatibles avec les fonctions définies par l'utilisateur à l'aide d'expressions SQL et de code JavaScript.

Vous trouverez une bibliothèque des fonctions définies par l'utilisateur courantes BigQuery dans le dépôt GitHub de GoogleCloudPlatform/bigquery-utils/.

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 actuellement 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 currently 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 currently 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 currently 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 currently 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 actuellement 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 le 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 actuellement 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 encore 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