Guía de traducción de SQL de Snowflake

En este documento, se detallan las similitudes y diferencias que existen en la sintaxis de SQL entre Snowflake y BigQuery para ayudar a acelerar la planificación y ejecución de la transferencia de tu EDW (almacén de datos empresariales) a BigQuery. El almacenamiento de datos de Snowflake está diseñado para funcionar con la sintaxis de SQL específica de Snowflake. Es posible que las secuencias de comandos escritas para Snowflake necesiten modificarse antes de que puedas usarlas en BigQuery, ya que los dialectos de SQL varían según los servicios. Usa la traducción de SQL por lotes para migrar tus secuencias de comandos de SQL de forma masiva o la traducción de SQL interactiva a fin de traducir consultas ad hoc. Snowflake SQL es compatible con ambas herramientas en la vista previa.

Tipos de datos

En esta sección, se muestran los equivalentes entre los tipos de datos en Snowflake y en BigQuery.



Snowflake BigQuery Notas
NUMBER/ DECIMAL/NUMERIC NUMERIC El tipo de datos NUMBER en Snowflake admite 38 dígitos de precisión y 37 dígitos de escala. La precisión y la escala se pueden especificar según el usuario.

BigQuery admite NUMERIC y BIGNUMERIC con precisión y escalamiento especificados de forma opcional dentro de ciertos límites.
INT/INTEGER BIGNUMERIC INT/INTEGERy todos los demásINT como los tipos de datos, comoBIGINT, TINYINT, SMALLINT, BYTEINT representan un alias para elNUMBER tipo de datos en el que la precisión y la escala no se pueden especificar y siempre estánNUMBER(38, 0)
BIGINT BIGNUMERIC
SMALLINT BIGNUMERIC
TINYINT BIGNUMERIC
BYTEINT BIGNUMERIC
FLOAT/
FLOAT4/
FLOAT8
FLOAT64 El tipo de datos FLOAT en Snowflake establece “NaN” como > X, en el que X es cualquier valor FLOAT (distinto de “NaN” en sí).

El tipo de datos FLOAT en BigQuery establece “NaN” como < X, en el que X es cualquier valor FLOAT (distinto de “NaN” en sí).
DOUBLE/
DOUBLE PRECISION/

REAL
FLOAT64 El tipo de datos DOUBLE en Snowflake es sinónimo del tipo de datos FLOAT en Snowflake, pero suele mostrarse de forma incorrecta como FLOAT. Se almacena correctamente como DOUBLE.
VARCHAR STRING El tipo de datos VARCHAR en Snowflake tiene una longitud máxima de 16 MB (sin comprimir). Si no se especifica la longitud, el valor predeterminado es la longitud máxima.

El tipo de datos STRING en BigQuery se almacena como Unicode codificado en UTF-8 de longitud variable. La longitud máxima es de 16,000 caracteres.
CHAR/CHARACTER STRING El tipo de datos CHAR en Snowflake tiene una longitud máxima de 1.
STRING/TEXT STRING El tipo de datos STRING en Snowflake es sinónimo de VARCHAR de Snowflake.
BINARY BYTES
VARBINARY BYTES
BOOLEAN BOOL El tipo de datos BOOL en BigQuery solo puede aceptar TRUE/FALSE, a diferencia del tipo de datos BOOL en Snowflake, que puede aceptar TRUE/FALSE/NULL.
DATE DATE El tipo DATE en Snowflake acepta los formatos de fecha más comunes, a diferencia del tipo DATE en BigQuery, que solo acepta fechas en el formato “AAAA-[M]M-[D]D”.
TIME TIME El tipo TIME en Snowflake admite entre 0 y 9 nanosegundos de precisión, mientras que el tipo TIME en BigQuery admite entre 0 y 6 nanosegundos de precisión.
TIMESTAMP DATETIME TIMESTAMP es un alias configurable por el usuario que se configura de forma predeterminada en TIMESTAMP_NTZ y se asigna a DATETIME en BigQuery.
TIMESTAMP_LTZ TIMESTAMP
TIMESTAMP_NTZ/DATETIME DATETIME
TIMESTAMP_TZ TIMESTAMP
OBJECT JSON El tipo OBJECT en Snowflake no admite valores con tipos explícitos. Los valores son del tipo VARIANT.
VARIANT JSON El tipo OBJECT en Snowflake no admite valores con tipos explícitos. Los valores son del tipo VARIANT.
ARRAY ARRAY<JSON> El tipo ARRAY en Snowflake solo puede admitir tipos VARIANT, mientras que el tipo ARRAY en BigQuery puede admitir todos los tipos de datos, excepto un array en sí.

BigQuery también tiene los siguientes tipos de datos que no tienen un análogo de Snowflake directo:

Sintaxis de consulta y operadores de consulta

En esta sección, se abordan las diferencias que existen en la sintaxis de consultas en Snowflake y en BigQuery.

Declaración SELECT

La mayoría de las declaraciones SELECT de Snowflake son compatibles con BigQuery. En la siguiente tabla, se incluye una lista de diferencias menores.

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


Nota: Snowflake admite la creación y referencia de un alias en la misma declaración 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)

Los identificadores y alias de Snowflake no distinguen entre mayúsculas y minúsculas de forma predeterminada. Para conservar las mayúsculas, escribe identificadores y alias con comillas dobles (“”).

Cláusula FROM

Una cláusula FROM en una consulta especifica las posibles tablas, vistas, subconsultas o funciones de tabla para usar en una declaración SELECT. BigQuery admite todas estas referencias de tabla.

En la siguiente tabla, se incluye una lista de diferencias menores.

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


Nota: BigQuery no tiene una alternativa directa al Snowflake de ANTES de usar un ID de instrucción. El valor de timestamp no puede ser más de 7 días antes de la marca de tiempo actual.

@[namespace]<stage_name>[/path]

BigQuery no admite el concepto de archivos almacenados en etapa intermedia.

SELECT*

FROM table

START WITH predicate

CONNECT BY

[PRIOR] col1 = [PRIOR] col2

[, ...]

...

BigQuery no ofrece una alternativa directa a CONNECT BY de Snowflake.

Se puede hacer referencia a las tablas de BigQuery en la cláusula FROM de las siguientes maneras:

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

BigQuery también admite referencias de tabla adicionales:

  • Versiones históricas de la definición y las filas de la tabla con FOR SYSTEM_TIME AS OF
  • Rutas de campo o cualquier ruta que se resuelva en un campo dentro de un tipo de datos (es decir, un STRUCT)
  • Arrays planos.

Cláusula WHERE

La cláusula WHERE de Snowflake y la cláusula WHERE de BigQuery son idénticas, excepto por los siguientes detalles:

Snowflake BigQuery

SELECT col1, col2 FROM table1, table2 WHERE col1 = col2(+)

SELECT col1, col2
FROM table1 INNER JOIN table2
ON col1 = col2

Nota: BigQuery no admite la sintaxis de (+) para JOINs

JOIN tipos

Snowflake y BigQuery admiten los siguientes tipos de unión:

Snowflake y BigQuery admiten las cláusulas ON y USING.

En la siguiente tabla, se incluye una lista de diferencias menores.

Snowflake BigQuery

SELECT col1

FROM table1

NATURAL JOIN

table2

SELECT col1

FROM table1

INNER JOIN

table2

USING (col1, col2 [, ...])


Nota: En BigQuery, las cláusulas JOIN requieren una condición JOIN, a menos que sea una CROSS JOIN o una de las tablas unidas es un campo dentro de un tipo de datos o un array.

SELECT ... FROM table1 AS t1, LATERAL ( SELECT*

FROM table2 AS t2

WHERE t1.col = t2.col )


Nota: A diferencia del resultado de una unión no lateral, el resultado de una unión lateral incluye solo las filas generadas desde la vista en línea. No es necesario que las filas del lado izquierdo se unan a la derecha porque las filas del lado izquierdo ya se tomaron en cuenta cuando se pasaron a la vista en línea.

SELECT ... FROM table1 as t1 LEFT JOIN table2 as t2

ON t1.col = t2.col

Nota: BigQuery no admite una alternativa directa a los LATERAL JOIN.

Cláusula WITH

Una cláusula WITH de BigQuery contiene una o más subconsultas con nombre que se ejecutan cada vez que una declaración SELECT posterior hace referencia a estas. Las cláusulas WITH de Snowflake se comportan de la misma manera que BigQuery, excepto que BigQuery no admite WITH RECURSIVE.

Cláusula GROUP BY

Las cláusulas GROUP BY de Snowflake admiten GROUP BY, GROUP BY ROLLUP, GROUP BY GROUPING SETS yGROUP BY CUBE, mientras que las cláusulas GROUP BY de BigQuery admiten GROUP BY, GROUP BY ALL, GROUP BY ROLLUP, GROUP BY GROUPING SETS yGROUP BY CUBE.

Snowflake HAVING y BigQuery HAVING son sinónimos. Ten en cuenta que HAVING ocurre después de GROUP BY y de la agregación y 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)


Nota: Snowflake permite hasta 128 conjuntos de agrupación en el mismo bloque de consulta

SELECT col1 as one, col2 as two

FROM table GROUP BY GROUPING SETS (one, 2)

SELECT col1 as one, col2 as two

FROM table GROUP BY CUBE (one,2)


Nota: Snowflake permite hasta 7 elementos (128 conjuntos de agrupación) en cada cubo.

SELECT col1 as one, col2 as two

FROM table GROUP BY CUBE (one, 2)

Cláusula ORDER BY

Existen algunas diferencias menores entre las cláusulas ORDER BY de Snowflake y las cláusulas ORDER BY de BigQuery.

Snowflake BigQuery
En Snowflake, los NULL se clasifican en último lugar de forma predeterminada (orden ascendente). En BigQuery, los NULLS se clasifican primero de forma predeterminada (orden ascendente).
Puedes especificar si los valores NULL deben ordenarse primero o en último lugar mediante NULLS FIRST o NULLS LAST, respectivamente. No hay equivalente para especificar si los valores NULL deben ser primeros o últimos en BigQuery.

Cláusula LIMIT/FETCH

La cláusula LIMIT/FETCH en Snowflake restringe la cantidad máxima de filas que muestra una declaración o subconsulta. LIMIT (sintaxis de Postgres) y FETCH (sintaxis ANSI) producen el mismo resultado.

En Snowflake y BigQuery, aplicar una cláusula LIMIT a una consulta no afecta la cantidad de datos leídos.

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]


Nota: Se aceptan los valores $$$$ , de cadena vacía ('')NULL y se tratan como "ilimitados". El uso principal es para conectores y controladores.

SELECT col1, col2

FROM table

ORDER BY col1

LIMIT count OFFSET start


NOTA: BigQuery no es compatible con FETCH. LIMIT reemplaza a FETCH.

Nota: En BigQuery, se debe usar OFFSET junto con una cantidad de LIMIT count. Asegúrate de configurar el valor INT64 count como el mínimo de filas ordenadas necesarias para obtener el mejor rendimiento. Si ordenas todas las filas de resultados de forma innecesaria, empeorará el rendimiento de la ejecución de consultas.

Cláusula QUALIFY

La cláusula QUALIFY en Snowflake te permite filtrar resultados para funciones analíticas similares a lo que hace HAVING con funciones agregadas y cláusulas GROUP BY.

Snowflake BigQuery

SELECT col1, col2 FROM table QUALIFY ROW_NUMBER() OVER (PARTITION BY col1 ORDER BY col2) = 1;

La cláusula QUALIFY de Snowflake con una función analítica como ROW_NUMBER(), COUNT() y conOVER PARTITION BY se expresa en BigQuery como una cláusula WHERE en la subconsulta que contiene el valor analítico.

Usando ROW_NUMBER():

SELECT col1, col2

FROM ( SELECT col1, col2

ROW NUMBER() OVER (PARTITION BY col1 ORDER by col2) RN FROM table ) WHERE RN = 1;


Usa ARRAY_AGG(), que admite particiones más grandes:

SELECT result.* FROM ( SELECT ARRAY_AGG(table ORDER BY table.col2 DESC LIMIT 1) [OFFSET(0)] FROM table

GROUP BY col1 ) AS result;

Funciones

En las siguientes secciones, se enumeran las funciones de Snowflake y sus equivalentes de BigQuery.

Funciones de agregación

En la siguiente tabla, se muestran las asignaciones entre las funciones comunes de agregación, analítica agregada y agregación de Snowflake aproximada con sus equivalentes de BigQuery.

Snowflake BigQuery

ANY_VALUE([DISTINCT] expression) [OVER ...]


Nota: DISTINCT no tiene ningún efecto.

ANY_VALUE(expression) [OVER ...]

APPROX_COUNT_DISTINCT([DISTINCT] expression) [OVER ...]


Nota: DISTINCT no tiene ningún efecto.

APPROX_COUNT_DISTINCT(expression)


Nota: BigQuery no es compatible con APPROX_COUNT_DISTINCT con funciones analíticas.

APPROX_PERCENTILE(expression, percentile) [OVER ...]


Nota: Snowflake no tiene la opción RESPECT NULLS

APPROX_QUANTILES([DISTINCT] expression,100) [OFFSET((CAST(TRUNC(percentile * 100) as INT64))]


Nota: BigQuery no es compatible con APPROX_QUANTILES con funciones analíticas.

APPROX_PERCENTILE_ACCUMULATE (expression)

BigQuery no admite la capacidad de almacenar el estado intermedio cuando se predicen valores aproximados.

APPROX_PERCENTILE_COMBINE(state)

BigQuery no admite la capacidad de almacenar el estado intermedio cuando se predicen valores aproximados.

APPROX_PERCENTILE_ESTIMATE(state, percentile)

BigQuery no admite la capacidad de almacenar el estado intermedio cuando se predicen valores aproximados.

APPROX_TOP_K(expression, [number [counters]]


Nota: Si no se especifica un parámetro numérico, el valor predeterminado es 1. Los contadores deben ser significativamente mayores que el número.

APPROX_TOP_COUNT(expression, number)


Nota: BigQuery no es compatible con APPROX_TOP_COUNT con funciones analíticas.

APPROX_TOP_K_ACCUMULATE(expression, counters)

BigQuery no admite la capacidad de almacenar el estado intermedio cuando se predicen valores aproximados.

APPROX_TOP_K_COMBINE(state, [counters])

BigQuery no admite la capacidad de almacenar el estado intermedio cuando se predicen valores aproximados.

APPROX_TOP_K_ESTIMATE(state, [k])

BigQuery no admite la capacidad de almacenar el estado intermedio cuando se predicen valores aproximados.

APPROXIMATE_JACCARD_INDEX([DISTINCT] expression)


Puedes usar una UDF personalizada para implementar MINHASH con funciones hash distintas de k. Otro enfoque para reducir la varianza en MINHASH es mantener
k de los valores mínimos de una función hash. En este caso, el índice de Jaccard puede aproximarse de la siguiente manera:

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)


Es un sinónimo de APPROXIMATE_JACCARD_INDEX y se puede implementar de la misma manera.

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


Nota: AVG de BigQuery no realiza la conversión automática en STRING.

BITAND_AGG(expression)

[OVER ...]

BIT_AND(expression) [OVER ...]

Nota: Nota: BigQuery no convierte de manera implícita las columnas de caracteres o texto en el INTEGER más cercano.

BITOR_AGG(expression)

[OVER ...]

BIT_OR(expression)

[OVER ...]


Nota: BigQuery no convierte de manera implícita las columnas de caracteres o texto en el INTEGER más cercano.

BITXOR_AGG([DISTINCT] expression) [OVER ...]

BIT_XOR([DISTINCT] expression) [OVER ...]


Nota: BigQuery no convierte de manera implícita las columnas de caracteres o texto en el INTEGER más cercano.

BOOLAND_AGG(expression) [OVER ...]


Nota: Snowflake permite que los valores numéricos, decimales y de punto flotante se traten como TRUE si no es cero.

LOGICAL_AND(expression)

[OVER ...]

BOOLOR_AGG(expression)

[OVER ...]


Nota: Snowflake permite que los valores numéricos, decimales y de punto flotante se traten como TRUE si no es cero.

LOGICAL_OR(expression)

[OVER ...]

BOOLXOR_AGG(expression)

[OVER ([PARTITION BY <partition_expr> ])


Nota: Snowflake permite que los valores numéricos, decimales y de punto flotante se traten como TRUE si no es cero.
Para la expresión 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, puedes ejecutar lo siguiente (se proporciona un ejemplo booleano):

SELECT

CASE COUNT(expression) OVER (PARTITION BY partition_expr)

WHEN 0 THEN NULL

ELSE

CASE COUNT(

CASE expression

WHEN TRUE THEN 1

END) OVER (PARTITION BY partition_expr)

WHEN 1 THEN TRUE

ELSE FALSE

END

END AS BOOLXOR_AGG

FROM T

CORR(dependent, independent)

[OVER ...]

CORR(dependent, independent)

[OVER ...]

COUNT([DISTINCT] expression [,expression2]) [OVER ...]

COUNT([DISTINCT] expression [,expression2]) [OVER ...]

COVAR_POP(dependent, independent) [OVER ...]

COVAR_POP(dependent, independent) [OVER ...]

COVAR_SAMP(dependent, independent)

[OVER ...]

COVAR_SAMP(dependent, independent)

[OVER ...]

GROUPING(expression1, [,expression2...])

BigQuery no tiene una alternativa directa a GROUPING de Snowflake. Disponible a través de una función definida por el usuario.

GROUPING_ID(expression1, [,expression2...])

BigQuery no tiene una alternativa directa a GROUPING_ID de Snowflake. Disponible a través de una función definida por el usuario.

HASH_AGG([DISTINCT] expression1, [,expression2])

[OVER ...]

SELECT
BIT_XOR(
FARM_FINGERPRINT(
TO_JSON_STRING(t))) [OVER]
FROM t

SELECT HLL([DISTINCT] expression1, [,expression2])

[OVER ...]


Nota: Snowflake no te permite especificar la precisión.

SELECT HLL_COUNT.EXTRACT(sketch) FROM (

SELECT HLL_COUNT.INIT(expression)

AS sketch FROM table )


Nota: BigQuery no es compatible con HLL_COUNT… con funciones analíticas. Un usuario no puede incluir varias expresiones en una sola función HLL_COUNT....

HLL_ACCUMULATE([DISTINCT] expression)


Nota: Snowflake no te permite especificar la precisión.
HLL_COUNT.INIT(expression [, precision])

HLL_COMBINE([DISTINCT] state)

HLL_COUNT.MERGE_PARTIAL(boceto)

HLL_ESTIMATE(state)

HLL_COUNT.EXTRACT(sketch)

HLL_EXPORT(binary)

BigQuery no tiene una alternativa directa a HLL_EXPORT de Snowflake.

HLL_IMPORT(object)

BigQuery no tiene una alternativa directa a HLL_IMPORT de Snowflake.

KURTOSIS(expression)

[OVER ...]

BigQuery no tiene una alternativa directa a KURTOSIS de Snowflake.

LISTAGG(

[DISTINCT] aggregate_expression

[, delimiter]

)

[OVER ...]

STRING_AGG(

[DISTINCT] aggregate_expression

[, delimiter]

)

[OVER ...]

MEDIAN(expression) [OVER ...]


Nota: Snowflake no admite la capacidad de IGNORE|RESPECT NULLS ni de LIMIT directamente en 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)

Puedes usar una UDF personalizada para implementar MINHASH con funciones hash distintas de k. Otro enfoque para reducir la varianza en MINHASH es mantener k de los valores mínimos de una función hash: SELECT DISTINCT
FARM_FINGERPRINT(
TO_JSON_STRING(t)) AS MINHASH

FROM t

ORDER BY MINHASH

LIMIT k

MINHASH_COMBINE([DISTINCT] state)

<code<select
FROM (
SELECT DISTINCT
FARM_FINGERPRINT(
TO_JSON_STRING(t)) AS h
FROM TA AS t
ORDER BY h
LIMIT k
UNION
SELECT DISTINCT
FARM_FINGERPRINT(
TO_JSON_STRING(t)) AS h
FROM TB AS t
ORDER BY h
LIMIT k
)
ORDER BY h
LIMIT k

MODE(expr1)

OVER ( [ PARTITION BY <expr2> ] )

SELECT expr1

FROM (

SELECT

expr1,

ROW_NUMBER() OVER (

PARTITION BY expr2

ORDER BY cnt DESC) rn

FROM (

SELECT

expr1,

expr2,

COUNTIF(expr1 IS NOT NULL) OVER

(PARTITION BY expr2, expr1) cnt

FROM t))

WHERE rn = 1

OBJECT_AGG(key, value) [OVER ...]

Puedes considerar usar TO_JSON_STRING para convertir un valor en una cadena con formato JSON.

PERCENTILE_CONT(percentile) WITHIN GROUP (ORDER BY value_expression)

[OVER ...]

PERCENTILE_CONT(

value_expression,

percentile

[ {RESPECT | IGNORE} NULLS]

) OVER()

PERCENTILE_DISC(percentile) WITHIN GROUP (ORDER BY value_expression)

[OVER ...]

PERCENTILE_DISC(

value_expression,

percentile

[ {RESPECT | IGNORE} NULLS]

) OVER()

REGR_AVGX(dependent, independent)

[OVER ...]

SELECT AVG(independent) [OVER ...]

FROM table

WHERE (

(dependent IS NOT NULL) AND

(independent IS NOT NULL)

)

REGR_AVGY(dependent, independent)

[OVER ...]

SELECT AVG(dependent) [OVER ...]

FROM table

WHERE (

(dependent IS NOT NULL) AND

(independent IS NOT NULL)

)

REGR_COUNT(dependent, independent)

[OVER ...]

SELECT COUNT(*) [OVER ...]

FROM table

WHERE (

(dependent IS NOT NULL) AND

(independent IS NOT NULL)

)

REGR_INTERCEPT(dependent, independent)

[OVER ...]

SELECT

AVG(dependent) -

COVAR_POP(dependent,independent)/

VAR_POP(dependent) *

AVG(independent)

[OVER ...]

FROM table

WHERE (

(dependent IS NOT NULL) AND

(independent IS NOT NULL)

)

[GROUP BY ...]

REGR_R2(dependent, independent)

[OVER ...]

SELECT

CASE

WHEN VAR_POP(independent) = 0

THEN NULL

WHEN VAR_POP(dependent) = 0 AND VAR_POP(independent) != 0

THEN 1

ELSE POWER(CORR(dependent, independent), 2)

END AS ...

FROM table

WHERE (

(dependent IS NOT NULL) AND

(independent IS NOT NULL)

)

[GROUP BY ...]

REGR_SLOPE(dependent, independent)

[OVER ...]

SELECT

COVAR_POP(dependent,independent)/

VAR_POP(dependent)

[OVER ...]

FROM table

WHERE (

(dependent IS NOT NULL) AND

(independent IS NOT NULL)

)

[GROUP BY ...]

REGR_SXX(dependent, independent)

[OVER ...]

SELECT COUNT(*)*VAR_POP(independent)

[OVER ...]

FROM table

WHERE (

(dependent IS NOT NULL) AND

(independent IS NOT NULL)

)

[GROUP BY ...]

REGR_SYY(dependent, independent)

[OVER ...]

SELECT COUNT(*)*VAR_POP(dependent)

[OVER ...]

FROM table

WHERE (

(dependent IS NOT NULL) AND

(independent IS NOT NULL)

)

[GROUP BY ...]

SKEW(expression)

BigQuery no tiene una alternativa directa a SKEW de Snowflake.

STDDEV([DISTINCT] expression)

[OVER ...]

STDDEV([DISTINCT] expression)

[OVER ...]

STDDEV_POP([DISTINCT] expression)

[OVER ...]

STDDEV_POP([DISTINCT] expression)

[OVER ...]

STDDEV_SAMP([DISTINCT] expression)

[OVER ...]

STDDEV_SAMP([DISTINCT] expression)

[OVER ...]

SUM([DISTINCT] expression)

[OVER ...]

SUM([DISTINCT] expression)

[OVER ...]

VAR_POP([DISTINCT] expression)

[OVER ...]


Nota: Snowflake admite la capacidad de convertir VARCHAR en valores de punto flotante.

VAR_POP([DISTINCT] expression)

[OVER ...]

VARIANCE_POP([DISTINCT] expression)

[OVER ...]


Nota: Snowflake admite la capacidad de convertir VARCHAR en valores de punto flotante.

VAR_POP([DISTINCT] expression)

[OVER ...]

VAR_SAMP([DISTINCT] expression)

[OVER ...]


Nota: Snowflake admite la capacidad de convertir VARCHAR en valores de punto flotante.

VAR_SAMP([DISTINCT] expression)

[OVER ...]

VARIANCE([DISTINCT] expression)

[OVER ...]


Nota: Snowflake admite la capacidad de convertir VARCHAR en valores de punto flotante.

VARIANCE([DISTINCT] expression)

[OVER ...]

BigQuery también ofrece las siguientes funciones de agregación, analítica agregada y agregación aproximada, que no tienen un análogo directo en Snowflake:

Funciones de expresión a nivel de bits

En la siguiente tabla, se muestran las asignaciones entre las funciones comunes de expresión de bits del Snowflake con sus equivalentes de BigQuery.

Si el tipo de datos de una expresión no es INTEGER, Snowflake intenta convertir en INTEGER. Sin embargo, BigQuery no intenta convertir en INTEGER.

Snowflake BigQuery

BITAND(expression1, expression2)

BIT_AND(x) FROM UNNEST([expression1, expression2]) AS x expression1 & expression2

BITNOT(expression)

~ expression

BITOR(expression1, expression2)

BIT_OR(x) FROM UNNEST([expression1, expression2]) AS x


expression1 | expression2

BITSHIFTLEFT (expression, n)

expression << n

BITSHIFTRIGHT

(expression, n)

expression >> n

BITXOR(expression, expression)


Nota: Snowflake no es compatible con DISTINCT.

BIT_XOR([DISTINCT] x) FROM UNNEST([expression1, expression2]) AS x


expression ^ expression

Funciones de expresión condicional

En la siguiente tabla, se muestran las asignaciones entre expresiones condicionales comunes del Snowflake con sus equivalentes de BigQuery.

Snowflake BigQuery

expression [ NOT ] BETWEEN lower AND upper

(expression >= lower AND expression <= upper)

BOOLAND(expression1, expression2)


Nota: Snowflake permite que los valores numéricos, decimales y de punto flotante se traten como TRUE si no es cero.

LOGICAL_AND(x)

FROM UNNEST([expression1, expression2]) AS x


expression1 AND expression2

BOOLNOT(expression1)


Nota: Snowflake permite que los valores numéricos, decimales y de punto flotante se traten como TRUE si no es cero.

NOT expression

BOOLOR

Nota: Snowflake permite que los valores numéricos, decimales y de punto flotante se traten como TRUE si no es cero.

LOGICAL_OR(x) FROM UNNEST([expression1, expression2]) AS x


expression1 OR expression2

BOOLXOR

Nota: Snowflake permite que los valores numéricos, decimales y de punto flotante se traten como TRUE si no es cero.
BigQuery no tiene una alternativa directa a BOOLXOR. de Snowflake.

CASE [expression] WHEN condition1 THEN result1 [WHEN condition2 THEN result2]

[...]

[ELSE result3]

END

CASE [expression] WHEN condition1 THEN result1 [WHEN condition2 THEN result2]

[...]

[ELSE result3]

END

COALESCE(expr1, expr2, [,...])


Nota: Snowflake requiere al menos dos expresiones. BigQuery solo requiere una.

COALESCE(expr1, [,...])

DECODE(expression, search1, result1, [search2, result2...] [,default])

CASE [expression] WHEN condition1 THEN result1 [WHEN condition2 THEN result2]

[...]

[ELSE result3]

END

Nota: BigQuery admite subconsultas en las declaraciones de condición. Se puede usar para reproducir el objeto DECODE de Snowflake. El usuario debe usar IS NULL en lugar de = NULL para hacer coincidir expresiones de selección de NULL con expresiones de búsqueda NULL.

EQUAL_NULL(expression1, expression2)

BigQuery no tiene una alternativa directa a EQUAL_NULL. de Snowflake.

GREATEST(expression1, [,expression2]...)

GREATEST(expression1, [,expression2]...)

IFF(condition, true_result, false_result)

IF(condition, true_result, false_result)

IFNULL(expression1, expression2)

IFNULL(expression1, expression2)

[ NOT ] IN ...

[ NOT ] IN ...

expression1 IS [ NOT ] DISTINCT FROM expression2

BigQuery no tiene una alternativa directa a IS [ NOT ] DISTINCT FROM. de Snowflake.

expression IS [ NOT ] NULL

expression IS [ NOT ] NULL

IS_NULL_VALUE(variant_expr)

BigQuery no admite tipos de datos 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)

Nota: BigQuery no admite una alternativa directa a las funciones REGR... de Snowflake.

REGR_VALY(expr1,expr2)

IF(expr2 IS NULL, NULL, expr1)


Nota: BigQuery no admite una alternativa directa a las funciones REGR... de Snowflake.

ZEROIFNULL(expression)

IFNULL(expression,0)

Funciones de contexto

En la siguiente tabla, se muestran las asignaciones entre las funciones de contexto comunes de Snowflake con sus equivalentes de BigQuery.

Snowflake BigQuery

CURRENT_ACCOUNT()

SESSION_USER()


Nota: No es una comparación directa. Snowflake muestra el ID de la cuenta, BigQuery muestra la dirección de correo electrónico del usuario.

CURRENT_CLIENT()

El concepto no se usa en BigQuery

CURRENT_DATABASE()

SELECT catalog_name

FROM INFORMATION_SCHEMA.SCHEMATA

Esto muestra una tabla de nombres de proyectos. No es una comparación directa.

CURRENT_DATE[()]


Nota: Snowflake no aplica “()” después del comando CURRENT_DATE para cumplir con los estándares ANSI.

CURRENT_DATE([timezone])


Nota: CURRENT_DATE de BigQuery admite la especificación opcional de zona horaria.

CURRENT_REGION()

SELECT location

FROM INFORMATION_SCHEMA.SCHEMATA


Nota: INFORMATION_SCHEMA.SCHEMATA de BigQuery muestra referencias de ubicación más generalizadas que CURRENT_REGION() de Snowflake. No es una comparación directa.

CURRENT_ROLE()

El concepto no se usa en BigQuery

CURRENT_SCHEMA()

SELECT schema_name

FROM INFORMATION_SCHEMA.SCHEMATA

Esto muestra una tabla de todos los conjuntos de datos (también llamados esquemas) disponibles en el proyecto o la región. No es una comparación directa.

CURRENT_SCHEMAS()

El concepto no se usa en BigQuery

CURRENT_SESSION()

El concepto no se usa en BigQuery

CURRENT_STATEMENT()

SELECT query

FROM INFORMATION_SCHEMA.JOBS_BY_*


Nota: INFORMATION_SCHEMA.JOBS_BY_* de BigQuery permite buscar consultas por tipo de trabajo, tipo de inicio/finalización, etcétera.

CURRENT_TIME[([frac_sec_prec])]


Nota: Snowflake permite una precisión de segundos fraccionarios opcional. Los valores válidos van de 0 a 9 nanosegundos. El valor predeterminado es 9. Para cumplir con el ANSI, se puede llamar sin “()”.

CURRENT_TIME()

CURRENT_TIMESTAMP[([frac_sec_prec])]


Nota: Snowflake permite una precisión de segundos fraccionarios opcional. Los valores válidos van de 0 a 9 nanosegundos. El valor predeterminado es 9. Para cumplir con el ANSI, se puede llamar sin “()”. Configura TIMEZONE como un parámetro de sesión.

CURRENT_DATETIME([timezone]) CURRENT_TIMESTAMP()


Nota: CURRENT_DATETIME muestra el tipo de datos DATETIME (no compatible con Snowflake). CURRENT_TIMESTAMP muestra tipos de datos TIMESTAMP:

CURRENT_TRANSACTION()

SELECT job_id

FROM INFORMATION_SCHEMA.JOBS_BY_*

Nota: INFORMATION_SCHEMA.JOBS_BY_* de BigQuery permite buscar IDs de trabajo por tipo de trabajo, tipo de inicio y finalización, etcétera.

CURRENT_USER[()]


Nota: Snowflake no aplica “()” después del comando CURRENT_USER para cumplir con los estándares ANSI.

SESSION_USER()


SELECT user_email

FROM INFORMATION_SCHEMA.JOBS_BY_*

Nota: No es una comparación directa. Snowflake muestra el nombre de usuario; BigQuery muestra la dirección de correo electrónico del usuario.

CURRENT_VERSION()

El concepto no se usa en BigQuery

CURRENT_WAREHOUSE()

SELECT catalg_name

FROM INFORMATION_SCHEMA.SCHEMATA

LAST_QUERY_ID([num])

SELECT job_id

FROM INFORMATION_SCHEMA.JOBS_BY_*


Nota: INFORMATION_SCHEMA.JOBS_BY_* de BigQuery permite buscar IDs de trabajo por tipo de trabajo, tipo de inicio y finalización, etcétera.

LAST_TRANSACTION()

SELECT job_id

FROM INFORMATION_SCHEMA.JOBS_BY_*


Nota: INFORMATION_SCHEMA.JOBS_BY_* de BigQuery permite buscar IDs de trabajo por tipo de trabajo, tipo de inicio y finalización, etcétera.

LOCALTIME()


Nota: Snowflake no aplica “()” después del comando LOCALTIME para cumplir con los estándares ANSI.

CURRENT_TIME()

LOCALTIMESTAMP()

CURRENT_DATETIME([timezone]) CURRENT_TIMESTAMP()


Nota: CURRENT_DATETIME muestra el tipo de datos DATETIME (no compatible con Snowflake). CURRENT_TIMESTAMP muestra tipos de datos TIMESTAMP:

Funciones de conversión

En la siguiente tabla, se muestran las asignaciones entre las funciones de conversión comunes de Snowflake con sus equivalentes de BigQuery.

Ten en cuenta que las funciones que parecen idénticas en Snowflake y BigQuery pueden mostrar diferentes tipos de datos.

Snowflake BigQuery

CAST(expression AS type)


expression :: type

CAST(expression AS type)

TO_ARRAY(expression)

[expression]


ARRAY(subquery)

TO_BINARY(expression[, format])


Nota: Snowflake admite la conversión HEX, BASE64 y UTF-8. Snowflake también admite TO_BINARY mediante el tipo de datos VARIANT. BigQuery no tiene una alternativa al tipo de datos VARIANT.

TO_HEX(CAST(expression AS BYTES)) TO_BASE64(CAST(expression AS BYTES))

CAST(expression AS BYTES)


Nota: La conversión de STRING predeterminada de BigQuery usa la codificación UTF-8. Snowflake no tiene una opción para admitir la codificación BASE32.

TO_BOOLEAN(expression)


Nota:
  • INT64
    TRUE:
    de lo contrario, FALSE: 0
  • STRING
    TRUE: "true"/"t"/"yes"/"y"/"on"/"1", FALSE: "false"/"f"/"no"/"n"/"off"/"0"

CAST(expression AS BOOL)


Nota:
  • INT64
    TRUE:
    de lo contrario, FALSE: 0
  • STRING
    TRUE: "true", FALSE: "false"

TO_CHAR(expression[, format])


TO_VARCHAR(expression[, format])


Nota: Los modelos de formato de Snowflake se pueden encontrar aquí. BigQuery no tiene una alternativa al tipo de datos VARIANT.

CAST(expression AS STRING)


Nota: La expresión de entrada de BigQuery puede formatearse con FORMAT_DATE, FORMAT_DATETIME, FORMAT_TIME o FORMAT_TIMESTAMP.

TO_DATE(expression[, format])


DATE(expression[, format])


Nota: Snowflake admite la capacidad de convertir directamente tipos INTEGER a tipos DATE. Los modelos de formato de Snowflake se pueden encontrar aquí. BigQuery no tiene una alternativa al tipo de datos VARIANT.

CAST(expression AS DATE)


Nota: La expresión de entrada de BigQuery puede formatearse con FORMAT, FORMAT_DATETIME o FORMAT_TIMESTAMP.

TO_DECIMAL(expression[, format]

[,precision[, scale]]


TO_NUMBER(expression[, format]

[,precision[, scale]]


TO_NUMERIC(expression[, format]

[,precision[, scale]]


Nota: Los modelos de formato de Snowflake para los tipos de datos DECIMAL, NUMBER y NUMERIC se pueden encontrar aquí. BigQuery no tiene una alternativa al tipo de datos VARIANT.

ROUND(CAST(expression AS NUMERIC)

, x)


Nota: La expresión de entrada de BigQuery puede formatearse con FORMAT.

TO_DOUBLE(expression[, format])


Nota: Los modelos de formato de Snowflake para los tipos de datos DOUBLE se pueden encontrar aquí. BigQuery no tiene una alternativa al tipo de datos VARIANT.

CAST(expression AS FLOAT64)


Nota: La expresión de entrada de BigQuery puede formatearse con FORMAT.

TO_JSON(variant_expression)

BigQuery no tiene una alternativa al tipo de datos VARIANT de Snowflake.

TO_OBJECT(variant_expression)

BigQuery no tiene una alternativa al tipo de datos VARIANT de Snowflake.

TO_TIME(expression[, format])


TIME(expression[, format])


Nota: Los modelos de formato de Snowflake para los tipos de datos STRING se pueden encontrar aquí. BigQuery no tiene una alternativa al tipo de datos VARIANT.

CAST(expression AS TIME)


Nota: BigQuery no tiene una alternativa al tipo de datos VARIANT del Snowflake. La expresión de entrada de BigQuery puede formatearse con FORMAT, FORMAT_DATETIME, FORMAT_TIMESTAMP o FORMAT_TIME.

TO_TIMESTAMP(expression[, scale])


TO_TIMESTAMP_LTZ(expression[, scale])


TO_TIMESTAMP_NTZ(expression[, scale])


TO_TIMESTAMP_TZ(expression[, scale])


Nota: BigQuery no tiene una alternativa al tipo de datos VARIANT.

CAST(expression AS TIMESTAMP)


Nota: La expresión de entrada de BigQuery puede formatearse con FORMAT, FORMAT_DATE, FORMAT_DATETIME y FORMAT_TIME. La zona horaria se puede incluir o no incluir mediante los parámetros de FORMAT_TIMESTAMP.

TO_VARIANT(expression)

BigQuery no tiene una alternativa al tipo de datos VARIANT de Snowflake.

TO_XML(variant_expression)

BigQuery no tiene una alternativa al tipo de datos VARIANT de Snowflake.

TRY_CAST(expression AS type)

SAFE_CAST(expression AS type)

TRY_TO_BINARY(expression[, format])

TO_HEX(SAFE_CAST(expression AS BYTES)) TO_BASE64(SAFE_CAST(expression AS BYTES))

SAFE_CAST(expression AS BYTES)

TRY_TO_BOOLEAN(expression)

SAFE_CAST(expression AS BOOL)

TRY_TO_DATE(expression)

SAFE_CAST(expression AS DATE)

TRY_TO_DECIMAL(expression[, format]

[,precision[, scale]]


TRY_TO_NUMBER(expression[, format]

[,precision[, scale]]


TRY_TO_NUMERIC(expression[, format]

[,precision[, scale]]

ROUND(

SAFE_CAST(expression AS NUMERIC)

, x)

TRY_TO_DOUBLE(expression)

SAFE_CAST(expression AS FLOAT64)

TRY_TO_TIME(expression)

SAFE_CAST(expression AS TIME)

TRY_TO_TIMESTAMP(expression)


TRY_TO_TIMESTAMP_LTZ(expression)


TRY_TO_TIMESTAMP_NTZ(expression)


TRY_TO_TIMESTAMP_TZ(expression)

SAFE_CAST(expression AS TIMESTAMP)

BigQuery también ofrece las siguientes funciones de conversión, que no tienen un análogo directo en Snowflake:

Funciones de generación de datos

En la siguiente tabla, se muestran las asignaciones entre las funciones comunes de generación de datos de Snowflake con sus equivalentes de BigQuery.

Snowflake BigQuery

NORMAL(mean, stddev, gen)

BigQuery no admite una comparación directa con NORMAL. de Snowflake.

RANDOM([seed])

IF(RAND()>0.5, CAST(RAND()*POW(10, 18) AS INT64),

(-1)*CAST(RAND()*POW(10, 18) AS

INT64))


Nota: BigQuery no admite la propagación

RANDSTR(length, gen)

BigQuery no admite una comparación directa con RANDSTR. de Snowflake.
SEQ1 / SEQ2 / SEQ4 / SEQ8 BigQuery no admite una comparación directa con SEQ_. de Snowflake.

UNIFORM(min, max, gen)

CAST(min + RAND()*(max-min) AS INT64)


Nota: Usa UDF persistentes para crear un equivalente al UNIFORM de Snowflake. Ejemplo aquí.
UUID_STRING([uuid, name])

Nota: Snowflake muestra 128 bits aleatorios. Snowflake admite los UUID de la versión 4 (aleatorio) y de la versión 5 (con nombre).

GENERATE_UUID()


Nota: BigQuery muestra 122 bits aleatorios. BigQuery solo es compatible con los UUID de la versión 4.

ZIPF(s, N, gen)

BigQuery no admite una comparación directa con ZIPF. de Snowflake.

Funciones de fecha y hora

En la siguiente tabla, se muestran las asignaciones entre las funciones comunes de fecha y hora de Snowflake con sus equivalentes de BigQuery. Las funciones de tiempo y datos de BigQuery incluyen funciones de fecha, funciones de fecha y hora, funciones de tiempo y funciones de marca de tiempo.

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

)

)


Nota: source_timezone siempre es UTC en BigQuery

DATE_FROM_PARTS(year, month, day)


Nota: Snowflake admite desbordamiento y fechas negativas. Por ejemplo, DATE_FROM_PARTS(2000, 1 + 24, 1) devuelve el 1 de enero de 2002. Esto no es compatible con BigQuery.

DATE(year, month, day)


DATE(timestamp_expression[, timezone])


DATE(datetime_expression)

DATE_PART(part, dateOrTime)


Nota: Snowflake admite los tipos de parte de día de la semana ISO, nanosegundo y segundo/milisegundo/microsegundo/nanosegundo del ciclo de entrenamiento. BigQuery no lo hace. Consulta la lista completa de tipos de partes de Snowflake aquí.

EXTRACT(part FROM dateOrTime)


Nota: BigQuery admite los tipos de parte de semana(<weekday>), microsegundo y milisegundo. Snowflake no lo hace. Consulta la lista completa de tipos de partes de BigQuery aquí y aquí.

DATE_TRUNC(part, dateOrTime)


Nota: Snowflake admite el tipo de parte de nanosegundo. BigQuery no lo hace. Consulta la lista completa de tipos de partes de Snowflake aquí.

DATE_TRUNC(date, part)


DATETIME_TRUNC(datetime, part)


TIME_TRUNC(time, part)


TIMESTAMP_TRUNC(timestamp, part[, timezone])


Nota: BigQuery es compatible con los tipos de parte de semana(<weekday>), semana ISO y año ISO. Snowflake no lo hace.

DATEADD(part, value, dateOrTime)

DATE_ADD(date, INTERVAL value part)

DATEDIFF(

part,

expression1,

expression2

)


Nota: Snowflake admite el cálculo de la diferencia entre dos tipos de fecha, hora y marca de tiempo en esta función.

DATE_DIFF(

dateExpression1,

dateExpression2,

part

)


DATETIME_DIFF(

datetimeExpression1,

datetimeExpression2,

part

)


TIME_DIFF(

timeExpression1,

timeExpression2,

part

)


TIMESTAMP_DIFF(

timestampExpression1,

timestampExpression2,

part

)


Nota: BigQuery admite los tipos de parte de semana(<weekday>) y año ISO.

DAYNAME(dateOrTimestamp)

FORMAT_DATE('%a', date)


FORMAT_DATETIME('%a', datetime)


FORMAT_TIMESTAMP('%a', timestamp)

EXTRACT(part FROM dateOrTime)


Nota: Snowflake admite los tipos de parte de día de la semana ISO, nanosegundo y segundo/milisegundo/microsegundo/nanosegundo del ciclo de entrenamiento. BigQuery no lo hace. Consulta la lista completa de tipos de partes de Snowflake aquí.

EXTRACT(part FROM dateOrTime)


Nota: BigQuery admite los tipos de parte de semana(<weekday>), microsegundo y milisegundo. Snowflake no lo hace. Consulta la lista completa de tipos de partes de BigQuery aquí y aquí.

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


Nota: Es posible que sea necesario cambiar el formato de dowString. Por ejemplo, “su” de Snowflake será “SUNDAY” en BigQuery.

PREVIOUS_DAY(dateOrTime, dowString)

DATE_TRUNC(

date,

WEEK(dowString)

)


Nota: Es posible que sea necesario cambiar el formato de dowString. Por ejemplo, “su” de Snowflake será “SUNDAY” en BigQuery.

TIME_FROM_PARTS(hour, minute, second[, nanosecond)


Nota: Snowflake admite tiempos de desbordamiento. Por ejemplo, TIME_FROM_PARTS(0, 100, 0) muestra 01:40:00… Esto no es compatible con BigQuery. BigQuery no admite nanosegundos.

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)


Nota: BigQuery no admite una comparación directa y exacta con TIME_SLICE de Snowflake. Usa DATETINE_TRUNC, TIME_TRUNC, TIMESTAMP_TRUNC para el tipo de datos adecuado.

TIMEADD(part, value, dateOrTime)

TIME_ADD(time, INTERVAL value part)

TIMEDIFF(

part,

expression1,

expression2,

)


Nota: Snowflake admite el cálculo de la diferencia entre dos tipos de fecha, hora y marca de tiempo en esta función.

DATE_DIFF(

dateExpression1,

dateExpression2,

part

)


DATETIME_DIFF(

datetimeExpression1,

datetimeExpression2,

part

)


TIME_DIFF(

timeExpression1,

timeExpression2,

part

)


TIMESTAMP_DIFF(

timestampExpression1,

timestampExpression2,

part

)


Nota: BigQuery admite los tipos de parte de semana(<weekday>) y año ISO.

TIMESTAMP_[LTZ, NTZ, TZ _]FROM_PARTS (year, month, day, hour, second [, nanosecond][, timezone])

TIMESTAMP(

string_expression[, timezone] | date_expression[, timezone] |

datetime_expression[, timezone]

)


Nota: BigQuery requiere que las marcas de tiempo se ingresen como tipos STRING. Ejemplo: "2008-12-25 15:30:00"

TIMESTAMPADD(part, value, dateOrTime)

TIMESTAMPADD(timestamp, INTERVAL value part)

TIMESTAMPDIFF(

part,

expression1,

expression2,

)


Nota: Snowflake admite el cálculo de la diferencia entre dos tipos de fecha, hora y marca de tiempo en esta función.

DATE_DIFF(

dateExpression1,

dateExpression2,

part

)


DATETIME_DIFF(

datetimeExpression1,

datetimeExpression2,

part

)


TIME_DIFF(

timeExpression1,

timeExpression2,

part

)


TIMESTAMP_DIFF(

timestampExpression1,

timestampExpression2,

part

)


Nota: BigQuery admite los tipos de parte de semana(<weekday>) y año ISO.

TRUNC(dateOrTime, part)


Nota: Snowflake admite el tipo de parte de nanosegundo. BigQuery no lo hace. Consulta la lista completa de tipos de partes de Snowflake aquí.

DATE_TRUNC(date, part)


DATETIME_TRUNC(datetime, part)


TIME_TRUNC(time, part)


TIMESTAMP_TRUNC(timestamp, part[, timezone])


Nota: BigQuery es compatible con los tipos de parte de semana(<weekday>), semana ISO y año ISO. Snowflake no lo hace.

[YEAR*, DAY*, WEEK*, MONTH, QUARTER](dateOrTimestamp)

EXTRACT(part FROM timestamp [AT THE ZONE timezone])

BigQuery también ofrece las siguientes funciones de fecha y hora, que no tienen un análogo directo en Snowflake:

Esquema de información y funciones de la tabla

BigQuery no admite de manera conceptual muchas de las funciones de la tabla y el esquema de información de Snowflake. Snowflake ofrece el siguiente esquema de información y funciones de la tabla, que no tienen un análogo directo en BigQuery:

A continuación, se muestra una lista de las funciones de tabla y el esquema de información asociados de BigQuery y Snowflake.

Snowflake BigQuery
QUERY_HISTORY

QUERY_HISTORY_BY_*
INFORMATION_SCHEMA.JOBS_BY_*

Nota: No es una alternativa directa.
TASK_HISTORY INFORMATION_SCHEMA.JOBS_BY_*

Nota: No es una alternativa directa.

BigQuery ofrece las siguientes funciones de tabla y esquema de información, que no tienen un análogo directo en Snowflake:

Funciones numéricas

En la siguiente tabla, se muestran las asignaciones entre las funciones numéricas comunes del Snowflake con sus equivalentes de 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)


Nota: CEIL de BigQuery no admite la capacidad de indicar precisión o escalamiento. ROUND no te permite especificar para redondear.

COS(expression)

COS(expression)

COSH(expression)

COSH(expression)

COT(expression)

1/TAN(expression)

DEGREES(expression)

(expression)*(180/ACOS(-1))

EXP(expression)

EXP(expression)

FACTORIAL(expression)

BigQuery no tiene una alternativa directa a FACTORIAL de Snowflake. Usa una función definida por el usuario.

FLOOR(expression [, scale])

FLOOR(expression)


Nota: FLOOR de BigQuery no admite la capacidad de indicar precisión o escalamiento. ROUND no te permite especificar para redondear. TRUNC funciona como sinónimo para números positivos, pero no negativos, ya que evalúa el valor absoluto.

HAVERSINE(lat1, lon1, lat2, lon2)

ST_DISTANCE( ST_GEOGPOINT(lon1, lat1),

ST_GEOGPOINT(lon2, lat2)

)/1000


Nota: No es una coincidencia exacta, pero es lo suficientemente similar.

LN(expression)

LN(expression)

LOG(base, expression)

LOG(expression [,base])


LOG10(expression)


Nota: La base predeterminada para LOG es 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])


Nota: El valor que se muestra de BigQuery debe ser menor que la expresión; no admite igual.

BigQuery también ofrece las siguientes funciones mamáticas, que no tienen un análogo directo en Snowflake:

Funciones de datos semiestructurados

Snowflake BigQuery
ARRAY_APPEND Función personalizada definida por el usuario
ARRAY_CAT ARRAY_CONCAT
ARRAY_COMPACT Función personalizada definida por el usuario
ARRAY_CONSTRUCT [ ]
ARRAY_CONSTRUCT_COMPACT Función personalizada definida por el usuario
ARRAY_CONTAINS Función personalizada definida por el usuario
ARRAY_INSERT Función personalizada definida por el usuario
ARRAY_INTERSECTION Función personalizada definida por el usuario
ARRAY_POSITION Función personalizada definida por el usuario
ARRAY_PREPEND Función personalizada definida por el usuario
ARRAY_SIZE ARRAY_LENGTH
ARRAY_SLICE Función personalizada definida por el usuario
ARRAY_TO_STRING ARRAY_TO_STRING
ARRAYS_OVERLAP Función personalizada definida por el usuario
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 Función personalizada definida por el usuario
CHECK_XML Función personalizada definida por el usuario
FLATTEN UNNEST
GET Función personalizada definida por el usuario
GET_IGNORE_CASE Función personalizada definida por el usuario

GET_PATH , :

Función personalizada definida por el usuario
IS_<object_type> Función personalizada definida por el usuario
IS_ARRAY Función personalizada definida por el usuario
IS_BINARY Función personalizada definida por el usuario
IS_BOOLEAN Función personalizada definida por el usuario
IS_CHAR , IS_VARCHAR Función personalizada definida por el usuario
IS_DATE , IS_DATE_VALUE Función personalizada definida por el usuario
IS_DECIMAL Función personalizada definida por el usuario
IS_DOUBLE , IS_REAL Función personalizada definida por el usuario
IS_INTEGER Función personalizada definida por el usuario
IS_OBJECT Función personalizada definida por el usuario
IS_TIME Función personalizada definida por el usuario
IS_TIMESTAMP_* Función personalizada definida por el usuario
OBJECT_CONSTRUCT Función personalizada definida por el usuario
OBJECT_DELETE Función personalizada definida por el usuario
OBJECT_INSERT Función personalizada definida por el usuario
PARSE_JSON JSON_EXTRACT
PARSE_XML Función personalizada definida por el usuario
STRIP_NULL_VALUE Función personalizada definida por el usuario
STRTOK_TO_ARRAY SPLIT
TRY_PARSE_JSON Función personalizada definida por el usuario
TYPEOF Función personalizada definida por el usuario
XMLGET Función personalizada definida por el usuario

Funciones binarias y de cadena

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 Función personalizada definida por el usuario
COLLATION Función personalizada definida por el usuario
COMPRESS Función personalizada definida por el usuario

CONCAT(string1, string2)

CONCAT(string1, string2)

Nota: CONCAT(…) de BigQuery admite la concatenación de cualquier cantidad de strings
CONTAINS Función personalizada definida por el usuario
DECOMPRESS_BINARY Función personalizada definida por el usuario
DECOMPRESS_STRING Función personalizada definida por el usuario
EDITDISTANCE EDIT_DISTANCE
ENDSWITH Función personalizada definida por el usuario
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 Función personalizada definida por el usuario
ILIKE ANY Función personalizada definida por el usuario
INITCAP INITCAP
INSERT Función personalizada definida por el usuario
LEFT Función definida por el usuario
LENGTH

LENGTH(expression)

LIKE LIKE
LIKE ALL Función personalizada definida por el usuario
LIKE ANY Función personalizada definida por el usuario
LOWER

LOWER(string)

LPAD

LPAD(string1, length[, string2])

LTRIM

LTRIM(string1, trim_chars)

MD5,MD5_HEX

MD5(string)

MD5_BINARY Función personalizada definida por el usuario
OCTET_LENGTH Función personalizada definida por el usuario
PARSE_IP Función personalizada definida por el usuario
PARSE_URL Función personalizada definida por el usuario
POSITION

STRPOS(string, substring)

REPEAT

REPEAT(string, integer)

REPLACE

REPLACE(string1, old_chars, new_chars)

REVERSE

number_characters

)

REVERSE(expression)

RIGHT Función definida por el usuario
RPAD RPAD
RTRIM

RTRIM(string, trim_chars)

RTRIMMED_LENGTH Función personalizada definida por el usuario
SHA1,SHA1_HEX

SHA1(string)

SHA1_BINARY Función personalizada definida por el usuario
SHA2,SHA2_HEX Función personalizada definida por el usuario
SHA2_BINARY Función personalizada definida por el usuario
SOUNDEX Función personalizada definida por el usuario
SPACE Función personalizada definida por el usuario
SPLIT SPLIT
SPLIT_PART Función personalizada definida por el usuario
SPLIT_TO_TABLE Función personalizada definida por el usuario
STARTSWITH Función personalizada definida por el usuario
STRTOK

SPLIT(instring, delimiter)[ORDINAL(tokennum)]


Nota: El argumento de string delimiter completo se usa como único delimitador. El delimitador predeterminado es una coma.
STRTOK_SPLIT_TO_TABLE Función personalizada definida por el usuario
SUBSTR,SUBSTRING SUBSTR
TRANSLATE Función personalizada definida por el usuario
TRIM TRIM
TRY_BASE64_DECODE_BINARY Función personalizada definida por el usuario
TRY_BASE64_DECODE_STRING

SUBSTR(string, 0, integer)

TRY_HEX_DECODE_BINARY

SUBSTR(string, -integer)

TRY_HEX_DECODE_STRING

LENGTH(expression)

UNICODE Función personalizada definida por el usuario

UPPER

UPPER

Funciones de cadena (expresiones regulares)

Snowflake BigQuery
REGEXP

IF(REGEXP_CONTAINS,1,0)=1

REGEXP_COUNT

ARRAY_LENGTH(

REGEXP_EXTRACT_ALL(

source_string,

pattern

)

)


Si se especifica position:

ARRAY_LENGTH(

REGEXP_EXTRACT_ALL(

SUBSTR(source_string, IF(position <= 0, 1, position)),

pattern

)

)


Nota: BigQuery proporciona compatibilidad con expresiones regulares mediante la biblioteca re2; consulta esa documentación para obtener su sintaxis de expresión regular.
REGEXP_INSTR

IFNULL(

STRPOS(

source_string,

REGEXP_EXTRACT(

source_string,

pattern)

), 0)


Si se especifica position, haz lo siguiente:

IFNULL(

STRPOS(

SUBSTR(source_string, IF(position <= 0, 1, position)),

REGEXP_EXTRACT(

SUBSTR(source_string, IF(position <= 0, 1, position)),

pattern)

) + IF(position <= 0, 1, position) - 1, 0)


Si se especifica occurrence:

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)


Nota: BigQuery proporciona compatibilidad con expresiones regulares mediante la biblioteca re2; consulta esa documentación para obtener su sintaxis de expresión regular.

REGEXP_LIKE

IF(REGEXP_CONTAINS,1,0)=1

REGEXP_REPLACE

REGEXP_REPLACE(

source_string,

pattern,

""

)


Si se especifica replace_string:

REGEXP_REPLACE(

source_string,

pattern,

replace_string

)


Si se especifica position:

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


Nota: BigQuery proporciona compatibilidad con expresiones regulares mediante la biblioteca re2; consulta esa documentación para obtener su sintaxis de expresión regular.
REGEXP_SUBSTR

REGEXP_EXTRACT(

source_string,

pattern

)


Si se especifica position:

REGEXP_EXTRACT(

SUBSTR(source_string, IF(position <= 0, 1, position)),

pattern

)


Si se especifica occurrence:

REGEXP_EXTRACT_ALL(

SUBSTR(source_string, IF(position <= 0, 1, position)),

pattern

)[SAFE_ORDINAL(occurrence)]


Nota: BigQuery proporciona compatibilidad con expresiones regulares mediante la biblioteca re2; consulta esa documentación para obtener su sintaxis de expresión regular.
RLIKE

IF(REGEXP_CONTAINS,1,0)=1

Funciones del sistema

Snowflake BigQuery
SYSTEM$ABORT_SESSION Función personalizada definida por el usuario
SYSTEM$ABORT_TRANSACTION Función personalizada definida por el usuario
SYSTEM$CANCEL_ALL_QUERIES Función personalizada definida por el usuario
SYSTEM$CANCEL_QUERY Función personalizada definida por el usuario
SYSTEM$CLUSTERING_DEPTH Función personalizada definida por el usuario
SYSTEM$CLUSTERING_INFORMATION Función personalizada definida por el usuario
SYSTEM$CLUSTERING_RATIO — Deprecated Función personalizada definida por el usuario
SYSTEM$CURRENT_USER_TASK_NAME Función personalizada definida por el usuario
SYSTEM$DATABASE_REFRESH_HISTORY Función personalizada definida por el usuario
SYSTEM$DATABASE_REFRESH_PROGRESS , SYSTEM$DATABASE_REFRESH_PROGRESS_BY_JOB Función personalizada definida por el usuario
SYSTEM$GET_AWS_SNS_IAM_POLICY Función personalizada definida por el usuario
SYSTEM$GET_PREDECESSOR_RETURN_VALUE Función personalizada definida por el usuario
SYSTEM$LAST_CHANGE_COMMIT_TIME Función personalizada definida por el usuario
SYSTEM$PIPE_FORCE_RESUME Función personalizada definida por el usuario
SYSTEM$PIPE_STATUS Función personalizada definida por el usuario
SYSTEM$SET_RETURN_VALUE Función personalizada definida por el usuario
SYSTEM$SHOW_OAUTH_CLIENT_SECRETS Función personalizada definida por el usuario
SYSTEM$STREAM_GET_TABLE_TIMESTAMP Función personalizada definida por el usuario
SYSTEM$STREAM_HAS_DATA Función personalizada definida por el usuario
SYSTEM$TASK_DEPENDENTS_ENABLE Función personalizada definida por el usuario
SYSTEM$TYPEOF Función personalizada definida por el usuario
SYSTEM$USER_TASK_CANCEL_ONGOING_EXECUTIONS Función personalizada definida por el usuario
SYSTEM$WAIT Función personalizada definida por el usuario
SYSTEM$WHITELIST Función personalizada definida por el usuario
SYSTEM$WHITELIST_PRIVATELINK Función personalizada definida por el usuario

Funciones de tabla

Snowflake BigQuery
GENERATOR Función personalizada definida por el usuario
GET_OBJECT_REFERENCES Función personalizada definida por el usuario
RESULT_SCAN Función personalizada definida por el usuario
VALIDATE Función personalizada definida por el usuario

Funciones hash y de utilidad

Snowflake BigQuery
GET_DDL Solicitud de función
HASH HASH es una función de propietario específica de Snowflake. No se puede traducir sin conocer la lógica subyacente usada por Snowflake.

Funciones analíticas

Snowflake BigQuery
CONDITIONAL_CHANGE_EVENT Función personalizada definida por el usuario
CONDITIONAL_TRUE_EVENT Función personalizada definida por el usuario
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 Función personalizada definida por el usuario
ROW_NUMBER ROW_NUMBER
WIDTH_BUCKET Función personalizada definida por el usuario

BigQuery también admite SAFE_CAST(expresión AS nombre de tipo), que muestra NULL si BigQuery no puede realizar una conversión (por ejemplo, SAFE_CAST("apple" AS INT64) muestra NULL).

Operadores

En las siguientes secciones, se enumeran los operadores de Snowflake y sus equivalentes de BigQuery.

Operadores aritméticos

En la siguiente tabla, se muestran las asignaciones entre los operadores aritméticos de Snowflake con sus equivalentes de BigQuery.

Snowflake BigQuery

(Unary) (+'5')

CAST("5" AS NUMERIC)

a + b

a + b

(Unary) (-'5')

(-1) * CAST("5" AS NUMERIC)


Nota: BigQuery admite menos unario estándar, pero no convierte los números enteros en formato de cadena al tipo INT64, NUMERIC o 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 ver los detalles de escala y precisión de Snowflake cuando se realizan operaciones aritméticas, consulta la documentación de Snowflake.

Operadores de comparación

Los operadores de comparación de Snowflake y los operadores de comparación de BigQuery son los mismos.

Operadores lógicos/booleanos

Los operadores lógicos/booleanos de Snowflake y operadores lógicos/booleanos de BigQuery son los mismos.

Configurar operadores

En la siguiente tabla, se muestran las asignaciones entre los operadores de conjuntos de Snowflake con sus equivalentes de BigQuery.

Snowflake BigQuery

SELECT ... INTERSECT SELECT ...

SELECT ...

INTERSECT DISTINCT

SELECT...

SELECT ... MINUS SELECT ...

SELECT ... EXCEPT SELECT …


Nota: MINUS y EXCEPT son sinónimos.

SELECT ... EXCEPT DISTINCT SELECT ...

SELECT ... UNION SELECT ...

SELECT ... UNION ALL SELECT ...

SELECT ... UNION DISTINCT SELECT ...


SELECT ... UNION ALL SELECT ...

Operadores de subconsulta

En la siguiente tabla, se muestran las asignaciones entre los operadores de subconsulta de Snowflake con sus equivalentes de BigQuery.

Snowflake BigQuery

SELECT ... FROM ... WHERE col <operator> ALL … SELECT ... FROM ... WHERE col <operator> ANY ...

BigQuery no admite una alternativa directa a ALL/ANY de Snowflake.

SELECT ... FROM ...

WHERE [NOT] EXISTS...

SELECT ... FROM ...

WHERE [NOT] EXISTS...

SELECT ... FROM ...

WHERE [NOT] IN...

SELECT ... FROM ...

WHERE [NOT] IN...

SELECT * FROM table1

UNION

SELECT * FROM table2

EXCEPT

SELECT * FROM table3

SELECT * FROM table1

UNION ALL

(

SELECT * FROM table2

EXCEPT

SELECT * FROM table3

)


Nota: BigQuery requiere paréntesis para separar diferentes operaciones de conjuntos. Si se repite el mismo operador de conjunto, no se necesitan los paréntesis.

Sintaxis de DML

En esta sección, se abordan las diferencias que existen entre la sintaxis del lenguaje de administración de datos de Snowflake y de BigQuery.

Declaración INSERT

Snowflake ofrece una palabra clave DEFAULT configurable para las columnas. En BigQuery, el valor DEFAULT para las columnas que permiten valores es NULL y DEFAULT no es compatible con las columnas obligatorias. La mayoría de las declaraciones INSERT de Snowflake son compatibles con BigQuery. En la siguiente tabla, se muestran las excepciones.

Snowflake BigQuery

INSERT [OVERWRITE] INTO table

VALUES [... | DEFAULT | NULL] ...


Nota: BigQuery no admite la inserción de objetos JSON con una declaración INSERT ..

INSERT [INTO] table (column1 [, ...])

VALUES (DEFAULT [, ...])

Nota: BigQuery no admite una alternativa directa a las funciones OVERWRITE de Snowflake. Utiliza DELETE en lugar de esta función.

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>]

...

Nota: <intoClause> representa la INSERT statement estándar, que se enumera antes.
BigQuery no admite la tabla múltiple condicional y no condicional INSERTs.

BigQuery también admite la inserción de valores mediante una subconsulta (en la que uno de los valores se calcula mediante una subconsulta), lo cual no es compatible con Snowflake. Por ejemplo:

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

Declaración COPY

Snowflake admite la copia de datos desde archivos de etapas a una tabla existente y desde una tabla a una etapa interna con nombre, una etapa externa con nombre y una ubicación externa (Amazon S3, Google Cloud Storage o Microsoft Azure).

BigQuery no usa el comando COPY de SQL para cargar datos, pero puedes usar cualquiera de las herramientas y opciones distintas de SQL para cargar datos en tablas de BigQuery. También puedes usar receptores de canalización de datos proporcionados en Apache Spark o Apache Beam para escribir datos en BigQuery.

Declaración UPDATE

La mayoría de las declaraciones UPDATE de Snowflake son compatibles con BigQuery. En la siguiente tabla, se muestran las excepciones.

Snowflake BigQuery

UPDATE table SET col = value [,...] [FROM ...] [WHERE ...]

UPDATE table

SET column = expression [,...]

[FROM ...]

WHERE TRUE


Nota: Todas las declaraciones UPDATE en BigQuery requieren una palabra clave WHERE, seguida de una condición.

Declaraciones DELETE y TRUNCATE TABLE

Las declaraciones DELETE y TRUNCATE TABLE son alternativas para quitar filas de una tabla sin afectar el esquema ni los índices de esta.

En Snowflake, DELETE y TRUNCATE TABLE mantienen los datos borrados con Time Journey de Snowflake' para fines de recuperación del período de retención de datos. Sin embargo, DELETE no borra el historial de carga de archivos externos ni los metadatos de carga.

En BigQuery, la declaración DELETE debe tener una cláusula WHERE. Para obtener más información sobre DELETE en BigQuery, consulta los ejemplos de DELETEde BigQuery en la documentación del DML.

Snowflake BigQuery

DELETE FROM table_name [USING ...]

[WHERE ...]



TRUNCATE [TABLE] [IF EXISTS] table_name

DELETE [FROM] table_name [alias]

WHERE ...


Nota: Las declaraciones DELETE de BigQuery requieren una cláusula WHERE .

Declaración MERGE

La declaración MERGE puede combinar declaraciones INSERT, UPDATE y DELETE en una sola declaración “upsert” y realizar las operaciones de forma automática. La operación MERGE debe vincular como máximo una fila de origen con cada fila de destino.

Las tablas de BigQuery tienen un límite de 1,000 declaraciones DML por día, por lo que debes consolidar de manera óptima las declaraciones INSERT, UPDATE y DELETE en una sola declaración MERGE, como se muestra en la siguiente tabla:

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,

...


Nota: Snowflake admite un parámetro de sesión ERROR_ON_NONDETERMINISTIC_MERGE para manejar resultados no deterministas.

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,

...



Nota: Todas las columnas se deben enumerar si se actualizan todas.

Declaraciones GET y LIST

La declaración GET descarga archivos de datos de una de las siguientes etapas de Snowflake en un directorio o carpeta local en una máquina cliente:

  • Etapa interna con nombre
  • Etapa interna para una tabla especificada
  • Etapa interna para el usuario actual

La declaración LIST (LS) muestra una lista de archivos que se habilitaron a etapas (es decir, se subieron desde un sistema de archivos local o se descargaron de una tabla) en una de las siguientes etapas de Snowflake:

  • Etapa interna con nombre
  • Etapa externa con nombre
  • Etapa de una tabla especificada
  • Etapa del usuario actual

BigQuery no admite el concepto de almacenamiento en etapa intermedia y no tiene los equivalentes GET y LIST.

Declaraciones PUT y REMOVE

La declaración PUT sube (es decir, almacena en etapa intermedia) los archivos de datos desde un directorio o una carpeta local en una máquina cliente a una de las siguientes etapas de Snowflake:

  • Etapa interna con nombre
  • Etapa interna para una tabla especificada
  • Etapa interna para el usuario actual

La declaración (RM) REMOVE quita los archivos que se almacenaron en etapa intermedia en una de las siguientes etapas internas del Snowflake:

  • Etapa interna con nombre
  • Etapa de una tabla especificada
  • Etapa del usuario actual

BigQuery no admite el concepto de almacenamiento en etapa intermedia y no tiene los equivalentes PUT y REMOVE.

Sintaxis del DDL

En esta sección, se abordan las diferencias que existen entre la sintaxis del lenguaje de definición de datos en Snowflake y en BigQuery.

DDL de base de datos, esquema y uso compartido

La mayor parte de la terminología de Snowflake coincide con la de BigQuery, excepto que la base de datos de Snowflake es similar al conjunto de datos de BigQuery. Consulta la asignación detallada de terminología de Snowflake a BigQuery.

Declaración CREATE DATABASE

Snowflake admite la creación y administración de una base de datos a través d ecomandos de administración de bases de datos mientras que BigQuery ofrece varias opciones, como el uso de la consola, la CLI, las bibliotecas cliente, etcétera, para crear conjuntos de datos. En esta sección, se usarán los comandos de la CLI de BigQuery correspondientes a los comandos de Snowflake para abordar las diferencias.

Snowflake BigQuery

CREATE DATABASE <name>


Nota: Snowflake proporciona estos requisitos para asignar nombres a las bases de datos. Solo permite 255 caracteres en el nombre.

bq mk <name>


Nota: BigQuery tiene requisitos de nombres de conjuntos de datos similares a Snowflake, excepto que permite 1,024 caracteres en el nombre.

CREATE OR REPLACE DATABASE <name>

En BigQuery, no se admite reemplazar el conjunto de datos.

CREATE TRANSIENT DATABASE <name>

No se admite la creación de un conjunto de datos temporal en BigQuery.

CREATE DATABASE IF NOT EXISTS <name>

El concepto no es compatible con BigQuery

CREATE DATABASE <name>

CLONE <source_db>

[ { AT | BEFORE }

( { TIMESTAMP => <timestamp> |

OFFSET => <time_difference> |

STATEMENT => <id> } ) ]

Aún no se admite la clonación de conjuntos de datos en BigQuery.

CREATE DATABASE <name>

DATA_RETENTION_TIME_IN_DAYS = <num>

La función de viaje en el tiempo a nivel de conjunto de datos no es compatible con BigQuery. Sin embargo, se admite la función de viaje en el tiempo para los resultados de las tablas y las consultas.

CREATE DATABASE <name>

DEFAULT_DDL_COLLATION = '<collation_specification>'

La intercalación en DDL no es compatible con BigQuery.

CREATE DATABASE <name>

COMMENT = '<string_literal>'

bq mk \

--description "<string_literal>" \

<name>

CREATE DATABASE <name>

FROM SHARE <provider_account>.<share_name>

La creación de conjuntos de datos compartidos no es compatible con BigQuery. Sin embargo, los usuarios pueden compartir el conjunto de datos a través de la consola o la IU una vez creado el conjunto de datos.

CREATE DATABASE <name>

AS REPLICA OF

<region>.<account>.<primary_db_name>

AUTO_REFRESH_MATERIALIZED_VIEWS_ON_SECONDARY = { TRUE | FALSE }


Nota: Snowflake ofrece la opción de mantenimiento automático en segundo plano de vistas materializadas en la base de datos secundaria que no es compatible con 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"}'

Nota: BigQuery admite la copia de conjuntos de datos mediante el Servicio de transferencia de datos de BigQuery. Consulta aquí los requisitos previos para copiar un conjunto de datos.

BigQuery también ofrece las siguientes opciones de comando bq mk, que no tienen un análogo directo en Snowflake:

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

Declaración ALTER DATABASE

En esta sección, se usarán los comandos de la CLI de BigQuery correspondientes a los comandos de Snowflake para abordar las diferencias en las declaraciones ALTER.

Snowflake BigQuery

ALTER DATABASE [ IF EXISTS ] <name> RENAME TO <new_db_name>

En BigQuery no se admite el cambio de nombre de conjuntos de datos, pero se admite la copia de conjuntos de datos.

ALTER DATABASE <name>

SWAP WITH <target_db_name>

El intercambio de conjuntos de datos no es compatible con BigQuery.

ALTER DATABASE <name>

SET

[DATA_RETENTION_TIME_IN_DAYS = <num>]

[ DEFAULT_DDL_COLLATION = '<value>']

En BigQuery, no se admite la administración de la retención y la intercalación de datos a nivel del conjunto de datos.

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

El concepto no es compatible con BigQuery.

ALTER DATABASE <name>

DISABLE REPLICATION [ TO ACCOUNTS <snowflake_region>.<account_name>

[ , <snowflake_region>.<account_name> ... ]]

El concepto no es compatible con BigQuery.

ALTER DATABASE <name>

SET AUTO_REFRESH_MATERIALIZED_VIEWS_ON_SECONDARY = { TRUE | FALSE }

El concepto no es compatible con BigQuery.

ALTER DATABASE <name> REFRESH

El concepto no es compatible con BigQuery.

ALTER DATABASE <name>

ENABLE FAILOVER TO ACCOUNTS <snowflake_region>.<account_name>

[ , <snowflake_region>.<account_name> ... ]

El concepto no es compatible con BigQuery.

ALTER DATABASE <name>

DISABLE FAILOVER [ TO ACCOUNTS <snowflake_region>.<account_name>

[ , <snowflake_region>.<account_name> ... ]]

El concepto no es compatible con BigQuery.

ALTER DATABASE <name>

PRIMARY

El concepto no es compatible con BigQuery.

Declaración DROP DATABASE

En esta sección, se usará el comando de la CLI de BigQuery correspondiente al comando de Snowflake para abordar la diferencia en la declaración DROP.

Snowflake BigQuery

DROP DATABASE [ IF EXISTS ] <name>

[ CASCADE | RESTRICT ]


Nota: En Snowflake, descartar una base de datos no la elimina de forma permanente del sistema. Se conserva una versión de la base de datos descartada durante la cantidad de días especificada por el parámetro DATA_RETENTION_TIME_IN_DAYS para la base de datos.

bq rm -r -f -d <name>


Where

-r permite quitar todos los objetos del conjunto de datos
.

-f is to skip confirmation for execution

-d indica el conjunto de datos

Nota: En BigQuery, la eliminación de un conjunto de datos es permanente. Además, la cascada no es compatible a nivel del conjunto de datos, ya que se borran todos los datos y objetos del conjunto de datos.

Snowflake también admite el comando UNDROP DATASET, que restablece la versión más reciente de un conjunto de datos descartado. Por el momento, esto no es compatible con BigQuery a nivel del conjunto de datos.

Declaración USE DATABASE

Snowflake ofrece la opción de configurar la base de datos para una sesión de usuario con el comando USE DATABASE. Esto elimina la necesidad de especificar nombres de objetos completamente calificados en los comandos de SQL. BigQuery no proporciona ninguna alternativa al comando USE DATABASE de Snowflake.

Declaración SHOW DATABASE

En esta sección, se usará el comando de la CLI de BigQuery correspondiente al comando del Snowflake para abordar la diferencia en la declaración SHOW.

Snowflake BigQuery

SHOW DATABASES


Nota: Snowflake proporciona una sola opción para enumerar y mostrar detalles sobre todas las bases de datos, incluidas las bases de datos descartadas que se encuentran dentro del período de retención.
bq ls --format=prettyjson
y/o

bq show <dataset_name>


Nota: En BigQuery, el comando ls solo proporciona información básica y nombres de conjuntos de datos y el comando show proporciona detalles, como la marca de tiempo de la última modificación, las LCA y las etiquetas de un conjunto de datos. BigQuery también proporciona más detalles sobre los conjuntos de datos a través del esquema de información.

SHOW TERSE DATABASES


Nota: Con la opción TERSE, Snowflake permite mostrar solo información o campos específicos sobre los conjuntos de datos.
El concepto no es compatible con BigQuery.

SHOW DATABASES HISTORY

El concepto de viaje en el tiempo no es compatible con BigQuery a nivel de conjunto de datos.
SHOW DATABASES

[LIKE '<pattern>']

[STARTS WITH '<name_string>']

En BigQuery, no se admite el filtrado de resultados por nombres de conjuntos de datos. Sin embargo, se admite el filtrado por etiquetas.
SHOW DATABASES

LIMIT <rows> [FROM '<name_string>']


Nota: De forma predeterminada, Snowflake no limita la cantidad de resultados. Sin embargo, el valor de LIMIT no puede ser superior a 10,000.

bq ls \

--max_results <rows>


Nota: De forma predeterminada, BigQuery solo muestra 50 resultados.

BigQuery también ofrece las siguientes opciones de comando bq, que no tienen un análogo directo en Snowflake:

  • bq ls --format=pretty: Muestra resultados con formato básico.
  • *bq ls -a: *Solo muestra conjuntos de datos anónimos (los que comienzan con un guión bajo).
  • bq ls --all: Muestra todos los conjuntos de datos, incluidos los anónimos.
  • bq ls --filter labels.key:value: Muestra los resultados filtrados por etiqueta de conjunto de datos
  • bq ls --d: Excluye los resultados del formulario de conjuntos de datos anónimos.
  • bq show --format=pretty: Muestra resultados con formato básico detallados para todos los conjuntos de datos.

Administración de SCHEMA

Snowflake proporciona varios comandos de administración de esquema similares a sus comandos de administración de bases de datos. Este concepto de creación y administración de esquemas no es compatible con BigQuery.

Sin embargo, BigQuery te permite especificar el esquema de una tabla cuando cargas datos en una tabla y cuando creas una tabla vacía. Como alternativa, puedes usar la detección automática de esquemas para los formatos de datos compatibles.

Administración de SHARE

Snowflake proporciona varios comandos de administración de recursos compartidos similares a sus comandos de administración de esquemas y bases de datos. Este concepto de creación y administración de recursos compartidos no es compatible con BigQuery.

DDL de Tabla, Vista y Secuencia

Declaración CREATE TABLE

La mayoría de las declaraciones CREATE TABLE de Snowflake son compatibles con BigQuery, excepto los siguientes elementos de la sintaxis, que no se usan en 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

)


Nota: Las restricciones UNIQUE y PRIMARY KEY son informativas y no las aplica el sistema de 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

)


en el que table_constraints son los siguientes:

[UNIQUE(column_name [, ... ])]

[PRIMARY KEY(column_name [, ...])]

[FOREIGN KEY(column_name [, ...])

REFERENCES reftable [(refcolumn)]


Nota: Las restricciones UNIQUE y PRIMARY KEY son informativas y no las aplica el sistema de Snowflake.

CREATE TABLE table_name

(

col1 data_type1[,...]

)

PARTITION BY column_name

CLUSTER BY column_name [, ...]


Nota: BigQuery no usa restricciones de tabla UNIQUE, PRIMARY KEY, FOREIGN o KEY. Para lograr una optimización similar que estas restricciones proporcionan durante la ejecución de la consulta, particiona y agrupa en clústeres tus tablas de BigQuery. CLUSTER BY admite hasta cuatro columnas.

CREATE TABLE table_name

LIKE original_table_name

Consulta este ejemplo a fin de aprender a usar las tablas INFORMATION_SCHEMA para copiar nombres de columnas, tipos de datos y restricciones NOT NULL en una tabla nueva.

CREATE TABLE table_name

(

col1 data_type1

)

BACKUP NO


Nota: En Snowflake, la configuración BACKUP NO se especifica para “guardar el tiempo de procesamiento cuando se crean instantáneas y se restablecen a partir de las instantáneas, y para reducir el espacio de almacenamiento”.
La opción de tabla BACKUP NO no se usa ni es necesaria, ya que BigQuery conserva de forma automática hasta 7 días de versiones históricas de todas tus tablas, sin ningún efecto en el tiempo de procesamiento ni en el almacenamiento facturado.

CREATE TABLE table_name

(

col1 data_type1

)

table_attributes


en el que table_attributes son los siguientes:

[DISTSTYLE {AUTO|EVEN|KEY|ALL}]

[DISTKEY (column_name)]

[[COMPOUND|INTERLEAVED] SORTKEY

(column_name [, ...])]

BigQuery es compatible con el agrupamiento en clústeres, lo que permite almacenar claves en orden.

CREATE TABLE table_name

AS SELECT ...

CREATE TABLE table_name

AS SELECT ...

CREATE TABLE IF NOT EXISTS table_name

...

CREATE TABLE IF NOT EXISTS table_name

...

BigQuery también admite la declaración DDL CREATE OR REPLACE TABLE, que reemplaza una tabla si ya existe.

La declaración CREATE TABLE de BigQuery también admite las siguientes cláusulas, que no tienen un equivalente de Snowflake:

Para obtener más información sobre CREATE TABLE en BigQuery, consulta los ejemplos de sentencias CREATE TABLE en la documentación del DDL.

Declaración ALTER TABLE

En esta sección, se usarán los comandos de la CLI de BigQuery correspondientes a los comandos de Snowflake para abordar las diferencias en las declaraciones ALTER de las tablas.

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>

El intercambio de tablas no es compatible con BigQuery.

ALTER TABLE <name>

SET

[DEFAULT_DDL_COLLATION = '<value>']

La administración de la intercalación de datos para tablas no es compatible con 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>')

Además, Snowflake proporciona opciones de agrupamiento en clústeres, columnas y restricciones para modificar tablas que no son compatibles con BigQuery.

Declaraciones DROP TABLE y UNDROP TABLE

En esta sección, se usará el comando de la CLI de BigQuery correspondiente al comando del Snowflake para abordar la diferencia en las declaraciones DROP y UNDROP.

Snowflake BigQuery

DROP TABLE [IF EXISTS] <table_name>

[CASCADE | RESTRICT]


Nota: En Snowflake, descartar una tabla no la elimina de forma permanente del sistema. Se conserva una versión de la tabla descartada durante la cantidad de días especificada por el parámetro DATA_RETENTION_TIME_IN_DAYS para la base de datos.

bq rm -r -f -d <dataset_name>.<table_name>


Where

-r permite quitar todos los objetos del conjunto de datos.
-f permite omitir la confirmación de la ejecución.
-d indica el conjunto de datos.

Nota: En BigQuery, la eliminación de una tabla tampoco es permanente, pero una instantánea se mantiene solo por 7 días.

UNDROP TABLE <table_name>

bq cp \ <dataset_name>.<table_name>@<unix_timestamp> <dataset_name>.<new_table_name>


Nota: En BigQuery, primero debes determinar una marca de tiempo UNIX de cuando existió la tabla (en milisegundos). Luego, copia la tabla en esa marca de tiempo a la tabla nueva. La tabla nueva debe tener un nombre distinto al de la tabla borrada.

Declaración CREATE EXTERNAL TABLE

BigQuery permite crear tablas externas permanentes y temporales y consultar datos directamente desde los siguientes recursos:

Snowflake permite crear una tabla externa permanente que, cuando se consulta, lee datos de un conjunto de uno o más archivos en una etapa externa especificada.

En esta sección, se usará el comando de la CLI de BigQuery correspondiente al comando del Snowflake para abordar las diferencias en la declaración 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]


Nota: Snowflake permite almacenar en etapa intermedia los archivos que contienen datos y especificar las opciones de tipo de formato para tablas externas. Tipos de formato Snowflake: CSV, JSON, AVRO, PARQUET y ORC son compatibles con BigQuery, excepto el 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


Nota: BigQuery permite crear una tabla permanente vinculada a tu fuente de datos mediante un archivo de definición de tablas [1], un archivo de esquema JSON [2] o una definición de esquema intercalado [3]. BigQuery no admite el almacenamiento en estapa intermedia de los archivos que se leerán y la especificación de las opciones 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


Nota: En la actualidad, BigQuery no admite ninguna de las opciones de parámetros opcionales que proporciona Snowflake para crear tablas externas. Para la partición, BigQuery admite el uso de la seudocolumna _FILE_NAME para crear tablas o vistas particionadas sobre las tablas externas. Para obtener más información, visita Consulta la seudocolumna _FILE_NAME.

Además, BigQuery también admite consultas de datos particionados externamente en formatos AVRO, PARQUET, ORC, JSON y CSV que se almacenan en Google Cloud Storage con un diseño de partición de subárbol predeterminado.

Declaración CREATE VIEW

En la siguiente tabla, se muestran equivalencias de la declaración CREATE VIEW entre Snowflake y 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 ...

No compatible CREATE VIEW IF NOT EXISTS

view_name

OPTIONS(view_option_list)

AS SELECT ...

CREATE VIEW view_name

AS SELECT ...

WITH NO SCHEMA BINDING

En BigQuery, para crear una vista, todos los objetos a los que se hace referencia ya deben existir.

BigQuery te permite consultar fuentes de datos externas.

Declaración CREATE SEQUENCE

Las secuencias no se usan en BigQuery; esto se puede lograr de la siguiente manera por lotes. Para obtener más información sobre las claves subrogadas y el cambio lento de las dimensiones (SCD), consulta las siguientes guías:

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

DDL de carga y descarga de datos

Snowflake admite la carga y descarga de datos mediante comandos de administración de etapas, formato de archivo y canalización. BigQuery también ofrece varias opciones para eso, como bq load, el Servicio de transferencia de datos de BigQuery, bq extract, etc. En esta sección, se destacan las diferencias en el uso de estas metodologías para la carga y descarga de datos.

DDL de la cuenta y la sesión

Los conceptos de cuenta y sesión de Snowflake no son compatibles con BigQuery. BigQuery permite la administración de cuentas a través de Cloud IAM en todos los niveles. Además, las transacciones de varias declaraciones aún no son compatibles con BigQuery.

Funciones definidas por el usuario (UDF)

Una UDF te permite crear funciones para operaciones personalizadas. Estas funciones aceptan columnas de entrada, realizan acciones y muestran el resultado de esas acciones como un valor.

Snowflake y BigQuery admiten UDF mediante expresiones de SQL y código JavaScript.

Consulta el repositorio de GitHub GoogleCloudPlatform/bigquery-utils/ para obtener una biblioteca de UDF comunes de BigQuery.

Sintaxis de CREATE FUNCTION

En la siguiente tabla, se abordan las diferencias que existen en la sintaxis de creación de UDF de SQL entre Snowflake y 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


Nota: En una UDF de SQL de BigQuery, el tipo de datos que se devuelve es opcional. BigQuery infiere el tipo de resultado de la función a partir del cuerpo de la función SQL cuando una consulta llama a la función.

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


Nota: En la actualidad, la UDF de SQL de BigQuery no es compatible con el tipo de tabla que se muestra, pero está en la hoja de ruta del producto y estará disponible pronto. Sin embargo, BigQuery admite devolver ARRAY de tipo STRUCT.

CREATE [SECURE] FUNCTION

function_name

([sql_arg_name sql_arg_data_type[,..]])

RETURNS data_type

AS sql_function_definition


Nota: Snowflake ofrece una opción segura para restringir la definición de UDF y los detalles solo a los usuarios autorizados (es decir, usuarios a los que se les otorga el rol que posee la vista).

CREATE FUNCTION

function_name

([sql_arg_name sql_arg_data_type[,..]])

RETURNS data_type

AS sql_function_definition


Nota: La volatilidad de la función no es un parámetro configurable en BigQuery. BigQuery admite la creación de roles y permisos de IAM para restringir el acceso a los datos subyacentes y la definición de las funciones.

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


Nota: El comportamiento de la función para entradas nulas se maneja de forma implícita en BigQuery y no es necesario especificarlo como una opción independiente.

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


Nota: La volatilidad de la función no es un parámetro configurable en BigQuery. Toda la volatilidad de la UDF de BigQuery es equivalente a la volatilidad IMMUTABLE de Snowflake (es decir, no realiza búsquedas en bases de datos ni usa información que no está directamente presente en su 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


Nota: Usar comillas simples o una secuencia de caracteres como símbolos de dólares$$) is not required or supported in BigQuery. BigQuery implicitly interprets the SQL expression.

CREATE [OR REPLACE] FUNCTION

function_name

([sql_arg_name sql_arg_data_type[,..]])

RETURNS data_type

[COMMENT = '<string_literal>']

AS sql_function_definition

CREATE [OR REPLACE] FUNCTION

function_name

([sql_arg_name sql_arg_data_type[,..]])

RETURNS data_type

AS sql_function_definition


Note:Adding comments or descriptions in UDFs is currently not supported in BigQuery.

CREATE [OR REPLACE] FUNCTION function_name

(x integer, y integer)

RETURNS integer

AS $$

SELECT x + y

$$


Note: Snowflake does not support ANY TYPE for SQL UDFs. However, it supports using VARIANT data types.

CREATE [OR REPLACE] FUNCTION function_name

(x ANY TYPE, y ANY TYPE)

AS

SELECT x + y



Note: BigQuery supports using ANY TYPE as argument type. The function will accept an input of any type for this argument. For more information, see templated parameter in BigQuery.

BigQuery also supports the CREATE FUNCTION IF NOT EXISTSstatement which treats the query as successful and takes no action if a function with the same name already exists.

BigQuery's CREATE FUNCTIONstatement also supports creating TEMPORARY or TEMP functions, which do not have a Snowflake equivalent. See calling UDFs for details on executing a BigQuery persistent UDF.

DROP FUNCTION syntax

The following table addresses differences in DROP FUNCTION syntax between Snowflake and BigQuery.

Snowflake BigQuery

DROP FUNCTION [IF EXISTS]

function_name

([arg_data_type, ... ])

DROP FUNCTION [IF EXISTS] dataset_name.function_name


Note: BigQuery does not require using the function's signature (argument data type) for deleting the function.

BigQuery requires that you specify the project_name if the function is not located in the current project.

Additional function commands

This section covers additional UDF commands supported by Snowflake that are not directly available in BigQuery.

ALTER FUNCTION syntax

Snowflake supports the following operations using ALTER FUNCTION syntax.

  • Renaming a UDF
  • Converting to (or reverting from) a secure UDF
  • Adding, overwriting, removing a comment for a UDF

As configuring function security and adding function comments is not available in BigQuery, ALTER FUNCTION syntax is currently not supported. However, the CREATE FUNCTION statement can be used to create a UDF with the same function definition but a different name.

DESCRIBE FUNCTION syntax

Snowflake supports describing a UDF using DESC[RIBE] FUNCTION syntax. This is currently not supported in BigQuery. However, querying UDF metadata via INFORMATION SCHEMA will be available soon as part of the product roadmap.

SHOW USER FUNCTIONS syntax

In Snowflake, SHOW USER FUNCTIONS syntax can be used to list all UDFs for which users have access privileges. This is currently not supported in BigQuery. However, querying UDF metadata via INFORMATION SCHEMA will be available soon as part of the product roadmap.

Stored procedures

Snowflake stored procedures are written in JavaScript, which can execute SQL statements by calling a JavaScript API. In BigQuery, stored procedures are defined using a block of SQL statements.

CREATE PROCEDURE syntax

In Snowflake, a stored procedure is executed with a CALL command while in BigQuery, stored procedures are executed like any other BigQuery function.

The following table addresses differences in stored procedure creation syntax between Snowflake and BigQuery.

Snowflake BigQuery

CREATE [OR REPLACE] PROCEDURE

procedure_name

([arg_name arg_data_type[,..]])

RETURNS data_type

AS procedure_definition;


Note: Snowflake requires that stored procedures return a single value. Hence, return data type is a required option.
CREATE [OR REPLACE] PROCEDURE

procedure_name

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

BEGIN

procedure_definition

END;


arg_mode: IN | OUT | INOUT


Note: BigQuery doesn't support a return type for stored procedures. Also, it requires specifying argument mode for each argument passed.

CREATE [OR REPLACE] PROCEDURE

procedure_name

([arg_name arg_data_type[,..]])

RETURNS data_type

AS

$$

javascript_code

$$;

CREATE [OR REPLACE] PROCEDURE

procedure_name

([arg_name arg_data_type[,..]])

BEGIN

statement_list

END;

CREATE [OR REPLACE] PROCEDURE

procedure_name

([arg_name arg_data_type[,..]])

RETURNS data_type

[{CALLED ON NULL INPUT | {RETURNS NULL ON NULL INPUT | STRICT}}]

AS procedure_definition;

CREATE [OR REPLACE] PROCEDURE

procedure_name

([arg_name arg_data_type[,..]])

BEGIN

procedure_definition

END;


Nota: El comportamiento de procedimientos para entradas nulas se maneja de forma implícita en BigQuery y no es necesario especificar como una opción independiente.
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;


Nota: La volatilidad de procedimiento no es un parámetro configurable en BigQuery. Es equivalente a la volatilidad IMMUTABLE de Snowflake.
CREATE [OR REPLACE] PROCEDURE

procedure_name

([arg_name arg_data_type[,..]])

RETURNS data_type

[COMMENT = '<string_literal>']

AS procedure_definition;

CREATE [OR REPLACE] PROCEDURE

procedure_name

([arg_name arg_data_type[,..]])

BEGIN

procedure_definition

END;


Nota: En la actualidad, no se admite la adición de comentarios o descripciones en las definiciones de procedimientos.
CREATE [OR REPLACE] PROCEDURE

procedure_name

([arg_name arg_data_type[,..]])

RETURNS data_type

[EXECUTE AS { CALLER | OWNER }]

AS procedure_definition;


Nota: Snowflake admite la especificación del emisor o propietario del procedimiento para la ejecución

CREATE [OR REPLACE] PROCEDURE

procedure_name

([arg_name arg_data_type[,..]])

BEGIN

procedure_definition

END;


Nota: Los procedimientos almacenados de BigQuery siempre se ejecutan como el emisor

BigQuery también admite la declaración CREATE PROCEDURE IF NOT EXISTS, que trata la consulta como correcta y no realiza ninguna acción si ya existe una función con el mismo nombre.

Sintaxis de DROP PROCEDURE

En la siguiente tabla, se abordan las diferencias que existen en la sintaxis de DROP FUNCTION entre Snowflake y BigQuery.

Snowflake BigQuery

DROP PROCEDURE [IF EXISTS]

procedure_name

([arg_data_type, ... ])

DROP PROCEDURE [IF EXISTS] dataset_name.procedure_name


Nota: BigQuery no requiere el uso de la firma del procedimiento (tipo de datos de argumento) para borrarlo.

BigQuery requiere que especifiques el project_name si el procedimiento no se encuentra en el proyecto actual.

Comandos de procedimiento adicionales

Snowflake proporciona comandos adicionales, como los siguientes:ALTER PROCEDURE, DESC[RIBE] PROCEDURE y SHOW PROCEDURES para administrar los procedimientos almacenados. Por el momento, no son compatibles con BigQuery.

Instrucciones de SQL de transacciones y metadatos

Snowflake BigQuery

BEGIN [ { WORK | TRANSACTION } ] [ NAME <name> ]; START_TRANSACTION [ name <name> ];

BigQuery siempre usa el aislamiento de instantáneas. Para obtener más información, consulta Garantías de coherencia en este documento.

COMMIT;

No se usa en BigQuery.

ROLLBACK;

No se usa en 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.

No se usa en BigQuery.

Instrucciones de SQL de varias instrucciones y varias líneas

Snowflake y BigQuery admiten transacciones (sesiones) y, por lo tanto, admiten declaraciones separadas por punto y coma que se ejecutan juntas de manera coherente. Para obtener más información, consulta Transacciones de varias declaraciones.

Columnas de metadatos para archivos almacenados en etapa intermedia

Snowflake genera metadatos de forma automática para archivos en etapas internas y externas. Estos metadatos se pueden consultar y cargar en una tabla junto con las columnas de datos regulares. Se pueden usar las siguientes columnas de metadatos:

Garantías de coherencia y aislamiento de transacción

Tanto Snowflake como BigQuery son atómicos, es decir, cumplen con el estándar ACID en un nivel por transformación en muchas filas.

Transacciones

A cada transacción de Snowflake se le asigna una hora de inicio única (incluye milisegundos) que se establece como el ID de transacción. Snowflake solo admite el nivel de aislamiento READ COMMITTED. Sin embargo, una declaración puede ver los cambios que realizó otra declaración si ambas están en la misma transacción, aunque esos cambios aún no se confirmaron. Las transacciones de Snowflake adquieren bloqueos en los recursos (tablas) cuando se modifica ese recurso. Los usuarios pueden ajustar el tiempo máximo que una declaración bloqueada esperará hasta que se agote el tiempo de espera de la declaración. Las declaraciones DML se confirman de forma automática si el parámetro AUTOCOMMIT está activado.

BigQuery también admite transacciones. BigQuery ayuda a garantizar el control de simultaneidad optimista (gana el primero en confirmarse) con el aislamiento de instantáneas, de modo que una consulta lea los últimos datos que se confirmaron antes de comenzar la consulta. Este enfoque garantiza el mismo nivel de coherencia por fila, por transformación y entre filas dentro de la misma declaración DML y evita los interbloqueos. En el caso de varias actualizaciones de DML en la misma tabla, BigQuery cambia al control de simultaneidad pesimista. Los trabajos de carga pueden ejecutarse de forma independiente por completo y agregarse a las tablas. Sin embargo, BigQuery aún no proporciona una sesión o un límite de transacción explícitos.

Revertir

Si la sesión de una transacción de Snowflake se cierra de forma inesperada antes de que la transacción se confirme o se revierta, la transacción queda en un estado desconectado. El usuario debe ejecutar SYSTEM$ABORT_TRANSACTION para anular la transacción desconectada o Snowflake revertirá la transacción desconectada después de cuatro horas inactivas. Si se produce un interbloqueo, Snowflake detecta el interbloqueo y selecciona la declaración más reciente para revertir. Si la declaración DML en una transacción abierta de manera explícita falla, los cambios se revierten, pero la transacción se mantiene abierta hasta que se confirma o se revierte. Las declaraciones DDL en Snowflake no se pueden revertir, ya que se confirman de forma automática.

BigQuery es compatible con la declaración ROLLBACK TRANSACTION. No hay una declaración ABORT en BigQuery.

Límites de bases de datos

Siempre consulta la documentación pública de BigQuery para conocer las cuotas y los límites actuales. Para aumentar las cuotas de los usuarios de gran volumen, comunícate con el equipo de Asistencia de Cloud.

Todas las cuentas de Snowflake tienen límites flexibles establecidos de forma predeterminada. Los límites flexibles se establecen durante la creación de la cuenta y pueden variar. Muchos límites flexibles de Snowflake se pueden aumentar a través del equipo de cuentas de Snowflake o un ticket de asistencia.

En la siguiente tabla, se muestra una comparación de los límites de bases de datos de Snowflake y BigQuery.

Límite Snowflake BigQuery
Tamaño del texto de la consulta 1 MB 1 MB
Cantidad máxima de consultas simultáneas XS Warehouse - 8
S Warehouse - 16
M Warehouse - 32
L Warehouse - 64
XL Warehouse - 128
100