Guía de traducción de SQL de Snowflake

En este documento se detallan las similitudes y diferencias entre las sintaxis SQL de Snowflake y BigQuery para ayudarle a acelerar la planificación y la ejecución de la migración de su EDW (almacén de datos empresarial) a BigQuery. El almacenamiento de datos de Snowflake está diseñado para funcionar con la sintaxis SQL específica de Snowflake. Es posible que tengas que modificar las secuencias de comandos escritas para Snowflake antes de poder usarlas en BigQuery, ya que los dialectos de SQL varían entre los servicios. Usa la traducción de SQL por lotes para migrar tus secuencias de comandos de SQL en bloque o la traducción de SQL interactiva para traducir consultas ad hoc. Ambas herramientas admiten SQL de Snowflake en versión preliminar.

Nota: En algunos casos, no hay una asignación directa entre un elemento SQL de Snowflake y BigQuery. Sin embargo, en la mayoría de los casos, puedes conseguir la misma funcionalidad en BigQuery que en Snowflake usando un método alternativo, como se muestra en los ejemplos de este documento.

Tipos de datos

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

Snowflake	BigQuery	Notas
NUMBER/ DECIMAL/NUMERIC	NUMERIC/BIGNUMERIC	Se puede asignar a NUMERIC o BIGNUMERIC, en función de la precisión y la escala. El tipo de datos NUMBER de 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 escala especificadas opcionalmente dentro de ciertos límites.
INT/INTEGER	BIGNUMERIC	INT/INTEGER y todos los demás tipos de datos similares a INT, como BIGINT, TINYINT, SMALLINT, BYTEINT, representan un alias del tipo de datos NUMBER en el que no se pueden especificar la precisión y la escala, que siempre son NUMBER(38, 0) . La opción de configuración REWRITE_ZERO_SCALE_NUMERIC_AS_INTEGER se puede usar para convertir INTEGER y los tipos relacionados en INT64.
BIGINT	BIGNUMERIC
SMALLINT	BIGNUMERIC
TINYINT	BIGNUMERIC
BYTEINT	BIGNUMERIC
FLOAT/ FLOAT4/ FLOAT8	FLOAT64	El tipo de datos FLOAT de Snowflake establece "NaN" como > X, donde X es cualquier valor FLOAT (excepto "NaN"). El tipo de datos FLOAT de BigQuery establece "NaN" como < X, donde X es cualquier valor FLOAT (excepto "NaN").
DOUBLE/ DOUBLE PRECISION/ REAL	FLOAT64	El tipo de datos DOUBLE de Snowflake es sinónimo del tipo de datos FLOAT de Snowflake, pero suele mostrarse incorrectamente como FLOAT. Se almacena correctamente como DOUBLE.
VARCHAR	STRING	El tipo de datos VARCHAR de Snowflake tiene una longitud máxima de 16 MB (sin comprimir). Si no se especifica la longitud, se usará la longitud máxima. El tipo de datos STRING de 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 de Snowflake tiene una longitud máxima de 1.
STRING/TEXT	STRING	El tipo de datos STRING de Snowflake es sinónimo de VARCHAR de Snowflake.
BINARY	BYTES
VARBINARY	BYTES
BOOLEAN	BOOL	El tipo de datos BOOL de BigQuery solo puede aceptar TRUE/FALSE, a diferencia del tipo de datos BOOL de Snowflake, que puede aceptar TRUE, FALSE o NULL.
DATE	DATE	El tipo DATE de Snowflake acepta los formatos de fecha más habituales, a diferencia del tipo DATE de BigQuery, que solo acepta fechas con el formato "AAAA-[M]M-[D]D".
TIME	TIME	El tipo TIME de Snowflake admite de 0 a 9 nanosegundos de precisión, mientras que el tipo TIME de BigQuery admite de 0 a 6 nanosegundos de precisión.
TIMESTAMP	DATETIME	TIMESTAMP es un alias que puede configurar el usuario y que tiene el valor predeterminado TIMESTAMP_NTZ, que se asigna a DATETIME en BigQuery.
TIMESTAMP_LTZ	TIMESTAMP
TIMESTAMP_NTZ/DATETIME	DATETIME
TIMESTAMP_TZ	TIMESTAMP
OBJECT	JSON	El tipo OBJECT de Snowflake no admite valores con tipo explícito. Los valores son del tipo VARIANT.
VARIANT	JSON	El tipo OBJECT de Snowflake no admite valores con tipo explícito. Los valores son del tipo VARIANT.
ARRAY	ARRAY<JSON>	El tipo ARRAY de Snowflake solo admite tipos VARIANT, mientras que el tipo ARRAY de BigQuery puede admitir todos los tipos de datos, excepto los arrays.

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

• DATETIME
• GEOGRAPHY

Sintaxis y operadores de consulta

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

SELECT declaración

La mayoría de las sentencias de SELECTSnowflake son compatibles con BigQuery. En la siguiente tabla se muestra 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 permite crear y hacer referencia a un alias en la misma instrucció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 alias e identificadores de Snowflake no distinguen entre mayúsculas y minúsculas de forma predeterminada. Para conservar las mayúsculas y minúsculas, incluye los alias y los identificadores entre comillas dobles (").

Cláusula FROM

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

En la siguiente tabla se muestra 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 a la función BEFORE de Snowflake que use un ID de instrucción. El valor de timestamp no puede ser anterior a 7 días de la marca de tiempo actual.
@[namespace]<stage_name>[/path]		BigQuery no admite el concepto de archivos organizados.
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 formas:

• [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 de la tabla y las filas mediante FOR SYSTEM_TIME AS OF
• Rutas de campo o cualquier ruta que se resuelva en un campo de un tipo de datos (es decir, un STRUCT)
• Matrices acopladas

Cláusula WHERE

Las cláusulas de Snowflake WHERE y BigQuery WHERE son idénticas, excepto en lo siguiente:

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 (+) para JOINs.

Tipos de JOIN

Tanto Snowflake como BigQuery admiten los siguientes tipos de combinación:

• [INNER] JOIN
• LEFT [OUTER] JOIN
• RIGHT [OUTER] JOIN
• FULL [OUTER] JOIN
• CROSS JOINy el equivalente "combinación cruzada con comas" implícita

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

En la siguiente tabla se muestra 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 se trate de una CROSS JOIN o que una de las tablas combinadas sea un campo de un tipo de datos o una matriz.
SELECT ... FROM table1 AS t1, LATERAL ( SELECT* FROM table2 AS t2 WHERE t1.col = t2.col ) Nota: A diferencia de la salida de una combinación no lateral, la salida de una combinación lateral solo incluye las filas generadas a partir de la vista insertada. No es necesario unir las filas de la izquierda con las de la derecha, ya que las filas de la izquierda ya se han tenido en cuenta al pasarse a la vista insertada.		SELECT ... FROM table1 as t1 LEFT JOIN table2 as t2 ON t1.col = t2.col Nota: BigQuery no admite una alternativa directa para las LATERAL JOIN.

Cláusula WITH

Una cláusula WITH de BigQuery contiene una o varias subconsultas con nombre que se ejecutan cada vez que una instrucción SELECT posterior las referencia. Las cláusulas de Snowflake WITH se comportan igual que las de BigQuery, con la excepción de que BigQuery no admite WITH RECURSIVE.

Cláusula GROUP BY

Snowflake admite las cláusulas GROUP BY GROUP BY, GROUP BY ROLLUP, GROUP BY GROUPING SETS, y GROUP BY CUBE, mientras que BigQuery admite las cláusulas GROUP BY GROUP BY, GROUP BY ALL, GROUP BY ROLLUP, GROUP BY GROUPING SETS, y GROUP BY CUBE.

Snowflake HAVING y BigQuery HAVING son sinónimos. Ten en cuenta que la HAVING se produce después de la GROUP BY y la agregación, y antes de la 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 agrupaciones) en cada cubo.		SELECT col1 as one, col2 as two FROM table GROUP BY CUBE (one, 2)

Cláusula ORDER BY

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

Snowflake		BigQuery
En Snowflake, los NULLs se clasifican en último lugar de forma predeterminada (orden ascendente).		En BigQuery, los NULLS se clasifican en primer lugar de forma predeterminada (orden ascendente).
Puede especificar si los valores de NULL deben ordenarse primero o al final con NULLS FIRST o NULLS LAST, respectivamente.		No hay ningún equivalente para especificar si los valores de NULL deben ser los primeros o los últimos en BigQuery.

Cláusula LIMIT/FETCH

La cláusula LIMIT/FETCH de Snowflake limita el número máximo de filas devueltas por una instrucción o subconsulta. LIMIT (sintaxis de PostgreSQL) y FETCH (sintaxis de ANSI) producen el mismo resultado.

En Snowflake y BigQuery, aplicar una cláusula LIMIT a una consulta no afecta a la cantidad de datos que se leen.

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: NULL, la cadena vacía ("") y los valores de $$$$ se aceptan y se tratan como "ilimitados". Se usa principalmente para conectores y controladores.		SELECT col1, col2 FROM table ORDER BY col1 LIMIT count OFFSET start Nota: BigQuery no admite FETCH. LIMIT sustituye a FETCH. Nota: En BigQuery, OFFSET debe usarse junto con LIMIT count. Asegúrate de definir el valor count INT64 en el número mínimo de filas ordenadas necesarias para obtener el mejor rendimiento. Ordenar todas las filas de resultados innecesariamente empeorará el rendimiento de la ejecución de las consultas.

Cláusula QUALIFY

La cláusula QUALIFY de Snowflake te permite filtrar los resultados de las funciones de ventana de forma similar a lo que hace HAVING con las funciones de agregación y las 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 de analíticas como ROW_NUMBER(), COUNT() y OVER PARTITION BY se expresa en BigQuery como una cláusula WHERE en una subconsulta que contiene el valor de analíticas. Uso de ROW_NUMBER(): SELECT col1, col2 FROM ( SELECT col1, col2 ROW NUMBER() OVER (PARTITION BY col1 ORDER by col2) RN FROM table ) WHERE RN = 1; Usar 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;

Functions

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

Funciones de agregación

En la siguiente tabla se muestran las asignaciones entre las funciones de agregación, agregación analítica y agregación aproximada de Snowflake, y sus equivalentes en 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 admite APPROX_COUNT_DISTINCT con funciones de ventana.
APPROX_PERCENTILE(expression, percentile) [OVER ...] Nota: Snowflake no tiene la opción de RESPECT NULLS	APPROX_QUANTILES([DISTINCT] expression,100) [OFFSET((CAST(TRUNC(percentile * 100) as INT64))] Nota: BigQuery no admite APPROX_QUANTILES con funciones de ventana.
APPROX_PERCENTILE_ACCUMULATE (expression)	BigQuery no permite almacenar estados intermedios al predecir valores aproximados.
APPROX_PERCENTILE_COMBINE(state)	BigQuery no permite almacenar estados intermedios al predecir valores aproximados.
APPROX_PERCENTILE_ESTIMATE(state, percentile)	BigQuery no permite almacenar estados intermedios al predecir valores aproximados.
APPROX_TOP_K(expression, [number [counters]] Nota: Si no se especifica ningún parámetro de número, el valor predeterminado es 1. Los contadores deben ser significativamente mayores que el número.	APPROX_TOP_COUNT(expression, number) Nota: BigQuery no admite APPROX_TOP_COUNT con funciones de ventana.
APPROX_TOP_K_ACCUMULATE(expression, counters)	BigQuery no permite almacenar estados intermedios al predecir valores aproximados.
APPROX_TOP_K_COMBINE(state, [counters])	BigQuery no permite almacenar estados intermedios al predecir valores aproximados.
APPROX_TOP_K_ESTIMATE(state, [k])	BigQuery no permite almacenar estados intermedios al predecir valores aproximados.
APPROXIMATE_JACCARD_INDEX([DISTINCT] expression)	Puedes usar una función definida por el usuario personalizada para implementar MINHASH con k funciones hash distintas. Otra forma de reducir la varianza de MINHASH es mantener k de los valores mínimos de una función hash. En este caso, el índice de Jaccard se puede aproximar 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 forma.
ARRAY_AGG([DISTINCT] expression1) [WITHIN GROUP (ORDER BY ...)] [OVER ([PARTITION BY expression2])] Note: Snowflake does not support ability to IGNORE|RESPECT NULLS and to LIMIT directly in ARRAY_AGG.	ARRAY_AGG([DISTINCT] expression1 [{IGNORE|RESPECT}] NULLS] [ORDER BY ...] LIMIT ...]) [OVER (...)]
AVG([DISTINCT] expression) [OVER ...]	AVG([DISTINCT] expression) [OVER ...] Nota: AVG de BigQuery no realiza conversiones automáticas en STRINGs.
BITAND_AGG(expression) [OVER ...]	BIT_AND(expression) [OVER ...] Nota: BigQuery no convierte implícitamente las columnas de caracteres o texto al INTEGER más cercano.
BITOR_AGG(expression) [OVER ...]	BIT_OR(expression) [OVER ...] Nota: BigQuery no convierte implícitamente las columnas de caracteres o texto al INTEGER más cercano.
BITXOR_AGG([DISTINCT] expression) [OVER ...]	BIT_XOR([DISTINCT] expression) [OVER ...] Nota: BigQuery no convierte implícitamente las columnas de caracteres o texto al INTEGER más cercano.
BOOLAND_AGG(expression) [OVER ...] Nota: Snowflake permite que los valores numéricos, decimales y de coma flotante se traten como TRUE si no son cero.	LOGICAL_AND(expression) [OVER ...]
BOOLOR_AGG(expression) [OVER ...] Nota: Snowflake permite que los valores numéricos, decimales y de coma flotante se traten como TRUE si no son cero.	LOGICAL_OR(expression) [OVER ...]
BOOLXOR_AGG(expression) [OVER ([PARTITION BY <partition_expr> ]) Nota: Snowflake permite que los valores numéricos, decimales y de coma flotante se traten como TRUE si no son cero.	Para expresiones numéricas: 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 admite 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 admite 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 permite especificar la precisión.	SELECT HLL_COUNT.EXTRACT(sketch) FROM ( SELECT HLL_COUNT.INIT(expression) AS sketch FROM table ) Nota: BigQuery no admite HLL_COUNT… con funciones de ventana. Un usuario no puede incluir varias expresiones en una sola función HLL_COUNT....
HLL_ACCUMULATE([DISTINCT] expression) Nota: Snowflake no 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 admite una alternativa directa a HLL_EXPORT de Snowflake.
HLL_IMPORT(object)	BigQuery no admite una alternativa directa a HLL_IMPORT de Snowflake.
KURTOSIS(expression) [OVER ...]	BigQuery no admite 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 posibilidad 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 k funciones hash distintas. Otra forma de reducir la varianza de 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 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 admite una alternativa directa a SKEWde 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 permite convertir VARCHARs en valores de coma flotante.	VAR_POP([DISTINCT] expression) [OVER ...]
VARIANCE_POP([DISTINCT] expression) [OVER ...] Nota: Snowflake permite convertir VARCHARs en valores de coma flotante.	VAR_POP([DISTINCT] expression) [OVER ...]
VAR_SAMP([DISTINCT] expression) [OVER ...] Nota: Snowflake permite convertir VARCHARs en valores de coma flotante.	VAR_SAMP([DISTINCT] expression) [OVER ...]
VARIANCE([DISTINCT] expression) [OVER ...] Nota: Snowflake permite convertir VARCHARs en valores de coma flotante.	VARIANCE([DISTINCT] expression) [OVER ...]

BigQuery también ofrece las siguientes funciones de agregación, de analíticas de agregación y de agregación aproximada, que no tienen una función análoga directa en Snowflake:

• COUNTIF
• ARRAY_CONCAT_AGG
• HLL_COUNT.MERGE

Funciones de expresiones bit a bit

En la siguiente tabla se muestran las asignaciones entre las funciones de expresión bit a bit de Snowflake habituales y sus equivalentes en BigQuery.

Si el tipo de datos de una expresión no es INTEGER, Snowflake intenta convertirlo a INTEGER. Sin embargo, BigQuery no intenta convertirlo a 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 admite DISTINCT.	BIT_XOR([DISTINCT] x) FROM UNNEST([expression1, expression2]) AS x expression ^ expression

Funciones de expresiones condicionales

En la siguiente tabla se muestran las asignaciones entre expresiones condicionales comunes de Snowflake y sus equivalentes en 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 coma flotante se traten como TRUE si no son 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 coma flotante se traten como TRUE si no son cero.	NOT expression
BOOLOR Nota: Snowflake permite que los valores numéricos, decimales y de coma flotante se traten como TRUE si no son 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 coma flotante se traten como TRUE si no son cero.	BigQuery no admite una alternativa directa a BOOLXOR.
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 uno.	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 instrucciones de condición. Se puede usar para reproducir el DECODE de Snowflake. El usuario debe usar IS NULL en lugar de = NULL para que las expresiones de selección NULL coincidan con las expresiones de búsqueda NULL.
EQUAL_NULL(expression1, expression2)	BigQuery no admite una alternativa directa a EQUAL_NULL.
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 admite una alternativa directa a IS [ NOT ] DISTINCT FROM.
expression IS [ NOT ] NULL	expression IS [ NOT ] NULL
IS_NULL_VALUE(variant_expr)	BigQuery no admite los 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 de Snowflake habituales y sus equivalentes de BigQuery.

Snowflake	BigQuery
CURRENT_ACCOUNT()	SESSION_USER() Nota: No es una comparación directa. Snowflake devuelve el ID de la cuenta, mientras que BigQuery devuelve la dirección de correo del usuario.
CURRENT_CLIENT()	Concepto no utilizado en BigQuery
CURRENT_DATABASE()	SELECT catalog_name FROM INFORMATION_SCHEMA.SCHEMATA Se devuelve una tabla con los nombres de los proyectos. No es una comparación directa.
CURRENT_DATE[()] Nota: Snowflake no exige el uso de "()" después del comando CURRENT_DATE para cumplir los estándares ANSI.	CURRENT_DATE([timezone]) Nota: CURRENT_DATE de BigQuery admite la especificación opcional de la zona horaria.
CURRENT_REGION()	SELECT location FROM INFORMATION_SCHEMA.SCHEMATA Nota: INFORMATION_SCHEMA.SCHEMATA de BigQuery devuelve referencias de ubicación más generalizadas que CURRENT_REGION() de Snowflake. No es una comparación directa.
CURRENT_ROLE()	Concepto no utilizado en BigQuery
CURRENT_SCHEMA()	SELECT schema_name FROM INFORMATION_SCHEMA.SCHEMATA Devuelve una tabla con 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()	Concepto no utilizado en BigQuery
CURRENT_SESSION()	Concepto no utilizado en BigQuery
CURRENT_STATEMENT()	SELECT query FROM INFORMATION_SCHEMA.JOBS_BY_* Nota: La INFORMATION_SCHEMA.JOBS_BY_* de BigQuery permite buscar consultas por tipo de trabajo, tipo de inicio o finalización, etc.
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 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 ANSI, se puede llamar sin "()". Define TIMEZONE como parámetro de sesión.	CURRENT_DATETIME([timezone]) CURRENT_TIMESTAMP() Nota: CURRENT_DATETIME devuelve el tipo de datos DATETIME (no compatible con Snowflake). CURRENT_TIMESTAMP devuelve el tipo de datos TIMESTAMP.
CURRENT_TRANSACTION()	SELECT job_id FROM INFORMATION_SCHEMA.JOBS_BY_* Nota: La INFORMATION_SCHEMA.JOBS_BY_* de BigQuery permite buscar IDs de trabajos por tipo de trabajo, tipo de inicio o finalización, etc.
CURRENT_USER[()] Nota: Snowflake no exige el uso de "()" después del comando CURRENT_USER para cumplir los estándares ANSI.	SESSION_USER() SELECT user_email FROM INFORMATION_SCHEMA.JOBS_BY_* Nota: No es una comparación directa. Snowflake devuelve el nombre de usuario, mientras que BigQuery devuelve la dirección de correo del usuario.
CURRENT_VERSION()	Concepto no utilizado en BigQuery
CURRENT_WAREHOUSE()	SELECT catalg_name FROM INFORMATION_SCHEMA.SCHEMATA
LAST_QUERY_ID([num])	SELECT job_id FROM INFORMATION_SCHEMA.JOBS_BY_* Nota: La INFORMATION_SCHEMA.JOBS_BY_* de BigQuery permite buscar IDs de tareas por tipo de tarea, tipo de inicio o finalización, etc.
LAST_TRANSACTION()	SELECT job_id FROM INFORMATION_SCHEMA.JOBS_BY_* Nota: La INFORMATION_SCHEMA.JOBS_BY_* de BigQuery permite buscar IDs de tareas por tipo de tarea, tipo de inicio o finalización, etc.
LOCALTIME() Nota: Snowflake no exige el uso de "()" después del comando LOCALTIME para cumplir los estándares ANSI.	CURRENT_TIME()
LOCALTIMESTAMP()	CURRENT_DATETIME([timezone]) CURRENT_TIMESTAMP() Nota: CURRENT_DATETIME devuelve el tipo de datos DATETIME (no compatible con Snowflake). CURRENT_TIMESTAMP devuelve el tipo de datos TIMESTAMP.

Funciones de conversión

En la siguiente tabla se muestran las asignaciones entre las funciones de conversión de Snowflake habituales y sus equivalentes en BigQuery.

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

Copo de nieve	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 de 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 STRING predeterminada de BigQuery usa la codificación UTF-8. Snowflake no tiene ninguna 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 se puede formatear con FORMAT_DATE, FORMAT_DATETIME, FORMAT_TIME o FORMAT_TIMESTAMP.
TO_DATE(expression[, format]) DATE(expression[, format]) Nota: Snowflake admite la conversión directa de 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 se puede formatear 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 consultar 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 se puede formatear con FORMAT.
TO_DOUBLE(expression[, format]) Nota: Los modelos de formato de Snowflake para los tipos de datos DOUBLE se pueden consultar aquí. BigQuery no tiene una alternativa al tipo de datos VARIANT.	CAST(expression AS FLOAT64) Nota: La expresión de entrada de BigQuery se puede formatear 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 consultar 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 de Snowflake. La expresión de entrada de BigQuery se puede formatear 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 se puede formatear con FORMAT, FORMAT_DATE, FORMAT_DATETIME y FORMAT_TIME. La zona horaria se puede incluir o no mediante los parámetros 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:

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

Funciones de generación de datos

En la siguiente tabla se muestran las asignaciones entre las funciones de generación de datos de Snowflake habituales y sus equivalentes en BigQuery.

Copo de nieve	BigQuery
NORMAL(mean, stddev, gen)	BigQuery no admite una comparación directa con la función NORMAL.
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 inicialización
RANDSTR(length, gen)	BigQuery no admite una comparación directa con la función RANDSTR.
SEQ1 / SEQ2 / SEQ4 / SEQ8	BigQuery no admite una comparación directa con la función SEQ_.
UNIFORM(min, max, gen)	CAST(min + RAND()*(max-min) AS INT64) Nota:Usa FDUs persistentes para crear un equivalente a UNIFORM de Snowflake. Consulta un ejemplo aquí.
UUID_STRING([uuid, name]) Nota: Snowflake devuelve 128 bits aleatorios. Snowflake admite UUIDs de las versiones 4 (aleatorios) y 5 (con nombre).	GENERATE_UUID() Nota: BigQuery devuelve 122 bits aleatorios. BigQuery solo admite UUIDs de la versión 4.
ZIPF(s, N, gen)	BigQuery no admite una comparación directa con la función ZIPF.

Funciones de fecha y hora

En la siguiente tabla se muestran las asignaciones entre las funciones de fecha y hora de Snowflake más habituales y sus equivalentes en BigQuery. Las funciones de fecha y hora de BigQuery incluyen funciones de fecha, funciones de fecha y hora, funciones de hora y funciones de marca de tiempo.

Copo de nieve	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 fechas negativas y de desbordamiento. Por ejemplo, DATE_FROM_PARTS(2000, 1 + 24, 1) devuelve el 1 de enero del 2002. Esta opción no está disponible en BigQuery.	DATE(year, month, day) DATE(timestamp_expression[, timezone]) DATE(datetime_expression)
DATE_PART(part, dateOrTime) Nota: Snowflake admite los tipos de parte del día de la semana ISO, nanosegundo y segundo, milisegundo, microsegundo y nanosegundo de la época. BigQuery no lo hace. Consulta la lista completa de tipos de piezas de Snowflake aquí..	EXTRACT(part FROM dateOrTime) Nota: BigQuery admite los tipos de parte week(<weekday>), microsecond y millisecond. Snowflake no lo hace. Consulta la lista completa de tipos de partición 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 piezas de Snowflake aquí..	DATE_TRUNC(date, part) DATETIME_TRUNC(datetime, part) TIME_TRUNC(time, part) TIMESTAMP_TRUNC(timestamp, part[, timezone]) Nota: BigQuery admite 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, start_date_or_time, end_date_or_time ) Nota: Snowflake admite el cálculo de la diferencia entre dos tipos de datos de fecha, hora y marca de tiempo en esta función.	DATE_DIFF( end_date, start_date, part ) DATETIME_DIFF( end_datetime, start_datetime, part ) TIME_DIFF( start_time, end_time, part ) TIMESTAMP_DIFF( end_timestamp, start_timestamp, part ) Nota: BigQuery admite los tipos de parte de año ISO y semana(<día de la semana>).
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 del día de la semana ISO, nanosegundo y segundo, milisegundo, microsegundo y nanosegundo de la época. BigQuery no lo hace. Consulta la lista completa de tipos de piezas de Snowflake aquí..	EXTRACT(part FROM dateOrTime) Nota: BigQuery admite los tipos de parte week(<weekday>), microsecond y millisecond. Snowflake no lo hace. Consulta la lista completa de tipos de partición 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 tengas que 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 tengas que 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) devuelve 01:40:00... Esta opción no está disponible en 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 o 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 datos 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 año ISO y semana(<día de la semana>).
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 introduzcan 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 datos 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 año ISO y semana(<día de la semana>).
TRUNC(dateOrTime, part) Nota: Snowflake admite el tipo de parte de nanosegundo. BigQuery no lo hace. Consulta la lista completa de tipos de piezas de Snowflake aquí..	DATE_TRUNC(date, part) DATETIME_TRUNC(datetime, part) TIME_TRUNC(time, part) TIMESTAMP_TRUNC(timestamp, part[, timezone]) Nota: BigQuery admite 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 una función análoga directa en Snowflake:

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

Esquema de información y funciones de tabla

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

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

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

Copo de nieve	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 los siguientes esquemas de información y funciones de tabla, que no tienen un análogo directo en Snowflake:

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

Funciones numéricas

En la siguiente tabla se muestran las asignaciones entre las funciones numéricas comunes de Snowflake y sus equivalentes en BigQuery.

Copo de nieve	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 posibilidad de indicar la precisión o la escala. ROUND no te permite especificar que se redondee hacia arriba.
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. Usar una función definida por el usuario.
FLOOR(expression [, scale])	FLOOR(expression) Nota: FLOOR de BigQuery no admite la posibilidad de indicar la precisión o la escala. ROUND no te permite especificar que se redondee hacia arriba. TRUNC funciona de forma sinónima para los números positivos, pero no para los 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 más parecido.
LN(expression)	LN(expression)
LOG(base, expression)	LOG(expression [,base]) LOG10(expression) Nota:La base predeterminada de 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 devuelto por BigQuery debe ser inferior a la expresión. No se admite el valor igual.

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

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

Funciones de datos semiestructurados

Copo de nieve	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 de cadena y binarias

Copo de nieve	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: La función CONCAT(...) de BigQuery permite concatenar cualquier número de cadenas.
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: Toda la cadena de argumentos del delimitador se usa como un único delimitador. El delimitador predeterminado es la 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)

Copo de nieve	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 ofrece compatibilidad con expresiones regulares mediante la biblioteca re2. Consulta la documentación de esta biblioteca para ver su sintaxis de expresiones regulares.
REGEXP_INSTR	IFNULL( STRPOS( source_string, REGEXP_EXTRACT( source_string, pattern) ), 0) Si se especifica position: 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 ofrece compatibilidad con expresiones regulares mediante la biblioteca re2. Consulta la documentación de esta biblioteca para ver su sintaxis de expresiones regulares.
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 ofrece compatibilidad con expresiones regulares mediante la biblioteca re2. Consulta la documentación de esta biblioteca para ver su sintaxis de expresiones regulares.
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 ofrece compatibilidad con expresiones regulares mediante la biblioteca re2. Consulta la documentación de esta biblioteca para ver su sintaxis de expresiones regulares.
RLIKE	IF(REGEXP_CONTAINS,1,0)=1

Funciones del sistema

Copo de nieve	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

Copo de nieve		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 de utilidad y hash

Copo de nieve		BigQuery
GET_DDL		Solicitud de función
HASH		HASH es una función propietaria específica de Snowflake. No se puede traducir sin conocer la lógica subyacente que usa Snowflake.

Funciones de ventana

Copo de nieve		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(expression AS typename), que devuelve NULL si BigQuery no puede realizar una conversión (por ejemplo, SAFE_CAST("apple" AS INT64) devuelve NULL).

Operadores

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

Operadores aritméticos

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

Copo de nieve	BigQuery
(Unary) (+'5')	CAST("5" AS NUMERIC)
a + b	a + b
(Unary) (-'5')	(-1) * CAST("5" AS NUMERIC) Nota: BigQuery admite el signo 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 la escala y la precisión de Snowflake al realizar 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 o booleanos

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

Operadores de conjuntos

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

Copo de nieve	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 subconsultas

En la siguiente tabla se muestran las asignaciones entre los operadores de subconsultas de Snowflake y sus equivalentes en BigQuery.

Copo de nieve	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 las distintas operaciones de conjuntos. Si se repite el mismo operador de conjunto, no es necesario usar paréntesis.

Sintaxis de DML

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

INSERT declaración

Snowflake ofrece una palabra clave DEFAULT configurable para las columnas. En BigQuery, el valor DEFAULT de las columnas que admiten valores nulos es NULL y DEFAULT no se admite en las columnas obligatorias. La mayoría de las sentencias de INSERTSnowflake son compatibles con BigQuery. En la siguiente tabla se muestran las excepciones.

Copo de nieve	BigQuery
INSERT [OVERWRITE] INTO table VALUES [... | DEFAULT | NULL] ... Nota: BigQuery no admite la inserción de objetos JSON con una INSERT instrucción..	INSERT [INTO] table (column1 [, ...]) VALUES (DEFAULT [, ...]) Nota: BigQuery no admite una alternativa directa a OVERWRITE de Snowflake. En su lugar, usa DELETE.
INSERT INTO table (column1 [, ...]) SELECT... FROM ...	INSERT [INTO] table (column1, [,...]) SELECT ... FROM ...
INSERT [OVERWRITE] ALL <intoClause> ... INSERT [OVERWRITE] {FIRST | ALL} {WHEN condition THEN <intoClause>} [...] [ELSE <intoClause>] ... Nota: <intoClause> representa el estándar INSERT statement, que se ha indicado más arriba.	BigQuery no admite INSERTs de varias tablas condicionales e incondicionales.

BigQuery también permite insertar valores mediante una subconsulta (donde uno de los valores se calcula mediante una subconsulta), lo que no se admite en Snowflake. Por ejemplo:

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

COPY declaración

Snowflake admite la copia de datos de archivos de áreas de stage a una tabla y de una tabla a un área de stage interna con nombre, a un área de stage externa con nombre y a una ubicación externa (Amazon S3, Google Cloud Storage o Microsoft Azure).

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

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

UPDATE declaración

La mayoría de las instrucciones de UPDATESnowflake son compatibles con BigQuery. En la tabla siguiente se muestran las excepciones.

Copo de nieve		BigQuery
UPDATE table SET col = value [,...] [FROM ...] [WHERE ...]		UPDATE table SET column = expression [,...] [FROM ...] WHERE TRUE Nota: Todas las instrucciones UPDATE de BigQuery requieren la palabra clave WHERE, seguida de una condición.

DELETE y TRUNCATE TABLE

Las instrucciones DELETE y TRUNCATE TABLE son dos formas de eliminar filas de una tabla sin afectar al esquema ni a los índices de la tabla.

En Snowflake, tanto DELETE como TRUNCATE TABLE conservan los datos eliminados mediante la función Time Travel de Snowflake para poder recuperarlos durante el periodo de conservación de datos. Sin embargo, DELETE no elimina el historial de carga de archivos externos ni los metadatos de carga.

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

Copo de nieve	BigQuery
DELETE FROM table_name [USING ...] [WHERE ...] TRUNCATE [TABLE] [IF EXISTS] table_name	DELETE [FROM] table_name [alias] WHERE ... Nota: Las instrucciones de BigQuery DELETE requieren una WHERE cláusula.

MERGE declaración

La instrucción MERGE puede combinar operaciones INSERT, UPDATE y DELETE en una sola instrucción "upsert" y realizar las operaciones automáticamente. La operación MERGE debe coincidir con una fila de origen como máximo por cada fila de destino.

Las tablas de BigQuery están limitadas a 1000 declaraciones de DML al día, por lo que lo ideal es consolidar las declaraciones INSERT, UPDATE y DELETE en una sola declaración MERGE, tal como se muestra en la siguiente tabla:

Copo de nieve	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 gestionar los 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: Si actualiza todas las columnas, debe incluirlas todas.

GET y LIST

La instrucción GET descarga archivos de datos de una de las siguientes áreas de stage de Snowflake en un directorio o carpeta local de un equipo cliente:

• Fase interna con nombre
• Fase interna de una tabla específica
• Fase interna del usuario actual

La instrucción LIST (LS) devuelve una lista de archivos que se han almacenado provisionalmente (es decir, que se han subido desde un sistema de archivos local o que se han descargado de una tabla) en una de las siguientes áreas de stage de Snowflake:

• Fase interna con nombre
• Fase externa con nombre
• Puesta en escena de una tabla específica
• Fase del usuario actual

BigQuery no admite el concepto de almacenamiento provisional y no tiene equivalentes de GET y LIST.

PUT y REMOVE

La instrucción PUT carga (es decir, coloca en un área de stage) archivos de datos de un directorio o una carpeta local de un equipo cliente en una de las siguientes áreas de stage de Snowflake:

• Fase interna con nombre
• Fase interna de una tabla específica
• Fase interna del usuario actual

La instrucción REMOVE (RM) elimina los archivos que se han almacenado en uno de los siguientes áreas de stage internos de Snowflake:

• Fase interna con nombre
• Puesta en escena de una tabla específica
• Fase del usuario actual

BigQuery no admite el concepto de almacenamiento provisional y no tiene equivalentes de PUT y REMOVE.

Sintaxis de DDL

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

DDL de bases de datos, esquemas y recursos compartidos

La mayoría de los términos de Snowflake coinciden con los de BigQuery, excepto que la base de datos de Snowflake es similar al conjunto de datos de BigQuery. Consulta la asignación detallada de la terminología de Snowflake a BigQuery.

CREATE DATABASE declaración

Snowflake permite crear y gestionar una base de datos mediante comandos de gestión de bases de datos, mientras que BigQuery ofrece varias opciones para crear conjuntos de datos, como la consola, la CLI o las bibliotecas cliente. En esta sección se usarán comandos de la CLI de BigQuery correspondientes a los comandos de Snowflake para abordar las diferencias.

Copo de nieve	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 para los nombres de conjuntos de datos similares a los de Snowflake, pero permite que el nombre tenga hasta 1024 caracteres.
CREATE OR REPLACE DATABASE <name>	No se puede sustituir el conjunto de datos en BigQuery.
CREATE TRANSIENT DATABASE <name>	No se pueden crear conjuntos de datos temporales en BigQuery.
CREATE DATABASE IF NOT EXISTS <name>	Concepto no admitido en BigQuery
CREATE DATABASE <name> CLONE <source_db> [ { AT | BEFORE } ( { TIMESTAMP => <timestamp> | OFFSET => <time_difference> | STATEMENT => <id> } ) ]	La clonación de conjuntos de datos aún no se admite en BigQuery.
CREATE DATABASE <name> DATA_RETENTION_TIME_IN_DAYS = <num>	BigQuery no admite la función de viaje en el tiempo a nivel de conjunto de datos. Sin embargo, se admite el viaje en el tiempo para las tablas y los resultados de las consultas.
CREATE DATABASE <name> DEFAULT_DDL_COLLATION = '<collation_specification>'	BigQuery no admite la ordenación en DDL.
CREATE DATABASE <name> COMMENT = '<string_literal>'	bq mk \ --description "<string_literal>" \ <name>
CREATE DATABASE <name> FROM SHARE <provider_account>.<share_name>	No se pueden crear conjuntos de datos compartidos en BigQuery. Sin embargo, los usuarios pueden compartir el conjunto de datos a través de la consola o de la interfaz de usuario una vez creado.
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 las vistas materializadas en la base de datos secundaria, que no se admite en 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 permite copiar conjuntos de datos mediante BigQuery Data Transfer Service. Consulta los requisitos previos para copiar conjuntos 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>

ALTER DATABASE declaración

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

Copo de nieve	BigQuery
ALTER DATABASE [ IF EXISTS ] <name> RENAME TO <new_db_name>	No se pueden cambiar los nombres de los conjuntos de datos en BigQuery, pero sí se pueden copiar.
ALTER DATABASE <name> SWAP WITH <target_db_name>	No se pueden intercambiar conjuntos de datos en BigQuery.
ALTER DATABASE <name> SET [DATA_RETENTION_TIME_IN_DAYS = <num>] [ DEFAULT_DDL_COLLATION = '<value>']	BigQuery no admite la gestión de la conservación y la ordenación de datos a nivel de 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> ... ]	Concepto no admitido en BigQuery.
ALTER DATABASE <name> DISABLE REPLICATION [ TO ACCOUNTS <snowflake_region>.<account_name> [ , <snowflake_region>.<account_name> ... ]]	Concepto no admitido en BigQuery.
ALTER DATABASE <name> SET AUTO_REFRESH_MATERIALIZED_VIEWS_ON_SECONDARY = { TRUE | FALSE }	Concepto no admitido en BigQuery.
ALTER DATABASE <name> REFRESH	Concepto no admitido en BigQuery.
ALTER DATABASE <name> ENABLE FAILOVER TO ACCOUNTS <snowflake_region>.<account_name> [ , <snowflake_region>.<account_name> ... ]	Concepto no admitido en BigQuery.
ALTER DATABASE <name> DISABLE FAILOVER [ TO ACCOUNTS <snowflake_region>.<account_name> [ , <snowflake_region>.<account_name> ... ]]	Concepto no admitido en BigQuery.
ALTER DATABASE <name> PRIMARY	Concepto no admitido en BigQuery.

DROP DATABASE declaración

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

Copo de nieve	BigQuery
DROP DATABASE [ IF EXISTS ] <name> [ CASCADE | RESTRICT ] Nota: En Snowflake, al eliminar una base de datos, no se quita de forma permanente del sistema. Se conserva una versión de la base de datos eliminada durante el número de días especificado por el parámetro DATA_RETENTION_TIME_IN_DAYS de la base de datos.	bq rm -r -f -d <name> Where -r elimina 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, no se admite la eliminación en cascada a nivel del conjunto de datos, ya que se eliminan todos los datos y objetos del conjunto de datos.

Snowflake también admite el comando UNDROP DATASET que restaura la versión más reciente de un conjunto de datos eliminado. Actualmente, BigQuery no admite esta función a nivel de conjunto de datos.

USE DATABASE declaración

Snowflake ofrece la opción de definir la base de datos de una sesión de usuario mediante el comando USE DATABASE. De esta forma, no es necesario especificar nombres de objeto completos en los comandos SQL. BigQuery no ofrece ninguna alternativa al comando USE DATABASE de Snowflake.

SHOW DATABASE declaración

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

Copo de nieve	BigQuery
SHOW DATABASES Nota: Snowflake ofrece una única opción para enumerar y mostrar detalles sobre todas las bases de datos, incluidas las eliminadas que se encuentran dentro del periodo de conservación.	bq ls --format=prettyjson y/o bq show <dataset_name> Nota: En BigQuery, el comando ls solo proporciona nombres de conjuntos de datos e información básica, mientras que el comando show ofrece detalles como la marca de tiempo de la última modificación, las listas de control de acceso y las etiquetas de un conjunto de datos. BigQuery también proporciona más detalles sobre los conjuntos de datos a través de Information Schema.
SHOW TERSE DATABASES Nota: Con la opción TERSE, Snowflake permite mostrar solo información o campos específicos sobre los conjuntos de datos.	Concepto no admitido en BigQuery.
SHOW DATABASES HISTORY	El concepto de viaje en el tiempo no se admite en BigQuery a nivel de conjunto de datos.
SHOW DATABASES [LIKE '<pattern>'] [STARTS WITH '<name_string>']	BigQuery no admite el filtrado de resultados por nombres de conjuntos de datos. Sin embargo, se puede filtrar por etiquetas.
SHOW DATABASES LIMIT <rows> [FROM '<name_string>'] Nota: De forma predeterminada, Snowflake no limita el número de resultados. Sin embargo, el valor de LIMIT no puede superar los 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: devuelve resultados básicos con formato.
• *bq ls -a: *devuelve solo los conjuntos de datos anónimos (los que empiezan por un guion bajo).
• bq ls --all: devuelve todos los conjuntos de datos, incluidos los anónimos.
• bq ls --filter labels.key:value: devuelve los resultados filtrados por la etiqueta del conjunto de datos.
• bq ls --d: excluye los conjuntos de datos anónimos de los resultados.
• bq show --format=pretty: devuelve resultados básicos detallados con formato de todos los conjuntos de datos.

Gestión de SCHEMA

Snowflake ofrece varios comandos de gestión de esquemas similares a los comandos de gestión de bases de datos. BigQuery no admite este concepto de crear y gestionar esquemas.

Sin embargo, BigQuery te permite especificar el esquema de una tabla al cargar datos en ella y al crear una tabla vacía. También puedes usar la detección automática de esquemas para los formatos de datos admitidos.

Gestión de SHARE

Snowflake proporciona varios comandos de gestión de recursos compartidos similares a los comandos de gestión de bases de datos y esquemas. Este concepto de crear y gestionar recursos compartidos no se admite en BigQuery.

DDL de tablas, vistas y secuencias

CREATE TABLE declaración

La mayoría de las instrucciones CREATE TABLE de Snowflake son compatibles con BigQuery, excepto los siguientes elementos de sintaxis, que no se usan en BigQuery:

Copo de nieve	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: UNIQUE y PRIMARY KEY son restricciones informativas que no 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 ) donde table_constraints están: [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 las restricciones de tabla UNIQUE, PRIMARY KEY ni FOREIGN KEY. Para conseguir una optimización similar a la que proporcionan estas restricciones durante la ejecución de las consultas, crea particiones y clústeres en tus tablas de BigQuery. CLUSTER BY admite hasta cuatro columnas.
CREATE TABLE table_name LIKE original_table_name	Consulta este ejemplo para saber cómo 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 opción BACKUP NO se especifica para "ahorrar tiempo de procesamiento al crear y restaurar capturas, así como para reducir el espacio de almacenamiento".	La opción de tabla BACKUP NO no se usa ni es necesaria porque BigQuery conserva automáticamente hasta 7 días de versiones históricas de todas tus tablas, sin que esto afecte al tiempo de procesamiento ni al almacenamiento facturado.
CREATE TABLE table_name ( col1 data_type1 ) table_attributes donde table_attributes están: [DISTSTYLE {AUTO|EVEN|KEY|ALL}] [DISTKEY (column_name)] [[COMPOUND|INTERLEAVED] SORTKEY (column_name [, ...])]	BigQuery admite 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 instrucción DDL CREATE OR REPLACE TABLE, que sobrescribe una tabla si ya existe.

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

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

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

ALTER TABLE declaración

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

Copo de nieve	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>	No se pueden intercambiar tablas en BigQuery.
ALTER TABLE <name> SET [DEFAULT_DDL_COLLATION = '<value>']	BigQuery no admite la gestión de la ordenación de datos de las tablas.
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 ofrece opciones de clúster, columna y restricción para modificar tablas que no son compatibles con BigQuery.

DROP TABLE y UNDROP TABLE

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

Copo de nieve	BigQuery
DROP TABLE [IF EXISTS] <table_name> [CASCADE | RESTRICT] Nota: En Snowflake, al eliminar una tabla, no se quita de forma permanente del sistema. Se conserva una versión de la tabla eliminada durante el número de días especificado por el parámetro DATA_RETENTION_TIME_IN_DAYS de la base de datos.	bq rm -r -f -d <dataset_name>.<table_name> Where -r sirve para eliminar todos los objetos del conjunto de datos. -f sirve para 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 actualmente se mantiene una instantánea durante 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 la marca de tiempo UNIX de cuándo existía la tabla (en milisegundos). A continuación, copia la tabla de esa marca de tiempo en una tabla nueva. La nueva tabla debe tener un nombre diferente al de la tabla eliminada.

CREATE EXTERNAL TABLE declaración

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

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

Snowflake permite crear una tabla externa permanente que, cuando se consulta, lee los datos de un conjunto de uno o varios archivos en un área de stage externa especificada.

En esta sección se usará el comando de la CLI de BigQuery correspondiente al comando de Snowflake para abordar las diferencias en la instrucción CREATE EXTERNAL TABLE.

Copo de nieve	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 organizar los archivos que contienen los datos que se van a leer y especificar las opciones de tipo de formato de las tablas externas. BigQuery admite todos los tipos de formato de Snowflake (CSV, JSON, AVRO, PARQUET y ORC), 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 tabla [1], un archivo de esquema JSON [2] o una definición de esquema insertada [3]. BigQuery no admite la preparación de archivos para leerlos ni la especificación de 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: Actualmente, BigQuery no admite ninguna de las opciones de parámetros opcionales que ofrece Snowflake para crear tablas externas. En cuanto a las particiones, BigQuery permite usar la pseudocolumna _FILE_NAME para crear tablas o vistas con particiones a partir de las tablas externas. Para obtener más información, consulta Consultar la pseudocolumna _FILE_NAME.

Además, BigQuery también permite consultar datos particionados externamente en formatos AVRO, PARQUET, ORC, JSON y CSV que se almacenan en Google Cloud Storage mediante un diseño de partición de Hive predeterminado.

CREATE VIEW declaración

En la siguiente tabla se muestran las equivalencias entre Snowflake y BigQuery para la instrucción CREATE VIEW.

Copo de nieve	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 referenciados deben existir. BigQuery permite consultar fuentes de datos externas.

CREATE SEQUENCE declaración

Las secuencias no se usan en BigQuery. Esto se puede conseguir de la siguiente forma por lotes. Para obtener más información sobre las claves subrogadas y las dimensiones que cambian lentamente (SCD), consulta las siguientes guías:

• Claves subrogadas de BigQuery
• BigQuery y las claves subrogadas: un enfoque práctico

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 gestión de fases, formatos de archivo y canales. BigQuery también ofrece varias opciones para ello, como bq load, BigQuery Data Transfer Service y bq extract, entre otras. En esta sección se destacan las diferencias en el uso de estas metodologías para cargar y descargar datos.

DDL de cuenta y sesión

Los conceptos de cuenta y sesión de Snowflake no se admiten en BigQuery. BigQuery permite gestionar cuentas a todos los niveles a través de Cloud IAM. Además, BigQuery aún no admite transacciones con varias instrucciones.

Funciones definidas por el usuario (UDF)

Una función definida por el usuario te permite crear funciones para operaciones personalizadas. Estas funciones aceptan columnas de entrada, realizan acciones y devuelven el resultado de esas acciones como un valor.

Tanto Snowflake como BigQuery admiten funciones definidas por el usuario (UDF) mediante expresiones SQL y código JavaScript.

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

Sintaxis de CREATE FUNCTION

En la siguiente tabla se muestran las diferencias en la sintaxis de creación de UDFs de SQL entre Snowflake y BigQuery.

Copo de nieve	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 las UDFs de SQL de BigQuery, el tipo de datos devuelto es opcional. BigQuery deduce 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 las UDFs de SQL de BigQuery, actualmente no se admite el tipo de tabla devuelto, pero está en la hoja de ruta del producto y estará disponible pronto. Sin embargo, BigQuery admite la devolución de 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 y los detalles de las funciones definidas por el usuario solo a los usuarios autorizados (es decir, los usuarios a los que se les ha concedido el rol propietario de la vista).	CREATE FUNCTION function_name ([sql_arg_name sql_arg_data_type[,..]]) RETURNS data_type AS sql_function_definition Nota: La seguridad de las funciones no es un parámetro configurable en BigQuery. BigQuery permite crear roles y permisos de gestión de identidades y accesos para restringir el acceso a los datos subyacentes y a la definición de 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 las entradas nulas se gestiona 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 las funciones no es un parámetro configurable en BigQuery. Toda la volatilidad de las UDFs de BigQuery equivale a la volatilidad IMMUTABLE de Snowflake (es decir, no realiza búsquedas en la base 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: Si usas comillas simples o una secuencia de caracteres como las comillas de dólar ($$) is not required or supported in BigQuery. BigQuery implicitly interprets the SQL expression.
CREATE [OR REPLACE] FUNCTION function_name ([sql_arg_name sql_arg_data_type[,..]]) RETURNS data_type [COMMENT = '<string_literal>'] AS sql_function_definition	CREATE [OR REPLACE] FUNCTION function_name ([sql_arg_name sql_arg_data_type[,..]]) RETURNS data_type AS sql_function_definition Note:Adding comments or descriptions in UDFs is currently not supported in BigQuery.
CREATE [OR REPLACE] FUNCTION function_name (x integer, y integer) RETURNS integer AS $$ SELECT x + y $$ Note: Snowflake does not support ANY TYPE for SQL UDFs. However, it supports using VARIANT data types.	CREATE [OR REPLACE] FUNCTION function_name (x ANY TYPE, y ANY TYPE) AS SELECT x + y Note: BigQuery supports using ANY TYPE as argument type. The function will accept an input of any type for this argument. For more information, see templated parameter in BigQuery.

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

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

DROP FUNCTION syntax

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

Snowflake	BigQuery
DROP FUNCTION [IF EXISTS] function_name ([arg_data_type, ... ])	DROP FUNCTION [IF EXISTS] dataset_name.function_name Note: BigQuery does not require using the function's signature (argument data type) for deleting the function.

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

Additional function commands

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

ALTER FUNCTION syntax

Snowflake supports the following operations using ALTER FUNCTION syntax.

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

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

DESCRIBE FUNCTION syntax

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

SHOW USER FUNCTIONS syntax

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

Stored procedures

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

CREATE PROCEDURE syntax

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

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

Snowflake	BigQuery
CREATE [OR REPLACE] PROCEDURE procedure_name ([arg_name arg_data_type[,..]]) RETURNS data_type AS procedure_definition; Note: Snowflake requires that stored procedures return a single value. Hence, return data type is a required option.	CREATE [OR REPLACE] PROCEDURE procedure_name ([arg_mode arg_name arg_data_type[,..]]) BEGIN procedure_definition END; arg_mode: IN | OUT | INOUT Note: BigQuery doesn't support a return type for stored procedures. Also, it requires specifying argument mode for each argument passed.
CREATE [OR REPLACE] PROCEDURE procedure_name ([arg_name arg_data_type[,..]]) RETURNS data_type AS $$ javascript_code $$;	CREATE [OR REPLACE] PROCEDURE procedure_name ([arg_name arg_data_type[,..]]) BEGIN statement_list END;
CREATE [OR REPLACE] PROCEDURE procedure_name ([arg_name arg_data_type[,..]]) RETURNS data_type [{CALLED ON NULL INPUT | {RETURNS NULL ON NULL INPUT | STRICT}}] AS procedure_definition;	CREATE [OR REPLACE] PROCEDURE procedure_name ([arg_name arg_data_type[,..]]) BEGIN procedure_definition END; Nota: El comportamiento de los procedimientos con entradas nulas se gestiona de forma implícita en BigQuery y no es necesario especificarlo 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 los procedimientos no es un parámetro configurable en BigQuery. Es equivalente a la volatilidad de 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:Actualmente, no se pueden añadir comentarios ni descripciones en las definiciones de procedimientos de BigQuery.
CREATE [OR REPLACE] PROCEDURE procedure_name ([arg_name arg_data_type[,..]]) RETURNS data_type [EXECUTE AS { CALLER | OWNER }] AS procedure_definition; Nota: Snowflake permite especificar el llamador o el 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 llamador.

BigQuery también admite la instrucció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 muestran las diferencias en la sintaxis de DROP FUNCTION entre Snowflake y BigQuery.

Copo de nieve	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 del argumento) para eliminarlo.

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 ALTER PROCEDURE, DESC[RIBE] PROCEDURE y SHOW PROCEDURES para gestionar los procedimientos almacenados. Actualmente, no se admiten en BigQuery.

Declaraciones SQL de metadatos y transacciones

Copo de nieve	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 la sección Garantías de coherencia de 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 SQL de varias líneas y con varias instrucciones

Tanto Snowflake como BigQuery admiten transacciones (sesiones) y, por lo tanto, admiten instrucciones separadas por puntos y comas que se ejecutan de forma coherente. Para obtener más información, consulta el artículo sobre las transacciones con varias declaraciones.

Columnas de metadatos de archivos de almacenamiento temporal

Snowflake genera automáticamente metadatos de los archivos de las áreas de almacenamiento internas y externas. Estos metadatos se pueden consultar y cargar en una tabla junto con las columnas de datos normales. Se pueden utilizar las siguientes columnas de metadatos:

• METADATA$FILENAME
• METADATA$FILE_ROW_NUMBER

Garantías de coherencia y aislamiento de transacciones

Tanto Snowflake como BigQuery son atómicos, es decir, cumplen los requisitos de ACID a nivel de mutación en muchas filas.

Transacciones

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

BigQuery también admite transacciones. BigQuery ayuda a asegurar el control de concurrencia optimista (el primero en confirmar gana) con el aislamiento de instantáneas, en el que una consulta lee los últimos datos confirmados antes de que empiece la consulta. Este enfoque garantiza el mismo nivel de coherencia por fila y por mutación, así como entre las filas de la misma instrucción DML, pero evita los interbloqueos. En el caso de que se realicen varias actualizaciones de DML en la misma tabla, BigQuery cambia al control de concurrencia pesimista. Las tareas de carga se pueden ejecutar de forma completamente independiente y añadir datos a las tablas. Sin embargo, BigQuery aún no proporciona un límite de transacción ni una sesión explícitos.

Restauración

Si la sesión de una transacción de Snowflake se termina de forma inesperada antes de que se confirme o se revierta la transacción, esta se queda en un estado independiente. El usuario debe ejecutar SYSTEM$ABORT_TRANSACTION para anular la transacción independiente. De lo contrario, Snowflake revertirá la transacción independiente después de cuatro horas de inactividad. Si se produce un interbloqueo, Snowflake lo detecta y selecciona la instrucción más reciente para revertirla. Si se produce un error en la instrucción DML de una transacción abierta explícitamente, los cambios se revierten, pero la transacción permanece abierta hasta que se confirma o se revierte. Las instrucciones DDL de Snowflake no se pueden deshacer, ya que se confirman automáticamente.

BigQuery admite la instrucción ROLLBACK TRANSACTION. No hay ninguna declaración ABORT en BigQuery.

Límites de las bases de datos

Consulta siempre la documentación pública de BigQuery para ver las cuotas y los límites más recientes. Muchas cuotas para usuarios con grandes volúmenes se pueden aumentar poniéndose en contacto con el equipo de Asistencia de Cloud.

Todas las cuentas de Snowflake tienen límites flexibles definidos de forma predeterminada. Los límites flexibles se definen 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 mediante una incidencia.

En la siguiente tabla se comparan los límites de las bases de datos de Snowflake y BigQuery.

Límite	Copo de nieve	BigQuery
Tamaño del texto de la consulta	1 MB	1 MB
Número máximo de consultas simultáneas	XS Warehouse - 8 S Warehouse - 16 M Warehouse - 32 L Warehouse - 64 XL Warehouse - 128	100