Guia de tradução de SQL do Snowflake

Neste documento, detalhamos as semelhanças e diferenças de sintaxe de SQL entre o Snowflake e o BigQuery para acelerar o planejamento e a execução da migração do armazenamento de dados corporativos (EDW, na sigla em inglês) para o BigQuery. O armazenamento de dados do Snowflake foi projetado para funcionar com a sintaxe de SQL específica do Snowflake. Os scripts criados para o Snowflake talvez precisem ser alterados antes de serem usados no BigQuery, porque os dialetos de SQL variam entre os serviços. Use a tradução do SQL em lote para migrar os scripts SQL em massa ou a tradução interativa do SQL para traduzir consultas ad-hoc. O SQL do Snowflake é compatível com as duas ferramentas da prévia.

Observação: em alguns casos, não há nenhum mapeamento direto entre um elemento SQL do Snowflake e o BigQuery. No entanto, na maioria dos casos, é possível conseguir a mesma funcionalidade do Snowflake no BigQuery usando outras alternativas, como mostrado nos exemplos deste documento.

Tipos de dados

Esta seção mostra os equivalentes entre os tipos de dados do Snowflake e do BigQuery.

Snowflake	BigQuery	Observações
NUMBER/ DECIMAL/NUMERIC	NUMERIC	O tipo de dados NUMBER do Snowflake aceita 38 dígitos de precisão e 37 dígitos de escala. A precisão e a escala podem ser especificadas de acordo com o usuário. O BigQuery é compatível com NUMERIC e BIGNUMERIC com precisão e escala especificadas opcionalmente dentro de determinados limites.
INT/INTEGER	BIGNUMERIC	INT/INTEGER e todos os outros tipos de dados semelhantes a INT, como BIGINT, TINYINT, SMALLINT, BYTEINT, representa um alias para o tipo de dados NUMBER em que a precisão e a escala não podem ser especificadas e são sempre NUMBER(38, 0)
BIGINT	BIGNUMERIC
SMALLINT	BIGNUMERIC
TINYINT	BIGNUMERIC
BYTEINT	BIGNUMERIC
FLOAT/ FLOAT4/ FLOAT8	FLOAT64	O tipo de dados FLOAT do Snowflake estabelece "NaN" como > X, em que X é qualquer valor FLOAT diferente de "NaN". O tipo de dados FLOAT do BigQuery estabelece "NaN" como < X, em que X é qualquer valor FLOAT diferente de "NaN".
DOUBLE/ DOUBLE PRECISION/ REAL	FLOAT64	O tipo de dados DOUBLE do Snowflake é equivalente ao tipo FLOAT do Snowflake, mas geralmente é exibido incorretamente como FLOAT. Ele é armazenado corretamente como DOUBLE.
VARCHAR	STRING	O tipo de dados VARCHAR do Snowflake tem um tamanho máximo de 16 MB, não compactado. Se o tamanho não estiver especificado, o padrão é o tamanho máximo. O tipo de dados STRING do BigQuery é armazenado como Unicode codificado em UTF-8 de tamanho variável. O tamanho máximo é de 16.000 caracteres.
CHAR/CHARACTER	STRING	O tipo de dados CHAR do Snowflake tem um tamanho máximo de 1.
STRING/TEXT	STRING	O tipo de dados STRING do Snowflake é equivalente ao VARCHAR do Snowflake.
BINARY	BYTES
VARBINARY	BYTES
BOOLEAN	BOOL	O tipo de dados BOOL do BigQuery só aceita TRUE/FALSE, ao contrário do tipo de dados BOOL do Snowflake, que aceita TRUE/FALSE/NULL.
DATE	DATE	O tipo DATE do Snowflake aceita os formatos de data mais comuns, ao contrário do tipo DATE do BigQuery, que aceita apenas datas no formato YYYY-[M]M-[D]D.
TIME	TIME	O tipo TIME do Snowflake aceita de 0 a 9 nanossegundos de precisão, enquanto o tipo TIME do BigQuery aceita de 0 a 6 nanossegundos de precisão.
TIMESTAMP	DATETIME	TIMESTAMP é um alias configurável pelo usuário que tem como padrão TIMESTAMP_NTZ, mapeado para DATETIME no BigQuery.
TIMESTAMP_LTZ	TIMESTAMP
TIMESTAMP_NTZ/DATETIME	DATETIME
TIMESTAMP_TZ	TIMESTAMP
OBJECT	JSON	O tipo OBJECT do Snowflake não aceita valores explicitamente especificados. Os valores são do tipo VARIANT.
VARIANT	JSON	O tipo OBJECT do Snowflake não aceita valores explicitamente especificados. Os valores são do tipo VARIANT.
ARRAY	ARRAY<JSON>	O tipo ARRAY do Snowflake aceita apenas os tipos VARIANT, enquanto o tipo ARRAY no BigQuery aceita todos os tipos de dados, exceto uma matriz em si.

O BigQuery também tem os seguintes tipos de dados que não têm um análogo direto do Snowflake:

• DATETIME
• GEOGRAPHY

Sintaxe e operadores de consulta

Nesta seção, mostramos as diferenças de sintaxe de consulta entre o Snowflake e o BigQuery.

Instrução SELECT

A maioria das instruções SELECT do Snowflake é compatível com o BigQuery. A tabela a seguir mostra uma lista de pequenas diferenças.

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 Observação: o Snowflake é compatível com a criação e a indicação de um alias na mesma instrução 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)

Por padrão, os aliases e identificadores do Snowflake não diferenciam maiúsculas de minúsculas. Para preservar a capitalização, coloque aliases e identificadores entre aspas duplas (").

O BigQuery aceita as seguintes expressões em instruções SELECT, que não têm um equivalente no Snowflake:

• EXCEPT
• REPLACE

Cláusula FROM

Uma cláusula FROM em uma consulta especifica as tabelas, visualizações, subconsultas ou funções de tabela possíveis para uma instrução SELECT. Todas essas referências de tabela são compatíveis com o BigQuery.

A tabela a seguir mostra uma lista de pequenas diferenças.

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 Observação: o BigQuery não tem uma alternativa direta ao processo do Snowflake ANTES de usar um ID de instrução. O valor do timestamp não pode ser mais de 7 dias antes do carimbo de data/hora atual.
@[namespace]<stage_name>[/path]		O BigQuery não oferece suporte ao conceito de arquivos preparados.
SELECT* FROM table START WITH predicate CONNECT BY [PRIOR] col1 = [PRIOR] col2 [, ...] ...		O BigQuery não oferece uma alternativa direta à CONNECT BY do Snowflake.

As tabelas do BigQuery podem ser indicadas na cláusula FROM usando:

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

O BigQuery também aceita referências a outras tabelas:

• Versões anteriores de definição e de linhas da tabela usando FOR SYSTEM_TIME AS OF.
• Caminhos de campo ou qualquer caminho que determine um campo dentro de um tipo de dados, ou seja, um STRUCT.
• Matrizes planas.

Cláusula WHERE

A cláusula WHERE do Snowflake e a cláusula WHERE do BigQuery são idênticas, exceto o seguinte:

Snowflake		BigQuery
SELECT col1, col2 FROM table1, table2 WHERE col1 = col2(+)		SELECT col1, col2 FROM table1 INNER JOIN table2 ON col1 = col2 Observação: o BigQuery não oferece suporte à sintaxe (+) para JOINs.

Tipos JOIN

Tanto o Snowflake quanto o BigQuery são compatíveis com os seguintes tipos de junção:

• [INNER] JOIN
• LEFT [OUTER] JOIN
• RIGHT [OUTER] JOIN
• FULL [OUTER] JOIN
• CROSS JOIN e a equivalente comma cross join implícita

Tanto o Snowflake quanto o BigQuery são compatíveis com as cláusulas ON e USING.

A tabela a seguir mostra uma lista de pequenas diferenças.

Snowflake		BigQuery
SELECT col1 FROM table1 NATURAL JOIN table2		SELECT col1 FROM table1 INNER JOIN table2 USING (col1, col2 [, ...]) Observação: no BigQuery, as cláusulas JOIN exigem uma condição JOIN, a menos que seja uma CROSS JOIN ou que uma das tabelas unidas seja um campo em um tipo de dados ou matriz.
SELECT ... FROM table1 AS t1, LATERAL ( SELECT* FROM table2 AS t2 WHERE t1.col = t2.col ) Observação: ao contrário da saída de uma junção não lateral, a saída de uma junção lateral inclui apenas as linhas geradas na visualização in-line. As linhas do lado esquerdo não precisam ser unidas ao lado direito, porque já foram consideradas ao serem passadas para a visualização in-line.		SELECT ... FROM table1 as t1 LEFT JOIN table2 as t2 ON t1.col = t2.col Observação: o BigQuery não é compatível com uma alternativa direta para LATERAL JOINs.

Cláusula WITH

Uma cláusula WITH do BigQuery contém uma ou mais subconsultas nomeadas que são executadas toda vez que uma instrução SELECT subsequente faz referência a elas. As cláusulas WITH do Snowflake se comportam da mesma forma que as do BigQuery, com a exceção de que o BigQuery não é compatível com WITH RECURSIVE.

Cláusula GROUP BY

As cláusulas GROUP BY do Snowflake são compatíveis com GROUP BY, GROUP BY ROLLUP, GROUP BY GROUPING SETS e GROUP BY CUBE, com cláusulas GROUP BY do BigQuery GROUP BY e GROUP BY ROLLUP.

HAVING do Snowflake e HAVING do BigQuery são equivalentes. HAVING ocorre após GROUP BY e de agregação e antes de 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) Observação: o Snowflake permite até 128 conjuntos de agrupamento no mesmo bloco de consulta.		O BigQuery não oferece uma alternativa direta à GROUP BY GROUPING SETS do Snowflake.
SELECT col1 as one, col2 as two FROM table GROUP BY CUBE (one,2) Observação: o Snowflake permite até 7 elementos (128 conjuntos de agrupamento) em cada cubo.		O BigQuery não oferece uma alternativa direta à GROUP BY CUBE do Snowflake.

Cláusula ORDER BY

Há algumas pequenas diferenças entre cláusulas ORDER BY do Snowflake e cláusulas ORDER BY do BigQuery.

Snowflake		BigQuery
No Snowflake, os NULLs são classificados por último, por padrão (ordem crescente).		Já no BigQuery, os NULLS vêm primeiro na classificação, por padrão (ordem crescente).
É possível especificar se os valores de NULL precisam ser os primeiros ou os últimos usando NULLS FIRST ou NULLS LAST, respectivamente.		Não há equivalente para especificar se os valores NULL precisam ser os primeiros ou os últimos no BigQuery.

Cláusula LIMIT/FETCH

A cláusula LIMIT/FETCH do Snowflake restringe o número máximo de linhas retornadas por uma instrução ou subconsulta. LIMIT (sintaxe Postgres) e FETCH (sintaxe ANSI) produzem o mesmo resultado.

No Snowflake e no BigQuery, aplicar uma cláusula LIMIT a uma consulta não afeta a quantidade de dados lidos.

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] Observação: NULL, string vazia ('') e valores $$$$ são aceitos e são tratados como "ilimitados". O uso principal é para conectores e drivers.		SELECT col1, col2 FROM table ORDER BY col1 LIMIT count OFFSET start Observação: o BigQuery não é compatível com FETCH. LIMIT substitui FETCH. Observação: no BigQuery, OFFSET precisa ser usado com um LIMIT count. Defina o valor count INT64 como o mínimo de linhas ordenadas necessárias para um melhor desempenho. Ordenar todas as linhas de resultado desnecessariamente resulta em um desempenho pior da execução da consulta.

Cláusula QUALIFY

A cláusula QUALIFY do Snowflake permite filtrar resultados de funções de janela de forma semelhante ao que o HAVING faz com funções agregadas e cláusulas GROUP BY.

Snowflake		BigQuery
SELECT col1, col2 FROM table QUALIFY ROW_NUMBER() OVER (PARTITION BY col1 ORDER BY col2) = 1;		A cláusula QUALIFY do Snowflake com uma função analítica como ROW_NUMBER() e COUNT() e com OVER PARTITION BY é expressa no BigQuery como uma cláusula WHERE de uma subconsulta que contém o valor da análise. Como usar ROW_NUMBER(): SELECT col1, col2 FROM ( SELECT col1, col2 ROW NUMBER() OVER (PARTITION BY col1 ORDER by col2) RN FROM table ) WHERE RN = 1; Como usar ARRAY_AGG(), que é compatível com partições maiores: SELECT result.* FROM ( SELECT ARRAY_AGG(table ORDER BY table.col2 DESC LIMIT 1) [OFFSET(0)] FROM table GROUP BY col1 ) AS result;

Funções

As seções a seguir listam as funções do Snowflake e os equivalentes do BigQuery.

Funções de agregação

A tabela a seguir mostra os mapeamentos entre as funções de agregação, agregação analítica e agregação aproximada do Snowflake com os equivalentes do BigQuery.

Snowflake	BigQuery
ANY_VALUE([DISTINCT] expression) [OVER ...] Observação: DISTINCT não tem efeito algum	ANY_VALUE(expression) [OVER ...]
APPROX_COUNT_DISTINCT([DISTINCT] expression) [OVER ...] Observação: DISTINCT não tem efeito algum	APPROX_COUNT_DISTINCT(expression) Observação: o BigQuery não é compatível com APPROX_COUNT_DISTINCT com funções de janela.
APPROX_PERCENTILE(expression, percentile) [OVER ...] Observação: o Snowflake não tem a opção RESPECT NULLS	APPROX_QUANTILES([DISTINCT] expression,100) [OFFSET((CAST(TRUNC(percentile * 100) as INT64))] Observação: o BigQuery não é compatível com APPROX_QUANTILES com funções de janela.
APPROX_PERCENTILE_ACCUMULATE (expression)	O BigQuery não tem a capacidade de armazenar o estado intermediário ao prever valores aproximados.
APPROX_PERCENTILE_COMBINE(state)	O BigQuery não tem a capacidade de armazenar o estado intermediário ao prever valores aproximados.
APPROX_PERCENTILE_ESTIMATE(state, percentile)	O BigQuery não tem a capacidade de armazenar o estado intermediário ao prever valores aproximados.
APPROX_TOP_K(expression, [number [counters]] Observação: se nenhum parâmetro numérico for especificado, o padrão é 1. Os contadores devem ser significativamente maiores que o número.	APPROX_TOP_COUNT(expression, number) Observação: o BigQuery não é compatível com APPROX_TOP_COUNT com funções de janela.
APPROX_TOP_K_ACCUMULATE(expression, counters)	O BigQuery não tem a capacidade de armazenar o estado intermediário ao prever valores aproximados.
APPROX_TOP_K_COMBINE(state, [counters])	O BigQuery não tem a capacidade de armazenar o estado intermediário ao prever valores aproximados.
APPROX_TOP_K_ESTIMATE(state, [k])	O BigQuery não tem a capacidade de armazenar o estado intermediário ao prever valores aproximados.
APPROXIMATE_JACCARD_INDEX([DISTINCT] expression)	Use uma UDF personalizada para implementar MINHASH com funções hash k distintas. Outra abordagem para reduzir a variação em MINHASH é manter k dos valores mínimos de uma função hash. Nesse caso, o índice de Jaccard pode ser aproximado da seguinte maneira: 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)	É sinônimo de APPROXIMATE_JACCARD_INDEX e pode ser implementado da mesma forma.
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 ...] Observação: o AVG do BigQuery não realiza a transmissão automática em STRINGs.
BITAND_AGG(expression) [OVER ...]	BIT_AND(expression) [OVER ...] Observação: o BigQuery não transmite implicitamente colunas de caracteres/textos para o INTEGER mais próximo.
BITOR_AGG(expression) [OVER ...]	BIT_OR(expression) [OVER ...] Observação: o BigQuery não transmite implicitamente colunas de caracteres/textos para o INTEGER mais próximo.
BITXOR_AGG([DISTINCT] expression) [OVER ...]	BIT_XOR([DISTINCT] expression) [OVER ...] Observação: o BigQuery não transmite implicitamente colunas de caracteres/textos para o INTEGER mais próximo.
BOOLAND_AGG(expression) [OVER ...] Observação: o Snowflake permite que valores numéricos, decimais e de ponto flutuante sejam tratados como TRUE, se não forem zero.	LOGICAL_AND(expression) [OVER ...]
BOOLOR_AGG(expression) [OVER ...] Observação: o Snowflake permite que valores numéricos, decimais e de ponto flutuante sejam tratados como TRUE, se não forem zero.	LOGICAL_OR(expression) [OVER ...]
BOOLXOR_AGG(expression) [OVER ([PARTITION BY <partition_expr> ]) Observação: o Snowflake permite que valores numéricos, decimais e de ponto flutuante sejam tratados como TRUE, se não forem zero.	Para expressão numérica: SELECT CASE COUNT(*) WHEN 1 THEN TRUE WHEN 0 THEN NULL ELSE FALSE END AS BOOLXOR_AGG FROM T WHERE expression != 0 Para usar OVER, execute o seguinte (exemplo booleano fornecido): 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...])	O BigQuery não oferece uma alternativa direta à GROUPING do Snowflake. Disponível por meio de uma função definida pelo usuário.
GROUPING_ID(expression1, [,expression2...])	O BigQuery não oferece uma alternativa direta à GROUPING_ID do Snowflake. Disponível por meio de uma função definida pelo usuário.
HASH_AGG([DISTINCT] expression1, [,expression2]) [OVER ...]	SELECIONAR BIT_XOR( FARM_FINGERPRINT( TO_JSON_STRING(t))) [OVER] DE t
SELECT HLL([DISTINCT] expression1, [,expression2]) [OVER ...] Observação: o Snowflake não permite especificar a precisão.	SELECT HLL_COUNT.EXTRACT(sketch) FROM ( SELECT HLL_COUNT.INIT(expression) AS sketch FROM table ) Observação: o BigQuery não é compatível com HLL_COUNT… com funções de janela. Um usuário não pode incluir várias expressões em uma única função HLL_COUNT....
HLL_ACCUMULATE([DISTINCT] expression) Observação: o Snowflake não permite especificar a precisão.	HLL_COUNT.INIT(expression [, precision])
HLL_COMBINE([DISTINCT] state)	HLL_COUNT.MERGE_PARTIAL(sketch)
HLL_ESTIMATE(state)	HLL_COUNT.EXTRACT(sketch)
HLL_EXPORT(binary)	O BigQuery não oferece uma alternativa direta à HLL_EXPORT do Snowflake.
HLL_IMPORT(object)	O BigQuery não oferece uma alternativa direta à HLL_IMPORT do Snowflake.
KURTOSIS(expression) [OVER ...]	O BigQuery não oferece uma alternativa direta à KURTOSIS do Snowflake.
LISTAGG( [DISTINCT] aggregate_expression [, delimiter] ) [OVER ...]	STRING_AGG( [DISTINCT] aggregate_expression [, delimiter] ) [OVER ...]
MEDIAN(expression) [OVER ...] Observação: o Snowflake não tem a capacidade de IGNORE|RESPECT NULLS e LIMIT diretamente em 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)	É possível usar uma UDF personalizada para implementar MINHASH com funções hash k distintas. Outra abordagem para reduzir a variação em MINHASH é manter k dos valores mínimos de uma função hash: 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 ...]	Use TO_JSON_STRING para converter um valor em uma string formatada em 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)	O BigQuery não oferece uma alternativa direta à SKEW do 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 ...] Observação: o Snowflake tem a capacidade de transmitir VARCHARs para valores de ponto flutuante.	VAR_POP([DISTINCT] expression) [OVER ...]
VARIANCE_POP([DISTINCT] expression) [OVER ...] Observação: o Snowflake tem a capacidade de transmitir VARCHARs para valores de ponto flutuante.	VAR_POP([DISTINCT] expression) [OVER ...]
VAR_SAMP([DISTINCT] expression) [OVER ...] Observação: o Snowflake tem a capacidade de transmitir VARCHARs para valores de ponto flutuante.	VAR_SAMP([DISTINCT] expression) [OVER ...]
VARIANCE([DISTINCT] expression) [OVER ...] Observação: o Snowflake tem a capacidade de transmitir VARCHARs para valores de ponto flutuante.	VARIANCE([DISTINCT] expression) [OVER ...]

O BigQuery também oferece as seguintes funções de agregação, agregação analítica e agregação aproximada, que não têm análogos diretos no Snowflake:

• COUNTIF
• ARRAY_CONCAT_AGG
• HLL_COUNT.MERGE

Funções de expressão bit a bit

A tabela a seguir mostra os mapeamentos entre funções de expressão bit a bit comuns do Snowflake e os equivalentes do BigQuery.

Se o tipo de dados de uma expressão não for INTEGER, o Snowflake tentará transmitir para INTEGER. No entanto, o BigQuery não tenta transmitir para 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) Observação: o Snowflake não é compatível com DISTINCT..	BIT_XOR([DISTINCT] x) FROM UNNEST([expression1, expression2]) AS x expression ^ expression

Funções de expressão condicional

A tabela a seguir mostra os mapeamentos entre expressões condicionais comuns do Snowflake com os equivalentes do BigQuery.

Snowflake	BigQuery
expression [ NOT ] BETWEEN lower AND upper	(expression >= lower AND expression <= upper)
BOOLAND(expression1, expression2) Observação: o Snowflake permite que valores numéricos, decimais e de ponto flutuante sejam tratados como TRUE, se não forem zero.	LOGICAL_AND(x) FROM UNNEST([expression1, expression2]) AS x expression1 AND expression2
BOOLNOT(expression1) Observação: o Snowflake permite que valores numéricos, decimais e de ponto flutuante sejam tratados como TRUE, se não forem zero.	NOT expression
BOOLOR Observação: o Snowflake permite que valores numéricos, decimais e de ponto flutuante sejam tratados como TRUE se não forem zero.	LOGICAL_OR(x) FROM UNNEST([expression1, expression2]) AS x expression1 OR expression2
BOOLXOR Observação: o Snowflake permite que valores numéricos, decimais e de ponto flutuante sejam tratados como TRUE se não forem zero.	O BigQuery não é compatível com uma alternativa direta ao BOOLXOR. do 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, [,...]) Observação: o Snowflake requer pelo menos duas expressões. O BigQuery só precisa de uma.	COALESCE(expr1, [,...])
DECODE(expression, search1, result1, [search2, result2...] [,default])	CASE [expression] WHEN condition1 THEN result1 [WHEN condition2 THEN result2] [...] [ELSE result3] END Observação: o BigQuery oferece suporte a subconsultas em instruções de condição. Isso pode ser usado para reproduzir o DECODE do Snowflake. O usuário precisa usar IS NULL em vez de = NULL para corresponder expressões de seleção NULL com expressões de pesquisa NULL.
EQUAL_NULL(expression1, expression2)	O BigQuery não oferece uma alternativa direta à EQUAL_NULL. do 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	O BigQuery não oferece uma alternativa direta à IS [ NOT ] DISTINCT FROM. do Snowflake
expression IS [ NOT ] NULL	expression IS [ NOT ] NULL
IS_NULL_VALUE(variant_expr)	O BigQuery não oferece suporte aos tipos de dados 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) Observação: o BigQuery não oferece uma alternativa direta às funções REGR... do Snowflake.
REGR_VALY(expr1,expr2)	IF(expr2 IS NULL, NULL, expr1) Observação: o BigQuery não oferece uma alternativa direta às funções REGR... do Snowflake.
ZEROIFNULL(expression)	IFNULL(expression,0)

Funções contextuais

A tabela a seguir mostra os mapeamentos entre funções de contexto comuns do Snowflake e os equivalentes do BigQuery.

Snowflake	BigQuery
CURRENT_ACCOUNT()	SESSION_USER() Observação: não é uma comparação direta. O Snowflake retorna o ID da conta, o BigQuery retorna o endereço de e-mail do usuário.
CURRENT_CLIENT()	Conceito não usado no BigQuery
CURRENT_DATABASE()	SELECT catalog_name FROM INFORMATION_SCHEMA.SCHEMATA Isso retorna uma tabela de nomes de projetos. Não é uma comparação direta.
CURRENT_DATE[()] Observação: o Snowflake não aplica "()" após o comando CURRENT_DATE para atender aos padrões ANSI.	CURRENT_DATE([timezone]) Observação: o CURRENT_DATE do BigQuery é compatível com a especificação de fuso horário opcional.
CURRENT_REGION()	SELECT location FROM INFORMATION_SCHEMA.SCHEMATA Observação: o INFORMATION_SCHEMA.SCHEMATA do BigQuery retorna referências de localização mais generalizadas que o CURRENT_REGION() do Snowflake. Não é uma comparação direta.
CURRENT_ROLE()	Conceito não usado no BigQuery
CURRENT_SCHEMA()	SELECT schema_name FROM INFORMATION_SCHEMA.SCHEMATA Isso retorna uma tabela de todos os conjuntos de dados (também chamados de esquemas) disponíveis no projeto ou na região. Não é uma comparação direta.
CURRENT_SCHEMAS()	Conceito não usado no BigQuery
CURRENT_SESSION()	Conceito não usado no BigQuery
CURRENT_STATEMENT()	SELECT query FROM INFORMATION_SCHEMA.JOBS_BY_* Observação: o INFORMATION_SCHEMA.JOBS_BY_* do BigQuery permite pesquisar consultas por tipo de job, tipo de início/término, etc.
CURRENT_TIME[([frac_sec_prec])] Observação: o Snowflake permite a precisão fracionária de segundos, que é opcional. Os valores válidos vão de 0 a 9 nanossegundos. O valor padrão é 9. Para obedecer ao ANSI, isso pode ser chamado sem "()".	CURRENT_TIME()
CURRENT_TIMESTAMP[([frac_sec_prec])] Observação: o Snowflake permite a precisão fracionária de segundos, que é opcional. Os valores válidos vão de 0 a 9 nanossegundos. O valor padrão é 9. Para obedecer ao ANSI, isso pode ser chamado sem "()". Defina TIMEZONE como um parâmetro de sessão.	CURRENT_DATETIME([timezone]) CURRENT_TIMESTAMP() Observação: CURRENT_DATETIME retorna o tipo de dados DATETIME (incompatível com o Snowflake). CURRENT_TIMESTAMP retorna o tipo de dados TIMESTAMP.
CURRENT_TRANSACTION()	SELECT job_id FROM INFORMATION_SCHEMA.JOBS_BY_* Observação: o INFORMATION_SCHEMA.JOBS_BY_* do BigQuery permite pesquisar IDs de job por tipo de job, tipo de início/término, etc.
CURRENT_USER[()] Observação: o Snowflake não aplica "()" após o comando CURRENT_USER para atender aos padrões ANSI.	SESSION_USER() SELECT user_email FROM INFORMATION_SCHEMA.JOBS_BY_* Observação: não é uma comparação direta. Snowflake retorna um nome de usuário, o BigQuery retorna o endereço de e-mail do usuário.
CURRENT_VERSION()	Conceito não usado no BigQuery
CURRENT_WAREHOUSE()	SELECT catalg_name FROM INFORMATION_SCHEMA.SCHEMATA
LAST_QUERY_ID([num])	SELECT job_id FROM INFORMATION_SCHEMA.JOBS_BY_* Observação: o INFORMATION_SCHEMA.JOBS_BY_* do BigQuery permite pesquisar IDs de job por tipo de job, tipo de início/término, etc.
LAST_TRANSACTION()	SELECT job_id FROM INFORMATION_SCHEMA.JOBS_BY_* Observação: o INFORMATION_SCHEMA.JOBS_BY_* do BigQuery permite pesquisar IDs de job por tipo de job, tipo de início/término, etc.
LOCALTIME() Observação: o Snowflake não aplica "()" após o comando LOCALTIME para atender aos padrões ANSI.	CURRENT_TIME()
LOCALTIMESTAMP()	CURRENT_DATETIME([timezone]) CURRENT_TIMESTAMP() Observação: CURRENT_DATETIME retorna o tipo de dados DATETIME (incompatível com o Snowflake). CURRENT_TIMESTAMP retorna o tipo de dados TIMESTAMP.

Funções de conversão

A tabela a seguir mostra os mapeamentos entre funções de conversão comuns do Snowflake com os equivalentes do BigQuery.

Funções que parecem idênticas no Snowflake e no BigQuery podem retornar diferentes tipos de dados.

Snowflake	BigQuery
CAST(expression AS type) expression :: type	CAST(expression AS type)
TO_ARRAY(expression)	[expression] ARRAY(subquery)
TO_BINARY(expression[, format]) Observação: o Snowflake oferece suporte para a conversão HEX, BASE64 e UTF-8. O Snowflake também oferece suporte a TO_BINARY usando o tipo de dados VARIANT. O BigQuery não tem uma alternativa ao tipo de dados VARIANT.	TO_HEX(CAST(expression AS BYTES)) TO_BASE64(CAST(expression AS BYTES)) CAST(expression AS BYTES) Observação: a transmissão STRING padrão do BigQuery usa a codificação UTF-8. O Snowflake não tem opção de suporte à codificação BASE32.
TO_BOOLEAN(expression) Observação: INT64 TRUE: , caso contrário FALSE: 0 STRING TRUE: "true"/"t"/"yes"/"y"/"on"/"1", FALSE: "false"/"f"/"no"/"n"/"off"/"0"	CAST(expression AS BOOL) Observação: INT64 TRUE: , caso contrário FALSE: 0 STRING TRUE: "true", FALSE: "false"
TO_CHAR(expression[, format]) TO_VARCHAR(expression[, format]) Observação: os modelos de formato do Snowflake podem ser encontrados aqui. O BigQuery não tem uma alternativa ao tipo de dados VARIANT.	CAST(expression AS STRING) Observação: a expressão de entrada do BigQuery pode ser formatada por FORMAT_DATE, FORMAT_DATETIME, FORMAT_TIME ou FORMAT_TIMESTAMP.
TO_DATE(expression[, format]) DATE(expression[, format]) Observação: o Snowflake tem a capacidade de converter diretamente os tipos INTEGER para os tipos DATE. Os modelos de formato do Snowflake podem ser encontrados aqui. O BigQuery não tem uma alternativa ao tipo de dados VARIANT.	CAST(expression AS DATE) Observação: a expressão de entrada do BigQuery pode ser formatada por FORMAT, FORMAT_DATETIME ou FORMAT_TIMESTAMP.
TO_DECIMAL(expression[, format] [,precision[, scale]] TO_NUMBER(expression[, format] [,precision[, scale]] TO_NUMERIC(expression[, format] [,precision[, scale]] Observação: os modelos de formato do Snowflake para os tipos de dados DECIMAL, NUMBER e NUMERIC podem ser encontrados aqui. O BigQuery não tem uma alternativa ao tipo de dados VARIANT.	ROUND(CAST(expression AS NUMERIC) , x) Observação: a expressão de entrada do BigQuery pode ser formatada por FORMAT.
TO_DOUBLE(expression[, format]) Observação: os modelos de formato do Snowflake para os tipos de dados DOUBLE podem ser encontrados aqui. O BigQuery não tem uma alternativa ao tipo de dados VARIANT.	CAST(expression AS FLOAT64) Observação: a expressão de entrada do BigQuery pode ser formatada por FORMAT.
TO_JSON(variant_expression)	O BigQuery não tem uma alternativa ao tipo de dados VARIANT do Snowflake.
TO_OBJECT(variant_expression)	O BigQuery não tem uma alternativa ao tipo de dados VARIANT do Snowflake.
TO_TIME(expression[, format]) TIME(expression[, format]) Observação: os modelos de formato do Snowflake para os tipos de dados STRING podem ser encontrados aqui. O BigQuery não tem uma alternativa ao tipo de dados VARIANT.	CAST(expression AS TIME) Observação: o BigQuery não tem uma alternativa ao tipo de dados VARIANT do Snowflake. A expressão de entrada do BigQuery pode ser formatada por 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]) Observação: o BigQuery não tem uma alternativa ao tipo de dados VARIANT.	CAST(expression AS TIMESTAMP) Observação: a expressão de entrada do BigQuery pode ser formatada por FORMAT, FORMAT_DATE, FORMAT_DATETIME e FORMAT_TIME. O fuso horário pode ser incluído ou não por parâmetros FORMAT_TIMESTAMP.
TO_VARIANT(expression)	O BigQuery não tem uma alternativa ao tipo de dados VARIANT do Snowflake.
TO_XML(variant_expression)	O BigQuery não tem uma alternativa ao tipo de dados VARIANT do 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)

O BigQuery também oferece as seguintes funções de conversão, que não têm um análogo direto no Snowflake:

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

Funções de geração de dados

A tabela a seguir mostra os mapeamentos entre funções de geração de dados comuns do Snowflake e os equivalentes do BigQuery.

Snowflake	BigQuery
NORMAL(mean, stddev, gen)	O BigQuery não oferece suporte a uma comparação direta com o NORMAL. do Snowflake.
RANDOM([seed])	IF(RAND()>0.5, CAST(RAND()*POW(10, 18) AS INT64), (-1)*CAST(RAND()*POW(10, 18) AS INT64)) Observação: o BigQuery não aceita a propagação
RANDSTR(length, gen)	O BigQuery não oferece suporte a uma comparação direta com o RANDSTR. do Snowflake.
SEQ1 / SEQ2 / SEQ4 / SEQ8	O BigQuery não oferece suporte a uma comparação direta com o SEQ_. do Snowflake.
UNIFORM(min, max, gen)	CAST(min + RAND()*(max-min) AS INT64) Observação: use UDFs permanentes para criar um equivalente ao UNIFORM do Snowflake. Exemplo aqui.
UUID_STRING([uuid, name]) Observação: o Snowflake retorna 128 bits aleatórios. O Snowflake é compatível com UUIDs das versões 4 (aleatória) e 5 (nomeada).	GENERATE_UUID() Observação: o BigQuery retorna 122 bits aleatórios. O BigQuery é compatível apenas com UUIDs da versão 4.
ZIPF(s, N, gen)	O BigQuery não oferece suporte a uma comparação direta com o ZIPF. do Snowflake.

Funções de data e hora

A tabela a seguir mostra os mapeamentos entre funções de data e hora comuns do Snowflake com os equivalentes do BigQuery. As funções de data e hora do BigQuery são funções de data, funções datetime, funções de hora e funções de carimbo de data/hora.

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 ) ) Observação: o campo source_timezone é sempre UTC no BigQuery.
DATE_FROM_PARTS(year, month, day) Observação: o Snowflake é compatível com datas excedentes e negativas. Por exemplo, DATE_FROM_PARTS(2000, 1 + 24, 1) retorna 1o de janeiro de 2002. Isso não é aceito no BigQuery.	DATE(year, month, day) DATE(timestamp_expression[, timezone]) DATE(datetime_expression)
DATE_PART(part, dateOrTime) Observação: o Snowflake é compatível com os tipos de parte ISO de dia da semana, nanosegundos e segundos/milissegundos/microssegundos/nanossegundos de época. O BigQuery não faz isso. Confira a lista completa de tipos de parte do Snowflake aqui.	EXTRACT(part FROM dateOrTime) Observação: o BigQuery oferece suporte aos tipos de parte de semana (<weekday>), microssegundo e milissegundo. O Snowflake não. Confira a lista completa dos tipos de parte do BigQuery aqui e aqui.
DATE_TRUNC(part, dateOrTime) Observação: o Snowflake é compatível com o tipo de parte de nanossegundos. O BigQuery não faz isso. Confira a lista completa de tipos de parte do Snowflake aqui.	DATE_TRUNC(date, part) DATETIME_TRUNC(datetime, part) TIME_TRUNC(time, part) TIMESTAMP_TRUNC(timestamp, part[, timezone]) Observação: o BigQuery é compatível com os tipos de parte de semana (<weekday>), semana ISO e ano ISO. O Snowflake não.
DATEADD(part, value, dateOrTime)	DATE_ADD(date, INTERVAL value part)
DATEDIFF( part, expression1, expression2 ) Observação: o Snowflake é compatível com o cálculo da diferença entre dois tipos de data, hora e carimbo de data/hora nessa função.	DATE_DIFF( dateExpression1, dateExpression2, part ) DATETIME_DIFF( datetimeExpression1, datetimeExpression2, part ) TIME_DIFF( timeExpression1, timeExpression2, part ) TIMESTAMP_DIFF( timestampExpression1, timestampExpression2, part ) Observação: o BigQuery é compatível com os tipos de parte de semana (<weekday>) e ano ISO.
DAYNAME(dateOrTimestamp)	FORMAT_DATE('%a', date) FORMAT_DATETIME('%a', datetime) FORMAT_TIMESTAMP('%a', timestamp)
EXTRACT(part FROM dateOrTime) Observação: o Snowflake é compatível com os tipos de parte ISO de dia da semana, nanosegundos e segundos/milissegundos/microssegundos/nanossegundos de época. O BigQuery não faz isso. Confira a lista completa de tipos de parte do Snowflake aqui.	EXTRACT(part FROM dateOrTime) Observação: o BigQuery oferece suporte aos tipos de parte de semana (<weekday>), microssegundo e milissegundo. O Snowflake não. Confira a lista completa dos tipos de parte do BigQuery aqui e aqui.
[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) Observação: o dowString talvez precise ser reformatado. Por exemplo, "su" do Snowflake será "SUNDAY" do BigQuery.
PREVIOUS_DAY(dateOrTime, dowString)	DATE_TRUNC( date, WEEK(dowString) ) Observação: o dowString talvez precise ser reformatado. Por exemplo, "su" do Snowflake será "SUNDAY" do BigQuery.
TIME_FROM_PARTS(hour, minute, second[, nanosecond) Observação: o Snowflake é compatível com horas flutuantes. Por exemplo, TIME_FROM_PARTS(0, 100, 0) retorna 01:40:00... Isso não é aceito no BigQuery. O BigQuery não aceita nanossegundos.	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) Observação: o BigQuery não oferece suporte a uma comparação direta e exata com o TIME_SLICE do Snowflake. Use DATETINE_TRUNC, TIME_TRUNC e TIMESTAMP_TRUNC para o tipo de dados apropriado.
TIMEADD(part, value, dateOrTime)	TIME_ADD(time, INTERVAL value part)
TIMEDIFF( part, expression1, expression2, ) Observação: o Snowflake é compatível com o cálculo da diferença entre dois tipos de data, hora e carimbo de data/hora nessa função.	DATE_DIFF( dateExpression1, dateExpression2, part ) DATETIME_DIFF( datetimeExpression1, datetimeExpression2, part ) TIME_DIFF( timeExpression1, timeExpression2, part ) TIMESTAMP_DIFF( timestampExpression1, timestampExpression2, part ) Observação: o BigQuery é compatível com os tipos de parte de semana (<weekday>) e ano ISO.
TIMESTAMP_[LTZ, NTZ, TZ _]FROM_PARTS (year, month, day, hour, second [, nanosecond][, timezone])	TIMESTAMP( string_expression[, timezone] | date_expression[, timezone] | datetime_expression[, timezone] ) Observação: o BigQuery exige que os carimbos de data/hora sejam inseridos como tipos STRING. Exemplo: "2008-12-25 15:30:00"
TIMESTAMPADD(part, value, dateOrTime)	TIMESTAMPADD(timestamp, INTERVAL value part)
TIMESTAMPDIFF( part, expression1, expression2, ) Observação: o Snowflake é compatível com o cálculo da diferença entre dois tipos de data, hora e carimbo de data/hora nessa função.	DATE_DIFF( dateExpression1, dateExpression2, part ) DATETIME_DIFF( datetimeExpression1, datetimeExpression2, part ) TIME_DIFF( timeExpression1, timeExpression2, part ) TIMESTAMP_DIFF( timestampExpression1, timestampExpression2, part ) Observação: o BigQuery é compatível com os tipos de parte de semana (<weekday>) e ano ISO.
TRUNC(dateOrTime, part) Observação: o Snowflake é compatível com o tipo de parte de nanossegundos. O BigQuery não faz isso. Confira a lista completa de tipos de parte do Snowflake aqui.	DATE_TRUNC(date, part) DATETIME_TRUNC(datetime, part) TIME_TRUNC(time, part) TIMESTAMP_TRUNC(timestamp, part[, timezone]) Observação: o BigQuery é compatível com os tipos de parte de semana (<weekday>), semana ISO e ano ISO. O Snowflake não.
[YEAR*, DAY*, WEEK*, MONTH, QUARTER](dateOrTimestamp)	EXTRACT(part FROM timestamp [AT THE ZONE timezone])

O BigQuery também oferece as seguintes funções de data e hora, que não têm um análogo direto no Snowflake:

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

Esquema de informações e funções de tabela

Conceitualmente, o BigQuery não é compatível com muitos esquemas de informações e funções de tabela do Snowflake. O Snowflake oferece o esquema de informações e as funções de tabela a seguir, que não têm um análogo direto no BigQuery:

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

Confira abaixo uma lista de esquemas de informações e funções de tabela associados do BigQuery e do Snowflake.

Snowflake	BigQuery
QUERY_HISTORY QUERY_HISTORY_BY_*	INFORMATION_SCHEMA.JOBS_BY_* Observação: não é uma alternativa direta.
TASK_HISTORY	INFORMATION_SCHEMA.JOBS_BY_* Observação: não é uma alternativa direta.

O BigQuery oferece as seguintes funções de esquema e tabela de informações, que não têm um análogo direto no Snowflake:

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

Funções numéricas

A tabela a seguir mostra os mapeamentos entre funções numéricas comuns do Snowflake e os equivalentes do 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) Observação: o CEIL do BigQuery não tem a capacidade de indicar precisão ou escala. ROUND não permite especificar um arredondamento.
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)	O BigQuery não tem uma alternativa direta à FACTORIAL do Snowflake. Usar uma função definida pelo usuário.
FLOOR(expression [, scale])	FLOOR(expression) Observação: o FLOOR do BigQuery não tem a capacidade de indicar precisão ou escala. ROUND não permite especificar um arredondamento. O TRUNC é usado como equivalente para números positivos, mas não negativos, porque avalia o valor absoluto.
HAVERSINE(lat1, lon1, lat2, lon2)	ST_DISTANCE( ST_GEOGPOINT(lon1, lat1), ST_GEOGPOINT(lon2, lat2) )/1000 Observação: não é uma correspondência exata, mas próxima o suficiente.
LN(expression)	LN(expression)
LOG(base, expression)	LOG(expression [,base]) LOG10(expression) Observação: a base padrão para LOG é 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]) Observação: o valor retornado pelo BigQuery precisa ser menor que a expressão; não pode ser igual a ela.

O BigQuery também oferece as seguintes funções matemáticas, que não têm uma analogia direta no Snowflake:

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

Funções de dados semiestruturados

Snowflake	BigQuery
ARRAY_APPEND	Função definida pelo usuário personalizada
ARRAY_CAT	ARRAY_CONCAT
ARRAY_COMPACT	Função definida pelo usuário personalizada
ARRAY_CONSTRUCT	[ ]
ARRAY_CONSTRUCT_COMPACT	Função definida pelo usuário personalizada
ARRAY_CONTAINS	Função definida pelo usuário personalizada
ARRAY_INSERT	Função definida pelo usuário personalizada
ARRAY_INTERSECTION	Função definida pelo usuário personalizada
ARRAY_POSITION	Função definida pelo usuário personalizada
ARRAY_PREPEND	Função definida pelo usuário personalizada
ARRAY_SIZE	ARRAY_LENGTH
ARRAY_SLICE	Função definida pelo usuário personalizada
ARRAY_TO_STRING	ARRAY_TO_STRING
ARRAYS_OVERLAP	Função definida pelo usuário personalizada
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	Função definida pelo usuário personalizada
CHECK_XML	Função definida pelo usuário personalizada
FLATTEN	UNNEST
GET	Função definida pelo usuário personalizada
GET_IGNORE_CASE	Função definida pelo usuário personalizada
GET_PATH , :	Função definida pelo usuário personalizada
IS_<object_type>	Função definida pelo usuário personalizada
IS_ARRAY	Função definida pelo usuário personalizada
IS_BINARY	Função definida pelo usuário personalizada
IS_BOOLEAN	Função definida pelo usuário personalizada
IS_CHAR , IS_VARCHAR	Função definida pelo usuário personalizada
IS_DATE , IS_DATE_VALUE	Função definida pelo usuário personalizada
IS_DECIMAL	Função definida pelo usuário personalizada
IS_DOUBLE , IS_REAL	Função definida pelo usuário personalizada
IS_INTEGER	Função definida pelo usuário personalizada
IS_OBJECT	Função definida pelo usuário personalizada
IS_TIME	Função definida pelo usuário personalizada
IS_TIMESTAMP_*	Função definida pelo usuário personalizada
OBJECT_CONSTRUCT	Função definida pelo usuário personalizada
OBJECT_DELETE	Função definida pelo usuário personalizada
OBJECT_INSERT	Função definida pelo usuário personalizada
PARSE_JSON	JSON_EXTRACT
PARSE_XML	Função definida pelo usuário personalizada
STRIP_NULL_VALUE	Função definida pelo usuário personalizada
STRTOK_TO_ARRAY	SPLIT
TRY_PARSE_JSON	Função definida pelo usuário personalizada
TYPEOF	Função definida pelo usuário personalizada
XMLGET	Função definida pelo usuário personalizada

Funções de string e binárias

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	Função definida pelo usuário personalizada
COLLATION	Função definida pelo usuário personalizada
COMPRESS	Função definida pelo usuário personalizada
CONCAT(string1, string2)	CONCAT(string1, string2) Observação: a CONCAT(...) do BigQuery é compatível com a concatenação de qualquer número de strings.
CONTAINS	Função definida pelo usuário personalizada
DECOMPRESS_BINARY	Função definida pelo usuário personalizada
DECOMPRESS_STRING	Função definida pelo usuário personalizada
EDITDISTANCE	Função definida pelo usuário personalizada
ENDSWITH	Função definida pelo usuário personalizada
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	Função definida pelo usuário personalizada
ILIKE ANY	Função definida pelo usuário personalizada
INITCAP	INITCAP
INSERT	Função definida pelo usuário personalizada
LEFT	Função definida pelo usuário
LENGTH	LENGTH(expression)
LIKE	LIKE
LIKE ALL	Função definida pelo usuário personalizada
LIKE ANY	Função definida pelo usuário personalizada
LOWER	LOWER(string)
LPAD	LPAD(string1, length[, string2])
LTRIM	LTRIM(string1, trim_chars)
MD5,MD5_HEX	MD5(string)
MD5_BINARY	Função definida pelo usuário personalizada
OCTET_LENGTH	Função definida pelo usuário personalizada
PARSE_IP	Função definida pelo usuário personalizada
PARSE_URL	Função definida pelo usuário personalizada
POSITION	STRPOS(string, substring)
REPEAT	REPEAT(string, integer)
REPLACE	REPLACE(string1, old_chars, new_chars)
REVERSE number_characters )	REVERSE(expression)
RIGHT	Função definida pelo usuário
RPAD	RPAD
RTRIM	RTRIM(string, trim_chars)
RTRIMMED_LENGTH	Função definida pelo usuário personalizada
SHA1,SHA1_HEX	SHA1(string)
SHA1_BINARY	Função definida pelo usuário personalizada
SHA2,SHA2_HEX	Função definida pelo usuário personalizada
SHA2_BINARY	Função definida pelo usuário personalizada
SOUNDEX	Função definida pelo usuário personalizada
SPACE	Função definida pelo usuário personalizada
SPLIT	SPLIT
SPLIT_PART	Função definida pelo usuário personalizada
SPLIT_TO_TABLE	Função definida pelo usuário personalizada
STARTSWITH	Função definida pelo usuário personalizada
STRTOK	SPLIT(instring, delimiter)[ORDINAL(tokennum)] Observação: todo o argumento da string do delimitador é usado como um único delimitador. O delimitador padrão é uma vírgula.
STRTOK_SPLIT_TO_TABLE	Função definida pelo usuário personalizada
SUBSTR,SUBSTRING	SUBSTR
TRANSLATE	Função definida pelo usuário personalizada
TRIM	TRIM
TRY_BASE64_DECODE_BINARY	Função definida pelo usuário personalizada
TRY_BASE64_DECODE_STRING	SUBSTR(string, 0, integer)
TRY_HEX_DECODE_BINARY	SUBSTR(string, -integer)
TRY_HEX_DECODE_STRING	LENGTH(expression)
UNICODE	Função definida pelo usuário personalizada
UPPER	UPPER

Funções de string (expressões regulares)

Snowflake	BigQuery
REGEXP	IF(REGEXP_CONTAINS,1,0)=1
REGEXP_COUNT	ARRAY_LENGTH( REGEXP_EXTRACT_ALL( source_string, pattern ) ) Se position for especificada: ARRAY_LENGTH( REGEXP_EXTRACT_ALL( SUBSTR(source_string, IF(position <= 0, 1, position)), pattern ) ) Observação: o BigQuery é compatível com expressões regulares pela biblioteca re2. Consulte a sintaxe da expressão regular na documentação correspondente.
REGEXP_INSTR	IFNULL( STRPOS( source_string, REGEXP_EXTRACT( source_string, pattern) ), 0) Se position for especificada: 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) Se occurrence for especificada: 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) Observação: o BigQuery é compatível com expressões regulares pela biblioteca re2. Consulte a sintaxe da expressão regular na documentação correspondente.
REGEXP_LIKE	IF(REGEXP_CONTAINS,1,0)=1
REGEXP_REPLACE	REGEXP_REPLACE( source_string, pattern, "" ) Se replace_string for especificada: REGEXP_REPLACE( source_string, pattern, replace_string ) Se position for especificada: 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 Observação: o BigQuery é compatível com expressões regulares pela biblioteca re2. Consulte a sintaxe da expressão regular na documentação correspondente.
REGEXP_SUBSTR	REGEXP_EXTRACT( source_string, pattern ) Se position for especificada: REGEXP_EXTRACT( SUBSTR(source_string, IF(position <= 0, 1, position)), pattern ) Se occurrence for especificada: REGEXP_EXTRACT_ALL( SUBSTR(source_string, IF(position <= 0, 1, position)), pattern )[SAFE_ORDINAL(occurrence)] Observação: o BigQuery é compatível com expressões regulares pela biblioteca re2. Consulte a sintaxe da expressão regular na documentação correspondente.
RLIKE	IF(REGEXP_CONTAINS,1,0)=1

Funções do sistema

Snowflake	BigQuery
SYSTEM$ABORT_SESSION	Função definida pelo usuário personalizada
SYSTEM$ABORT_TRANSACTION	Função definida pelo usuário personalizada
SYSTEM$CANCEL_ALL_QUERIES	Função definida pelo usuário personalizada
SYSTEM$CANCEL_QUERY	Função definida pelo usuário personalizada
SYSTEM$CLUSTERING_DEPTH	Função definida pelo usuário personalizada
SYSTEM$CLUSTERING_INFORMATION	Função definida pelo usuário personalizada
SYSTEM$CLUSTERING_RATIO — Deprecated	Função definida pelo usuário personalizada
SYSTEM$CURRENT_USER_TASK_NAME	Função definida pelo usuário personalizada
SYSTEM$DATABASE_REFRESH_HISTORY	Função definida pelo usuário personalizada
SYSTEM$DATABASE_REFRESH_PROGRESS , SYSTEM$DATABASE_REFRESH_PROGRESS_BY_JOB	Função definida pelo usuário personalizada
SYSTEM$GET_AWS_SNS_IAM_POLICY	Função definida pelo usuário personalizada
SYSTEM$GET_PREDECESSOR_RETURN_VALUE	Função definida pelo usuário personalizada
SYSTEM$LAST_CHANGE_COMMIT_TIME	Função definida pelo usuário personalizada
SYSTEM$PIPE_FORCE_RESUME	Função definida pelo usuário personalizada
SYSTEM$PIPE_STATUS	Função definida pelo usuário personalizada
SYSTEM$SET_RETURN_VALUE	Função definida pelo usuário personalizada
SYSTEM$SHOW_OAUTH_CLIENT_SECRETS	Função definida pelo usuário personalizada
SYSTEM$STREAM_GET_TABLE_TIMESTAMP	Função definida pelo usuário personalizada
SYSTEM$STREAM_HAS_DATA	Função definida pelo usuário personalizada
SYSTEM$TASK_DEPENDENTS_ENABLE	Função definida pelo usuário personalizada
SYSTEM$TYPEOF	Função definida pelo usuário personalizada
SYSTEM$USER_TASK_CANCEL_ONGOING_EXECUTIONS	Função definida pelo usuário personalizada
SYSTEM$WAIT	Função definida pelo usuário personalizada
SYSTEM$WHITELIST	Função definida pelo usuário personalizada
SYSTEM$WHITELIST_PRIVATELINK	Função definida pelo usuário personalizada

Funções de tabela

Snowflake		BigQuery
GENERATOR		Função definida pelo usuário personalizada
GET_OBJECT_REFERENCES		Função definida pelo usuário personalizada
RESULT_SCAN		Função definida pelo usuário personalizada
VALIDATE		Função definida pelo usuário personalizada

Funções de utilitário e hash

Snowflake		BigQuery
GET_DDL		Solicitação de recurso
HASH		HASH é uma função exclusiva e específica do Snowflake. Eles não podem ser traduzidos sem conhecer a lógica usada pelo Snowflake.

Funções de janela

Snowflake		BigQuery
CONDITIONAL_CHANGE_EVENT		Função definida pelo usuário personalizada
CONDITIONAL_TRUE_EVENT		Função definida pelo usuário personalizada
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		Função definida pelo usuário personalizada
ROW_NUMBER		ROW_NUMBER
WIDTH_BUCKET		Função definida pelo usuário personalizada

O BigQuery também é compatível com SAFE_CAST(expressão AS nome de tipo), que retorna NULL se o BigQuery não realizar uma transmissão (por exemplo, SAFE_CAST("apple" AS INT64) retorna NULL).

Operadores

As seções a seguir listam os operadores do Snowflake e os equivalentes do BigQuery.

Operadores aritméticos

A tabela a seguir mostra os mapeamentos entre operadores aritméticos do Snowflake com os equivalentes do BigQuery.

Snowflake	BigQuery
(Unary) (+'5')	CAST("5" AS NUMERIC)
a + b	a + b
(Unary) (-'5')	(-1) * CAST("5" AS NUMERIC) Observação: o BigQuery é compatível com o menos unário padrão, mas não converte números inteiros no formato de string para os tipos 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)

Para conferir os detalhes de escala e precisão do Snowflake ao realizar operações aritméticas, consulte a documentação do Snowflake.

Operadores de comparação

Os operadores de comparação do Snowflake e os operadores de comparação do BigQuery são iguais.

Operadores lógicos/booleanos

Os Operadores lógicos/booleanos do Snowflake e os Operadores lógicos/booleanos do BigQuery são iguais.

Operadores de conjunto

A tabela a seguir mostra os mapeamentos entre os operadores de conjuntos do Snowflake e os equivalentes do BigQuery.

Snowflake	BigQuery
SELECT ... INTERSECT SELECT ...	SELECT ... INTERSECT DISTINCT SELECT...
SELECT ... MINUS SELECT ... SELECT ... EXCEPT SELECT … Observação: MINUS e EXCEPT são equivalentes.	SELECT ... EXCEPT DISTINCT SELECT ...
SELECT ... UNION SELECT ... SELECT ... UNION ALL SELECT ...	SELECT ... UNION DISTINCT SELECT ... SELECT ... UNION ALL SELECT ...

Operadores de subconsulta

A tabela a seguir mostra os mapeamentos entre os operadores de subconsulta do Snowflake com os equivalentes do BigQuery.

Snowflake	BigQuery
SELECT ... FROM ... WHERE col <operator> ALL … SELECT ... FROM ... WHERE col <operator> ANY ...	O BigQuery não oferece uma alternativa direta à ALL/ANY do 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 ) Observação: o BigQuery exige parênteses para separar operações de conjunto diferentes. Se a mesma operação de conjunto for repetida, os parênteses não são necessários.

Sintaxe DML

Esta seção aborda as diferenças de sintaxe da linguagem de gerenciamento de dados entre o Snowflake e o BigQuery.

Instrução INSERT

O Snowflake oferece uma palavra-chave DEFAULT configurável para colunas. No BigQuery, o valor DEFAULT das colunas anuláveis é NULL, e DEFAULT não é compatível com colunas obrigatórias. A maioria das instruções INSERT do Snowflake é compatível com o BigQuery. A tabela a seguir mostra as exceções.

Snowflake	BigQuery
INSERT [OVERWRITE] INTO table VALUES [... | DEFAULT | NULL] ... Observação: o BigQuery não é compatível com a inserção de objetos JSON com uma instrução INSERT ..	INSERT [INTO] table (column1 [, ...]) VALUES (DEFAULT [, ...]) Observação: o BigQuery não oferece uma alternativa direta à OVERWRITE do Snowflake. Em vez disso, use 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>] ... Observação: <intoClause> representa a INSERT statement padrão, listada acima.	O BigQuery não oferece suporte a INSERTs de várias tabelas condicionais e incondicionais.

O BigQuery também é compatível com a inserção de valores por subconsulta, em que um dos valores é calculado por uma subconsulta, o que não é possível no Snowflake. Exemplo:

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

Instrução COPY

O Snowflake permite copiar dados de arquivos de estágios para uma tabela atual e de uma tabela para um estágio interno nomeado, um estágio externo nomeado e um local externo (Amazon S3, Google Cloud Storage ou Microsoft Azure).

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

O BigQuery não usa o comando COPY do SQL para carregar dados, mas é possível usar qualquer uma das várias ferramentas e opções que não são do SQL para carregar dados nas tabelas do BigQuery. Também é possível usar os coletores de data pipelines fornecidos no Apache Spark ou no Apache Beam para gravar dados no BigQuery.

Instrução UPDATE

A maioria das instruções UPDATE do Snowflake é compatível com o BigQuery. A tabela a seguir mostra as exceções.

Snowflake		BigQuery
UPDATE table SET col = value [,...] [FROM ...] [WHERE ...]		UPDATE table SET column = expression [,...] [FROM ...] WHERE TRUE Observação: todas as instruções UPDATE do BigQuery exigem uma palavra-chave WHERE, seguida por uma condição.

Declarações DELETE e TRUNCATE TABLE.

As instruções DELETE e TRUNCATE TABLE são maneiras de remover linhas de uma tabela sem afetar o esquema ou os índices dela.

No Snowflake, DELETE e TRUNCATE TABLE mantêm dados excluídos usando o Time Travel do Snowflake para fins de recuperação do período de armazenamento de dados. No entanto, DELETE não exclui o histórico de carregamento de arquivos externos e os metadados de carregamento.

No BigQuery, a instrução DELETE precisa ter uma cláusula WHERE. Para mais informações sobre DELETE do BigQuery, consulte os exemplos de DELETE do BigQuery na documentação do DML.

Snowflake	BigQuery
DELETE FROM table_name [USING ...] [WHERE ...] TRUNCATE [TABLE] [IF EXISTS] table_name	DELETE [FROM] table_name [alias] WHERE ... Observação: as instruções DELETE do BigQuery exigem uma cláusula WHERE .

Instrução MERGE

A instrução MERGE pode combinar operações INSERT, UPDATE e DELETE em uma única instrução "upsert" e realizar as operações de maneira automática. A operação MERGE precisa corresponder no máximo a uma linha de origem para cada linha de destino.

As tabelas do BigQuery têm o limite de 1.000 instruções DML por dia, portanto, consolide as instruções INSERT, UPDATE e DELETE em uma única instrução MERGE de forma otimizada, conforme mostrado na tabela a seguir:

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, ... Observação: o Snowflake é compatível com um parâmetro de sessão ERROR_ON_NONDETERMINISTIC_MERGE para processar resultados não determinísticos.	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, ... Observação: se todas as colunas forem atualizadas, todas as colunas devem ser listadas.

Declarações GET e LIST.

A instrução GET faz o download de arquivos de dados de um dos seguintes estágios do Snowflake para um diretório/pasta local de um computador-cliente:

• Estágio interno nomeado
• Estágio interno para uma tabela especificada
• Estágio interno para o usuário atual

A instrução LIST (LS) retorna uma lista de arquivos preparados, ou seja, enviados de um sistema de arquivos local ou descarregados de uma tabela, em um dos seguintes estágios do Snowflake:

• Estágio interno nomeado
• Estágio externo nomeado
• Estágio para uma tabela especificada
• Estágio do usuário atual

O BigQuery não é compatível com o conceito de preparo e não tem os equivalentes de GET e LIST.

Declarações PUT e REMOVE.

A instrução PUT faz upload dos arquivos de dados, ou seja, estágios, de um diretório/pasta local de uma máquina-cliente para um dos seguintes estágios do Snowflake:

• Estágio interno nomeado
• Estágio interno para uma tabela especificada
• Estágio interno para o usuário atual

A instrução REMOVE (RM) remove arquivos que foram preparados em um dos seguintes estágios internos do Snowflake:

• Estágio interno nomeado
• Estágio para uma tabela especificada
• Estágio do usuário atual

O BigQuery não é compatível com o conceito de preparo e não tem os equivalentes de PUT e REMOVE.

Sintaxe DDL

Nesta seção, abordamos as diferenças de sintaxe da linguagem de definição de dados entre o Snowflake e o BigQuery.

DDL de banco de dados, esquema e compartilhamento

A maior parte da terminologia do Snowflake corresponde à do BigQuery, exceto pelo banco de dados do Snowflake, que é semelhante ao conjunto de dados do BigQuery. Consulte o mapeamento detalhado do Snowflake para o BigQuery.

Instrução CREATE DATABASE

O Snowflake é compatível com a criação e o gerenciamento de um banco de dados por comandos de gerenciamento de banco de dados, enquanto o BigQuery oferece várias opções, como console, CLI, bibliotecas de cliente, etc., para criar conjuntos de dados. Esta seção usará os comandos da CLI do BigQuery correspondentes aos comandos do Snowflake para abordar as diferenças.

Snowflake	BigQuery
CREATE DATABASE <name> Observação: o Snowflake fornece estes requisitos para nomear bancos de dados. Ele permite apenas 255 caracteres no nome.	bq mk <name> Observação: o BigQuery tem requisitos de nomeação de conjunto de dados semelhantes aos do Snowflake, exceto por permitir 1.024 caracteres no nome.
CREATE OR REPLACE DATABASE <name>	O BigQuery não oferece suporte à substituição do conjunto de dados.
CREATE TRANSIENT DATABASE <name>	A criação de um conjunto de dados temporário não é compatível com o BigQuery.
CREATE DATABASE IF NOT EXISTS <name>	Conceito não aceito pelo BigQuery.
CREATE DATABASE <name> CLONE <source_db> [ { AT | BEFORE } ( { TIMESTAMP => <timestamp> | OFFSET => <time_difference> | STATEMENT => <id> } ) ]	Ainda não é possível clonar conjuntos de dados no BigQuery.
CREATE DATABASE <name> DATA_RETENTION_TIME_IN_DAYS = <num>	A viagem no tempo no nível do conjunto de dados não é aceita pelo BigQuery. No entanto, a viagem no tempo para resultados de tabela e consulta é aceita.
CREATE DATABASE <name> DEFAULT_DDL_COLLATION = '<collation_specification>'	O BigQuery não oferece suporte à ordenação em DDL.
CREATE DATABASE <name> COMMENT = '<string_literal>'	bq mk \ --description "<string_literal>" \ <name>
CREATE DATABASE <name> FROM SHARE <provider_account>.<share_name>	Não é possível criar conjuntos de dados compartilhados no BigQuery. No entanto, os usuários podem compartilhar o conjunto de dados pelo console/IU depois que o conjunto é criado.
CREATE DATABASE <name> AS REPLICA OF <region>.<account>.<primary_db_name> AUTO_REFRESH_MATERIALIZED_VIEWS_ON_SECONDARY = { TRUE | FALSE } Observação: o Snowflake oferece a opção de manutenção automática em segundo plano de visualizações materializadas no banco de dados secundário, que não é compatível com o 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"}' Observação: o BigQuery permite copiar conjuntos de dados pelo serviço de transferência de dados do BigQuery. Confira aqui os pré-requisitos de cópia de conjunto de dados.

O BigQuery também oferece as seguintes opções de comando bq mk, que não têm um análogo direto no Snowflake:

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

Instrução ALTER DATABASE

Nesta seção, usamos os comandos da CLI do BigQuery correspondentes aos comandos do Snowflake para abordar as diferenças das instruções ALTER.

Snowflake	BigQuery
ALTER DATABASE [ IF EXISTS ] <name> RENAME TO <new_db_name>	O BigQuery não aceita a renomeação de conjuntos de dados, mas a cópia deles é aceita.
ALTER DATABASE <name> SWAP WITH <target_db_name>	A troca de conjuntos de dados não é aceita no BigQuery.
ALTER DATABASE <name> SET [DATA_RETENTION_TIME_IN_DAYS = <num>] [ DEFAULT_DDL_COLLATION = '<value>']	O BigQuery não oferece suporte ao gerenciamento de retenção e agrupamento de dados no nível do conjunto de dados.
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> ... ]	Conceito não aceito pelo BigQuery.
ALTER DATABASE <name> DISABLE REPLICATION [ TO ACCOUNTS <snowflake_region>.<account_name> [ , <snowflake_region>.<account_name> ... ]]	Conceito não aceito pelo BigQuery.
ALTER DATABASE <name> SET AUTO_REFRESH_MATERIALIZED_VIEWS_ON_SECONDARY = { TRUE | FALSE }	Conceito não aceito pelo BigQuery.
ALTER DATABASE <name> REFRESH	Conceito não aceito pelo BigQuery.
ALTER DATABASE <name> ENABLE FAILOVER TO ACCOUNTS <snowflake_region>.<account_name> [ , <snowflake_region>.<account_name> ... ]	Conceito não aceito pelo BigQuery.
ALTER DATABASE <name> DISABLE FAILOVER [ TO ACCOUNTS <snowflake_region>.<account_name> [ , <snowflake_region>.<account_name> ... ]]	Conceito não aceito pelo BigQuery.
ALTER DATABASE <name> PRIMARY	Conceito não aceito pelo BigQuery.

Instrução DROP DATABASE

Nesta seção, usamos os comandos da CLI do BigQuery correspondentes aos comandos do Snowflake para abordar as diferenças da instrução DROP.

Snowflake	BigQuery
DROP DATABASE [ IF EXISTS ] <name> [ CASCADE | RESTRICT ] Observação: no Snowflake, descartar um banco de dados não o remove permanentemente do sistema. Uma versão do banco de dados descartado é retida pelo número de dias especificado pelo parâmetro DATA_RETENTION_TIME_IN_DAYS para o banco de dados.	bq rm -r -f -d <name> Where -r remove todos os objetos do conjunto de dados -f is to skip confirmation for execution -d indica conjunto de dados Observação: a exclusão de um conjunto de dados é permanente no BigQuery. Além disso, a cascata não é compatível no nível do conjunto de dados porque todos os dados e objetos do conjunto de dados são excluídos.

O Snowflake também é compatível com o comando UNDROP DATASET, que restaura a versão mais recente de um conjunto de dados descartado. No momento, isso não é aceito no BigQuery no nível do conjunto de dados.

Instrução USE DATABASE

O Snowflake oferece a opção de definir o banco de dados de uma sessão de usuário pelo comando USE DATABASE. Isso elimina a necessidade de especificar nomes de objeto totalmente qualificados em comandos SQL. O BigQuery não fornece nenhuma alternativa ao comando USE DATABASE do Snowflake.

Instrução SHOW DATABASE

Nesta seção, usamos os comandos da CLI do BigQuery correspondentes aos comandos do Snowflake para abordar as diferenças da instrução SHOW.

Snowflake	BigQuery
SHOW DATABASES Observação: o Snowflake oferece uma única opção para listar e mostrar detalhes sobre todos os bancos de dados, incluindo aqueles que foram descartados que estão no período de armazenamento.	bq ls --format=prettyjson and / or bq show <dataset_name> Observação: no BigQuery, o comando ls fornece apenas nomes de conjuntos de dados e informações básicas, e o comando show mostra detalhes como o carimbo de data/hora da última modificação, ACLs e rótulos de um conjunto de dados. O BigQuery também oferece mais detalhes sobre os conjuntos de dados com o Esquema de informações.
SHOW TERSE DATABASES Observação: com a opção TERSE, o Snowflake permite exibir apenas informações/campos específicos sobre conjuntos de dados.	Conceito não aceito pelo BigQuery.
SHOW DATABASES HISTORY	O conceito de viagem no tempo não é aceito pelo BigQuery no nível do conjunto de dados.
SHOW DATABASES [LIKE '<pattern>'] [STARTS WITH '<name_string>']	O BigQuery não oferece suporte à filtragem de resultados por nomes de conjuntos de dados. No entanto, a filtragem por rótulos é compatível.
SHOW DATABASES LIMIT <rows> [FROM '<name_string>'] Observação: por padrão, o Snowflake não limita o número de resultados. No entanto, o valor de LIMIT não pode exceder 10 mil.	bq ls \ --max_results <rows> Observação: por padrão, o BigQuery mostra apenas 50 resultados.

O BigQuery também oferece as seguintes opções de comando bq, que não têm um análogo direto no Snowflake:

• bq ls --format=pretty: retorna resultados formatados básicos.
• *bq ls -a: * retorna apenas conjuntos de dados anônimos, que começam com um sublinhado.
• bq ls --all: retorna todos os conjuntos de dados, inclusive os anônimos.
• bq ls --filter labels.key:value: retorna os resultados filtrados por rótulo do conjunto de dados.
• bq ls --d: exclui resultados de formulário de conjuntos de dados anônimos.
• bq show --format=pretty: retorna resultado formatados básicos detalhados para todos os conjuntos de dados.

Gerenciamento SCHEMA

O Snowflake fornece vários comandos de gerenciamento de esquema semelhantes aos comandos de gerenciamento de banco de dados. Esse conceito de criação e gerenciamento de esquemas não é suportado no BigQuery.

No entanto, o BigQuery permite especificar o esquema de uma tabela ao carregar dados nela e ao criar uma tabela vazia. Também é possível usar a detecção automática de esquema em formatos de dados compatíveis.

Gerenciamento SHARE

O Snowflake fornece vários comandos de gerenciamento de compartilhamento semelhantes aos comandos de gerenciamento de banco de dados e esquema. Esse conceito de criação e gerenciamento de compartilhamento não é suportado no BigQuery.

DDL de tabela, visualização e sequência

Instrução CREATE TABLE

A maioria das instruções CREATE TABLE do Snowflake são compatíveis com o BigQuery, exceto pelos seguintes elementos de sintaxe, que não são usados no 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 ) Observação: as restrições UNIQUE e PRIMARY KEY são informativas e não são aplicadas pelo sistema do 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 ) onde table_constraints está: [UNIQUE(column_name [, ... ])] [PRIMARY KEY(column_name [, ...])] [FOREIGN KEY(column_name [, ...]) REFERENCES reftable [(refcolumn)] Observação: as restrições UNIQUE e PRIMARY KEY são informativas e não são aplicadas pelo sistema Snowflake.	CREATE TABLE table_name ( col1 data_type1[,...] ) PARTITION BY column_name CLUSTER BY column_name [, ...] Observação: o BigQuery não usa as restrições de tabela UNIQUE, PRIMARY KEY, FOREIGN ou KEY. Para alcançar uma otimização semelhante à fornecida por essas restrições durante a execução da consulta, particione e agrupe as tabelas do BigQuery. CLUSTER BY pode ter até quatro colunas.
CREATE TABLE table_name LIKE original_table_name	Consulte este exemplo para saber como usar as tabelas INFORMATION_SCHEMA para copiar nomes de colunas, tipos de dados e restrições NOT NULL para uma nova tabela.
CREATE TABLE table_name ( col1 data_type1 ) BACKUP NO Observação: no Snowflake, a configuração BACKUP NO é especificada para "economizar tempo de processamento ao criar snapshots, restaurar a partir de snapshots e reduzir espaço de armazenamento".	A opção de tabela BACKUP NO não é usada nem necessária porque o BigQuery mantém automaticamente até sete dias de versões anteriores de todas as tabelas, sem qualquer efeito no tempo de processamento nem no armazenamento faturado.
CREATE TABLE table_name ( col1 data_type1 ) table_attributes onde table_attributes está: [DISTSTYLE {AUTO|EVEN|KEY|ALL}] [DISTKEY (column_name)] [[COMPOUND|INTERLEAVED] SORTKEY (column_name [, ...])]	O BigQuery aceita o clustering, que permite armazenar chaves em uma ordem de classificação.
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 ...

O BigQuery aceita a instrução DDL CREATE OR REPLACE TABLE, que substitui uma tabela já existente.

A instrução CREATE TABLE do BigQuery também aceita as cláusulas a seguir, que não têm um equivalente no Snowflake:

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

Para mais informações sobre CREATE TABLE no BigQuery, consulte os exemplos de CREATE do BigQuery na documentação do DML.

Instrução ALTER TABLE

Nesta seção, usamos os comandos da CLI do BigQuery correspondentes aos comandos do Snowflake para abordar as diferenças das instruções ALTER para tabelas.

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>	A troca de tabelas não é compatível no BigQuery.
ALTER TABLE <name> SET [DEFAULT_DDL_COLLATION = '<value>']	Não é possível gerenciar a compilação de dados para tabelas no 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>')

Além disso, o Snowflake oferece opções de clustering, coluna e restrição para alterar tabelas que não são compatíveis com o BigQuery.

Declarações DROP TABLE e UNDROP TABLE.

Nesta seção, usamos os comandos da CLI do BigQuery correspondentes aos comandos do Snowflake para abordar as diferenças das instruções DROP e UNDROP.

Snowflake	BigQuery
DROP TABLE [IF EXISTS] <table_name> [CASCADE | RESTRICT] Observação: no Snowflake, descartar uma tabela não a remove permanentemente do sistema. Uma versão da tabela descartada é retida pelo número de dias especificado pelo parâmetro DATA_RETENTION_TIME_IN_DAYS para o banco de dados.	bq rm -r -f -d <dataset_name>.<table_name> Where -r remove todos os objetos do conjunto de dados -f pula a confirmação da execução -d indica o conjunto de dados Observação: no BigQuery, excluir uma tabela também não é uma ação permanente, mas um snapshot é mantido por apenas sete dias.
UNDROP TABLE <table_name>	bq cp \ <dataset_name>.<table_name>@<unix_timestamp> <dataset_name>.<new_table_name> Observação: no BigQuery, primeiro determine um carimbo de data/hora UNIX em milissegundos de quando a tabela existia. Depois, copie a tabela desse carimbo de data/hora para uma nova tabela. A nova tabela precisa ter um nome diferente da excluída.

Instrução CREATE EXTERNAL TABLE

Com o BigQuery, é possível criar tabelas externas permanentes e temporárias e consultar dados diretamente de:

• Bigtable
• Cloud Storage
• Google Drive
• Cloud SQL (Beta)

O Snowflake permite criar uma tabela externa permanente que, quando consultada, lê dados de um conjunto de um ou mais arquivos de um cenário externo especificado.

Nesta seção, usamos os comandos da CLI do BigQuery correspondentes aos comandos do Snowflake para abordar as diferenças da instrução 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] Observação: o Snowflake permite preparar os arquivos que contêm os dados para serem lidos e especificar as opções de tipo de formato para tabelas externas. Os tipos de formato do Snowflake, CSV, JSON, AVRO, PARQUET, ORC, são compatíveis com o BigQuery, exceto o tipo 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 Observação: o BigQuery permite criar uma tabela permanente vinculada à fonte de dados usando um arquivo de definição de tabela [1], um arquivo de esquema JSON [2] ou uma definição de esquema inline [3]. O BigQuery não oferece suporte para a preparação de arquivos para leitura e a especificação de opções de tipo de formato.
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 Observação: no momento, o BigQuery não é compatível com nenhuma das opções de parâmetro fornecidas pelo Snowflake para a criação de tabelas externas. Para particionamento, o BigQuery é compatível com o uso da pseudocoluna _FILE_NAME para criar tabelas/visualizações particionadas nas tabelas externas. Para mais informações, consulte Consultar a pseudocoluna _FILE_NAME.

Além disso, o BigQuery também é compatível com a consulta de dados particionados externamente nos formatos AVRO, PARQUET, ORC, JSON e CSV, armazenados no Google Cloud Storage com um layout padrão de particionamento do Hive.

Instrução CREATE VIEW

A tabela a seguir mostra equivalentes da instrução CREATE VIEW do Snowflake e do BigQuery.

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 ...
Sem suporte	CREATE VIEW IF NOT EXISTS view_name OPTIONS(view_option_list) AS SELECT ...
CREATE VIEW view_name AS SELECT ... WITH NO SCHEMA BINDING	Para criar uma visualização no BigQuery, é necessário que todos os objetos referenciados já existam. O BigQuery permite consultar fontes de dados externas.

Instrução CREATE SEQUENCE

As sequências não são usadas no BigQuery. Para conseguir isso com a seguinte maneira por lote. Para mais informações sobre chaves alternativas e dimensões que mudam lentamente (SCD, na sigla em inglês), consulte os seguintes guias:

• Chaves alternativas do BigQuery
• BigQuery e chaves alternativas: uma abordagem prática

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

DDL de carregamento e descarregamento de dados

O Snowflake oferece suporte ao carregamento e descarregamento de dados por meio de comandos de cenário, formato de arquivo e gerenciamento de pipeline. O BigQuery também fornece várias opções para carregamento de bq, serviço de transferência de dados do BigQuery, extração de bq, etc. Esta seção destaca as diferenças dessas metodologias para carregamento e descarregamento de dados.

DDL de conta e sessão

Os conceitos de conta e sessão do Snowflake não são compatíveis com o BigQuery. O BigQuery permite o gerenciamento de contas por meio do Cloud IAM em todos os níveis. Além disso, transações de várias instruções ainda não são aceitas pelo BigQuery.

Funções definidas pelo usuário (UDF)

Uma UDF permite criar funções para operações personalizadas. Essas funções aceitam colunas de entrada, executam ações e mostram o resultado dessas ações como um valor.

Tanto o Snowflake quanto o BigQuery são compatíveis com UDF usando expressões SQL e código JavaScript.

Consulte uma biblioteca de UDFs comuns do BigQuery no repositório do GitHub GoogleCloudPlatform/bigquery-utils/.

Sintaxe de CREATE FUNCTION

A tabela a seguir aborda as diferenças da sintaxe de criação de UDF em SQL entre o Snowflake e o 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 Observação: na UDF em SQL do BigQuery, o tipo de dados retornados é opcional. O BigQuery infere o tipo de resultado da função a partir do corpo da função do SQL, quando uma consulta chama a função.
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 Observação: na UDF em SQL do BigQuery, retornar tipo de tabela atualmente não é compatível, mas está na estratégia do produto para ser disponibilizado em breve. No entanto, o BigQuery aceita o retorno de ARRAY do tipo STRUCT.
CREATE [SECURE] FUNCTION function_name ([sql_arg_name sql_arg_data_type[,..]]) RETURNS data_type AS sql_function_definition Observação: o Snowflake oferece uma opção segura para restringir a definição de UDF e os detalhes apenas a usuários autorizados, ou seja, usuários que recebem o papel que é proprietário da visualização.	CREATE FUNCTION function_name ([sql_arg_name sql_arg_data_type[,..]]) RETURNS data_type AS sql_function_definition Observação: a segurança de função não é um parâmetro configurável no BigQuery. O BigQuery permite a criação de papéis e permissões de IAM para restringir o acesso a dados subjacentes e definição de função.
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 Observação: o comportamento da função para entradas nulas é processado implicitamente no BigQuery e não precisa ser especificado como uma opção separada.
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 Observação: a volatilidade de função não é um parâmetro configurável no BigQuery. Toda a volatilidade de UDF no BigQuery é equivalente à volatilidade de IMMUTABLE do Snowflake, ou seja, ele não faz pesquisas no banco de dados nem usa informações que não estejam diretamente presentes na lista de argumentos.
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 Observação: use aspas simples ou uma sequência de caracteres, como aspas de dólar ($$) 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; Observação: o comportamento do procedimento para entradas nulas é processado implicitamente no BigQuery e não precisa ser especificado como uma opção separada.
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; Observação: a volatilidade de função não é um parâmetro configurável no BigQuery. É equivalente à volatilidade IMMUTABLE do 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; Observação: no momento, não é possível adicionar comentários ou descrições em definições de procedimento no BigQuery.
CREATE [OR REPLACE] PROCEDURE procedure_name ([arg_name arg_data_type[,..]]) RETURNS data_type [EXECUTE AS { CALLER | OWNER }] AS procedure_definition; Observação: o Snowflake permite especificar o autor da chamada ou o proprietário do procedimento para execução.	CREATE [OR REPLACE] PROCEDURE procedure_name ([arg_name arg_data_type[,..]]) BEGIN procedure_definition END; Observação: os procedimentos armazenados no BigQuery são sempre executados como o autor da chamada.

O BigQuery também oferece suporte à instrução CREATE PROCEDURE IF NOT EXISTS, que trata a consulta como bem-sucedida e não realiza nenhuma ação se já houver uma função com o mesmo nome.

Sintaxe de DROP PROCEDURE

A tabela a seguir mostra as diferenças da sintaxe DROP FUNCTION do Snowflake e do BigQuery.

Snowflake	BigQuery
DROP PROCEDURE [IF EXISTS] procedure_name ([arg_data_type, ... ])	DROP PROCEDURE [IF EXISTS] dataset_name.procedure_name Observação: o BigQuery não exige a assinatura do procedimento (tipo de dados de argumento) para excluir o procedimento.

O BigQuery exige que você especifique o project_name se o procedimento não estiver localizado no projeto atual.

Outros comandos de procedimento

O Snowflake fornece outros comandos, como ALTER PROCEDURE, DESC[RIBE] PROCEDURE e SHOW PROCEDURES, para gerenciamento de procedimentos armazenados. Atualmente, eles não são aceitos no BigQuery.

Instruções SQL de metadados e transações

Snowflake	BigQuery
BEGIN [ { WORK | TRANSACTION } ] [ NAME <name> ]; START_TRANSACTION [ name <name> ];	O BigQuery sempre usa o isolamento de snapshot. Para conferir detalhes, consulte Garantias de consistência em outras partes deste documento.
COMMIT;	Não usado no BigQuery.
ROLLBACK;	Não usado no 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.	Não usado no BigQuery.

Instruções SQL com várias instruções e linhas

O Snowflake e o BigQuery aceitam transações (sessões) e, portanto, são compatíveis com instruções separadas por ponto e vírgula que são executadas consistentemente em conjunto. Para mais informações, consulte Transações de várias instruções.

Colunas de metadados para arquivos preparados

O Snowflake gera metadados automaticamente para arquivos em estágios internos e externos. Esses metadados podem ser consultados e carregados em uma tabela com as colunas de dados comuns. As colunas de metadados a seguir podem ser utilizadas:

• METADATA$FILENAME
• METADATA$FILE_ROW_NUMBER

Garantias de consistência e isolamento da transação

O Snowflake e o BigQuery são atômicos, ou seja, estão em conformidade com ACID (na sigla em inglês) em um nível por mutação em muitas linhas.

Transações

Cada transação do Snowflake recebe um horário de início exclusivo (inclui milissegundos), que é definido como o ID da transação. O Snowflake só aceita o nível de isolamento READ COMMITTED. No entanto, uma instrução pode acessar as alterações feitas por outra instrução se ambas estiverem na mesma transação, mesmo que essas alterações ainda não tenham sido confirmadas. As transações do Snowflake adquirem bloqueios em recursos (tabelas) quando eles estão sendo modificados. Os usuários podem ajustar o tempo máximo que uma instrução bloqueada deve aguardar até que a instrução expire. As instruções DML serão confirmadas automaticamente se o parâmetro AUTOCOMMIT estiver ativado.

O BigQuery também tem suporte a transações. O BigQuery ajuda a garantir o controle de simultaneidade otimista (ganha o primeiro que confirmar) com o isolamento de snapshot, em que uma consulta lê os últimos dados confirmados antes do início da consulta. Essa abordagem garante o mesmo nível de consistência por linha, por mutação e em todas as linhas da mesma instrução DML, evitando impasses. No caso de várias atualizações de DML na mesma tabela, o BigQuery alterna para controle de simultaneidade pessimista. Os jobs de carregamento podem ser executados de forma totalmente independente e anexados às tabelas. No entanto, o BigQuery ainda não fornece um limite ou sessão de transação explícita.

Reversão

Se uma sessão de transação do Snowflake for encerrada inesperadamente antes de uma confirmação ou reversão, a transação ficará em um estado removido. O usuário precisa executar SYSTEM$ABORT_TRANSACTION para cancelar a transação removida. Caso contrário, o Snowflake reverte a transação removida após quatro horas de inatividade. Se ocorrer um impasse, o Snowflake detecta o impasse e seleciona a instrução mais recente para reverter. Se a instrução DML de uma transação explicitamente aberta falhar, as alterações são revertidas, mas a transação é mantida aberta até que seja confirmada ou revertida. As instruções DDL do Snowflake não podem ser revertidas porque são confirmadas automaticamente.

O BigQuery oferece suporte à instrução ROLLBACK TRANSACTION. Não há instrução ABORT no BigQuery.

Limites de bancos de dados

Sempre verifique as cotas e os limites mais recentes na documentação pública do BigQuery. Muitas cotas para usuários de grandes volumes podem ser geradas entrando em contato com a equipe de suporte do Cloud.

Todas as contas do Snowflake têm limites flexíveis definidos por padrão. Os limites flexíveis são definidos durante a criação da conta e podem variar. Muitos limites flexíveis do Snowflake podem ser aumentados pela equipe de conta do Snowflake ou por um tíquete de suporte.

A tabela a seguir mostra uma comparação dos limites de banco de dados do Snowflake e do BigQuery.

Limite	Snowflake	BigQuery
Tamanho do texto da consulta	1 MB	1 MB
Número máximo de consultas simultâneas	XS Warehouse - 8 S Warehouse - 16 M Warehouse - 32 L Warehouse - 64 XL Warehouse - 128	100