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.

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:

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:

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:

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, enquanto que as cláusulas GROUP BY do BigQuery são compatíveis com 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)

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:

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:

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:

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:

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:

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:

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

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:

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:

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 o particionamento, o BigQuery aceita a pseudocoluna _FILE_NAME para a criação de tabelas particionadas/visualizações sobre as tabelas externas. Para mais informações, acesse 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:

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: usar aspas simples ou uma sequência de caracteres, como aspas de dólar ($$), não é necessário nem aceito no BigQuery. O BigQuery interpreta implicitamente a expressão SQL.

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


Observação: no momento, não é possível adicionar comentários ou descrições em UDFs no BigQuery.

CREATE [OR REPLACE] FUNCTION function_name

(x integer, y integer)

RETURNS integer

AS $$

SELECT x + y

$$


Observação: o Snowflake não é compatível com ANY TYPE para UDFs em SQL. No entanto, ele aceita o uso de tipos de dados VARIANT.

CREATE [OR REPLACE] FUNCTION function_name

(x ANY TYPE, y ANY TYPE)

AS

SELECT x + y



Observação: o BigQuery aceita o uso de ANY TYPE como tipo de argumento. A função aceitará uma entrada de qualquer tipo para esse argumento. Para mais informações, consulte o parâmetro com modelo no BigQuery.

O BigQuery também aceita a instrução CREATE FUNCTION 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.

A instrução CREATE FUNCTION do BigQuery também oferece suporte à criação de TEMPORARY or TEMP functions, que não têm um equivalente do Snowflake. Consulte Como chamar UDFs para conferir detalhes sobre como executar uma UDF permanente do BigQuery.

Sintaxe de DROP FUNCTION

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

Snowflake BigQuery

DROP FUNCTION [IF EXISTS]

function_name

([arg_data_type, ... ])

DROP FUNCTION [IF EXISTS] dataset_name.function_name


Observação: o BigQuery não exige a assinatura da função (tipo de dados de argumento) para excluir a função.

O BigQuery exige que você especifique o project_name se a função não estiver localizada no projeto atual.

Comandos de função adicionais

Nesta seção, abordamos outros comandos de UDF compatíveis com o Snowflake, que não estão disponíveis diretamente no BigQuery.

Sintaxe de ALTER FUNCTION

O Snowflake é compatível com as operações a seguir usando a sintaxe ALTER FUNCTION.

  • Renomear uma UDF
  • Converter para (ou reverter de) uma UDF segura
  • Como adicionar, substituir e remover um comentário em uma UDF

Como a configuração da segurança de função e a adição de comentários de função não estão disponíveis no BigQuery, a sintaxe ALTER FUNCTION não é aceita no momento. No entanto, a instrução CREATE FUNCTION pode ser usada para a criação de uma UDF com a mesma definição de função e um nome diferente.

Sintaxe de DESCRIBE FUNCTION

O Snowflake é compatível com a descrição de uma UDF com a sintaxe DESC[RIBE] FUNCTION. No momento, isso não é aceito no BigQuery. No entanto, a consulta de metadados da UDF pela INFORMATION SCHEMA será disponibilizada em breve como parte da estratégia do produto.

Sintaxe de SHOW USER FUNCTIONS

No Snowflake, a sintaxe SHOW USER FUNCTIONS pode ser usada para listar todas as UDFs a que os usuários tenham privilégios de acesso. No momento, isso não é aceito no BigQuery. No entanto, a consulta de metadados da UDF pela INFORMATION SCHEMA será disponibilizada em breve como parte da estratégia do produto.

Procedimentos armazenados

Os procedimentos armazenados do Snowflake são escritos em JavaScript, que pode executar instruções SQL chamando uma API JavaScript. No BigQuery, os procedimentos armazenados são definidos por um bloco de instruções SQL.

Sintaxe de CREATE PROCEDURE

No Snowflake, um procedimento armazenado é executado com um comando CALL, enquanto no BigQuery os procedimentos armazenados são executados como qualquer outra função do BigQuery.

A tabela a seguir mostra as diferenças da sintaxe de criação de procedimentos armazenados do Snowflake e do BigQuery.

Snowflake BigQuery

CREATE [OR REPLACE] PROCEDURE

procedure_name

([arg_name arg_data_type[,..]])

RETURNS data_type

AS procedure_definition;


Observação: o Snowflake exige que os procedimentos armazenados retornem um único valor. Portanto, o tipo de dados retornados é obrigatório.
CREATE [OR REPLACE] PROCEDURE

procedure_name

([arg_mode arg_name arg_data_type[,..]])

BEGIN

procedure_definition

END;


arg_mode: IN | OUT | INOUT


Observação: o BigQuery não é compatível com um tipo de retorno para procedimentos armazenados. Além disso, é necessário especificar o modo para cada argumento transmitido.

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:

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.

Reverter

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