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.

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 :

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 (").

BigQuery accepte les expressions suivantes dans les instructions SELECT, qui n'ont pas d'équivalent Snowflake:

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:

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 et GROUP BY ROLLUP.

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
BigQuery ne dispose pas d'une alternative directe compatible avec GROUP BY GROUPING SETS de Snowflake.

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
BigQuery n'est pas compatible avec une alternative directe à GROUP BY CUBE de Snowflake.

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 :

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_ADD(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:

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:

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:

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:

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:

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 Fonction définie par l'utilisateur personnalisée.
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).

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

)


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


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:

Pour en savoir plus sur l'instruction CREATE TABLE dans BigQuery, consultez les exemples d'instructions CREATE BigQuery dans la documentation sur le LMD.

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 :

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 sur les tables externes. Pour en savoir plus, consultez la section Interroger la pseudo-colonne _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:

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: Utiliser des guillemets simples ou 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écifiez le nom du projet 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:

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